ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 10:17:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Release 1.1.2 — the default path works end to end

Browse Source 
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
2026-09-29 21:32:19 +10:00
co-authored by Claude Opus 5.5
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/hotfix/SKILL.md
+62 -30
View File
@@ -12,17 +12,17 @@ model: sonnet
## Phase 1: Assess Severity
Read the bug description or ID. Assess severity using these criteria:
Read the bug description or ID. Assess severity on `/bug-triage`'s scale:
- **S1 (Critical)**: Game unplayable, data loss, security vulnerability
- **S2 (Major)**: Significant feature broken, workaround exists
- **S3 or lower**: Minor issue — normal bug fix workflow applies
- **S1 (Critical)**: Crash, data loss, or complete feature failure — the game cannot proceed (rate a security issue by that impact)
- **S2 (High)**: Major feature broken, but the game is still playable
- **S3 or lower**: Feature degraded with a workaround, or cosmetic — normal bug fix workflow applies
Confirm with `AskUserQuestion`:
- Prompt: "I've assessed this as **[assessed severity]** — [brief rationale]. Confirm severity to proceed:"
- Options:
- `[A] S1 (Critical) — game unplayable, data loss, or security issue`
- `[B] S2 (Major) — significant feature broken, workaround exists`
- `[A] S1 (Critical) — crash, data loss, or complete feature failure`
- `[B] S2 (High) — major feature broken, game still playable`
- `[C] S3 or lower — redirect to normal bug fix workflow`
If [C]: stop. Verdict: **REDIRECTED** — use the normal bug fix workflow for S3 and below.
@@ -75,6 +75,12 @@ Check whether this is a git repository:
If this command fails or returns empty: note "Not a git repository — create the branch manually." and skip branch creation.
`[base-ref]` is the release the bug is in. Releases are tags on `main` (the
trunk), so it is that release's tag (`git tag --list`; the newest is usually
the live build) — or its `release/*` branch, if one was cut to stabilise that
release (`git branch --list 'release/*'`). Never the head of `main`: it may carry
work that has not shipped.
If the check passes, use `AskUserQuestion` before creating the branch:
- Prompt: "Ready to create hotfix branch 'hotfix/[short-name]' from [base-ref]?"
- Options:
@@ -96,7 +102,7 @@ Present the root cause and proposed fix, then ask: "May I implement this fix?" D
## Phase 4b: Implement (only after approval)
Implement the approved minimal change. Validate the fix by running targeted tests for the affected system. Check for regressions in adjacent systems.
Implement the approved minimal change. Validate the fix by running targeted tests for the affected system, with `commands.test` from `project.yaml` (narrowed to the affected suite where the runner allows) — never a runner line written from memory, which drops the flags the engine needs (gdUnit4 hangs without `--remote-debug tcp://127.0.0.1:0`). Check for regressions in adjacent systems. If `commands.test` is unset, or no test covers the affected system, say so and record `Tests: NOT RUN — [reason]` in the hotfix record's Testing section; the Phase 5b QA gate then carries the verification.
Update the hotfix record with root cause, fix details, and test results.
@@ -124,8 +130,13 @@ After approvals, determine the QA scope required before deploying the hotfix. Sp
Ask qa-lead: **Is a full smoke check sufficient, or does this fix require a targeted team-qa pass?**
Apply the verdict:
- **Smoke check sufficient** — run `/smoke-check` against the hotfix build. If PASS, proceed to Phase 6.
- **Targeted QA pass required** — run `/team-qa [affected-system]` scoped to the changed system only. If QA returns APPROVED or APPROVED WITH CONDITIONS, proceed to Phase 6.
- **Smoke check sufficient** — run `/smoke-check` against the hotfix build. If PASS or
PASS WITH WARNINGS, proceed to Phase 6 (carry the warnings into the hotfix record).
If **FAIL**, do not deploy: return to Phase 4 with the failing checks, get the
revised fix approved there, implement it (Phase 4b), then re-run Phase 5's
approvals — qa-tester's regression run among them — and this QA step. A hotfix
that breaks the smoke suite is a second incident, not a fix.
- **Targeted QA pass required** — run `/team-qa feature: [affected-system]` scoped to the changed system only. If QA returns APPROVED or APPROVED WITH CONDITIONS, proceed to Phase 6; if NOT APPROVED or BLOCKED, handle it as a smoke-check FAIL above.
- **Full QA required** — S1 fixes that touch core systems may require a full `/team-qa sprint`. This delays deployment but prevents a bad patch.
**If the QA step returns `NOT ASSESSED`, the gate did not run — treat it as unmet,
@@ -136,7 +147,8 @@ is the one that will feel reasonable,
which is exactly why it is written down here. Either obtain the missing result —
the verdict names what would make it runnable — or take the decision to the
producer explicitly, as a decision to deploy an unverified hotfix rather than as a
gate that quietly cleared.
gate that quietly cleared. Log that decision — who made it, and why — in the
hotfix record's Testing section.
Do not skip this gate. A hotfix that breaks something else is worse than the original bug.
@@ -145,27 +157,38 @@ Do not skip this gate. A hotfix that breaks something else is worse than the ori
## Phase 6: Update Bug Status and Deploy
> **STOP — deployment requires explicit approval, unconditionally.** Merging a
> hotfix to a release branch is the one irreversible act in this skill, so it is
> gated even though branch creation (reversible) already is. Before any merge,
> tag, or deploy, use `AskUserQuestion`:
> hotfix and tagging the patch release is the one irreversible act in this skill,
> so it is gated even though branch creation (reversible) already is. Before any
> merge, tag, or deploy, use `AskUserQuestion`:
>
> - Prompt: "Hotfix validated and approved. Merge to the release branch and
> deploy?"
> - Options: `[A] Yes — merge and deploy` / `[B] Merge to development only — hold
> - Prompt: "Hotfix validated and approved. Merge to [targets], tag [patch tag]
> and deploy?" — `[targets]` is `main`, plus the release's `release/*` branch
> only if it has one
> - Options: `[A] Yes — merge and deploy` / `[B] Merge to main only — hold
> the release` / `[C] Stop here`
>
> This holds regardless of `modes.automation`, including `autonomous`. An
> emergency process is exactly where an unreviewed irreversible step is most
> likely and least recoverable.
> **Backport is not verified unless you verify it.** The frontmatter advertises
> "backport verified", and until this note the word `backport` appeared **once in
> this file — in that claim**. After merging, confirm the fix is present on BOTH
> the release branch and the development branch, and state the result. An
> unbackported hotfix means the bug returns in the next release from development,
> which is the single most common hotfix regression.
On `[A]`: merge the hotfix branch to `main`, and to the release's `release/*`
branch if it has one; tag the patch release (the next patch version, e.g.
`v1.2.0` → `v1.2.1`) on the fixed build — the `release/*` branch head if there
is one, else the hotfix branch head — and deploy that tag, not the head of
`main`. On `[B]`: merge to `main` only — no release-branch merge, no tag, no
deploy. On `[C]`: stop — no merge, no tag, no deploy and no bug-file update; the
hotfix record's Status stays IN PROGRESS, and say so.
Update the original bug file if one exists:
> **Backport is not verified unless you verify it.** The frontmatter advertises
> "backport verified". After merging, confirm the fix is present on `main` (the
> trunk) — and on the release's `release/*` branch, if it has one — and state
> the result. An unbackported hotfix means the bug returns in the next release
> tagged from `main`, which is the single most common hotfix regression.
Update the original bug file if one exists — find it in `production/qa/bugs/`
by its number, as `/bug-report verify` does. Ask first: "May I update
`production/qa/bugs/[bug file]` with the fix record below and set its Status to
`Fixed — Pending Verification`?"
```markdown
## Fix Record
@@ -176,10 +199,13 @@ Update the original bug file if one exists:
Set `**Status**: Fixed — Pending Verification` in the bug file header.
Output a deployment summary:
Output a deployment summary. Its title follows the Phase 6 answer — `Hotfix
Deployed: [short-name]` on `[A]`, `Hotfix Merged to main — release held:
[short-name]` on `[B]` — and on `[B]` the closing line omits the Tag, since none
was created:
```
## Hotfix Ready to Deploy: [short-name]
## Hotfix Deployed: [short-name]
**Severity**: [S1/S2]
**Root cause**: [one line]
@@ -187,18 +213,20 @@ Output a deployment summary:
**QA gate**: [Smoke check PASS / Team-QA APPROVED / NOT ASSESSED — [why, and whose
explicit decision it was to deploy anyway]]
**Approvals**: lead-programmer ✓ / qa-tester ✓ / producer ✓
**Backport**: [verified present on release AND development — or NOT VERIFIED, with
what was not checked]
**Backport**: [verified present on `main` (and the `release/*` branch, if the
release has one) — or NOT VERIFIED, with what was not checked]
**Rollback plan**: [from Phase 2 record]
Merge to: release branch AND development branch
Merge to: [targets] · Tag: [patch tag]
Next: /bug-report verify [BUG-ID] after deploy to confirm resolution
```
### Rules
- Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring
- Every hotfix must have a rollback plan documented before deployment
- Hotfix branches merge to BOTH the release branch AND the development branch
- A hotfix branch starts from the release it fixes — its tag, or its `release/*`
branch if one exists — and merges to `main` (the trunk), and to that
`release/*` branch only if it exists; the patch release is tagged
- All hotfixes require a post-incident review within 48 hours
- If the fix is complex enough to need more than 4 hours, escalate to `technical-director`
@@ -210,8 +238,12 @@ After deploying, run `/bug-report verify [BUG-ID]` to confirm the fix resolved t
If VERIFIED FIXED: run `/bug-report close [BUG-ID]` to formally close it.
If STILL PRESENT: the hotfix failed — immediately re-open, assess rollback, and escalate.
If CANNOT VERIFY: the fix is unconfirmed — do not close the bug; play its reproduction steps in the deployed build, then run `/bug-report verify [BUG-ID]` again and answer its manual-play question to settle it.
Schedule a post-incident review within 48 hours using `/retrospective hotfix`.
Schedule a post-incident review within 48 hours. `/retrospective` reviews a
sprint or milestone, not an incident: record the review with
`.claude/docs/templates/incident-response.md`, and raise its lessons at the next
`/retrospective`.
Use `AskUserQuestion`:
- Prompt: "Hotfix complete. What's the next step?"