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-review/references/6-document-coverage.md

@@ -0,0 +1,25 @@
+# /architecture-review — Phase 6: Architecture Document Coverage
+
+> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it
+> resolved and the rules under its later headings still apply here.
+
+## Phase 6: Architecture Document Coverage
+
+**If `docs/architecture/architecture.md` does not exist, say so in the report** —
+`Architecture document coverage: NOT ASSESSED — no docs/architecture/architecture.md`
+— and carry it into the Phase 7 verdict per the trigger list below. Phase 5
+already models this for the engine consultation (*"A skipped check that says
+nothing is indistinguishable from a check that passed"*); this phase is the one
+that did not. Silently producing no Phase 6 findings reads as an architecture
+document that was checked and found clean, which is the opposite of what
+happened.
+
+If it exists, validate it against GDDs:
+
+- Does every system from `systems-index.md` appear in the architecture layers?
+- Does the data flow section cover all cross-system communication defined in GDDs?
+- Do the API boundaries support all integration requirements from GDDs?
+- Are there systems in the architecture doc that have no corresponding GDD
+  (orphaned architecture)?
+
+---