Claude-Code-Game-Studios/CCGS Skill Testing Framework/skills/utility/day-one-patch.md

Skill Test Spec: /day-one-patch

Skill Summary

/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).

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)

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 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 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 — Scope, rollback plan first, fixes, patch record

Fixture:

• 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. 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:

• 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 Bug That Cannot Be Fixed Safely — Accepted risk, rollback trigger

Fixture:

• 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. 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:

• 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: No Release-Gate Record — NOT ASSESSED, not assumed

Fixture:

• 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. 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:

• 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: Nothing Worth Patching — User selects "No day-one patch needed"

Fixture:

• 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. 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:

• 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 — Patch QA NOT ASSESSED is not a pass

Fixture:

• 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. 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:

• 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

• 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

• 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.