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.

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

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.

First-game planning choice: a small, offline, single-player 2D route puzzle. A player connects a start and destination while satisfying visible board constraints. Use fixed authored levels, a short tutorial, clear completion feedback, replay, and local progression. Start with approximately 30 validated levels with several distinct rule combinations. This is a proposed testable scope, not a validated market opportunity or a promise of store acceptance.

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. For this small 2D game, begin with a fresh React Native/TypeScript project and reuse the available native delivery paths. 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

Use quick simulator/emulator runs during development, then verify the real signed release candidate. Android evidence includes an installable build derived from the identified AAB, followed by the Play-distributed build. iOS evidence includes the production app on a physical iPhone and the identified TestFlight/App Store build. Record the relationship between each test artifact and its source/release; a debug build cannot certify an untested release build.

Use two readiness markers to avoid a circular gate: device QA passed permits uploading to a store test channel; release QA passed additionally requires the store-distributed candidate to pass the critical journey. Gate A closes at the second marker, before production submission. For pre-upload iPhone testing, use a properly provisioned physical-device build from the same identified production source/configuration and record signing differences; the TestFlight check confirms the distribution candidate itself.

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

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 a specific boundary to settle before execution. 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. Proposed default: a restricted macOS uploader sends the signed binary to the same registered Apple team, then Octo verifies the resulting build and performs every store-console action. This is an explicit technical exception to a literal “every operation inside the browser” interpretation, not a second publisher or permission to move submissions to API scripts. If that exception is unacceptable, the iOS lane is blocked at preflight until a supported route is agreed. Apple upload options, browser submission steps

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:

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, device_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 a small agreed territory set. 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 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.

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.

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, with the publisher mappings and scoped release policy established and the Apple upload boundary resolved. Those are setup inputs for the future run, not permission requests 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.