@3fn/core 14.0.0 → 14.1.0

package/governance/Process-Hook-Operations.md

@@ -2,7 +2,7 @@
 id: process-hook-operations
 inclusion: manual
 name: Process-Hook-Operations
-description: Agent hook operational guidance — dependency chains, execution order, automatic file organization, troubleshooting, and best practices. Load when debugging hook issues, setting up or modifying hooks, or troubleshooting automation failures. NOTE - Release detection sections are outdated; the release system was rebuilt in Spec 065 as an on-demand CLI tool at src/tools/release/. See Release Management System.md for current architecture.
+description: Agent hook operational guidance — dependency chains, execution order, automatic file organization, troubleshooting, and best practices. Load when debugging hook issues, setting up or modifying hooks, or troubleshooting automation failures. NOTE - Release detection sections are historical; the Spec-065 release CLI was RETIRED 2026-08-12 (Q6 ballot) in favor of the manual release recipe. See Release Management System for current process.
 ---
 
 # Hook Operations Guide
@@ -25,7 +25,7 @@ This document provides detailed operational guidance for working with Kiro agent
 >
 > **2. "Task completion" now means merge (125-A PR-gate).** Since the ratified 125-A workflow, a task is accepted when its unit's **PR is merged** — not when a local status flips. The completion tool is `./.kiro/hooks/complete-task.sh` (opens the PR), which **superseded** the old commit-on-completion tooling. Work reaches `main` only through a merged, branch-protected PR. So the troubleshooting guidance below that frames "direct git commits" as *bypassing hooks* (versus using the `taskStatus` tool) is **Kiro-IDE-specific and predates the branch→PR→merge flow** — under the current workflow, committing and pushing a branch is a *correct, expected* step, not an error to avoid.
 >
-> **3. Release detection here is historical.** As the frontmatter notes, the release system was rebuilt in Spec 065 into an on-demand CLI (`src/tools/release/`); the release-detection-on-task-completion hook content below is retained for Kiro-hook operational history. See [Release Management System](release-management-system) for the current architecture.
+> **3. Release detection here is historical.** The Spec-065 release CLI was itself RETIRED on 2026-08-12 (Q6 ballot: `.kiro/docs/ballots/2026-08-12-q6-release-manager-retirement.md`), and the `release-manager.sh` hook described below was DELETED the same day; this content is retained solely as Kiro-hook operational history. See [Release Management System](release-management-system) for the current release recipe.
 >
 > This doc is preserved for Kiro-runtime hook operations and history. A cross-runtime rework belongs with the 122 agent-generator work (OB-7), not here.
 
@@ -1187,11 +1187,10 @@ Release detection triggers automatically when parent task summary documents are
 - `.kiro/` directory is filtered from Kiro IDE file watching (hooks don't trigger there)
 
 **Quick Reference**:
-- **Summary docs**: `docs/specs/[spec-name]/task-N-summary.md` (triggers hooks)
+- **Summary docs**: `docs/specs/[spec-name]/task-N-summary.md` (release-note source material)
 - **Detailed docs**: `.kiro/specs/[spec-name]/completion/task-N-parent-completion.md` (internal)
-- **Manual trigger**: `./.kiro/hooks/release-manager.sh auto`
 
-**For detailed guidance** on release detection pipeline, troubleshooting, hook debugging, and manual triggers, query Release Management System via MCP:
+**For the current release process** (the manual recipe; the detection hook was deleted 2026-08-12, Q6 ballot), query Release Management System via MCP:
 
 ```
 get_document_full({ path: "release-management-system" })
@@ -1199,8 +1198,8 @@ get_document_full({ path: "release-management-system" })
 
 Or query specific sections:
 ```
-get_section({ path: "release-management-system", heading: "Release Pipeline Architecture" })
-get_section({ path: "release-management-system", heading: "AI Agent Decision Points" })
+get_section({ path: "release-management-system", heading: "The Release Recipe" })
+get_section({ path: "release-management-system", heading: "Discovering What Changed and Why" })
 ```
 
 ---

package/governance/Process-Spec-Planning.md

@@ -403,8 +403,8 @@ During spec formalization (design-outline → requirements.md), Thurgood will id
 **Completion Documentation**:
 - Two documents per primary task:
   - Detailed: `.kiro/specs/[spec-name]/completion/task-[N]-parent-completion.md` (comprehensive internal documentation)
-  - Summary: `docs/specs/[spec-name]/task-[N]-summary.md` (concise public-facing summary, used by release tool)
-- Detailed docs preserve comprehensive knowledge; summary docs trigger hooks and serve as release notes
+  - Summary: `docs/specs/[spec-name]/task-[N]-summary.md` (concise public-facing summary — source material for hand-authored release notes)
+- Detailed docs preserve comprehensive knowledge; summary docs serve as release-note source material
 
 **Sub-tasks**:
 - Focus on implementation steps
@@ -2227,25 +2227,20 @@ Developers can now:
 
 ### Parent Task Summary Documents
 
-**Purpose**: Create concise, commit-style summaries of parent task completion that serve as release note content for the release tool.
+**Purpose**: Create concise, commit-style summaries of parent task completion that serve as source material for hand-authored release notes.
 
 **Location**: `docs/specs/[spec-name]/task-N-summary.md`
 
 **When to Create**: After completing a parent task and writing detailed completion documentation in `.kiro/specs/[spec-name]/completion/task-N-parent-completion.md`
 
-**Hook Limitation**: Kiro IDE's `fileCreated` and `fileSaved` hooks only trigger for manual file operations through the IDE UI, not for programmatically created files by AI agents. This requires a hybrid approach:
-- **Automatic hooks**: Work for manually created/edited files through IDE UI
-- **Manual trigger**: Required for AI-assisted workflows after summary document creation
-
-**Rationale**: 
-- **Hook Triggering**: The `.kiro/` directory is filtered from Kiro IDE's file watching system, preventing hooks from triggering on files created there. Summary documents in `docs/specs/` directory enable automatic release detection for manual file operations.
-- **Dual Purpose**: Summary documents serve both as hook triggers and as concise, public-facing release note content.
+**Rationale**:
+- **Dual Purpose**: Summary documents are the concise, public-facing record of each parent task — the source material the release recipe reads when authoring release notes.
 - **Clear Separation**: Detailed completion docs (internal knowledge preservation) remain in `.kiro/`, while summaries (public-facing) live in `docs/`.
-- **Hybrid Approach**: Automatic hooks for manual edits, manual trigger for AI workflows ensures release detection works in all scenarios.
+- *(Historical: `docs/`-placement also served a Kiro release-detection hook and its manual trigger, deleted 2026-08-12 — Q6 ballot. The public/internal split stands on its own.)*
 
 **Forward-Looking Note**: This summary document workflow applies to new specs going forward. Existing completion documents don't need changes.
 
-**Release Analysis**: The release tool (`src/tools/release/`) scans summary documents via git log to generate release notes. Release analysis runs post-merge on `main` (non-blocking); run `npm run release:analyze` for on-demand detail.
+**Release notes**: hand-authored per the release recipe (Release Management System) — the author derives the delta from squash titles since the last tag and reads summary docs for each change's substance. (The automated release tool was retired 2026-08-12, Q6 ballot.)
 
 **Format Template**:
 
@@ -2294,7 +2289,7 @@ Developers can now:
 - 🟡 **Ecosystem** — new tools, agents, MCPs, build system changes, or third-party integrations. Surfaced prominently.
 - 🔵 **Internal** — governance updates, process changes, infrastructure work. Included as context.
 
-When present, the release tool uses this for accurate classification. When absent, it falls back to section-based extraction. Include when your task delivers artifacts that should appear in release notes.
+When present, the release-notes author uses this for accurate classification. Include when your task delivers artifacts that should appear in release notes.
 
 **Example - Task 1 Summary**:
 
@@ -2503,7 +2498,6 @@ When creating cross-references, calculate relative paths based on the source doc
 - Manual task status updates → `complete-task.sh` on the task branch → No agent hooks triggered
 - **Benefit**: Simpler, direct control
 - **Use when**: Quick fixes, non-spec work, or when agent hooks aren't needed
-- **Note**: Run `npm run release:analyze` for on-demand release analysis
 
 ---
 

package/governance/Rosetta-System-Architecture.md

@@ -313,10 +313,11 @@ Semantic color tokens are resolved into light and dark mode sets before generati
 │                       MODE RESOLUTION SUBSYSTEM                              │
 ├─────────────────────────────────────────────────────────────────────────────┤
 │                                                                              │
-│   Level 1: Primitive Mode Values                                             │
-│   ├── Primitives carry distinct light/dark values in ColorTokenValue         │
-│   ├── Same primitive name in both modes — primitive handles differentiation │
-│   ├── Handles the common case (~85% of semantic color tokens)               │
+│   Level 1: Primitive Value Resolution (no mode variance)                     │
+│   ├── Primitives are single OKLCH triples — NO mode dimension (Spec 112)    │
+│   ├── No dark override → token falls back to the base (light) reference,    │
+│   │   resolving to the SAME value in both modes                             │
+│   ├── The common case — see npm run audit:mode-parity for the live split    │
 │   └── Resolved by: SemanticValueResolver                                    │
 │                                                                              │
 │   Level 2: Semantic Overrides                                                │
@@ -334,7 +335,8 @@ Semantic color tokens are resolved into light and dark mode sets before generati
 │                                                                              │
 │   Fallback Behavior                                                          │
 │   ├── Absent dark override → token uses base (light) primitive reference    │
-│   ├── Absent dark primitive value → primitive's light value used            │
+│   │   — the ONLY fallback that fires; primitives have no mode values to     │
+│   │   fall back from (legacy ColorTokens.ts is deprecated, Spec 115)        │
 │   ├── Fallback is graceful degradation, not build failure                   │
 │   └── Mode parity audit reports fallback usage: npm run audit:mode-parity   │
 │                                                                              │

package/governance/Token-Quick-Reference.md

@@ -13,7 +13,7 @@ description: Token documentation routing table — maps token types to their MCP
 **Scope**: cross-project
 **Layer**: 2
 **Relevant Tasks**: component-development, token-selection, styling
-**Last Reviewed**: 2026-06-24
+**Last Reviewed**: 2026-08-25
 
 ---
 
@@ -52,32 +52,50 @@ This document serves as a routing table for token documentation—it helps AI ag
 
 Semantic color tokens support light/dark mode through a two-level resolution system. Use this guide to determine how a token behaves across modes.
 
+**Prerequisite fact (Spec 112).** Color primitives have **no mode dimension**. A primitive is a single OKLCH triple (`{ l, c, h }`) composed from channel references in `src/tokens/color/` — the same value in light and dark. Mode differentiation therefore happens **only** at the semantic tier, via a theme override. Zero primitives in the system carry differing light/dark values.
+
 ### Does My Token Need a Dark Override?
 
 | Question | Answer | Resolution Level |
 |----------|--------|-----------------|
-| Is the token mode-invariant (print, glow, scrim, contrast.onLight/onDark)? | Yes → same value in both modes | Mode-invariant — no action needed |
-| Does the token use the same primitive name in both modes, just with different light/dark values? | Yes → primitive handles it | Level 1 — populate primitive's dark value in `ColorTokens.ts` |
-| Does the token need a *different primitive name* in dark mode (role remapping)? | Yes → semantic override needed | Level 2 — add entry to the appropriate theme's SemanticOverrides |
+| Is the token mode-invariant *by design* (print, glow, scrim, contrast.onLight/onDark)? | Yes → same value in both modes, declared as intentional | Mode-invariant — listed in `MODE_INVARIANT_TOKENS` (`src/validators/ModeParity.ts`); no theme-file entry needed |
+| Is the same value correct in both modes? | Yes → no override | **Level 1** — leave the token **commented out** in the dark theme file; it falls back to the base (light) reference |
+| Does the token need a *different primitive* in dark mode (role remapping)? | Yes → override needed | **Level 2** — add an active entry to the appropriate theme's SemanticOverrides |
+
+> **Level 1 does not mean "the primitive handles it."** No primitive varies by mode. Level 1 means *the token deliberately resolves to the same value in both modes*, and the commented-out theme-file line is the record of that decision. A token that must actually change in dark mode needs a Level 2 override — there is no other mechanism.
 
-### Level 1 Example (Primitive Handles Mode)
+### Level 1 Example (Falls Back to Base — Same Value in Both Modes)
 
-`color.structure.canvas` references `white100`. The primitive `white100` carries its own light/dark values:
+`color.feedback.error.text` references `pink400`. It has no active dark override; the entry sits commented out in the dark theme file (`src/tokens/themes/dark/SemanticOverrides.ts:27`):
+```typescript
+// color.feedback.error.text: { value: 'pink400' }
 ```
-white100.light.base = 'oklch(1.0 0 0)'      // white in light mode
-white100.dark.base  = 'oklch(0.21 0 0)'     // near-black in dark mode
+`pink400` resolves to one OKLCH value used in both modes — `l` 0.55 (`channels/lightness/chromatic.ts`), `c` 0.203 (`channels/chroma/chromatic.ts`), `h` 10 (`channels/hues.ts`). The emitted CSS carries a single value with no `light-dark()` wrapper (`dist/DesignTokens.web.css:527`):
+```css
+--color-feedback-error-text: oklch(0.55 0.203 10);
 ```
-No semantic override needed — the primitive handles differentiation.
 
 ### Level 2 Example (Semantic Override)
 
-`color.action.navigation` references `cyan500` in light mode, but dark mode needs `cyan100` (a different primitive). The dark theme overrides the reference:
+`color.structure.canvas` references `white100` in light mode, but dark mode needs `gray400` (a different primitive). The dark theme overrides the reference (`src/tokens/themes/dark/SemanticOverrides.ts:163`):
 ```typescript
 // Dark theme SemanticOverrides
 export const darkSemanticOverrides: SemanticOverrideMap = {
-  'color.action.navigation': { primitiveReferences: { value: 'cyan100' } },
+  'color.structure.canvas': { primitiveReferences: { value: 'gray400' } },
 };
 ```
+Because the modes now resolve to different values, the generator emits a mode-aware value (`dist/DesignTokens.web.css:559`):
+```css
+--color-structure-canvas: light-dark(oklch(1 0 260), oklch(0.42 0.018 260));
+```
+
+### Which File Actually Changes a Color?
+
+| Goal | Edit | Note |
+|------|------|------|
+| Make a semantic token differ by mode | The theme's `SemanticOverrides.ts` (Level 2) | The only mechanism that produces mode variance |
+| Change a primitive's color value | `src/tokens/color/channels/**` (lightness / chroma / hue) | Changes the primitive in **both** modes and every theme; composed into named primitives in `src/tokens/color/primitives/**` |
+| — | ~~`src/tokens/ColorTokens.ts`~~ | **Deprecated (Spec 115).** `SemanticValueResolver.resolveColorPrimitive()` consults `composedColorMap` first, so for all 50 OKLCH primitives the legacy `light`/`dark`/`wcag` slots are never read on the CSS/Swift/Kotlin path. Only the four shadow primitives (`shadowBlack100`, `shadowBlue100`, `shadowOrange100`, `shadowGray100`) still fall through to it. It *is* still the sole source for DTCG/Figma primitive export — see `.kiro/issues/2026-08-25-dual-color-source-divergence.md`. |
 
 ### Context Resolution
 
@@ -297,25 +315,20 @@ Returns targeted content (~2,000 tokens) for specific information:
 ```
 // Get color concept tokens by category
 get_section({ path: "token-family-color", heading: "Feedback Concept" })
-get_section({ path: "token-family-color", heading: "Identity Concept" })
-get_section({ path: "token-family-color", heading: "Action Concept" })
-get_section({ path: "token-family-color", heading: "Contrast Concept" })
-get_section({ path: "token-family-color", heading: "Structure Concept" })
-
-// Get component-specific color tokens
-get_section({ path: "token-family-color", heading: "Component Tokens" })
+get_section({ path: "token-family-color", heading: "Identity, Action, Contrast, Structure, Progress" })
 
 // Get primitive color families
-get_section({ path: "token-family-color", heading: "Primitive Color Families" })
+get_section({ path: "token-family-color", heading: "Neutral Partition" })
+get_section({ path: "token-family-color", heading: "Chromatic Families" })
 
 // Get spacing scale values
-get_section({ path: "token-family-spacing", heading: "Spacing Scale" })
+get_section({ path: "token-family-spacing", heading: "Primitive Spacing Tokens" })
 
 // Get typography composition patterns
-get_section({ path: "token-family-typography", heading: "Typography Composition" })
+get_section({ path: "token-family-typography", heading: "Typography Token Categories" })
 
 // Get shadow elevation levels
-get_section({ path: "token-family-shadow", heading: "Shadow Scale" })
+get_section({ path: "token-family-shadow", heading: "Shadow Semantic Tokens" })
 
 // Get radius values
 get_section({ path: "token-family-radius", heading: "Primitive Radius Tokens" })

package/governance/Web-Authoring-Standards.md

@@ -397,7 +397,7 @@ get_document_full({ path: "web-authoring-standards" })
 For specific sections:
 ```
 get_section({ path: "web-authoring-standards", heading: "Hard Rules" })
-get_section({ path: "web-authoring-standards", heading: "Token Priority" })
+get_section({ path: "web-authoring-standards", heading: "3. Token Priority" })
 get_section({ path: "web-authoring-standards", heading: "Product Token Authoring (Sparky)" })
 get_section({ path: "web-authoring-standards", heading: "Naming Schema" })
 ```

package/governance/classification-map.md

@@ -192,6 +192,8 @@ education:
 history:
   - { date: 2026-07-14, change: "entry created from Experiment 1 classification (Task 1.4); per-surface assessments + candidate prune diff: .kiro/specs/125-B-classification-map/completion/pilot/pilot-row-assessment.md; prune candidate produced, not applied", by: thurgood }
   - { date: 2026-07-14, change: "prune applied via U1-p ballot (.kiro/docs/ballots/2026-07-14-npm-test-imperative-prune.md), staged on task/125-B-u1-p; probe (NO GROSS LOSS DETECTED) + trial (NO-DIFFERENCE-DETECTED) evidence attached; A2-pattern zero-hits + Jest-education-intact independently re-verified; awaiting Peter's ratification and the U1-p merge (which opens the Task 3.1 observation window)", by: thurgood }
+  - { date: 2026-08-25, change: "Wave-1 deferred adjudication of Test-Development-Standards ~:1468-1474 CLOSED (Wave 2, 5.3): the four-stage validation-timing list ('Pre-Merge: Complete validation suite / All linting passes / All tests pass / Manual review complete') RULED KEEP intact — lifecycle-taxonomy education parallel to the pilot's retained lane-selection teaching, not a standalone imperative; deleting stage 4 would break the four-stage model (blade-1 fails). FLAG recorded, not actioned: 'All linting passes' describes a gate that does not exist (no lint required check) — known aspirational content, cited here so it is not silent drift. Owner consult AGREE (wave-2-consult-lina.md §4). Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md §3", by: thurgood }
+  - { date: 2026-08-25, change: "REGISTER-INTEGRITY repair (separate entry per the wave-2 consult nit): wave 1's typecheck-build-green-at-merge disposition claimed the TDS:1472 deferral was 'recorded on npm-test-before-complete's history' at wave-1 time — that history line never landed (the deferral lived only in the C3 row's own disposition). The preceding entry closes the deferral; this one records the dangling cross-reference and its repair, explicitly rather than silently", by: thurgood }
 ```
 
 ### tool-boot-smoke
@@ -210,6 +212,7 @@ education:
   disposition: "nothing to prune — no prose predecessor"
 history:
   - { date: 2026-07-14, change: "entry created (U1-s pilot substrate, Task 1.6); check wired: .github/workflows/tool-boot-smoke.yml + tests/tool-boot-smoke.test.ts; local run 49/49 passing incl. Product MCP passing index-empty (Req 5.2); side-effect confirmation + gate-bite proof plan recorded in .kiro/specs/125-B-classification-map/completion/task-1-6-completion.md", by: thurgood }
+  - { date: 2026-08-21, change: "context 125B-tool-boot-smoke added to verify-gate-registration.sh EXPECTED_CONTEXTS (drift reconciliation — the 2026-07-14 arming never updated the count-assert in the same recorded change; record: .kiro/issues/2026-08-21-gate-registration-drift-reconciliation.md, applied via this entry's PR)", by: thurgood }
 ```
 
 ### no-autonomous-token-creation
@@ -243,9 +246,10 @@ verification:
   check_state: armed
   checks: ["root functional lane — src/__tests__/console-fail-setup.ts wired via jest.config.js setupFilesAfterEnv; every root-lane test file; gate-bite proven live during Task 4.4 (clean tests pass, an injected unallowlisted console.error/console.warn fails the test)"]
 education:
-  disposition: "nothing to prune — no prose predecessor. The allowlist itself (src/__tests__/console-allowlist.json) is the citable record: each entry carries its own { suite, pattern, reason } — the adjudication lives with the data, not in steering prose."
+  disposition: "nothing to prune — no prose predecessor. The allowlist itself (src/__tests__/console-allowlist.json) is the citable record: each entry carries its own { suite, pattern, reason } — the adjudication lives with the data, not in steering prose. ROWS-ONLY (wave-2 finding, recorded 2026-08-25, CORPUS-WIDE sweep — owner-run, steward-spot-verified): every console hit in the education corpus outside this register is illustrative code inside a guide (Transformer-Development-Guide, MCP-Integration-Guide, browser-distribution-guide, Test-Failure-Audit-Methodology, Token-Resolution-Patterns, CDG:1713, TDS:1533/:1958) — no prose console rule exists ANYWHERE; the no-prose-predecessor claim holds corpus-wide, not just on the rostered surface. DISCLOSURE (wave-1 tooling-echo class, steward-verified): Progress web implementations console.warn on their clamp paths and the guard throws only when NODE_ENV==='development' — under Jest ('test') the WARN branch runs (ProgressPaginationBase.web.ts:191-201; Stepper equivalent); no allowlist entry exists; LATENT until someone writes a clamp-path test, which then needs an allowlist entry or a spy. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md §2; consult: wave-2-consult-lina.md (U4/U5)."
 history:
   - { date: 2026-07-14, change: "entry created (U2, Task 4.4): hook wired; allowlist seeded with 12 entries (10 from PR #39's adjudicated jsdom-stylesheet-limitation and deliberate-error-path-logging classes, discharging the pending jsdom-stylesheet-limitation doc-addition chip [125-B-backlog.md item 5]; 2 net-new — figma-extract.test.ts / figma-push.test.ts CLI-output classes discovered during this task's own full-suite gate-bite run); full root suite green (377 suites / 8987 tests). Mechanism built and row drafted by Lina; landed by Thurgood per the Task 4.1 register-writes-stay-with-the-steward convention — evidence: .kiro/specs/125-B-classification-map/completion/task-4-4-completion.md", by: thurgood }
+  - { date: 2026-08-25, change: "Wave 2 (5.3) rows-only finding recorded on CORPUS-WIDE evidence (owner-run sweep, steward-spot-verified) — zero imposter clauses in C6 territory; no prose console rule exists anywhere in the education corpus. Progress clamp-path console.warn latent tension disclosed (steward-verified: test env takes the WARN branch, not the throw branch). Owner consult: Lina R1+R2 (wave-2-consult-lina.md, U4/U5). Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md §2", by: thurgood }
 ```
 
 ### console-fail-subpackage-deferred
@@ -282,6 +286,7 @@ education:
   disposition: "nothing to prune — no prose predecessor. Record-only entry (Req 12.7): the check's already-armed state needed a citable register row; this is it."
 history:
   - { date: 2026-07-14, change: "entry created (U2, Task 4.4, Req 12.7) — record-only: verified already armed/blocking since 125-A, no work performed. Row drafted by Lina; landed by Thurgood per the Task 4.1 register-writes-stay-with-the-steward convention — evidence: .kiro/specs/125-B-classification-map/completion/task-4-4-completion.md", by: thurgood }
+  - { date: 2026-08-25, change: "ROSTERED into U1b wave 2 by Peter's amendment ruling (2026-08-25, record-first — this row was armed but rostered in NO campaign wave; gap found at consult U6). Education layer classified with wave 2: its only found imposter is the shared dual-rule clause CDS:513 ('Contracts reference valid WCAG criteria' — restates this rule AND wcag-required-refs in one line), cut as hunk W2-2 of the ratified wave-2 candidate diff; trial coverage via the informational R1'-fv line. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md", by: thurgood }
 ```
 
 ### inverse-drift-incremental-build
@@ -315,10 +320,13 @@ verification:
   check_state: armed
   checks: ["behavioral-contract-validation.test.ts 'accessibility-related contracts should have WCAG references' (root functional lane) — re-armed at the canonical allowlist matcher (Req 12.1-12.3). Match-count floor: aggregate selection > 0 (69 selected at Task 4.2's audit) PLUS per-literal presence for interaction_focusable (7 live), interaction_focus_ring (10 live), state_error (4 live). state_disabled is EXCLUDED from the per-literal floor pending the Button-CTA disabled-state adjudication (Peter, 2026-07-14 amendment) — the matcher itself is unchanged: state_disabled contracts (currently 1 live, Button-CTA) are still selected and still must carry a valid wcag ref, proven live via a gate-bite mutation (Task 4.3)"]
 education:
-  disposition: "nothing to prune — no prose predecessor taught the six-name trigger as a rule (it was implementation detail of a stale test, not documented education). The adjudication table (.kiro/specs/125-B-classification-map/completion/u2/stemma-pre-arm-adjudication.md) is the citable record of the 7 nulls resolved (4 genuine-defect fixes + 3 'N/A' legitimate-null exemptions) and the DD3 floor-input correction (design.md's recorded 11/11/21/4 were grep over-counts conflating live contracts: with excludes: blocks; true live counts are 7/10/1/4)."
+  disposition: "WAVE-2 ROW (5.3, 2026-08-25) — prune CANDIDATE pending ratification: corpus-wide sweep (steward + owner enumerations converged) found 3 imposter deletions (CDS:686 and CDS:513 checklist restatements — CDS:513 dual-rule with wcag-format-validity; PIG:468 review-template restatement inside a decorative yaml fence) + 2 contradiction REWRITES (CDS:824 wrong-trigger line; CSR:183 field-table 'null if not applicable' — instructs the exact form that reds the gate for allowlisted contracts). KEEP set: CDS:612 why-education; CDS:823 accurate schema field list; CMDT:681 out-of-territory (validates the family-doc table, which the gate never reads); TBCV:63/:67 the genuine teacher; CDG wcag-THEME (different concept); CSR:152/:185 schema reference. EDUCATION-DRIFT HAZARD (recorded per the owner consult — the strongest methodology finding of the campaign: a KEEP-classified education surface can defeat an armed gate WITHOUT restating it): Component-Templates.md :699-849 teaches SEVEN retired pre-063 contract names (focusable, pressable, hoverable, error_state, success_state, loading_state, focus_ring) that the allowlist matcher cannot select — a scaffolding author produces contracts the gate never checks; CIS:79-90 legacy names + wrong count; family-doc tables name accessibility contracts WITHOUT the accessibility_ prefix (routing around the matcher); CDS:804-829 block lists post-063-removed schema fields. The per-literal floor is a corpus-liveness alarm, NOT per-component coverage — it will not fire on new drift. Repair = Lina's ballot items (Component-Templates FIRST), sequenced per the Peter ruling recorded at ratification. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md; consult: wave-2-consult-lina.md (R1+R2). PRIOR STATE (U2, retained): no prose predecessor taught the six-name trigger; the adjudication table (.kiro/specs/125-B-classification-map/completion/u2/stemma-pre-arm-adjudication.md) records the 7 nulls resolved and the DD3 floor-input correction (true live counts 7/10/1/4)."
 history:
   - { date: 2026-07-14, change: "entry created (U2, Task 4.2 audit -> Task 4.3 arm): check re-armed, replacing the legacy 6-name trigger (behavioral-contract-validation.test.ts, formerly :325-350) with the normative allowlist matcher (C7) copied verbatim from .kiro/specs/125-B-classification-map/completion/u2/wcag-required-matcher.ts. State transition: DORMANT (armed-but-aimed-at-6-retired-legacy-names, discovered 125-B design-outline §3.3) -> armed (re-pointed at canonical allowlist; audit-clean per 4 WCAG-ref fixes + 3 legitimate-null 'N/A' exemptions applied to contracts.yaml BEFORE arming). Aggregate floor: 69 selected at audit. Bite-tested live (4 mutate/red/restore/green cycles). Row drafted by Lina; landed by Thurgood per the Task 4.1 register-writes-stay-with-the-steward convention — evidence: .kiro/specs/125-B-classification-map/completion/task-4-3-completion.md", by: thurgood }
   - { date: 2026-07-14, change: "Per-literal floor set to THREE literals (interaction_focusable, interaction_focus_ring, state_error) per Peter's in-session amendment to DD3's originally-recorded four (design.md still records four; this entry is the citable deviation record). state_disabled EXCLUDED from the per-literal floor pending the Button-CTA disabled-state adjudication — the matcher's WCAG_REQUIRED_EXACT set is UNCHANGED: state_disabled contracts (1 live, Button-CTA) are still selected and still must carry a valid wcag ref; the amendment narrows the floor assertion only, not the selection. This defuses the razor's-edge coupling risk Lina raised as a PETER-ESCALATION in Task 4.2's adjudication table (.kiro/specs/125-B-classification-map/completion/u2/stemma-pre-arm-adjudication.md §7). Drafted by Lina; landed by Thurgood — evidence: .kiro/specs/125-B-classification-map/completion/task-4-3-completion.md", by: thurgood }
+  - { date: 2026-08-25, change: "Wave 2 (5.3) classification: candidate diff produced (3 deletions + 2 rewrites, three surfaces — CDS/PIG/CSR), education-drift hazard recorded (Component-Templates seven retired names, CIS, family-doc unprefixed tables, CDS stale block), consumed unchanged by (b)'s probe+trial and applied only as ratified at (c). An R1 roster-bounded sweep reported rows-only and was FALSIFIED by the owner consult (Lina, BLOCKING x4) — the corpus-wide re-sweep found the candidates on surfaces the roster never named; both rounds + steward verification: wave-2-consult-lina.md. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md", by: thurgood }
+  - { date: 2026-08-25, change: "STALE-PENDING DISCHARGE (register currency, steward catch at wave 2): the 2026-07-14 floor amendment's state_disabled exclusion cites the Button-CTA disabled-state adjudication as 'pending' — it RESOLVED 2026-07-15, RULED REMOVE, implemented (.kiro/issues/button-cta-disabled-state-adjudication.md; CIS:90 records DesignerPunk does not support disabled states by design). The exclusion's rationale is therefore SETTLED, not pending: state_disabled stays outside the per-literal floor because no live instances exist by design; the matcher's WCAG_REQUIRED_EXACT still lists it (harmless — selects nothing; any future state_disabled contract is still selected and checked)", by: thurgood }
+  - { date: 2026-08-25, change: "Wave 2 rows + candidate diff RATIFIED (Peter, 2026-08-25, record-first, in-session at step (a) completion): the 5-hunk diff approved as the (b) probe+trial input (prune application still gated on (b) evidence + the wave ballot at (c)); roster/register amendment APPROVED (wcag-format-validity education layer rostered into wave 2 + contract-platforms-specified row created); sequencing RULED — Lina's Component-Templates repair lands BEFORE/WITH the wave-2 prune merge (option (a) of assessment §5.4)", by: thurgood }
 ```
 
 ### validation-criteria-completeness
@@ -334,9 +342,10 @@ verification:
   check_state: armed
   checks: ["behavioral-contract-validation.test.ts 'all contracts should have validation criteria' (root functional lane), formerly :435 -- promoted from toBeGreaterThan(0) to expect(contractsWithoutValidation).toBe(0); inherited-contract skip preserved. Bite-tested live: emptying a non-inherited contract's validation array reds the check; restored to green."]
 education:
-  disposition: "nothing to prune -- no prose predecessor. DD4's no-exemption-mechanism rationale (a zero-validation contract is defective by definition; escalate, don't self-exempt) is the citable design rationale, not restated in steering prose."
+  disposition: "nothing to prune -- no prose predecessor. DD4's no-exemption-mechanism rationale (a zero-validation contract is defective by definition; escalate, don't self-exempt) is the citable design rationale, not restated in steering prose. ROWS-ONLY (wave-2 finding, recorded 2026-08-25, CORPUS-WIDE sweep — steward + owner enumerations converged after the owner consult falsified a roster-bounded first pass): zero imposter clauses. Scored KEEPs beyond the roster: Test-Behavioral-Contract-Validation.md:63/:67 ('Every behavioral contract MUST pass these validation criteria:' — heads the section defining what good criteria CONTAIN, the how the gate cannot supply; the genuine teacher, owner-defended) and Component-Development-Standards.md:823 (fenced schema field list, accurate — the CSR:185 class). Rostered-surface hits are the category taxonomy (CSR:37/:85), the schema field table (CSR:185), example YAML, or component-capability descriptions (CIS — a different sense of 'validation'). No prune action exists for this rule; the clean state rests on corpus-wide enumeration. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md §2; consult: wave-2-consult-lina.md."
 history:
   - { date: 2026-07-14, change: "entry created (U2, Task 4.2 inventory -> Task 4.3 promotion): pre-promotion inventory (Task 4.2) found 234 non-inherited contracts, 0 without validation -- zero fixes, zero DD4 escalations needed (no trigger existed). Assertion promoted audit-first per Req 12.6 / Peter's 2026-07-13 approval. Flagged by Lina as beyond the explicit (a)/(b) drafting scope (one-rule-per-entry: this promotion governs a distinct assertion from wcag-required-refs) and accepted for landing on that basis. Row drafted by Lina; landed by Thurgood per the Task 4.1 register-writes-stay-with-the-steward convention — evidence: .kiro/specs/125-B-classification-map/completion/task-4-3-completion.md", by: thurgood }
+  - { date: 2026-08-25, change: "Wave 2 (5.3) rows-only finding recorded on CORPUS-WIDE evidence — zero imposter clauses in C5 territory (two beyond-roster candidates scored KEEP: TBCV:63/:67 owner-defended teacher; CDS:823 accurate fenced schema list). Owner consult: Lina R1+R2 (wave-2-consult-lina.md). Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md §2", by: thurgood }
 ```
 
 ### certainty-calibration
@@ -366,3 +375,100 @@ attribution:
 history:
   - { date: 2026-08-02, change: "entry created (119-B Task 1, unit U1 — window-free per R1 AC1; lands pre-measurement under the ratified R11 AC2 exception, with the keyword-shadowing check scheduled in the U2 case-study findings). Cite as governance/classification-map.md § 'certainty-calibration' (entry-id grammar, never count/position — R1 AC4). Drafted and landed by Thurgood per the steward-writes-register convention; pending Peter's ratification at the U1 merge. Evidence: .kiro/specs/119-B-capability-routing-measurement/completion/task-1-completion.md", by: thurgood }
 ```
+
+### section-citation-resolution
+
+```yaml
+rule: "A get_section heading citation in served or steering docs must resolve — the doc id must be MCP-served and the heading must exist on it"
+boundary_call:
+  class: functional
+  rationale: "Whether a citation resolves is a mechanical property of the artifact pair (id served + heading present) — no judgment; a dead citation silently withholds teaching from every agent that follows it"
+verification:
+  disposition: barrier
+  owner: thurgood
+  check_state: armed
+  checks: ["scripts/check-section-citations.ts (`npm run check:section-citations`), CI job .github/workflows/section-citations.yml, check context \"Section Citation Guard / section-citations\" — resolver-chain-aware (doc id -> indexed key -> frozen legacy manifest, reusing the runtime's own resolution helpers: extractFrontmatterInfo, FROZEN_LEGACY_MANIFEST), exact trimmed-string heading matching, identity-doc awareness (a citation targeting a never-served identity doc is a defect by construction), template-placeholder allowlist (`[family-name]`-style). Deliberate deviation from the D5 recipe: aliases do NOT pass resolution — resolveRef never consults them (alias is a find_docs scoring signal only), so an alias-only match fails at runtime; the checker flags it as a defect with a fix hint rather than treating it as resolved."]
+education:
+  disposition: "No prose prune — this row records a NET-NEW verification need. Known defect class recorded 2026-08-12: first-ever scan found ~14 dead citations of 135 (Token-Quick-Reference ~10 [Ada], Component-Readiness-Status 1 [Lina], identity-doc self-MCP-query examples in Spec-Feedback-Protocol + Civitas-System-Overview [Thurgood — identity docs are deliberately never MCP-served, so those example blocks teach a failing action]). Fixes + checker build completed 2026-08-12 via PR #122 — full execution record (re-scan counts, per-owner adjudications, deviations): .kiro/issues/2026-08-12-section-citation-defects-and-checker.md § 'Execution record'"
+history:
+  - { date: 2026-08-12, change: "entry created (steward, window-free — the certainty-calibration precedent) from the Q6-execution consult incident (Stacy caught two dead citations only because safeguard-2 happened to run) + the same-day corpus scan proving 14 pre-existing silent instances; evidence + adjudication table in the linked issue; check_state proposed — Peter ratifies the row at this PR's merge, the ARMING remains his separate flip", by: thurgood }
+  - { date: 2026-08-12, change: "row ratified at PR #122's merge (per the creation entry's own terms). PR #122 built the checker and fixed all 18 defects found by the resolver-chain-aware re-scan (183 citations checked; the issue table's ~15 plus one new exact-match catch, row 16 / Web-Authoring-Standards) — post-fix corpus 173 citations, 0 defects. Gate-bite proven red on throwaway PR #121 (one deliberate dead citation; run https://github.com/3fn/DesignerPunk/actions/runs/31608088052/job/94152123200), closed unmerged. Peter flipped \"Section Citation Guard\" required on main branch protection the same day, BEFORE U1b wave 1's prune merges — measurement-free per campaign law (no window open yet; not a boundary-event charge). check_state: proposed -> armed", by: thurgood }
+  - { date: 2026-08-21, change: "context \"Section Citation Guard\" added to verify-gate-registration.sh EXPECTED_CONTEXTS (drift reconciliation — the 2026-08-12 arming never updated the count-assert in the same recorded change; record: .kiro/issues/2026-08-21-gate-registration-drift-reconciliation.md, applied via this entry's PR)", by: thurgood }
+```
+
+### commit-to-main-via-pr-only
+
+```yaml
+rule: "Work never lands on main directly — commits ride task branches and land via PR merge (the C1 wave-1 row)"
+boundary_call:
+  class: operational
+  rationale: "A workflow-topology requirement (where work is allowed to land), mechanically owned by branch protection since 125-A — the gate rejects the PUSH (a local commit on main is non-durable and detected at push); the imperative restatements add no durable behavior the platform does not force"
+verification:
+  disposition: barrier
+  owner: thurgood
+  check_state: armed
+  checks: ["branch protection on main, admins included (platform gate, 125-A; admin-rejection proven in 125-A records; re-verified live 2026-08-02)"]
+education:
+  disposition: "PRUNED (wave 1, applied via ballot 2026-08-12-wave-1-workflow-gate-prune at the wave PR's merge) — six C1 hunks across TWO surfaces (wave-1-assessment.md §2): FOUR deletions (W1-1; W1-2/3 half-clauses; W1-4 half-clause) + one rewrite-to-descriptive (W1-5) on Task-Completion-Protocol, + one half-clause deletion (W1-9, consult catch) on Process-Development-Workflow § Troubleshooting. Clause-grain cuts justified per Req 10.2: the compound sentences' 'Never merge your own PR' halves are NOT gate-owned until U3 and are retained verbatim on every surface. Retained education: 'Direct pushes to main are rejected by branch protection, admins included' and all branch/PR-flow how-to prose (per-surface hit counts in the assessment). DISCLOSED: .kiro/hooks/complete-task.sh:372 echoes the compound imperative at completion time — tooling, outside the education corpus, retained (weak trial confound recorded)."
+history:
+  - { date: 2026-08-02, change: "entry created (U1b wave 1, Task 5.2 step (a)); clause scoring + candidate diff: .kiro/specs/125-B-classification-map/completion/u1b/wave-1-assessment.md + wave-1-candidate-diff.patch; Stacy process-owner consult recorded in the assessment; pending Peter's record-first row ratification", by: thurgood }
+  - { date: 2026-08-12, change: "rows ratified (Peter, record-first — commit 3c729da2); candidate diff RE-DERIVED post-#118 (context-only delta, assessment §3 note); step (b) verdicts: probe NO GROSS LOSS DETECTED + trial NO-DIFFERENCE-DETECTED (1 valid pair, zero voids, relevance gate passed on R1'-C1; evidence: wave-1-probe-evidence.md + wave-1-trial-diff-table.md); prune applied via ballot 2026-08-12-wave-1-workflow-gate-prune (record-first) at the wave-1 PR's merge — the wave-1 window (N=10) opens at that merge", by: thurgood }
+  - { date: 2026-08-02, change: "row RATIFIED (Peter, 2026-08-02, in-session record-first; post-consult revision reviewed) — classification approved; prune application still gated on 5.W(b) verification + the wave ballot", by: thurgood }
+```
+
+### squash-merge-only
+
+```yaml
+rule: "Squash-merge is the only merge method (the C2 wave-1 row)"
+boundary_call:
+  class: operational
+  rationale: "A repo-configuration fact (merge-method policy) — closed by configuration since 125-A; prose about it is almost entirely consequence-education (atomic history, PR title becomes the commit subject)"
+verification:
+  disposition: barrier
+  owner: thurgood
+  check_state: armed
+  checks: ["repository merge-method configuration: squash-only (platform config, 125-A)"]
+education:
+  disposition: "REWRITTEN (wave 1, applied via ballot 2026-08-12-wave-1-workflow-gate-prune at the wave PR's merge) — one rewrite only (W1-6: TCP:80's imperative-shaped lead becomes descriptive; the education after the dash is retained verbatim). All other squash prose (TCP:100/:117, PDW:130/:250) scored KEEP as retained-class education. Low prune yield expected and recorded up front."
+history:
+  - { date: 2026-08-02, change: "entry created (U1b wave 1, Task 5.2 step (a)); scoring + candidate hunk in wave-1-assessment.md / wave-1-candidate-diff.patch; pending Peter's record-first row ratification", by: thurgood }
+  - { date: 2026-08-12, change: "row ratified + TRIAL-EXEMPTION RULED (Peter, record-first, commit 3c729da2): C2 unscoreable by construction in a control arm (agents never merge); the single content-preserving rewrite rides on probe evidence + the window backstop — per-case exemption, never-prune-untested stands for trial-coverable rules. Probe evidence: symmetric silence on merge method + textual verification that the rewrite retains the full education (wave-1-probe-evidence.md). W1-6 context re-derived post-#118 (assessment §3). Rewrite applied via ballot 2026-08-12-wave-1-workflow-gate-prune at the wave-1 PR's merge", by: thurgood }
+  - { date: 2026-08-02, change: "row RATIFIED + TRIAL-EXEMPTION RULED (Peter, 2026-08-02, in-session record-first): C2 is unexercisable by agent trials by construction (merges are Peter-performed platform acts) — its single content-preserving rewrite (W1-6) rides on probe evidence + the window backstop, per-case exemption; the never-prune-untested rule stands for every trial-coverable rule (wave-1-assessment.md §4)", by: thurgood }
+```
+
+### typecheck-build-green-at-merge
+
+```yaml
+rule: "Full typecheck and build-validate must be green to merge (the C3 wave-1 row)"
+boundary_call:
+  class: functional
+  rationale: "The artifact requirement (tsc + build:validate green) is functional and owned by the armed lanes; no workflow imperative restating it survives in prose, so only the artifact half remains to classify — the DIVERGENCE from the twin row npm-test-before-complete (operational) is deliberate: that row classifies a surviving workflow imperative, this one classifies the artifact requirement alone"
+verification:
+  disposition: barrier
+  owner: thurgood
+  check_state: armed
+  checks: ["lane-typecheck (required check, armed 2026-07-10, frozen 18-context set)", "lane-build-validate (required check, armed 2026-07-10, frozen 18-context set)"]
+education:
+  disposition: "ROWS-ONLY (wave-1 finding, recorded 2026-08-02): the sweep found ZERO imposter clauses — TCP:44/:146/:149 are the pilot's own retained/rewritten education (untouched); BUILD-SYSTEM-SETUP:188/:210 are KEEP (local dev-loop guidance, no gate at that grain — the retained subtask-targeted-tests precedent); PTD/PSP hits are task-template examples. Late-found adjacent hit Test-Development-Standards:1472 is DEFERRED to Wave 2 with its surface (explicit call, recorded on npm-test-before-complete's history). No prune action exists for this rule; the row documents the clean state so future waves do not re-litigate it."
+history:
+  - { date: 2026-08-02, change: "entry created (U1b wave 1, Task 5.2 step (a)) as a rows-only finding; enumeration record in wave-1-assessment.md §5; pending Peter's record-first row ratification", by: thurgood }
+  - { date: 2026-08-02, change: "row RATIFIED (Peter, 2026-08-02, in-session record-first; post-consult revision reviewed) — classification approved; prune application still gated on 5.W(b) verification + the wave ballot", by: thurgood }
+```
+
+### contract-platforms-specified
+
+```yaml
+rule: "All behavioral contracts SHALL specify platforms — armed assertion behavioral-contract-validation.test.ts:275 'all contracts should specify platforms' (root functional lane)"
+boundary_call:
+  class: functional
+  rationale: "A machine-checkable presence check against a contract's own platforms field — the validation-criteria-completeness class"
+verification:
+  disposition: barrier
+  owner: lina
+  check_state: armed
+  checks: ["behavioral-contract-validation.test.ts:275 'all contracts should specify platforms' (root functional lane) — armed since 125-A; no implementation work performed in wave 2"]
+education:
+  disposition: "record-only entry (the wcag-format-validity Req 12.7 class): the check was armed but UNREGISTERED until wave 2's scoring of CDS:823 surfaced it (owner consult R2-2 — a gap-mode finding produced by adjudicating a KEEP line). Education layer: CDS:823's fenced schema field list (KEEP, wave 2) is the only known prose naming the obligation — accurate, retained. No imposters known; the territory sweeps with any future wave that touches its surfaces."
+history:
+  - { date: 2026-08-25, change: "entry created (U1b wave 2, Task 5.3 step (a)) per Peter's roster/register amendment ruling (2026-08-25, record-first, in-session — approved together with rostering wcag-format-validity's education layer into wave 2). Found by Lina at consult R2-2; drafted and landed by Thurgood per the register-writes-stay-with-the-steward convention. Related open question (5.6 closeout checklist item): whether the remaining non-C1-C11 armed rows are rostered anywhere. Evidence: .kiro/specs/125-B-classification-map/completion/u1b/wave-2-assessment.md; wave-2-consult-lina.md R2-2", by: thurgood }
+```

package/governance/completion-documentation-guide.md

@@ -24,9 +24,9 @@ This guide consolidates all guidance for creating completion documentation, incl
 - What content to include (documentation tiers)
 - Where to place files (directory structure)
 - How to name files (naming conventions)
-- Why summary docs matter (release detection)
+- Why summary docs matter (release-note source material)
 
-**Key Principle**: Parent task completion requires TWO documents - a detailed completion doc for internal knowledge preservation and a summary doc for release detection and public-facing release notes.
+**Key Principle**: Parent task completion requires TWO documents - a detailed completion doc for internal knowledge preservation and a summary doc as public-facing release-note source material.
 
 ---
 
@@ -39,12 +39,12 @@ Parent task completion produces two complementary documents:
 | Document Type | Location | Purpose | Audience |
 |---------------|----------|---------|----------|
 | **Detailed Completion Doc** | `.kiro/specs/[spec-name]/completion/` | Comprehensive internal documentation | Internal team, knowledge preservation |
-| **Summary Doc** | `docs/specs/[spec-name]/` | Concise, commit-style summary | Public-facing, release notes, hook trigger |
+| **Summary Doc** | `docs/specs/[spec-name]/` | Concise, commit-style summary | Public-facing, release-note source |
 
 **Rationale**:
-- **Hook Triggering**: The `.kiro/` directory is filtered from Kiro IDE's file watching system. Summary documents in `docs/specs/` enable automatic release detection.
-- **Dual Purpose**: Summary documents serve both as hook triggers and as concise, public-facing release note content.
+- **Dual Purpose**: Summary documents are the concise, public-facing record of each parent task — the source material the release recipe reads when authoring release notes.
 - **Clear Separation**: Detailed completion docs (internal knowledge preservation) remain in `.kiro/`, while summaries (public-facing) live in `docs/`.
+- *(Historical: the `docs/`-placement also served a Kiro release-detection hook, deleted 2026-08-12 — Q6 ballot. The placement stays: the public/internal split earns it on its own.)*
 
 ### When to Create Each Document
 
@@ -130,10 +130,10 @@ docs/specs/cross-platform-build-system/
 ### Two-Directory Structure
 
 ```
-docs/specs/[spec-name]/                   # Public-facing documentation (TRIGGERS HOOKS)
-├── task-1-summary.md                     # ✅ Parent task summary (triggers release detection)
-├── task-2-summary.md                     # ✅ Parent task summary (triggers release detection)
-└── task-N-summary.md                     # ✅ Parent task summary (triggers release detection)
+docs/specs/[spec-name]/                   # Public-facing documentation
+├── task-1-summary.md                     # ✅ Parent task summary (release-note source)
+├── task-2-summary.md                     # ✅ Parent task summary (release-note source)
+└── task-N-summary.md                     # ✅ Parent task summary (release-note source)
 
 .kiro/specs/[spec-name]/                  # Internal documentation (NO HOOK TRIGGERS)
 ├── requirements.md                        # ❌ Spec requirements (no hook trigger)
@@ -150,7 +150,7 @@ docs/specs/[spec-name]/                   # Public-facing documentation (TRIGGER
 
 | Location | Purpose | Hook Trigger | Audience |
 |----------|---------|--------------|----------|
-| `docs/specs/[spec-name]/` | Concise summaries | ✅ Yes | Public-facing, release notes |
+| `docs/specs/[spec-name]/` | Concise summaries | — (hook retired) | Public-facing, release-note source |
 | `.kiro/specs/[spec-name]/completion/` | Comprehensive docs | ❌ No | Internal, knowledge preservation |
 
 ---
@@ -282,18 +282,10 @@ Detailed completion documents can optionally link to the summary document:
 ### How Summary Documents Feed Release Notes
 
 1. **Summary document created** in `docs/specs/[spec-name]/`
-2. **Release tool** (`npm run release:analyze`) scans summary docs via git log since last tag
-3. **ChangeExtractor** parses markdown sections into structured data
-4. **ChangeClassifier** maps changes to priority tiers (🔴/🟡/🔵)
-5. **NotesRenderer** generates public + internal markdown release notes
+2. **At release time**, the release author derives the shipped delta from squash-commit titles since the last tag (`git log <last-tag>..main --oneline`) and reads summary docs for each change's substance and classification (🔴/🟡/🔵)
+3. **Release notes are hand-authored** at `docs/releases/release-X.Y.Z.md` from that material — summaries are the notes' source, and the durable per-task record
 
-### Automatic Analysis
-
-Release analysis runs post-merge on `main` (non-blocking). For on-demand analysis:
-
-```bash
-npm run release:analyze
-```
+*(The automated release tool that formerly scanned summaries was retired 2026-08-12 — Q6 ballot `.kiro/docs/ballots/2026-08-12-q6-release-manager-retirement.md`. See Release Management System § "The Release Recipe".)*
 
 ---
 
@@ -326,14 +318,6 @@ task-10-summary.md
 
 Summary documents are ONLY for parent tasks. Subtasks only need detailed completion docs.
 
-### ❌ Forgetting Manual Trigger for AI Workflows
-
-If AI agent created the summary document, you MUST run:
-```bash
-./.kiro/hooks/release-manager.sh auto
-```
-
----
 
 ## Workflow Checklist
 
@@ -350,7 +334,6 @@ If AI agent created the summary document, you MUST run:
 - [ ] Run validation (`npm test` or `npm run test:all`)
 - [ ] Create detailed completion doc: `.kiro/specs/[spec-name]/completion/task-N-completion.md`
 - [ ] Create summary doc: `docs/specs/[spec-name]/task-N-summary.md`
-- [ ] Trigger release detection: `./.kiro/hooks/release-manager.sh auto`
 - [ ] Mark parent task complete using `taskStatus` tool
 - [ ] Complete the parent on its unit branch: `./.kiro/hooks/complete-task.sh "..."` — completion and summary docs travel on the branch.
    - **If this parent IS its own merge unit** (a standalone task, or a small single-unit spec): the tooling opens the PR.
@@ -370,5 +353,5 @@ If AI agent created the summary document, you MUST run:
 ```
 get_section({ path: "process-spec-planning", heading: "Three-Tier Completion Documentation System" })
 get_section({ path: "process-development-workflow", heading: "Task Completion Workflow" })
-get_section({ path: "release-management-system", heading: "Release Pipeline Architecture" })
+get_section({ path: "release-management-system", heading: "The Release Recipe" })
 ```

package/governance/platform-implementation-guidelines.md

@@ -50,7 +50,7 @@ behavioral_contract_compliance:
 
 **Example - Float Label Animation Contract**:
 ```
-Contract: provides_float_label_animation
+Contract: content_float_label
 
 All platforms MUST:
 ✅ Animate label from placeholder to floating position on focus
@@ -465,7 +465,6 @@ pre_implementation:
   contract_review:
     - [ ] Each contract has clear trigger conditions
     - [ ] Each contract has measurable outcomes
-    - [ ] WCAG references included for accessibility contracts
     - [ ] Contracts are platform-agnostic (WHAT not HOW)
     
   human_ai_checkpoint: