Release 1.1.2 — the default path works end to end

Fix release for 1.1.1: the minimal path end to end, engine commands that
run on Godot, Unity and Unreal, hook warnings you can see, and verdicts
that say when they could not check. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.1 → v1.1.2).

Fixes #67
Fixes #131

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ

CCGS Skill Testing Framework/skills/review/architecture-review.md

@@ -2,191 +2,208 @@
 
 ## Skill Summary
 
-`/architecture-review` is an Opus-tier skill that validates a technical architecture
-document against the project's 8 required architecture sections and checks that it
-is internally consistent, non-contradictory with existing ADRs, and correctly
-targeting the pinned engine version. It produces a verdict of APPROVED /
-NEEDS REVISION / MAJOR REVISION NEEDED.
+`/architecture-review` is an Opus-tier skill that checks whether the whole body
+of architectural decisions covers the game's design. It extracts technical
+requirements (TR-IDs) from every GDD, maps each one to the ADRs that cover it
+in a traceability matrix, detects cross-ADR conflicts, orders ADRs by
+dependency (via `.claude/scripts/adr-dep-graph.sh`), audits engine
+compatibility against `docs/engine-reference/`, consults the primary engine
+specialist, and checks `docs/architecture/architecture.md` coverage of the
+systems index. It produces a PASS / CONCERNS / NOT ASSESSED / FAIL verdict.
 
-In `full` review mode, the skill spawns two director gate agents in parallel:
-TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY (lead-programmer). In
-`lean` or `solo` mode, both gates are skipped and noted. The skill is read-only —
-no files are written.
+It takes a focus argument (`full` by default, or `coverage`, `consistency`,
+`engine`, `single-gdd [path]`, `rtm`). After the report, it asks via
+`AskUserQuestion` before writing the review report
+(`docs/architecture/architecture-review-[date].md`), the traceability index and
+`docs/architecture/tr-registry.yaml`. It is the quality gate between Technical
+Setup and Pre-Production.
 
 ---
 
 ## Static Assertions (Structural)
 
-Verified automatically by `/skill-test static` — no fixture needed.
+Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
 
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings
-- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
-- [ ] Does NOT require "May I write" language (read-only skill)
-- [ ] Has a next-step handoff at the end
-- [ ] Documents gate behavior: TD-ARCHITECTURE + LP-FEASIBILITY in full mode; skipped in lean/solo
+- [ ] Contains verdict keywords: PASS, CONCERNS, NOT ASSESSED, FAIL
+- [ ] `allowed-tools` includes Write, so write-approval language is present ("May I update the systems index?", "May I update `docs/architecture/tr-registry.yaml`…")
+- [ ] Has a next-step handoff at the end (Phase 9)
+- [ ] Documents the argument modes: `full`, `coverage`, `consistency`, `engine`, `single-gdd [path]`, `rtm`
 
 ---
 
 ## Director Gate Checks
 
-In `full` mode: TD-ARCHITECTURE (technical-director) and LP-FEASIBILITY
-(lead-programmer) are spawned in parallel after the skill reads the architecture doc.
-
-In `lean` mode: both gates are skipped. Output notes:
-"TD-ARCHITECTURE skipped — lean mode" and "LP-FEASIBILITY skipped — lean mode".
-
-In `solo` mode: both gates are skipped with equivalent notes.
+None. This skill resolves no `review_mode` (its config block requests only
+`automation` and `workflow`) and spawns no director gate. The only agent it
+spawns is the primary engine specialist in Phase 5. The architecture sign-off
+gates (TD-ARCHITECTURE, LP-FEASIBILITY) belong to `/create-architecture`, not to
+this skill.
 
 ---
 
 ## Test Cases
 
-### Case 1: Happy Path — Complete architecture doc in full mode
+### Case 1: Happy Path — every requirement covered by an Accepted ADR
 
 **Fixture:**
-- `docs/architecture/architecture.md` exists with all 8 required sections populated
-- All sections reference the correct engine version from `docs/engine-reference/`
-- No contradictions with existing Accepted ADRs in `docs/architecture/`
-- `production/session-state/review-mode.txt` contains `full`
+- `project.yaml` sets `modes.workflow: full`, `engine.name: Godot`, `engine.version: 4.6`
+- `design/gdd/systems-index.md` plus two system GDDs (`combat.md`, `inventory.md`),
+  each with a `## Summary` and technical requirements in its Detailed Rules
+- `docs/architecture/adr-0001-*.md` … `adr-0003-*.md`, each with `## Status: Accepted`,
+  `## GDD Requirements Addressed`, `## Engine Compatibility` and `## ADR Dependencies`,
+  whose `**Depends On**` row is filled in — `None` for `adr-0001`, `ADR-0001` for
+  `adr-0002` and `adr-0003` — so `adr-dep-graph.sh` finds real edges and lists no
+  ADR under `NO_DEPS_SECTION`; together they cover every requirement; no two contradict
+- `docs/architecture/architecture.md` exists and names every system in the index
+- No prior `docs/architecture/architecture-review-*.md` report
+- Pre-gate items all exist: `tests/unit/`, `tests/integration/` (the Godot test root),
+  `.github/workflows/tests.yml`, `design/accessibility-requirements.md`,
+  `design/ux/interaction-patterns.md`
 
-**Input:** `/architecture-review docs/architecture/architecture.md`
+**Input:** `/architecture-review`
 
 **Expected behavior:**
-1. Skill reads the architecture document
-2. Skill reads existing ADRs for cross-reference
-3. Skill reads engine version reference
-4. TD-ARCHITECTURE and LP-FEASIBILITY gate agents spawn in parallel
-5. Both gates return APPROVED
-6. Skill outputs section-by-section completeness check (8/8 sections present)
-7. Verdict: APPROVED
+1. Freshness check prints `RECEIPT: NONE` → full review
+2. Skill counts the denominators (N_gdd, N_adr), loads the needed sections with
+   targeted Greps rather than whole files, and reports
+   "Loaded [N] GDDs, [M] ADRs, engine: Godot 4.6"
+3. Skill extracts TR-IDs (reusing any existing `tr-registry.yaml` IDs) and builds the matrix
+4. Skill runs `bash .claude/scripts/adr-dep-graph.sh` and prints the recommended implementation order
+5. Skill runs the engine audit and consults `godot-specialist`
+6. Report ends with `### Verdict: PASS`
+7. Phase 8 asks what to write; Phase 9 offers `/gate-check pre-production`
 
 **Assertions:**
-- [ ] All 8 required sections are checked and reported
-- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel (not sequentially)
-- [ ] Verdict is APPROVED when all sections are present and no conflicts exist
-- [ ] Skill does NOT write any files
-- [ ] Next-step handoff to `/create-control-manifest` or `/create-epics` is present
+- [ ] Output reports "Loaded [N] GDDs, [M] ADRs, engine: [name + version]"
+- [ ] A Traceability Matrix lists each TR-ID with its GDD, system, requirement, ADR coverage and status; every row is ✅
+- [ ] The ADR dependency order comes from `adr-dep-graph.sh`, not hand-tracing, and puts `adr-0001` first; `NO_DEPS_SECTION` is empty, so the acyclic result is a clean graph rather than a structural gap
+- [ ] Verdict is PASS only because all requirements are covered by **Accepted** ADRs, no conflicts exist, and engine references agree
+- [ ] The report includes the `review-receipts.sh hash` lines for the ADRs and GDDs reviewed
+- [ ] No file is written before the Phase 8 `AskUserQuestion` (`[A]` all three files / `[B]` report only at `docs/architecture/architecture-review-[date].md` / `[C]` nothing yet)
+- [ ] The closing widget offers `/gate-check pre-production`, because every pre-gate checklist item is ✅
 
 ---
 
-### Case 2: Failure Path — Missing required sections
+### Case 2: Failure Path — Foundation gap plus a cross-ADR ownership conflict
 
 **Fixture:**
-- `docs/architecture/architecture.md` exists but is missing at least 2 required sections
-  (e.g., no data model section, no error handling section)
-- `production/session-state/review-mode.txt` contains `full`
+- As Case 1, except:
+  - `save-system.md` (a Foundation-layer system) requires "Player progress
+    persists between sessions" and no ADR addresses it
+  - `adr-0002` and `adr-0004` are both Accepted and both claim authority over the
+    player's health value
 
-**Input:** `/architecture-review docs/architecture/architecture.md`
+**Input:** `/architecture-review`
 
 **Expected behavior:**
-1. Skill reads the document and identifies missing sections
-2. Section completeness shows fewer than 8/8 sections present
-3. Missing sections are listed by name with specific remediation guidance
-4. Verdict: MAJOR REVISION NEEDED (≥2 missing sections)
+1. The persistence requirement appears as a `❌ GAP` row
+2. The gap appears under "Coverage Gaps" with a suggested `/architecture-decision [title]`, Domain and Engine Risk
+3. A conflict block `## Conflict: [ADR-0002] vs [ADR-0004]` is printed
+4. Verdict is FAIL; Blocking Issues list at least the Foundation gap
+5. Neither ADR is edited; the user decides the resolution
 
 **Assertions:**
-- [ ] Verdict is MAJOR REVISION NEEDED (not APPROVED or NEEDS REVISION) for ≥2 missing sections
-- [ ] Each missing section is named explicitly in the output
-- [ ] Remediation guidance is specific (what to add, not just "add missing sections")
-- [ ] Skill does NOT pass a document missing required sections
+- [ ] Verdict is FAIL (a Foundation-layer requirement is uncovered)
+- [ ] The gap row names the TR-ID, GDD and requirement, with a suggested `/architecture-decision` command
+- [ ] The conflict block names both ADR numbers, a Type (State / Data ownership), what each ADR claims, the Impact, and at least two resolution options
+- [ ] Skill does NOT auto-resolve the conflict or edit either ADR
+- [ ] If `docs/consistency-failures.md` exists, the Phase 8 `[A]` option names it ("…and append 1 conflict entry to `docs/consistency-failures.md`") and the entry is appended only when the user picks `[A]`; `[B]` (report only) writes the report and nothing else; if the file does not exist, it is not created
+- [ ] The closing widget does not offer `/gate-check`; it offers writing the missing ADR via `/architecture-decision [system]`
 
 ---
 
-### Case 3: Partial Path — Architecture contradicts an existing ADR
+### Case 3: Partial Path — coverage resting on a Proposed ADR
 
 **Fixture:**
-- `docs/architecture/architecture.md` exists with all 8 sections present
-- One Accepted ADR in `docs/architecture/` establishes a constraint that the architecture doc contradicts
-  (e.g., ADR-001 mandates ECS pattern; architecture.md describes a different pattern for the same system)
+- As Case 1, except `adr-0003` (the only ADR covering `TR-inventory-001`) has `## Status: Proposed`
+- `adr-0004` (Accepted) has `**Depends On**: ADR-0003` in its `## ADR Dependencies` table
 
-**Input:** `/architecture-review docs/architecture/architecture.md`
+**Input:** `/architecture-review`
 
 **Expected behavior:**
-1. Skill reads the architecture doc and all existing ADRs
-2. Conflict is detected between the architecture doc and the named ADR
-3. Conflict entry names: the ADR number/title, the contradicting sections, and impact
-4. Verdict: NEEDS REVISION (conflict exists but structure is otherwise sound)
+1. `TR-inventory-001` is marked `🟡 Covered (Proposed)`, not ✅
+2. The dependency analysis flags "ADR-0004 depends on ADR-0003 — but ADR-0003 is still Proposed"
+3. Verdict is capped at CONCERNS and names the way out: `/architecture-decision accept ADR-0003`
 
 **Assertions:**
-- [ ] Verdict is NEEDS REVISION (not MAJOR REVISION NEEDED for a single contradiction)
-- [ ] The specific ADR number and title are named in the conflict entry
-- [ ] The contradicting sections in both documents are identified
-- [ ] Skill does NOT auto-resolve the contradiction
+- [ ] Skill reads each ADR's `## Status` before marking coverage; a Proposed ADR never yields ✅
+- [ ] Verdict is CONCERNS (not PASS) when coverage rests on a Proposed ADR
+- [ ] Output names `/architecture-decision accept ADR-0003` as the route to clear it
+- [ ] The unresolved dependency on a Proposed ADR is flagged
 
 ---
 
-### Case 4: Edge Case — File not found
+### Case 4: Edge Case — missing architecture document; malformed ADRs
 
-**Fixture:**
-- The path provided does not exist in the project
+**Case 4a — no master architecture document:**
+- As Case 1, but `docs/architecture/architecture.md` does not exist
 
-**Input:** `/architecture-review docs/architecture/nonexistent.md`
+**Assertions (4a):**
+- [ ] The report states `Architecture document coverage: NOT ASSESSED — no docs/architecture/architecture.md` as a named line item, rather than showing no Phase 6 findings
+- [ ] The overall verdict is NOT ASSESSED, not PASS: Phase 6 is part of the `full` scope and did not run, even though every requirement is covered (a CONCERNS or FAIL finding elsewhere would still outrank it)
 
-**Expected behavior:**
-1. Skill attempts to read the file
-2. File not found
-3. Skill outputs a clear error naming the missing file
-4. Skill suggests checking `docs/architecture/` or running `/create-architecture`
-5. Skill does NOT produce a verdict
+**Case 4b — ADRs present but none has a scannable section:**
+- As Case 1 (`modes.workflow: full` — at the default `minimal` tier, a `project.yaml` with no `modes` block,
+  the skill does not apply), except the three `docs/architecture/adr-*.md` files
+  carry none of the six headings the Phase 1b scan looks for: `## Status`,
+  `## Decision`, `## GDD Requirements Addressed`, `## Engine Compatibility`,
+  `## ADR Dependencies`, `## Performance Implications`
 
-**Assertions:**
-- [ ] Skill outputs a clear error when the file is not found
-- [ ] No verdict is produced (APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED)
-- [ ] Skill suggests a corrective action
-- [ ] Skill does NOT crash or produce a partial report
+**Assertions (4b):**
+- [ ] Skill reports "[N] ADRs found, none carries a scannable section — run `/architecture-decision retrofit [file]` on each" (subcommand first — with the path first, `/architecture-decision` would start authoring a new ADR instead)
+- [ ] Skill does NOT report zero coverage or a design failure — it is a format failure
+- [ ] Rows whose ADR has no `## Status` are `❓ Not assessed`, and the verdict is not PASS — nor FAIL on coverage grounds, since coverage is unknown rather than absent
 
 ---
 
-### Case 5: Director Gate — Full mode spawns both gates; solo mode skips both
+### Case 5: Engine specialist consultation — configured vs unconfigured engine
 
-**Fixture (full mode):**
-- `docs/architecture/architecture.md` exists with all 8 sections
-- `production/session-state/review-mode.txt` contains `full`
+**Case 5a — engine configured:** Case 1 fixture (`engine.name: Godot`)
 
-**Full mode expected behavior:**
-1. TD-ARCHITECTURE gate spawns
-2. LP-FEASIBILITY gate spawns in parallel with TD-ARCHITECTURE
-3. Both gates complete before verdict is issued
+**Expected behavior:**
+1. After the Phase 5 engine audit, skill spawns `godot-specialist` via `Agent`,
+   passing the engine-specific ADRs, the engine reference docs and the audit findings
+2. The specialist's findings appear under `### Engine Specialist Findings` and count toward the verdict
 
-**Assertions (full mode):**
-- [ ] TD-ARCHITECTURE and LP-FEASIBILITY both appear in the output as completed gates
-- [ ] Both gates spawn in parallel (not one after the other)
-- [ ] Verdict reflects gate feedback
+**Assertions (5a):**
+- [ ] The specialist is resolved from `engine.name` (Godot → `godot-specialist`)
+- [ ] It is spawned after the engine audit, with the audit findings in its prompt
+- [ ] Output includes an `### Engine Specialist Findings` section
+- [ ] No director gate (TD-ARCHITECTURE, LP-FEASIBILITY or any other gate ID) is spawned or mentioned
 
-**Fixture (solo mode):**
-- Same architecture doc
-- `production/session-state/review-mode.txt` contains `solo`
+**Case 5b — no engine configured:** as Case 1, except `engine.name` is unset in `project.yaml` and `technical-preferences.md` is still `[TO BE CONFIGURED]`
 
-**Solo mode expected behavior:**
-1. Skill reads the architecture doc
-2. Gates are NOT spawned
-3. Output notes: "TD-ARCHITECTURE skipped — solo mode" and "LP-FEASIBILITY skipped — solo mode"
-4. Verdict is based on structural checks only
-
-**Assertions (solo mode):**
-- [ ] Neither TD-ARCHITECTURE nor LP-FEASIBILITY appears as an active gate
-- [ ] Both skipped gates are noted in the output
-- [ ] Verdict is still produced based on the structural check alone
+**Assertions (5b):**
+- [ ] No engine specialist is spawned
+- [ ] Output records `Engine validation: NOT ASSESSED — no engine configured` rather than omitting the step
+- [ ] The verdict is NOT ASSESSED, not PASS — the engine audit is part of the `full` scope and had no pinned engine to check against, even though every requirement is covered
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Does NOT write any files (read-only skill)
-- [ ] Presents section completeness check before issuing verdict
-- [ ] TD-ARCHITECTURE and LP-FEASIBILITY spawn in parallel in full mode
-- [ ] Skipped gates are noted by name and mode in lean/solo output
-- [ ] Verdict is one of exactly: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
-- [ ] Ends with next-step handoff appropriate to verdict
+- [ ] Shows the full traceability matrix before any write approval (the Phase 1a freshness question and Phase 2's ambiguous-requirement questions may come earlier)
+- [ ] Every write approval uses `AskUserQuestion` with labelled options, not a plain-text "May I?"
+- [ ] Shows the content to be written (report, systems-index rows) before asking to write it
+- [ ] Never renumbers or deletes existing `tr-registry.yaml` entries; marking one deprecated is confirmed with the user
+- [ ] Verdict is one of exactly: PASS, CONCERNS, NOT ASSESSED, FAIL
+- [ ] Ends with a Phase 9 handoff via `AskUserQuestion`; `/gate-check` is not offered while any pre-gate item is ❌
 
 ---
 
 ## Coverage Notes
 
-- The 8 required architecture sections are project-specific; tests use the
-  section list defined in the skill body — not re-enumerated here.
-- Engine version compatibility checking (cross-referencing `docs/engine-reference/`)
-  is part of Case 1's happy path but not independently fixture-tested.
-- RTM (requirement traceability matrix) mode is a separate concern covered by
-  the `/architecture-review` skill's own `rtm` argument mode, not tested here.
+- The `coverage`, `consistency`, `engine`, `single-gdd` and `rtm` modes are not
+  individually fixture-tested; Cases 1–5 exercise the default `full` mode.
+- Phase 5b (GDD revision flags written to `systems-index.md` as `Needs Revision`)
+  is not tested; it needs a HIGH RISK engine finding that contradicts a GDD.
+- The freshness receipt paths (everything `UNCHANGED`, some `CHANGED`/`NEW`,
+  `UNRESOLVED`) are not fixture-tested.
+- The `standard` tier's reduced scope (architecture doc + critical ADRs only) is
+  not tested.
+- The default `minimal` tier (a `project.yaml` with no `modes` block), where the skill's scope table
+  says the review does not apply, is not fixture-tested — every case pins
+  `modes.workflow: full`. Nor is `workflow_overrides.system_overrides`: this skill
+  does not request that key, so a per-system tier has no effect on it.

CCGS Skill Testing Framework/skills/review/design-review.md

@@ -2,24 +2,33 @@
 
 ## Skill Summary
 
-`/design-review` reads a game design document (GDD) and evaluates it against
-the project's 8-section design standard (Overview, Player Fantasy, Detailed
-Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria).
-It checks for internal consistency, implementability, and cross-system
-conflicts. It produces a verdict of APPROVED, NEEDS REVISION, or MAJOR
-REVISION NEEDED. It is a read-only skill (no file writes) and runs as a
-`context: fork` subagent.
+`/design-review` reviews one game design document (GDD) against the project's
+design standard (Overview, Player Fantasy, Detailed Rules, Formulas, Edge
+Cases, Dependencies, Tuning Knobs, Acceptance Criteria). Which sections are
+REQUIRED depends on the workflow tier resolved for that system: all 8 at
+`full`; 5 at `standard` (plus Formulas when the system defines numeric rules).
+It gathers section presence with `.claude/scripts/gdd-structure-check.sh`,
+validates the declared dependency graph, checks internal consistency,
+implementability and cross-system fit, and produces a verdict of APPROVED,
+NEEDS REVISION, MAJOR REVISION NEEDED, or NOT ASSESSED.
+
+The review mode sets its depth: `full` adds a parallel adversarial specialist
+review plus a `creative-director` senior synthesis (Phase 3b); `lean` runs all
+phases without agents; `solo` runs Phases 1–4 only with no next-step prompt.
+Phase 4 writes nothing. In Phase 5 it can update `design/gdd/systems-index.md`
+and append to `design/gdd/reviews/[doc-name]-review-log.md`, each only after the
+user approves via `AskUserQuestion`.
 
 ---
 
 ## Static Assertions (Structural)
 
-Verified automatically by `/skill-test static` — no fixture needed.
+Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
 
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings or numbered steps
-- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED
-- [ ] Does NOT require "May I write" language (read-only skill — `allowed-tools` excludes Write/Edit)
+- [ ] Contains verdict keywords: APPROVED, NEEDS REVISION, MAJOR REVISION NEEDED, NOT ASSESSED
+- [ ] `allowed-tools` includes Write/Edit, so "May I" write-approval language is present (systems-index update, review-log append)
 - [ ] Output format is documented (review template shown in skill body)
 
 ---
@@ -29,78 +38,92 @@ Verified automatically by `/skill-test static` — no fixture needed.
 ### Case 1: Happy Path — Complete GDD, all 8 sections present
 
 **Fixture:**
-- `design/gdd/light-manipulation.md` exists (use `_fixtures/minimal-game-concept.md`
-  as a stand-in — represents a complete document with all required content)
-- All 8 required sections are populated with substantive content
-- Formulas section contains at least one formula with defined variables
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/light-manipulation.md` exists with all 8 sections populated with
+  substantive content (the Detailed Rules section is titled `## Detailed Design`)
+- Formulas section defines at least one formula with named variables
 - Acceptance Criteria section contains at least 3 testable criteria
+- Every system named in its Dependencies section has a GDD in `design/gdd/`
+- No prior review log exists for this document
 
-**Input:** `/design-review design/gdd/light-manipulation.md`
+**Input:** `/design-review design/gdd/light-manipulation.md --review lean`
 
 **Expected behavior:**
-1. Skill reads the target document in full
-2. Skill reads CLAUDE.md for project context and standards
-3. Skill evaluates all 8 required sections (present/absent check)
-4. Skill checks internal consistency (formulas match described behavior)
-5. Skill checks implementability (rules are precise enough to code)
-6. Skill outputs structured review with section-by-section status
-7. Skill outputs APPROVED verdict
+1. Freshness check (`review-receipts.sh check …`) finds no receipt → full review
+2. Skill reads the target document in full and reads CLAUDE.md
+3. Skill runs `bash .claude/scripts/gdd-structure-check.sh design/gdd/light-manipulation.md`
+4. Skill Globs `design/gdd/` for each declared dependency
+5. Skill checks internal consistency, implementability and cross-system fit
+6. No agents are spawned (lean)
+7. Skill outputs the Phase 4 review, ending with the verdict
+8. On APPROVED, one multi-select `AskUserQuestion` offers the two tracking
+   updates; only the selected ones are written; then a final closing widget
 
 **Assertions:**
 - [ ] Skill reads the target file before producing any output
-- [ ] Output includes a "Completeness" section showing X/8 sections present
-- [ ] Output includes an "Internal Consistency" section
-- [ ] Output includes an "Implementability" section
-- [ ] Output ends with a verdict line: APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED
-- [ ] APPROVED verdict is given when all 8 sections are present and consistent
+- [ ] Section presence comes from `gdd-structure-check.sh`, and `## Detailed Design` is accepted as the Detailed Rules section (not flagged missing)
+- [ ] Output includes "Completeness: 8/8" (N is 8 because the tier is `full`)
+- [ ] Output includes a "Dependency Graph" section listing each declared dependency with whether its GDD exists
+- [ ] Output includes "Required Before Implementation", "Recommended Revisions" and "Scope Signal" sections, and "Re-review: No — first review"
+- [ ] Output ends with `### Verdict:` APPROVED when all REQUIRED sections are present and no blocking issue is found
+- [ ] No file is written before the tracking-records widget, and only the options the user selects are written
+- [ ] If the review-log option is selected, the appended entry includes the `review-receipts.sh hash` output for the document
 
 ---
 
-### Case 2: Failure Path — Incomplete GDD (4/8 sections)
+### Case 2: Failure Path — Incomplete GDD (4/8 sections at `full`)
 
 **Fixture:**
-- `design/gdd/light-manipulation.md` exists using content from
-  `tests/skills/_fixtures/incomplete-gdd.md` (4 of 8 sections populated;
-  Formulas, Edge Cases, Tuning Knobs, Acceptance Criteria are missing)
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/light-manipulation.md` has Overview, Player Fantasy, Detailed
+  Rules and Dependencies only; Formulas, Edge Cases, Tuning Knobs and
+  Acceptance Criteria are absent
 
-**Input:** `/design-review design/gdd/light-manipulation.md`
+**Input:** `/design-review design/gdd/light-manipulation.md --review lean`
 
 **Expected behavior:**
-1. Skill reads the document
-2. Skill identifies 4 missing sections
-3. Skill outputs "Completeness: 4/8 sections present"
-4. Skill lists specifically which 4 sections are missing
-5. Skill outputs MAJOR REVISION NEEDED verdict (not APPROVED or NEEDS REVISION)
+1. `gdd-structure-check.sh` reports the 4 sections in its `ABSENT:` list
+2. All 4 are REQUIRED at `full`, so each blocks approval
+3. Skill outputs "Completeness: 4/8" and names each missing section
+4. Verdict is a revision verdict, never APPROVED
+5. Phase 5 offers `[A] Revise the GDD now` / `[B] Stop here`; "Accept as-is" is
+   offered only when all items are advisory, which they are not here
 
 **Assertions:**
 - [ ] Output shows "4/8" in the completeness section (not a higher number)
-- [ ] Output explicitly names each missing section (Formulas, Edge Cases, Tuning Knobs, Acceptance Criteria)
-- [ ] Verdict is MAJOR REVISION NEEDED (not APPROVED or NEEDS REVISION) when ≥3 sections are missing
+- [ ] Output explicitly names each missing section (Formulas, Edge Cases, Tuning Knobs, Acceptance Criteria) as REQUIRED
+- [ ] Verdict is NEEDS REVISION or MAJOR REVISION NEEDED — never APPROVED while a REQUIRED section is missing, and not NOT ASSESSED (the document was read)
 - [ ] Output does not suggest the document is implementation-ready
-- [ ] Skill does not write any files (read-only enforcement)
+- [ ] "Accept as-is and move on" is not offered, because the missing sections are blocking
+- [ ] No file is written except after an explicit Phase 5 choice: `[A] Revise the GDD now`, "May I update `design/gdd/systems-index.md`…", or "May I append this review summary…"
+- [ ] The systems-index prompt offers `Needs Revision` or `In Review` — never `Approved` on this revision verdict — and the review-log entry records the revision verdict, not an approval
 
 ---
 
-### Case 3: Partial Path — 7/8 sections, minor inconsistency
+### Case 3: Partial Path — `standard` tier, numeric rules with no Formulas section
 
 **Fixture:**
-- GDD has all sections except Formulas
-- The described behavior mentions numeric values but no formulas are defined
-- Acceptance Criteria exist but are vague ("feels good" rather than measurable)
+- `project.yaml` sets `modes.workflow: standard`
+- GDD has Overview, Player Fantasy, `## Detailed Design`, Edge Cases,
+  Dependencies, Tuning Knobs and Acceptance Criteria; no Formulas section
+- Detailed Design states numeric rules ("drain 2 oxygen per second", "refill
+  costs 50 credits") but no formula defines them
+- Acceptance Criteria are vague ("feels good" rather than measurable)
 
-**Input:** `/design-review design/gdd/[document].md`
+**Input:** `/design-review design/gdd/oxygen.md --review lean`
 
 **Expected behavior:**
-1. Skill identifies missing Formulas section
-2. Skill flags vague acceptance criteria as an implementability issue
-3. Skill outputs NEEDS REVISION verdict (not APPROVED, not MAJOR REVISION NEEDED)
-4. Skill provides specific remediation notes for each issue
+1. Skill marks Formulas REQUIRED at `standard` because the system defines
+   numeric rules (the system's `Category` alone never clears it)
+2. N = 6 (5 standard sections + Formulas); Completeness shows 5/6, not a /8 count
+3. Skill flags the vague acceptance criteria as an implementability issue
+4. Verdict is a revision verdict
 
 **Assertions:**
-- [ ] Verdict is NEEDS REVISION (not APPROVED, not MAJOR REVISION NEEDED) for 7/8 with issues
-- [ ] Output identifies the missing Formulas section specifically
-- [ ] Output flags the vague acceptance criteria as an implementability gap
-- [ ] Each flagged issue has a specific, actionable remediation note
+- [ ] Output identifies the missing Formulas section as REQUIRED (not advisory) because numeric rules are present
+- [ ] Completeness is reported against the `standard` count ("5/6"), not "7/8"
+- [ ] Output flags the vague acceptance criteria as an implementability gap, quoting each one — the main review does this itself, since no `qa-lead` runs in `lean`
+- [ ] Verdict is NEEDS REVISION or MAJOR REVISION NEEDED, never APPROVED
 
 ---
 
@@ -109,62 +132,107 @@ Verified automatically by `/skill-test static` — no fixture needed.
 **Fixture:**
 - The path provided does not exist in the project
 
-**Input:** `/design-review design/gdd/nonexistent.md`
+**Input:** `/design-review design/gdd/nonexistent.md --review lean`
+
+(`lean`, so Phase 5 runs. In `solo` — what the review mode resolves to when
+`project.yaml` sets neither `modes.review_mode` nor `modes.rigor` — Phase 5 never
+runs and the last assertion below would test nothing.)
 
 **Expected behavior:**
-1. Skill attempts to read the file
+1. Freshness check reports no receipt; skill attempts to read the file
 2. File not found
-3. Skill outputs an error message naming the missing file
-4. Skill suggests checking the path or listing files in `design/gdd/`
-5. Skill does NOT produce a verdict
+3. Skill outputs `### Verdict: NOT ASSESSED`, naming the missing document and
+   the skill that produces it (`/design-system`)
+4. Skill does NOT produce a quality verdict or any tracking write
+5. Phase 5 skips the tracking widgets and goes to the final closing widget,
+   leading with `/design-system`
 
 **Assertions:**
-- [ ] Skill outputs a clear error when the file is not found
-- [ ] Skill does NOT output APPROVED, NEEDS REVISION, or MAJOR REVISION NEEDED when file is missing
-- [ ] Skill suggests a corrective action (check path, list available GDDs)
+- [ ] Verdict is NOT ASSESSED — not APPROVED, NEEDS REVISION or MAJOR REVISION NEEDED
+- [ ] Output names the missing file and which skill produces it
+- [ ] Phase 5 runs, and offers neither a `systems-index.md` status update nor a review-log entry — in particular it never offers to mark the system Approved
 
 ---
 
+### Case 5: Review mode — specialist delegation in `full`, none in `lean` / `solo`
+
+**Fixture (all sub-cases):**
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/light-manipulation.md` exists with all 8 sections, including
+  formulas and combat stats
+
+**Case 5a — full:** `/design-review design/gdd/light-manipulation.md --review full`
+
+**Expected behavior:**
+1. Before spawning, skill prints "Full review: spawning specialist agents in parallel…"
+2. Skill spawns the relevant specialists in parallel as real `Agent` calls —
+   `game-designer` (any gameplay system) and `systems-designer` (formulas) at minimum here
+3. After the specialists return, skill spawns `creative-director` as senior
+   reviewer; its synthesis becomes the final verdict
+4. Findings are source-tagged; disagreements are listed, not silently resolved
+
+**Assertions (5a):**
+- [ ] The notice is printed before any agent is spawned
+- [ ] Specialists are spawned in parallel via `Agent` (not simulated in-session)
+- [ ] `creative-director` is spawned only after the specialists respond, and output has a "Senior Verdict [creative-director]" section
+- [ ] "Specialists consulted:" lists the agents actually spawned, and every finding carries a source tag such as `[game-designer]`
+- [ ] Specialist disagreements appear under "Specialist Disagreements"
+- [ ] The `### Verdict:` line carries exactly one of this skill's words — APPROVED, NEEDS REVISION or MAJOR REVISION NEEDED — taken from the creative-director's synthesis; never a director-gate word such as READY, CONCERNS, NOT READY, APPROVE or REJECT
+- [ ] No director-gate IDs appear ("Gate: CD-…" etc.) — the senior review is a direct spawn, not a gate from `director-gates.md`
+
+**Case 5b — lean via the legacy flag:** `/design-review design/gdd/light-manipulation.md --depth lean`
+
+**Assertions (5b):**
+- [ ] `--depth lean` is treated as `--review lean`, and the skill says once that the flag was renamed
+- [ ] No `Agent` call is made; the review runs in-session
+- [ ] Phase 5's next-step widgets still run
+
+**Case 5c — solo:** `/design-review design/gdd/light-manipulation.md --review solo`
+
+**Assertions (5c):**
+- [ ] No `Agent` call is made
+- [ ] Only Phases 1–4 run: no Phase 5 next-step prompt, so no systems-index or review-log write is offered
+
 ---
 
-### Case 5: Director Gate — no gate spawned regardless of review mode
+### Case 6: Review mode from the resolved config — no flag
 
 **Fixture:**
+- `project.yaml` sets `modes.workflow: full` and `modes.review_mode: lean`
 - `design/gdd/light-manipulation.md` exists with all 8 sections
-- `production/session-state/review-mode.txt` exists with `full` (most permissive mode)
 
-**Input:** `/design-review design/gdd/light-manipulation.md` (with full review mode active)
+**Input:** `/design-review design/gdd/light-manipulation.md`
 
 **Expected behavior:**
-1. Skill reads the GDD document
-2. Skill does NOT read `review-mode.txt` — this skill has no director gates
-3. Skill produces the review output normally
-4. No director gate agents are spawned at any point
-5. Verdict is APPROVED (all 8 sections present in fixture)
+1. No `--review` flag, so the skill takes `review_mode: lean` from the resolved
+   config block at the top of the skill
+2. The review runs in-session with no `Agent` call
+3. Phase 5's widgets run — which `solo`, the `rigor: minimal` default, would have skipped
 
 **Assertions:**
-- [ ] Skill does NOT spawn any director gate agent (CD-, TD-, PR-, AD- prefixed agents)
-- [ ] Skill does NOT read `review-mode.txt` or equivalent mode file
-- [ ] The `--review` flag or `full` mode state has NO effect on whether directors spawn
-- [ ] Output does not contain any "Gate: [GATE-ID]" entries
-- [ ] Skill IS the review — it does not delegate the review to a director
+- [ ] The review mode comes from the resolved config block when no flag is given (`review_mode: lean (project.yaml)`)
+- [ ] No `Agent` call is made, and Phase 5's next-step widgets run — so the run is `lean`, not the `solo` default
+- [ ] Variant — the same fixture with `--review solo` on the input: the flag wins over the config, and no Phase 5 widget runs
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Does NOT use Write or Edit tools (read-only skill)
-- [ ] Presents complete findings before any verdict
-- [ ] Does not ask for approval before producing output (no writes to approve)
-- [ ] Ends with recommended next step (e.g., fix issues and re-run, or proceed to `/map-systems`)
+- [ ] Writes nothing during the review itself (Phase 4)
+- [ ] Every write (systems-index status, review-log append) happens only after an `AskUserQuestion` approval
+- [ ] Presents complete findings before the verdict line
+- [ ] Outside `solo`, closes with an `AskUserQuestion` next-step widget rather than plain text (collaborative/guided modes)
 
 ---
 
 ## Coverage Notes
 
-- Cross-system consistency checking (Case 3 in the skill's own phase list) is
-  not directly tested here because it requires multiple GDD files to compare;
-  this is covered by the `/review-all-gdds` spec instead.
-- The skill's `context: fork` behavior (running as a subagent) is not tested
-  at the spec level — this is a runtime behavior verified manually.
+- Cross-system consistency across many GDDs is covered by the `/review-all-gdds`
+  spec; this spec checks only one document's dependency references.
+- The freshness receipt paths (byte-identical re-review offering the prior
+  verdict; registry-only change) are not fixture-tested here.
+- The entity-registry grep path (registry lists this system) is not tested; the
+  fixtures above use the fallback of reading the GDDs named in Dependencies.
+- The `minimal` tier (no GDD expected; standard sections checked advisorily) is
+  not tested.
 - Performance and edge cases involving very large GDD files are not in scope.

CCGS Skill Testing Framework/skills/review/review-all-gdds.md

@@ -2,38 +2,42 @@
 
 ## Skill Summary
 
-`/review-all-gdds` is an Opus-tier skill that performs a holistic cross-GDD review
-across all files in `design/gdd/`. It runs two complementary review phases in
-parallel: Phase 1 checks for consistency (contradictions, formula mismatches,
-stale references, competing ownership), and Phase 2 checks design theory (dominant
-strategies, pillar drift, cognitive overload, economic imbalance). Because the two
-phases are independent, they are spawned simultaneously to save time. The skill
-produces a CONSISTENT / MINOR ISSUES / MAJOR ISSUES verdict and is read-only — no
-files are written without explicit user approval.
+`/review-all-gdds` is an Opus-tier skill that performs a holistic cross-GDD
+review across the system GDDs in `design/gdd/`. After loading everything
+(Phase 1), it runs two independent reviews in parallel as `game-designer`
+sub-agents: Phase 2, Cross-GDD Consistency (dependency bidirectionality, rule
+contradictions, stale references, ownership conflicts, formula compatibility,
+acceptance-criteria conflicts), and Phase 3, Game Design Holism (competing
+progression loops, attention budget, dominant strategies, economic loops,
+difficulty curves, pillar alignment, player-fantasy coherence). Phase 4 walks
+multi-system scenarios. It produces a PASS / NOT ASSESSED / CONCERNS / FAIL
+verdict, and writes `design/gdd/gdd-cross-review-[YYYY-MM-DD].md` and
+systems-index "Needs Revision" statuses only after the user approves.
 
-The skill is itself the holistic review gate in the pipeline. It is invoked after
-individual GDDs are complete and before architecture work begins. It does NOT spawn
-any director gate agents (it IS the director-level review).
+It is invoked after individual GDDs are approved and before architecture work.
+It spawns no director gate agents. At `workflow: minimal` it does not apply (no
+GDDs), so every fixture below sets `modes.workflow: full`.
 
 ---
 
 ## Static Assertions (Structural)
 
-Verified automatically by `/skill-test static` — no fixture needed.
+Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
 
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥5 phase headings (complex multi-phase skill)
-- [ ] Contains verdict keywords: CONSISTENT, MINOR ISSUES, MAJOR ISSUES
-- [ ] Does NOT require "May I write" language (read-only skill)
+- [ ] Contains verdict keywords: PASS, NOT ASSESSED, CONCERNS, FAIL
+- [ ] `allowed-tools` includes Write, so "May I write" language is present (Phase 6 report write)
 - [ ] Has a next-step handoff at the end
-- [ ] Documents parallel phase spawning (Phase 1 and Phase 2 are independent)
+- [ ] Documents parallel spawning of Phase 2 (Consistency) and Phase 3 (Design Theory)
 
 ---
 
 ## Director Gate Checks
 
-No director gates — this skill spawns no director gate agents. It IS the holistic
-review; delegating to a director gate would create a circular dependency.
+No director gates — this skill spawns no director gate agents and resolves no
+review mode. It IS the holistic review; its only agents are the two
+`game-designer` sub-agents for Phases 2 and 3.
 
 ---
 
@@ -42,137 +46,202 @@ review; delegating to a director gate would create a circular dependency.
 ### Case 1: Happy Path — Clean GDD set with no conflicts
 
 **Fixture:**
-- `design/gdd/` contains ≥3 system GDDs
-- All GDDs are internally consistent: no formula contradictions, no competing ownership, no stale references
-- All GDDs align with the pillars defined in `design/gdd/game-pillars.md`
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/` contains `game-concept.md`, `game-pillars.md` (pillars and
+  anti-pillars), `systems-index.md`, and three system GDDs — `combat.md`,
+  `inventory.md`, `crafting.md` — each with every section Phase 1c loads and a
+  filled `## Cross-References` table whose rows all resolve
+- All GDDs are consistent: no formula contradictions, no competing ownership,
+  no stale references, reciprocal dependencies; every system serves a pillar
+- Nothing a design-theory check would warn on either: one primary progression
+  loop, at most 4 systems active at once, every resource has both a source and a
+  sink, compatible scaling curves, compatible player fantasies
 
 **Input:** `/review-all-gdds`
 
 **Expected behavior:**
-1. Skill reads all GDD files in `design/gdd/`
-2. Phase 1 (consistency scan) and Phase 2 (design theory check) spawn in parallel
-3. Phase 1 finds no contradictions, no formula mismatches, no ownership conflicts
-4. Phase 2 finds no pillar drift, no dominant strategies, no cognitive overload
-5. Skill outputs a structured findings table with 0 blocking issues
-6. Verdict: CONSISTENT
+1. Skill greps `## Summary` across `design/gdd/*.md` and shows a manifest ("Found [N] GDDs. Summaries: …")
+2. Skill reads the entity registry, or notes that it is empty and suggests `/consistency-check`
+3. Skill loads the review sections and reports "Loaded [N] system GDDs covering [M] systems. Pillars: […]. Anti-pillars: […]."
+4. Phase 2 and Phase 3 spawn simultaneously as `game-designer` sub-agents, each
+   given the pasted GDD content for its slice (not file paths) and its checklist (2a–2f / 3a–3g)
+5. Phase 4 walks 3–5 multi-system scenarios
+6. Report shows no blocking issues and no warnings; verdict PASS
+7. `AskUserQuestion`: "May I write this review to `design/gdd/gdd-cross-review-[date].md`?"
+8. Closing widget built from project state
 
 **Assertions:**
-- [ ] Both review phases are spawned in parallel (not sequentially)
-- [ ] Output includes a findings table (even if empty — shows "No issues found")
-- [ ] Verdict is CONSISTENT when no conflicts are found
-- [ ] Skill does NOT write any files without user approval
-- [ ] Next-step handoff to `/architecture-review` or `/create-architecture` is present
+- [ ] Phase 2 and Phase 3 are spawned in parallel (both `Agent` calls issued before either result is awaited)
+- [ ] Sub-agent prompts carry the GDD section content, not just file paths
+- [ ] The report states the covered set: `GDDs reviewed: [N] of [M] present` and `Not read: none`, and lists the scenarios walked
+- [ ] Verdict is PASS only because there are no blocking issues **and no warnings**, over three readable GDDs — a single warning would make it CONCERNS
+- [ ] The report is written only after the user approves, under an ISO-dated name (`gdd-cross-review-YYYY-MM-DD.md`)
+- [ ] The closing widget offers `/create-architecture` and `/gate-check` (both allowed on PASS)
 
 ---
 
 ### Case 2: Failure Path — Conflicting rules between two GDDs
 
 **Fixture:**
-- GDD-A defines a floor value (e.g. "minimum [output] is [N]")
-- GDD-B states a mechanic that bypasses that floor (e.g. "[mechanic] can reduce [output] to 0")
-- The two GDDs are otherwise complete and valid
+- `project.yaml` sets `modes.workflow: full`
+- `combat.md` defines a floor: "Minimum damage after armour reduction is 1"
+- `status-effects.md` states a mechanic that bypasses it: "Poison ignores armour
+  and can reduce damage to 0"
+- The two GDDs are otherwise complete and valid; `game-pillars.md` defines the
+  pillars and `systems-index.md` lists both systems
 
 **Input:** `/review-all-gdds`
 
 **Expected behavior:**
-1. Phase 1 (consistency scan) detects the contradiction between GDD-A and GDD-B
-2. Conflict is reported with: both filenames, the specific conflicting rules, and severity HIGH
-3. Verdict: MAJOR ISSUES
-4. Handoff instructs user to resolve the conflict and re-run before proceeding
+1. Phase 2 detects the floor/ceiling contradiction
+2. Report prints a `🔴 Rule Contradiction` entry quoting both rules and asking which GDD is authoritative
+3. The issue sits under Consistency Issues → Blocking; both GDDs appear in "GDDs Flagged for Revision"
+4. Verdict: FAIL, with "If FAIL — required actions before re-running"
+5. After the report write question, a second `AskUserQuestion` offers to mark the flagged GDDs `Needs Revision` in `systems-index.md`
 
 **Assertions:**
-- [ ] Verdict is MAJOR ISSUES (not CONSISTENT or MINOR ISSUES)
+- [ ] Verdict is FAIL (not PASS, CONCERNS or NOT ASSESSED)
 - [ ] Both GDD filenames are named in the conflict entry
-- [ ] The specific contradicting rules are quoted or described (not vague "conflict found")
-- [ ] Issue is classified as severity HIGH (blocking)
-- [ ] Skill does NOT auto-resolve the conflict
+- [ ] The specific contradicting rules are quoted (not a vague "conflict found")
+- [ ] The issue is classified as Blocking (🔴), and both GDDs are in the flagged table with Priority Blocking
+- [ ] Skill does NOT decide which GDD is right and does NOT edit either GDD
+- [ ] If the user approves the systems-index update, the status is written as exactly `Needs Revision` with no parenthetical
+- [ ] The closing widget offers neither `/create-architecture` nor `/gate-check` (verdict is FAIL)
 
 ---
 
-### Case 3: Partial Path — Single GDD with orphaned dependency reference
+### Case 3: Partial Path — Cross-reference to a GDD that does not exist
 
 **Fixture:**
-- GDD-A lists a dependency in its Dependencies section pointing to "system-B"
-- No GDD for system-B exists in `design/gdd/`
-- All other GDDs are consistent
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/` holds `game-pillars.md`, `systems-index.md` and two consistent
+  system GDDs, `crafting.md` and `inventory.md`
+- `crafting.md`'s `## Cross-References` table has a row whose Target GDD is
+  `system-b.md`; no `design/gdd/system-b.md` exists
+- `systems-index.md` lists system-b as the next system with Status: Not Started
+- Nothing else would warn
 
 **Input:** `/review-all-gdds`
 
 **Expected behavior:**
-1. Phase 1 detects the orphaned dependency reference in GDD-A
-2. Issue is reported as: DEPENDENCY GAP — GDD-A references system-B which has no GDD
-3. No other conflicts found
-4. Verdict: MINOR ISSUES (dependency gap is advisory, not blocking by itself)
+1. Phase 2's stale-reference check (2c) confirms each Cross-References row's
+   Target GDD exists, and finds `system-b.md` missing
+2. Because `systems-index.md` lists system-b, the reference is a dependency on
+   planned work: a `⚠️ Stale Reference` Warning naming `crafting.md` and the
+   missing target, to re-check when that GDD is written
+3. No other issues found; verdict CONCERNS (warnings, nothing blocking)
+4. Closing widget includes `/design-system system-b` (next in design order)
 
 **Assertions:**
-- [ ] Verdict is MINOR ISSUES (not MAJOR ISSUES for a single orphaned reference)
-- [ ] The specific GDD filename and the missing dependency name are reported
-- [ ] Skill suggests running `/design-system system-B` to resolve the gap
-- [ ] Skill does NOT skip or silently ignore the missing dependency
+- [ ] The finding names `crafting.md` and the missing `system-b.md`
+- [ ] It is reported under Warnings (⚠️), not Blocking — because the systems index lists system-b as planned
+- [ ] Verdict is CONCERNS — not FAIL for a reference to planned work, and not an unqualified PASS
+- [ ] The closing widget offers `/design-system system-b`, and offers `/create-architecture` but not `/gate-check` (which requires PASS)
+- [ ] Skill does NOT skip or silently ignore the missing target
+
+**Case 3b — the target is in neither place:** the same fixture, except
+`systems-index.md` has no entry for system-b. Nothing will ever define it.
+
+**Assertions (3b):**
+- [ ] The reference is reported as 🔴 Blocking, and `crafting.md` appears in "GDDs Flagged for Revision" with Priority Blocking
+- [ ] Verdict is FAIL, and the closing widget offers neither `/create-architecture` nor `/gate-check`
 
 ---
 
-### Case 4: Edge Case — No GDD files found
+### Case 4: Edge Case — Fewer than two system GDDs
 
 **Fixture:**
-- `design/gdd/` directory is empty or does not exist
-- No GDD files are present
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/` contains `systems-index.md` and a single system GDD, `combat.md`
 
 **Input:** `/review-all-gdds`
 
 **Expected behavior:**
-1. Skill attempts to read files in `design/gdd/`
-2. No files found — skill outputs an error with guidance
-3. Skill recommends running `/brainstorm` and `/design-system` before re-running
-4. Skill does NOT produce a verdict (CONSISTENT / MINOR ISSUES / MAJOR ISSUES)
+1. Skill loads what exists and counts the system GDDs
+2. Fewer than 2 → skill stops with: "Cross-GDD review requires at least 2 system
+   GDDs. Write more GDDs first, then re-run `/review-all-gdds`."
+3. No review phase runs and no report is offered
 
 **Assertions:**
-- [ ] Skill outputs a clear error message when no GDDs are found
-- [ ] No verdict is produced when the directory is empty
-- [ ] Skill recommends the correct next action (`/brainstorm` or `/design-system`)
-- [ ] Skill does NOT crash or produce a partial report
+- [ ] Skill outputs the "requires at least 2 system GDDs" stop message
+- [ ] Neither Phase 2 nor Phase 3 sub-agent is spawned
+- [ ] No verdict of PASS is produced for the single document
+- [ ] No report write is offered and no file is written
 
 ---
 
-### Case 5: Director Gate — No gate spawned regardless of review mode
+### Case 5: Director Gate — none spawned, whatever the review mode
 
 **Fixture:**
-- `design/gdd/` contains ≥2 consistent system GDDs
-- `production/session-state/review-mode.txt` exists with content `full`
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/` holds the Case 1 set: concept, pillars, systems index and three
+  consistent system GDDs
+- 5a: `modes.review_mode: full`; 5b: `modes.review_mode: solo`
 
 **Input:** `/review-all-gdds`
 
 **Expected behavior:**
-1. Skill reads all GDDs and runs the two review phases
-2. Skill does NOT read `review-mode.txt`
-3. Skill does NOT spawn any director gate agent (CD-, TD-, PR-, AD- prefixed)
-4. Skill completes and outputs its verdict normally
-5. Review mode setting has no effect on this skill's behavior
+1. The resolved config block requests only `automation`, `workflow` and
+   `system_overrides` — review mode is not consulted
+2. In both 5a and 5b, the same two `game-designer` sub-agents run Phases 2 and 3
+3. No director gate agent is spawned; the verdict is produced normally
 
 **Assertions:**
-- [ ] No director gate agents are spawned at any point
-- [ ] Skill does NOT read `production/session-state/review-mode.txt`
-- [ ] Output does not contain any "Gate: [GATE-ID]" or "skipped" gate entries
-- [ ] The skill produces a verdict regardless of review mode
-- [ ] R4 metric: gate count for this skill = 0 in all modes
+- [ ] No director gate agents (CD-, TD-, PR-, AD-, LP- prefixed gates) are spawned in either mode
+- [ ] Review mode changes nothing: under `solo` the two `game-designer` sub-agents still run
+- [ ] Output contains no "Gate: [GATE-ID]" or "[GATE-ID] skipped" entries
+- [ ] The skill produces a verdict in both modes
+- [ ] The only `Agent` spawns in the run are the Phase 2 and Phase 3 `game-designer` sub-agents
+
+---
+
+### Case 6: NOT ASSESSED — fewer than two readable GDDs
+
+**Fixture:**
+- `project.yaml` sets `modes.workflow: full`
+- `design/gdd/` holds `game-pillars.md`, `systems-index.md` and two system GDDs:
+  `combat.md`, complete, and `inventory.md`, which has the template's headings but
+  only placeholder text under them
+
+**Input:** `/review-all-gdds`
+
+**Expected behavior:**
+1. Two system GDDs exist, so the "requires at least 2 system GDDs" stop does not fire
+2. `inventory.md` is present but empty — not reviewable — so only one GDD can be
+   compared, and a clean result would mean only that nothing was compared
+3. Verdict NOT ASSESSED; "If NOT ASSESSED — what could not be reviewed, and why"
+   names `inventory.md` as placeholder-only and says a cross-review needs two
+   readable GDDs
+4. The report states `GDDs reviewed: 1 of 2 present`
+
+**Assertions:**
+- [ ] Verdict is NOT ASSESSED — not PASS, although no contradiction was found
+- [ ] The report names `inventory.md` as present but not reviewable, and states `GDDs reviewed: 1 of 2 present`
+- [ ] A GDD that could not be read at all would be named on the report's `Not read:` line under every verdict, and is a NOT ASSESSED trigger like an empty one
+- [ ] The closing widget offers neither `/create-architecture` nor `/gate-check`
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Phase 1 (consistency) and Phase 2 (design theory) spawned in parallel — not sequentially
-- [ ] Does NOT write any files without "May I write" approval
-- [ ] Findings table shown before any write ask
-- [ ] Verdict is one of exactly: CONSISTENT, MINOR ISSUES, MAJOR ISSUES
-- [ ] Ends with appropriate handoff: MAJOR ISSUES → fix and re-run; MINOR ISSUES → may proceed with awareness; CONSISTENT → `/create-architecture`
+- [ ] Phase 2 (Consistency) and Phase 3 (Design Theory) spawned in parallel — not sequentially
+- [ ] The full analysis is shown before any write is requested
+- [ ] Does NOT write the report or update `systems-index.md` without `AskUserQuestion` approval
+- [ ] Verdict is one of exactly: PASS, NOT ASSESSED, CONCERNS, FAIL
+- [ ] Every issue cites the GDD, section and text involved
+- [ ] Ends with an `AskUserQuestion` handoff built from the verdict: FAIL or NOT ASSESSED → neither `/create-architecture` nor `/gate-check`; CONCERNS → `/create-architecture` only; PASS → both
 
 ---
 
 ## Coverage Notes
 
-- Economic balance analysis (source/sink loops) requires cross-GDD resource data — covered
-  structurally by Case 2 (the conflict detection pattern is the same).
-- The design theory phase (Phase 2) checks including dominant strategy detection and
-  cognitive overload are not individually fixture-tested — they follow the same
-  pattern as consistency checks and are validated via the pillar drift case structure.
-- The `since-last-review` scoping mode is not tested here — it is a runtime concern.
+- Economic loop analysis (3d, source/sink loops) is not fixture-tested. Case 2
+  exercises Phase 2's rule-contradiction check — a different checklist, run by
+  the other sub-agent — so it says nothing about 3d.
+- The design theory phase (Phase 3) checks, including dominant strategy detection
+  and cognitive overload, are not individually fixture-tested.
+- Case 6 covers the fewer-than-two-readable-GDDs trigger, through a
+  present-but-empty GDD. The NOT ASSESSED triggers for undefined pillars and for
+  a sub-agent that returns no report are not fixture-tested.
+- The `since-last-review` mode (`.claude/scripts/review-scope.sh`) and the
+  `consistency` / `design-theory` focus modes are not tested here.