archy/Release & Testing/Detailed Plans/01-Completion-Execution-Plan.md

Sanitized detailed source transcription S01, captured 2026-10-24. Original planning steps, acceptance criteria and historical evidence are retained rather than condensed. Read current context and precedence first: dated holds, approvals, test counts and “latest” labels below belong to their original checkpoint and do not grant current execution/publication authority. Privacy replacements preserve roles and test semantics. See section coverage.

Archipelago 1.9.2 completion: execution and UAT plan

Current execution authority — approved UX, begin gated development

The operator approved the design subject to original black modal containers and instructed completion of executor's plan and execution. The earlier UX hold is superseded. 02-Execution-Entry.md is the current authority/task entry point; 03-Tasks-T00-T29.md, 04-Qualification-Test-Contract.md, 05-Guarded-Installed-UAT.md and ledger.json are now present. Start T00 provenance and baseline before implementing dependency-ready tasks.

The executable pack maps the original 43 requirements plus A10 bounded chunked ecash, A11 complete social/zaps, A12 Networking Profits, A13 public-guest isolation, and C10 Mesh text/sender/audio UX: 48 requirements, 30 tasks. Preserve the original shell/info modal/player/zap picker and black containers. Public guest access must be separate from all owner wallet/signer/session/private-data authority; read the mandatory 09-Public-Guest-Security.md gate. No absolute exploit-proof claim is possible.

Scoped qualified operator node candidate delivery remains authorized through its guarded procedure; no blanket new funds, public events/exposure/releases, other-node/hardware or destructive authority. Historical no-implementation/Phase-0-only/hold statements below describe the earlier planning phase and are superseded by this entry point. Production gates still start NOT_RUN.

Purpose and authority

This replaces the narrow release-resume approach for planning purposes. It does not erase prior evidence, unfinished requirements, operator acceptances, or safety constraints. It is a planning deliverable, not authorization to deploy, spend funds, publish films, flash hardware, or publish releases.

Requested outcome: complete the unfinished work carried through 1.9.1, especially a production-path IndeeHub using native node wallets for Lightning, ecash and on-chain payments, FIPS-only inter-node film delivery, cross-instance published films and comments, and coherent Backstage UX. Then qualify the integrated artifacts and hand them to the operator for UAT.

Quality rule: zero known blocking defects, zero missing mandatory acceptance evidence, and no silent omission of scope. Network/hardware/provider failures cannot be eliminated; the product must handle them without unauthorized access, data loss, duplicate payment, invented success, or a non-FIPS media fallback. An unavailable required test is BLOCKED, not PASS.

1. What was established in this planning inspection

No builds, tests, live-node operations, payments, or deployments were performed. Findings below are source/history findings or clearly identified historical evidence.

• The inspected release checkout is [private candidate checkout], local HEAD fcc18b392. The local v1.9.1-alpha tag resolves to 7f0318c68. Live canonical remote state and publication state still need verification.
• Its 1.9.2 changelog currently describes companion 0.5.37/build 57 packaging, an ISO/APK version gate, and unchanged 1.9.1 limitations. That is NOT the completion scope requested here.
• 1.9.1 explicitly lists unaccepted Lightning rentals (BTCPay unconfigured), unverified metered ecash playback and an authenticated operator-node check, retained regressions, and historical mirror drift.
• [private candidate checkout] is a different checkout with a dirty worktree and local UAT artifacts. Do not overwrite it or treat its contents as reviewed release source. Several of its disk UI changes have corresponding commits in release history; reconcile rather than blindly cherry-pick them again.
• IndeeHub work is spread across multiple checkouts. The inspected [private candidate checkout] is at 5f62657; other candidates contain publication, rental-readiness, and worker-drain work. Neither this checkout nor any other is automatically the accepted source. Establish provenance before integration.
• In that IndeeHub candidate, backend/src/rents/rents.service.ts still injects BTCPay and issues/reconciles its invoices. The legacy rental modal also contains BTCPay assumptions. The native/distributed route must be traced separately; finding native primitives does not prove every purchase entry point uses them.
• Core already contains purchase journals, Lightning/on-chain modules, seller records, media registration, and FIPS media primitives. They are reuse candidates, not fresh end-to-end acceptance. In particular, the inspected media-registration method validation does not include on-chain and one registration response narrows capabilities to Cashu. Trace and qualify the full capability path.
• src/composables/useNostr.ts constructs comment identifiers as {VITE_CONTENT_ORIGIN or window.location.origin}/content/{id}. src/lib/relay.ts defaults to the instance's own /relay; src/lib/nostr.ts describes its event store as in-memory. These are risks for split discussions and lost local-only history, not a newly reproduced live incident.
• Historical evidence records free FIPS playback, selected native identity repairs, and explicit expired-rental renewal source/deployment work. The ledger expressly does not establish full paid playback or actual renewed payment acceptance.
• The retained backlog has 23 numbered work groups plus later terminal/developer, external publishing, business/mining and release work. Historical operator-accepted flows must remain accepted as historical evidence; they still need relevant regression checks on the final changed artifacts.

Source map for the executor

Read the appropriate repository AGENTS.md first. Principal scope/evidence sources:

• docs/post-1.8.22-regressions-20261001.md (mandatory retained regression coverage).
• docs/post-1.9.0-work-backlog.md (23 groups and sequencing refinements).
• docs/post-1.9.0-progress-20261006.md, docs/release-1.9.0-acceptance.md, and CHANGELOG.md (historical records; use latest evidence per item, not the first stale status).
• docs/release-uat-checklist-20261007.md.
• docs/indeehub-integration-map.md, docs/indeehub-distribution-current-design.md, docs/indeehub-fips-protocol-review.md and registration/private-delivery/update documents.
• docs/paid-content-recovery-followup.md, docs/paid-file-recovery-qualification-20261007.md, docs/paid-process-recovery-20261008.md.
• Fleet, peering, HTTPS app-gate, firewall/tunnel, container-store ownership, and managed-update recovery documents.
• docs/terminal-developer-environment-spec.md, docs/archipelago-agent-design-system-spec.md, docs/app-media-integration.md, and app/developer guides.
• Relevant IndeeHub candidate source and its docs/archipelago-* contracts; compare against accepted history before selecting changes.

The ignored release resume is not a dependency of this plan. Do not use any resume's broad “completed UAT” statement to close individual requirements.

2. Non-negotiable product contract

Native payments

IndeeHub is a client of the same scoped node payment platform used by Cloud Files, not a second wallet and not an unrestricted wallet RPC client. The owner approves spending through the native wallet UI. Producer destinations are verified and bound to the published offer; app login is not spending consent.

The required methods are:

1. Lightning: native wallet payment and correlated seller settlement. Include first-use Lightning-to-ecash receiving where supported, without forcing every producer to run LND. Verify issuance/recovery separately from invoice settlement.
2. Ecash: actual supported node wallet backends and negotiated mints/federations. Preserve proofs, change and pending recovery; unsupported/wrong mint is explicit. Cashu and Fedimint are not interchangeable protocols. Retain existing supported Fedimint behavior rather than promising an unimplemented adapter.
3. On-chain: native node wallet transaction, explicit fee review, unique bound payment intent/address, amount/network checks, confirmation policy, fee-bump linkage and reorg handling. Reject below-policy/dust amounts before payment. Do not substitute an arbitrary tiny test payment for a valid on-chain test.

The complete node-native installation must boot and support all required user journeys without BTCPay installed, reachable, or configured. Audit rentals, renewal, seasons/episodes, subscriptions, discounts/free grants, tips/zaps, revenue and payout screens. Migrate in-scope monetization paths to native services; no enabled purchase button may quietly require BTCPay. If a feature genuinely belongs outside this release, require an explicit operator scope decision rather than hiding a broken button and calling the app complete.

Preserve legacy paid receipts and active entitlements. Do not erase history or re-charge users during migration. Any necessary legacy-provider reconciliation is explicit and isolated; it is not a prerequisite for new node-native purchases. Revenue calculations must not confuse sats, BTC, msats or fiat display units, or credit a settlement twice. Do not invent payout destinations or revenue splits.

Persist one logical purchase before any external side effect. Bind app/install, buyer, producer, film identity and media revision, price/unit, rental terms, method/network and idempotency key. Distinguish awaiting approval, payment pending, outcome unknown, settled, delivery pending, playable and expired. Model rejected/refund/recovery states explicitly. A timeout or lost response is NEVER permission to submit another payment or switch payment methods until the original outcome is resolved.

FIPS-only film delivery

Every inter-node request carrying film/trailer bytes, HLS manifests/segments or content keys must use authenticated, authorized FIPS. Enforce this centrally in the media resolver/gateway, not only in UI URL selection. Browser/companion-to-own-node authenticated HTTP(S) is the presentation interface; local storage reads are local, not a claim of a remote FIPS hop. Lightning and Bitcoin settlement retain their own network protocols.

No hidden fallback to direct producer HTTP/LAN, Tor, iroh, public MinIO, object-store URLs or external CDN film playback. Redirects, variant playlists, subtitles and cached playback must obey the selected transport/access policy. Existing external catalog sources must not bypass strict playback: either qualify FIPS delivery or identify them as unsupported in this mode. Make Archipelago the default content source only once its acceptance gate passes; no fallback to mock titles or Top Docs to disguise failure.

When FIPS is unavailable, stop remote delivery, preserve the purchase, display a recoverable error and resume without repayment after recovery. Check every protected range/segment/key/cache request. Protect original masters as well as transcoded renditions. Cached content must not become an unrestricted download that defeats rental expiry.

Published films and comments on all instances

“All backstage films” means films the creator explicitly publishes. Drafts, private assets and unapproved historical uploads are NOT automatically public. A migration must show existing public/published projects needing distribution and require an explicit authorized backfill; publish no unrelated personal files.

Any compatible node with IndeeHub, including a new node with no prior peer/federation relationship, can discover public film metadata and its public discussion. Public discovery grants no management access and does not unlock paid film bytes. Document the minimum compatible app/backend versions; do not imply immutable older clients gain new behavior automatically.

Use a stable producer-authorized film identity independent of viewer origin, local API row ID and cache node. Keep media revisions separate from film discussion identity. Review pinned current Nostr specifications before finalizing metadata/comment tags; NIP-71/NIP-94 and NIP-22 are candidates, not a claim that our rental contract is standardized.

Persist publication/comment delivery intent and acknowledgement, verify signatures and identity binding, deduplicate events, reconcile revisions/withdrawals, backfill for late joiners, and recover relay/node outages. Local event insertion is not distributed publication success. Bridge known old discussion identifiers without mixing unrelated films or silently discarding existing comments. Bound pagination, thread depth, event sizes and subscriptions; prevent recursive/cyclic thread failures, XSS and stale account signing.

Specify public comment visibility, reporting/muting/moderation and deletion semantics. Local moderation may alter a node's view; no promise that a decentralized deletion erases every external copy. Offline/partitioned nodes catch up after reconnection, not instantaneously.

A catalog is not an availability service. To tolerate publisher outage, implement or qualify owner-authorized FIPS replica/cache serving, integrity checks and entitlement validation at every serving peer. Replicate only approved content under explicit storage/quota/retention policy. No automatic publication or unapproved hosting charges. If every authorized source is unavailable, show unavailable rather than promising impossible uptime.

Backstage

Use a clear sequence: native identity -> project details -> Assets -> processing/readiness -> pricing/receiving wallet -> dedicated Publishing tab -> published status/distribution/revisions.

Computer upload and authorized Cloud selection are distinct. Retain asset/editor state across tabs and navigation, truthful byte/upload/transcode progress, cancellation/retry, save feedback and safe draft recovery. Publishing is disabled with a useful reason until the selected file, serving node, payment capabilities, price/terms and renditions are ready. Saving a draft must not publish it.

Use the selected native Nostr identity consistently in signer, API profile, project ownership and publication. No generated/imported app-local keys or stale-account fallback. Test explicit sign-out, reload, cancellation and cached-account A -> selected-account B. Isolate or clear stale signer state on logout without deleting native identities.

Viewing terms must agree across Backstage, checkout, My Library, backend and player. Proposed default: window starts at first successfully authorized playback, atomically and once; preview/preflight must not consume it. Renewal is a new explicitly approved purchase only after the prior rental is confirmed expired. Metered playback, if retained as an offered mode, needs separate rate, cap, stop and recovery acceptance; it is not equivalent to a timed rental.

3. Full recovered completion inventory

Each item below requires a ledger row. “Retain/retest” means implementation or historical acceptance exists, not that new work must be invented. Phase 0 resolves the exact latest status.

IndeeHub (A)

• A01 Native identity/authentication: selection, auto-login after selection, matching profile, sign-out, stale account transition, permissions and iframe/companion lifecycle. Backlog 2.
• A02 Backstage UX and assets: computer and Cloud upload, save/reopen, tabs, registration, ownership, processing/retry, publishing readiness and useful errors. Backlogs 1/2.
• A03 Distributed film catalog: stable signed identity, all explicitly published films, late unrelated-node discovery, updates/withdrawals, complete pagination, no demo fallback. Backlog 1.
• A04 Global film discussion: comments, replies, reactions/counts, stable identity across nodes, durable distribution/backfill, old-identifier compatibility, moderation and abuse limits. Explicit new requirement.
• A05 Shared native checkout and settlement: all three requested rails, real receiver capabilities, no BTCPay dependency, native approval and idempotency. Backlog 1 plus new on-chain/no-BTCPay requirement.
• A06 Entitlements and recovery: first-play timing, expiry, resume/seek, permitted device/session behavior, lost replies/restart, explicit renewal and metered mode qualification. Backlog 1 and 1.9.1 limitations.
• A07 FIPS-only streaming: all remote media paths, encrypted HLS/keys, originals/previews, ranges, cache, no route, integrity/backpressure/cancellation, decoder/mobile behavior. Backlog 14.
• A08 Availability and capacity: authorized replicas, producer/relay loss, long-film/concurrent-viewer load, storage limits and honest availability. No unbounded swarm rewrite is implied.
• A09 Durable app delivery: pinned frontend/API/worker and dependencies, nonempty/monetary-state migrations, worker drain, readiness, seven-service cutover and rollback, no running-container patches as final artifacts.

Cloud, payments and media (B)

• B01 Paid Cloud Files: Lightning/ecash/on-chain settlement, exact delivered bytes, durable ownership, optional Files copy, free repeat, method fallback safety and process-restart/lost-response recovery. Retain closure of the original individual missing-file recovery; do not repay it.
• B02 Wallet fee experience: dynamic Fast defaults for sends/opens/cooperative closes, slower/custom preservation, stale estimates, Bump quote shortfall UX, budgets, supported RBF/CPFP, duplicate submission, history grouping, confirmation/reorg and unknown-not-zero balances.
• B03 Cloud connectors: independently configured Nextcloud and Immich, user/account isolation, browse/preview/download, pagination/revocation, correct categories and no direct mutation of app storage. Must work with File Browser absent/stopped. Backlog 5.
• B04 File Browser and uploads: unique node credentials, preserved custom users/data, removal warning on all routes, no forced reinstall, resumable/cancellable exact-byte uploads, original destination, 44px original-screen-only progress and off-screen completion notice. Physical accepted flows retained; remaining restart/lifecycle boundaries explicit.
• B05 Cloud viewer/downloads: permanent file menus, safe areas, fullscreen, aspect ratio, authenticated save/open/cancel, no HTML-error downloads, source permissions. Retain accepted phone flows; retest changed artifacts.
• B06 Public files/folders: explicit Make public, existing pricing UI with blue treatment, tiny accessible marker, child/override rules, unrelated-node discovery, withdrawal and paid access. Backlog 21.
• B07 Mesh file sharing: node/computer picker, own-library search/tree, retained multi-select, staging, private recipient binding, free/paid message items, progress/retry, no implicit public sharing. Backlog 22.
• B08 Private V4V demo: original catalog/attribution/payment destinations, native sign-in, approved node-only availability and promotion, private image recovery, no accidental public distribution. Backlog 13.
• B09 Reusable audio/video platform: single playback session, bottom player, reopen same queue/position, physical background/lock-screen/headset controls, logout/expiry, Cloud PiP and reusable developer contract. Backlogs 19/20.
• B10 Companion notification artwork: actual-track authenticated thumbnail/native notification diagnosis and physical proof. Backlog 23, keep last in feature work as requested.

Connectivity, performance and UX (C)

• C01 Peering and requests: reciprocal approval/removal, persistent/replay-safe requests, Connect with Nodes naming, actionable notifications and no routine manual refresh. Backlogs 3/6.
• C02 Fleet and federated sync: full action matrix, real authenticated metrics, deduplication, mixed versions, bounded parallel sync, progress/partial failures and reconnect. Backlogs 8/12 and sync addition.
• C03 Availability/map and final connection UX: last-seen versus known offline duration, stable sorting, map stale links, peer/trusted counts, distinct relationships, bottom actions, map request focus and mobile accessibility. Backlog 10 and deferred final UX expansion.
• C04 Latency and companion reliability: cold/warm launch, signer/HTTPS gate, grey screens, Web5/Cloud navigation, all tabs, immediate feedback plus measured useful-data latency, cancellation and background/resume. Backlogs 2/7/11.
• C05 Monitoring and visual regressions: affected-node authenticated Monitoring, recovered alerts, live free/total disk/TB, stale-versus-zero, footer alignment, transaction filters and search controls. Backlogs 4/16 and 1.9.1 UI changes.
• C06 HTTPS app authentication: iframe versus tab, trusted hostname, cookie/gate/bootstrap, expired sessions/logout, public denial, physical companion. Backlog 17.
• C07 AIUI setup/funding: saved/missing/invalid credentials, supported provider auth, Routstr unfunded/outage, private credential entry, fund/scan/balance refresh, unsent prompt and no unexpected charges. Preserve standalone/embedded backgrounds. Backlog 9.
• C08 MeshCore: standard community public channel, official firmware/tooling and board detection, valid RF plan/readback, serial ownership, listener/502/reconnect, real bidirectional and standard-client interoperability. Backlog 15 and retained flasher gates; physical access/authorization required.
• C09 Firewall/tunnels: truthful effective state, saved/manual configuration recognition, existing design/layout, actual scoped apply, raw TCP versus browser routes, independent stage diagnostics, persistence/reboot/rollback. Backlog 18; preserve working manual repairs.

System, applications and developer work (D)

• D01 Lifecycle/update safety: installed/stopped/restarting/removed/legacy app matrix, aliases/internal components, inventory refresh, uninstall tombstones, app author/launch readiness, native graceful shutdown and wallet/data preservation.
• D02 Container storage and recovery: ownership-safe cleanup, correct user/system storage, never prune live unrelated state, interrupted update/admission/recovery, all restored versus committed outcomes reported accurately.
• D03 NPM/public security: active storage layout, hosts/accounts/certs/ACME renewals, aliases, ACL/WebSocket/client-IP preservation, emergency-route retirement, public management denial including IPv6, restart/reboot/upgrade/rollback.
• D04 Gitea/Portainer/GitWorkshop: same-server actual request namespace, fresh install both orders, Git/SSH/LFS/registry/compose, saved state, build contexts/progress and restart persistence.
• D05 Bitcoin/Lightning/ecash application regressions: Mempool image/catalog/update card consistency and explorer fallback, IBD/startup/readiness, Phoenixd headless behavior, Minibits/address/backup UX, no orphan app resurrection. Preserve prior accepted startup incident closure.
• D06 Angor: public Mempool UI/API/TLS/WebSockets, current client project flow, full-chain prerequisites and historical signed-announcement recovery. The historical missing-announcement limitation was operator accepted; keep it explicit and separate from runtime defects. Do not fabricate replacement signatures to claim recovery.
• D07 Websites/external access: reviewed static archives/nsites/Blossom, native Cloud website flow, scoped app guest access, FIPS/Tor publication as appropriate to websites, TLS/authentication and rollback. The film-only no-fallback rule must not accidentally remove legitimate website transports.
• D08 Business/mining apps: JustWorks native business identity/setup, secure matching-key import, LNURL endpoint safety; Gashboard/DATUM actual service and external miner flow, persistence/reboot and admin exposure boundaries. Regression-test accepted changes and locate outstanding UAT, not assume a merged PR passed.
• D09 Terminal/developer environment: real PTY, shell/editor/Codex keys, scrollback, close/reopen/reconnect, process/session ownership and logout, setup retry/offline/upgrade, actual bundled tools/skills, origin restrictions and workspace preservation. Audit developer privilege exposure; do not claim a dedicated isolated developer account if the shipped terminal is an owner shell.
• D10 Shared design and app-development contract: maintained tokens/components/starter, agent-built real app, mobile/error/accessibility behavior, accurate local docs and packaging. Keep broader optional Omarchy/desktop/toolchain parity explicitly listed as follow-on unless the operator brings it into this release; core developer outcomes remain required.
• D11 Hardware/discovery UI: private-phone setup/GrapheneOS listings, router/LoRa product views, real NIP-99 sources, no production mock listings, responsive layout and safe external links. No claim of physical-device support from 3D artwork.

Release (E)

• E01 Provenance and review: reviewed exact commits for all components, dirty-tree reconciliation, ngit proposal dispositions, exact accepted mirror history, inventory historical drift without rewriting it.
• E02 Reproducible artifact set: backend/dashboard/AIUI, IndeeHub images, signed scoped catalogs, helper/runtime assets, companion APK and OTA/raw installer ISO; versions/hashes/tool payloads match source. App-only updates remain decoupled when possible.
• E03 Installed-artifact acceptance: fresh x86 installation, actual 1.9.1 upgrade, reboot, app update and rollback, APK in-place upgrade, every important feature from the installed packages rather than copied source assets.
• E04 UAT and sign-off: full traceability, operator scenarios, all required hardware, real compatible nodes, exact artifacts, zero blockers, accurate release notes and controlled publication only after explicit approval.

4. Execution phases and dependency order

Phase 0 — Reconcile scope, provenance and baseline (no live changes)

Create a machine-readable acceptance ledger. Required fields: ID, requirement/source, implementation commit, status, source tests, disposable integration, packaged tests, actual-node evidence, physical/operator evidence, evidence path, owner, blocker and next action. Use OPEN / IMPLEMENTED / SOURCE-PASS / INTEGRATION-PASS / ARTIFACT-PASS / UAT-PASS / BLOCKED; keep historical evidence separately.

Check exact canonical/main/tag refs and component provenance. Inventory dirty changes and candidate branches without resetting/deleting anything. Map every retained checklist item to A–E, including already accepted items and later additions. Record duplicate/superseded requirements and why (for example, upload bar stays on its origin screen). Unknown status stays unknown.

Choose clean pinned worktrees; review baseline before giving CI any source. Establish current test commands and failing baseline using repository scripts. Inspect existing CI, unit and browser suites before creating duplicates. Record version/capability compatibility. Verify whether 1.9.2 has actually been published; never replace an immutable release—use the next version if needed.

Exit: complete reconciled ledger, clean reviewed starting revisions, reproducible baseline, and decisions below resolved or visibly blocked.

Phase 1 — Freeze high-risk contracts and test fixtures

One strong reviewer owns payment/entitlement state machines, native app permissions, stable film/comment identity, strict FIPS gateway, publication replication and migration/rollback contracts. Pin relevant primary protocol revisions at implementation time.

Write failing integration tests before implementation for: no BTCPay installation, all three payment rails, unrelated-node discovery/comments, lost settlement response, FIPS hard outage with non-FIPS alternatives available, expired cache/key access, stale native identity, and update with monetary history. Define test identities, approved synthetic media and network/resource budgets.

Exit: reviewed contracts, agreed user-visible wireframes and executable failures that represent the requested outcome.

Phase 2 — Complete IndeeHub critical path

Dependency order:

1. A01 identity and A02 reliable asset/registration foundations.
2. A03 stable catalog identity plus A04 comment distribution (one shared identity contract).
3. A05 shared native payments, extended capability schema and durable seller/buyer records.
4. A06 entitlement/renewal/metered behavior and old-receipt migration.
5. A07 strict FIPS gateway integrated with all player/asset paths.
6. A08 replica/availability/load behavior and A09 durable update packaging.

Backstage, library and checkout must use the real integrated APIs, not fixture-only UI. Add positive and fault-path tests per slice; test Cloud payments whenever shared code changes. A complete isolated publish -> discover -> approve/pay -> seller settlement -> play -> resume -> comment -> cross-node view -> expire/renew flow is the phase exit, on all three rails. No single-method demo closes this gate.

Phase 3 — Complete other product work in bounded lanes

Suggested lanes: B01–B07 Cloud/payments; C01–C07 connectivity/UI/AI; D01–D08 lifecycle/security/apps; D09–D11 developer/design/hardware UI. Share files only through an assigned integrator; no two agents edit the same dispatcher/schema/common player at once.

Preserve the previously requested finishing sequence as far as dependencies allow: ordinary backlog work and media first; standard-channel MeshCore then firewall/tunnels; deferred final connection UX review; public file/folder sharing; Mesh file picker/delivery; notification artwork last. Prepare shared primitives earlier if necessary, but do not divert effort into the deferred polish before its prerequisites.

Each lane closes ledger rows with evidence, not broad “done” messages. Historical acceptance that still applies avoids unnecessary rework; fixes touching the same path require targeted regression runs. No unlimited redesign of already working surfaces.

Phase 4 — Integrated automated qualification

Run full clean backend/frontend/app/Android tests and production builds on frozen reviewed commits. Run real services in disposable multi-node fixtures with resource limits, not only mocked API tests. Include process kill/restart, storage-full/permission errors, relay partition, mixed versions, wrong identity, invalid metadata, payment uncertainty, mint/chain outages, FIPS path loss and restoration.

Use at least publisher P, buyer B and initially unrelated late-joining node C. Qualify A<->B and C joins, not a hard-coded pair. Run one longer soak through expiry, reconnect, repeated app open/close and controlled producer outage; inspect memory, descriptors, queues, payment attempts and duplicate streams. Archive failures as well as successful reruns.

Performance targets are proposed, not measured claims: immediate action feedback within 100 ms; cached destination shell within 500 ms; on a declared healthy test network, publication/comment convergence p95 within 10 s and recovered/late-join discovery within 60 s. Propose first frame p95 within 5 s and seek within 3 s for a specified 1080p fixture/link; record actual codec, bitrate, concurrency and resources. Agree budgets after baseline measurement, before tuning; never relax a failed budget silently.

Exit: all mandatory automated/integration tests pass, required ignored tests accounted for, no unresolved security/funds/data/transport defects, and measured performance evidence.

Phase 5 — Package and rehearse the exact candidate

Build immutable versioned candidate artifacts from the frozen commits. Rehearse native IndeeHub update with real nonempty project and monetary fixtures; drain queue jobs, preserve all volumes/migration history and pending purchases, then verify both commit and forced rollback. A rollback that restores correctly is not a successful forward update.

Qualify fresh x86 VM/ISO install and 1.9.1 -> candidate OTA, reboot and rollback. Verify helper/template bytes, companion APK version/build/certificate consistency, app image digests, signed catalog capability gates and normal update discovery. Exercise the key product scenarios after installing the actual artifacts. Do not count extracted payload checks as booted ISO acceptance.

Native ARM compilation/frontend testing is useful additional evidence, not x86 release/ISO acceptance. A Raspberry Pi claim additionally needs pinned compatible build environment and physical supported Pi hardware; do not call an ARM binary a node image.

Exit: exact installed artifacts pass; documented data-preserving rollback works; no hot patches required.

Phase 6 — Supervised real-node pre-UAT and physical qualification

Obtain explicit candidate deployment scope, private backups, rollback conditions, approved test content and any spending cap. Verify node roles privately and capture wallet/app/identity baselines without copying secrets or infrastructure identifiers into public artifacts. Start with one canary, then publisher/buyer/third node. Use the normal managed update path.

Perform extensive headless actual-node checks BEFORE asking the operator to discover obvious defects. Verify served hashes, actual FIPS byte route, source integrity, settlement records, entitlement, repeat access, comments and publishing. Exercise physical Android signer, WebView resume, media/PiP/controls/artwork, upload/download and terminal input. Complete authorized real MeshCore standard-channel checks and affected-node authenticated UI acceptance.

Funded smoke tests, if needed, use a newly approved total including fees and verified destinations; old budget notes are not a fresh allowance. Destructive, double-spend/reorg and expiry-clock fault tests remain in isolation. Do not close real channels to test fee defaults.

Exit: private environment-specific evidence, no regression in wallets/files/native identities/unrelated apps, and concise UAT instructions with no expected blockers.

Phase 7 — Operator UAT, repair/retest and release decision

Give the operator the matrix below and exact candidate versions. Every failure becomes a ledger item with reproduction, fix, focused rerun and relevant regression/packaged rerun. Any artifact change invalidates the evidence affected by that change. Rebuild/re-sign only through authorized release ownership; do not overwrite existing tags/artifacts.

After UAT, produce completed matrix, unresolved external/previously accepted limitations, hashes, compatibility/migration notes, backup/rollback proof, ngit proposal dispositions and mirror verification. Publication is a separate explicit owner action; workers never merge, push main, tag, sign, publish or change live nodes on their own.

5. UAT matrix (operator-facing steps to specialize privately)

1. Fresh experience: open the packaged app, choose the intended native identity, verify profile; sign out/reopen/switch identity without stale account restoration.
2. Backstage: create a draft, select the approved Cloud film and separately exercise computer upload; change tabs, save/reopen, process/retry, configure real receiving methods and terms, explicitly publish. Draft remains private.
3. All-instance catalog: B and unrelated C discover the same published film and stable identity; C joins after publication. Repeat for all approved published fixtures, pagination, edited metadata and withdrawal.
4. Shared comments: post on B, view/reply on C and publisher; compare thread/counts after reload, relay interruption and late join. Same film via different hostnames or node proxies keeps the same discussion. Moderation/deletion behavior is explicit.
5. Lightning rental: native approval, one correlated payment, producer settlement, valid entitlement and working film. No BTCPay access/configuration at any stage.
6. Ecash rental: supported mint/backend, exact price/change, valid settlement and playback; interruption/recovery creates no second spend. Exercise metered behavior separately if offered.
7. On-chain rental: explicit amount/fee/confirmation review, native submission, correct pending display and grant only under agreed confirmation policy; resume without duplicate transaction. Chain fault cases already proven in regtest.
8. Transport proof: capture diagnostic evidence for initial play, seek, rendition switch, trailer and resume. With FIPS denied and direct/Tor alternatives available, remote delivery fails closed; restore FIPS and resume without repayment. Inspect MinIO/original/key endpoints for bypass.
9. Rental lifecycle: first-play start once, pause/reopen/authorized second session, app/node restart, expiry denial including cache/keys; renewal requires explicit consent and no ambiguous prior operation.
10. Availability: publisher outage while an approved serving replica is available; no-route state when all sources are unavailable; recovery retains entitlement and film identity.
11. Phone media: foreground, lock, background, PiP enter/exit, pause/seek/next/stop, reopen same position/queue, artwork, logout/session expiry and network recovery without duplicate audio or charges.
12. Cloud: all configured sources including no File Browser, private-user separation, uploads/recovery/downloads, paid file/cache/copy/repeat, public folder rules, Mesh multi-file delivery.
13. Connections/Fleet: new request, notification/approval, reciprocal state, relationship-specific removal, offline/last-seen/map, partial sync, metrics and responsive navigation.
14. System/apps: recovered monitoring/disk, app restart/uninstall/update decisions, HTTPS iframe/tab, AI setup/funding, websites/guest access, business/mining scoped scenarios, terminal session continuity and agent-built app.
15. Hardware: physical standard MeshCore messages both directions and standard-client interoperability, reconnection/listener stability; required companion/device cases.
16. Upgrade safety: candidate OTA/app/APK, reboot and documented rollback preserve identities, wallets, receipts, files, drafts/comments, app decisions and unrelated services. Repeat core flow from the installed candidate.

6. Safety and release controls

• Backend execution on machines with installed apps uses scripts/test-backend-isolated.sh; cargo test --no-run is compile-only. Inspect other harnesses before execution.
• Untrusted proposal CI uses disposable secret-free isolation, exact reviewed commits, resource caps, no host network/home/credentials/wallets/service buses/container socket/live storage.
• Keep source/unit, disposable integration, packaged artifact, actual-node and operator/physical results separate. Historical test counts are not this plan's test results.
• Keep infrastructure access details, endpoints, node identifiers, keys and private operational evidence out of repositories/public logs. Use generic role labels in public records.
• Preserve all operator identities and source files; back up before authorized migration. No auto-publication, no wallet reset, no automatic re-payment or uncertain refund claim.
• Use canonical ngit review/merge once; mirror exact accepted commits/tag objects to Gitea. Verify required refs before release, inventory unrelated historical drift and resolve only with approval; do not force-push it away. A main-only check is not full historical parity.
• Existing V4V private source/images remain private. Catalog audience restriction alone does not make a public registry image private.

7. Cost-controlled execution and model handoff

[historical model alias] may be a provider-specific alias. Its availability, underlying model, current pricing and performance were not verified in this session. Use it as the primary implementer only after a small paid pilot demonstrates repository instruction compliance, safe diffs and passing tests. No unsupported claim that it is best or cheapest.

Recommended split: economical coding model for bounded implementation, test fixtures, UI states, documentation and ledger maintenance; strongest available coding/reasoning reviewer for architecture, payment/idempotency, authorization, FIPS bypasses, migrations and final release evidence. Deterministic tests, not model confidence, decide pass/fail.

Cost rules:

• One coordinator/ledger; at most a few independent lanes, never five agents editing shared payment code.
• Give each task exact source paths, contract, acceptance tests and forbidden actions. Do not reload the entire historical conversation every task.
• Land small reviewed slices; run focused tests on each, full suites at integration freezes. Build the expensive release/ISO only after a frozen green candidate.
• Stop after two unsuccessful diagnosis/fix cycles or any financial/auth ambiguity; escalate with reproducer instead of spending indefinitely.
• Record tokens/cost, elapsed time, test evidence and rework per accepted task; compare models by accepted change, not token price alone. No reliable total estimate before Phase 0 and the pilot.

Copyable executor brief

Implement the completion plan in this file, starting with Phase 0 only. Ignore the prior release resume as authority, but preserve historical evidence and all repository instructions. Do not implement from the dirty checkout or assume candidate branches are accepted. Produce the reconciled A–E ledger, exact source map and baseline results first. Then execute reviewed bounded slices in the stated dependency order. Required outcomes are no-BTCPay native Lightning/ecash/on-chain checkout, strict FIPS inter-node media, globally discoverable explicitly published films and shared comments, correct Backstage/native identity UX, and all retained completion gates. Never mark unavailable or fixture-only checks as real-node passes. No live deployment, new payment, public content publication, hardware flash or release publication without explicit scoped authorization. Stop/escalate on fund safety, auth, provenance or destructive migration uncertainty. End every task with changed paths, exact revisions, tests/results, remaining blockers and next action.

8. Decisions to confirm before implementation or live testing

• Approve the broadened completion scope and ledger; distinguish required core developer experience from previously deferred broad Omarchy parity.
• Confirm unpublished release version after remote checks; never rewrite an existing 1.9.2 release.
• Approve strict Archipelago/FIPS playback behavior for external catalogs and switch the default only after qualification.
• Confirm rental first-play/window/renewal/device terms, metered offer semantics, creator revenue/split policy, on-chain confirmation/reorg/refund policy and minimum viable prices.
• Approve public-film backfill selection and replica storage/retention policy; drafts stay private.
• Confirm public comment moderation/legacy-reference migration policy and acceptable convergence/performance budgets.
• Identify the exact approved test film, candidate deployment roles, physical Android/radio availability and any fresh real-funds cap privately.
• Keep previously accepted upstream limitations (notably missing original Angor announcements) explicitly separate. Fix what is fixable; do not claim impossible reconstruction as completion or silently broaden a waiver to new defects.