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/architecture-decision/references/0-accept.md

@@ -0,0 +1,84 @@
+# /architecture-decision — Acceptance Mode
+
+> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it
+> resolved and the rules under its later headings still apply here.
+
+**If the argument starts with `accept` followed by an ADR id**
+
+(e.g., `/architecture-decision accept ADR-0005`):
+
+Enter **acceptance mode**. This is the *only* path in the framework that moves an
+ADR from `Proposed` to `Accepted`. Authoring always produces `Proposed`
+(Step 5), while
+`/create-control-manifest`, `/create-epics`, `/create-stories` and `/gate-check`
+all require `Accepted` — so without this mode the pipeline had a state it could
+enter and never leave.
+
+1. **Resolve the id to a file, then read it.** Glob
+   `docs/architecture/adr-NNNN-*.md` for the given number. If **no** file matches,
+   or **more than one** does, stop and say which — do not pick one. If the file
+   has no `## Status` section, stop and say so; a missing Status is exactly what
+   retrofit mode is for.
+2. **Check the current status.** If it is already `Accepted`, say so and stop.
+   If it is `Deprecated` or `Superseded`, refuse: reviving a superseded decision
+   is a new ADR, not a status edit.
+3. **Check its dependencies first.** Read `## ADR Dependencies`.
+
+   **If that section is absent, empty, or reads `UNKNOWN`, do not read it as
+   "no dependencies" — refuse and say which:**
+   > "ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what
+   > this decision rests on. An empty dependency list and an unexamined one look
+   > identical here, and only one of them is safe to accept. Run
+   > `/architecture-decision retrofit <path>` to establish it."
+
+   A dependency check reading a field that defaults to empty is the vacuous-pass
+   shape this gate exists to prevent — the check would examine nothing and report
+   clean.
+
+   If it depends on any ADR that is not itself `Accepted`, **refuse and name them**:
+   > "ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002
+   > first — an accepted decision resting on an unaccepted one is not a decision,
+   > it is a deferral with a different label."
+   This is the same dependency rule `/architecture-review` already flags; here it
+   is enforced rather than reported.
+4. **Confirm with the user, always.** Per `CONTRACT.md`, acceptance authority is
+   **the user, or `technical-director` on the user's explicit confirmation — no
+   other agent, and never this skill on its own.** Use `AskUserQuestion`:
+   - Prompt: "Accept ADR-NNNN — [title]? This is what unblocks stories and epics
+     that depend on it."
+   - Options: `[A] Yes — accept it` / `[B] Not yet — leave it Proposed`
+   **This prompt fires regardless of `modes.automation`, including `autonomous`.**
+   Acceptance is the decision the whole architecture pipeline gates on; it is not
+   a step to be inferred.
+5. **Find the stories this will unblock, BEFORE the prompt in step 4.** Grep
+   every story for a Blocked Status line —
+   `Grep pattern="Status\**:\**\s*Blocked" path="production/epics" glob="**/story-*.md" output_mode="files_with_matches"`,
+   which matches `> **Status**: Blocked` (the form `/create-stories` writes),
+   `**Status:** Blocked` and `Status: Blocked` — and keep the files that name
+   this ADR's id as the reason they are blocked. That pairing is what "blocked
+   pending this ADR" means — a story blocked for an unrelated reason will not
+   name it. Leave out a story that names this ADR only as the successor to point
+   at (`point the story at ADR-NNNN`, the note for a `Deprecated` or
+   `Superseded` ADR): it is still governed by the old ADR, and accepting the
+   successor does not re-point it.
+   > **Stories live only under `production/epics/`.** A flat top-level stories
+   > directory does not exist and no skill creates one — never write or match a
+   > path outside `production/epics/`. `/dev-story` matches entries *by file
+   > path*, so a story recorded under any other path silently fails to match and
+   > never gets picked up.
+
+   Feed the count into step 4's prompt so it reads *"3 stories become Ready"*
+   rather than a generic claim: **the user is being asked to authorise an effect, and should be
+   shown the effect.** If none match, say "no stories are waiting on this" — that
+   is useful information, not an empty result to omit.
+6. On confirmation, `Edit` the `## Status` line to `Accepted`. Leave an existing
+   `## Date` as it is: it records when the ADR was written, and `/create-stories`
+   stamps stories with it (or `## Last Verified`), so rewriting it on acceptance
+   would make every story drafted against the Proposed ADR look out of date to
+   `/dev-story`. **If that section is absent, add it** with today's date — retrofit
+   mode already owns this shape, and acceptance must not fail on a template that
+   predates the field.
+7. Then set each story found in step 5 from `Blocked` to `Ready`. Unblocking is a
+   consequence of acceptance, never of authoring — see Step 6's note below.
+8. Report what moved: the ADR (and its `## Date`, if one was added), and every
+   story that became Ready.