mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 01:37:05 +00:00

Files

T

DonchitosandClaude Opus 5 d05699707f 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

2026-09-23 12:25:11 +10:00

7.2 KiB

Raw Blame History

ADR-[NNNN]: [Title]

Status

[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]

Who may move this to Accepted: the user, or technical-director on the user's explicit confirmation. No other agent, and no skill on its own. Stated here because every consumer of this field enforces the consequences of acceptance (stories referencing a Proposed ADR are set Blocked; epics require Accepted), so something has to say who may produce it. technical-director is the role coordination-rules.md already escalates technical conflicts to, and an ADR is exactly that decision made durable.

This does not relax the existing rule that Status: Accepted is never set without explicit user confirmation — it narrows which agent may set it once that confirmation exists. An agent that believes an ADR is ready says so and escalates; it does not edit this field.

Date

[YYYY-MM-DD — when this ADR was written]

Last Verified

[YYYY-MM-DD — when this ADR was last confirmed accurate against the current engine version and design. Update this date when you re-read and confirm it is still correct, even if nothing changed.]

Decision Makers

[Who was involved in this decision]

Summary

[2 sentences: what problem this ADR solves, and what was decided. Written for tiered context loading — a skill scanning 20 ADRs uses this to decide whether to read the full decision. Be specific: name the system, the problem, and the chosen approach.]

Engine Compatibility

Field	Value
Engine	[e.g. Godot 4.6 / Unity 6 / Unreal Engine 5.4]
Domain	[Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input / Scripting]
Layer	[Foundation / Core / Feature / Presentation]
Knowledge Risk	[LOW — in training data / MEDIUM — near cutoff, verify / HIGH — post-cutoff, must verify]
References Consulted	[e.g. `docs/engine-reference/godot/modules/physics.md`, `breaking-changes.md`]
Post-Cutoff APIs Used	[Specific APIs from post-cutoff engine versions this decision depends on, or "None"]
Verification Required	[Concrete behaviours to test against the target engine version before shipping, or "None"]

Note

: If Knowledge Risk is MEDIUM or HIGH, this ADR must be re-validated if the project upgrades engine versions. Flag it as "Superseded" and write a new ADR.

Layer is the ADR's own layer, not the referencing epic's — and it is a different taxonomy from Domain. Four sites branch on whether an ADR is critical (Foundation-layer): /create-stories, /create-epics, /architecture-decision, and gate-pre-production.md. At standard, /create-stories stops for a missing critical ADR and only warns for a non-critical one, so this row decides whether a run halts. Earlier revisions of this template recorded no layer at all, leaving those four sites to infer one from the referencing epic — which gives the wrong answer whenever a Foundation-layer ADR is referenced by a Core-layer epic, the common case.

The vocabulary is the same Foundation / Core / Feature / Presentation that epics and stories already carry — do not invent a fifth value, and do not reuse a Domain value here. Domain says what part of the engine this touches; Layer says how early in the build it must exist.

ADR Dependencies

Field	Value
Depends On	[ADR-NNNN (must be Accepted before this can be implemented), or "None"]
Enables	[ADR-NNNN (this ADR unlocks that decision), or "None"]
Blocks	[Epic/Story name — cannot start until this ADR is Accepted, or "None"]
Ordering Note	[Any sequencing constraint that isn't captured above]

Context

Problem Statement

[What problem are we solving? Why must this decision be made now? What is the cost of not deciding?]

Current State

[How does the system work today? What is wrong with the current approach?]

Constraints

[Technical constraints -- engine limitations, platform requirements]
[Timeline constraints -- deadline pressures, dependencies]
[Resource constraints -- team size, expertise available]
[Compatibility requirements -- must work with existing systems]

Requirements

[Functional requirement 1]
[Functional requirement 2]
[Performance requirement -- specific, measurable]
[Scalability requirement]

Decision

[The specific technical decision, described in enough detail for someone to implement it without further clarification.]

Architecture

[ASCII diagram showing the system architecture this decision creates.
Show components, data flow direction, and key interfaces.]

Key Interfaces

[Pseudocode or language-specific interface definitions that this decision
creates. These become the contracts that implementers must respect.]

Implementation Guidelines

[Specific guidance for the programmer implementing this decision.]

Alternatives Considered

Alternative 1: [Name]

Description: [How this approach would work]
Pros: [What is good about this approach]
Cons: [What is bad about this approach]
Estimated Effort: [Relative effort compared to chosen approach]
Rejection Reason: [Why this was not chosen]

Alternative 2: [Name]

[Same structure as above]

Consequences

Positive

[Good outcomes of this decision]

Negative

[Trade-offs and costs we are accepting]

Neutral

[Changes that are neither good nor bad, just different]

Risks

Risk	Probability	Impact	Mitigation

Performance Implications

Metric	Before	Expected After	Budget
CPU (frame time)	[X]ms	[Y]ms	[Z]ms
Memory	[X]MB	[Y]MB	[Z]MB
Load Time	[X]s	[Y]s	[Z]s
Network (if applicable)	[X]KB/s	[Y]KB/s	[Z]KB/s

Migration Plan

[If this changes existing systems, the step-by-step plan to migrate.]

[Step 1 -- what changes, what breaks, how to verify]
[Step 2]
[Step 3]

Rollback plan: [How to revert if this decision proves wrong]

Validation Criteria

[How we will know this decision was correct after implementation.]

[Measurable criterion 1]
[Measurable criterion 2]
[Performance criterion]

GDD Requirements Addressed

GDD Document	System	Requirement	How This ADR Satisfies It
[e.g. `design/gdd/combat.md`]	[e.g. Combat]	[e.g. "Hitbox detection must resolve within 1 frame"]	[e.g. "Jolt physics collision queries run synchronously in _physics_process"]

If this is a foundational decision with no direct GDD dependency, write: "Foundational — no GDD requirement. Enables: [list what GDD systems this decision unlocks or constrains]"

[Link to related ADRs — note if supersedes, contradicts, or depends on]
[Link to relevant code files once implemented]

7.2 KiB Raw Blame History