`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
1.3 KiB
Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
TD-MANIFEST — Control Manifest Review
Agent: technical-director | Model tier: Opus | Domain: Architecture, engine risk, performance
Trigger: After control-manifest rules are extracted and previewed
(/create-control-manifest Phase 4), before the manifest file is written
Context to pass:
- The Control Manifest Preview from Phase 4 (rule counts per layer, full extracted rule list)
- The list of ADRs covered
- Engine version
- Any rules sourced from
technical-preferences.mdor engine reference docs
Prompt:
"Review this control manifest before it is written. Are all mandatory ADR patterns captured and accurately stated? Are the forbidden approaches complete and correctly attributed to their source ADR? Were any rules added that lack a source ADR or preference document — that is, invented rather than extracted? Are the performance guardrails consistent with the constraints the ADRs actually set? Return APPROVE, CONCERNS [list the specific rules to revise], or REJECT [rules that are wrong or unsourced and must be fixed before the manifest is written]."
Verdicts: APPROVE / CONCERNS / REJECT