Release 1.1.0 — one config file, and a process weight you choose

`project.yaml` at the repo root is now the single source of truth for a
project's configuration, replacing `production/stage.txt`,
`production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all
three still read as a fallback; nothing is force-deleted).

**`modes.rigor` — one question instead of six.** `minimal`, `standard` or
`full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`,
`modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to
`minimal`, which is a change from 1.0's behaviour: the heavier tier was
measured costing several times more to reach working code without producing a
better result, and returning nothing when a fresh developer inherited the
project. Pin `modes.rigor: standard` to keep 1.0's process level.

Also in this release:

- `/settings` to view or change any setting, and `project.local.yaml` for
  per-developer preferences that should not be committed.
- `system_overrides` to hold one system to a higher standard than the rest of
  the project, and `testing.strict` to set per test type whether missing
  evidence blocks a story or warns.
- A story that changes anything the player sees is not closed until the game
  has been launched, observed, and a screenshot retained in
  `production/qa/evidence/`. A parse check is not a run. This holds at every
  rigor level, including `minimal`, where automated tests are waived but the
  look is not.
- The code root is engine-specific and enforced as such: Godot `src/`, Unity
  `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a
  project laid out any other way.
- Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh`
  converts a 1.0 layout, non-destructively by default, with a report to review
  before `--finalize` deletes anything.
- Ask-before-write holds regardless of personal automation settings.

Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes:
CHANGELOG.md.

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

.claude/skills/map-systems/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: map-systems
-description: "Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index."
+description: "Decompose a concept into individual systems, map dependencies, prioritize design order, create the systems index."
 argument-hint: "[next | system-name] [--review full|lean|solo]"
 user-invocable: true
-allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite, Task
+allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Agent
 model: sonnet
 ---
 
+!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && resolve_config --keys review_mode,automation,workflow,docs.density`
+
+Resolved above — use as-is; `--review` overrides `review_mode`. No block →
+defaults in `.claude/docs/config-resolution.md`.
+
+
 When this skill is invoked:
 
 ## Parse Arguments
@@ -18,12 +24,46 @@ Two modes:
 - **`next`**: `/map-systems next` — Pick the highest-priority undesigned system
   from the index and hand off to `/design-system` (Phase 6).
 
-Also resolve the review mode (once, store for all gate spawns this run):
-1. If `--review [full|lean|solo]` was passed → use that
-2. Else read `production/review-mode.txt` → use that value
-3. Else → default to `lean`
 
-See `.claude/docs/director-gates.md` for the full check pattern.
+See `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.
+
+
+Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`
+(collaborative asks always · guided major-only · autonomous logs and proceeds;
+`automation_always_ask` categories always prompt).
+
+**`docs.density`** — it controls per-section *depth*, where `workflow`
+controls which sections exist. `modes.rigor` sets both together; set
+`docs.density` explicitly to vary depth alone: `terse` = one-line system descriptions;
+`balanced` = a brief paragraph per system + dependency notes (default);
+`thorough` = full system-by-system rationale + relationship analysis. Apply it to
+every section you author.
+
+> **Where the per-system prose goes.** `templates/systems-index.md`'s Systems
+> Enumeration is a fixed-column table with no description column, so at
+> `balanced` and `thorough` the prose belongs in `## Overview` — one short
+> paragraph per system at `balanced`, plus relationship analysis at `thorough` —
+> and in the `## Dependency Map` layer notes. **Do not add a column to the
+> enumeration table** — it is a fixed contract in
+> `.claude/docs/templates/systems-index.md`, and its consumers
+> (`/design-system` §6 and §7, `/create-epics`) are written against the columns it
+> defines. Widening it is a schema change, not a formatting choice.
+>
+> **How the consumers actually read it.** Nothing parses this table
+> positionally. The two scripts that mention `systems-index.md`
+> (`gdd-structure-check.sh:51`, `review-scope.sh:40`) match it **by filename** in a
+> `case` statement and parse no columns at all; the two skills key on the
+> **`Category` column by name** (`design-system:229`, `:780`). So `Category` is
+> the column that must never be renamed or dropped, and the table stays a fixed
+> contract because every consumer is written against the set of columns the
+> template defines.
+> At `terse`, the table plus a one-paragraph `## Overview` is the whole output.
+
+**`workflow`** (see `.claude/docs/workflow-modes.md`):
+- `full` / `standard` — required before `/design-system` (systems must be mapped
+  before per-system GDDs are authored).
+- `minimal` — not required (the game brief replaces the systems index). Can
+  still be run voluntarily.
 
 ---
 
@@ -33,9 +73,10 @@ Read the game concept and any existing design work. This provides the raw materi
 for systems decomposition.
 
 **Required:**
-- Read `design/gdd/game-concept.md` — **fail with a clear message if missing**:
-  > "No game concept found at `design/gdd/game-concept.md`. Run `/brainstorm` first
-  > to create one, then come back to decompose it into systems."
+- Read `design/gdd/game-concept.md` (at `minimal`, read `design/game-brief.md`
+  instead) — **fail with a clear message if neither is found**:
+  > "No game concept found. Run `/brainstorm` first to create one, then come back
+  > to decompose it into systems."
 
 **Optional (read if they exist):**
 - Read `design/gdd/game-pillars.md` — pillars constrain priority and scope
@@ -102,7 +143,16 @@ Then use `AskUserQuestion` to capture feedback:
 - "Should any of these be combined or split?"
 - "Are there systems listed that this game does NOT need?"
 
-Iterate until the user approves the enumeration.
+**At `collaborative`** — iterate until the user approves the enumeration.
+**At `guided`** — ask once, apply the answer, and proceed; do not loop.
+**At `autonomous`** — do not ask. Record the enumeration and its inferred systems
+via `log_decision` and proceed.
+
+> **The loop needed an exit that does not depend on being asked.**
+> `automation-modes.md:56` defines `autonomous` as *"No `AskUserQuestion`"*, so a
+> loop terminating on "the user approves" has no termination path there at all.
+> Same class as Step 5b, one level up: that was an unconditional *write* gate,
+> this is an unconditional *control-flow loop* around the question.
 
 ---
 
@@ -150,7 +200,7 @@ dependencies I'm missing or that should be removed?"
 - `lean` → skip (not a PHASE-GATE). Note: "TD-SYSTEM-BOUNDARY skipped — Lean mode." Proceed to priority assignment.
 - `full` → spawn as normal.
 
-**After dependency mapping is approved, spawn `technical-director` via Task using gate TD-SYSTEM-BOUNDARY (`.claude/docs/director-gates.md`) before proceeding to priority assignment.**
+**After dependency mapping is approved, spawn `technical-director` via `Agent` using gate TD-SYSTEM-BOUNDARY (`.claude/docs/director-gates/td-system-boundary.md`) before proceeding to priority assignment.**
 
 Pass: the dependency map summary, layer assignments, bottleneck systems list, any circular dependency resolutions.
 
@@ -182,19 +232,37 @@ Which systems should be higher or lower priority?"
 Explain reasoning in conversation: "I placed [system] in MVP because the core loop
 requires it — without [system], the 30-second loop can't function."
 
-**"Why" column guidance**: When explaining why each system was placed in a priority tier, mix technical necessity with player-experience reasoning. Do not use purely technical justifications like "Combat needs damage math" — connect to player experience where relevant. Examples of good "Why" entries:
-- "Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)"
-- "Ballista's punch-through identity is established here — this stat definition is what makes it feel different from Archer"
-- "Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices"
+**How to phrase the reasoning** — this governs what you *say*, not a column you
+write. Neither table has a `Why` column: Systems Enumeration is
+`# / Name / Category / Priority / Status / Design Doc / Depends On`, and
+Recommended Design Order is `Order / System / Priority / Layer / Agent(s) /
+Est. Effort`. The rationale lives in the conversation above and, for anything
+the user should still see after the session, in the index's `## Overview`
+paragraph. Do not invent a column for it.
 
-Pure technical necessity ("X depends on Y") is insufficient alone when the system directly shapes player experience.
+Mix technical necessity with player-experience reasoning. A purely technical
+justification — "the damage system needs damage math" — is insufficient on its
+own when the system directly shapes what the player feels. Good reasoning names
+both, and cites the pillar it serves:
+- "Required for the core loop — without it the player's main choice has no
+  consequence (Pillar [N]: [pillar name])"
+- "This is where [system]'s identity is established — the stat definitions here
+  are what make it feel different from [the sibling system]"
+- "Foundation for every later economy decision — the player must understand
+  costs before any of the choices built on top of it mean anything"
+
+> **Fill the brackets from *this* project.** The bracketed slots are not
+> decoration. Worked examples from another genre (a tower-defense "Ballista's
+> punch-through identity… what makes it feel different from Archer", "Pillar 2:
+> Placement is the Puzzle") get reproduced verbatim by a run against a different
+> game, which then carries that game's vocabulary instead of its own.
 
 **Review mode check** — apply before spawning PR-SCOPE:
 - `solo` → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to writing the systems index.
 - `lean` → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to writing the systems index.
 - `full` → spawn as normal.
 
-**After priorities are approved, spawn `producer` via Task using gate PR-SCOPE (`.claude/docs/director-gates.md`) before writing the index.**
+**After priorities are approved, spawn `producer` via `Agent` using gate PR-SCOPE (`.claude/docs/director-gates/pr-scope.md`) before writing the index.**
 
 Pass: total system count per milestone tier, estimated implementation volume per tier (system count × average complexity), team size, stated project timeline.
 
@@ -233,20 +301,34 @@ Present a summary of the document:
 - First 3 systems in the design order
 - Any high-risk items
 
-Ask: "May I write the systems index to `design/gdd/systems-index.md`?"
+**At `automation: collaborative`** — ask: "May I write the systems index to
+`design/gdd/systems-index.md`?" Wait for approval. Write the file only after
+"yes."
 
-Wait for approval. Write the file only after "yes."
+**At `automation: guided`** — present the summary above, name the destination
+(`design/gdd/systems-index.md`), and write it without waiting for an explicit
+"yes", per `.claude/docs/automation-modes.md`. Say what you wrote afterwards.
+
+> **Keep this line scoped to its mode.** `automation-modes.md` says `guided`
+> *"proceeds after a short summary, does not wait for explicit yes"*, and this
+> skill's own Collaborative Protocol section is scoped to `collaborative`. An
+> unconditional "wait for approval" here collides with both.
 
 **Review mode check** — apply before spawning CD-SYSTEMS:
 - `solo` → skip. Note: "CD-SYSTEMS skipped — Solo mode." Proceed to Phase 7 next steps.
 - `lean` → skip (not a PHASE-GATE). Note: "CD-SYSTEMS skipped — Lean mode." Proceed to Phase 7 next steps.
 - `full` → spawn as normal.
 
-**After the systems index is written, spawn `creative-director` via Task using gate CD-SYSTEMS (`.claude/docs/director-gates.md`).**
+**After the systems index is written, spawn `creative-director` via `Agent` using gate CD-SYSTEMS (`.claude/docs/director-gates/cd-systems.md`).**
 
 Pass: systems index path, game pillars and core fantasy (from `design/gdd/game-concept.md`), MVP priority tier system list.
 
-Present the assessment. If REJECT, revise the system set with the user before GDD authoring begins. If CONCERNS, record them in the systems index as a `> **Creative Director Note**` at the top of the relevant tier section.
+Present the assessment. If REJECT, revise the system set with the user before GDD authoring begins. If CONCERNS, record them in the systems index as a `> **Creative Director Note**`
+placed **directly beneath the `## Priority Tiers` table**, naming the tier each
+concern applies to — e.g. `> **Creative Director Note** (MVP): …`.
+`templates/systems-index.md` has a Priority Tiers *definition table*, not a
+section per tier, so there is no "top of the tier section" to write to — do not
+direct the writer to one.
 
 ### Step 5c: Update Session State
 
@@ -326,6 +408,10 @@ After any individual GDD is completed:
 
 ## Collaborative Protocol
 
+**Applies in `collaborative` mode (the default).** For `guided` and
+`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below
+describe what collaborative mode requires, not universal behavior.
+
 This skill follows the collaborative design principle at every phase:
 
 1. **Question -> Options -> Decision -> Draft -> Approval** at every step