mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
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
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -3,8 +3,7 @@
|
||||
## Agent Summary
|
||||
**Domain owned:** Visual identity, art bible authorship and enforcement, asset quality standards, UI/UX visual design, visual phase gate, concept art evaluation.
|
||||
**Does NOT own:** UX interaction flows and information architecture (ux-designer's domain), audio direction (audio-director), code implementation.
|
||||
**Model tier:** Sonnet (note: despite the "director" title, art-director is assigned Sonnet per coordination-rules.md — it handles individual system analysis, not multi-document phase gate synthesis at the Opus level).
|
||||
**Gate IDs handled:** AD-CONCEPT-VISUAL, AD-ART-BIBLE, AD-PHASE-GATE.
|
||||
**Gate IDs handled:** AD-CONCEPT-VISUAL, AD-ART-BIBLE, AD-VISUAL, AD-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
@@ -13,8 +12,8 @@
|
||||
Verified by reading the agent's `.claude/agents/art-director.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references visual identity, art bible, asset standards — not generic)
|
||||
- [ ] `allowed-tools:` list is read-focused; image review capability if supported; no Bash unless asset pipeline checks are justified
|
||||
- [ ] Model tier is `claude-sonnet-5` (NOT Opus — coordination-rules.md assigns Sonnet to art-director)
|
||||
- [ ] `tools:` includes Read (which also opens images for visual review) and Write/Edit for the art bible it maintains, and no Bash — `disallowedTools:` blocks it
|
||||
- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over UX interaction flows or audio direction
|
||||
|
||||
---
|
||||
@@ -22,12 +21,12 @@ Verified by reading the agent's `.claude/agents/art-director.md` frontmatter:
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** The art bible's color palette section is submitted for review. The section defines a desaturated earth-tone primary palette with high-contrast accent colors tied to the game pillar "beauty in decay." The palette is internally consistent and references the pillar vocabulary. Request is tagged AD-ART-BIBLE.
|
||||
**Expected:** Returns `AD-ART-BIBLE: APPROVE` with rationale confirming the palette's internal consistency and its alignment with the stated pillar.
|
||||
**Scenario:** A complete art bible is submitted for sign-off with the pillars and core fantasy, the platform constraints and the visual identity anchor chosen during brainstorm. Its color section defines a desaturated earth-tone primary palette with high-contrast accent colors tied to the game pillar "beauty in decay"; its shape language, asset standards and character direction are consistent with that section and within the stated platform constraints. Request is tagged AD-ART-BIBLE.
|
||||
**Expected:** Returns `AD-ART-BIBLE: APPROVE` with rationale confirming the palette's internal consistency and that the color system matches the pillar's mood target.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
||||
- [ ] Verdict token is formatted as `AD-ART-BIBLE: APPROVE`
|
||||
- [ ] Rationale references the specific palette characteristics and pillar alignment — not generic art advice
|
||||
- [ ] Rationale references the specific palette characteristics and how they serve the "beauty in decay" mood target (the gate's color-vs-mood check) — not generic art advice
|
||||
- [ ] Output stays within visual domain — does not comment on UX interaction patterns or audio mood
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
@@ -36,16 +35,16 @@ Verified by reading the agent's `.claude/agents/art-director.md` frontmatter:
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about audio layering or ducking behavior
|
||||
- [ ] Explicitly names `audio-director` as the correct handler
|
||||
- [ ] May note if the audio has visual mood implications (e.g., "the audio should match the visual tension of the zone"), but defers all audio specification to audio-director
|
||||
- [ ] Any comment it makes is about the zone's visual mood (e.g., "the audio should match the visual tension of the zone") — it specifies no layer, duck amount, fade time or trigger
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** Concept art for the protagonist is submitted. The art uses a vivid, saturated color palette (primary: #FF4500, #00BFFF) that directly contradicts the established art bible's "desaturated earth-tones" palette specification. Request is tagged AD-CONCEPT-VISUAL.
|
||||
**Expected:** Returns `AD-CONCEPT-VISUAL: CONCERNS` with specific citation of the palette discrepancy, referencing the art bible's stated palette values versus the submitted concept's palette.
|
||||
**Scenario:** Right after pillars are locked, the concept and pillar set are submitted for a visual identity anchor. The three pillars are "fun combat," "great story," and "lots of content"; none of their design tests says anything about mood, atmosphere, or what the world should feel like, and no visual touchstones were given. Request is tagged AD-CONCEPT-VISUAL.
|
||||
**Expected:** Returns `AD-CONCEPT-VISUAL: CONCERNS` — the gate's verdict for pillars that don't yet give enough direction to differentiate a visual identity — naming which pillars give no visual direction and what is missing (mood, shape language, color meaning).
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict is exactly one of CONCEPTS / STRONG / CONCERNS (the AD-CONCEPT-VISUAL verdicts) — not APPROVE / REJECT and not freeform text
|
||||
- [ ] Verdict token is formatted as `AD-CONCEPT-VISUAL: CONCERNS`
|
||||
- [ ] Rationale specifically identifies the palette conflict — not a generic "doesn't match style" comment
|
||||
- [ ] References the art bible as the authoritative source for the correct palette
|
||||
- [ ] Rationale names the specific pillars that give no visual direction and which of the gate's four direction components (visual rule, mood, shape language, color philosophy) they leave open — not a generic "pillars are vague"
|
||||
- [ ] Does not rewrite the pillars itself — pillar changes go back to the user and creative-director
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** ux-designer proposes using high-contrast, brightly colored icons for the HUD to improve readability. art-director believes this violates the art bible's muted visual language and would undermine the visual identity.
|
||||
@@ -57,23 +56,32 @@ Verified by reading the agent's `.claude/agents/art-director.md` frontmatter:
|
||||
- [ ] References the specific art bible rule being violated
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the existing art bible with specific palette values (primary: #8B7355, #6B6B47; accent: #C8A96E) and style rules ("no pure white, no pure black; all shadows have warm undertones"). A new asset is submitted for review.
|
||||
**Expected:** Assessment references the specific hex values and style rules from the provided art bible, not generic color theory advice. Any concerns are tied to specific violations of the provided rules.
|
||||
**Scenario:** Agent receives a gate context block that includes the existing art bible with specific palette values (primary: #8B7355, #6B6B47; accent: #C8A96E) and style rules ("no pure white, no pure black; all shadows have warm undertones"). A new asset type is submitted for review: the first enemy sprite sheet, whose body colors come from the primary palette but whose outline is pure black (#000000), highlights pure white (#FFFFFF) and shadows a cool blue-grey (#5A6A7A). Request is tagged AD-VISUAL.
|
||||
**Expected:** Assessment references the specific hex values and style rules from the provided art bible, not generic color theory advice, and returns `AD-VISUAL: REJECT` — the sprite breaks all three style rules, a style violation to resolve before the asset type is used — with each violation tied to the rule it breaks.
|
||||
**Assertions:**
|
||||
- [ ] References specific palette values from the provided art bible context
|
||||
- [ ] Applies the specific style rules (no pure white/black, warm shadow undertones) from the provided document
|
||||
- [ ] Applies the specific style rules (no pure white/black, warm shadow undertones) from the provided document, naming the outline, highlight and shadow colors that break them
|
||||
- [ ] Does not generate generic art direction feedback disconnected from the supplied art bible
|
||||
- [ ] Verdict rationale is traceable to specific lines or rules in the provided context
|
||||
- [ ] Verdict token is `AD-VISUAL: REJECT`, with rationale traceable to specific lines or rules in the provided context
|
||||
|
||||
### Case 6: Missing gate input — NOT ASSESSED
|
||||
**Scenario:** A complete, internally consistent art bible is submitted for sign-off with the pillars and the visual identity anchor, but no platform or performance constraints: the context gives none, `project.yaml` sets no `platform.*` or `performance.*` keys, and `.claude/docs/technical-preferences.md` still holds only unconfigured placeholders. Request is tagged AD-ART-BIBLE.
|
||||
**Expected:** Returns `AD-ART-BIBLE: NOT ASSESSED`, naming the platform and performance constraints as the input it could not read — without them, the gate's check that the asset standards are achievable on the platform cannot be made.
|
||||
**Assertions:**
|
||||
- [ ] Verdict token is `AD-ART-BIBLE: NOT ASSESSED` — not APPROVE, although every section it could check is sound
|
||||
- [ ] Names the platform and performance constraints as the missing input
|
||||
- [ ] Does not assume a platform or budget to complete the review
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Returns the verdict vocabulary the invoked gate's definition file lists — APPROVE / CONCERNS / REJECT for AD-ART-BIBLE and AD-VISUAL; CONCEPTS / STRONG / CONCERNS for AD-CONCEPT-VISUAL; READY / CONCERNS / NOT READY for AD-PHASE-GATE; `NOT ASSESSED`, naming the input, at any gate when an input the gate names is missing
|
||||
- [ ] Stays within declared visual domain
|
||||
- [ ] Escalates UX-vs-visual conflicts to creative-director
|
||||
- [ ] Uses gate IDs in output (e.g., `AD-ART-BIBLE: APPROVE`) not inline prose verdicts
|
||||
- [ ] Does not make binding UX interaction, audio, or code implementation decisions
|
||||
- [ ] At a phase gate, treats an artifact the target phase requires that the calling skill passes as "none" as a finding (NOT READY or CONCERNS), and one passed as "not expected before [phase]" or "not required at `workflow: [tier]`" as no finding — it judges readiness for the phase being entered, not a later one
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,7 +3,6 @@
|
||||
## Agent Summary
|
||||
**Domain owned:** Creative vision, game pillars, GDD alignment, systems decomposition feedback, narrative direction, playtest feedback interpretation, phase gate (creative aspect).
|
||||
**Does NOT own:** Technical architecture or implementation details (delegates to technical-director), production scheduling (producer), visual art style execution (delegates to art-director).
|
||||
**Model tier:** Opus (multi-document synthesis, high-stakes phase gate verdicts).
|
||||
**Gate IDs handled:** CD-PILLARS, CD-GDD-ALIGN, CD-SYSTEMS, CD-NARRATIVE, CD-PLAYTEST, CD-PHASE-GATE.
|
||||
|
||||
---
|
||||
@@ -13,8 +12,8 @@
|
||||
Verified by reading the agent's `.claude/agents/creative-director.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references creative vision, pillars, GDD alignment — not generic)
|
||||
- [ ] `allowed-tools:` list is read-heavy; should not include Bash unless justified by a creative workflow need
|
||||
- [ ] Model tier is `claude-opus-4-8` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, WebSearch and `disallowedTools:` lists Bash
|
||||
- [ ] Model tier is `opus` — frontmatter `model:` reads exactly `opus` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over technical architecture or production scheduling
|
||||
|
||||
---
|
||||
@@ -22,12 +21,12 @@ Verified by reading the agent's `.claude/agents/creative-director.md` frontmatte
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** A game concept document is submitted for pillar review. The concept describes a narrative survival game built around three pillars: "emergent stories," "meaningful sacrifice," and "lived-in world." Request is tagged CD-PILLARS.
|
||||
**Expected:** Returns `CD-PILLARS: APPROVE` with rationale citing how each pillar is represented in the concept and any reinforcing or weakening signals found in the document.
|
||||
**Scenario:** The pillar set for a narrative survival game is submitted for a stress test, with its anti-pillars, core fantasy and unique hook. The hook names its closest comparable — "Like *Don't Starve*, AND ALSO every survivor you lose changes the world for good" — and none of the three pillars is a goal that comparable is built around. It has three pillars — "emergent stories," "meaningful sacrifice," and "lived-in world" — each with a definition and a design test that names a real decision it would settle; the pillars pull against each other (sacrifice vs. a world the player wants to preserve). Request is tagged CD-PILLARS.
|
||||
**Expected:** Returns `CD-PILLARS: APPROVE` with specific feedback on each pillar, judged by the gate's criteria: is it falsifiable, does it create tension with the others, does it differentiate the game, would it settle a real design disagreement.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
||||
- [ ] Verdict token is formatted as `CD-PILLARS: APPROVE` (gate ID prefix, colon, verdict keyword)
|
||||
- [ ] Rationale references the three specific pillars by name, not generic creative advice
|
||||
- [ ] Gives feedback on each of the three pillars by name against the gate's criteria (falsifiability, tension, differentiation from *Don't Starve*), not generic creative advice
|
||||
- [ ] Output stays within creative scope — does not comment on engine feasibility or sprint schedule
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
@@ -36,16 +35,16 @@ Verified by reading the agent's `.claude/agents/creative-director.md` frontmatte
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about the schema design
|
||||
- [ ] Explicitly names `technical-director` as the correct handler
|
||||
- [ ] May note whether the data model has creative implications (e.g., what player data is tracked), but defers structural decisions entirely
|
||||
- [ ] Any comment on the schema is limited to its creative implications (e.g., which player choices a save must remember) — it proposes no table, column, key or query design
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A GDD for the "Crafting" system is submitted. Section 4 (Formulas) defines a resource decay formula that punishes exploration — contradicting the Player Fantasy section which calls for "freedom to roam without fear." Request is tagged CD-GDD-ALIGN.
|
||||
**Expected:** Returns `CD-GDD-ALIGN: CONCERNS` with specific citation of the contradiction between the formula behavior and the Player Fantasy statement.
|
||||
**Scenario:** A GDD for the "Crafting" system is submitted with the game's pillars — "curiosity is always rewarded" and "the world remembers" — and its MDA target, Discovery first. Section 4 (Formulas) defines a resource decay formula that punishes exploration — contradicting the Player Fantasy section which calls for "freedom to roam without fear," and working against the curiosity pillar. Every other section serves the pillars, and retuning the formula would resolve the conflict without redesigning the system. Request is tagged CD-GDD-ALIGN.
|
||||
**Expected:** Returns `CD-GDD-ALIGN: CONCERNS` with specific citation of the contradiction between the formula behavior and the Player Fantasy statement. The fix is stated as a creative constraint; the formula itself is left to the design team.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict token is formatted as `CD-GDD-ALIGN: CONCERNS`
|
||||
- [ ] Rationale quotes or directly references GDD Section 4 (Formulas) and the Player Fantasy section
|
||||
- [ ] Does not prescribe a specific formula fix — that belongs to systems-designer
|
||||
- [ ] Rationale quotes or directly references GDD Section 4 (Formulas), the Player Fantasy section and the "curiosity is always rewarded" pillar
|
||||
- [ ] States the fix as a creative constraint (e.g., decay must not punish roaming) and leaves the formula to `game-designer`, its delegate for mechanical design — does not author replacement formula values
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** technical-director raises a concern that the core loop mechanic (real-time branching conversations) is prohibitively expensive to implement and recommends cutting it. creative-director disagrees on creative grounds.
|
||||
@@ -57,7 +56,7 @@ Verified by reading the agent's `.claude/agents/creative-director.md` frontmatte
|
||||
- [ ] Does not claim to own implementation decisions
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the game pillars document (`design/gdd/pillars.md`) and a new mechanic spec for review. The pillars document defines "player authorship," "consequence permanence," and "world responsiveness" as the three core pillars.
|
||||
**Scenario:** Agent receives a gate context block that includes the game pillars document (`design/gdd/game-pillars.md`) and a new system GDD for review. The pillars document defines "player authorship," "consequence permanence," and "world responsiveness" as the three core pillars. Request is tagged CD-GDD-ALIGN.
|
||||
**Expected:** Assessment uses the exact pillar vocabulary from the provided document, not generic creative heuristics. Any approval or concern is tied back to one or more of the three named pillars.
|
||||
**Assertions:**
|
||||
- [ ] Uses the exact pillar names from the provided context document
|
||||
@@ -65,20 +64,29 @@ Verified by reading the agent's `.claude/agents/creative-director.md` frontmatte
|
||||
- [ ] References the specific pillar(s) most relevant to the mechanic under review
|
||||
- [ ] Does not reference pillars not present in the provided document
|
||||
|
||||
### Case 6: Missing gate input — NOT ASSESSED
|
||||
**Scenario:** A complete, internally consistent system GDD is submitted with its Player Fantasy section, but no game pillars: the context gives none, and none of `design/gdd/game-concept.md`, `design/gdd/game-pillars.md` or `design/game-brief.md` exists. Request is tagged CD-GDD-ALIGN.
|
||||
**Expected:** Returns `CD-GDD-ALIGN: NOT ASSESSED`, naming the game pillars as the input it could not read. Alignment with pillars nobody supplied cannot be judged, so no alignment verdict is given.
|
||||
**Assertions:**
|
||||
- [ ] Verdict token is `CD-GDD-ALIGN: NOT ASSESSED` — not APPROVE, although nothing in the GDD itself looks wrong
|
||||
- [ ] Names the game pillars as the missing input
|
||||
- [ ] Does not infer pillars from the GDD under review and judge alignment against them
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Returns the verdict vocabulary the invoked gate's definition file lists — APPROVE / CONCERNS / REJECT for CD-PILLARS, CD-GDD-ALIGN, CD-SYSTEMS, CD-NARRATIVE and CD-PLAYTEST; READY / CONCERNS / NOT READY for CD-PHASE-GATE; `NOT ASSESSED`, naming the input, at any gate when an input the gate names is missing
|
||||
- [ ] Stays within declared creative domain
|
||||
- [ ] Escalates conflicts by presenting trade-offs to user rather than unilateral override
|
||||
- [ ] Uses gate IDs in output (e.g., `CD-PILLARS: APPROVE`) not inline prose verdicts
|
||||
- [ ] Does not make binding cross-domain decisions (technical, production, art execution)
|
||||
- [ ] At a phase gate, treats an artifact the target phase requires that the calling skill passes as "none" as a finding (NOT READY or CONCERNS), and one passed as "not expected before [phase]" or "not required at `workflow: [tier]`" as no finding — it judges readiness for the phase being entered, not a later one
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Multi-gate scenario (e.g., single submission triggering both CD-PILLARS and CD-GDD-ALIGN) is not covered here — deferred to integration tests.
|
||||
- CD-PHASE-GATE (full phase advancement) involves synthesizing multiple sub-gate results; this complex case is deferred.
|
||||
- Playtest report interpretation (CD-PLAYTEST) is not covered — a dedicated case should be added when the playtest-report skill produces structured output.
|
||||
- CD-PHASE-GATE (the creative director's own readiness review, which `/gate-check` runs at `workflow: full`) has no case yet.
|
||||
- CD-PLAYTEST (review of a `/playtest-report` report) has no case yet.
|
||||
- Interaction with art-director on visual-pillar alignment is not covered.
|
||||
|
||||
@@ -3,7 +3,6 @@
|
||||
## Agent Summary
|
||||
**Domain owned:** Scope management, sprint planning validation, milestone tracking, epic prioritization, production phase gate.
|
||||
**Does NOT own:** Game design decisions (creative-director / game-designer), technical architecture (technical-director), creative direction.
|
||||
**Model tier:** Opus (multi-document synthesis, high-stakes phase gate verdicts).
|
||||
**Gate IDs handled:** PR-SCOPE, PR-SPRINT, PR-MILESTONE, PR-EPIC, PR-PHASE-GATE.
|
||||
|
||||
---
|
||||
@@ -13,8 +12,8 @@
|
||||
Verified by reading the agent's `.claude/agents/producer.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references scope, sprint, milestone, production — not generic)
|
||||
- [ ] `allowed-tools:` list is primarily read-focused; Bash only if sprint/milestone files require parsing
|
||||
- [ ] Model tier is `claude-opus-4-8` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] `tools:` includes Write and Edit (it authors sprint plans per its Output Format and maintains the risk register) and Bash only because a preloaded skill needs it (`skills:` includes `scope-check`, which reads `git log`)
|
||||
- [ ] Model tier is `opus` — frontmatter `model:` reads exactly `opus` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over design decisions or technical architecture
|
||||
|
||||
---
|
||||
@@ -22,12 +21,12 @@ Verified by reading the agent's `.claude/agents/producer.md` frontmatter:
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** A sprint plan is submitted for Sprint 7. The plan includes 12 story points across 4 team members over 2 weeks. Historical velocity from the last 3 sprints averages 11.5 points. Request is tagged PR-SPRINT.
|
||||
**Expected:** Returns `PR-SPRINT: REALISTIC` with rationale noting the plan is within one standard deviation of historical velocity and capacity appears matched.
|
||||
**Scenario:** A sprint plan is submitted for Sprint 7. The plan commits 9 story points across 4 team members over 2 weeks, with dependencies listed and no story larger than 3 days. Historical velocity from the last 3 sprints averages 11.5 points; no backlog debt is carried in, and the milestone constraints add nothing to this sprint. Request is tagged PR-SPRINT.
|
||||
**Expected:** Returns `PR-SPRINT: REALISTIC` with rationale noting the load sits below historical velocity while keeping the 20% buffer its Sprint Planning Rules require (9 ≤ 80% of 11.5).
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of REALISTIC / CONCERNS / UNREALISTIC
|
||||
- [ ] Verdict token is formatted as `PR-SPRINT: REALISTIC`
|
||||
- [ ] Rationale references the specific story point count and historical velocity figures
|
||||
- [ ] Rationale compares the 9 committed points with the 11.5-point velocity and the 20% buffer rule — not a generic "looks achievable"
|
||||
- [ ] Output stays within production scope — does not comment on whether the stories are well-designed or technically sound
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
@@ -36,49 +35,68 @@ Verified by reading the agent's `.claude/agents/producer.md` frontmatter:
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding assessment of the mechanic's design quality
|
||||
- [ ] Explicitly names `game-designer` or `creative-director` as the correct handler
|
||||
- [ ] May note if the mechanic's scope has production implications (e.g., dependencies on other systems), but defers all design evaluation
|
||||
- [ ] Any comment it makes is about production implications only (e.g., which other systems the mechanic depends on) — never whether the mechanic is fun, engaging or well designed
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A new feature proposal adds three new systems (crafting, weather, and faction reputation) to a milestone that was scoped for two systems only. None of these additions appear in the current milestone plan. Request is tagged PR-SCOPE.
|
||||
**Expected:** Returns `PR-SCOPE: CONCERNS` with specific identification of the three unplanned systems and their absence from the milestone scope document.
|
||||
**Scenario:** A scope estimate is submitted for a solo developer with a 4-month timeline. The MVP was two systems (movement and combat), estimated at 3 months. The revised MVP adds three more — crafting, weather, and faction reputation — bringing the estimate to exactly 4 months: the whole timeline, with no buffer left for unplanned work. Each of the three could move to the next scope tier without breaking the MVP. Request is tagged PR-SCOPE.
|
||||
**Expected:** Returns `PR-SCOPE: OPTIMISTIC` — the gate's middle verdict, with specific adjustments — because the MVP fits only if nothing goes wrong: names the three added systems and recommends which to move to a later scope tier to restore a buffer. Not UNREALISTIC: the estimate does not exceed the timeline, so neither has to be revised.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of REALISTIC / CONCERNS / UNREALISTIC — not freeform text
|
||||
- [ ] Verdict token is formatted as `PR-SCOPE: CONCERNS`
|
||||
- [ ] Rationale names the three specific systems being added out of scope
|
||||
- [ ] Verdict is exactly one of REALISTIC / OPTIMISTIC / UNREALISTIC (the PR-SCOPE verdicts) — not CONCERNS and not freeform text
|
||||
- [ ] Verdict token is formatted as `PR-SCOPE: OPTIMISTIC`
|
||||
- [ ] Rationale names the three specific systems that use up the buffer
|
||||
- [ ] Does not evaluate whether the systems are good design — only whether they fit the plan
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** game-designer wants to add a late-breaking mechanic (dynamic weather affecting all gameplay systems) that technical-director warns will require 3 additional sprints. game-designer and technical-director are in disagreement about whether to proceed.
|
||||
**Expected:** Producer does not take a side on whether the mechanic is worth adding (design decision) or feasible (technical decision). Producer quantifies the production impact (3 sprints of delay, milestone slip risk), presents the trade-off to the user, and follows coordination-rules.md conflict resolution: escalate to the shared parent (in this case, surface the conflict for user decision since creative-director and technical-director are both top-tier).
|
||||
**Expected:** Producer does not take a side on whether the mechanic is worth adding (design decision) or feasible (technical decision). Producer quantifies the production impact (3 sprints of delay, milestone slip risk), presents the trade-off to the user, and follows coordination-rules.md rule 3: game-designer and technical-director share no parent, and whether the mechanic is worth its cost is a design conflict, so it goes to creative-director, the arbiter of scope questions where creative intent and production capacity collide.
|
||||
**Assertions:**
|
||||
- [ ] Quantifies the production impact in concrete terms (sprint count, milestone date slip)
|
||||
- [ ] Does not make a binding design or technical decision
|
||||
- [ ] Surfaces the conflict to the user with the scope implications clearly stated
|
||||
- [ ] References coordination-rules.md conflict resolution protocol (escalate to shared parent or user)
|
||||
- [ ] Escalates the conflict to `creative-director` per coordination-rules.md rule 3 (no shared parent; a design conflict) — not to technical-director, and not straight to the user as if no escalation target existed
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the current milestone deadline (8 weeks away) and velocity data from the last 4 sprints (8, 10, 9, 11 points). A sprint plan is submitted with 14 story points.
|
||||
**Expected:** Assessment uses the provided velocity data to project whether 14 points is achievable, and references the 8-week milestone window to assess whether the current sprint's scope leaves adequate buffer.
|
||||
**Scenario:** Agent receives a gate context block that includes the current milestone deadline (8 weeks away, two-week sprints) and velocity data from the last 4 sprints (8, 10, 9, 11 points). A sprint plan is submitted with 14 story points in five stories: Player movement (3), Jump buffering (2, depends on Player movement), Enemy patrol AI (5), Pause menu (2) and Save slots (2). Request is tagged PR-SPRINT.
|
||||
**Expected:** Assessment uses the provided velocity data to show 14 points is well over the ~9.5-point average (and further over it once the 20% buffer is kept), returns `PR-SPRINT: UNREALISTIC` naming stories to defer, and references the 8-week milestone window to assess what the overrun does to the milestone.
|
||||
**Assertions:**
|
||||
- [ ] Uses the specific velocity figures from the provided context (not generic estimates)
|
||||
- [ ] References the 8-week deadline in the capacity assessment
|
||||
- [ ] Calculates or estimates remaining sprint count within the milestone window
|
||||
- [ ] Calculates or estimates remaining sprint count within the milestone window (four two-week sprints), as its duty to flag milestone risk at least 2 sprints ahead requires
|
||||
- [ ] Names the stories to defer from the five supplied, by title, and never keeps Jump buffering while deferring Player movement, which it depends on
|
||||
- [ ] Does not give generic scope advice disconnected from the supplied deadline and velocity data
|
||||
|
||||
### Case 6: Missing gate input — NOT ASSESSED
|
||||
**Scenario:** A sprint plan is submitted with five stories — titles, estimates and dependencies, correctly ordered — and the milestone constraints, but no team capacity: the context gives none, and `production/sprints/` holds no earlier sprint to derive a velocity from. Request is tagged PR-SPRINT.
|
||||
**Expected:** Returns `PR-SPRINT: NOT ASSESSED`, naming team capacity as the input it could not read. Whether a story load is realistic depends on the capacity it is measured against, so no feasibility verdict is given.
|
||||
**Assertions:**
|
||||
- [ ] Verdict token is `PR-SPRINT: NOT ASSESSED` — not REALISTIC, and not UNREALISTIC by assumption
|
||||
- [ ] Names team capacity as the missing input
|
||||
- [ ] Does not invent a capacity or velocity figure to judge the load against
|
||||
|
||||
### Case 7: Phase gate at `minimal` — the brief's Build order is the plan
|
||||
**Scenario:** `/gate-check production` at `workflow: minimal` runs the panel with `review_mode: lean` set explicitly, so the producer is spawned alone for PR-PHASE-GATE. The context gives the target phase (Production), the tier, and the gate's required artifacts at that tier: a filled `design/game-brief.md` with its Build order, and stories under `production/epics/`. Both are present — the Build order lists four MVP features, the first three independent and the fourth depending on the first, and there is one story per feature in that order, none Blocked. `team.size` is `individual`; the brief states a six-week target for the MVP. The sprint plan and sprint capacity are passed as "not required at `workflow: minimal`".
|
||||
**Expected:** Returns `PR-PHASE-GATE: READY` — the Build order is the plan at this tier, its dependency is ordered, and four stories fit a solo developer's six weeks. The absent sprint plan and velocity are not findings.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of READY / CONCERNS / NOT READY (the PR-PHASE-GATE verdicts), formatted as `PR-PHASE-GATE: READY`
|
||||
- [ ] Judges the Build order as the plan, and checks its dependency order (the fourth feature after the first)
|
||||
- [ ] Does not raise the missing sprint plan or velocity as a concern, and does not answer NOT ASSESSED for them — they were passed as "not required at `workflow: minimal`"
|
||||
- [ ] Does not invent a sprint capacity to judge the load against
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using REALISTIC / CONCERNS / UNREALISTIC vocabulary only
|
||||
- [ ] Returns the verdict vocabulary the invoked gate's definition file lists — REALISTIC / CONCERNS / UNREALISTIC for PR-SPRINT and PR-EPIC; REALISTIC / OPTIMISTIC / UNREALISTIC for PR-SCOPE; ON TRACK / AT RISK / OFF TRACK for PR-MILESTONE; READY / CONCERNS / NOT READY for PR-PHASE-GATE; `NOT ASSESSED`, naming the input, at any gate when an input the gate names is missing
|
||||
- [ ] Stays within declared production domain
|
||||
- [ ] Escalates design/technical conflicts by quantifying scope impact and presenting to user
|
||||
- [ ] Uses gate IDs in output (e.g., `PR-SPRINT: REALISTIC`) not inline prose verdicts
|
||||
- [ ] Does not make binding game design or technical architecture decisions
|
||||
- [ ] At a phase gate, treats an artifact the target phase requires that the calling skill passes as "none" as a finding (NOT READY or CONCERNS), and one passed as "not expected before [phase]" or "not required at `workflow: [tier]`" as no finding — it judges readiness for the phase being entered, not a later one
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- PR-EPIC (epic-level prioritization) is not covered — a dedicated case should be added when the /create-epics skill produces structured epic documents.
|
||||
- PR-EPIC (the epic-structure review `/create-epics` runs before it writes any epic) has no case yet.
|
||||
- PR-MILESTONE (milestone health review) is not covered — deferred to integration with /milestone-review skill.
|
||||
- PR-PHASE-GATE (full production phase advancement) involving synthesis of multiple sub-gate results is deferred.
|
||||
- PR-PHASE-GATE is covered at `minimal` (Case 7); a `standard`/`full` Production gate judged against a sprint plan has no case yet.
|
||||
- Multi-sprint burn-down and velocity trend analysis are not covered here.
|
||||
|
||||
@@ -3,8 +3,7 @@
|
||||
## 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.
|
||||
**Gate IDs handled:** TD-SYSTEM-BOUNDARY, TD-FEASIBILITY, TD-ARCHITECTURE, TD-ADR, TD-ENGINE-RISK, TD-MANIFEST, TD-CHANGE-IMPACT, TD-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
@@ -13,8 +12,8 @@
|
||||
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-8` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash, WebSearch
|
||||
- [ ] Model tier is `opus` — frontmatter `model:` reads exactly `opus` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over game design decisions or creative direction
|
||||
|
||||
---
|
||||
@@ -22,63 +21,82 @@ Verified by reading the agent's `.claude/agents/technical-director.md` frontmatt
|
||||
## 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.
|
||||
**Scenario:** The master architecture document is submitted for sign-off with its context: every TR-ID in the technical requirements baseline maps to an ADR, the Foundation-layer ADRs are Accepted, and the one HIGH risk engine domain is flagged as an open question. Its "Combat System" section 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 the gate's checks against the document: requirement coverage, engine risk handled, and clean, minimal API boundaries between the layers.
|
||||
**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
|
||||
- [ ] Rationale specifically references the layered structure and its interface definitions as the API-boundary check — 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.
|
||||
**Expected:** Agent declines to evaluate dialogue quality and redirects the content decision to narrative-director, who owns dialogue direction and to whom the writer reports; creative-director remains the escalation target for creative decisions.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about the dialogue content or structure
|
||||
- [ ] Explicitly names `narrative-director` as the correct handler
|
||||
- [ ] May note technical constraints that affect dialogue (e.g., localization string limits, data format), but defers all content decisions
|
||||
- [ ] Explicitly names `narrative-director` as the owner of the dialogue content — creative-director delegates dialogue to it, and coordination-rules.md rule 1 forbids skipping a tier; naming `creative-director` as the escalation target as well is fine
|
||||
- [ ] Comments only on technical constraints that affect dialogue (e.g., localization string limits, data format) — no judgement of the lines' quality, tone or wording
|
||||
|
||||
### 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.
|
||||
**Scenario:** A concept's identified technical risks (platform: PC; engine: Godot 4.6) include a multiplayer mechanic that raycasts from every active entity against every other entity each frame to detect line-of-sight. At expected counts (1000 entities in a large zone), this is O(n²) — about a million raycasts per frame. The mechanic itself can survive with a different implementation. Request is tagged TD-FEASIBILITY.
|
||||
**Expected:** Returns `TD-FEASIBILITY: CONCERNS` — the gate's middle verdict, a list with mitigation suggestions — citing the O(n²) complexity and the entity count that breaks the frame budget as implemented. Not HIGH RISK, because the concept does not need revising.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict is exactly one of VIABLE / CONCERNS / HIGH RISK (the TD-FEASIBILITY verdicts) — not APPROVE / REJECT and 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
|
||||
- [ ] Suggests at least one mitigation (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.
|
||||
**Expected:** technical-director clearly states the technical cost and constraints, proposes alternative implementation approaches that could achieve a similar feel, but explicitly defers the design priority decision to creative-director as the arbiter of player experience trade-offs, with the user making the final call.
|
||||
**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
|
||||
- [ ] Explicitly defers the "is this worth the cost" decision to `creative-director` (its escalation target for design decisions; coordination-rules.md rule 3 for a design conflict with no shared parent), leaving the final call to the user — 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.
|
||||
**Scenario:** An ADR proposing a GPU-driven rendering pipeline — culling and draw submission on compute shaders — is submitted before it is Accepted, with the engine version and its related ADRs. The gate context block adds the target platform constraints: mobile, 60fps target, 2GB RAM ceiling, no compute shaders. The ADR never mentions the platform. Request is tagged TD-ADR.
|
||||
**Expected:** Assessment references the specific hardware constraints from the context, identifies the compute shader dependency as incompatible with the stated platform constraints, and returns `TD-ADR: REJECT` — the decision rests on a capability the target platform does not have, an unsound technical assumption — 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
|
||||
- [ ] Verdict token is `TD-ADR: REJECT`, with rationale tied to the provided context, not boilerplate warnings
|
||||
|
||||
### Case 6: Missing gate input — NOT ASSESSED
|
||||
**Scenario:** The master architecture document is submitted for sign-off with its ADR list (Foundation-layer ADRs Accepted) and the engine knowledge gap inventory; its layers and interfaces are sound. The technical requirements baseline the gate names is missing: the context gives none, and `docs/architecture/tr-registry.yaml` does not exist. Request is tagged TD-ARCHITECTURE.
|
||||
**Expected:** Returns `TD-ARCHITECTURE: NOT ASSESSED`, naming the technical requirements baseline as the input it could not read — without it, the gate's first check (is every requirement covered by an architectural decision?) cannot be made.
|
||||
**Assertions:**
|
||||
- [ ] Verdict token is `TD-ARCHITECTURE: NOT ASSESSED` — not APPROVE, although every part of the document it could check is sound
|
||||
- [ ] Names the technical requirements baseline as the missing input
|
||||
- [ ] Does not reconstruct a requirement list from the architecture document itself and judge coverage against it
|
||||
|
||||
### Case 7: Phase gate — judged against the phase being entered
|
||||
**Scenario:** `/gate-check technical-setup` at `workflow: standard` spawns TD-PHASE-GATE. The context gives the target phase (Technical Setup), the tier, and the gate's required and recommended artifacts at that tier: a systems index enumerating the MVP systems, each MVP GDD at the 5 standard sections and reviewed, and — recommended — a cross-GDD review report. All are present; the systems index gives each system's dependencies and data flow both ways. The engine reference path is `docs/engine-reference/godot/VERSION.md`. The architecture document and the ADR list are passed as "not expected before Pre-Production".
|
||||
**Expected:** Returns `TD-PHASE-GATE: READY` — the systems and GDDs give enough to architect from, which is what entering Technical Setup requires. The absent architecture document and ADRs are the work of the phase being entered, not a gap in it.
|
||||
**Variant:** the same project at target Pre-Production, where the architecture document is required and is passed as "none" → `TD-PHASE-GATE: NOT READY` or `CONCERNS`, naming the missing architecture document.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of READY / CONCERNS / NOT READY (the TD-PHASE-GATE verdicts), formatted as `TD-PHASE-GATE: READY`
|
||||
- [ ] Does not list the architecture document or the ADRs as a blocker or concern when they are passed as "not expected before Pre-Production"
|
||||
- [ ] Does not answer NOT ASSESSED for them — an artifact passed as not expected yet is neither a finding nor a missing input
|
||||
- [ ] Variant: an artifact the target phase requires, passed as "none", is a finding (NOT READY or CONCERNS) — not NOT ASSESSED
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Returns the verdict vocabulary the invoked gate's definition file lists — APPROVE / CONCERNS / REJECT for TD-ARCHITECTURE, TD-ADR, TD-SYSTEM-BOUNDARY, TD-ENGINE-RISK, TD-MANIFEST and TD-CHANGE-IMPACT; VIABLE / CONCERNS / HIGH RISK for TD-FEASIBILITY; READY / CONCERNS / NOT READY for TD-PHASE-GATE; `NOT ASSESSED`, naming the input, at any gate when an input the gate names is missing
|
||||
- [ ] 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
|
||||
- [ ] At a phase gate, treats an artifact the target phase requires that the calling skill passes as "none" as a finding (NOT READY or CONCERNS), and one passed as "not expected before [phase]" or "not required at `workflow: [tier]`" as no finding — it judges readiness for the phase being entered, not a later one
|
||||
|
||||
---
|
||||
|
||||
## 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-ADR is covered only for a platform conflict (Case 5); an ADR with missing sections or unflagged post-cutoff APIs has no case yet.
|
||||
- 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.
|
||||
- TD-PHASE-GATE is covered at one target phase (Case 7); its later-phase judgements (Production and on: is the architecture holding up in the build?) have no case yet.
|
||||
- Multi-domain architecture reviews (e.g., touching both TD-ARCHITECTURE and TD-ENGINE-RISK simultaneously) are not covered here.
|
||||
|
||||
Reference in New Issue
Block a user