Make it work.
Ship it. Improve it.

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.

Hard execution requirement: progress autonomously from researched idea to a publicly available app on both stores, then rebuild and release updates from feedback. Once execution starts, no routine owner approval, physical-device check, manual handoff, or unattended checkpoint may stop that chain. Automated quality checks still run; failures trigger repair and another attempt. The interface must show what happened at every stage and what happens next.

The first publication closes gates A and B below. Gate C establishes the continuing feedback/update loop; waiting for the first authentic feedback item must not delay an otherwise ready first publication. Store review remains an external wait that the coordinator monitors and resumes from automatically.

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 remains background evidence.

Owner decisions recorded for the next execution session: choose the best-suited new game and launch countries from research; use the existing corresponding Octo publisher accounts and the allowed same-team Apple uploader; require no physical-device testing; run the ordinary idea-to-publication and feedback-update workflow without further owner checkpoints; expose stage progress and evidence in the interface. Execution still starts in the next session. These decisions update the plan and do not start development or publishing now.

1. The outcome and the scope

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.

The coordinator owns recovery and forward progress. Fix failed tests, missing artifacts, ordinary build/configuration problems, and actionable store feedback automatically. Resume after service restarts and external review waits. A real account-holder verification/legal action or an unresolved platform decision can still prevent publication; report that exact external dependency with evidence while continuing all eligible work. This requirement removes agent-created stops, not the stores' authority to approve an app. Never represent an unapproved or unavailable app as published to satisfy a dashboard target.

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.

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, Apple simulated and 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, Apple upload options

Use two readiness markers: local QA passed means the rules and production-entry emulator/simulator scenarios passed; release QA passed additionally binds those tests to the intended source revision and verifies distribution packaging, version/build, signing, entry point, and configuration. Gate A closes before production submission with no physical-device dependency. Record the tested runtime artifact and signed distribution artifact separately: an iOS Simulator test does not prove that the signed iPhone binary ran on hardware.

Physical-device testing is explicitly not required. It is optional, non-blocking evidence if it becomes available. Do not create a hardware-procurement task, physical-device approval, mandatory TestFlight installation, or phone-based public-install check as a prerequisite to submission, release, or completion. The interface must say “Physical testing: not requested — non-blocking”, rather than show it as a pending required stage. Emulator/simulator coverage and physical performance remain different claims. Apple testing limitations

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

These are proposed acceptance thresholds, not claims about existing coverage or guarantees of zero future defects. An unrun, flaky, or inaccessible required automated check triggers diagnosis and recovery; it cannot become a release pass. Optional physical coverage has no effect on release eligibility.

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 release whose QA/evidence chain does not match its source, configuration, and version. Record the hashes of both tested runtime artifacts and separately signed distribution artifacts, including their declared platform/SDK differences. Changes after QA invalidate affected checks and automatically schedule a rerun. The full critical journey still runs in the native virtual runtimes for every new binary release; never label the signed iPhone binary as runtime-tested when only its Simulator counterpart was exercised.

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

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, browser submission steps

For unattended publishing, use the owner's recorded execution scope to replace per-release phrase checkpoints with standing authority for the selected game, mapped accounts, researched territories, and ordinary submissions/updates. Once the next session starts execution, do not ask again for concept approval, artwork approval, a routine merge handoff, or each final publishing click. Route required source integration through the owning Chief/approved integration mechanism automatically; do not bypass repository permissions. The scoped release executor still requires an identified release and passing automated QA/listing receipts. Keep general browser drivers unable to publish arbitrary content. This planning request does not start 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:

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, Google testing, Google release process

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 publication proof to the publisher, package/bundle, source SHA, version/build, store record, track, territory, and observation time. A public listing may not expose its internal build number; use the console's published-version-to-build association together with an independent observation of that public version. Expose version/build in the game's support/about screen for available runtime checks. Store availability, virtual gameplay, and physical installation are separate evidence fields. A missing physical install does not keep the publication stage pending or imply it was performed. Stores may re-sign or repackage delivery; do not assume uploaded and delivered bytes are identical.

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

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.

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 native virtual-runtime build with real saved progress. Keep any unsupported store-delivery upgrade path visible as a coverage limitation, not a physical-device dependency.
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. Replay the original problem and save migration in the updated native virtual runtime, then verify the corresponding new version is publicly available through the same stores. Close the automated repair only with reproduction/regression, source/build, and publication evidence; display physical/store-installed retesting separately when available. If the original defect specifically depends on hardware and cannot be reproduced, keep its resolution unverified rather than claim a repair; independent release work continues.

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. Bound each worker attempt in time and scope. Repeated failures trigger automatic re-diagnosis, a different repair strategy, or replacement of the failed worker; an arbitrary retry count must not become a mandatory owner checkpoint. Persist attempts, back off repeated external failures, and prevent identical expensive retry loops within configured resource limits. Never close an issue 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.

Before first publication, demonstrate the rebuild mechanism with clearly labeled local failure/replay tests. After publication, keep collecting authentic feedback and perform the real update loop when it arrives. “No feedback yet” is a monitoring state, not a reason to delay or undo first-publication success.

8. Execution phases and accountable work

These are proposed engineering windows. The role names below describe automated worker responsibilities coordinated by the execution session, not people the owner must hire or hand work to. Store reviews, account verification, and mandated testing may extend calendar time; the coordinator persists and monitors those waits rather than waiting for the owner to restart it.

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.

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.
• Stage event: sequence/event ID, game/release/attempt, stage, status, human-readable action and result, artifact references, start/update/end times, and next automatic action or external dependency.

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 interface: what happened at every stage

This section specifies the interface to implement during execution. It is not a claim that the live operational dashboard has already been changed. Extend the existing Studio and control-state system. Start recording and displaying real events in phase 0, then add richer artifacts as stages become available. The interface is a view of the running workflow; the owner does not have to operate it to keep work progressing.

Show one game journey with a shared research/design/code/QA track and distinct Android/Google and iOS/Apple tracks. Each stage shows its status, what was done, the result, evidence links, start/finish/last-update times, elapsed time, and the next automatic action. Default to plain language; put technical logs and identifiers in expandable details. The top summary states the current activity and each store's actual publication state.

Use status labels such as Queued, Working, Checking, Fixing, Waiting for store, Published, and External action required. A failed attempt stays in the history; the current stage shows its active recovery rather than reverting to a blank state. “Waiting for store” includes the last observed state and next check. “External action required” names the actual unresolved dependency, not a generic human checkpoint. Optional work never contributes a false blockage.

Populate this interface from durable stage/release events, not hard-coded snapshot counts or an agent's prose alone. Refresh automatically, preserve history across reload/restart, and show the age of the latest observation. Reject stale/out-of-order results that belong to an older attempt; attach each artifact to its actual release. If the data feed is unavailable, show its last update time rather than inventing progress or success. Authenticate private evidence and redact credentials, sessions, and private reviewer/customer data from shareable views.

Interface acceptance: on mobile and desktop, the owner can open a single URL and see the latest action, prior completed work, stage evidence, both store states, and the next action. During a test failure → repair → rerun, all three events become visible automatically. Reloading the page or restarting a worker preserves that history. No stage requires pressing an approval or continue button to advance an already-authorized operation. Provide a direct anchor for every stage so an individual result can be shared or inspected.

11. 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. Public distribution: independently observed public availability in the researched territories, reconciled with the exact published console version/build. Physical installation is not a completion condition.
5. A repaired game: authentic feedback when received, a failing regression, a passing patch, fresh binaries where needed, virtual-runtime save/upgrade evidence, and verified public updates. First publication does not wait for feedback to arrive.
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.
7. Visible progress: the interface shows the work, result artifacts, attempts, store states, and next actions at every stage, without an owner having to advance the workflow.

Ready to execute means the owner starts execution of this plan. Game selection, research countries, the same-team Apple uploader, no mandatory physical-device checks, and unattended ordinary publication/update work are already specified. Materialize that scope in the executor during setup and validate existing credentials. Do not re-request those decisions or substitute a new manual gate. The coordinator must continue from idea to verified publication and into monitoring; genuine external account/platform dependencies remain accurately reported exceptions. This iteration still changes the plan only.

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.