aetherbound-guild/docs/reviews/PRE_DEVELOPMENT_READINESS_AUDIT.md

# Recruit-Line Pre-Development Readiness Audit

Date: 2026-08-11
Status: `READY_FOR_DUAL_INDEPENDENT_REVIEW`
Integrated product source: `f8d5bfe`
Frozen specification: `.agent-taskgraph/spec.md` revision `design-spec-r3`

## Decision

The six design authorities, the forward repair for the failed first review,
and the deterministic action-outcome repair with its content, art and audio
sync have been integrated without write conflicts. The deterministic
pre-development validator passes. The package is ready for two independent,
read-only reviews with non-overlapping emphasis: systems integrity and player
experience/production feasibility. It is not yet owner-approved and does not
authorize HTML prototype, engine, asset generation, audio generation,
packaging or release work.

## Integrated Candidates

| Workstream | Candidate | Scope |
|---|---|---|
| Core systems | `b0f9033`, repair `e598eed` -> `f55906e`, `9be1927` | four files under `docs/product/` |
| Content matrix | `4e07a91` + `6a41189` -> `65f316d` + `30fb0b9` | `docs/content/` only |
| UX and screen states | `c364a5e`, repair `c64b99e` -> `dc8d654`, `ec4863a` | two named presentation files |
| Art, animation and VFX | `ca4d3df` -> `4b6270a` | art catalog only |
| Audio | `1d51137`, repair `ff4101a` -> `8b26e0a`, `f0095af` | audio catalog only |
| Design validator | `493e714`, repair `e7f80d0` -> `b2d8f7b`, `83bba23` | validator contract and executable only |
| Deterministic outcome authority | `5a05ffc` -> `f2a3f3c` | battle systems authority only |
| Content outcome sync | `d5fd2fc` -> `edbd281` | four content catalogs only |
| Art outcome sync | `8c8c1b7` -> `f8d5bfe` | art catalog only |
| Audio outcome sync | `ea69bc7` -> `404e996` | audio catalog only |

The content worker's exact identity ACK was observed at candidate close instead
of before implementation. Runtime configuration, isolated worktree, exclusive
write scope, two candidate commits and clean terminal are all independently
recorded. This is a process-order deviation for reviewer awareness, not hidden
evidence or a reason to upgrade product acceptance.

## Verified Envelope

| Domain | Verified count or boundary |
|---|---|
| Professions | 12 base + 24 advanced + 6 hidden = 42 |
| Recruit traits | 36 |
| Equipment | 320 |
| Run artifacts | 60 |
| Ordinary/elite enemies | 100 |
| Bosses | 16 |
| Regions | 8 |
| Player-facing pages | 50 complete screen definitions |
| Audio production IDs | 32 music, 76 ambience, 228 shared SFX, 32 voice intents |
| Integration bindings | 33 declarations; zero unresolved values |

The product authority now uses generated recruits, repeated shop decisions, a
single ordered horizontal party line, automatic combat, recruitment,
dismissal, permanent casualty and replacement. Fixed protagonists,
relationships, fixed six-person grid combat, three lanes and manual
Directive/Anchor/Cache battle authority are retired.

The first independent review of fixed revision `7ffd6b0` failed because an
ordinary dismissal could remove the final live Recruit and expose an undefined
zero-Recruit Market. The forward repair now evaluates one canonical
`live_recruit_count` at preview and commit, rejects final-survivor, stale,
duplicate and interrupted dismissal without rebate or state mutation, and
keeps casualty recovery and explicit run abandonment as separate
transactions. UX exposes the rejection and a distinct `OUT-006` abandonment
confirmation that routes directly to run end rather than an empty Shop.

Systems R2 then failed fixed revision `7054fe6` because `PF-A04` depended on
undefined probabilistic hit/miss/evasion semantics. The forward repair keeps
the product rule of no hidden miss chance, defines 12 deterministic `AO_*`
terminal outcomes, and binds Turnblade, affected equipment/traits/enemies,
VFX shapes, SFX and captions to those outcomes. Experience R2 was `INVALID`
because its context named a nonexistent reference file; R3 must use the actual
authorities `docs/reference/REFERENCE_RUNTIME_CENSUS.md` and
`docs/reference/TRANSFERABLE_STRUCTURE_LESSONS.md`.

## Reproducible Checks

Run from the repository root:

```bash
python3 tools/validate_predevelopment_design.py --self-test
python3 tools/validate_predevelopment_design.py
python3 tools/validate_predevelopment_design.py --json
git diff --check
```

Expected markers and counts:

```text
ABG_PREDEVELOPMENT_DESIGN_SELF_TEST_OK cases=15
ABG_PREDEVELOPMENT_DESIGN_OK errors=0
```

The JSON result must contain `"ok": true`, an empty `diagnostics` array and
the exact counts above.

`tools/validate_design_contracts.py` and the current `prototype/site/` bundle
belong to the superseded fixed-character, chapter-grid design. They are not
evidence for this revision and must not be shown to the owner as the current
game. Updating or replacing the HTML prototype is a later Goal after
independent review and owner direction approval.

## Independent Review Questions

1. Does the ten-minute loop remain immediately understandable: inspect offers,
   recruit or buy, equip, reorder, choose risk, watch automatic combat, read
   casualties/rewards, then make the next shop decision?
2. Does party order materially change protection, reach, movement, healing and
   replacement without recreating a hidden lane grid?
3. Do permanent loss and price pressure create recoverable adaptation instead
   of an unrecoverable run collapse or a trivial dismissal exploit?
4. Are all 42 professions, 36 traits, 320 equipment, 60 artifacts and 116 enemy
   identities decision-bearing rather than name-only filler?
5. Are the five pacing profiles, save/failure transaction rules and postgame
   loop executable and mutually consistent?
6. Can the 50-page landscape UX teach the loop without relying on prose-heavy
   documentation, unexplained icons or manual skill controls?
7. Are the modular art and audio scopes feasible, original and consistent with
   generated recruits rather than fixed protagonists?
8. Do any transferred structural lessons reproduce commercial expression,
   names, formulas, layouts, source or assets?

The systems reviewer owns questions 1-5 plus machine-checkable content
coherence. The experience reviewer owns questions 6-8 plus production
feasibility. Both must start at fixed-revision and validator gates; neither may
reuse the failed `7ffd6b0` judgment as proof for the repaired source.

## Open Gates

- Two fresh independent reviewer terminals and PMO synthesis on one fixed clean
  revision.
- Owner acceptance of game direction, comprehension, choice quality and scope.
- Rebuilt landscape HTML gallery and interactive design prototype.
- Final art/audio generation, integration, human visual review and listening.
- Engine implementation, simulations, runtime, physical device and persistence.
- Packaging, signing, stores, submission, publishing and release.