docs(p9.1): freeze implementation contract

This commit is contained in:
2026-08-13 09:25:02 +08:00
parent 7bc871d08b
commit ed4a9fac8b
5 changed files with 371 additions and 28 deletions
+6 -4
View File
@@ -20,13 +20,14 @@ Phase 8 产品设计已建立;Phase 9 正在用 Godot 逐模块实现。P9.0R1
|---|---|
| 批次 | `abg-p9-1-continuous-development-01` |
| Agent TaskGraph 协议版本 | 0.8.0-beta.12 |
| Source baseline | READY: `/Users/wusumac/Documents/game/aetherbound_guild` at `dec9574405043624acee0f4f81963d829e8d40e9`, branch `main`, clean/upstream at batch freeze |
| Frozen spec | `.agent-taskgraph/spec.md` revision `p9.1-spec-r1` |
| 当前阶段 | 先并行规格,汇合后再并行实现 |
| Source baseline | READY: accepted product `41204acafa911a505f5b24a493aa032983e706d1`; PMO specification integration starts from clean/upstream `7bc871d` |
| Frozen spec | `.agent-taskgraph/spec.md` revision `p9.1-spec-r2`; implementation contract `p9.1-contract-r1` |
| 当前阶段 | 三份规格已汇合;下一阶段为独占 foundation 与并行代表性视觉切片 |
| 最大同时工作会话 | 3 个 worker;PMO 独立监督 |
| Owner 授权 | 2026-08-13:使用 agent graph,并行安排策划、技术架构、设计师和多个开发 |
| Human Gates | 玩法理解、乐趣、视觉、听感、物理设备、打包、商店与发布 |
| 已启用可选适配器 | HAPI:本批 worker/reviewer 必须用户可见、可接管 |
| Paid image boundary | Owner standing approval reaffirmed 2026-08-13; current P9.1 visual slice only, <=4 paid calls and <=USD 5 including retries |
## Execution Profile
@@ -57,8 +58,9 @@ Every new session requires fresh `runtime-evidence.json`, a delivered Role boots
## 共享写入边界
- PMO only: `.agent-taskgraph/`, `CURRENT_CHECKPOINT.md`, P9.1 parent Goal/contract and acceptance records.
- Expert wave uses three separate Markdown outputs under `docs/runtime/p9_1/`.
- Expert wave produced three separate Markdown outputs under `docs/runtime/p9_1/`; PMO reconciles them into the frozen P9.1 contract.
- Foundation worker alone may extract shared APIs and change `runtime/main.gd` during extraction.
- The UX/visual role may prepare the bounded representative visual slice without editing runtime source.
- Domain, UI and test workers run after foundation integration and own disjoint paths.
- Integration worker alone wires parallel products into shared entry and runner files.
- Reviewer is read-only. H5 publishing occurs only after reviewer PASS.
+25 -12
View File
@@ -1,9 +1,9 @@
version: 1
batch:
id: "abg-p9-1-continuous-development-01"
revision: "graph-p9.1-r1"
revision: "graph-p9.1-r2"
spec: ".agent-taskgraph/spec.md"
spec_revision: "p9.1-spec-r1"
spec_revision: "p9.1-spec-r2"
approved_by: "Owner"
approved_at: "2026-08-13"
max_concurrency: 3
@@ -67,21 +67,34 @@ nodes:
goal_ref: "task:ABG-P9.1-RUNTIME-FOUNDATION"
needs: ["p91_spec_integration"]
consumes: ["docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md", "P9.0R10 fixed runtime source"]
produces: ["runtime/domain/foundation/", "runtime/ui/foundation/"]
writes: ["runtime/main.gd", "runtime/domain/foundation/", "runtime/ui/foundation/"]
produces: ["runtime/domain/p9_1/session_state.gd", "runtime/domain/p9_1/session_service.gd", "runtime/domain/p9_1/battle_fixture.gd", "runtime/presentation/", "runtime/ui/session_presenter.gd", "runtime/ui/widgets.gd", "runtime/compat/p9_0_root_facade.gd"]
writes: ["runtime/main.gd", "runtime/domain/p9_1/contracts.gd", "runtime/domain/p9_1/session_state.gd", "runtime/domain/p9_1/session_service.gd", "runtime/domain/p9_1/battle_fixture.gd", "runtime/presentation/", "runtime/ui/session_presenter.gd", "runtime/ui/widgets.gd", "runtime/compat/p9_0_root_facade.gd"]
acceptance: ["P9.0R1-R10 declared behavior remains equivalent", "Shared state has one owner", "Parallel extension APIs compile and are covered"]
on_pass: "p91_domain_implementation"
on_fail: "failed"
max_attempts: 2
- id: "p91_representative_visual_slice"
title: "Produce the bounded first-battle visual slice"
kind: "worker"
goal_ref: "task:ABG-P9.1-VISUAL-SLICE"
needs: ["p91_spec_integration"]
consumes: ["docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md", "docs/runtime/p9_1/UX_VISUAL_FLOW_SPEC.md", "accepted P9.0R3-R10 visual assets"]
produces: ["docs/runtime/p9_1/visual_slice/"]
writes: ["docs/runtime/p9_1/visual_slice/"]
acceptance: ["Formation-to-diagnosis composition reads at 844x390", "Paid generation stays within four calls and USD 5", "Prompts, task IDs, costs and hashes are recorded", "No runtime integration or bulk asset expansion"]
on_pass: "p91_runtime_integration"
on_fail: "failed"
max_attempts: 2
- id: "p91_domain_implementation"
title: "Implement arbitrary-party P9.1 domain flow"
kind: "worker"
goal_ref: "task:ABG-P9.1-DOMAIN"
needs: ["p91_runtime_foundation"]
consumes: ["runtime/domain/foundation/", "docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md"]
produces: ["runtime/domain/p9_1/"]
writes: ["runtime/domain/p9_1/"]
consumes: ["runtime/domain/p9_1/session_service.gd", "runtime/domain/p9_1/session_state.gd", "docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md"]
produces: ["runtime/domain/p9_1/content/", "runtime/domain/p9_1/rules/"]
writes: ["runtime/domain/p9_1/content/", "runtime/domain/p9_1/rules/"]
acceptance: ["Six-pair deterministic state matrix passes", "Transactions commit exactly once", "No Control-tree or frame-rate dependency"]
on_pass: "p91_runtime_integration"
on_fail: "failed"
@@ -92,7 +105,7 @@ nodes:
kind: "worker"
goal_ref: "task:ABG-P9.1-UI"
needs: ["p91_runtime_foundation"]
consumes: ["runtime/ui/foundation/", "docs/runtime/p9_1/UX_VISUAL_FLOW_SPEC.md"]
consumes: ["runtime/ui/session_presenter.gd", "runtime/ui/widgets.gd", "docs/runtime/p9_1/UX_VISUAL_FLOW_SPEC.md"]
produces: ["runtime/ui/p9_1/"]
writes: ["runtime/ui/p9_1/"]
acceptance: ["All declared screens render from real state", "Chinese first and accessibility variants fit", "Accepted battle movement and feedback are preserved"]
@@ -106,8 +119,8 @@ nodes:
goal_ref: "task:ABG-P9.1-TESTS"
needs: ["p91_runtime_foundation"]
consumes: ["docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md", "runtime/tests/"]
produces: ["runtime/tests/p9_1/", "runtime/tools/p9_1/"]
writes: ["runtime/tests/p9_1/", "runtime/tools/p9_1/"]
produces: ["runtime/tests/p9_1/", "runtime/tests/support/p9_1/"]
writes: ["runtime/tests/p9_1/", "runtime/tests/support/p9_1/"]
acceptance: ["Pair-path and negative boundaries are executable", "Parsed touch and layout states are declared", "Strict diagnostics and cleanup are enforced"]
on_pass: "p91_runtime_integration"
on_fail: "failed"
@@ -117,8 +130,8 @@ nodes:
title: "Integrate the complete P9.1 first session"
kind: "merge"
goal_ref: "task:ABG-P9.1-RUNTIME-INTEGRATION"
needs: ["p91_domain_implementation", "p91_ui_implementation", "p91_test_implementation"]
consumes: ["runtime/domain/p9_1/", "runtime/ui/p9_1/", "runtime/tests/p9_1/", "runtime/tools/p9_1/"]
needs: ["p91_domain_implementation", "p91_ui_implementation", "p91_test_implementation", "p91_representative_visual_slice"]
consumes: ["runtime/domain/p9_1/content/", "runtime/domain/p9_1/rules/", "runtime/ui/p9_1/", "runtime/tests/p9_1/", "runtime/tests/support/p9_1/", "docs/runtime/p9_1/visual_slice/"]
produces: ["P9.1 fixed candidate revision"]
writes: ["runtime/main.gd", "runtime/project.godot", "runtime/tools/run_p9_1_tests.sh"]
acceptance: ["Complete five-battle flow works for all pairs", "Full R1-R10 plus P9.1 suite passes", "Normal-render and touch evidence meet the frozen contract"]
+4 -3
View File
@@ -3,7 +3,7 @@
> Status: FROZEN
> Requested: 2026-08-13
> Frozen by: Owner / 2026-08-13
> Revision: p9.1-spec-r1
> Revision: p9.1-spec-r2
## 本批要回答的问题
@@ -43,7 +43,7 @@ P9.0R10 允许玩家从四人中任意选择两人,并让全部六种无序组
1. 游戏策划、UX/视觉设计、技术架构并行输出三份互斥规格。
2. PMO 汇合三份规格,消除矛盾并冻结实现合同。
3. Foundation worker 行为等价拆分共享运行时。
3. Foundation worker 行为等价拆分共享运行时;代表性视觉切片可并行准备。
4. Domain、UI、Tests 三个 worker 在互斥路径中并行实现。
5. Integration worker 接入共享入口,跑完整回归、矩阵、触摸和正常渲染。
6. Fresh independent reviewer 固定 revision 只读验收。
@@ -65,7 +65,8 @@ P9.0R10 允许玩家从四人中任意选择两人,并让全部六种无序组
- 第二章节及以后、完整 42 职业/320 装备/100 敌人内容生产。
- 正式 Market、持久装备背包、权威 XP 3-10、晋升、伤亡恢复和 save migration。
- 权威完整战斗公式、难度、经济、离线进度与长期元进度。
- 新的付费图片/音频生成、批量最终美术与音频生产。
- 除 P9.1 首战/诊断代表性视觉切片外的付费图片、音频、视频和批量最终媒体生产。
- 代表性视觉切片最多 4 次付费图片调用、总额不超过 5 美元(含重试),并记录任务 ID、成本与来源;不再逐次请求 Owner 批准。
- iOS/Android 打包、TestFlight、设备安装、签名、商店、评审与发布。
- 复制参考商业游戏的名称、文案、数值、布局、代码或资产。
@@ -25,11 +25,13 @@ Each choice and result must be based on the actual party, equipment and prior de
1. Parallel game-design, UX/visual and runtime-architecture specifications.
2. PMO integration into one implementation contract.
3. Behavior-equivalent runtime extraction.
4. Parallel domain, UI and test implementation with disjoint writes.
5. Integration, full regression and source-bound runtime evidence.
6. Fresh independent review.
7. New private remotely playable H5 after reviewer PASS.
8. Owner play judgment.
4. One bounded representative visual slice, with at most four paid image calls
and USD 5 total, may run beside foundation extraction.
5. Parallel domain, UI and test implementation with disjoint writes.
6. Integration, full regression and source-bound runtime evidence.
7. Fresh independent review.
8. New private remotely playable H5 after reviewer PASS.
9. Owner play judgment.
## Acceptance
@@ -44,10 +46,13 @@ Each choice and result must be based on the actual party, equipment and prior de
## Frozen
No chapter expansion, bulk content, authoritative full combat/economy/save systems, paid media,
mobile packaging, TestFlight, device actions, store actions or release work.
No chapter expansion, bulk content, authoritative full combat/economy/save systems, mobile
packaging, TestFlight, device actions, store actions or release work. Current-task image
generation is authorized only for the contract's representative visual slice, with at most
four paid calls and USD 5 equivalent total including retries. Audio/video generation and
bulk/final media remain frozen.
## Current Gate
The first three expert tasks must produce mutually consistent specifications. Runtime code is
not authorized until their commits are integrated and the implementation contract is frozen.
The three expert tasks are integrated. Runtime code is authorized only through the frozen
`docs/runtime/PHASE9_1_ARBITRARY_PARTY_FIRST_SESSION_CONTRACT.md` and the TaskGraph stage order.
@@ -0,0 +1,322 @@
# Phase 9.1 Arbitrary-Party First-Session Implementation Contract
> Status: `FROZEN`
> Contract revision: `p9.1-contract-r1`
> Frozen: 2026-08-13
> Accepted predecessor product source: `41204acafa911a505f5b24a493aa032983e706d1`
> Predecessor closure: `f0b7d7b0234d8ad304f7b9d39fa99ded1dbfc27d`
> Expert inputs: `GAMEPLAY_EXPERIENCE_SPEC.md`, `UX_VISUAL_FLOW_SPEC.md`,
> `RUNTIME_ARCHITECTURE_SPEC.md`
## 1. Product Outcome And Stopping Point
P9.1 carries every unordered pair selected from the four current Recruits through
one truthful five-battle first session:
```text
choose any two -> automatic formation -> battle 1 -> diagnosis -> adaptation
-> battle 2 -> Guild response -> battle 3 -> route -> battle 4 -> growth
-> battle 5 -> first-session result
```
The player chooses people, never front/rear slots. The system forms the line,
automatic combat makes each actual profession act, and every decision page shows
current evidence, gain, cost and foregone alternative before commit. The final
page ends the bounded experience or restarts it; it does not claim a saved run,
next chapter, permanent item, authoritative XP or release readiness.
This is one deterministic vertical slice. Complete combat, economy, save,
Market, promotion, injury/recovery, difficulty, chapters and bulk content remain
frozen.
## 2. Reconciled Authorities
This contract resolves the three expert inputs. Implementation follows this
precedence:
1. This frozen contract for reconciled behavior and ownership.
2. `p9_1/GAMEPLAY_EXPERIENCE_SPEC.md` for the complete numeric matrix,
transaction rules and causal values.
3. `p9_1/UX_VISUAL_FLOW_SPEC.md` for layouts, copy, controls, accessibility and
evidence states, except where this contract explicitly reconciles a conflict.
4. `p9_1/RUNTIME_ARCHITECTURE_SPEC.md` for APIs, migration and final file paths.
5. P9.0R1-R10 contracts for unchanged regression anchors.
The expert files remain immutable source records. Developers do not amend them
to fit implementation.
## 3. Reconciled Product Decisions
### 3.1 Stable identities and automatic formation
The stable member/profession IDs are the existing runtime IDs:
```text
Hearthguard, Wayrunner, Farstring, Kindhand
```
Automatic priority is:
```text
Hearthguard -> Wayrunner -> Farstring -> Kindhand
```
`starting_pair` is normalized by this priority. `initial_second_id` and
`marked_id` remain the identity that began second, regardless of later visible
position. Selection order never affects formation.
A Guild addition may reform the whole line. It must preserve the two original
members' relative order while inserting the new member at its priority position.
For `Farstring + Kindhand`, adding Hearthguard therefore changes the lead from
Farstring to Hearthguard and yields `Hearthguard, Farstring, Kindhand`. The
receipt must state:
- who was added and at which position;
- every original member whose visible number changed;
- that the original two retained their relative order;
- why the system reformed the line.
Existing actors move to their new positions; they do not disappear and respawn.
This reconciles the UX continuity rule with the gameplay re-formation rule.
### 3.2 Exact decision and content IDs
```text
adaptation: EQ-002 | EQ-061
Guild response: retain_loan | add_recruit
route: R6-01 | R6-02 | R6-03
growth: exactly one current member ID
```
The Guild addition allowlist, route coverage, battle values, rewards and growth
effects are exactly those in the gameplay specification. UI does not infer an
action from `front`, `rear`, `second` or `added`; it presents domain-resolved
member IDs, facts and events.
### 3.3 Final screen and legacy naming
The final domain/presentation screen is `session_result`, surfaced as
`P91-FIRST-SESSION-RESULT`. During migration it maps to the historical
`AppPage.THIRD_CYCLE_RESULT`; P9.1 does not add another final page. New code and
evidence use the P9.1 name. The legacy enum remains facade-only until its stated
deletion gate is met.
### 3.4 One result grammar
All five result pages use exactly this order in Chinese and English:
```text
发生了什么:{outcome_clause}
为什么:{cause_clause}
决定造成的差异:{decision_clause}
现在改变了:{changed_state_clause}
下一步:{next_action_clause}
```
For Result 1 only, line three is `系统编队造成的差异`. The gameplay
specification's result templates supply the facts and numeric substitutions,
but the UI formats them into these five labels. No separate `状态变化` line or
unlabeled decision chain is shown. Result 5 may append the compact chain after
line four, never before cause or changed state.
`P91_RESULT` therefore contains already-resolved `outcome_clause`,
`cause_clause`, `decision_clause`, `changed_state_clause`,
`next_action_clause`, `reward_receipt` and `decision_chain`. It never contains
only totals that require UI-side causal reconstruction.
## 4. Screen Snapshot And Action Contract
Every render receives one immutable snapshot, plus named callbacks for only the
listed `available_actions`. A missing required fact renders `P91-BINDING-ERROR`;
the UI must not invent a fallback result.
| Screen family | Required snapshot facts | Available actions |
|---|---|---|
| Boot/Title/Menu/Intro/Settings | resource status, locale/settings, caller/focus, no transient run claim | existing R8 navigation/settings actions only |
| Commission/Recruit 0-2 | four member identities, selected IDs, capacity, automatic-order preview, disabled reasons | `open_recruit`, `toggle_recruit`, `review_formation`, `home` |
| Formation review | normalized `starting_pair`, lead/second responsibility, order reason | `revise_formation`, `commit_formation`, `home` |
| Battles 1-5 | encounter/phase, party order/origin/HP/level, enemy HP, ordered semantic events, current committed decision | `pause`, `captions`; domain progression is clock/event driven |
| Results 1-5 | the five resolved result clauses, exact resource/HP/time facts, receipt state | the one next-flow action; final result also offers inspect, restart review and finish |
| Adaptation 0-1 | both options' gain/cost/foregone state, actual lead, pending/committed ID | `choose_adaptation`, then `commit_adaptation`; Back before commit |
| Guild 0-1 | current party/order/origin, Coin, loan, mapped Recruit, both exact consequences | `choose_guild_response`, then `commit_guild_response`; Back before commit |
| Route 0-1/review | three routes, pressure, target, reward, domain-resolved coverage/reason, pending ID | `choose_route`, `review_route`, `cancel_route_review`, `commit_route` |
| Growth 0-1/review | every present member, order/origin/level, exact next-battle delta, one mark | `choose_growth`, `review_growth`, `cancel_growth_review`, `commit_growth` |
| Pause/Home/Restart review | frozen caller snapshot and exact transient state to preserve or clear | resume/cancel plus separately focused confirm |
Choice screens always open unselected. Selection is reversible and free.
Commit is the only mutation boundary, revalidates the complete precondition and
increments domain revision once. Rejected or duplicate commands change no
snapshot field, event, reward, clock or revision.
## 5. Domain And Presentation Boundary
The final paths are the architect's paths, not placeholder `foundation/`
directories.
### 5.1 Exclusive foundation writes
```text
runtime/main.gd
runtime/domain/p9_1/contracts.gd
runtime/domain/p9_1/session_state.gd
runtime/domain/p9_1/session_service.gd
runtime/domain/p9_1/battle_fixture.gd
runtime/presentation/presentation_settings.gd
runtime/presentation/battle_clock.gd
runtime/presentation/animation_adapter.gd
runtime/presentation/audio_adapter.gd
runtime/presentation/feedback_presenter.gd
runtime/ui/session_presenter.gd
runtime/ui/widgets.gd
runtime/compat/p9_0_root_facade.gd
```
The foundation is behavior-equivalent. It introduces one authoritative state
object, commands, snapshots, semantic events and compatibility forwarding; it
adds no P9.1-only decision branch or changed player value.
### 5.2 Parallel extension writes after foundation PASS
| Role | Exact write scope |
|---|---|
| Domain | new files only under `runtime/domain/p9_1/content/` and `runtime/domain/p9_1/rules/` |
| UI | new files only under `runtime/ui/p9_1/` |
| Tests | new files under `runtime/tests/p9_1/` and `runtime/tests/support/p9_1/` |
| Integration | shared entry/foundation files, exact shared P9.1 runner/manifest, and `runtime/project.godot` only when needed |
No parallel developer edits `runtime/main.gd`, foundation API files, existing
P9.0 tests or another role's directory. Integration is the sole shared-file
owner after foundation.
### 5.3 Domain and time invariants
- Domain scripts do not extend/read `Node`, `Control`, SceneTree, Input,
AudioServer, textures, paths, viewport or render FPS.
- `FirstSessionService` is the only run mutator. Snapshots are deep copies.
- `BattleClock` requests named impacts; it never decides HP, rewards or result.
- An impact is keyed by encounter + phase + impact ID and commits at most once.
- Render FPS, locale, viewport, mute, reduced motion/flashes and low power do not
change the final domain snapshot.
- Low power may reduce presentation sampling, particles and nonessential idle
animation only. It preserves event order, actor state transitions, captions,
number feedback, battle duration and every transaction.
## 6. Behavior-Equivalent Foundation Gate
The exact non-capture P9.0 regression manifest is:
```text
p9_0_boot_title_test.gd
p9_0_layout_test.gd
p9_0_touch_test.gd
p9_0r1_domain_test.gd
p9_0r1_dynamic_slice_test.gd
p9_0r1_layout_test.gd
p9_0r1_touch_test.gd
p9_0r2_character_animation_test.gd
p9_0r2_dynamic_slice_test.gd
p9_0r3_audio_lifecycle_test.gd
p9_0r3_battle_feedback_test.gd
p9_0r3_dynamic_slice_test.gd
p9_0r4_second_cycle_test.gd
p9_0r4_touch_test.gd
p9_0r5_first_session_arc_test.gd
p9_0r5_full_route_touch_test.gd
p9_0r6_route_touch_test.gd
p9_0r6_second_cycle_route_test.gd
p9_0r7_growth_touch_test.gd
p9_0r7_individual_growth_test.gd
p9_0r8_front_door_test.gd
p9_0r8_front_door_touch_test.gd
p9_0r9a_auto_formation_test.gd
p9_0r9a_auto_formation_touch_test.gd
p9_0r10_pair_adaptation_test.gd
p9_0r10_pair_adaptation_touch_test.gd
```
The foundation task must run these exact 26 scripts serially from a clean
import, require each script's unique accepted terminal marker and scan all logs
for strict diagnostics. It also reruns the preserved normal-render R8 front
door, R9A formation, R10 adaptation, and R3 feedback capture scripts at
`844x390` to detect presentation drift. Capture output is development evidence,
not a new candidate.
Tracked `runtime/domain/run_state.gd` and the five pre-existing
`runtime/tests/p9_1_*` scripts belong to an older opening/Market lineage. P9.1
foundation leaves them unchanged and excludes them from its pass claim. A later
integration-only commit may retire or reclassify them only with explicit source
search, replacement coverage and a contract amendment.
## 7. P9.1 Implementation And Evidence Gate
The gameplay specification's compact functions expand to:
```text
6 unordered pairs x 2 click orders
12 pair/adaptation paths
24 pair/adaptation/Guild paths
72 paths through three routes
each route path x every present two- or three-member growth target
```
Tests assert identity, origin, relative order, actual profession events,
lead/marked/enemy HP, time, Coin, Company, item state, route coverage/reward,
exactly one Lv.2 member, commit flags and the five result clauses. Negative
coverage includes invalid IDs, stale/duplicate commits, insufficient Coin,
duplicate Recruit, absent growth member, premature reward and reset cleanup.
Runtime evidence requires:
- one uninterrupted parsed-ScreenTouch path through all five battles with
fallback/direct zero;
- all six pairs reaching the final result;
- small/reference/large landscape, zh_CN/EN, 130%, reduced motion/flashes,
mute/captions, contrast and low-power representative states;
- the UX specification's 25 named frames and battle-event states;
- visible party-line continuity, melee contact, ranged attack, heal/guard,
damage/heal numbers, result cause and persistent decision change;
- strict scan covering script/parse/resource/import/assertion/ObjectDB and
owned-process cleanup failures.
Automated or visual agent evidence cannot close Owner understanding, fun,
visual/listening, physical device, packaging or release gates.
## 8. Bounded Representative Visual Slice
The Owner authorizes current-task image generation without another per-call
prompt. The visual task may make at most four paid image calls and spend at most
USD 5 equivalent total, including retries. It records prompts, provider task
IDs, returned cost, source/output hashes and acceptance or rejection.
The visual slice is limited to the representative first-battle/diagnosis chain:
```text
formation review -> approach/contact -> profession response -> damage/heal
feedback -> first causal result
```
It may produce a bounded layered battlefield/UI reference or replacement asset
set only after graybox composition. It must preserve the accepted four Recruit
identities, Japanese hand-painted direction, landscape party scale and event
readability. It does not authorize bulk chapter assets, new character families,
audio, video, store media or silent provider expansion. Generated material is
not integrated unless play-size review and provenance checks pass.
## 9. Submission And Remaining Gates
The developer legal terminal is:
```text
Aetherbound Guild P9.1 candidate ready
```
or:
```text
Aetherbound Guild P9.1 redesign required: <earliest failed product boundary>
```
Submission requires a focused pushed source, clean/upstream repository, complete
contract evidence and no owned process. A fresh visible independent reviewer
then reruns the fixed candidate from zero. Only reviewer PASS authorizes a new
private H5. Packaging, TestFlight, devices, stores and release remain frozen.