DonchitosandClaude Opus 5
d05699707f
`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
6.2 KiB
Agent Test Spec: technical-director
Agent Summary
Domain owned: System architecture decisions, technical feasibility assessment, ADR oversight and approval, engine risk evaluation, technical phase gate. Does NOT own: Game design decisions (creative-director / game-designer), creative direction, visual art style, production scheduling (producer). Model tier: Opus (multi-document synthesis, high-stakes architecture and phase gate verdicts). Gate IDs handled: TD-SYSTEM-BOUNDARY, TD-FEASIBILITY, TD-ARCHITECTURE, TD-ADR, TD-ENGINE-RISK, TD-PHASE-GATE.
Static Assertions (Structural)
Verified by reading the agent's .claude/agents/technical-director.md frontmatter:
description:field is present and domain-specific (references architecture, feasibility, ADR — not generic)allowed-tools:list may include Read for architecture documents; Bash only if required for technical checks- Model tier is
claude-opus-4-8per coordination-rules.md (directors with gate synthesis = Opus) - Agent definition does not claim authority over game design decisions or creative direction
Test Cases
Case 1: In-domain request — appropriate output format
Scenario: An architecture document for the "Combat System" is submitted. It describes a layered design: input layer → game logic layer → presentation layer, with clearly defined interfaces between each. Request is tagged TD-ARCHITECTURE.
Expected: Returns TD-ARCHITECTURE: APPROVE with rationale confirming that system boundaries are correctly separated and interfaces are well-defined.
Assertions:
- Verdict is exactly one of APPROVE / CONCERNS / REJECT
- Verdict token is formatted as
TD-ARCHITECTURE: APPROVE - Rationale specifically references the layered structure and interface definitions — not generic architecture advice
- Output stays within technical scope — does not comment on whether the mechanic is fun or fits the creative vision
Case 2: Out-of-domain request — redirects or escalates
Scenario: Writer asks technical-director to review and approve the dialogue scripts for the game's opening cutscene. Expected: Agent declines to evaluate dialogue quality and redirects to narrative-director. Assertions:
- Does not make any binding decision about the dialogue content or structure
- Explicitly names
narrative-directoras the correct handler - May note technical constraints that affect dialogue (e.g., localization string limits, data format), but defers all content decisions
Case 3: Gate verdict — correct vocabulary
Scenario: A proposed multiplayer mechanic requires raycasting against all active entities every frame to detect line-of-sight. At expected player counts (1000 entities in a large zone), this is O(n²) per frame. Request is tagged TD-FEASIBILITY.
Expected: Returns TD-FEASIBILITY: CONCERNS with specific citation of the O(n²) complexity and the entity count that makes this infeasible at target framerate.
Assertions:
- Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
- Verdict token is formatted as
TD-FEASIBILITY: CONCERNS - Rationale includes the specific algorithmic complexity concern and the entity count threshold
- Suggests at least one alternative approach (e.g., spatial partitioning, interest management) without mandating which to choose
Case 4: Conflict escalation — correct parent
Scenario: game-designer wants to add a real-time physics simulation for every inventory item (hundreds of items on screen simultaneously). technical-director assesses this as technically expensive and proposes simplifying the simulation. game-designer disagrees, arguing it is essential to the game feel. Expected: technical-director clearly states the technical cost and constraints, proposes alternative implementation approaches that could achieve a similar feel, but explicitly defers the final design priority decision to creative-director as the arbiter of player experience trade-offs. Assertions:
- Expresses the technical concern with specifics (e.g., performance budget, estimated cost)
- Proposes at least one alternative that could reduce cost while preserving intent
- Explicitly defers the "is this worth the cost" decision to creative-director — does not unilaterally cut the feature
- Does not claim authority to override game-designer's design intent
Case 5: Context pass — uses provided context
Scenario: Agent receives a gate context block that includes the target platform constraints: mobile, 60fps target, 2GB RAM ceiling, no compute shaders. A proposed architecture includes a GPU-driven rendering pipeline. Expected: Assessment references the specific hardware constraints from the context, identifies the compute shader dependency as incompatible with the stated platform constraints, and returns a CONCERNS or REJECT verdict with those specifics cited. Assertions:
- References the specific platform constraints provided (mobile, 2GB RAM, no compute shaders)
- Does not give generic performance advice disconnected from the supplied constraints
- Correctly identifies the architectural component that conflicts with the platform constraint
- Verdict includes rationale tied to the provided context, not boilerplate warnings
Protocol Compliance
- Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
- Stays within declared technical domain
- Defers design priority conflicts to creative-director
- Uses gate IDs in output (e.g.,
TD-FEASIBILITY: CONCERNS) not inline prose verdicts - Does not make binding game design or creative direction decisions
Coverage Notes
- TD-ADR (Architecture Decision Record approval) is not covered — a dedicated case should be added when the /architecture-decision skill produces ADR documents.
- TD-ENGINE-RISK assessment for specific engine versions (e.g., Godot 4.6 post-cutoff APIs) is not covered — deferred to engine-specialist integration tests.
- TD-PHASE-GATE (full technical phase advancement) involving synthesis of multiple sub-gate results is deferred.
- Multi-domain architecture reviews (e.g., touching both TD-ARCHITECTURE and TD-ENGINE-RISK simultaneously) are not covered here.