178 lines
11 KiB
Markdown
178 lines
11 KiB
Markdown
# P9.1 Five-Battle First-Session Implementation Plan
|
|
|
|
> Status: `OWNER_REVIEW_DEFERRED`
|
|
> Active step: `NONE`
|
|
> Active source baseline: `cca5eae6247f37dc4ee51770819adb6ddfc51cc5`
|
|
> Goal: `docs/goals/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_GOAL.md`
|
|
> Contract: `docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md`
|
|
> Evidence ledger: `docs/reviews/PHASE9_GODOT_VERTICAL_SLICE_LEDGER.md`
|
|
> Process protocol: `docs/runtime/PLAN_DRIVEN_DEVELOPMENT_PROTOCOL.md`
|
|
> Post-milestone roadmap: `docs/runtime/p9_1/POST_P9_1_ROADMAP.md`
|
|
|
|
## 1. Player-Visible Stopping Point
|
|
|
|
P9.1 ends when the owner can open one landscape H5 build and complete this
|
|
unbroken first session:
|
|
|
|
```text
|
|
Title -> Main Menu -> New Game -> choose any two Recruits
|
|
-> automatic formation -> battle 1 -> choose one adaptation
|
|
-> battle 2 -> choose one Guild response -> battle 3
|
|
-> choose and review one route -> battle 4
|
|
-> choose and review one current member for Lv.2 -> battle 5
|
|
-> first-session result -> restart or Home
|
|
```
|
|
|
|
The player must be able to explain who acted, what changed, why each choice was
|
|
rational, and how the final result followed from the four decisions. P9.1 is
|
|
not complete merely because the domain matrix or old preview pages pass.
|
|
|
|
The milestone stops after one owner playthrough and one bounded repair round.
|
|
It does not continue into chapter production.
|
|
|
|
## 2. Current Reality
|
|
|
|
### Complete and pushed
|
|
|
|
- Front door: Boot, Title, Main Menu, Introduction and Settings.
|
|
- Any two of four current Recruits can be selected; the system assigns order.
|
|
- Five deterministic battles and four intervening decisions exist in the
|
|
domain layer.
|
|
- Guild addition performs real automatic re-formation.
|
|
- Member HP, member levels, battle times, Coin and result identity are tracked
|
|
by stable member ID.
|
|
- The source at `8cfbc14` passes a 180-path matrix across six pairs, two
|
|
adaptations, two Guild responses, three routes and every current growth
|
|
candidate. It also preserves the declared P9.0 focused regressions.
|
|
- The source at `bbad4e2` renders Guild re-formation, battles 3-5, route,
|
|
training and result pages from current `field_order`; its exceptional
|
|
`Farstring + Kindhand -> add Hearthguard` path displays
|
|
`Hearthguard -> Farstring -> Kindhand` consistently.
|
|
- The source at `08fd15c` gives all four decision pages the same reason/gain/
|
|
cost/foregone grammar and all five result pages the same five labeled lines;
|
|
it passes Chinese/English 130% comprehension and 844x390 bounds checks.
|
|
- The source at `ef45f2a` binds every battle feedback payload to encounter,
|
|
source member, target member, cue and VFX, including third-position recoil;
|
|
it passes the Step 3 battle continuity marker and 10 strict-clean regressions.
|
|
- The source at `cca5eae` passes the complete first-session runtime marker with
|
|
five pacing profiles, 190 parsed ScreenTouch, five parsed ScreenDrag, zero
|
|
fallback/direct input, restart cleanup, three layout fixtures and strict
|
|
diagnostics zero. A normal `844x390` recording also passes with five
|
|
source-bound result captures.
|
|
|
|
### Not complete
|
|
|
|
- The Owner has not yet completed the delivered five-battle H5 without
|
|
coaching.
|
|
- Human understanding, fun, listening and willingness to continue remain open.
|
|
- The roughly 55 MB uncompressed Web payload has a multi-minute cold-start
|
|
limitation; this is recorded honestly and is not a gameplay PASS or FAIL.
|
|
|
|
## 3. Frozen Scope
|
|
|
|
P9.1 must not add or redesign:
|
|
|
|
- authoritative combat, difficulty or economy;
|
|
- save/load, offline progress, casualty or recovery;
|
|
- Market, permanent inventory, promotion or levels above this bounded Lv.2;
|
|
- more professions, enemies, equipment, regions or chapters;
|
|
- bulk/final art, generated audio, packaging, TestFlight, stores or release.
|
|
|
|
Findings in these areas go into the issue register or the next milestone. They
|
|
do not expand the active P9.1 step.
|
|
|
|
## 4. Execution Rules
|
|
|
|
1. Exactly one step below is `IN_PROGRESS`.
|
|
2. Before editing, identify the current step's owned files and acceptance
|
|
checks. Do not edit a later step's files speculatively.
|
|
3. Run focused checks first. Run the declared regression set only after the
|
|
focused boundary passes.
|
|
4. Each completed step gets a focused commit and push. The plan and checkpoint
|
|
are updated in the same commit only when their status actually changes.
|
|
5. A failed check keeps the current step active. Record the earliest boundary
|
|
in the issue register and repair it before advancing.
|
|
6. Do not describe a step as complete until `HEAD == upstream`, the worktree is
|
|
clean and no owned Godot process remains.
|
|
7. Deployment begins only after Steps 1-4 are complete. Packaging is not part
|
|
of this plan.
|
|
|
|
## 5. Ordered Delivery Plan
|
|
|
|
| Step | Status | Player outcome | Required verification | Commit boundary |
|
|
|---|---|---|---|---|
|
|
| P9.1-STEP-0 Domain five-battle foundation | `COMPLETE` | Every legal party/decision path reaches a truthful final snapshot. | 180 paths; exact HP/Coin/time/order/levels/actions; foundation atomicity; P9.0 focused regressions. | Pushed `8cfbc14`. |
|
|
| P9.1-STEP-1 Real formation UI | `COMPLETE` | Guild re-formation immediately and consistently shows the actual lead, second and third members. No actor, health bar, action caption, feedback or training card refers to the wrong person. | `ABG_P9_1_REAL_FORMATION_UI_OK`; 180-path domain and 13 affected P9.0/P9.1 regressions strict-clean; five normal-render 844x390 states strict-clean. | Pushed `bbad4e2`. |
|
|
| P9.1-STEP-2 Decision and result comprehension | `COMPLETE` | Adaptation, Guild, route and growth pages open unselected, show exact gain/cost/foregone state, and all five results use outcome/cause/difference/change/next-action order in Chinese and English. | `ABG_P9_1_DECISION_RESULT_COMPREHENSION_OK`; 17 strict-clean domain/touch regressions; six 844x390 zh/en-130% frames with no overlap or clipping. | Pushed `08fd15c`. |
|
|
| P9.1-STEP-3 Battle readability and continuity | `COMPLETE` | Battles 1-5 visibly show approach, pressure, each profession's one action, damage/heal numbers, defeat and victory without identity swaps or dead time. | `ABG_P9_1_BATTLE_READABILITY_CONTINUITY_OK`; 10 strict-clean regressions; four normal-render 844x390 frames with no overlap. | Pushed `ef45f2a`. |
|
|
| P9.1-STEP-4 Full first-session runtime gate | `COMPLETE` | A player can use real touch from Title to final result and restart without hidden helper calls. | `ABG_P9_1_FULL_FIRST_SESSION_RUNTIME_OK profiles=5 touch=190 drag=5 fallback=0 direct=0`; max decision gap `1.09s`; three layout fixtures; strict scan zero; normal 844x390 recording marker and five captures. | Pushed `cca5eae`. |
|
|
| P9.1-STEP-5 H5 owner delivery | `COMPLETE` | The exact accepted source is available through one stable landscape mobile URL. Refresh starts cleanly and Restart is visible. | Runtime-only Web export; local/remote bytes, MIME, CSP and health recorded in `H5_DELIVERY.md`; cold-start limitation reported honestly. | Documentation closure pushed with `H5_DELIVERY.md`. |
|
|
| P9.1-STEP-6 Owner play and bounded repair | `PENDING` | Owner completes one uncoached first session and reports whether formation, decisions, battles and result are understandable and worth continuing. | Owner observations; one ranked repair batch; rerun affected Step 4 checks; republish only if code changed. | Deferred by Owner continuation instruction; human gates remain open. |
|
|
|
|
## 6. Current Step Contract
|
|
|
|
### P9.1-STEP-6 OWNER_PLAY_AND_BOUNDED_REPAIR
|
|
|
|
Current owned issue register and play report:
|
|
|
|
```text
|
|
docs/runtime/p9_1/OWNER_PLAY_REPORT.md
|
|
```
|
|
|
|
No product file may be edited before the Owner reports the first confusion or
|
|
choice-quality problem. Any repair must name its exact source file before edit.
|
|
|
|
Required behavior:
|
|
|
|
- Give the Owner the current signed private H5 URL without coaching the route.
|
|
- Record the first confusion, pointless choice, unreadable battle event and
|
|
unclear result or next action in `OWNER_PLAY_REPORT.md`.
|
|
- Rank at most three findings by first-play impact. One repair batch may own
|
|
only the highest-impact bounded boundary.
|
|
- If code changes, rerun the affected Step 4 focused and runtime checks, commit,
|
|
push and republish the source-bound H5. If no code changes, close P9.1 with
|
|
the actual Owner gate result.
|
|
|
|
Step 6 is complete only after one uncoached Owner playthrough, one ranked issue
|
|
list, and at most one bounded repair batch with focused rerun evidence. If no
|
|
repair is needed, close the milestone with the Owner's acceptance or explicit
|
|
open gates.
|
|
|
|
## 7. Known Issue Register
|
|
|
|
| ID | Status | Boundary | Disposition |
|
|
|---|---|---|---|
|
|
| P91-I01 | `RESOLVED` | Later UI displayed stale historical slots after Guild re-formation. | Step 1 source `bbad4e2` uses current `field_order` and stable member IDs across preview, battle, route, training and results. |
|
|
| P91-I02 | `RESOLVED` | Later decision/result copy used legacy front/rear language and incomplete causal grammar. | Step 2 source `08fd15c` uses stable five-line result labels and four-row option consequences in both locales. |
|
|
| P91-I06 | `RESOLVED` | Battle 3-5 event text and animation cadence still need one source-bound continuity check across re-formed parties and accessibility variants. | Step 3 source `ef45f2a` binds identity, cue, VFX and third-position recoil; focused marker and normal frames pass. |
|
|
| P91-I03 | `RESOLVED` | No complete Title-to-final parsed-touch path on the new five-battle domain. | Step 4 source `cca5eae` passes five profiles, 190 Touch, five Drag, fallback/direct zero, restart cleanup and strict diagnostics. |
|
|
| P91-I04 | `RECORDED` | Godot 4.6.1 Dummy-audio touch runs can intermittently emit exit-only ObjectDB cleanup warnings while functional markers pass; audio lifecycle focused test passes. | Step 4's authoritative run is strict-clean. Preserve the historical limitation without reopening product audio in Step 6. |
|
|
| P91-I05 | `OPEN` | Existing Web payload is large and cold loading is slow. | Step 5 delivery optimization only; it must not change gameplay. |
|
|
|
|
## 8. P9.1 Completion Checklist
|
|
|
|
P9.1 may be closed only when all are true:
|
|
|
|
- Steps 0-6 are `COMPLETE`.
|
|
- One exact pushed source revision owns the latest H5 delivery.
|
|
- The first session is playable from Title through final result and Restart.
|
|
- No visible party member, action, HP, level, reward or result contradicts the
|
|
domain snapshot.
|
|
- Automated, runtime, agent visual and machine audio evidence are reported at
|
|
their actual levels.
|
|
- Owner understanding/fun/listening are recorded only from owner evidence.
|
|
- The repository is clean/upstream and no owned process remains.
|
|
|
|
Anything beyond this checklist begins a new milestone plan rather than silently
|
|
extending P9.1.
|
|
|
|
## 9. Next Milestones After P9.1
|
|
|
|
These are sequencing notes, not current authorization:
|
|
|
|
- P9.2: one owner-driven comprehension/feel repair milestone if more than the
|
|
bounded Step 6 batch is required.
|
|
- P9.3: authoritative combat, failure/recovery and persistence vertical slice.
|
|
- P9.4: scalable profession/enemy/equipment authoring and chapter production.
|
|
- P9.5: final presentation, device performance, packaging and release gates.
|