Gameplay rebuild plan¶
Historical plan. Use the current roadmap for scope, order and verification; this file retains earlier design and evidence.
Goal¶
Rebuild Tiny Chaos's intertwined gameplay code into understandable, reusable Unity systems, then integrate the existing game on those systems. The owner changed the work order on 2026-10-25: audit and plan the whole cleanup before further implementation; prioritize shared foundations over repairing each existing screen independently. This document retains its filename so current links continue to work. It is the sole active work-order plan; the issue register owns defects, the architecture reference describes current code, and the code audit supplies source evidence.
The source-backed core inventory/contracts, dependency order, fixture/content standards and first implementation gate were checkpointed in documentation-only dd0a666b. Batches 35/36 now implement the isolated lifecycle and minimal shared host/scene. Work through the dependency order in coherent system groups, using the lightweight checks and integration campaign below. Trace affected callers and serialized bindings before replacing their owner. Do not return to independent downstream screen patches.
Owner clarification on 2026-10-26: plan explicit one-device-per-slot setup for up to four players. P1 uses keyboard or gamepad; P2–P4 use distinct gamepads. Add keyboard/gamepad button remapping with persistent per-profile bindings. Migrate legacy input to Unity's Input System with reusable player setup. These are approved scope extensions, not implemented features; unrelated feature proposals remain deferred. The dummy stage/enemy and any development-only launcher/config are development fixtures for this rebuild, excluded from public catalogs, progression, score submission and production build dependencies. The shared gameplay runtime scene can later ship after released-content migration; development data must not become a serialized dependency of that production scene.
Owner additions on 2026-10-26: plan one shared gameplay runtime scene with stage ScriptableObject/environment composition (IDEA-20), and explicit scoped event ownership (IDEA-21). These are architecture planning directions, not implemented systems. A distinct stage should supply data/environment/behavior through shared contracts; use separate content composition only for a demonstrated requirement. Current GameEvents is existing event infrastructure to migrate, not evidence that a new event bus has shipped.
Dedicated investigation/fixes for the reported one-minute main-menu freeze (GAME-01) remain deferred until the owner resumes them. Preserve evidence and record incidental observations. Rebuild progress is judged by clear ownership, reusable content setup, removed duplicate paths and verified system behavior. Final playability and Windows release validation remain required integration outcomes, rather than reasons to keep repairing downstream code before its dependencies.
Owner update · 2026-10-27¶
The earlier Codex goal is paused and its wording predates the current planning-first, test-deferral and ability/stat architecture direction. It is not evidence that work is currently continuing automatically. Use this repository plan as the current work queue; a goal in another chat is a separate user-controlled choice. Keep implementation and documentation/evidence commits separate, then safely fetch and normally push checkpoints to dev-0.9.0-bootloader. Preserve unrelated edits and normal saves; no force push or unverified success claims. No numerical quota budget was supplied; account/tool limits and consequential external blockers still apply.
The owner deferred new rebinding/setup menus, four-player layout expansion and broad UI/UX redesign to the later presentation phase. Existing input/config/profile/draft/capture foundations remain useful and must be retained. They are not completed player-facing features. Do not spend the next core batches creating new menus or require a finished four-player/rebind screen before Player/movement/AbilityHolder work. Keep current one/two-player production behavior and menu layout as the compatibility baseline; use explicit development-fixture assignment through the shared roster/session APIs to prove core integration. Full four-player/remap UI/physical acceptance stays open for R7 and final qualification.
Batch 48 reproduces and repairs GAME-24's incomplete panel slide: the closed Achievements panel covered the bottom of the main menu and Settings. Canvas-relative bounds replace pixel distances; 6/6 geometry and 7/7 existing animation/pause checks pass, plus Linux IL2CPP visible regressions at 1280×720 and 960×540. This closes the scoped slide symptom, not the remaining menu migration or whole-game acceptance. Then finish only input-core prerequisites needed for production-system player assembly/dummy arena and R3 movement/capabilities. Accepted-remap persistence commands and presentation recovery policy can be completed with their actual UI consumer later; preserve the existing file safeguards meanwhile.
Progress and completion boundaries¶
December 2026 remains the owner's earlier release target; the broader rebuild has no evidence-backed completion estimate yet. Do not promise that date or silently reduce scope to fit it. Re-estimate after the design gate and first measured system slice, and report any conflict between scope, time and quota.
A smaller class is not proof of a better design. Each system must own its state, expose a clear boundary, support its actual callers and content, and have evidence of behavior. Owner instruction on 2026-10-25: preserve gameplay while rebuilding one dependency at a time. Preserve movement feel, authored values/formulas, combat/ability/reward rules and progression; any intentional rule/balance/feel change requires an explicit owner decision. Approved scope extensions are the clarified device-to-slot policy, up to four-player capacity and button remapping. Preserve the existing one/two-player mechanics as the comparison baseline; design added-player participation explicitly without silently changing balance/spawn/reward rules. The player/input contract defines baseline evidence and equivalence checks. Reuse useful current services and checks where appropriate; decide replace/retain/migrate by responsibility and evidence rather than age, file length or loyalty to recent fixes.
The prior playable repairs are reference evidence. They do not require retaining their architecture. Batch 24 is the last player-verified checkpoint for its recorded scenarios, not a complete playthrough; batch 25 is an incomplete Tutorial migration, preserved but superseded as the next task. Do not finish Tutorial-specific patches merely to close that batch. Reassess its code and checks when shared gameplay and Tutorial integration reach their proper phase. Do not discard uncommitted work as part of planning.
Owner safeguard, 2026-10-27: preserve character-specific capabilities throughout shared cleanup. Wu Ran, Tiamra and Zenova's source-backed attack routes are mandatory R3/R4 comparison cases. A held weapon may provide stats/hooks while a separate entity deals damage; null projectile/zero ammo does not by itself establish unused content. Trace all affected characters' actual consumers before changing common assembly, stats, movement, ability or life assumptions. This is a preservation constraint, not added feature scope or completed runtime acceptance.
Owner refinement, 2026-10-28: each distinct ability has its own behavior and player-specific state, joined to gameplay through documented registration contracts. Player stats and the central, explicitly named source calculations are separate responsibilities; all factors affecting a stat must remain easy to inspect in that central calculation. See the ability architecture and stat design. Plan the complete connected change before implementation. Defer tests for now as specified in the workflow below.
Later owner clarification: the next chat must first plan the full player-system overhaul, then implement it and necessary connected changes. AbilityHolder is one part of that system; include player setup/input, movement, stats, resources, damage/status/life, targeting, abilities, weapons/attacks, companions and player-facing integration. Whenever a new or better approach is found during the overhaul, present it to the owner with its reason, tradeoffs and effects, and discuss it. Obtain the owner's decision before adopting an alternative that changes an agreed design or needs their preference; continue independent work while waiting. Record accepted decisions in the existing contracts and plan. See the new-chat handoff.
The dependency-ordered execution plan is player-system-overhaul-plan.md. Its stages and bridge removal conditions supplement the detailed contracts; implementation and acceptance remain open.
Structural repair within stabilization¶
This heading remains for existing links. The active scope is a gameplay rebuild, including replacement of unsuitable ownership boundaries, player setup/input and content wiring. Existing findings still distinguish confirmed defects, risks and historical leads; maintainability work need not wait for a separately reproduced bug. The code audit records observed problems and a complete inventory, with review-depth limits.
Use a clear separation between authoring definitions, per-player/per-run state, runtime behavior and presentation. Prefer ordinary serialized references for content authoring and explicit runtime initialization for dependencies. A ScriptableObject is a useful authoring container; it does not automatically solve lifecycle, state sharing or incomplete wiring. Do not introduce a universal framework or a class for every method just to appear modular.
Dependency order and why¶
| Phase | Work and deliverable | Dependency / why later work waits | Exit evidence before dependents migrate |
|---|---|---|---|
| R0 · Core architecture pass recorded | Finish source/serialized ownership and behavior contracts, stage data/scene differences, event producers/subscribers and payloads, save/ID compatibility, content recipes and first implementation slice. | Plan the interfaces together before changing their consumers. Existing motor/input/combat contracts are design evidence, not implementation. | Each workstream has an owner, lifetime, migration/disposition map and behavior checks. Scene/event decisions and remaining save/roster semantics are explicit. |
| R1 · Minimal lifetime/scene verified | Run identity, readiness/cancellation and minimal shared host/scene now pass R1a/b checks. Keep immutable definitions/runtime separation and safe prepare/activate/reset boundaries; add required request/clock/registry/pool/event adapters with their first real owner rather than inventing empty services. The isolated launch currently has no actors/content. | Every later actor needs an owned lifetime and known dependencies. This is a minimal reusable foundation, not a framework containing all game rules. Stage definition schema is designed now; full stage loading waits for R5b. | F0 loads/resets without normal saves/network, receives complete context before activation, disposes listeners, rejects stale run callbacks and validates required bindings. No duplicate test gameplay implementation. |
| R2 · Core now; presentation later | Reusable roster/device/action/context/profile owners and production player assembly, with explicit assignment in the development arena. Retain capacity/contract for four slots; keep current one/two-player production flow. New setup/rebind menus and four-player layouts wait for R7 UI/UX. | Movement/abilities need stable identities and input APIs, not a redesigned menu. Core integration may proceed with the fixture/compatibility adapter while full F1 stays open. | Prove core sampling/isolation, lifecycle and selection-to-actor handoff before R3. Do not close four-player/remap/recovery/UI/physical acceptance without their later real consumer. |
| R3 · Player capabilities and motion | Extract Player motor, movement/dash execution, health/damage/status, stamina/regen, stats and death/revive lifecycle. Move motion/resource responsibility out of AbilityHolder as needed. | Abilities need these capabilities. Do not move dash and leave two scripts authoritative over movement/stamina. Minimal dash admission state has one owner; the richer ability runtime follows in R4a. | F2 compares original feel, formulas, timings and ordered damage/resource/status hooks. Active player slots remain isolated across death/revive/reset. |
| R4a · AbilityHolder runtime ownership | Separate each player's acquired abilities, cooldown/admission/count meters, temporary modifiers, hooks, shields and owned work from definitions, views and effect implementations. | Concrete skills should not be repeatedly rewritten around a changing AbilityHolder. Establish their runtime API after input/motor/vitals contracts, before migrating skill implementations. | Independent per-player cooldown/effect state, repeat/refresh/cancel/reset, UI-readable state and caller adapters pass the relevant comparison cases. No shared mutable Ability asset authority. |
| R4b · Targeting, weapons and attacks | Target registry/query policies, weapon cadence/ammo/reload, attack payload/attribution, projectile/carrier preparation, impact and secondary-attack routes. | Uses player capabilities, ability-state hooks and R1 lifecycle. The basic attack path is needed before complex skills, enemy combat and reward application can be evaluated. | F3 receives real attributable damage; preserves timing, hit budgets, random/proc order, target-loss and fresh/recycled payload equivalence. The passive target uses production receiver contracts. |
| R4c · Existing abilities, companions and evolution | Migrate one character's real skill/weapon path first, then each released skill/companion/evolution combination through R4a/R4b. | Skill effects now consume stable input/motion/vitals/attack owners. Keep formulas and branch order; do not implement dormant placeholders as new features. | Each released ability has a behavior/disposition record and validated content recipe. Counters, shield hooks, per-player state, repeated run and real serialized callbacks work. |
| R5a · Enemy capabilities, AI and death/drop lifecycle | Extend the passive target to one simple production enemy, then special/miniboss/boss behaviors; explicit perception, state transitions, attacks, status, registration and death/despawn/drop ownership. | The minimal receiver/lifecycle contract exists earlier. Full AI and boss migration uses actual player/combat APIs; bosses are not prerequisites for testing movement. | F4 simple enemy and representative special/boss paths behave through repeated spawn/death/despawn/reset without duplicate notifications or drops. |
| R5b · Stage data, environments and encounters | Compose stage definition + difficulty + environment/bounds/spawn markers into the shared gameplay scene; encounter schedules, boss/miniboss flow, clock/clear/reset and existing progression handoff. | Schema and scene shell come first; executing full schedules requires working enemies/combat. Inventory current scene differences before replacing the copies. | Two different existing stage configurations run sequentially through the same runtime without stale objects/listeners/settings. Authored schedules, terrain/camera/audio and stable progression/reward identities are preserved. |
| R6 · Rewards, pickups and progression | Eligibility/rolls, queue, per-player selection/confirmation, upgrade application, XP/stats/results and compatibility adapters. | Depends on roster, stage eligibility and stable ability/stat APIs. The owner confirmed shared distinct choices and max(existing count, living participants+1) cards. Scarce-offer fallback, mastery/payout and recovery semantics must be specified; card redesign is deferred. | F5 verifies level/chest/boss/repeated/queued rewards apply once to the intended player; mutable taken counts stay out of definitions; next run resets. |
| R7 · Production UI, saves, audio and services | Implement deferred setup/rebinding/four-player layouts and agreed UI/UX work against the completed runtime owners. Complete menu/HUD/settings/results and persistence/migration/audio/achievement/optional-service integration against the new owners. Remove corresponding GameManager/GameMenuManager authority. | Minimal HUD/input/settings/save adapters ship with earlier slices when required. Full integration now has stable runtime data/events; presentation must not own combat or pairing. | Current/legacy/malformed disposable saves, independent UI/pause/result timing and optional-service failures pass; production flows use the same owners as the fixture. |
| R8 · Tutorial and remaining content migration | Reuse shared player/input/combat/enemy/stage contracts for lessons; finish all released character/stage/prefab/scene bindings and retire verified duplicate paths. | Tutorial consumes these systems. Keep lesson orchestration only; migrate representative content earlier, then finish coverage. Do not delete old arenas before their behavior/content is accounted for. | Tutorial and released content support complete runs, clear/death/revive/retry/return; old scripts/scenes retire only after all callers and content pass. |
| R9 · Profile and qualify | Measure representative dense workloads, optimize demonstrated costs, remove remaining bridges and verify Windows IL2CPP/Steam source/build identity. | Correct ownership comes first; dense-workload optimizations require the resulting implementation. Preserve baseline measurements and address directly relevant waste during each slice. | Measured frame/allocation/lifecycle evidence, release provenance and target-platform acceptance. GAME-01 risk returns to the owner before release sign-off. |
The execution hierarchy is run/data/lifetime + minimal events/shared scene → player setup/input → movement/vitals/stats → ability runtime → weapon/attack execution → concrete skills → enemies → encounters/stages → rewards → full UI/services → Tutorial/content completion → measured optimization/release. These are dependencies, not an effort ranking. Inspect the source dependency before extracting a leaf method: if it writes another owner's state, establish that owner/API first.
AbilityHolder and Player are split by responsibility rather than replacing one giant script completely in isolation. Input sampling is upstream of the motor; dash motion/stamina use the player capabilities; ability admission/cooldowns own action state; skill effects consume those capabilities. This avoids the cycle in which movement waits for the whole ability catalog while abilities wait for movement. Event payload/lifetime rules and definition/save identities are designed in R0/R1, with concrete notifications and adapters added beside each owner. No global event rewrite or full stage conversion precedes the minimum player test loop.
Batch 59's ability-module design records the broader source paths. The owner now prioritizes planning the complete connected rework before implementation: ability modules, dash registration, cooldowns, assets, stats, damage, weapons, attacks and character-specific interactions. The hook and cooldown contract applies to each affected caller/ability migration. Unmigrated named perk adapters stay pending. No new skill or balance change is included.
R1a/b now verify the minimal shared lifetime/scene. R2a now verifies slot/device ownership and the pinned SDK; action/session/context/profile and actor integration follow within R2. Full environment/encounter composition waits for R5b; existing scene copies are retired only after their content migrates. A small passive target exists earlier than enemy AI. Record interface/authoring and behavior comparisons needed for each slice; the owner's current workflow defers executing tests. New source dependencies may refine this order; record the reason.
Design gate before implementation¶
Batch 34 reconciles the core architecture pass and admits only the first R1a lifecycle slice next. These checks refer to planning coverage and explicit gates, not completed implementation or deep semantic review of every file.
- [x] Whole-project inventory is current and every file belongs to a workstream; focused source review versus inventory-only coverage remains marked.
- [x] Core workstreams have owners/dispositions and source/caller/binding maps; unreviewed secondary APIs and imported overrides have an affected-phase investigation gate.
- [x] Player/roster/device/input, run lifetime and definition/runtime/profile/presentation boundaries are written down. R1a does not implement or resolve later participation rules.
- [x] Dummy-stage F0–F5 milestones and character/enemy/stage authoring standards have explicit acceptance; no empty-arena or test-double gameplay claim.
- [x] Save identity, legacy input conversion, logical remap schema and asset compatibility are specified. Concrete package serialization, IO recovery and platform evidence remain required before affected writes/migrations. No shipped Steam baseline is fabricated.
- [x] Shared-scene/environment and scoped-event boundaries, existing scene differences and migration follow-ups are mapped. Imported content and event consumers still require their own slice verification.
- [x] The first implementation slice has exact files/new metadata, dependencies, production isolation, rollback and pass/fail checks. The larger rebuild retains its ordered phases.
The gate register records seven planning conclusions, all 27 named PC/CA/SE/RP/PS follow-ups, nine passed R1a groups, seven passed R1b groups and nine passed R2a groups (the latter use simulated SDK devices). No open gameplay/content decision is needed by R1a's isolated lifetime core. This is permission to begin that narrow slice within the owner's existing rebuild scope, not a blanket pass for R2–R9. Expand a slice only after its callers/bindings, compatibility and behavior choices are resolved. Do not restart a general inventory or claim every future API/import decision is finished.
Dummy stage and content standard¶
The shared-scene direction is IDEA-20; the dummy arena is a development configuration of that runtime, with any development-only launcher/config excluded from production. Do not copy a second gameplay-manager hierarchy for tests. The fixture and authoring contracts are specified in the code audit. Create the fixture only after R0. Use the same production player, damage, spawn and state boundaries; no second hard-coded test player. Begin with a passive damageable target and add a simple enemy as its contracts mature. Development controls may reset/spawn/grant an existing upgrade for testing; they must not become public progression, cheats or submitted runs.
Issue routing¶
Issue severity is retained in the register. This table routes findings into the rebuild; effort alone no longer determines implementation order. Existing verified fixes remain evidence, and unresolved risks remain unresolved until tested.
| Workstream | Existing issue IDs | Treatment |
|---|---|---|
| Shared contracts/lifecycle | ARCH-01, GAME-08, GAME-10 | Whole cleanup ownership, pooling and definition/runtime separation. |
| Player setup/input | GAME-16, GAME-17, GAME-21 | Preserve useful selection/entry evidence while migrating its runtime boundary. |
| Combat/abilities | GAME-11, CONTENT-05 | Inventory released behavior and incomplete implementations before migration. |
| Stage/enemy systems | GAME-06, GAME-14, GAME-15, CONTENT-01, CONTENT-02 | Spawn/event identity, stage routing, catalogs and intended release reachability. |
| Reward/progression | GAME-02, GAME-04, GAME-07, GAME-09, GAME-25, CONTENT-07 | Preserve fixed behavior and cover active-player/queue/reset cases on the new model. |
| UI/scene integration | GAME-12, GAME-13, GAME-18, GAME-19, GAME-20, GAME-22, GAME-23, GAME-24, CONTENT-08 | Existing menu/startup/Tutorial/database evidence; migrate consumers after shared systems. |
| Persistence/audio/services | GAME-03, SAVE-01, SAVE-02, SAVE-03, SAVE-04, SAVE-05, SAVE-06, NET-01, NET-02, CONTENT-03, CONTENT-04, CONTENT-09 | Design compatibility early, implement adapters with owners, complete external validation later. |
| Profiling/release/tooling | PERF-01, PERF-02, PERF-03, PERF-04, REL-01, REL-02, REL-03, TOOL-01, TOOL-02, TOOL-03 | Preserve measurements/tooling limitations and complete target-platform acceptance. |
| Disproven concerns | GAME-05, CONTENT-06 | No speculative rename/material replacement; revisit only if new evidence contradicts prior checks. |
| Owner-deferred | GAME-01 | No dedicated freeze investigation/fixes until resumed. |
All 53 current findings are routed once above. The broader rebuild is tracked through ARCH-01 and workstream contracts; avoid creating a duplicate defect for every extraction or inventory row.
Quota and batch discipline¶
Owner update, 2026-10-28: focus on planning the complete player-system and connected-system overhaul before implementation, including AbilityHolder as one part. Map player assembly/input, movement, stats/resources, life/damage/status, abilities/hooks, cooldowns, assets, attacks and character-specific paths together. After planning, work through the larger rework without running tests for now. Compilation is separate from gameplay testing; report whether it was run rather than treating it as gameplay verification. Record changes as implemented but unverified, and preserve separate, clearly labelled implementation commits and documentation history. Previous test results apply only to their recorded revisions and scopes. Return to focused regression and full gameplay/platform qualification when verification resumes; do not claim playability or close acceptance gates until then. This supersedes the test cadence and commit prerequisites below, which remain as historical workflow context.
Owner workflow clarification, 2026-10-27: work through the remaining cleanup list in larger, dependency-ordered groups. Use lightweight checks while implementing; defer repeated full builds, desktop control and hands-on playthroughs to the integration campaign after the cleanup and existing-content wiring. This supersedes the earlier small-batch/full-verification cadence. Preserve gameplay and the dependency order; the request does not authorize new balance rules or deferred features.
| Implementation group | Work in order | Checks during implementation |
|---|---|---|
| Player foundation · R3 | Finish motion consumers, then health/damage/status, stamina/regen, stats, death/revive and minimum dash admission/execution. | Compile changed assemblies; compare affected formulas, ordering, lifecycle and player isolation with focused automated checks. |
| Abilities and combat · R4a–R4c | Establish AbilityHolder ownership, then damage/target/weapon boundaries and representative skills before migrating remaining skills. | Compile and exercise affected cooldowns, hooks, attack/damage routes and lifecycle in the production-system arena. Reuse unchanged movement/input evidence. |
| Enemies, stages and rewards · R5–R6 | Enemy lifecycle and spawning, shared stage composition, then rewards/pickups/progression using their new owners. | Compile and check affected spawn/reset, stage data, reward admission and persistence boundaries without a full player build for each extraction. |
| Existing-content integration · R7–R9 | Migrate released content and existing menus/HUD, services, audio and Tutorial; remove obsolete authoritative paths and validate authoring. New UI/redesign and other owner-deferred scope remain separate. | Compile, validate serialized references/data and run focused integration checks as consumers become available. Record untested runtime flows explicitly. |
| Integration campaign | Exercise the connected game after the above implementation and wiring, fix observed regressions, then qualify the release candidate. | Build Linux once per candidate and perform full menu-to-run, co-op, combat, rewards, death/revive, stage/result/retry and save/reload sweeps. Physical-device and Windows IL2CPP/Steam checks remain external acceptance gates. |
A group may contain several independently reviewable implementation commits. Commit at a meaningful responsibility boundary after compilation and relevant focused checks; a commit does not require a native build, a full test suite or a documentation report for each method. Keep documentation/evidence commits separate and consolidate their updates at group checkpoints. Continue to fetch/reconcile safely and normally push reviewed checkpoints. Reuse existing contracts and passing evidence; do not restart the general audit or build speculative infrastructure. No numerical quota/token budget was supplied.
Keep three states distinct in progress reports: implemented, focused checks passed, and full integration verified. Do not close a runtime acceptance gate from compilation or a dummy fixture alone. Fix compilation failures and blocking contract/lifecycle problems before building dependents on them. A concrete destructive save migration or other high-impact change can justify an earlier targeted runtime check; explain that specific reason instead of automatically repeating full control tests. Discover and repair issues encountered in changed code within the current group's scope, with evidence proportionate to the change.
Preserve normal saves, unrelated dirty files, unresolved audio deletion, archived Plastic evidence, preexisting generated assets and local Git recovery backups. The owner-requested GitHub Desktop lock repair is recorded in status; do not treat the archived lock as a current live blocker. On 2026-10-26 the owner also approved removing/ignoring the unused root .plastic metadata; do not restore it as an unresolved deletion. Its remaining local files were archived under .git/codex-recovery/. Capture pre-run bytes before Unity; restore only reviewed probe-generated changes. The owner requires separate documentation and implementation commits: checkpoint reviewed plans before runtime work, then keep code and evidence/documentation updates distinct. The owner now authorizes independently reviewable implementation commits with lightweight verification, with documentation/evidence committed separately at group checkpoints. Standing owner authorization now covers normal pushes to the existing development branch after verified checkpoints; do not include unrelated package upgrades, broad asset reserialization or mass deletion.
Starting or continuing a session¶
- Read applicable AGENTS instructions, status, this plan, the relevant audit/contract and issue entries. Confirm actual branch/HEAD, dirty files and any live tool processes. Do not restart an interrupted process without checking its authoritative handle/state.
- Follow the current dependency phase. Batch 34 closes the core architecture pass for R1a; batch 35 now verifies that isolated lifetime core (9/9 Editor checks). No existing gameplay is integrated onto it yet. The player/input contract and shared run/bootstrap contract record the first boundaries and maps. Batch 28 records player motor/vitals/stats ownership; batch 29 records combat/weapon/targeting/ability-state ownership, with authored routes, caller/binding/event maps and source-derived comparison cases. Batch 30 adds shared gameplay-scene/event scope and refines the implementation hierarchy. Batch 31 records the stage/enemy/encounter/event contract, with scene/data/state/event maps and authoring recipes. Batch 32 records the reward/pickup/progression contract, including the owner-confirmed shared/distinct N+1 card rule and remaining payout/scarcity/recovery decisions. Batch 33 records the persistence/input preferences/UI/service integration contract, with actual storage/schema/preset/lifetime and adapter maps. Batch 34 now records the R1a lifecycle slice and phase gate register. Batch 35 implements/verifies that exact lifetime slice. Batch 36 now verifies the scene/host/development entry (7/7 import/PlayMode groups). Batch 37 now verifies the first R2 roster/device/package slice. Batch 38 verifies action/session/context ownership and batch 39 verifies in-memory binding profiles/legacy conversion. Batch 40 verifies blocked-session application and reversible drafts. Batch 41 verifies device-owned capture. Batch 42 verifies that document/file adapter on disposable Linux paths. Batch 43 implements the control-preset slice; batch 44 separates audio/locale loaded application; batch 45 wires the production config owner; built-player validation and recovery/UI rollout remain, retaining Windows/recovery, input compatibility and actor gates. Do not resume batch 25's Tutorial verification as the default next action.
- Before implementing, use the existing contracts to choose the next dependency-owned system group. Trace affected code and all scene/prefab/data bindings; identify compatibility bridges and the condition for removing them.
- Compile and check affected behavior with focused automated checks and the development arena; reserve the full build/control sweep for the integration campaign. Migrate real callers/content before declaring a system complete. Fixtures or a compiling package alone do not establish real player/controller behavior.
- At group checkpoints, update the existing audit/contract, issue evidence and verification record. State what is implemented, focused-checked and still integration-pending; commit code/evidence separately, normally push the checkpoint, and continue in dependency order. Do not mark the overall goal complete before integration acceptance. Ask only for consequential missing behavior/access, not routine implementation choices.
Current batch¶
Batch 46 builds the batch-45 wiring into a Linux IL2CPP player at df212c83, exit0, without implementation changes. Two recorded interactive runs verify actual Settings volume save, exact original backup, natural quit, restart/restored UI value and byte-preserved config during startup/Settings opening. Four scoped startup probes accept supported current/custom-remap and legacy files without writes, and reject corrupt/future data without replacing it or completing startup. They are deliberately stopped after data assertions, not counted as natural menu-flow passes.
Native custom-remap/legacy interactive edits remain unverified: the extra custom-profile UI attempt reached another tab and did not edit the slider. Harness focus/geometry/capture and startup-prompt timing mistakes are excluded, not called game defects. All 7,743 captured project files and normal game-profile bytes match after reviewed generated cleanup. No full gameplay, Windows, physical-device, audio-output or freeze-resolution claim. Batch 45's 44 Editor groups are reused because implementation is unchanged. This batch records documentation/evidence only; no push. All 27 workstream follow-ups remain open.
Before batch 29, the owner requested a commit. Local checkpoint 93d92282 on codex/checkpoint-stabilization-and-r0-20261026 saves 114 reviewed files through batch 28, including the parked Tutorial changes. The branch/index and nonempty lock were initially left intact. The owner subsequently requested GitHub Desktop recovery; local branch/index alignment and preserved recovery data are recorded in status. That checkpoint was initially local only. The owner subsequently requested publication to the existing remote development branch, including the following batch-29 documentation checkpoint; see status.
Batch 30 adds the owner's shared-scene and event-bus planning directions and makes R4a/R4b/R4c and R5a/R5b dependencies explicit. It does not implement Player, AbilityHolder, input, a new bus or a unified scene.
Next group: R3 player capability ownership¶
The panel repair remains verified in batch 48. Batches 49/50 supply explicit character preparation and owned actor lifetime; batch 51 supplies immutable original keyboard/motor observations. Batch 52 now extracts PlayerMotor, forwards the production facade through it and activates the same motor from assigned input in the shared scene. Session-owned keyboard history continues without actors and through blocked contexts; the local Linux SDL gamepad rescale is measured. Real physics/animation, pause/retry/reload and independent keyboard/pad checks pass. The existing native two-player run also moves, selects distinct rewards, resumes and returns/quits normally.
This is partial R3, not full F1/F2 or a completed combat arena. Legacy Player/AbilityHolder/weapon/collector behaviours remain disabled; assigned movement/dash and the required stamina/immunity rules now run explicitly. Batch 53 now shares unchanged screen-limit/overlap calculations and binds the prepared actor to its run camera and one callback owner. Ten boundary and ten motor groups pass headlessly; full native integration of this change is pending. Target-facing remains a facade consumer. Batch 54 now separates stat projection and stamina/health-cap/immunity rules, with 217 original stat cases, 14 setup cases and six resource groups passing headlessly. Public serialized state and mutation callers remain in compatibility facades; this is not complete vitals/stat authority migration or active combat in the shared arena. Batch 55 adds the ordered damage resolver/legacy effect adapter and player-owned death/revive sequence; the revive upgrade calls that boundary. Original damage/status and inactive-object revive comparisons plus pipeline/callback checks pass headlessly. Existing effect services, live activation/cancellation, joined-slot participation and full run life registration remain open. Batch 56 adds actor-owned dash execution and shared Entity status rules, preserving 70 original dash and 14 status cases. Execution epochs retire old dash completions; a reproduced stale-freeze-after-reset mutation is guarded. Legacy perk/services and shared ability cooldown state remain adapters. Batch 57 establishes the required R4a ownership prerequisite before that composition: opt-in per-player ability copies, admission/display clocks and actor/run-owned work. Sixteen original clock traces, 14 ownership groups, real shared-scene handoffs/release and launcher retry/disposal pass headlessly. Default production ability ownership remains legacy. Batch 58 now consumes one command frame for movement and owned dash, injects character/pause/feedback/effect adapters and ticks the existing stamina/immunity rules. Fifteen assigned-input/lifecycle groups pass, including all seven character costs/impulses; the 70 original dash and 14 status cases still match. Plan the full connected rework before implementation; include dash registration, owned activation/cooldown admission and real ability modules alongside remaining R3 simulation and lifecycle composition: health recovery, stat mutation callers, status/damage dependencies and explicit joined-player death/revive/run participation. Remaining ability counters/shields, concrete effect bodies and their global workers still require migration before broad combat activation. Finish actor/run participation and remaining state/caller migration using the lightweight workflow; this does not close R3/F2 or ability/combat acceptance. Preserve character-specific live stat and hook consumers. Preserve original incoming-damage/status/resource/death/revive ordering and time-varying stat formulas before moving their callers. Minimum dash execution/admission must use those owners; do not enable the full old AbilityHolder/GameManager chain to make the fixture fight. Add a real production-contract damage receiver when R4b is ready, then migrate representative attacks and abilities before broad content.
Sampling comparisons cover default WASD and one Linux OS-backed virtual-pad path. Inputs held before a brand-new input owner exists, rebind-history/focus policy, other physical backends and Windows remain acceptance work. Keep input identity/history separate from actor lifetime and read command edges once; later capabilities consume the driver snapshot rather than polling it again. New setup/rebind/four-player UI and recovery/layout rollout remain in R7. Their deferral does not close acceptance.
Follow the current workflow above across groups. Tests are deferred for now; report compilation separately if performed and mark untested implementation as unverified. Consolidate separate documentation updates, fetch/reconcile safely and normally push authorized checkpoints. Respect an explicit goal pause. Never force push or overwrite unrelated work. Physical devices/Windows that require the owner's hardware remain explicit external gates. Dedicated GAME-01 work and unrelated features remain deferred.
Candidate release acceptance¶
The rebuilt architecture is complete only when the supported game also works on it. Acceptance is not a claim of zero undiscovered bugs.
- [ ] Core ownership/data contracts are implemented; duplicate authoritative input/state paths and temporary migration bridges have supported dispositions.
- [ ] Character/enemy/stage authoring follows documented required components/data and validation; the development arena uses production code and stays outside shipped catalogs/progression.
- [ ] Input System migration is complete for supported consumers: P1 keyboard-or-pad, P2–P4 pad-only, exclusive device assignment, keyboard/gamepad remapping and recovery, per-profile persistence, UI/reward contexts and reconnect; no abandoned legacy input path.
- [ ] Existing released characters, abilities, enemies, stages, tutorial, menus/HUD/audio and progression are migrated and verified end to end, including repeated runs and one-to-four-player co-op. Existing one/two-player behavior is the equivalence baseline; additional-player reward participation must be specified rather than guessed.
- [ ] Fresh/current/legacy/malformed saves preserve supported currencies, unlocks, counters and settings; optional services cannot block local gameplay/results.
- [ ] Dense gameplay has representative profiling evidence and resulting optimization checks.
- [ ] Source/build provenance, intentional version metadata and production Windows IL2CPP/Steam validation are recorded; Linux checks alone are insufficient.
- [ ] Every issue and inventory workstream has a supported disposition; outstanding limits require an explicit owner decision. Revisit deferred GAME-01 risk before release sign-off.