# Game delivery plan: prove it works, publish through Octo, rebuild from feedback

**Iteration 2 · 6 September 2026 · PLAN ONLY.** This is the proposed execution plan. No games are being deleted, developed, built, or submitted during this iteration. Updating the published planning document does not start execution.

**The target is one completely new game that works on Android and iPhone, reaches both public stores through the corresponding publisher accounts in Octo Browser, and can be fixed and released again from actual feedback.** Three separate gates must pass: gameplay works; the intended release is publicly installable; a feedback-driven update works and reaches users.

This replaces the earlier recommendation to finish an existing app. Existing games may be retired when execution starts. Preserve reusable delivery tooling and account/signing custody; create the game's source, identity, content, and artwork from scratch. Discovery scale, portfolio economics, and generating more games move behind the first verified release-and-update cycle. The [previous audit](https://mediamagic-project-report.pages.dev/audit) remains background evidence.

**Owner decisions recorded for the next execution session:** choose the best-suited new game from research without another concept-selection checkpoint; use the actual countries/storefronts supported by that game's research; allow the needed Apple binary uploader for the same publisher team. Execution still starts in the next session. These decisions do not start development or publishing now.

## 1. The outcome and the scope

| Gate | Required result | Evidence that closes it |
|---|---|---|
| **A — The game works** | A player can learn, play, finish, replay, save progress, and resume on both platforms. | Real interaction tests against the release entry point, gameplay assertions, device logs, recordings, and release-candidate identity. |
| **B — The game is published** | The exact intended version is available in the selected territories under the correct Google and Apple publishers. | Octo account/submission receipts, current store observations, and successful installations from both public stores. |
| **C — Feedback produces an update** | An authentic issue becomes a verified change delivered through the same publisher accounts. | Original feedback → reproduction → regression test → source change → new identified build → store update → installed verification. |

An APK link, simulator recording, saved console draft, TestFlight upload, or successful browser click closes none of these gates by itself. If one store is blocked, report the other store's progress independently; the overall two-store objective remains incomplete.

**Game selection is delegated to the executing agent.** Refresh the existing research, compare a small shortlist of game opportunities across the actual Google Play and App Store storefronts, and choose the strongest fit for unmet player need, meaningful differentiation, manageable scope, and the ability to test/release through the existing accounts. Record competitors, evidence age, territory, selection reasons, and rejected alternatives. The winning research dossier determines the launch countries; a query's language alone does not establish a country. Do not quietly substitute the US for an unsupported storefront.

The earlier route-puzzle suggestion is only an example of a testable scope, not the chosen product. If research supports that concept, an illustrative version would use authored boards, a tutorial, clear completion feedback, replay, local progression, and approximately 30 validated levels with distinct rule combinations. Otherwise replace it with the stronger researched game and write equivalent game-specific acceptance scenarios. No game is being selected merely because a scaffold is easy to generate.

Exclude accounts, multiplayer, advertisements, purchases, and a remote backend from this first release. That limits the number of systems that can obscure the delivery problem. It does not justify a superficial game: the concept must pass a fresh differentiation and playable-content review before implementation. If it fails, select another small game within the same delivery constraints rather than reviving an old app.

## 2. Reset the games and retain the useful machinery

**During execution, first inventory and freeze old game jobs.** Record their source revisions, app/store identifiers, outstanding submissions, and any remaining user/support obligations. Preserve an archive tag, durable signing assets, and release receipts. Then remove existing game source, game-specific assets, active manifests, and obsolete catalogue entries in a reviewed change; update hard-coded fixtures and references so CI still works. The active catalogue should contain only the new game once it is created.

Removing old source does not imply deleting developer accounts, Octo profiles, signing material, store records, or taking an existing public app away from users. Verify any existing distribution before retirement and keep necessary support/privacy URLs and update custody. Do not delete worktrees or branches owned by other sessions. All cleanup in this section is future work.

| Keep and adapt | What the inspected checkout still needs |
|---|---|
| [Octo attachment and session handling](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/octo-harness/README.md) | Durable publisher identity checks, complete browser submission/release steps, and restart-safe observation. |
| [Dedicated store profile checks](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/octo-harness/src/store-isolation.js) | Bind the visible developer account or Apple team to each game; a matching profile alone is insufficient. |
| [Android device capture](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/ship-game/src/device-qa.js) | Gameplay assertions. The current checks primarily prove non-blank/changed frames, foreground presence, and a playable recording. |
| [iPhone workflow](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/.github/workflows/ship-game-ios.yml) | A separate interaction lane using the production entry point. Its current coverage/screenshot modes select `index.screenshots.js`. |
| [Scheduling and stages](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/ship-game/src/stages.js) | Gates for real QA, independent platform progress, feedback ingestion, and an actual verified update. |
| [Release approval checks](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/octo-harness/src/approval.js) | A scoped executor that handles the whole submission/release sequence and confirms external state. Existing exact-phrase/manual checkpoints do not supply unattended operation. |
| [Game design contract](https://github.com/PytaichukBohdan/MediaMagicASO/blob/06d869a673c2c0913d1a6513f104c12c304e5ae7/game-design-system/README.md) | A new game-specific design and meaningful device evidence, with visual capture kept distinct from behavioral QA. |

Do not rebuild the scheduler or replace the whole stack first. Prefer a simple 2D game compatible with a fresh React Native/TypeScript project and the available native delivery paths. Confirm the framework fits the researched winner's mechanics before scaffolding. Pin a currently supported toolchain during the initial Android/iPhone smoke build; do not inherit the old hard-coded framework version by default. Evaluate a dedicated game engine only if an early measured gameplay requirement cannot be met.

## 3. Define the game and its tests before building it

The product specification must describe rules, invalid moves, progression, persistence, pause/resume behavior, accessibility, and every promised feature. Create `design.md` and `game.visual.json` from the repository templates before UI implementation. Author new assets with recorded usage rights. Include distinct loader, menu, gameplay, and result states, semantic colors, safe areas, 48dp controls, and press feedback.

Separate the deterministic game model from rendering. The game model owns legal moves, completion, scoring, and save-state transitions. A level validator independently checks that every shipped level has at least one valid solution; separate reference cases check that invalid or incomplete boards cannot win. A test that calls the production win function and compares it with itself proves nothing.

Write acceptance scenarios as **player action → observable expected result**, with stable accessibility identifiers where possible. For example:

1. Fresh install → start tutorial → perform the displayed legal moves → reach a valid completed board → see the correct result and unlock only the next level.
2. Attempt an illegal connection → board and score remain correct → receive understandable feedback → continue playing successfully.
3. Complete level 1 → close and relaunch the app → level 2 remains unlocked and settings persist.
4. Pause during an unfinished board → background the app → resume → the board is unchanged, with no duplicated reward or unexpected timer advance.
5. Install the update over a saved earlier version → retain progression → complete the repaired scenario.

The test plan must cover failure and recovery, not merely take a screenshot of a screen named “result.” Do not add test-only handlers that replace production gameplay in the acceptance build.

## 4. Gate A: prove the developed game works

**Owning or connecting a phone is not a prerequisite for starting development or building/uploading release artifacts.** Run the actual Android game in Android Emulator/redroid and the actual iOS game in Simulator on the Mac runner. These are native runtime tests, not browser mockups. Octo operates the publisher consoles; it does not replace a native build system or emulate the game. [Android emulator](https://developer.android.com/studio/run/emulator), [Apple simulated and physical devices](https://developer.apple.com/documentation/Xcode/running-your-app-on-simulated-or-physical-devices)

Create the signed production artifacts separately: an Android AAB and an iOS distribution archive/build. A Simulator binary cannot be uploaded as an iPhone distribution build. Xcode can create that archive using a generic build-only device destination without a connected iPhone, and the approved same-team uploader can deliver it. [Apple distribution archive](https://help.apple.com/xcode/mac/current/en.lproj/devf37a1db04.html), [Apple upload options](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/)

Use two readiness markers: **local QA passed** permits uploading to a store test channel after rules and actual emulator/simulator gameplay tests pass; **release QA passed** additionally requires the identified store-distributed candidate to pass the critical journey and the hardware checks below. Gate A closes at the second marker, before production submission. A debug or Simulator result cannot certify an untested distribution build.

Physical Android/iPhone testing is this plan's proposed final quality gate, not a universal store-upload requirement. Local phones, remotely controlled phones, or a compatible hosted-device service can satisfy it; the owner need not personally own the devices. Verify that the selected access supports the required signing, store installation, account access, upgrade tests, and evidence export. Do not assume every device farm supports TestFlight or App Store installation. Missing hardware leaves final QA pending while research, development, virtual testing, signing, and beta uploads continue. Simulator performance is not physical-device performance. [Apple testing limitations](https://developer.apple.com/documentation/Xcode/running-your-app-on-simulated-or-physical-devices)

One separate platform prerequisite may apply: Google's new personal developer accounts require verification using a physical, non-rooted Android device running Android 10 or later. Check the existing publisher account's actual requirements during preflight; this is account verification, not something Octo or an emulator can substitute for. [Google device verification](https://support.google.com/googleplay/android-developer/answer/14316361?hl=en)

| Test layer | Concrete pass condition |
|---|---|
| Rules and levels | All shipped levels validate; reference solutions pass; invalid moves and premature completion fail; score/reward limits and save migrations are tested. |
| Static checks | Unit tests, lint, TypeScript, and `node game-design-system/scripts/verify-game-visual.mjs apps/<NewGame>` pass. |
| Actual player journey | Tutorial, start, play, completion, replay, progression, settings, and back navigation pass through actual taps on both native platforms. Complete every shipped level at least once on each platform using independently validated move sequences. Assert state and visible results after each action. |
| Persistence and interruption | Clean install, process kill/relaunch, background/foreground, interruption, offline play, and old-save upgrade preserve the specified behavior. |
| Device coverage | At least one physical Android device and one physical iPhone; additional small-screen and minimum-supported-OS emulator/simulator coverage. List the actual models and OS versions tested. |
| Stability | Proposed release threshold: 100 scripted rounds plus a 30-minute continuous session on each physical platform, with no observed crash, ANR, unrecoverable freeze, or blocked primary action. Retain failure logs, not just a pass label. |
| Responsiveness | Before coding, record budgets on named target devices. Initial targets for this simple puzzle: at least 95% of 20 cold launches interactive within 3 seconds; 95th-percentile tap-to-visible feedback within 150 ms. Measure them on the release candidate. |
| Visual and accessibility | Real loader/menu/game/result screenshots, readable text and contrast, large-text checks, accessible controls, correct safe areas, and no clipped or unreachable actions. |
| Packaging and listing | Correct package/bundle, version/build, signer, assets, support/privacy links, content rating, and declarations reflecting the actual SDK/data inventory. |

These are proposed acceptance thresholds, not claims about existing coverage or guarantees of zero future defects. An unrun, flaky, or inaccessible check is reported as such and cannot become a release pass.

**Prove the gate can reject a broken game.** In isolated test builds, introduce an incorrect win condition, disabled primary control, and lost-save defect. Require the corresponding tests to fail and publication eligibility to be refused. Remove the defects and prove the tests pass. Those builds never reach a store. Screenshot comparison remains a visual check; it cannot replace these behavioral failures.

No production submission may use a build whose QA receipt does not match its source, configuration, version, and artifact identity. Changes after QA invalidate the affected checks. The full critical journey still runs for every new binary.

## 5. Publisher identity and the Octo Browser boundary

**All developer-console setup, listing edits, build selection, submission, release controls, and reviewer correspondence will be operated in the corresponding authenticated Octo Browser profiles.** Use the existing Google and Apple accounts; do not create substitute publishers or switch accounts when a step fails. Octo supports attaching automation frameworks to its profiles; the repository already uses Playwright over CDP. [Octo automation documentation](https://docs.octobrowser.net/en/api/start-api/)

Create a private account registry with one record per store: stable profile UUID, expected developer-account/Apple-team identifier, permitted role, configured network assignment, allowed game identifiers, and references to signing/upload credentials. Public reports use account aliases and redacted evidence, not session cookies or private credentials.

Before each write, verify the profile, hostname, current visible publisher/team, app identifier, intended version/build, and target track/territories. Recheck immediately before submission or release. Preserve current profile/network assignments unless the owner separately changes them. One browser profile gets one active automation lease; one app/store gets one persisted submission lock.

A sign-in wall, wrong team, missing permission, verification request, or legal-agreement requirement becomes a precise account blocker with evidence. The current harness already refuses login challenges. Reusing an authenticated Octo session does not eliminate occasional account-holder work. A broken Apple lane must not stop Google monitoring, or vice versa.

**Apple binary transport is allowed for the next execution session.** Apple's supported upload paths include Xcode, Transporter, Xcode Cloud, and the App Store Connect API; its documented browser submission flow selects a build that is already uploaded and processed. There is no documented general IPA file-upload control in that flow. Use a restricted uploader for the same registered Apple team, then let Octo verify the resulting build and perform every store-console action. This permission covers the binary transport boundary, not another publisher or moving store submissions to API scripts. Preflight must still verify the uploader's credentials, team, and network configuration; approval is already recorded and need not be requested again. [Apple upload options](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/), [browser submission steps](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-app/)

For unattended routine publishing, replace per-release phrase checkpoints with an owner-established execution policy scoped to the new game, account mappings, territories, and allowed actions. The executor receives only an identified release with valid QA/listing receipts. Keep general browser drivers unable to publish arbitrary content. **This planning request does not activate that policy or authorize a store action now.**

## 6. Gate B: publish through the corresponding accounts

Develop the Android and Apple paths independently, joining them only for the final two-store completion criterion. Check account eligibility and required forms before investing in the full game, then follow this sequence:

| Step | Google Play through its Octo profile | App Store Connect through its Octo profile |
|---|---|---|
| Establish the record | Verify developer account; create the new game's record; record the exact package and console identifier. | Verify provider/team; create the record with the matching bundle identifier; record the Apple app ID. |
| Prepare store information | Fill listing, screenshots, rating, data declarations, audience, support/privacy links, and distribution settings. | Fill listing, screenshots, rating, privacy, support/review information, export declarations, and distribution settings. |
| Deliver a QA-passed candidate | Upload the signed AAB through the browser into the intended internal-testing release. | Use the scoped uploader above; in Octo, verify processing completed for the expected version/build and team. |
| Exercise store distribution | Install from Play's test track on an eligible device and run the critical journey. Complete any account-specific testing requirement. | Configure the appropriate TestFlight testing in Octo; install that build on an eligible iPhone and run the critical journey. Handle any beta review separately. |
| Prepare production | Select the already-tested AAB/version code and intended countries. Reconcile all outstanding changes. | Select the already-tested processed build; complete the version and review information. |
| Submit | Complete the actual publishing-overview/review controls required by the observed console state; preserve the submission receipt. | Complete both adding the version to the review submission and sending that submission for review. Preserve the receipt. |
| Observe and handle feedback | Read current release/review information and the complete relevant messages in Octo. | Read current submission/build information and reviewer messages/attachments in Octo. |
| Release approved work | Complete the release/publishing control when the configured workflow requires it. | Use a deliberate manual-release setting for the pilot; operate the release control in Octo after approval. |
| Verify users can get it | Independently open the public listing in a chosen territory, install the production version, and complete the critical journey. | Independently open the public listing in a chosen territory, install the production version, and complete the critical journey. |

At execution preflight, validate the current console's actual sequence; a fixed button-name list is not sufficient. Apple explicitly distinguishes adding an item for review from submitting it. Google also distinguishes test tracks and production release, with account-dependent testing prerequisites. [Apple review submission](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-app/), [Google testing](https://support.google.com/googleplay/android-developer/answer/9845334?hl=en), [Google release process](https://support.google.com/googleplay/android-developer/answer/9859348?hl=en)

**Never equate a disappeared button with a submitted or public release.** Store a write intent before acting; after the action, reload and verify the external state and matching identifiers. After a timeout or worker restart, inspect the console before retrying. An unknown result remains `unknown`, and an operator should never find duplicate submissions caused by blind retries.

Use separate states: `qa_failed`, `local_qa_passed`, `uploaded`, `processing`, `test_available`, `release_qa_passed`, `submission_draft`, `submitted`, `in_review`, `rejected`, `approved_unreleased`, `public_unverified`, `public_verified`, and `blocked`. Persist them per app, platform, and release attempt. Absence of the requested version cannot fall back to an older live release. Pre-order and staged availability remain distinct from the intended full availability.

Bind the final proof to the publisher, package/bundle, source SHA, version/build, store record, track, territory, and observation time. Expose the app's version/build in its support/about screen for installed verification. Stores may re-sign or repackage delivery, so prove source-to-submission-to-installed identity rather than expecting downloaded bytes to match the uploaded binary.

For the first production release, use the countries/storefronts supported by the selected game's research and the existing publishers' distribution eligibility. The owner has delegated this choice; another arbitrary country list is not needed. Record unavailable researched territories explicitly instead of silently changing geographies. Do not promise a percentage rollout for a new Play app: Google's percentage controls apply to updates. Later update rollouts can use available phased/staged controls under the execution policy. [Google release controls](https://support.google.com/googleplay/android-developer/answer/9859348?hl=en)

## 7. Gate C: turn feedback into a rebuilt game

Start observing each store as soon as a test build or submission exists. Poll through the relevant Octo session at a proposed 15-minute cadence while awaiting processing/review, then daily for routine released-game feedback; use backoff, profile leases, and the platform's limits. Ingest support/tester reports as well. Store original message text, attachments, timestamp, source, affected version, and a deduplication identifier. Record inaccessible correspondence as missing coverage.

| Feedback class | Required response |
|---|---|
| Gameplay, crash, progress loss, or performance defect | Reproduce on the affected build; add a regression; patch source; create a new binary; pass QA; redistribute, submit, and verify the update. |
| Listing, screenshot, or declaration issue | Correct the specific material in Octo, keep it consistent with the game, and follow the relevant review path. Rebuild only when the binary also needs to change. |
| Build processing, signing, or entitlement failure | Preserve the processing error; repair the build/signing inputs; create a new identified artifact and repeat affected device/distribution tests. |
| Usability complaint or feature request | Establish the expected user behavior and acceptance scenario; prioritize within scope. Vague feedback does not trigger an unlimited rewrite. |
| Account, legal, or ambiguous policy issue | Pause that store lane with original evidence and the required accountable action. Do not pretend changing game code resolves an account issue. |

The binary repair sequence is explicit:

1. Locate the affected source revision, toolchain, build, and save-state format from its release record.
2. Reproduce the defect using the original report's actions/device conditions; retain the failing run. If reproduction is unavailable, record uncertainty and collect diagnostics instead of claiming a fix.
3. Add an independent regression that fails on the old revision; make a bounded change; show it passing on the new revision.
4. Preserve package/bundle identity and signing continuity; allocate a new version/build as required. Test upgrade over the previous installed game with real saved progress.
5. Run the critical journey and affected regression tests on both platforms for shared-code changes. Rebuild and retest each affected platform; do not unnecessarily replace a passing unaffected release.
6. Send the candidate through store testing, then the same Octo account and publishing workflow. Preserve review responses and each new attempt.
7. Install the public update over the prior version and replay the original problem. Close the feedback item only after the relevant user-visible outcome is verified.

Retain the last known good source and release inputs. Recovery generally means halting an available rollout and shipping a corrected higher-version build; do not assume the stores can instantly downgrade every installed app. Initially bound an issue to three automated repair attempts, then retain it as unresolved with evidence for escalation. Never close it merely because stages were reset.

**The demonstration must include authentic feedback that causes a game-code change.** A real beta/player issue can establish the rebuild mechanism, followed by a verified public update. Separately replay recorded rejection messages and simulated submission timeouts to test those handlers; label these as simulations. Do not manufacture bad public releases, reviews, or store rejections to obtain evidence.

## 8. Execution phases and accountable work

These are proposed engineering windows with a mobile engineer for each platform, a QA automation engineer, and an automation/release lead available. Roles can be combined at lower throughput. Store reviews, account verification, and mandated testing may extend calendar time; they are external waits, not successful completed phases.

| Phase | Work and dependencies | Owner | Exit gate |
|---|---|---|---|
| **0 · Days 1–2** | Freeze/archive old games; map the two Octo publisher accounts; verify roles, signing custody, virtual test capacity, and the approved Apple uploader. Run fresh Android/iPhone build smoke checks; identify access for later physical-device QA. | Release lead + mobile engineers | Known account readiness, recoverable identities, working build/virtual-test capacity, and an empty active product catalogue. Physical-device procurement does not block independent development. |
| **1 · Days 2–4** | Refresh the research, select the best-suited game and matching countries, then finalize its specification, differentiation, content/assets, deterministic rules, and executable acceptance scenarios. | Product/mobile lead + QA | A cited selection dossier and geography mapping; every promised behavior has a test and a target-device budget; design documents exist. |
| **2 · Days 4–12** | Build the new game; add rules/content tests, emulator/simulator interaction QA, persistence, packaging, and intentionally failing gate checks. Develop publisher identity checks and arrange physical-device access alongside it. | Mobile engineers + QA + automation lead | Local QA passes against identified candidates; broken builds are demonstrably refused. |
| **3 · Days 10–16** | Complete Octo console setup, beta distribution, physical-device release QA, submission/release controls, exact-version observation, and restart recovery. Requires account readiness and local-QA-passed candidates for beta upload. | Automation/release lead + QA | Both beta-distributed candidates pass the final hardware checks, closing Gate A; receipts survive a worker restart without duplicate actions. |
| **4 · After phase 3 and review** | Submit, observe, address authentic review feedback, release, and install from both public stores. | Release lead | Gate B passes for the intended versions and territories. |
| **5 · In parallel from beta onward** | Ingest real feedback, reproduce, patch, rebuild, retest upgrades, and deliver the public update. | Mobile engineer + QA + release lead | Gate C passes with a complete feedback-to-installed-update evidence chain. |
| **6 · Only after A, B, and C** | Repeat routine updates, verify unattended recovery, then consider a second distinct game. | Lead | Three consecutive routine update cycles meet the same gates without per-release owner clicks. |

Do not spend these weeks expanding niche discovery, generating multiple games, or migrating to a new orchestration platform. The primary dependencies are game correctness, trustworthy release identity, complete Octo publishing, and repair from evidence.

## 9. Concrete engineering tickets and durable records

Every path below is a proposed implementation starting point, not a claim that the change is already present.

| Ticket | Starting point | Definition of done |
|---|---|---|
| **RESET-01** | `apps/`, active manifests/catalogue, game-specific CI fixtures | Old game jobs retired and source removed after preservation; new-game scaffold is the only active product; shared checks remain valid. |
| **GAME-01** | New `apps/<NewGame>` | Fresh game, assets, levels, design documents, and deterministic gameplay contract on Android and iPhone. |
| **QA-01** | `ship-game/src/device-qa.js`, QA scenario schema, native test workflows | Real actions and assertions, physical-device evidence, negative controls, and source-bound release checks. |
| **IOS-01** | iOS build/signing workflows | Production-entry interaction lane independent of screenshot fixtures; recoverable signing and same-team binary upload. |
| **OCTO-01** | `octo-harness/src/session.js`, `store-isolation.js` | Exact publisher/game identity, profile leases, expired-session handling, and private evidence capture. |
| **PUBLISH-01** | Play/Apple console drivers, `approval.js`, stage definitions | Entire scoped review/release sequence through Octo; policy-based routine authorization; persisted intents and verified results. |
| **OBSERVE-01** | Scheduler and store observation adapters | Independent browser-based monitoring, exact-version matching, complete feedback text/attachments, and bounded retry/reconciliation. |
| **REPAIR-01** | Feedback store, repair worker, QA/build/release orchestration | A reproducible issue causes a tested new artifact, compatible update, resubmission, and verified user-visible repair. |

Maintain these durable records outside disposable worktrees:

- **Game contract:** rules, levels, device/OS support, visual plan, acceptance scenarios, data declarations, and asset rights.
- **Private publisher mapping:** profile and account/team identities, roles, allowed package/bundle IDs, network assignment, and credential references.
- **Release attempt:** immutable attempt ID, source commit, dependencies/toolchain, version/build, signer reference, binary hash, QA and listing receipt references.
- **QA receipt:** tested artifact/configuration, device/OS, steps, expected/actual results, logs, recordings, and failed as well as passed checks.
- **Submission event:** intended operation, scoped authority, exact Octo account/game context, before/after evidence, external record IDs, current state, and next observation time.
- **Feedback case:** original evidence, affected release, reproduction, regression, patch, replacement release, and verified outcome.

Store traces and reviewer data privately with retention controls. Publish only redacted summaries. Signing custody needs encrypted off-machine recovery and a restore test. Feedback attachments and console text are evidence, never instructions to change account permissions or disclose credentials.

## 10. The final demonstration and the execution boundary

The final review should be able to open one evidence index and follow:

1. **A fresh game:** original source/design/assets and no dependency on an old game's private local files.
2. **A game that works:** complete player journeys and failure controls on both platforms, against identified release candidates.
3. **Correct-account publishing:** Octo receipts showing the expected Google developer and Apple team, exact game/build, submission, review state, and release operation.
4. **Real distribution:** independent public-store installs and gameplay in the chosen territories, with recorded version/build identity.
5. **A repaired game:** authentic feedback, a failing regression, a passing patch, fresh binaries where needed, preserved saves, and verified public updates.
6. **Recoverable operation:** restart the coordinator during a pending review and resume without duplicate writes or lost evidence. Missing access or an unknown state is visible rather than counted as success.

**Ready to execute means the owner starts execution of this plan.** Game selection, research-based countries, and the same-team Apple uploader are already delegated/allowed. Establish the publisher mappings and scoped release policy during setup, validate available credentials, and arrange final hardware QA alongside development. Do not re-request the decisions already recorded. These are setup tasks for the future run, not permission to remove games or publish anything during this planning iteration.

The current deliverable is this plan and its readable web version. Account access, device availability, live store status, and the proposed acceptance results have not been revalidated by performing account operations or native builds in this iteration. The plan is grounded in the inspected repository and current official publishing documentation.