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/gate-check/references/5-verdict.md

@@ -0,0 +1,167 @@
+# /gate-check — Sections 5 and 5a: Verdict and Chain-of-Verification
+
+> Part of `/gate-check`. `SKILL.md` names when to read this file; the settings it
+> resolved and the rules under its later headings still apply here.
+
+## 5. Output the Verdict
+
+**In this file:**
+
+- 5. Output the Verdict: the report, `NOT ASSESSED`, verdict precedence
+- 5a. Chain-of-Verification: Steps 1-4
+
+```
+## Gate Check: [Current Phase] → [Target Phase]
+
+**Date**: [date]
+**Checked by**: gate-check skill
+
+### Required Artifacts: [X/Y present]
+- [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
+
+### Quality Checks: [X/Y passing]
+- [x] GDD has 8/8 required sections
+- [ ] Tests — FAILED (3 failures in tests/unit/)
+- [?] Core loop playtested — MANUAL CHECK NEEDED
+
+### Blockers
+1. **No Architecture Decision Records** — Run `/architecture-decision` to create one
+   covering core system architecture before entering production.
+2. **3 test failures** — Fix failing tests in tests/unit/ before advancing.
+
+### Recommendations
+- [Priority actions to resolve blockers]
+- [Optional improvements that aren't blocking]
+
+### 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 —
+  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**
+(a gate that could not check part of its scope has not established the phase is
+ready) and **ranks below CONCERNS and FAIL** (a known blocker is more actionable
+than an unknown, and demoting it behind an access problem buries it). It is not a
+softer FAIL: "I checked and found a blocker" and "I could not check" need
+different fixes — one needs work done, the other needs the input produced or made
+readable.
+
+**Verdict precedence — first matching rule wins**, evaluated in this order:
+**FAIL**, then **CONCERNS**, then **NOT ASSESSED**, then **PASS**. A gate with
+both a real blocker and an unassessable check is FAIL: the blocker is the
+actionable finding. Stating the order mechanically removes the inference — the
+rank sentence above says what outranks what, but only an ordered list says what
+to do when two conditions hold at once.
+
+Emit it when any of:
+
+- A **required artifact exists but cannot be assessed** — empty, unreadable, or
+  still entirely `[TO BE CONFIGURED]` / template placeholders. Present-but-empty
+  is the case that most looks like present.
+- A **quality check's input carries no measured data**. Section 3 compares the
+  performance budgets against "profiling data in `tests/performance/` or recent
+  `/perf-profile` output" — and `/perf-profile`'s report template pre-fills
+  `[16.67ms]` as the budget, so it can render ">99% headroom" from zero profiler
+  data. Placeholder numbers are not measurements: a budget nobody set is not a
+  budget that was met. Absent data already prompts (Section 4 offers to run
+  `/perf-profile`); this covers data that is *present and hollow*, which is the
+  case that looks like a measurement.
+- A **test check the tier requires could not be executed** — no test runner is
+  configured, or the runner is configured but failed to start. Section 3 runs the
+  suite "if a test runner is configured", and an unconfigured runner produced no
+  failures, so the test check contributed nothing to the verdict and the gate
+  could still reach PASS. Meanwhile `testing.strict.logic` and
+  `.integration` both default to `true`, so the project's own configuration
+  called those gates BLOCKING. A blocking gate that never ran is the unknown this
+  verdict exists to name. Remediation is already listed under Common Gaps
+  (`/test-setup`); this is what the verdict does with it.
+
+  > **Scope this to tiers that require tests.** At `qa.level: minimal` no test
+  > gates apply at all (see the config block above), so a missing runner there is
+  > the configured posture, not a hole — firing the trigger would make every
+  > `minimal` gate permanently NOT ASSESSED and stop stage advancement, the same
+  > over-broad reading the director trigger below warns against. Fires only where
+  > the resolved tier actually asked for the test check.
+- A **`MANUAL CHECK NEEDED` item the user never resolved**. Section 4 already
+  refuses to assume PASS for unverifiable items and marks them this way — but
+  until now the verdict vocabulary had nowhere to put one, so an unresolved
+  manual check had to land inside PASS, CONCERNS or FAIL anyway. This is where it
+  goes.
+- A director the **resolved tier was supposed to spawn** did not return — it
+  errored, produced no verdict, or was interrupted.
+
+  > **Scope this narrowly, and do not read it as "fewer than four directors ran".**
+  > Section 4b narrows the panel *by design* — 1 director at `minimal`, 2 at
+  > `standard`, 4 at `full`, and none in `solo` — and that narrowing is a
+  > deliberate, announced reduction, not a failure to assess. The broad reading
+  > makes every `minimal`, `standard` and `solo` gate permanently NOT ASSESSED,
+  > which means the verdict can never be PASS and Section 6 can never advance
+  > `project.stage`. **That would break stage advancement for most projects,**
+  > since those are the common tiers. The trigger fires only when a director the
+  > tier *did* call for fails to come back — a hole in the panel you expected,
+  > never the panel you deliberately chose.
+- A referenced upstream verdict is itself `NOT ASSESSED` — it propagates upward
+  rather than resolving to a pass.
+
+Never resolve an unknown by assuming the permissive reading. If the check could
+not run, that fact is the finding.
+
+---
+
+## 5a. Chain-of-Verification
+
+After drafting the verdict in Phase 5, challenge it before finalising.
+
+**Step 1 — Generate 5 challenge questions** designed to disprove the verdict:
+
+> **Tool-action requirement**: At least 2 of the 5 challenge questions below must be answered by re-reading a specific file (Read tool) or re-running a specific check (Grep tool) — not by reflection alone. Mark these with [TOOL ACTION] to indicate a tool was used.
+
+For a **PASS** draft:
+- "Which quality checks did I verify by actually reading a file, vs. inferring they passed?"
+- "Are there MANUAL CHECK NEEDED items I marked PASS without user confirmation? [TOOL ACTION] Re-scan the checklist for any [?] or MANUAL CHECK items."
+- "Did I confirm all listed artifacts have real content, not just empty headers? [TOOL ACTION] Re-read the file and check it has non-placeholder content."
+- "Could any blocker I dismissed as minor actually prevent the phase from succeeding?"
+- "Which single check am I least confident in, and why?"
+
+For a **CONCERNS** draft:
+- "Could any listed CONCERN be elevated to a blocker given the project's current state?"
+- "Is the concern resolvable within the next phase, or does it compound over time?"
+- "Did I soften any FAIL condition into a CONCERN to avoid a harder verdict?"
+- "Are there artifacts I didn't check that could reveal additional blockers?"
+- "Do all the CONCERNS together create a blocking problem even if each is minor alone?"
+
+For a **FAIL** draft:
+- "Have I accurately separated hard blockers from strong recommendations?"
+- "Are there any PASS items I was too lenient about?"
+- "Am I missing any additional blockers the user should know about?"
+- "Can I provide a minimal path to PASS — the specific 3 things that must change?"
+- "Is the fail condition resolvable, or does it indicate a deeper design problem?"
+
+**Step 2 — Answer each question** independently.
+Do NOT reference the draft verdict text — re-check specific files or ask the user.
+
+**Step 3 — Revise if needed:**
+- If any answer reveals a missed blocker → upgrade verdict (PASS→CONCERNS or CONCERNS→FAIL)
+- If any answer reveals a check that **could not be run** rather than one that
+  ran and passed → PASS→NOT ASSESSED. The first two PASS-draft questions above
+  ("verified by actually reading a file, vs. inferring", "MANUAL CHECK NEEDED
+  items I marked PASS") exist to find exactly this, and until now a yes to either
+  had no verdict to move to
+- If any answer reveals an over-stated blocker → downgrade only if citing specific evidence
+- Never revise NOT ASSESSED down to PASS by re-reasoning about the missing input.
+  Only obtaining the input clears it
+- If answers are consistent → confirm verdict unchanged
+
+**Step 4 — Note the verification** in the final report output:
+`Chain-of-Verification: [N] questions checked — verdict [unchanged | revised from X to Y]`
+
+---