mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +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,7 +3,6 @@
|
||||
## Agent Summary
|
||||
**Domain owned:** Code architecture decisions, LP-FEASIBILITY gate, LP-CODE-REVIEW gate, coding standards enforcement, tech stack decisions within the approved engine.
|
||||
**Does NOT own:** Game design decisions (game-designer), creative direction (creative-director), production scheduling (producer), visual art direction (art-director).
|
||||
**Model tier:** Sonnet (implementation-level analysis of individual systems).
|
||||
**Gate IDs handled:** LP-FEASIBILITY, LP-CODE-REVIEW.
|
||||
|
||||
---
|
||||
@@ -13,8 +12,8 @@
|
||||
Verified by reading the agent's `.claude/agents/lead-programmer.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references code architecture, feasibility, code review, coding standards — not generic)
|
||||
- [ ] `allowed-tools:` list includes Read for source files; Bash may be included for static analysis or test runs; no write access outside `src/` without explicit delegation
|
||||
- [ ] Model tier is `claude-sonnet-5` per coordination-rules.md
|
||||
- [ ] `tools:` includes Read for source files and Bash for static analysis or test runs; Write/Edit are gated in the body — every write waits for the user's "yes", and the orchestrated-run exception covers only new artifacts under `production/`, `docs/` or `tests/`
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over game design, creative direction, or production scheduling
|
||||
|
||||
---
|
||||
@@ -22,28 +21,28 @@ Verified by reading the agent's `.claude/agents/lead-programmer.md` frontmatter:
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** A new `CombatSystem` implementation is submitted for code review. The system uses dependency injection for all external references, has doc comments on all public APIs, follows the project's naming conventions, and includes unit tests for all public methods. Request is tagged LP-CODE-REVIEW.
|
||||
**Expected:** Returns `LP-CODE-REVIEW: APPROVED` with rationale confirming dependency injection usage, doc comment coverage, naming convention compliance, and test coverage.
|
||||
**Scenario:** A new `CombatSystem` implementation is submitted for code review with every input LP-CODE-REVIEW names: its implementation files, its story's acceptance criteria, the relevant GDD section (the combat rules) and its governing ADR. The system stays inside the ADR's boundary, implements the GDD's combat rules as written, uses dependency injection for all external references, has doc comments on all public APIs, loads its tuning values from data files, and includes unit tests for all public methods. Request is tagged LP-CODE-REVIEW.
|
||||
**Expected:** Returns the verdict APPROVE with rationale confirming the ADR boundary match, correctness against the GDD rules, dependency injection usage, doc comment coverage, data-driven configuration, and a testable public API.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVED / NEEDS CHANGES
|
||||
- [ ] Verdict token is formatted as `LP-CODE-REVIEW: APPROVED`
|
||||
- [ ] Rationale references specific coding standards criteria (DI, doc comments, naming, tests)
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT (the LP-CODE-REVIEW verdicts)
|
||||
- [ ] States the verdict word `APPROVE` explicitly — `/story-done` branches on the gate's verdict words, so a verdict left implicit in prose cannot be acted on
|
||||
- [ ] Rationale references specific criteria from its Coding Standards Enforcement list and the gate prompt (ADR boundary, GDD rules, DI, doc comments, data-driven values, testable API)
|
||||
- [ ] Output stays within code quality scope — does not comment on whether the mechanic is fun or fits creative vision
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
**Scenario:** Team member asks lead-programmer to review and approve the balance formula for player damage scaling across levels, checking whether the numbers "feel right."
|
||||
**Expected:** Agent declines to evaluate design balance and redirects to systems-designer.
|
||||
**Expected:** Agent declines to evaluate design balance and redirects to game-designer, its stated contact for design concerns.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding assessment of formula balance or game feel
|
||||
- [ ] Explicitly names `systems-designer` as the correct handler
|
||||
- [ ] May note code implementation concerns about the formula (e.g., integer overflow risk at max level), but defers all balance evaluation to systems-designer
|
||||
- [ ] Explicitly names `game-designer` as the correct handler (its "What This Agent Must NOT Do" target for design concerns); naming `systems-designer` as the formula owner as well is fine
|
||||
- [ ] Any comment it makes on the formula is about implementation (e.g., integer overflow risk at max level); all balance evaluation is deferred to the design team
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A proposed pathfinding approach for enemy AI uses a brute-force nearest-neighbor search against all other entities every frame. With expected enemy counts of 200+, this is O(n²) per frame at 60fps. Request is tagged LP-FEASIBILITY.
|
||||
**Expected:** Returns `LP-FEASIBILITY: INFEASIBLE` with specific citation of the O(n²) complexity, the entity count threshold, and the resulting per-frame cost against the target frame budget.
|
||||
**Scenario:** The architecture document under review (passed with its technical requirements baseline and ADR list) specifies enemy AI that runs a brute-force nearest-neighbor search against all other entities every frame. With expected enemy counts of 2,000+, this is O(n²) — about 4 million distance checks per frame — against the document's 2 ms AI budget at 60fps. Request is tagged LP-FEASIBILITY.
|
||||
**Expected:** Returns the verdict INFEASIBLE with specific citation of the O(n²) complexity, the entity count threshold, and the resulting per-frame cost against the 2 ms AI budget.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of FEASIBLE / CONCERNS / INFEASIBLE — not freeform text
|
||||
- [ ] Verdict token is formatted as `LP-FEASIBILITY: INFEASIBLE`
|
||||
- [ ] States the verdict word `INFEASIBLE` explicitly, not a verdict implied by prose
|
||||
- [ ] Rationale includes the specific algorithmic complexity and entity count numbers
|
||||
- [ ] Suggests at least one alternative approach (e.g., spatial hashing, KD-tree) without mandating a choice
|
||||
|
||||
@@ -57,7 +56,7 @@ Verified by reading the agent's `.claude/agents/lead-programmer.md` frontmatter:
|
||||
- [ ] Does not unilaterally cut or modify the mechanic design
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the project's frame budget: 16.67ms total per frame, with 4ms allocated to AI systems. A new AI behavior system is submitted that profiling estimates will consume 7ms per frame under normal conditions.
|
||||
**Scenario:** Agent receives a gate context block for an architecture document (with its technical requirements baseline and ADR list) that includes the project's frame budget: 16.67ms total per frame, with 4ms allocated to AI systems. The document adopts a new AI behavior system that prototype profiling estimates will consume 7ms per frame under normal conditions. Request is tagged LP-FEASIBILITY.
|
||||
**Expected:** Assessment references the specific frame budget allocation from context (4ms AI budget), identifies the 7ms estimate as exceeding the allocation by 3ms, and returns CONCERNS or INFEASIBLE with those specific numbers cited.
|
||||
**Assertions:**
|
||||
- [ ] References the specific frame budget figures from the provided context (16.67ms total, 4ms AI allocation)
|
||||
@@ -65,15 +64,24 @@ Verified by reading the agent's `.claude/agents/lead-programmer.md` frontmatter:
|
||||
- [ ] Does not give generic "this might be slow" advice — cites concrete numbers
|
||||
- [ ] Verdict rationale is traceable to the provided budget constraints
|
||||
|
||||
### Case 6: Missing gate input — NOT ASSESSED
|
||||
**Scenario:** An `InventorySystem` implementation is submitted for code review with its implementation files, its story's acceptance criteria and its governing ADR; everything the agent can check is sound. The relevant GDD section the gate names was not passed: the context gives neither its text nor a path, the story file names none, and the calling skill does not report it absent. Request is tagged LP-CODE-REVIEW.
|
||||
**Expected:** Returns NOT ASSESSED for LP-CODE-REVIEW, naming the GDD section as the input it was not given — without it, the gate's check for correctness issues against the GDD rules cannot be made, so APPROVE is out of reach.
|
||||
**Assertions:**
|
||||
- [ ] States the verdict `NOT ASSESSED` explicitly for LP-CODE-REVIEW — not APPROVE, although everything it could check is sound
|
||||
- [ ] Names the relevant GDD section as the missing input
|
||||
- [ ] Does not infer the GDD rules from the code or the story and judge correctness against them
|
||||
- [ ] Variant — had the calling skill reported that no inventory GDD exists, that is a finding, not a missing input: the verdict is CONCERNS or REJECT, not NOT ASSESSED
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns LP-CODE-REVIEW verdicts using APPROVED / NEEDS CHANGES vocabulary only
|
||||
- [ ] Returns LP-FEASIBILITY verdicts using FEASIBLE / CONCERNS / INFEASIBLE vocabulary only
|
||||
- [ ] Returns LP-CODE-REVIEW verdicts using APPROVE / CONCERNS / REJECT vocabulary only — or `NOT ASSESSED`, naming the input, when an input the gate names was not given or could not be read; an artifact the calling skill reports absent is a finding, in the gate's own words
|
||||
- [ ] Returns LP-FEASIBILITY verdicts using FEASIBLE / CONCERNS / INFEASIBLE vocabulary only — or `NOT ASSESSED`, naming the input, when an input the gate names was not given or could not be read; an artifact the calling skill reports absent is a finding, in the gate's own words
|
||||
- [ ] Stays within declared code architecture domain
|
||||
- [ ] Defers design priority conflicts to creative-director
|
||||
- [ ] Uses gate IDs in output (e.g., `LP-FEASIBILITY: INFEASIBLE`) not inline prose verdicts
|
||||
- [ ] States each gate verdict as an explicit verdict word from that gate's definition, not a verdict implied by inline prose
|
||||
- [ ] Does not make binding game design or creative direction decisions
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user