Release 1.1.3 — long skills keep their later steps

Fix release for 1.1.2: the 14 longest skills keep their later phases
after a compaction, a question nobody answered is never taken as an
answer, settings read the same from a subfolder, the commit check works
for a project in a subfolder of a larger repository, every skill opens
with a title, and the shipped allow rules no longer approve deleting a
branch or writing files without asking. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.2 → v1.1.3).

Refs #83
Refs #133

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko

.claude/skills/smoke-check/references/4-manual-checks.md

@@ -0,0 +1,132 @@
+# /smoke-check — Phase 4: Run Manual Smoke Checks
+
+> Part of `/smoke-check`. `SKILL.md` names when to read this file; the settings it
+> resolved and the rules under its later headings still apply here.
+
+## Phase 4: Run Manual Smoke Checks
+
+**In this file:**
+
+- Checklist source: name it in the report
+- Batch 1 — Core stability
+- Batch 2 — Sprint changes and regression
+- Batch 3 — Data integrity and performance
+- Platform batches: PC, console, mobile
+
+Draw the smoke test checklist from, in priority order (and name the one you used in the report):
+1. The QA plan's "Smoke Test Scope" section (if QA plan was found in Phase 1)
+2. `production/qa/smoke-tests.md` (if it exists)
+3. `tests/smoke/` directory contents (if it exists)
+4. The standard fallback list below (used only when none of the above exist)
+
+**Name the source you used in the report**, on its own line — *"Checklist source:
+`production/qa/smoke-tests.md`"*, or *"Checklist source: standard fallback list —
+no QA plan scope, no `production/qa/smoke-tests.md`, no `tests/smoke/`."* The
+fallback is a real fallback, so nothing is silently skipped here; what was
+missing is that a report drawn from the generic list and one drawn from this
+project's own smoke definitions were indistinguishable. `/gate-check` now
+validates a smoke report's claims against the repo, and it cannot weigh them
+without knowing what the checklist was drawn from.
+
+Tailor batches 2 and 3 to the actual systems identified from the sprint or QA
+plan. Replace bracketed placeholders with real mechanic names from the current
+sprint's stories.
+
+Use `AskUserQuestion` to batch-verify. Keep to at most 3 calls.
+
+**Batch 1 — Core stability (always run):** one call, two questions — an empty
+failure list means nothing unless somebody launched the build.
+```
+question: "Did you launch the current build this session?"
+multiSelect: false
+options:
+  - "Yes — I launched it and checked the items below"
+  - "No — I have not launched the current build this session"
+
+question: "Core stability — select any items that FAILED (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "Game does not launch or crashes before reaching the main menu"
+  - "New game / session fails to start"
+  - "Main menu does not respond to inputs"
+  - "Crash or hang observed during basic navigation"
+```
+
+For any selected item, ask the user to briefly describe what failed before generating the report.
+
+If the build was **not launched**, the Batch 1 checks could not be executed:
+record them as `NOT RUN — build not launched this session`, skip Batches 2 and
+3 and any platform batch (say so — they need a running build), and ignore the
+unselected failure list. The verdict is then NOT ASSESSED unless something else
+FAILED.
+
+**Batch 2 — Sprint changes and regression (always run):**
+```
+question: "Sprint changes and regression — select any items that FAILED (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "[Primary mechanic this sprint] — FAILED"
+  - "[Second notable change this sprint, if any] — FAILED"
+  - "Regression in a previous sprint's feature — FAILED"
+  - "Other unexpected breakage observed — FAILED"
+```
+
+For any selected item, ask the user to briefly describe what broke before generating the report.
+
+**Batch 3 — Data integrity and performance (run unless `quick` argument):**
+```
+question: "Data integrity and performance — select any items that FAILED or were skipped (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "Save / load — FAILED (data loss or corruption observed)"
+  - "Save / load — N/A (save system not yet implemented)"
+  - "Frame rate drops or hitches observed — FAILED"
+  - "Performance not checked this session"
+```
+
+For any FAILED item selected, ask the user to describe what broke before generating the report.
+
+Record each response verbatim for the Phase 5 report.
+
+**Platform Batches** *(run only if `--platform` argument was provided)*:
+
+**PC platform** (`--platform pc` or `--platform all`):
+```
+question: "PC Platform — select any items that FAILED (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "Keyboard controls — FAILED (describe issue after)"
+  - "Mouse input or cursor visibility — FAILED (describe issue after)"
+  - "Windowed / fullscreen mode — FAILED (describe issue after)"
+  - "Resolution change — FAILED (describe issue after)"
+```
+
+For any selected item, ask the user to briefly describe what failed before generating the report.
+
+**Console platform** (`--platform console` or `--platform all`):
+```
+question: "Console Platform — select any items that FAILED (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "Gamepad input — FAILED (describe issue after)"
+  - "UI outside TV safe zone / text clipped — FAILED (describe what is clipped after)"
+  - "Keyboard/mouse fallback shown to gamepad user — FAILED (describe after)"
+  - "Cold start (no prior save) — FAILED (describe issue after)"
+```
+
+For any selected item, ask the user to briefly describe what failed before generating the report.
+
+**Mobile platform** (`--platform mobile` or `--platform all`):
+```
+question: "Mobile Platform — select any items that FAILED (leave all unselected if everything passed):"
+multiSelect: true
+options:
+  - "Touch controls — FAILED (describe issue after)"
+  - "Orientation change (portrait ↔ landscape) — FAILED (describe what breaks after)"
+  - "Background / foreground transition (home button) — FAILED (describe issue after)"
+  - "Performance / thermal throttling on target device — FAILED (describe after)"
+```
+
+For any selected item, ask the user to briefly describe what failed before generating the report.
+
+---