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
@@ -1,7 +1,7 @@
|
||||
# /gate-check — Handoff Contract
|
||||
|
||||
## Role in Pipeline
|
||||
Validates whether the project is ready to advance from one development phase to the next by auditing required artifacts and quality checks, producing a PASS / NOT ASSESSED / CONCERNS / FAIL verdict (NOT ASSESSED outranks PASS — a gate that could not check part of its scope has not established readiness; see SKILL.md's verdict section for the precedence order), and — on PASS with user confirmation — writing the new stage name to `project.stage` in `project.yaml` (and legacy `production/stage.txt` for backward compatibility).
|
||||
Validates whether the project is ready to advance from one development phase to the next by auditing required artifacts and quality checks, producing a PASS / NOT ASSESSED / CONCERNS / FAIL verdict (NOT ASSESSED outranks PASS — a gate that could not check part of its scope has not established readiness; see SKILL.md's verdict section for the precedence order), and — on PASS with user confirmation, or on CONCERNS when the user explicitly accepts the listed risks — writing the new stage name to `project.stage` in `project.yaml` (and legacy `production/stage.txt` for backward compatibility).
|
||||
|
||||
## Inputs Required
|
||||
|
||||
@@ -9,7 +9,7 @@ Validates whether the project is ready to advance from one development phase to
|
||||
| File | Required Fields / Sections | Read-Only? |
|
||||
|------|---------------------------|-----------|
|
||||
| `project.yaml` (`project.stage`, fallback `production/stage.txt`) | Stage name (used when no argument provided, to auto-detect current stage) | Yes |
|
||||
| `project.yaml` (`modes.workflow`, default `standard`; `workflow_overrides.system_overrides.*`, `workflow_overrides.art_bible_strict`) | Workflow tier — selects the per-gate artifact checklist (Section 2b); per-system overrides resolved when validating MVP GDDs | Yes |
|
||||
| `project.yaml` (`modes.workflow`, which follows `modes.rigor` — `minimal` by default; `workflow_overrides.system_overrides.*`, `workflow_overrides.art_bible_strict`) | Workflow tier — selects the per-gate artifact checklist (Section 2b); per-system overrides resolved when validating MVP GDDs | Yes |
|
||||
| `docs/engine-reference/[engine]/VERSION.md` | Engine version, post-cutoff risk levels (read during engine validation checks) | Yes |
|
||||
| `.claude/docs/technical-preferences.md` | Legacy fallback for `engine.*`, `naming.*` and `performance.*` when those keys are absent or empty in `project.yaml`; sole source for forbidden patterns (never migrated). Referenced in quality checks | Yes — required only for keys absent from `project.yaml` |
|
||||
| `docs/consistency-failures.md` | Domain-tagged entries surfaced as increased-scrutiny context (read if exists; skip if absent) | Yes |
|
||||
@@ -17,12 +17,12 @@ Validates whether the project is ready to advance from one development phase to
|
||||
### Phase-specific inputs (subset read depending on target gate)
|
||||
| Target Gate | Key Files Checked |
|
||||
|-------------|------------------|
|
||||
| Concept → Systems Design | `design/gdd/game-concept.md`; pillars either inside it **or** in an optional `design/gdd/game-pillars.md` |
|
||||
| Concept → Systems Design | `design/gdd/game-concept.md`; pillars either inside it **or** in an optional `design/gdd/game-pillars.md` — at the `minimal` tier, `design/game-brief.md` instead (pillars check drops) |
|
||||
| Systems Design → Technical Setup | `design/gdd/systems-index.md`, all MVP GDDs in `design/gdd/`, cross-GDD review report |
|
||||
| Technical Setup → Pre-Production | `docs/architecture/` ADRs (≥3), `docs/engine-reference/[engine]/deprecated-apis.md`, `docs/architecture/architecture.md`, `docs/architecture/requirements-traceability.md`, `design/accessibility-requirements.md`, `design/ux/interaction-patterns.md` |
|
||||
| Pre-Production → Production | `prototypes/` (≥1 concept REPORT.md), `production/sprints/` (first sprint plan), `docs/architecture/control-manifest.md`, `production/epics/` (Foundation + Core layer epics), `production/qa/playtests/` (≥3 sessions), `design/ux/hud.md`, `design/ux/` key screen specs |
|
||||
| Production → Polish | code-root subsystems (resolve per `.claude/docs/code-root-resolution.md`), `tests/unit/` + `tests/integration/` (all Logic stories covered), `production/qa/smoke-*.md` (PASS verdict), `production/qa/playtests/` (≥3 sessions) |
|
||||
| Polish → Release | Full story test evidence for all Must Have stories, QA sign-off report, localization check, `production/qa/` QA plan, release checklist output, changelog |
|
||||
| Pre-Production → Production | `production/sprints/` (first sprint plan), `docs/architecture/control-manifest.md`, `production/epics/` (Foundation + Core layer epics), `design/ux/hud.md`, `design/ux/` key screen specs; recommended, not blocking: `prototypes/*-vertical-slice/REPORT.md` and its playtest in `production/qa/playtests/` — at the `minimal` tier, only a filled `design/game-brief.md` with its build order and stories under `production/epics/` (no sprint plan; the rest drops, the Vertical Slice items included — two checks on the current build replace them: the core loop is fun, and it runs end to end) |
|
||||
| Production → Polish | code-root subsystems (resolve per `.claude/docs/code-root-resolution.md`), the engine's test root — `tests/unit/` + `tests/integration/` (Godot), `Assets/Tests/` (Unity), `Source/<Module>/Private/Tests/` (Unreal) — with all Logic stories covered, `production/qa/smoke-*.md` (PASS or PASS WITH WARNINGS), `production/qa/playtests/` (≥3 sessions) |
|
||||
| Polish → Release | Full story test evidence for all Must Have stories, QA sign-off report, localization check, `production/qa/` QA plan, release checklist output, changelog, the newest full-scope `production/security/security-audit-*.md` (plus any later `quick` re-run) |
|
||||
|
||||
### Preconditions
|
||||
- The target phase argument must be one of: `systems-design`, `technical-setup`, `pre-production`, `production`, `polish`, `release`; if omitted, auto-detects from `project.stage` in `project.yaml` (fallback `production/stage.txt`) and validates the next transition
|
||||
@@ -34,48 +34,48 @@ Validates whether the project is ready to advance from one development phase to
|
||||
| File | Guaranteed Fields / Sections | Notes |
|
||||
|------|------------------------------|-------|
|
||||
| `production/gate-checks/gate-[phase]-[date].md` (or path chosen by user) | Full checklist with per-item status, Blockers list, Recommendations, Verdict, Chain-of-Verification note | written only after user approves ("May I write this gate check report to production/gate-checks/?") |
|
||||
| `project.yaml` (`project.stage`) + legacy `production/stage.txt` | New stage name (dual-write for backward compat) | written ONLY when verdict is PASS AND user explicitly confirms; never written on CONCERNS or FAIL |
|
||||
| `project.yaml` (`project.stage`) + legacy `production/stage.txt` | New stage name (dual-write for backward compat) | written ONLY when the verdict is PASS and the user explicitly confirms, or the verdict is CONCERNS and the user explicitly accepts the listed risks; never written on FAIL or NOT ASSESSED |
|
||||
|
||||
### Output Guarantees
|
||||
- The gate report always contains: artifact checklist (with file sizes or "MISSING"), quality check results, list of blockers (empty if PASS), recommendations, and the Chain-of-Verification note
|
||||
- `project.stage` (and legacy `production/stage.txt`) is updated to the new stage name only on a confirmed PASS — never speculatively
|
||||
- The gate report always contains: artifact checklist (with file sizes or "MISSING"), quality check results, list of blockers (empty if PASS), recommendations, and the Chain-of-Verification note — plus an `### Accepted Risks` section (each concern, accepted by the user, dated) when the user advanced on CONCERNS
|
||||
- `project.stage` (and legacy `production/stage.txt`) is updated to the new stage name only on a confirmed PASS, or on CONCERNS after the user explicitly accepts the risks — never speculatively
|
||||
- Any item that cannot be automatically verified is marked `MANUAL CHECK NEEDED` and the user is asked before the verdict is finalized
|
||||
|
||||
## Immutability Rules
|
||||
- READS but does NOT modify: all GDDs in `design/gdd/`, all ADRs in `docs/architecture/`, `docs/architecture/control-manifest.md`, `docs/architecture/tr-registry.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback), `docs/engine-reference/[engine]/VERSION.md`, `docs/engine-reference/[engine]/deprecated-apis.md`, all story files in `production/epics/`, all sprint files in `production/sprints/`, all playtest files in `production/qa/playtests/`, source files in the code root (Grep only), test files in `tests/` (run via Bash)
|
||||
- MODIFIES: `project.yaml` (`project.stage` only) + legacy `production/stage.txt` (both on PASS + user confirmation only), `production/gate-checks/[report].md` (new file, with user approval)
|
||||
- READS but does NOT modify: all GDDs in `design/gdd/`, all ADRs in `docs/architecture/`, `docs/architecture/control-manifest.md`, `docs/architecture/tr-registry.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback), `docs/engine-reference/[engine]/VERSION.md`, `docs/engine-reference/[engine]/deprecated-apis.md`, all story files in `production/epics/`, all sprint files in `production/sprints/`, all playtest files in `production/qa/playtests/`, source files in the code root (Grep only), test files under the engine's test root (run via Bash)
|
||||
- MODIFIES: `project.yaml` (`project.stage` only) + legacy `production/stage.txt` (both on a confirmed PASS or an accepted CONCERNS override only), `production/gate-checks/[report].md` (new file, with user approval)
|
||||
- Does NOT modify story files, ADRs, GDDs, or any source/test code
|
||||
|
||||
## Hard Constraints (Never Violate)
|
||||
- Never writes stage (either `project.yaml` `project.stage` or legacy `production/stage.txt`) unless the verdict is PASS and the user has explicitly confirmed advancement
|
||||
- Never writes stage on a CONCERNS or FAIL verdict under any circumstances
|
||||
- Never writes stage (either `project.yaml` `project.stage` or legacy `production/stage.txt`) unless the verdict is PASS and the user has explicitly confirmed advancement, or the verdict is CONCERNS and the user has explicitly accepted every listed risk (recorded in the report's `### Accepted Risks`)
|
||||
- Never writes stage on a FAIL or NOT ASSESSED verdict under any circumstances — no override turns either into a stage change
|
||||
- Never auto-advances stage — even a PASS verdict requires explicit user confirmation before the file is written
|
||||
- Never assumes PASS for items that cannot be automatically verified — always marks them `MANUAL CHECK NEEDED` and asks the user
|
||||
- Never blocks the user from advancing — the verdict is advisory; if the user overrides, document the risks explicitly in the gate report
|
||||
- Never blocks the user from working — the verdict decides only whether the stage is written; a CONCERNS override records the accepted risks in the gate report
|
||||
- Never passes a director "none" for an artifact the target gate does not require yet — that is "not expected before [phase]" (or "not required at `workflow: [tier]`"), and not a finding; "none" is reserved for an artifact the gate asks for that does not exist
|
||||
- Always runs Chain-of-Verification (5 challenge questions) after drafting the verdict before finalizing it
|
||||
- If any Vertical Slice Validation item is NO at the Pre-Production → Production gate, the verdict is automatically FAIL regardless of all other checks — and regardless of workflow tier (tier reductions relax what must *exist*, never make a broken built artifact passable)
|
||||
- If any Vertical Slice Validation item is NO at the Pre-Production → Production gate, the verdict is automatically FAIL regardless of all other checks, at `full` and `standard`; at `minimal`, where the slice items drop, a "no" to either current-build check (the core loop is fun, it runs end to end) is FAIL the same way (tier reductions relax what must *exist*, never make a broken build passable)
|
||||
- Workflow-tier reductions (Section 2b) only ever *relax* a requirement (Required → CONCERNS-if-absent, or drop); they never add one. The sole exception that adds is `workflow_overrides`: a system pinned via `system_overrides` to a higher tier than the project blocks the gate until that one system's GDD meets the higher section count, and `art_bible_strict: true` forces the complete art bible regardless of tier
|
||||
- gate-check honors `modes.workflow` but is exempt from `modes.automation` — the collaborative prompting protocol (Section 8) always applies; a phase gate is never auto-run
|
||||
- gate-check honors `modes.workflow` but is exempt from `modes.automation` — the collaborative prompting protocol (the Collaborative Protocol section) always applies; a phase gate is never auto-run
|
||||
|
||||
## Downstream Skill Expects
|
||||
**Next skill (on PASS):** varies by gate
|
||||
|
||||
| Gate Passed | Enabled downstream skill |
|
||||
|-------------|-------------------------|
|
||||
| Concept → Systems Design | `/map-systems` |
|
||||
| Systems Design → Technical Setup | `/architecture-decision`, `/setup-engine` |
|
||||
| Technical Setup → Pre-Production | `/create-epics`, `/create-stories`, prototyping skills |
|
||||
| Concept → Systems Design | `/map-systems` — or `/design-system` for the first system when `design/gdd/systems-index.md` already exists |
|
||||
| Systems Design → Technical Setup | `/create-architecture` first — the master architecture and the ADR work plan (it needs an engine, so `/setup-engine` if none is configured) — then `/architecture-decision` |
|
||||
| Technical Setup → Pre-Production | `/create-control-manifest` if `docs/architecture/control-manifest.md` does not exist yet, then `/vertical-slice`; `/create-epics` and `/create-stories` once the slice has validated the core loop |
|
||||
| Pre-Production → Production | `/dev-story`, `/sprint-plan`, `/story-readiness` |
|
||||
| Production → Polish | `/perf-profile`, `/playtest-report`, `/smoke-check` |
|
||||
| Polish → Release | `/launch-checklist`, `/release-checklist` |
|
||||
| Polish → Release | `/launch-checklist`, `/team-release` (the release checklist, changelog and security audit are done before this gate) |
|
||||
|
||||
- Downstream skills read `project.stage` from `project.yaml` (fallback `production/stage.txt`) to confirm their phase is active before proceeding
|
||||
- `/dev-story` specifically checks that the project is in Production stage before implementing stories; if the resolved stage is still `Pre-Production`, stories may be blocked
|
||||
- `/create-epics` requires `docs/architecture/control-manifest.md` to exist (enforced by the Technical Setup → Pre-Production gate)
|
||||
- `/create-epics` reads `docs/architecture/control-manifest.md` — required at `full`, read if present at `standard` — and the Pre-Production → Production gate checks it
|
||||
|
||||
## Known Fragile Points
|
||||
- `project.stage` in `project.yaml` (with legacy `production/stage.txt` as fallback) is the authoritative stage indicator — if either is manually edited to a wrong value outside of `/gate-check`, auto-detection in future sessions will be incorrect; never edit them outside of a PASS gate
|
||||
- The Production → Polish gate runs the test suite via Bash. If the test runner command is not configured or fails to start (e.g. the `godot --headless --script` path is wrong), the test check now yields `NOT ASSESSED`, which outranks PASS — so the gate cannot advance a stage on the strength of a suite that never ran. Without the `NOT ASSESSED` branch this masks silent test regressions: Section 3 runs the suite "if a test runner is configured", and with no else an unconfigured runner simply contributes nothing to the verdict
|
||||
- `project.stage` in `project.yaml` (with legacy `production/stage.txt` as fallback) is the authoritative stage indicator — if either is manually edited to a wrong value outside of `/gate-check`, auto-detection in future sessions will be incorrect; never edit them outside `/gate-check`'s stage write
|
||||
- The Production → Polish gate runs the test suite via Bash. If the test runner command is not configured or fails to start (e.g. gdUnit4 is not installed at `addons/gdUnit4/`), the test check now yields `NOT ASSESSED`, which outranks PASS — so the gate cannot advance a stage on the strength of a suite that never ran. Without the `NOT ASSESSED` branch this masks silent test regressions: Section 3 runs the suite "if a test runner is configured", and with no else an unconfigured runner simply contributes nothing to the verdict
|
||||
- The Pre-Production → Production gate has a hard Vertical Slice validation block; any subjective checklist item (e.g., "core mechanic feels good") requires a user response via `AskUserQuestion` — if the user answers without playing the build, a false PASS is possible
|
||||
- Gate report files in `production/gate-checks/` are not validated for completeness by any downstream skill; a partial report written due to a session interruption will look identical to a complete one
|
||||
- `docs/consistency-failures.md` is optional context that adjusts scrutiny but does not change the formal checklist; if this file exists but is stale, the increased-scrutiny signals may point at resolved issues
|
||||
|
||||
@@ -33,16 +33,16 @@ The project progresses through these stages:
|
||||
6. **Polish** — Performance, playtesting, bug fixing
|
||||
7. **Release** — Launch prep, certification
|
||||
|
||||
**When a gate passes**, update the stage in both `project.yaml` (set `project.stage: <new-stage>`) AND write the new stage name to `production/stage.txt` (single line, e.g. `Production`). Dual-write keeps backward compatibility with hooks that haven't migrated yet. This updates the status line immediately.
|
||||
**When a gate passes** (or the user explicitly accepts a CONCERNS verdict's risks — Section 6), update the stage in both `project.yaml` (set `project.stage: <new-stage>`) AND write the new stage name to `production/stage.txt` (single line, e.g. `Production`). Dual-write keeps backward compatibility with hooks that haven't migrated yet. This updates the status line immediately.
|
||||
|
||||
---
|
||||
|
||||
## 1. Parse Arguments
|
||||
|
||||
**Target phase:** `$ARGUMENTS[0]` (blank = auto-detect current stage, then validate next transition)
|
||||
**Target phase:** `$ARGUMENTS` with any `--review <mode>` pair removed (blank = auto-detect current stage, then validate next transition). `/gate-check --review full` names no phase.
|
||||
|
||||
|
||||
Note: in `solo` mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In `lean` mode, all four directors still run (phase gates are the purpose of lean mode).
|
||||
Note: in `solo` mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In `lean` mode, the phase-gate directors still run (phase gates are the purpose of lean mode); how many of them run is set by `workflow` below.
|
||||
|
||||
**`workflow`** (per `.claude/docs/workflow-modes.md`):
|
||||
|
||||
@@ -54,16 +54,23 @@ before the gate passes, regardless of the project-level workflow (see Section 2b
|
||||
"Per-system overrides").
|
||||
|
||||
> **gate-check honors `workflow` but is exempt from `automation`.** The artifact
|
||||
> checklist changes per tier; the collaborative prompting protocol (Section 8)
|
||||
> always applies — a phase gate is a deliberate human checkpoint, never auto-run.
|
||||
> checklist changes per tier; the collaborative prompting protocol (the
|
||||
> Collaborative Protocol section) always applies — a phase gate is a deliberate
|
||||
> human checkpoint, never auto-run.
|
||||
|
||||
**`qa.level`**: controls test enforcement at phase gates, where `workflow`
|
||||
controls which artifacts are required. `modes.rigor` sets both together; set
|
||||
`qa.level` explicitly to vary enforcement alone. At `minimal`, no test gates apply — the
|
||||
test-evidence / unit-test / smoke artifact items become non-required and the
|
||||
Section 3 `testing.strict` check is a no-op. At `standard`, Logic + Integration
|
||||
tests must pass. At `full`, a full coverage check + regression suite are required
|
||||
(coverage minimum from `qa.coverage_minimum` if set).
|
||||
test-evidence and unit-test artifact items become non-required and the
|
||||
Section 3 `testing.strict` check is a no-op; the smoke check is not relaxed (Section 2b) —
|
||||
but at this level `/smoke-check` runs without game tests (its automated row reads
|
||||
WAIVED), so the build check (`commands.smoke`, else `commands.build`, when set) and
|
||||
the launch and critical-path checks are the floor — a build nobody launched is
|
||||
NOT ASSESSED — and a project with no tests can still pass. At `standard`,
|
||||
Logic + Integration tests must pass. At `full`, a full coverage check + regression suite are required
|
||||
(coverage minimum from `qa.coverage_minimum` if set). The retained screenshots
|
||||
UI and Visual/Feel stories need are not test items: no `qa.level` relaxes them
|
||||
(Section 2b).
|
||||
|
||||
**`team.size`**: does not change how many directors spawn at a phase gate — panel
|
||||
width is `workflow`'s axis (Section 4b). This value affects only the
|
||||
@@ -123,6 +130,12 @@ across all of them:
|
||||
> non-required at every workflow tier (so even `workflow: full` does not require
|
||||
> them); the Section 3 `testing.strict` check is then a no-op.
|
||||
>
|
||||
> **It relaxes tests, not the look.** A UI story's retained screenshots, and a
|
||||
> Visual/Feel story's screenshots plus lead sign-off, are required at every
|
||||
> `qa.level` wherever the gate file asks for story evidence
|
||||
> (`.claude/docs/coding-standards.md`: tests are waived at `minimal`, the look
|
||||
> is not).
|
||||
>
|
||||
> **The smoke check is excluded from that relaxation, and is the floor.**
|
||||
> `qa.level` relaxes *per-story test evidence*; a smoke check is **build health**,
|
||||
> not story evidence, and the two are already held apart on exactly this basis in
|
||||
@@ -133,8 +146,7 @@ across all of them:
|
||||
> Without that exclusion the Production → Polish gate had **zero required
|
||||
> artifacts at `rigor: minimal`** and could not fail on artifacts by
|
||||
> construction: `minimal` reduced the gate to the smoke check alone, `qa.level`
|
||||
> then dropped the smoke check too, and one `modes.rigor` setting fires both. Two
|
||||
> agents found it independently on the same fixture.
|
||||
> then dropped the smoke check too, and one `modes.rigor` setting fires both.
|
||||
|
||||
> **A gate with no required artifacts left must say so, and may not return
|
||||
> PASS.** After applying the tier reduction and the `qa.level` relaxation, count
|
||||
@@ -147,6 +159,13 @@ across all of them:
|
||||
> requires the emptiness to be visible in the output rather than inferable from
|
||||
> a silent green.
|
||||
>
|
||||
> **The one exception: a gate its tier reference file marks "not applicable" at
|
||||
> this tier** (Systems Design → Technical Setup at `workflow: minimal`). That is
|
||||
> not a gate with nothing left to check but a transition the tier does not have:
|
||||
> it PASSes with that file's note, printed in the report. The director panel
|
||||
> does not run for it — note "Director Panel skipped — gate not applicable at
|
||||
> `workflow: [tier]`" — and the Section 6 stage write still asks first.
|
||||
>
|
||||
> **`performance.enforce` is likewise independent of the tier, and a tier
|
||||
> reduction never suppresses it.** The performance check in Section 3 runs at
|
||||
> every workflow tier, and `block` makes a breach a Blocker at every workflow
|
||||
@@ -155,12 +174,9 @@ across all of them:
|
||||
> deliberate choice the user makes on the same key.
|
||||
>
|
||||
> Without this, `performance.enforce: block` is **inert on every `rigor: minimal`
|
||||
> project** — `minimal` used to reduce the Polish gate to the smoke check alone, and
|
||||
> "Performance is within budget" sits in the dropped remainder. Two independent
|
||||
> agents run against a project breaching three of four budgets both spotted the
|
||||
> contradiction, both overrode the literal reading to reach FAIL, and both
|
||||
> flagged it as the call most likely to be wrong. A setting that only works
|
||||
> because agents disregard a rule is not wired.
|
||||
> project** — the Polish gate's `minimal` reduction drops everything outside its
|
||||
> floor, and "Performance is within budget" sits in the dropped remainder. A
|
||||
> setting that works only when a rule is disregarded is not wired.
|
||||
|
||||
### Per-system overrides (`workflow_overrides.system_overrides`)
|
||||
|
||||
@@ -241,6 +257,11 @@ Pass the phase being advanced *from* (its steps are the work that must be
|
||||
complete): `systems-design` for the Systems Design → Technical Setup gate,
|
||||
`pre-production` for Pre-Production → Production, and so on.
|
||||
|
||||
At `workflow: minimal`, also run
|
||||
`bash .claude/scripts/artifact-check.sh --path minimal`: the brief and stories
|
||||
live on that path, not on any phase, and its `game-brief` and `create-stories`
|
||||
rows are this tier's floor.
|
||||
|
||||
It reads `workflow-catalog.yaml` — which already encodes each step's `glob`,
|
||||
`pattern`, `min_count` and `any_of` — and reports per step:
|
||||
|
||||
@@ -275,10 +296,12 @@ does not turn on.
|
||||
> and nothing verifies. Check its claims against the repo, and raise any that the
|
||||
> tree contradicts:
|
||||
>
|
||||
> - It reports a passing automated suite → `tests/` must actually contain test
|
||||
> files and the project must have a runner. "24 passed, 0 failed" in a repo
|
||||
> with no `tests/unit/`, no `tests/integration/` and no runner is a finding,
|
||||
> not evidence.
|
||||
> - It reports a passing automated suite → the engine's test root must actually
|
||||
> contain test files and the project must have a runner. "24 passed, 0 failed"
|
||||
> in a repo with no test files under that root — `tests/unit/` and
|
||||
> `tests/integration/` on Godot, `Assets/Tests/` on Unity,
|
||||
> `Source/<Module>/Private/Tests/` on Unreal — and no runner is a finding, not
|
||||
> evidence.
|
||||
> - It marks a critical path PASS → the code for that path must exist in the code
|
||||
> root. A PASS on "banking ends the run" with no banking code is a finding.
|
||||
> - It carries no date, or predates the newest commit touching the code root →
|
||||
@@ -286,8 +309,7 @@ does not turn on.
|
||||
>
|
||||
> Report a contradiction at the same level the artifact was required at: a
|
||||
> Blocker where the smoke check is required, CONCERNS where it is recommended.
|
||||
> This was found by handing a gate a one-page fabricated smoke report on a
|
||||
> two-file repo; it cleared on existence plus a verdict-line grep.
|
||||
> Existence plus a verdict-line grep would clear a fabricated report.
|
||||
|
||||
For code checks, verify directory structure and file counts.
|
||||
|
||||
@@ -299,7 +321,9 @@ If no file matches: at `full` mark the "cross-GDD review report exists" artifact
|
||||
`standard` the report is recommended, so mark it **CONCERNS**, not a blocker; at
|
||||
`minimal` this gate is not applicable (see the gate file). If a file is found, read it and
|
||||
check the verdict line: a FAIL verdict means the cross-GDD consistency check failed
|
||||
and must be resolved before advancing.
|
||||
and must be resolved before advancing. A NOT ASSESSED verdict means that review
|
||||
could not compare the GDDs, so it satisfies nothing here: mark the item NOT
|
||||
ASSESSED for this gate, never passed.
|
||||
|
||||
### Quality Checks
|
||||
- For test checks: Run the test suite via `Bash` if a test runner is configured.
|
||||
@@ -310,8 +334,12 @@ and must be resolved before advancing.
|
||||
**resolved in Phase 1** (`resolve_config` merges `project.local.yaml` over
|
||||
`project.yaml`; reading the file directly would drop a local override), per
|
||||
test type:
|
||||
- **Logic** — failures in `tests/unit/`, gated by `testing.strict.logic`.
|
||||
- **Integration** — failures in `tests/integration/`, gated by `testing.strict.integration`.
|
||||
- **Logic** — unit-level failures (`tests/unit/` on Godot, Edit Mode on
|
||||
Unity), gated by `testing.strict.logic`.
|
||||
- **Integration** — failures in `tests/integration/` on Godot, Play Mode on
|
||||
Unity, gated by `testing.strict.integration`. On Unreal, where one root
|
||||
(`Source/<Module>/Private/Tests/`) holds both, classify a failure by its
|
||||
story's Type, or apply the stricter of the two levels when that is unknown.
|
||||
- For each type: take `testing.strict.<type>` from that block; use it only
|
||||
if its value is `true` or `false` (case-insensitive). If the key is absent,
|
||||
empty, or holds any other value, read `testing.strict` as a plain boolean
|
||||
@@ -369,6 +397,17 @@ For items that can't be automatically verified, **ask the user**:
|
||||
- "Performance profiling data isn't available. Would you like to run `/perf-profile`?"
|
||||
|
||||
**Never assume PASS for unverifiable items.** Mark them as MANUAL CHECK NEEDED.
|
||||
An answer resolves the item: "no" or "not yet" is a checked, failed item
|
||||
(CONCERNS or FAIL, naming the skill that closes it — `/design-review [doc]` for
|
||||
an unreviewed concept or GDD) — except a play question at the Production gate
|
||||
(a human has played the Vertical Slice; at `minimal`, the core loop is fun on
|
||||
the current build), where "not yet" means nobody has played it: NOT ASSESSED
|
||||
(`gate-production.md`). Only an unanswered item or "I don't know" stays
|
||||
MANUAL CHECK NEEDED, which Section 5 turns into NOT ASSESSED.
|
||||
|
||||
This applies to questions about the project's state. Declining an offer to
|
||||
produce missing data (e.g. `/perf-profile`) leaves the item NOT ASSESSED; at
|
||||
`performance.enforce: off` it stays out of the verdict.
|
||||
|
||||
---
|
||||
|
||||
@@ -413,37 +452,71 @@ Before generating the final verdict, spawn the directors for the resolved tier a
|
||||
3. **`producer`** — gate **PR-PHASE-GATE** (`.claude/docs/director-gates/pr-phase-gate.md`)
|
||||
4. **`art-director`** — gate **AD-PHASE-GATE** (`.claude/docs/director-gates/ad-phase-gate.md`)
|
||||
|
||||
Pass to each: target phase name, list of artifacts present, and the context fields listed in that gate's definition.
|
||||
Pass to each the target phase name, the resolved `workflow` tier, the target
|
||||
gate's required and recommended artifacts at the resolved tier (the loaded gate
|
||||
file's checklist after its tier reduction and the `qa.level` relaxation — what
|
||||
this gate asks for, not what a later one will), the list of artifacts present,
|
||||
and its gate's own context — named here, so this session never has to read the
|
||||
gate files:
|
||||
- **CD-PHASE-GATE**: the game pillars and core fantasy (from
|
||||
`design/gdd/game-concept.md`, else `design/game-brief.md`).
|
||||
- **TD-PHASE-GATE**: the architecture document path, the engine reference path
|
||||
(`docs/engine-reference/<engine>/VERSION.md`), and the ADR list.
|
||||
- **PR-PHASE-GATE**: the sprint and milestone artifacts present, `team.size` as
|
||||
resolved above (with the current sprint plan's capacity, if a plan exists), and
|
||||
the number of stories under `production/epics/` whose status is `Blocked`. At
|
||||
`workflow: minimal`, pass the Build order in `design/game-brief.md` as the plan — that
|
||||
tier has no sprint plan.
|
||||
- **AD-PHASE-GATE**: the art and visual artifacts present, the Visual Identity
|
||||
Anchor (from `design/gdd/game-concept.md`, else the "Art & audio direction"
|
||||
line of `design/game-brief.md`), and the art bible path.
|
||||
|
||||
Pass each context item as one of three things, so no director has to guess:
|
||||
- **Present** — its path or value (`0` blocked stories is a value).
|
||||
- **"none"** — the target gate (or an earlier one) requires or recommends it at
|
||||
this tier and it does not exist (no architecture document at
|
||||
`/gate-check pre-production`). For the director that is a fact about the
|
||||
project to judge, not a missing input.
|
||||
- **"not expected before [phase]"** — the target gate does not ask for it yet;
|
||||
name the phase whose gate first does (the architecture document and ADRs
|
||||
before Pre-Production, the sprint plan before Production). One this tier never
|
||||
requires is "not required at `workflow: [tier]`" (any sprint plan at
|
||||
`minimal`). Neither is ever passed as "none", and neither is a finding — a
|
||||
director judges readiness for the phase being entered, not a later one.
|
||||
|
||||
**Name the omissions in the output.** Below the Director Panel summary, when the
|
||||
panel ran narrower than four, state which perspectives did not run and how to get
|
||||
them — e.g. "Panel: 2 of 4 (`workflow: standard`). Creative and Art perspectives
|
||||
not consulted. Run `/gate-check --review full` or set `modes.workflow: full` for
|
||||
the complete panel." A silently narrow panel reads as a clean bill of health from
|
||||
reviewers who never looked.
|
||||
not consulted. Raise `modes.rigor` to `full` (or set `modes.workflow: full`) for
|
||||
the complete panel." Name the setting the config block shows as `workflow`'s
|
||||
source: when `modes.workflow` is set on its own, raising `modes.rigor` does not
|
||||
change it. Never point to `--review full` for this — `--review` decides whether
|
||||
the panel runs, not how wide it is. A silently narrow panel reads as a clean bill
|
||||
of health from reviewers who never looked.
|
||||
|
||||
**Collect all four responses, then present the Director Panel summary:**
|
||||
**Collect every response from the directors that ran, then present the Director Panel summary** (one row per director that ran; name the ones `workflow` left out):
|
||||
|
||||
```
|
||||
## Director Panel Assessment
|
||||
|
||||
Creative Director: [READY / CONCERNS / NOT READY]
|
||||
Creative Director: [READY / CONCERNS / NOT READY / NOT ASSESSED]
|
||||
[feedback]
|
||||
|
||||
Technical Director: [READY / CONCERNS / NOT READY]
|
||||
Technical Director: [READY / CONCERNS / NOT READY / NOT ASSESSED]
|
||||
[feedback]
|
||||
|
||||
Producer: [READY / CONCERNS / NOT READY]
|
||||
Producer: [READY / CONCERNS / NOT READY / NOT ASSESSED]
|
||||
[feedback]
|
||||
|
||||
Art Director: [READY / CONCERNS / NOT READY]
|
||||
Art Director: [READY / CONCERNS / NOT READY / NOT ASSESSED]
|
||||
[feedback]
|
||||
```
|
||||
|
||||
**Apply to the verdict:**
|
||||
- Any director returns NOT READY → verdict is minimum FAIL (user may override with explicit acknowledgement)
|
||||
- Any director returns NOT READY → verdict is minimum FAIL (no override turns a FAIL into a stage change — Section 6)
|
||||
- Any director returns CONCERNS → verdict is minimum CONCERNS
|
||||
- All four READY → eligible for PASS (still subject to artifact and quality checks from Section 3)
|
||||
- Any director returns NOT ASSESSED (and none returned NOT READY or CONCERNS) → verdict at best NOT ASSESSED; name the input that director said was missing — it never counts as READY
|
||||
- Every director that ran returns READY → eligible for PASS (still subject to artifact and quality checks from Section 3)
|
||||
|
||||
---
|
||||
|
||||
@@ -456,7 +529,7 @@ Art Director: [READY / CONCERNS / NOT READY]
|
||||
**Checked by**: gate-check skill
|
||||
|
||||
### Required Artifacts: [X/Y present]
|
||||
- [x] design/gdd/game-concept.md — exists, 2.4KB
|
||||
- [x] design/gdd/game-concept.md (design/game-brief.md at `minimal`) — exists, 2.4KB
|
||||
- [ ] docs/architecture/ — MISSING (no ADRs found)
|
||||
- [x] production/sprints/ — exists, 1 sprint plan
|
||||
|
||||
@@ -476,10 +549,14 @@ Art Director: [READY / CONCERNS / NOT READY]
|
||||
|
||||
### Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]
|
||||
- **PASS**: All required artifacts present, all quality checks passing
|
||||
- **CONCERNS**: Minor gaps exist but can be addressed during the next phase
|
||||
- **CONCERNS**: Minor gaps exist but can be addressed during the next phase —
|
||||
the stage advances only if the user explicitly accepts them (Section 6)
|
||||
- **FAIL**: Critical blockers must be resolved before advancing
|
||||
- **NOT ASSESSED**: One or more required checks could not be run at all — name
|
||||
which, and why, in the Blockers section
|
||||
|
||||
### Accepted Risks (only when the user advanced on CONCERNS)
|
||||
- [each concern, as listed above] — accepted by the user, [date]
|
||||
```
|
||||
|
||||
**`NOT ASSESSED` — when the gate could not look.** Rank: it **outranks PASS**
|
||||
@@ -606,6 +683,16 @@ Do NOT reference the draft verdict text — re-check specific files or ask the u
|
||||
When the verdict is **PASS** and the user confirms they want to advance, write the
|
||||
new stage to BOTH `project.yaml` and the legacy `production/stage.txt`.
|
||||
|
||||
**On CONCERNS, the user may override — explicitly.** Do not offer the stage
|
||||
write by default. If the user asks to advance anyway, list every concern and
|
||||
ask: "The gate returned CONCERNS. Accept these risks — [list] — and may I update
|
||||
`project.stage` in `project.yaml` to '[stage]' (and the legacy
|
||||
`production/stage.txt`)?" Only on an explicit yes, add the `### Accepted Risks`
|
||||
section to the gate report (each concern, accepted by the user, with the date)
|
||||
and write the stage as below. **A FAIL is never overridden into a stage change, and
|
||||
neither is NOT ASSESSED** — the blockers must be fixed, or the missing input
|
||||
produced, and the gate re-run.
|
||||
|
||||
### 6.1 Primary write — `project.yaml`
|
||||
|
||||
Set `project.stage` to the new stage name in `project.yaml` at the repo root.
|
||||
@@ -630,7 +717,7 @@ Set `project.stage` to the new stage name in `project.yaml` at the repo root.
|
||||
schema_version: 1
|
||||
|
||||
framework:
|
||||
version: 1.1.1
|
||||
version: 1.1.2
|
||||
last_upgraded: <YYYY-MM-DD>
|
||||
|
||||
project:
|
||||
@@ -638,7 +725,7 @@ Set `project.stage` to the new stage name in `project.yaml` at the repo root.
|
||||
```
|
||||
Do not seed `modes.review_mode` here. It is a rigor-fronted knob — `modes.rigor`
|
||||
supplies its value, so an explicit value would shadow the rigor expansion and pin
|
||||
the review mode regardless of the project's rigor. Test Y.6 locks this in.
|
||||
the review mode regardless of the project's rigor.
|
||||
|
||||
### 6.2 Legacy fallback write — `production/stage.txt`
|
||||
|
||||
@@ -654,7 +741,7 @@ After both writes, Read `project.yaml` and `production/stage.txt` and confirm bo
|
||||
show the new stage. If they diverge, report the discrepancy to the user and stop —
|
||||
a split stage indicator corrupts future auto-detection.
|
||||
|
||||
**Always ask before writing**: "Gate passed. May I update `project.stage` in `project.yaml` to 'Production' (and the legacy `production/stage.txt`)?"
|
||||
**Always ask before writing**: "Gate passed. May I update `project.stage` in `project.yaml` to 'Production' (and the legacy `production/stage.txt`)?" — on an accepted CONCERNS override, the explicit yes above is that ask.
|
||||
|
||||
### 6.4 Rigor-fit check (advisory — never affects the verdict)
|
||||
|
||||
@@ -675,9 +762,28 @@ setting yourself.
|
||||
|
||||
After the verdict is presented and any stage update is complete (project.yaml + stage.txt), close with a structured next-step prompt using `AskUserQuestion`.
|
||||
|
||||
**Tailor the options to the gate that just ran:**
|
||||
**Tailor the options to the gate that just ran.** The argument names the phase
|
||||
being entered, so `/gate-check systems-design` is the Concept → Systems Design gate.
|
||||
|
||||
For **systems-design PASS**:
|
||||
**At `workflow: minimal`, skip the menus below.** They walk the phase ladder, and
|
||||
the minimal route is not the ladder: offer the first incomplete step of
|
||||
`paths.minimal` instead (the `--path minimal` rows from Section 3):
|
||||
`/setup-engine`, then `/brainstorm`, then `/create-stories`, then `/dev-story`
|
||||
on the next story — the route `/help` gives.
|
||||
|
||||
For **Concept → Systems Design** (`/gate-check systems-design`) PASS — option [A] is
|
||||
`/map-systems` when `design/gdd/systems-index.md` does not exist yet (many
|
||||
projects write it during Concept, as the workflow catalog orders it), otherwise
|
||||
`/design-system [first system in the index's design order]`:
|
||||
```
|
||||
Gate passed. What would you like to do next?
|
||||
[A] Run /map-systems — decompose the concept into systems and a design order (recommended next step)
|
||||
— or, when the systems index already exists: Run /design-system [first system] — author its GDD
|
||||
[B] Revisit the concept first — return here when it is settled
|
||||
[C] Stop here for this session
|
||||
```
|
||||
|
||||
For **Systems Design → Technical Setup** (`/gate-check technical-setup`) PASS:
|
||||
```
|
||||
Gate passed. What would you like to do next?
|
||||
[A] Run /create-architecture — produce your master architecture blueprint and ADR work plan (recommended next step)
|
||||
@@ -685,23 +791,23 @@ Gate passed. What would you like to do next?
|
||||
[C] Stop here for this session
|
||||
```
|
||||
|
||||
> **Note for systems-design PASS**: `/create-architecture` is the required next step before writing any ADRs. It produces the master architecture document and a prioritized list of ADRs to write. Running `/architecture-decision` without this step means writing ADRs without a blueprint — skip it at your own risk.
|
||||
> **Note for the Systems Design → Technical Setup PASS**: `/create-architecture` is the required next step before writing any ADRs. It produces the master architecture document and a prioritized list of ADRs to write. Running `/architecture-decision` without this step means writing ADRs without a blueprint — skip it at your own risk.
|
||||
|
||||
For **technical-setup PASS**:
|
||||
For **Technical Setup → Pre-Production** (`/gate-check pre-production`) PASS:
|
||||
```
|
||||
Gate passed. What would you like to do next?
|
||||
[A] Run /create-control-manifest — generate the layer rules manifest from your Accepted ADRs (do this first)
|
||||
[A] Run /create-control-manifest — generate the layer rules manifest from your Accepted ADRs (first, if docs/architecture/control-manifest.md does not exist yet)
|
||||
[B] Run /vertical-slice — build the Vertical Slice (do this before writing epics — validate fun first)
|
||||
[C] Write more ADRs first — run /architecture-decision [next-system]
|
||||
[D] Stop here for this session
|
||||
```
|
||||
|
||||
> **Note for technical-setup PASS**: The Pre-Production sequence is deliberately ordered
|
||||
> **Note for the Technical Setup → Pre-Production PASS**: The Pre-Production sequence is deliberately ordered
|
||||
> to validate fun before committing to detailed planning:
|
||||
>
|
||||
> 1. `/create-control-manifest` — extract technical rules from Accepted ADRs (required before epics)
|
||||
> 1. `/create-control-manifest` — extract technical rules from Accepted ADRs, if not done yet (`/create-epics` requires it at `full`)
|
||||
> 2. `/vertical-slice` — build the Vertical Slice **FIRST**, before writing epics or stories
|
||||
> 3. Playtest → `/playtest-report` — at least 1 session required to pass the Pre-Production gate; 3+ recommended before committing the full team
|
||||
> 3. Playtest → `/playtest-report` — at least 1 documented session, 3+ better before committing the full team. `/gate-check production` treats the slice as recommended: skipped → CONCERNS, unplayed → NOT ASSESSED
|
||||
> 4. `/ux-design [screen]` — UX specs for main menu, core HUD, pause menu (if not done)
|
||||
> 5. `/create-epics layer:foundation` then `/create-epics layer:core` — plan after fun is validated
|
||||
> 6. `/create-stories [epic-slug]` for each epic
|
||||
@@ -724,11 +830,12 @@ Based on the verdict, suggest specific next steps:
|
||||
- **No game concept?** → `/brainstorm` to create one
|
||||
- **No systems index?** → `/map-systems` to decompose the concept into systems
|
||||
- **Missing design docs?** → `/reverse-document` or delegate to `game-designer`
|
||||
- **Small design change needed?** → `/quick-design` for changes under ~4 hours (bypasses full GDD pipeline)
|
||||
- **Small design change needed?** → `/quick-design` for changes under about one week of implementation (bypasses full GDD pipeline)
|
||||
- **No UX specs?** → `/ux-design [screen name]` to author specs, or `/team-ui [feature]` for full pipeline
|
||||
- **UX specs not reviewed?** → `/ux-review [file]` or `/ux-review all` to validate
|
||||
- **No accessibility requirements doc?** → run `/ux-design` which creates both `design/accessibility-requirements.md` and `design/ux/interaction-patterns.md` in one step
|
||||
- **No interaction pattern library?** → `/ux-design patterns` to initialize it
|
||||
- **Concept or a GDD not reviewed?** → `/design-review [doc]`
|
||||
- **GDDs not cross-reviewed?** → `/review-all-gdds` (run after all MVP GDDs are individually approved)
|
||||
- **Cross-GDD consistency issues?** → fix flagged GDDs, then re-run `/review-all-gdds`
|
||||
- **No test framework?** → `/test-setup` to scaffold the framework for your engine
|
||||
@@ -757,6 +864,7 @@ Based on the verdict, suggest specific next steps:
|
||||
- **Need a quick sprint check?** → `/sprint-status` for current sprint progress snapshot
|
||||
- **Performance unknown?** → `/perf-profile`
|
||||
- **Not localized?** → `/localize`
|
||||
- **No security audit, or open CRITICAL/HIGH findings?** → `/security-audit` (after fixes, `/security-audit quick` to confirm)
|
||||
- **Ready for release?** → `/launch-checklist`
|
||||
|
||||
---
|
||||
@@ -768,12 +876,16 @@ This skill follows the collaborative design principle:
|
||||
1. **Scan first**: Check all artifacts and quality gates
|
||||
2. **Ask about unknowns**: Don't assume PASS for things you can't verify
|
||||
3. **Present findings**: Show the full checklist with status
|
||||
4. **User decides**: The verdict is a recommendation — the user makes the final call
|
||||
4. **User decides**: The verdict is a recommendation — the user makes the final call on
|
||||
what to do next; only the stage write is bound to it (Section 6)
|
||||
5. **Get approval**: "May I write this gate check report to production/gate-checks/?"
|
||||
6. **Never auto-fix**: If required artifacts are missing, report the FAIL verdict and
|
||||
name the skill to run (e.g. "run `/test-setup`"). Do NOT create missing files or
|
||||
re-run the gate automatically. Creating files to manufacture a PASS defeats the
|
||||
gate's purpose.
|
||||
|
||||
**Never** block a user from advancing — the verdict is advisory. Document the risks
|
||||
and let the user decide whether to proceed despite concerns.
|
||||
**Never** block a user from working — the verdict decides only whether this skill
|
||||
writes the new stage. On CONCERNS the user may advance by explicitly accepting the
|
||||
listed risks, which the report records (Section 6); on FAIL or NOT ASSESSED the
|
||||
stage stays where it is until a re-run passes, and nothing stops the user working
|
||||
on the blockers meanwhile.
|
||||
|
||||
@@ -9,8 +9,8 @@
|
||||
- [ ] The code root has active code organized into subsystems
|
||||
- [ ] All core mechanics from GDD are implemented (cross-reference `design/gdd/` with the code root)
|
||||
- [ ] Main gameplay path is playable end-to-end
|
||||
- [ ] Test files exist in `tests/unit/` and `tests/integration/` covering Logic and Integration stories
|
||||
- [ ] All Logic stories from this sprint have corresponding unit test files in `tests/unit/`
|
||||
- [ ] Test files exist under the engine's test root — `tests/unit/` and `tests/integration/` (Godot), `Assets/Tests/EditMode/` and `Assets/Tests/PlayMode/` (Unity), `Source/<Module>/Private/Tests/` (Unreal) — covering Logic and Integration stories
|
||||
- [ ] All Logic stories from this sprint have corresponding unit test files in the engine's unit-test location (`tests/unit/`, `Assets/Tests/EditMode/` or `Source/<Module>/Private/Tests/`)
|
||||
- [ ] Smoke check has been run with a PASS or PASS WITH WARNINGS verdict — report exists in `production/qa/`
|
||||
- [ ] At least one QA plan exists in `production/qa/` (generated by `/qa-plan`) covering this sprint, the final production sprint, or this production phase — run `/qa-plan` if missing (CONCERNS — advisory, not blocking)
|
||||
- [ ] QA sign-off report exists in `production/qa/` (generated by `/team-qa`) with verdict APPROVED or APPROVED WITH CONDITIONS
|
||||
@@ -20,7 +20,7 @@
|
||||
|
||||
**Quality Checks:**
|
||||
- [ ] Tests are passing (run test suite via Bash)
|
||||
- [ ] No critical/blocker bugs in any bug tracker or known issues
|
||||
- [ ] No open S1 Critical bugs in any bug tracker or known issues
|
||||
- [ ] Core loop plays as designed (compare to GDD acceptance criteria)
|
||||
- [ ] Performance is within budget (check `performance.*` in `project.yaml`, else technical-preferences.md targets)
|
||||
- [ ] Playtest findings have been reviewed and critical fun issues addressed (not just documented)
|
||||
@@ -37,11 +37,11 @@ reduction for the resolved tier; items not named keep their status above.
|
||||
Reductions only ever *relax* a requirement — `workflow_overrides` is the
|
||||
only thing that adds one.
|
||||
|
||||
- **`full`** — core mechanics + Logic/Integration tests + smoke check (PASS) + QA sign-off + 3+ playtests all required
|
||||
- **`full`** — core mechanics + Logic/Integration tests + smoke check (PASS or PASS WITH WARNINGS) + QA sign-off + 3+ playtests all required
|
||||
- **`standard`** — QA sign-off + per-story test coverage → recommended;
|
||||
**core mechanics + smoke check + playable end-to-end + 1+ documented
|
||||
playtest + no critical/blocker bugs** required
|
||||
- **`minimal`** — **smoke check + playable end-to-end + no critical/blocker
|
||||
playtest + no open S1 Critical bugs** required
|
||||
- **`minimal`** — **smoke check + playable end-to-end + no open S1 Critical
|
||||
bugs** required; the core-mechanics cross-check → recommended; everything
|
||||
else **drops**. Reductions relax what must *exist*, never what must *work* —
|
||||
a gate that closes production on "it boots" alone has not asked whether the
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
- [ ] At least 3 Architecture Decision Records in `docs/architecture/` covering
|
||||
Foundation-layer systems (scene management, event architecture, save/load)
|
||||
- [ ] Engine reference docs exist in `docs/engine-reference/[engine]/`
|
||||
- [ ] Test framework initialized: `tests/unit/` and `tests/integration/` directories exist
|
||||
- [ ] Test framework initialized: the engine's test root exists — `tests/unit/` and `tests/integration/` (Godot), `Assets/Tests/EditMode/` and `Assets/Tests/PlayMode/` (Unity), or `Source/<Module>/Private/Tests/` (Unreal); see `.claude/docs/directory-structure.md`
|
||||
- [ ] CI/CD test workflow exists at `.github/workflows/tests.yml` (or equivalent)
|
||||
- [ ] At least one example test file exists to confirm the framework is functional
|
||||
- [ ] Master architecture document exists at `docs/architecture/architecture.md`
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
**Required Artifacts:**
|
||||
- [ ] Vertical slice exists in `prototypes/` with a REPORT.md (run `/vertical-slice`) — **recommended, not blocking**; if absent, surface as CONCERNS
|
||||
- [ ] First sprint plan exists in `production/sprints/`
|
||||
- [ ] Art bible is complete (all 9 sections) and AD-ART-BIBLE sign-off verdict is recorded in `design/art/art-bible.md`
|
||||
- [ ] Art bible is complete (all 9 sections) and AD-ART-BIBLE sign-off verdict is recorded in `design/art/art-bible.md` — where `review_mode` skips that gate (`lean`, `solo`), a `SKIPPED` sign-off line `/art-bible` records stands in for it, and a header still reading `[Not yet reviewed]` on such a project reads "sign-off skipped — [mode] mode", never missing
|
||||
- [ ] Entity inventory exists at `design/assets/entity-inventory.md` (recommended — run `/asset-spec` with no arguments to generate collaboratively from GDDs + art bible)
|
||||
- [ ] All MVP-tier GDDs from systems index are complete
|
||||
- [ ] Master architecture document exists at `docs/architecture/architecture.md`
|
||||
@@ -51,6 +51,10 @@
|
||||
> **Verdict rules for Vertical Slice:**
|
||||
> - **Slice was built AND any validation item is NO** → verdict is automatically FAIL. A broken
|
||||
> or unfun vertical slice should not advance to Production.
|
||||
> - **Slice was built but its report says NOT ASSESSED** (nobody has played it) → it is not a
|
||||
> PROCEED, and its validation items were not checked (they are not NO): the Vertical Slice
|
||||
> Validation block does not run, so the FAIL rule above does not apply. The gate item is NOT
|
||||
> ASSESSED, never passed — and a "not yet" to "a human has played it" means the same.
|
||||
> - **Slice was not built (skipped)** → downgrade to CONCERNS only, not FAIL. Surface the risk
|
||||
> clearly: "Advancing without a validated Vertical Slice increases the risk of late-stage design
|
||||
> pivots. Recommended before committing full production scope." The user decides.
|
||||
@@ -63,16 +67,20 @@ reduction for the resolved tier; items not named keep their status above.
|
||||
Reductions only ever *relax* a requirement — `workflow_overrides` is the
|
||||
only thing that adds one.
|
||||
|
||||
- **`full`** — sprint plan + complete (9-section) art bible + epics + 3+ playtests + UX specs + control manifest all required; **Vertical Slice keeps its Section 2 status** (see note)
|
||||
- **`standard`** — **1+ playtest** required (not 3); epics + sprint plan required; art bible complete + UX specs + control manifest → recommended
|
||||
- **`minimal`** — only **sprint plan** required (the minimal floor); epics, playtests, art bible, UX, control manifest all **drop**
|
||||
- **`full`** — sprint plan + complete (9-section) art bible + epics + UX specs + control manifest all required; **Vertical Slice keeps its Section 2 status** (see note) — its playtest is recommended, 1 documented session with 3+ better
|
||||
- **`standard`** — epics + sprint plan required; art bible complete + UX specs + control manifest → recommended; **Vertical Slice keeps its Section 2 status**
|
||||
- **`minimal`** — the minimal floor only: a filled **`design/game-brief.md`** with its build order, and **stories** under `production/epics/` (`workflow-modes.md` — the brief's build order is the plan, so there is **no sprint plan**); everything else **drops** — sprint plan, epics, playtests, art bible, entity inventory, MVP GDDs, the master architecture document, both ADR items, control manifest, the UX items (key screen specs, HUD document, `/ux-review`), and the Vertical Slice items (the slice, its playtest, and the Vertical Slice Validation block) — the two current-build checks below replace them
|
||||
**Quality checks at `minimal`:** every check that reads a dropped artifact drops with it — the sprint-plan, architecture, both ADR, GDD-coherence, UX and accessibility checks, and the Player Fantasy check (no GDD holds one). Two still apply, to the current build instead of a slice: **the core loop is fun** (ask the user, or read a playtest note if one exists) and **it runs end to end** — one complete start → challenge → resolution cycle. A "no" to either is FAIL, as a NO on a built slice is at the other tiers; a "not yet" to the fun question means nobody has played the build — NOT ASSESSED.
|
||||
|
||||
> **The Vertical Slice keeps its Section 2 status at every tier.** The
|
||||
> **The Vertical Slice keeps its Section 2 status at `full` and `standard`.** The
|
||||
> Pre-Production → Production "prototype/Vertical Slice" floor is NOT upgraded to
|
||||
> blocking by the tier table — the Vertical Slice artifacts stay *recommended,
|
||||
> not blocking* (absent → CONCERNS, not FAIL) exactly as Section 2 defines, at
|
||||
> `full`, `standard`, and `minimal` alike. The genuinely-required floor item at
|
||||
> this gate is the **sprint plan**. The one hard rule that binds at every tier:
|
||||
> if a Vertical Slice *was built* and any of its validation items is NO, the
|
||||
> verdict is FAIL regardless of tier — tier reductions relax what must *exist*,
|
||||
> never what must *work*.
|
||||
> `full` and `standard` alike. At `minimal` they drop — the minimal route never
|
||||
> builds a slice — and the two current-build checks replace them. The
|
||||
> genuinely-required floor item at this gate is the **sprint plan** at `standard`
|
||||
> and `full`, and the **brief's build order plus stories** at `minimal`. The one
|
||||
> hard rule that binds at every tier: if a Vertical Slice *was built* and any of
|
||||
> its validation items is NO (at `minimal`, if the current build fails either of
|
||||
> its two checks), the verdict is FAIL regardless of tier — tier reductions relax
|
||||
> what must *exist*, never what must *work*.
|
||||
|
||||
@@ -11,11 +11,11 @@
|
||||
- [ ] Localization strings are externalized (no hardcoded player-facing text in the code root)
|
||||
- [ ] QA test plan exists (`/qa-plan` output in `production/qa/`)
|
||||
- [ ] QA sign-off report exists (`/team-qa` output — APPROVED or APPROVED WITH CONDITIONS)
|
||||
- [ ] All Must Have story test evidence is present (Logic/Integration: test files pass; Visual/Feel/UI: sign-off docs in `production/qa/evidence/`)
|
||||
- [ ] All Must Have story test evidence is present (Logic/Integration: test files pass; UI: retained screenshots of each screen touched; Visual/Feel: retained screenshots plus lead sign-off — both in `production/qa/evidence/`, and no `qa.level` waives either)
|
||||
- [ ] Smoke check passes cleanly (PASS verdict) on the release candidate build
|
||||
- [ ] No test regressions from previous sprint (test suite passes fully)
|
||||
- [ ] Balance data has been reviewed (`/balance-check` run)
|
||||
- [ ] Release checklist completed (`/release-checklist` or `/launch-checklist` run)
|
||||
- [ ] Release checklist completed (`/release-checklist` run)
|
||||
- [ ] Store metadata prepared (if applicable)
|
||||
- [ ] Changelog / patch notes drafted
|
||||
|
||||
@@ -23,9 +23,10 @@
|
||||
- [ ] Full QA pass signed off by `qa-lead`
|
||||
- [ ] All tests passing
|
||||
- [ ] Performance targets met across all target platforms
|
||||
- [ ] No known critical, high, or medium-severity bugs
|
||||
- [ ] No known open S1 Critical, S2 High or S3 Medium bugs
|
||||
- [ ] No open CRITICAL or HIGH findings in the newest `production/security/security-audit-*.md` whose **Scope** is `full`, as updated by any later `quick` report (the re-run `/security-audit` prescribes after remediation). A later `network`, `save` or `input` report adds its open findings but never clears a category it did not scan — any open CRITICAL or HIGH finding means not ready (a blocker). No `full`-scope audit report means the check could not run: this item is NOT ASSESSED, never passed. A report whose release recommendation is itself NOT ASSESSED makes this item NOT ASSESSED too
|
||||
- [ ] Accessibility basics covered (remapping, text scaling if applicable)
|
||||
- [ ] Localization verified for all target languages
|
||||
- [ ] Localization verified for all target languages — every translated locale being shipped has a `/localize qa` verdict of PASS or PASS WITH CONDITIONS (`production/localization/loc-qa-[locale]-[date].md`). A FAIL blocks that locale; the others may still ship. A locale with no QA report, or whose QA reported NOT ASSESSED (nobody has played it), has not been verified: this item is NOT ASSESSED, never passed. The source locale (`en`, per `/localize`) is not a target language and needs no `/localize qa` report; a game that ships only its source locale marks this item N/A and says so
|
||||
- [ ] Legal requirements met (EULA, privacy policy, age ratings if applicable)
|
||||
- [ ] Build compiles and packages cleanly
|
||||
|
||||
@@ -36,6 +37,6 @@ reduction for the resolved tier; items not named keep their status above.
|
||||
Reductions only ever *relax* a requirement — `workflow_overrides` is the
|
||||
only thing that adds one.
|
||||
|
||||
- **`full`** — all features + content complete + localization + QA sign-off + smoke (PASS) + no critical bugs all required
|
||||
- **`standard`** — content-complete audit + QA sign-off + localization → recommended; **all features + smoke + no critical bugs** required
|
||||
- **`minimal`** — only **smoke + no critical bugs** required; everything else **drops**
|
||||
- **`full`** — all features + content complete + localization + QA sign-off + smoke (PASS) + no open S1–S3 bugs all required
|
||||
- **`standard`** — content-complete audit + QA sign-off + localization → recommended; **all features + smoke + no open S1 Critical bugs** required; open S2 High and S3 Medium bugs → recommended
|
||||
- **`minimal`** — only **smoke + no open S1 Critical bugs** required; everything else **drops**
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
**Quality Checks:**
|
||||
- [ ] All MVP GDDs pass individual design review (8 required sections, no MAJOR REVISION NEEDED verdict)
|
||||
- [ ] `/review-all-gdds` verdict is not FAIL (cross-GDD consistency and design theory checks pass)
|
||||
- [ ] `/review-all-gdds` verdict is not FAIL (cross-GDD consistency and design theory checks pass). A NOT ASSESSED verdict does not satisfy this: that review could not compare the GDDs, so this item is NOT ASSESSED for the gate
|
||||
- [ ] All cross-GDD consistency issues flagged by `/review-all-gdds` are resolved or explicitly accepted
|
||||
- [ ] System dependencies are mapped in the systems index and are bidirectionally consistent
|
||||
- [ ] MVP priority tier is defined
|
||||
@@ -33,4 +33,6 @@ only thing that adds one.
|
||||
> has no meaning at `minimal` (no GDDs exist by design). Return a PASS verdict
|
||||
> with the note: *"No design gate at minimal workflow — minimal skips the
|
||||
> Systems Design phase; advancing brief → code."* The Section 6 stage write still
|
||||
> applies on user confirmation. Do NOT flag absent GDDs as blockers.
|
||||
> applies on user confirmation. Do NOT flag absent GDDs as blockers. This is the
|
||||
> named exception to Section 2b's rule that a gate with no required artifacts left
|
||||
> may not PASS; the director panel does not run for it.
|
||||
|
||||
Reference in New Issue
Block a user