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

2.2 KiB

Raw Blame History

paths

design/gdd/**

Design Document Rules

The 8 GDD sections are: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
How many are required depends on modes.workflow — all 8 at full, 5 (+ Formulas when the system defines numeric rules: rates, curves, thresholds, costs, damage, drop weights — anything a balance pass would tune) at standard, none at minimal (the design record there is design/game-brief.md). Resolve the tier before flagging a section as missing; see .claude/docs/workflow-modes.md
The Formulas test is what the system defines, not what it is called. A system's Category in systems-index.md is a hint — Gameplay, Economy and Progression almost always qualify — never the test. Do not gate Formulas on a category token: the categories /map-systems writes (Core · Gameplay · Progression · Economy · Persistence · UI · Audio · Narrative · Meta) do not include combat or AI, which are example systems within Gameplay. Every site stating this rule must state the same test.
Section-name alias: The GDD template and /design-system author this section as ## Detailed Design; the design standard calls it Detailed Rules. These are the SAME required section — accept either heading and never rewrite one into the other.
Formulas must include variable definitions, expected value ranges, and example calculations
Edge cases must explicitly state what happens, not just "handle gracefully"
Dependencies must be bidirectional — if system A depends on B, B's doc must mention A
Tuning knobs must specify safe ranges and what gameplay aspect they affect
Acceptance criteria must be testable — a QA tester must be able to verify pass/fail
No hand-waving: "the system should feel good" is not a valid specification
Balance values must link to their source formula or rationale
Design documents MUST be written incrementally: create skeleton first, then fill each section one at a time with user approval between sections. Write each approved section to the file immediately to persist decisions and manage context

2.2 KiB Raw Blame History

Design Document Rules

2.2 KiB

Raw Blame History