3.3 KiB
Aetherbound Guild Post-P9.1 Development Roadmap
This roadmap is sequencing authority after the bounded P9.1 first-session slice. Only the active step may be implemented at a time.
Product Direction
Deliver a readable landscape mobile incremental tactics game in which the player selects a small Guild, watches each profession perform a legible action, makes state-dependent decisions between expeditions, automates solved labor, and starts the next cycle with a changed Guild and route situation.
P9.1 proves the first-session presentation and touch chain. It is not the full game: combat, economy, save, content scale, audio and release are deliberately separate milestones.
Ordered Milestones
| Milestone | Player-visible stopping point | Main work | Exit evidence |
|---|---|---|---|
| P9.1-S5 | Private H5 opens the exact accepted first-session source. | Runtime-only export, stable private URL and honest delivery record. | Export inventory, local/remote checks, clean pushed docs. |
| P9.1-S6 | Owner completes one uncoached Title -> five battles -> result -> Restart playthrough. | Collect comprehension/fun/visual/audio observations and make at most one ranked repair batch. | Owner notes; affected runtime checks; one new H5 only if code changed. |
| P9.2 | A second cycle has a real state-dependent choice and a readable consequence. | Freeze the first-session UX, then add one authoritative combat/failure/recovery slice. | Domain, five-profile simulation, save boundary and runtime decision evidence. |
| P9.3 | A run survives interruption and resumes truthfully. | Versioned save, migration, corruption, duplicate-claim, clock rollback and bounded offline rules. | Persistence matrix plus interrupted mobile runtime evidence. |
| P9.4 | The Guild can grow without hard-coded pair branches. | Data-driven professions, enemies, equipment, recruit generation and chapter authoring. | Schema validation, content coverage, balance counterfactuals and representative runtime. |
| P9.5 | The game is ready for device and release evaluation. | Final art/audio pass, performance, iOS/Android device delivery and packaging. | Device evidence, signed build, store processing and Owner release decision. |
Immediate Execution
The current implementation plan is docs/runtime/p9_1/IMPLEMENTATION_PLAN.md.
The only active work before Owner feedback is:
- Finish and record P9.1-S5 H5 delivery.
- Stop and wait for one uncoached Owner playthrough.
- Convert the Owner's observations into a ranked issue register.
- Implement only the highest-impact bounded repair, if needed.
- Re-run the affected P9.1 checks, push, and republish the H5 only when the repair changes the source.
No P9.2 implementation starts before this sequence is closed. No packaging or TestFlight work is implied by a green P9.1 runtime check.
Decision Gates For Future Work
Do not advance a milestone unless the current build demonstrates:
- a manual action with immediate visible/audio result;
- an automation transition that removes solved labor rather than only adding a multiplier;
- a readable bottleneck and at least two rational responses whose value changes with state;
- a persistent transformation that changes the next cycle;
- five pacing profiles, save/interruption boundaries and actual mobile input;
- a human-readable result naming what happened, why and what to do next.