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
@@ -2,174 +2,217 @@
|
||||
|
||||
## Skill Summary
|
||||
|
||||
`/day-one-patch` prepares a day-one patch plan for issues that are known at
|
||||
launch but deferred from the v1.0 release. It reads open bug reports in
|
||||
`production/bugs/`, deferred acceptance criteria from story files (stories
|
||||
marked `Status: Done` but with noted deferred ACs), and produces a prioritized
|
||||
patch plan with estimated fix timelines per issue.
|
||||
`/day-one-patch` runs a fix-only mini-sprint for known issues found after the
|
||||
gold master: scope → rollback plan → fixes → lightweight QA gate → patch record.
|
||||
It runs only when the user types it (`disable-model-invocation: true`).
|
||||
|
||||
The patch plan is written to `production/releases/day-one-patch.md` after a
|
||||
"May I write" ask. If a P0 (critical post-ship) issue is discovered, the skill
|
||||
triggers guidance to run `/hotfix` before the patch. No director gates apply.
|
||||
The verdict is always COMPLETE.
|
||||
Phase 1 reads `project.stage` (`project.yaml`, fallback `production/stage.txt`)
|
||||
and requires `Release` or `Polish`; reads the most recent record in
|
||||
`production/gate-checks/` and **verifies the release gate passed** rather than
|
||||
inferring it from the stage; and loads bugs from `production/qa/bugs/*.md` with
|
||||
Status `Open` or `Fixed — Pending Verification`, plus the latest sprint and
|
||||
security audit. Phase 2 classifies each bug for inclusion (S1/S2, P1, fix under
|
||||
4 hours, data/config-only and cert requirements go in; architecture changes and
|
||||
new code paths are deferred to 1.1; S3/S4 only if a trivial config fix) and asks
|
||||
the user to approve the scope, with `[C] No day-one patch needed` as an exit.
|
||||
|
||||
Before any fix, `release-manager` drafts a rollback plan written to
|
||||
`production/releases/rollback-plan-[version].md`. Code fixes go through
|
||||
`lead-programmer`, which first returns each fix and the files it would change
|
||||
while writing nothing; the skill then asks once for the set — "May I apply these
|
||||
fixes? [BUG-ID → files]" — before any code changes, and `qa-tester` verifies each
|
||||
fix. Targeted and broader tests run with `commands.test` from `project.yaml`
|
||||
(unset → `Tests: NOT RUN` per fix, and the broader regression NOT ASSESSED).
|
||||
Config/data fixes are made directly, after a "May I edit" ask naming the file and
|
||||
the value change. `qa-lead` decides the QA scope (`/smoke-check`, or the affected
|
||||
systems' tests in the engine's test root); the patch QA verdict must be PASS or PASS WITH WARNINGS to
|
||||
proceed — FAIL defers the fix to 1.1 and NOT ASSESSED is never a pass. The patch
|
||||
record is written to `production/releases/day-one-patch-[version].md` after a
|
||||
"May I write" ask. No director gates are spawned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified automatically by `/skill-test static` — no fixture needed.
|
||||
Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] Frontmatter sets `disable-model-invocation: true`
|
||||
- [ ] Has ≥2 phase headings
|
||||
- [ ] Contains verdict keyword: COMPLETE
|
||||
- [ ] Contains "May I write" collaborative protocol language before writing the plan
|
||||
- [ ] Has a next-step handoff (e.g., `/hotfix` for P0 issues, `/release-checklist` for follow-up)
|
||||
- [ ] Contains verdict keywords: PASS, PASS WITH WARNINGS, NOT ASSESSED, FAIL
|
||||
- [ ] Contains "May I write" language for both the rollback plan and the patch record, and "May I edit" for a direct config/data fix
|
||||
- [ ] Has a next-step handoff (`/patch-notes`, `/bug-report verify`, `/retrospective [milestone-name]` for the launch milestone)
|
||||
|
||||
---
|
||||
|
||||
## Director Gate Checks
|
||||
|
||||
None. `/day-one-patch` is a release planning utility. No director gates apply.
|
||||
None of the director-tier agents (creative-director, technical-director,
|
||||
producer, art-director) is spawned. The skill spawns working agents —
|
||||
`release-manager` (rollback plan), `lead-programmer` and `qa-tester` (fixes),
|
||||
`qa-lead` (patch QA scope) — and checks the existing release-gate record in
|
||||
`production/gate-checks/`; it does not run `/gate-check` itself.
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — 3 Known Issues, Patch Plan With Fix Estimates
|
||||
### Case 1: Happy Path — Scope, rollback plan first, fixes, patch record
|
||||
|
||||
**Fixture:**
|
||||
- `production/bugs/` contains 3 open bugs with severities: 1 MEDIUM, 2 LOW
|
||||
- No deferred ACs in sprint stories
|
||||
- All bugs have repro steps and system identifications
|
||||
- `project.yaml` has `project.stage: Release`
|
||||
- The most recent file in `production/gate-checks/` records a release-gate PASS
|
||||
- `production/qa/bugs/` holds three Open bugs:
|
||||
- `BUG-0010` — S2, P1, code fix estimated at 2 hours
|
||||
- `BUG-0011` — S3, a one-value config/data fix
|
||||
- `BUG-0012` — S2, fix requires an architecture change
|
||||
|
||||
**Input:** `/day-one-patch`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads all 3 open bugs
|
||||
2. Skill assigns fix effort estimates: MEDIUM bug = 1-2 days, LOW bugs = 4 hours each
|
||||
3. Skill produces a patch plan prioritizing MEDIUM bug first
|
||||
4. Plan includes: priority order, estimated timeline, responsible system, fix description
|
||||
5. Skill asks "May I write to `production/releases/day-one-patch.md`?"
|
||||
6. File written; verdict is COMPLETE
|
||||
1. Phase 1 confirms Release stage and a passing release gate
|
||||
2. Phase 2 proposes including BUG-0010 and BUG-0011 and deferring BUG-0012
|
||||
("Fix requires architecture change — defer to 1.1"); `AskUserQuestion` offers
|
||||
Approve / Adjust / No day-one patch needed
|
||||
3. After approval, `release-manager` drafts the rollback plan and the skill asks
|
||||
"May I write this rollback plan to `production/releases/rollback-plan-[version].md`?"
|
||||
— no fix work starts before it is written
|
||||
4. `lead-programmer` returns BUG-0010's minimal fix and the files it would change,
|
||||
writing nothing; the skill asks "May I apply these fixes? [BUG-0010 → files]",
|
||||
and only on yes does `lead-programmer` implement it and run targeted tests with
|
||||
`commands.test`; `qa-tester` verifies it. BUG-0011's config
|
||||
change is made directly without a programmer agent, after the skill asks
|
||||
"May I edit `[config file]` — `[key]`: [old value] → [new value]?"
|
||||
5. `qa-lead` sets the QA scope; the QA verdict is PASS
|
||||
6. Skill asks "May I write this patch record to `production/releases/day-one-patch-[version].md`?"
|
||||
7. Record lists BUG-0010 and BUG-0011 under Bugs Fixed and BUG-0012 under Deferred to 1.1 with its reason
|
||||
8. Next steps offer `/patch-notes`
|
||||
|
||||
**Assertions:**
|
||||
- [ ] All 3 bugs appear in the plan
|
||||
- [ ] Bugs are prioritized by severity (MEDIUM before LOW)
|
||||
- [ ] Fix estimates are provided per issue
|
||||
- [ ] "May I write" is asked before writing
|
||||
- [ ] Verdict is COMPLETE
|
||||
- [ ] BUG-0012 is deferred to 1.1 because it needs an architecture change
|
||||
- [ ] Scope is approved via `AskUserQuestion` before any work
|
||||
- [ ] The rollback plan is written before any fix is attempted
|
||||
- [ ] No code file changes before the one "May I apply these fixes?" ask is approved, and `lead-programmer` writes nothing while proposing
|
||||
- [ ] BUG-0011 is fixed without spawning `lead-programmer`
|
||||
- [ ] The config file is not edited before a "May I edit" ask naming the file and the value change is approved
|
||||
- [ ] "May I write" names `production/releases/day-one-patch-[version].md`
|
||||
- [ ] Next steps include `/patch-notes`
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Critical Issue Discovered Post-Ship — P0, Triggers /hotfix Guidance
|
||||
### Case 2: Critical Bug That Cannot Be Fixed Safely — Accepted risk, rollback trigger
|
||||
|
||||
**Fixture:**
|
||||
- A CRITICAL severity bug is found in `production/bugs/` after the v1.0 release
|
||||
- The bug causes data loss for all save files
|
||||
- Release stage; release-gate PASS on record
|
||||
- `production/qa/bugs/` holds `BUG-0020` — S1 (save-file data loss) whose fix needs
|
||||
an architecture change — and `BUG-0021` — S2, P1, 1-hour fix
|
||||
|
||||
**Input:** `/day-one-patch`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads bugs and identifies the CRITICAL severity issue
|
||||
2. Skill escalates: "P0 ISSUE DETECTED — data loss bug requires immediate hotfix
|
||||
before patch planning can proceed"
|
||||
3. Skill does NOT include the P0 issue in the patch plan timeline
|
||||
4. Skill explicitly directs: "Run `/hotfix` to resolve this issue first"
|
||||
5. After P0 guidance is issued: plan for remaining lower-severity bugs is still
|
||||
generated and written; verdict is COMPLETE
|
||||
1. BUG-0020 is S1 but its fix requires an architecture change, so it is proposed
|
||||
for deferral to 1.1; BUG-0021 is included
|
||||
2. The user approves the scope; the patch proceeds for BUG-0021
|
||||
3. After the patch record is written, the skill warns: "S1 bugs remain open and were
|
||||
not patched. These are accepted risks. Document them in the rollback plan trigger
|
||||
conditions — if they occur at scale, rollback may be preferable to a follow-up patch."
|
||||
|
||||
**Assertions:**
|
||||
- [ ] P0 escalation message appears prominently before the patch plan
|
||||
- [ ] `/hotfix` is explicitly directed for the P0 issue
|
||||
- [ ] P0 issue is NOT scheduled in the patch plan timeline (it needs immediate action)
|
||||
- [ ] Non-P0 issues are still planned; verdict is COMPLETE
|
||||
- [ ] BUG-0020 appears in the deferred table with its reason (architecture change)
|
||||
- [ ] BUG-0021 is still patched — the S1 does not block the rest of the patch
|
||||
- [ ] The "S1 bugs remain open" warning is shown after the record is written
|
||||
- [ ] The warning points to the rollback plan's trigger conditions
|
||||
|
||||
---
|
||||
|
||||
### Case 3: Deferred AC From Story-Done — Pulled Into Patch Plan Automatically
|
||||
### Case 3: No Release-Gate Record — NOT ASSESSED, not assumed
|
||||
|
||||
**Fixture:**
|
||||
- `production/sprints/sprint-008.md` has a story with `Status: Done` and a note:
|
||||
"DEFERRED AC: Gamepad vibration on damage — deferred to post-launch patch"
|
||||
- No open bugs for the same system
|
||||
- `project.yaml` has `project.stage: Release`
|
||||
- `production/gate-checks/` is empty (no release-gate record)
|
||||
- Open bugs exist in `production/qa/bugs/`
|
||||
|
||||
**Input:** `/day-one-patch`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads sprint stories and detects the deferred AC note
|
||||
2. Deferred AC is automatically included in the patch plan as a work item
|
||||
3. Plan entry: "Deferred from sprint-008: Gamepad vibration on damage"
|
||||
4. Fix estimate is assigned; patch plan written after "May I write" approval
|
||||
5. Verdict is COMPLETE
|
||||
1. Phase 1 finds no release-gate record
|
||||
2. Reports `Release gate: NOT ASSESSED — no gate-check record found`
|
||||
3. States that the reduced QA scope depends on a gate nobody can find
|
||||
4. Asks whether to run `/gate-check` first or proceed with a full QA pass instead
|
||||
5. Does not proceed silently to scoping or fixes
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Deferred ACs from story files are automatically pulled into the plan
|
||||
- [ ] Deferred items are labeled by their source story (sprint-008)
|
||||
- [ ] Deferred AC gets a fix estimate like bug entries
|
||||
- [ ] Verdict is COMPLETE
|
||||
- [ ] `Release gate: NOT ASSESSED — no gate-check record found` is reported
|
||||
- [ ] `project.stage: Release` alone is not treated as proof the gate passed
|
||||
- [ ] User is offered `/gate-check` first or a full QA pass
|
||||
- [ ] No rollback plan, fix or patch record is produced before the user answers
|
||||
|
||||
---
|
||||
|
||||
### Case 4: No Known Issues — Empty Plan With Template Note
|
||||
### Case 4: Nothing Worth Patching — User selects "No day-one patch needed"
|
||||
|
||||
**Fixture:**
|
||||
- `production/bugs/` is empty
|
||||
- No stories have deferred ACs
|
||||
- Release stage; release-gate PASS on record
|
||||
- `production/qa/bugs/` holds only two S4 cosmetic bugs that need code changes
|
||||
|
||||
**Input:** `/day-one-patch`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads bugs — none found
|
||||
2. Skill reads story deferred ACs — none found
|
||||
3. Skill produces an empty patch plan with a note: "No known issues at launch"
|
||||
4. Template structure is preserved (headers intact) for future use
|
||||
5. Skill asks "May I write to `production/releases/day-one-patch.md`?"
|
||||
6. File written; verdict is COMPLETE
|
||||
1. Both S4 bugs are proposed for deferral (S3/S4 only if a trivial config fix)
|
||||
2. Scope question is asked; user selects `[C] No day-one patch needed`
|
||||
3. Skill outputs "No day-one patch required. Proceed to `/launch-checklist`." and stops
|
||||
4. No rollback plan, no agents, no patch record
|
||||
|
||||
**Assertions:**
|
||||
- [ ] "No known issues at launch" note appears in the written file
|
||||
- [ ] Template headers are present in the empty plan
|
||||
- [ ] Skill does NOT error out when there are no issues to plan
|
||||
- [ ] Verdict is COMPLETE
|
||||
- [ ] Both S4 bugs are listed as deferred, not included
|
||||
- [ ] On `[C]`, "No day-one patch required. Proceed to `/launch-checklist`." is shown
|
||||
- [ ] Skill stops without writing any file
|
||||
- [ ] No `release-manager`, `lead-programmer` or `qa-lead` is spawned
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Director Gate Check — No gate; day-one-patch is a planning utility
|
||||
### Case 5: Director Gate Check — Patch QA NOT ASSESSED is not a pass
|
||||
|
||||
**Fixture:**
|
||||
- Known issues present in production/bugs/
|
||||
- `project.yaml`: `modes.rigor: standard` (so a project with no game tests gets NOT ASSESSED, not WAIVED)
|
||||
- Release stage; release-gate PASS on record; one included S2/P1 fix implemented
|
||||
- `qa-lead` chooses a targeted smoke check; `/smoke-check` returns
|
||||
`NOT ASSESSED — no game tests found`
|
||||
|
||||
**Input:** `/day-one-patch`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill generates and writes the patch plan
|
||||
2. No director agents are spawned
|
||||
3. No gate IDs appear in output
|
||||
1. The skill does not treat NOT ASSESSED as PASS or PASS WITH WARNINGS
|
||||
2. It either obtains a real result (following what the verdict says would make it
|
||||
runnable) or defers the fix to 1.1
|
||||
3. No director-tier agent is spawned at any point and `/gate-check` is not run
|
||||
4. The patch record, if written, shows the QA verdict and fills "Not assessed" with what could not be checked and why
|
||||
|
||||
**Assertions:**
|
||||
- [ ] No director gate is invoked
|
||||
- [ ] No gate skip messages appear
|
||||
- [ ] Verdict is COMPLETE without any gate check
|
||||
- [ ] NOT ASSESSED does not let the patch proceed as if it passed
|
||||
- [ ] The fix is either re-verified with a real result or deferred to 1.1
|
||||
- [ ] No creative-director, technical-director, producer or art-director is spawned
|
||||
- [ ] Any written record states the QA verdict and what was not assessed
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Reads open bugs from `production/bugs/` before generating the plan
|
||||
- [ ] Scans story files for deferred AC notes
|
||||
- [ ] Escalates CRITICAL (P0) bugs with explicit `/hotfix` guidance
|
||||
- [ ] Produces an empty plan with note when no issues exist (not an error)
|
||||
- [ ] Asks "May I write to `production/releases/day-one-patch.md`?" before writing
|
||||
- [ ] Verdict is COMPLETE in all paths
|
||||
- [ ] Confirms Release/Polish stage and verifies the release-gate record before scoping
|
||||
- [ ] Loads bugs from `production/qa/bugs/*.md`
|
||||
- [ ] Gets user approval of the scope before any work
|
||||
- [ ] Writes the rollback plan before any fix
|
||||
- [ ] Asks once — "May I apply these fixes?" — before `lead-programmer` changes any code
|
||||
- [ ] Runs tests with `commands.test`, never a runner line from memory; with the key unset, says so (the broader regression is NOT ASSESSED)
|
||||
- [ ] Requires PASS or PASS WITH WARNINGS to proceed; FAIL defers the fix; NOT ASSESSED is never a pass
|
||||
- [ ] Asks "May I write" before the rollback plan and before the patch record, and "May I edit" before a direct config/data change
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- The case where multiple CRITICAL bugs exist is handled the same as Case 2;
|
||||
all P0 issues are escalated together.
|
||||
- Timeline estimation for the patch (e.g., "patch available in 3 days")
|
||||
requires manual QA and build time estimates; the skill uses rough estimates
|
||||
based on severity, not actual team velocity.
|
||||
- The patch notes player communication document (`/patch-notes`) is a separate
|
||||
skill invoked after the patch plan is executed.
|
||||
- A stage other than Release/Polish ("Day-one patch prep is for Release-stage
|
||||
projects") is not separately tested.
|
||||
- A most-recent gate record of FAIL, CONCERNS or NOT ASSESSED (name it and stop)
|
||||
is not separately tested.
|
||||
- The >1 day scope warning and the `cert-feedback` scope argument are not separately tested.
|
||||
|
||||
Reference in New Issue
Block a user