The visual installation atlas

1. Read the cabinet plate, Android model/version and actual controller model. Compare the software machine number with the approved cabinet record; an Android USB serial is a different identifier.
2. ZHZN vending cabinet: install the approved ai.intelliverse.zhzn.kioskx APK with the provisioned kiosk role and supported driver. Reyeah vending cabinet: use the approved real com.ruiye.jd vending APK. They are not interchangeable.
3. Reyeah companion support: the same ZHZN package can run in the exact companion role alongside the Reyeah vending app. Provision and verify that role before its first launch; the default role starts a vending agent. It provides support capabilities and must not become a second vending driver.
4. Operator phone: use Flutter Operator ai.intelliversex.operatorx for the full phone workflow, or the compact native ai.intelliversex.kioskx.operator with its Full console fallback. Neither belongs on the cabinet as its vending controller.
5. Emulator, debug, oldcloud and pristine vendor-reference APKs are not production choices. An unidentified VC EL/Silkron/Vendron cabinet must stay on its supported installation while its controller and integration are qualified.

Stop if: model, package, signer or ownership is uncertain. Identify it; do not try a different manufacturer's APK to see whether it works.

Next: Android basics. Exact download choices and verification records.

1. Tap once with a dry finger to select. Long-press means hold your finger in one place until the menu opens. Do not repeatedly tap a slow payment or install button.
2. Swipe by sliding a finger. On an unlocked service device, swipe down from the top for notifications and quick settings; swipe again if needed. Tap the gear for Settings. A managed kiosk may intentionally block this; use its authorized service procedure.
3. The Back triangle returns one screen; Home returns to the selected Home app; the square shows recent apps. Some Android versions use gestures instead. These controls do not all appear on every industrial display.
4. Tap a text field to open the keyboard. Use 123/?123 for numbers/symbols, the eye icon only in a private setting to inspect a password, and Back to hide the keyboard. Passwords are case-sensitive.
5. In Settings → About tablet/device, record the Android version and model. Use System → Date & time or the OEM equivalent to set a correct clock; time zone must match the venue's operational record.

Stop if: touch fails, the screen flickers in Android Settings, or the cabinet repeatedly reboots. Have the technician diagnose the panel/power/hardware before installing software.

Next: Connect Wi-Fi. Full Android manual.

1. Obtain the venue's approved network name and password. In authorized Android service mode open Settings → Network & internet → Internet/Wi-Fi, or Settings → Wi-Fi on older Android. Turn Wi-Fi on.
2. Tap the exact network name. Enter the password carefully; check capital letters, spaces and symbols. Tap Connect and wait for Connected. Do not use a similarly named network supplied by a stranger.
3. If Android says Sign in to network, the venue may use a captive portal. Ask the venue IT owner for a supported unattended-machine connection. A portal that expires overnight is unsuitable without an approved renewal solution.
4. Return to the vending app. Check the correct machine ID, a fresh cloud presence time, catalog and enabled payment readiness. Refresh the same machine in Operator. Wi-Fi bars alone do not prove internet, DNS, TLS, authentication or payment access.
5. For a failure, check password, signal, correct clock, router uplink and venue firewall with IT. Try the approved alternative Ethernet/LTE path if fitted. Restore service through the assigned PIN process and retest after a cold restart. Preserve configuration and pending orders.

Stop if: Android is connected but enrollment, catalog or payments are still failing. Do not clear app storage. The Linux agent's SoftAP procedure is a different platform; do not assume the Android APK creates that hotspot.

Next: Verify the APK. Network and Android instructions.

1. Obtain the approved APK from the current downloads. Match its full SHA-256, package, version code, CPU compatibility and trusted signing certificate with the release record. A filename alone is insufficient.
2. Finish active purchases, resolve unknown outcomes and reserve a service window. Keep approved recovery material and the cabinet's existing identity/configuration; do not clone another machine's app data.
3. A technician connects the laptop using the approved data/service USB port and cable. Charging-only cables cannot provide ADB. Enable the OEM-approved debugging procedure and approve this laptop on the cabinet when prompted.
4. Use adb devices -l, then explicitly select the intended device for every command. If unauthorized, approve the prompt; if absent, check the cable, port, driver and debugging setting. Do not issue commands against an ambiguous device list.
5. Follow the exact cabinet-specific install command in its manual, then check package/version. Launch a vending app only after its required provisioning; for a companion, complete the role and private-credential setup before first launch. A signature mismatch requires an approved migration; an ABI mismatch needs the correct build; a downgrade needs an approved higher version code.

Stop if: installation is refused. Do not uninstall the production app, wipe storage, disable security globally or force a downgrade to get past the error.

Next: USB/Files installation or managed kiosk setup. ZHZN commands, Reyeah migration.

1. If the approved installation route is a USB drive or download, open Android Files/File Manager and select the verified APK. Use the OEM-approved USB/OTG port. Do not open an unknown APK from a message or advertisement.
2. If Android blocks the source, open the installer's Settings → Allow from this source for that specific trusted Files/browser app. Older Android may label this Unknown sources; follow the OEM's managed installation policy. Return to the same file and tap Install.
3. Wait for installation to finish and verify the installed package/version. For a companion, do not tap Open before its role and private credentials are provisioned; follow companion setup. For a vending app, complete its required provisioning and then open it. Revoke temporary unknown-app installation permission after use and remove the service drive when safe.
4. Grant camera, microphone and the correct USB device only when needed by the approved diagnostic or app workflow. Camera permission on an operator phone enables scanning; it does not authorize a cabinet vend.
5. If a permission was denied, use Settings → Apps → [the exact app] → Permissions, grant the needed permission and retry the affected operation. A USB permission must refer to the correct controller. Android may ask again after reconnecting.

Stop if: Android policy prevents the approved route. Ask the provisioning owner for the managed install procedure. A manual Files install does not establish device ownership or silent update capability.

Next: Home and management. Complete APK installation.

1. For a ZHZN vending role, configure the approved vending app as Home using the OEM's default-app settings. Test Home behavior.
2. For the ZHZN kiosk role, the authorized installer separately provisions and verifies device owner using the approved clean-device process. Device owner and Home are different settings; ordinary screen pinning is user-exitable. This is not a blanket device-owner instruction for Reyeah, companion or phone APKs. Do not factory-reset a working cabinet merely because device-owner provisioning is refused.
3. For Reyeah, retain the approved OEM auto-start/kiosk policy for com.ruiye.jd. A support companion must not replace the vending Home app. Only one process should drive the controller.
4. Test kiosk confinement, authorized service access, return from service and a cold reboot. The cabinet must return to the intended vending screen, same identity, board connection and cloud state without a technician tapping a launcher.
5. Secure service credentials through the operator's approved channel. Remove/revoke bench access according to the release process; deleting a provisioning file does not necessarily remove a cached credential.

Stop if: Android management is missing, the wrong Home app starts, or service access cannot be recovered. Record the failure and use the provisioning owner; do not ship an assumed lockdown.

Next: Physical hardware. ZHZN management details.

1. A qualified technician matches the cabinet's approved wiring/port map, supply, controller, firmware and tray layout. Isolate power before internal inspection according to the manufacturer's procedure. The illustration is not a wiring pinout.
2. Record the actual display, antennas, controller, card/MDB devices, sensors, lift/spirals, coin/bill mechanisms, cooling, printer and power-bank option. Photograph identification labels where appropriate; preserve leading zeros in accessory IDs.
3. Verify correct ports, protocol/module, power and grounding against the actual manufacturer's diagram. Do not experiment with serial voltage levels, force baud rates or attach a second driver to the same port.
4. Close and secure the mechanism before tests. Dispense from every configured lane, including first/last lanes; verify correct item, quantity, pickup detection and stock mapping. A motor acknowledgment or board handshake alone is insufficient.
5. Test fitted payment devices, cooling and accessories under the destination profile. Record pass, fail, not tested, or a justified not fitted for optional hardware. Required hardware cannot be made optional to clear a gate.

Stop if: any lane is mis-mapped, a fitted device fails, electrical condition is unsafe or the board is unidentified. Never reach into moving machinery or create a jam with a hand/object.

Next: ZHZN enrollment or Reyeah conversion. Manufacturer physical test catalog.

1. Have the provisioning owner prepare the correct machine identity, backend, kiosk role, board profile and approved per-device/bootstrap credential workflow. Record the APK's persisted hardware serial and its separate device ID; an enrollment arm bound to a head unit must use that actual device ID, not the printed plate, ADB serial or reader ID. Do not publish credentials in this guide, a screenshot or the crate.
2. If using bootstrap-authenticated accessory tooling, finish real fitted/absent records and bindings at the approved point before enrollment. After enrollment, that endpoint requires the established device credential/witness workflow.
3. Launch ZHZN and wait for enrollment to complete. Compare the actual serial/device ID in the app, factory build and cloud; verify the issued key identity and a subsequent authenticated contact. A catalog screen or registering/retry state is not evidence of completed enrollment.
4. Check board detection on the intended serial/USB port with its protocol/module. On connection trouble inspect power, permissions, cabling and profile with the technician; then rescan. Keep existing identity and queued reports intact.
5. Treat the actual identity result: needs-arming requires the administrator's arm; budget needs the permitted retry delay; needs-key-rescue requires recovery of the existing key; revoked requires the identity administrator; no-bootstrap requires correct provisioning. Preserve data. Do not invent a serial, clone another device or reinstall to evade the error.

Ready for factory diagnostics when: this physical cabinet has the intended identity, working board, fresh authenticated cloud presence and correct machine configuration. Empty inventory is expected before the operator's product/stock setup; it is not a reason to reinstall. The cabinet remains unclaimed until the intended operator's claim stage.

Next: ZHZN factory diagnostics. Credentials, factory prerequisites.

1. Use the authorized PIN service menu → Factory test / 工厂测试. Ensure the approved factory API credential is readable through the provisioning workflow; this is separate from device enrollment.
2. Camera: tap Capture, inspect the identified camera's actual image. Speaker: tap Play tone and listen.
3. Microphone: tap Record 2 s — speak now and speak; inspect the automatic result and RMS level. The current step does not provide recording playback.
4. Touch: tap all nine required zones. Screen: use Show R/G/B/W pages, tap through all four colors and inspect the physical panel.
5. Board: inspect the identified port/protocol/module; correct problems and Rescan. Review all six results in Summary. A skipped check is not a pass.
6. Wait for the actual diagnostic and FAT upload results. Retry after fixing connectivity; read refusal reasons. The APK uploads observed board and screen/touch FAT rows, not fabricated passes for power, network or every-lane dispensing.

Stop if: any required check is failed/skipped, the identified camera/board is missing or upload is only queued. Record a required-hardware/profile mismatch instead of pretending it passed.

Next: Two signatures and shipping. Full bilingual factory procedure, all sign-off requirements.

1. Confirm a supported Reyeah JD controller and the real vending package com.ruiye.jd. Record OEM Android/ABI, controller firmware, existing signer/version, local configuration and pending/offline transactions.
2. The Kiosk-X Reyeah app and the stock vendor app can share a package name but have different signers. A first conversion needs a supervised migration with recovery material. Do not uninstall the old app just to bypass a signature error.
3. Install the pinned verified cabinet build using the Reyeah manual. Never use its emulator APK, oldcloud build or a pristine vendor-reference APK for Kiosk-X operation.
4. The real controller ID becomes equipmentNo; compare it with the intended cloud record. Verify OEM serial permissions, actual port/profile, backend/MQTT connectivity and catalog. Do not force every serial device to the same settings.
5. Test native auto-start, service PIN, every lane, payment paths and recovery on this cabinet. A ZHZN reyeah_jd driver in source does not certify replacing the Reyeah vendor vending app.

Stop if: there is a signer, ABI, identity, controller or ownership mismatch. Preserve evidence and have the migration owner resolve it.

Next: Optional companion, then shipping. The ZHZN six-test certificate is not a Reyeah vendor-app button.

1. Install the approved ZHZN package, then have authorized provisioning set the exact role=companion and companionMachineNo matching the existing Reyeah cloud machine before the package first starts. Verify the saved role. The default is kiosk; launching an unconfigured install can start the wrong vending agent. Keep com.ruiye.jd, its controller ownership and Home policy intact.
2. Provision companion-credentials.json in the package's private app files directory (filesDir/companion-credentials.json, normally /data/user/0/ai.intelliverse.zhzn.kioskx/files/companion-credentials.json for Android user 0). Use the approved deviceKey and optional witness, or an explicitly authorized Reyeah compatibility credential. Do not put the file on public shared storage or substitute the ZHZN fleet secret. Missing credentials produce no HTTP request; this companion does not enroll or rotate its own device key.
3. Qualify the already-rooted, manufacturer-approved firmware and a successful current root/screen-capture check. Installing the package, granting camera/Accessibility permissions or setting device owner does not supply the root capability this companion uses. Its full-device readiness expires unless a recent successful capture refreshes it; disabled remote-screen features or failed readiness must stop control.
4. With an onsite person and no active transaction, verify a fresh decoded capture of this cabinet, then send one harmless action. Wait for the matching successful input result and the exact fresh after-command capture identified by that result. A random live frame or capture acknowledgment is insufficient. A failed, expired, partial, missing or unknown result stops control; preserve the original command and inspect before any explicit resumption. Never automatically replay it.
5. Recheck the claimed support behavior after reboot, record any required onsite prompt and end access according to policy. The companion must remain headless and must never initialize the vend driver. Do not use a remote support session to start a shopper purchase or physical vend; screen control does not prove delivery or payment settlement.

Stop if: credential, role, readiness or capture evidence is missing. ZHZN kiosk-role native access is scoped to its own activity; it is not a universal Android Settings viewer.

Next: Factory handover. Remote-support capability boundaries.

1. Review actual physical FAT, every-lane results, destination payment profile, accessories and unresolved issues for this serial. Record all required dispositions through the authorized bench workflow.
2. ZHZN: after eligible diagnostics/uploads and actual physical checks, the real technician completes Acceptance sign-off / 验收签核, name, employee ID, attestation and handwritten signature. Wait for SIGNED — acceptance certificate issued and read the saved certificate back. QUEUED/REJECTED is unfinished.
3. Separately finish and read back the full Partner FAT, then have the real authorized signer sign the Partner factory build last. The Android certificate does not create this second signature. The operator factory view cannot be used to invent a missing factory-write button.
4. Reyeah: retain its actual manufacturer build/FAT and required shipping approval using the approved workflow. The vendor app does not expose ZHZN's native certificate screen. Resolve any acceptance-profile mismatch with the manufacturer/platform owner; do not invent a “not applicable” app control, waive required approval locally or claim a ZHZN test was performed.
5. Match plate, software, build, accessories, certificate/approval and shipment. Pack wiring/port map, tray map, exact releases, results, references, support/warranty and destination limitations. Transfer credentials only through the protected handover channel.
6. Cold-start once more, verify controller/cloud recovery, resolve outstanding purchases, secure the cabinet and record shipment. A warehouse receipt is separate from the operator's later acceptance and go-live.

Stop if: a required signature/upload is missing, fitted hardware is untested or serials disagree. No illustration or local checklist can sign these records for a person.

Next: Arrival at the venue. ZHZN sign-off and logistics.

1. Before signing receipt, photograph shipping damage and compare the cabinet serial/model with shipment, build and required manufacturer approvals. Record damage honestly and use the carrier/manufacturer claim process.
2. Position the cabinet according to its manual: stable/level base, required ventilation and service access, clear pickup area, suitable ambient conditions and the manufacturer's settling time for cooling equipment if specified.
3. Have qualified personnel confirm the destination power rating, earthing, socket and installation requirements. Do not improvise adapters, internal wiring or universal power-on delays.
4. Start the cabinet and verify the expected vending app, same machine number, correct time, board and network. Rejoin the venue Wi-Fi using the basic steps; factory Wi-Fi does not travel with the machine.
5. Keep shoppers away until claim, stock, payment, physical acceptance and readiness are complete. Verify keys, service access and support contact with the intended operator.

Stop if: damaged, unstable, unsafe, wrong serial or missing approval. Do not mark damaged goods as good to advance setup.

Next: Install Operator. Operator handover.

1. On the operator's Android phone, choose the approved Flutter Operator or compact native Operator download and verify its package/signature/version. Follow the phone distribution guide. Apple uses approved Apple distribution, not an APK.
2. Install on the phone, open it and sign in to the intended fleet account. Flutter labels the action Log in; native/web use Sign in. Check the account before scanning or changing stock. Complete required MFA in the supported flow; native login offers Open web console for MFA and full fleet setup. After native login, Full console opens the browser for the remaining workflows.
3. Allow camera permission for scanning when requested. If denied, grant it in Android app permissions or use supported manual serial entry. Do not post login codes, API keys or screenshots containing credentials.
4. Flutter provides the field setup flow; web provides full machine, host and delivery-acceptance controls. Native provides login, scan/register, fleet, stock, recent sales and plans, with Full console for missing workflows. There is no common Pair button.
5. If login fails, check internet/clock, credentials and account invitation status; complete the intended authentication method. An offline login error is not proof the password is wrong. Avoid repeated blind attempts.

Ready when: the correct user/account is displayed and the supported machine list loads. A login alone does not enroll or claim a cabinet.

Next: Claim and locate. Feature differences and download identities.

1. Compare the actual software machine number at the cabinet with the handover record. Sign in to the correct operator account. For scanning, use Fleet/Machines → Register and its QR control, or type the serial. Flutter also offers the QR control inside Set up machine; web Field setup accepts a typed/pasted serial. Verify the exact ID before submitting.
2. In Flutter/web use Claim machine. Native scanning uses its registration flow; complete the remaining setup through Full console. Claiming assigns the cloud machine record; the installer must already have provisioned the cabinet's network/authentication.
3. If already owned by another operator, use the approved ownership transfer. If already owned by this operator, continue its existing setup. Do not invent a duplicate ID, claim for a temporary installer account or assume a scanned barcode proves ownership.
4. In the current Flutter Locate step, use Where does it live? → Check machine address. Enter the complete structured address, choose Check address, review the returned components and map point, then Choose this match → Confirm selected address → Done → Continue. Web uses Check address, a candidate selector, Confirm selected address match, then Continue with confirmed address. The optional machine display name is not its address; Finish setup later exits without completing setup. A legacy label or GPS pin does not supply reviewed address evidence.
5. At the actual cabinet, use its address panel to enter the exact machine number and precise placement, and read and select the physical-presence declaration. Flutter calls the action Confirm installation; web calls it Confirm installation as operator. Confirm only after observing this cabinet at the saved address. This operator statement is separate from the geocoder match, manufacturer sign-off and payment/delivery tests.
6. Current address review covers numbered street addresses. Owner-entered unit details and a geocoder match do not verify postal deliverability or physical installation. Correct a missing, wrong or expired candidate and check again; do not invent address parts to clear a gate. Verify the venue time zone separately. Record the actual host revenue agreement in the web workflow, or an explicit supported no-host arrangement with its reason; address confirmation does not establish that agreement.

Ready when: the same cabinet appears in the intended account with fresh presence, the reviewed address saved and read back, and separate on-site installation confirmation for that exact machine. Resolve host requirements before delivery acceptance.

Next: Payments. First-install flow.

1. Identify the payment profile actually fitted/enabled. In the reader setup step use the real Nayax Device Number from its sticker, including leading zeros; do not use the shorter Core Machine ID. Check the saved readback against the physical reader.
2. Binding associates transactions with this cabinet. Separately verify processor activation, merchant ownership, currency, reader configuration/wiring and the intended bank settlement arrangement. An app label saying “settles to” is saved metadata, not proof of a deposit.
3. For an approved QR-only cabinet, use Continue without binding a reader where offered, then verify the live QR route and supported currency. Do not invent a reader to satisfy a form. Simulated/test-mode QR is not production readiness.
4. Test each enabled method with the actual reader/provider/profile. Check price, currency/decimal places, authorization, exactly one delivery, matching order and stock change. Keep provider references and verify real settlement separately.
5. The current Spark route is USD-only; Stripe QR has currency and single-product/single-unit limits, and native MDB card is single-product/single-unit. Read the precise current constraints before offering other markets or carts.

Stop if: reader belongs to a previous merchant, price/currency disagrees, the enabled path is unsupported or an outcome is unclear. Signing into MoMa does not connect transaction reporting or move revenue into Operator.

Next: Load stock. Payment and market limits, Nayax reconciliation.

1. Match each physical coil/lane to the saved planogram. Load the intended product with the mechanism safely stopped. Respect its capacity, size, storage and age rules; inspect expiry and packaging.
2. Save the correct product, price, currency, age tier, availability and maximum quantity through the supported editor. Flutter offers Edit product & price; image/category changes use the authorized web/API editor. A numeric price edit does not change currency.
3. Enter the actual count. Fill/Fill to max means the lane was physically filled to its saved maximum; use a partial count for a partial fill. Stock buttons record quantities; they do not put products in the machine.
4. In First fill, review the selected aisles before Confirm … aisles filled. Wait for saves, refresh and compare cloud counts/prices with cabinet display and checkout amount. Do not repeat an uncertain save before checking its outcome.
5. Keep unavailable/faulty lanes disabled until repaired and retested. On Reyeah never leave a public sale lane at zero price: the OEM zero-total path can dispense without payment. Use the approved supervised service procedure for testing.

Ready when: actual products, lane mapping, counts, prices and cabinet readback agree. Product images and optional promotional settings must not misrepresent what will dispense.

Next: Acceptance and opening. Stock and operating details.

1. Review claimed ownership, the confirmed address and separate on-site installation record, fresh online state, controller/dispense readiness, stock/planogram and an enabled real payment path. Verify any required active device plan for this exact serial in Plans or web subscriptions; registration alone does not establish it. Setup saved — not live yet means remaining work; do not force incomplete checks green.
2. In the approved supervised acceptance mode, perform one purchase per enabled payment method. Confirm exact product/quantity, amount/currency, original order, provider result and exactly one stock decrement. Keep the public machine unavailable during setup.
3. In a controlled bench/service setting, exercise failure/refund or reconciliation, network interruption, restart and late/duplicate result handling. Do not create an unsafe jam or place a second paid order to investigate the first.
4. In web machine detail, review Build & factory QA → Accept this machine and required host arrangement. Record truthful receipt/physical checks. The UI states that operator acceptance cannot be withdrawn; complete the physical checks first. The Flutter factory card reads the manufacturer's certificate and is not that acceptance control. Native uses Full console.
5. Complete Go live when the required readiness gates and site evidence are satisfied. Verify the saved live state and shopper screen, lock the service door, close privileged access and display a readable support contact.

Stop if: any paid-undelivered order, damage, missing required factory approval, wrong ownership/host or readiness blocker remains. Factory signature, warehouse receipt, operator acceptance and go-live are separate milestones.

Next: Shopper flow, then daily care. Acceptance procedure.

1. Choose the product and review quantity, price and currency. Remove unwanted cart items before paying; complete any required age check. Operator login and service PIN are not shopper requirements.
2. QR: scan the purchase QR for this order using a phone, check the destination/amount, complete the permitted payment and retain the order reference. A support, reward or power-bank QR is a different flow.
3. Card: wait for the fitted reader's prompt and verify amount/currency before tapping. Do not also pay the QR for the same order. Single-unit routes must reject unsupported carts before charging.
4. Wait for the result; collect the actual item(s) from the pickup compartment. Paid, authorized and motor-acknowledged are not interchangeable with delivered. A partial delivery requires review of the missing items on the original order.
5. Use the offered cancellation controls before starting payment. On the current ZHZN card flow, Cancel is hidden once the reader is armed; wait for the original reader session to resolve. If a tap/payment may already have happened, retain the original reference and follow recovery; do not assume cancellation, a timeout or a screen change erased a late authorization.

Stop if: amount is wrong or payment/delivery is uncertain. Do not pay twice, shake the cabinet or reach into the mechanism.

Next: Payment problems. Full shopper edge cases, Reyeah sale checks.

1. Keep the original order/reference, machine number, time, amount/currency and observed product outcome. Contact the support information on the cabinet. Never request a shopper's password, full card number or login code.
2. The operator compares the original order, payment-provider evidence, delivery result and stock. Check uncertain/partial/late outcomes before retrying a vend, refund or payment. Do not treat a local status label as processor evidence.
3. For supported Stripe Scan & Pay refunds, use the authorized refund workflow and confirm the provider result. If it fails, keep the liability unresolved with its error/reference. “Refund initiated” is not “money received”.
4. The inspected backend has no outbound Nayax/cash refund path. Use the authorized provider/cash-return procedure, then record the actual external reference through tooling that supports it. The Flutter phone's basic refund action does not record external refund references.
5. Inspect queue limits: the Flutter refund view is recent 500; web warns at 10,000. Use appropriately scoped reconciliation before asserting all liabilities are cleared. Do not sum different currencies or equate sales totals with deposits.

Cash review: use the current Operator app from Downloads. A partial or disputed cash receipt shows Cash receipt needs review, the original reported cash and an unknown refund amount. Keep every original lane order and count the actual stock before resolving the case with authorized support. The whole-order Refund action cannot close it. A late receipt after a stock recount must not add stock again. Follow the cash reconciliation steps.

Ready when: the original case has evidence of the actual delivery/refund/void result, or a named owner and documented next action. Preserve uncertain cases across logout/restart.

Next: Reyeah outage recovery, or ZHZN held offline stock after resolving the original payment. Shopper support, payment reconciliation.

1. Preserve the existing app, identity/configuration and offline-order journal. Do not clear storage or reinstall as an outage shortcut. QR payment needs connectivity; offline card operation depends on the actual VMC/reader/profile and acceptance evidence.
2. Use the authorized Reyeah top-right long-press service hotspot and assigned PIN only when needed by service. Inspect configuration, VMC logs and offline orders. That PIN is separate from Operator login.
3. Restore the approved network, clock, backend/MQTT and board connection. Watch queued reports reconcile against their original orders. A drained report must not cause a second vend.
4. Reyeah remote commands arrive through MQTT; the vendor APK does not poll generic Partner /commands/pending as a fallback. Accepted/queued means delivery is still unproven. Do not issue repeated test commands when the first result is unknown.
5. Observe one supervised known-lane test only through supported service tooling with no shopper present. The current Flutter phone build has no test-vend button. Verify the physical outcome and final command reference before any retry.

Stop if: pending orders/commands have unknown physical outcomes or reconnection repeats sales. Keep the machine out of public service and reconcile with its operator.

ZHZN offline recovery is a separate path: offline card requires explicit eligibility, fresh approved inventory and a ready reader; QR still needs connectivity. Follow section 27 to resolve the original payment/reports before physical stock reconciliation and the PIN-gated refresh. Do not apply this Reyeah journal procedure to the ZHZN APK.

Next: Daily service. Reyeah boot/outage manual.

1. Before opening, inspect power/display/touch, cleanliness, pickup area, visible damage, stock/expiry, cooling when fitted, support contact and service-door lock. Review fresh connectivity, faults and unresolved orders.
2. Prioritize paid-undelivered and uncertain payments, then unsafe/mechanical faults, then stock and cosmetic work. Disable the affected lane or take the machine out of public service through the supported workflow.
3. Use the assigned service credential and qualified repair procedure. A cloud clear fault action cannot repair hardware. Avoid service commands while a purchase, motor action, update or unresolved prior command is active.
4. After repair, run a supervised single-lane test, inspect the actual product, clear only the resolved fault, reconcile stock and verify the shopper view before enabling sales again.
5. Record technician, time, parts, observed result and evidence. Close remote/service access and lock the cabinet. On departure, verify auto-start, cloud presence and the support contact.

Stop if: a fault returns, the command outcome is unknown or stock cannot be reconciled. Do not spam commands or reset identity to remove an alert.

Next: Fleet operation. Machine care.

1. Keep one accountable record per physical cabinet: owner, venue/time zone, hardware, installed releases, payment profile, acceptance evidence, support contact and unresolved issues.
2. Invite crew with the appropriate role and verify the invitation was accepted and access really works before dispatch. Use web/full console for functions absent from the selected phone app. Never share the owner password as staff access.
3. Review daily queues by severity and assign an owner. Confirm list freshness, filters, pagination and limits before describing the entire fleet. Missing/stale data is not zero inventory or zero liability.
4. Reconcile orders, provider transactions, delivery and stock per machine and currency. Separate merchant settlement, host payouts, advertising estimates and refund obligations. Investigate duplicated, missing, pending and externally refunded transactions.
5. Before an ownership/location/reader transfer, resolve open obligations and follow the supported transfer workflow. Preserve the same physical machine identity and historical evidence; verify the new account and merchant before reopening.

Ready when: every exception has a responsible person and the fleet view agrees with the actual scoped records. Global release is qualified by specific country, currency, hardware and processor combinations.

Next: Update and recovery. Fleet release matrix.

1. Record current and target package/version code/hash/signer, supported Android/ABI/controller and configuration recovery plan. Cabinet, companion, native phone and Flutter phone packages each have their own update history.
2. Finish purchases and unknown outcomes before the service window. Stage a small staffed group. Use the correct same-signer higher-version build; a completed download or OTA offer does not prove Android installed it.
3. Verify according to the updated package's role. Vending APK: read the installed version, cold-start and check the same identity, Home/management, permissions, board/cloud and pending reports, then a supervised purchase with stock/provider reconciliation. Companion: verify its retained headless role, machine binding, private authentication and fresh capture/input readiness while Reyeah remains the vending Home app. Operator phone: verify its installed version, login, correct fleet and supported workflow; updating the phone does not demonstrate a cabinet update or physical vend.
4. For failure, pause expansion and keep affected machines out of public service. Preserve diagnostics/orders. Follow the approved recovery or higher-version fix-forward path; do not uninstall/wipe or force a downgrade casually.
5. Check adoption and physical return-to-service evidence before expanding. Record any prompt needing onsite help after reboot, including remote-support consent. Phone app updates do not update cabinet APKs automatically.

Stop if: signer/ABI mismatch, downgrade refusal, changed identity, missing reports or new payment/vend/startup faults. A successful CI build is not release qualification on every cabinet.

Next: Remote support. Release sequence and recovery.

1. Agree a service window, verify the intended cabinet and assign an onsite fallback. Finish purchases and resolve uncertain commands before support interaction.
2. Choose the supported access method for this exact ROM/build. AnyDesk or another approved tool may need OEM add-ons, Accessibility, screen-capture consent and battery/startup policy. Do not assume a generic Android instruction provides unattended control.
3. Grant only the approved access needed for the session. Verify viewing and input separately, using a fresh capture and the expected after-action state. An acknowledged request or old screenshot alone is insufficient.
4. For ZHZN kiosk-role native support, scope is its own activity; Android Settings/full-device capture is a separate capability. For Reyeah companion, follow the provisioned role and its actual root/readiness requirements.
5. Test the claimed behavior after reboot with onsite supervision. Record remaining consent prompts and limitations, then close the session and protect/revoke credentials as required.

Stop if: identity, readiness, privacy or screen freshness is uncertain. Do not label a cabinet remotely recoverable until the required path has actually worked.

Next: Optional features. Detailed Android support guide.

1. Age-gated products: enable only the qualified flow. Verify pass, refusal, cancel, timeout and session reset before payment; a previous shopper's result must not unlock the next shopper. Handle identity information only through the approved provider workflow.
2. Rewards, quests and games: verify eligibility, expiry, one-time redemption, cancellation and exactly one product/stock change. Do not make a public zero-price Reyeah lane as a reward shortcut.
3. Photo printing: explicitly record fitted/absent status. Test the actual supported capture/consent/payment/print and failure/support flow before advertising printing; a configured option does not prove a printer is attached.
4. Power-bank rental: identify the supported separate cabinet/gateway and its real door QR. Test accessory binding, hold/charge, exactly one release, return detection, rental closure and failed release/refund handling. Do not connect an unknown charging cabinet to a snack VMC protocol.
5. Ads/content: verify licensed content, readable shopper/support information, return from the attract loop and that no stale cart, payment or personal session persists for the next shopper.

Ready when: each enabled option has its own real acceptance evidence; absent/disabled options are recorded truthfully. Disable an unqualified experience instead of advertising it as ready.

Next: if ZHZN offline stock remains held, reconcile it; otherwise complete the cabinet checklist. Shopper optional flows, power-bank visual manual, factory accessory requirements.

Use this procedure for the ZHZN vending APK when offline products remain unavailable after a failed or unresolved attempt. Offline card approval reserves one unit before the motor command; the hold survives restart. Online and remote motor attempts also close the offline catalog until their reports and a fresh inventory download reconcile it. This is separate from the Reyeah journal workflow.

1. Put this cabinet in an attended service window and keep shoppers away. Resolve the original payment, inspect the pickup compartment and affected lanes, and retain the original order/provider evidence. Do not make a new payment or motor command to discover whether the first one worked. Restarting the reader/app does not prove cancellation.
2. Restore connectivity and wait for queued sales/dispense reports to be acknowledged. Check their original references in Operator. If a reader session is still active or its payment outcome is unknown, reconcile it with the payment provider before any controlled restart. Do not clear app storage, uninstall or bypass a session gate.
3. After the reports finish, physically count or refill the affected lanes and save the matching stock for this exact machine in Operator. Confirm the saved readback. Correcting counts before delayed reports finish can let a late report undo the physical reconciliation.
4. Enter the authorized cabinet PIN, choose Reconcile offline stock / 校准离线库存, read the explanation, then choose Stock counted and saved / 已核对保存 only after step 3. These are cabinet service controls; an operator phone stock button does not perform this step.
5. The action refuses while a card session is active/unresolved, the board is dispensing or reports remain queued. Resolve the stated condition, then repeat the count/save check before retrying. Do not start another sale, repeatedly press the action or reset identity to remove the refusal.
6. Verify the freshly downloaded lane counts, prices, currency and availability before returning to shoppers. A failed download leaves offline selling closed until fresh inventory arrives; a storage failure requires service. Fix an incorrect Android clock and use the full manual for cache-expiry restrictions.

Important: an accepted successful motor report followed by a fresh inventory download can reconcile cached stock even when drop detection was not_detected or unknown. It does not prove the shopper received the product or that a refund completed. Investigate the original missing-product/payment case separately; do not automatically retry the vend.

Stop if: payment/session outcome, report acknowledgement, physical count or fresh inventory is still uncertain. Keep the cabinet out of public service until the required conditions are resolved.

Next: complete the cabinet checklist and daily service checks. Full PIN-gated recovery and cache rules, shopper offline limits.