@3fn/core 14.0.0 → 15.0.0

package/dist/consumer-canonical/always-set/civitas-system-overview.overlay.md

@@ -0,0 +1,70 @@
+## @unit #overview @ sha256:e27d3c131615f18f5b656491e1cd7c2beff89d5a86acadfea0132830701efdc8
+## Overview
+
+Civitas is the governance layer — in DesignerPunk, and in this repo, which inherits the pattern: named alongside Rosetta (tokens) and Stemma (components) as the third foundational system. This repo's Civitas is its own, not DesignerPunk's. Where Rosetta provides the mathematical token foundation and Stemma provides the component architecture, Civitas provides the governance infrastructure that binds them together — the steering documentation, MCP servers, agent configurations, automation hooks, knowledge bases, and processes that enable the system to operate coherently.
+
+The name comes from the Latin concept of the social contract — the shared framework of obligations and participation that makes collective action possible. Civitas is not a place or a government; it is the connective tissue between participants and their shared standards.
+
+Civitas is architecturally different from its siblings. Rosetta has a unified artifact format (token definitions with mathematical formulas). Stemma has a unified artifact format (component schemas with behavioral contracts). Civitas is a governance umbrella over heterogeneous artifacts — markdown files, JSON configurations, shell scripts, TypeScript validators, and indexed knowledge bases. This heterogeneity is intentional: governance infrastructure serves diverse purposes and doesn't benefit from a single format.
+
+---
+
+## @unit #what-civitas-contains @ sha256:6d5bb7e904c10be1b5bf04b25fd03b6f5222b3e5ea2b46c92b40aa4b6debf137
+## What Civitas Contains
+
+**Identity documentation** (always loaded):
+- The generated `designerpunk-*` identity members — this repo's collaboration principles, feedback protocol, startup checklist, completion protocol, agent directory, and these overviews
+- Your team's personal note (`.designerpunk/personal-note.local.md`, local to each machine)
+
+**MCP servers** (from the installed package):
+- Docs MCP: serves DesignerPunk's shipped documentation corpus, read-only
+- Application MCP: serves component and token metadata for this design system
+- Product MCP: serves this product's screens, product tokens and context
+
+**Agent configurations** (8 agents):
+- 3 system agents (Ada/Rosetta, Lina/Stemma, Thurgood/Civitas) that build and maintain this design system
+- 5 product agents (Leonardo, Sparky, Kenya, Data, Stacy) that use the design system to build products
+- Each agent is generated for your agent tool; regenerate rather than hand-edit
+
+**Spec infrastructure**:
+- Your specs (starting from the shipped starter specs) encoding decisions and implementation history
+- Spec workflow: design outline → feedback → requirements → design → tasks → execution
+- Feedback protocol, formalization gates, completion documentation
+---
+
+## @unit #the-three-layer-boundary @ sha256:07a57ddc3770e58fd778f308e53b46af5663158ed9c8332885ab516db02a27fa
+## The Three-Layer Boundary
+
+Governance responsibilities are distributed across three layers:
+
+**Content correctness** — Domain agents own this. Is the technical content accurate? Ada validates token mathematics. Lina validates component architecture. Domain agents have the expertise to judge their content.
+
+**Content consistency** — Civitas steward (Thurgood) owns this. Does content align across surfaces? When the same concept appears in multiple docs, are the descriptions consistent? The steward flags potential inconsistencies; domain agents adjudicate whether the inconsistency is real drift or intentional abstraction.
+
+**Infrastructure health** — Civitas steward (Thurgood) owns this. Valid metadata, current cross-references, recent review dates, MCP health, agent prompt currency, governance tooling adoption. The operational maintenance layer.
+
+**Resolution path for flagged inconsistencies:**
+- Intra-domain (two docs owned by the same agent disagree): Steward flags → domain agent resolves
+- Cross-domain (docs owned by different agents disagree): Steward flags → both agents review → your human lead arbitrates if they disagree
+- Unowned (infrastructure-level): Steward resolves directly
+
+---
+
+## @unit #document-access @ sha256:6bc5c92dbd79c125b497c35a6c88f5257913263b559f610306984985adf0ba9b
+## Document Access
+
+This is a generated identity member (`designerpunk-civitas-system-overview.md`) — never MCP-served, always loaded in full into every agent's context. No query is needed to access it. If you need to point to a specific part of it, use an in-document § reference (e.g., this doc's § "The Three-Layer Boundary" or § "Relationship to Rosetta and Stemma"), not an MCP call.
+## @unit #governance-processes @ sha256:48af3eb551057bd0d40cb4379bdb9f1e0a8953447545978ab8973de5e7651bd4
+## Governance Processes
+
+Civitas governance processes are documented in Thurgood's prompt as operational responsibilities. Key processes:
+
+- **Steering doc lifecycle**: creation (metadata requirements) → review (monthly health check) → update (event-driven triggers) → deprecation (ballot measure with rationale)
+- **MCP health monitoring**: index health, content drift detection, tool availability — monthly cadence + post-spec events
+- **Agent prompt currency**: prompt-to-steering alignment, Agent Directory consistency — post-modification verification
+- **Governance tooling adoption**: ensuring scripts and automation remain active after the spec that created them completes
+
+For detailed process documentation, see your Thurgood agent's charter (its Civitas Steward mode).
+
+---
+

package/dist/consumer-canonical/always-set/core-goals.dispositions.yaml

@@ -0,0 +1,9 @@
+# canonical/profiles/consumer/always-set/core-goals.dispositions.yaml — Spec 123 Task 15.4 (design C19; DD25)
+# An always-set member: body rows only; the shipped doc's own frontmatter is dropped, never carried (C19).
+# Re-pointed units re-ground the member at the consumer's repo (Req 12.1: the always-set re-grounds as a class).
+source: .kiro/steering/core-goals.md
+counterpart: .kiro/steering/core-goals.md
+body:
+  "#core-goals:preamble": {"disposition": "retained"}
+  "#core-project-context": {"disposition": "re-pointed", "removals": [{"text": "DesignerPunk is a True Native cross-platform design system", "cites": "subtraction-2"}, {"text": "**For detailed architectural guidance, see:**\n- True Native Architecture: `preserved-knowledge/true-native-architecture-concepts.md`\n- Token System: `docs/token-system-overview.md`\n- Mathematical Foundation: `preserved-knowledge/token-architecture-2-0-mathematics.md`", "cites": "subtraction-5"}], "destination": "#core-project-context", "signature": {"signer": "stacy", "canonicalHash": "sha256:809e8be5a1088c68b6641c0fc1af3419698ced6ecd18007501a1c8df309e7491", "renderedHash": "sha256:565e95a14c1ad36cd9b5021573286ba03f044f4b0e679747639cb51327195f26", "assent": {"surviving": ["principle-1", "principle-2", "principle-3", "principle-4", "principle-5", "principle-6", "platform-android", "platform-web"]}, "evidence": "canonical/profiles/consumer/signatures/core-goals.md#core-project-context"}}
+  "#development-practices": {"disposition": "re-pointed", "removals": [{"text": "`./.kiro/hooks/complete-task.sh \"Task Name\"` opens the task PR; Peter merges on green", "cites": "subtraction-1"}, {"text": "Repository: https://github.com/3fn/DesignerPunk (PR-gated workflow: branch protection on `main`, admins included)", "cites": "subtraction-2"}, {"text": "`Process-Development-Workflow.md` (Layer 2); `Process-File-Organization.md` (Layer 2)", "cites": "subtraction-4"}], "destination": "#development-practices", "signature": {"signer": "stacy", "canonicalHash": "sha256:06bfac06966cb2bd1b0344f3e6ee26d2db6577e0ca62b05f88fe3e6106fa548f", "renderedHash": "sha256:c700853a4b4478d63395839552ee81cf9435d968f9fe30cf52a90ab3d212f99c", "assent": {"surviving": ["practice-2", "practice-7", "practice-8", "practice-9", "practice-10", "practice-11", "practice-12", "practice-13", "practice-14", "token-governance-query", "practice-15", "practice-16", "practice-17", "practice-18", "practice-19", "practice-20", "practice-21", "practice-22", "practice-26", "practice-27", "construction-rule"]}, "evidence": "canonical/profiles/consumer/signatures/core-goals.md#development-practices"}}

package/dist/consumer-canonical/always-set/core-goals.overlay.md

@@ -0,0 +1,74 @@
+## @unit #core-project-context @ sha256:809e8be5a1088c68b6641c0fc1af3419698ced6ecd18007501a1c8df309e7491
+## Core Project Context
+
+This design system is built on DesignerPunk — a True Native cross-platform design system with mathematical foundations, built for Human-AI collaboration — and carries its principles.
+
+**Key Principles:**
+- Build-time platform separation (web/iOS/Android) rather than runtime detection
+- Mathematical foundation: REM-style baseline grid with modular scale
+- Accessibility-first: WCAG 2.1 AA compliance
+- Cross-platform consistency through unitless token architecture
+- Human-AI partnership as foundational value
+
+**Platform Minimum Versions:**
+- iOS: 17.0+
+- Android: Not yet constrained
+- Web: Not yet constrained
+
+**For detailed architectural guidance, see (docs MCP):**
+- True Native Architecture: `platform-implementation-guidelines`
+- Token System: `rosetta-system-architecture`
+- Mathematical Foundation: `rosetta-system-principles`
+
+## @unit #development-practices @ sha256:06bfac06966cb2bd1b0344f3e6ee26d2db6577e0ca62b05f88fe3e6106fa548f
+## Development Practices
+
+**Task Completion:**
+- Follow your repo's own task-completion workflow — branch, review, and merge as your team does; the human lead's acceptance is the authorization act (see the Task Completion Protocol member)
+
+**For detailed workflow guidance, see:**
+- Spec planning: `process-spec-planning` (docs MCP, conditional)
+
+**Token Usage:**
+- **Always** prioritize design tokens over hard-coded values
+- **MUST** use semantic tokens first — only use primitive tokens when no semantic token exists for the use case
+- All tokens must follow Rosetta System: mathematical relationships, unitless values, primitive→semantic hierarchy
+- Inform user if hard-coded values are necessary
+
+**Token Governance (Autonomy Levels):**
+- **Semantic tokens**: Use freely (verify semantic correctness)
+- **Primitive tokens**: Requires prior context (spec docs) or human acknowledgment
+- **Component tokens**: Requires explicit human approval before use
+- **Creating ANY token**: Always requires human review — no autonomous token creation
+
+**For detailed governance**, query Token Governance via MCP:
+```
+get_section({ path: "token-governance", heading: "Token Selection Matrix" })
+get_section({ path: "token-governance", heading: "Token Usage Governance" })
+```
+
+**Token Selection Priority (MUST follow this order):**
+1. **Semantic tokens** — purpose-built for specific use cases (e.g., `tapAreaRecommended` for touch targets, `color.contrast.onPrimary` for content on primary backgrounds)
+2. **Primitive tokens** — when no semantic token exists, check if a primitive token provides the needed value
+3. **Component tokens referencing primitives** — when a component needs a semantic name but the value exists as a primitive, create a component token that references the primitive (e.g., `buttonIcon.inset.medium = space125`)
+4. **Hard-coded values** — only as last resort, requires user approval
+
+**Component Token Construction Rule:**
+Component tokens must either reference an existing primitive token OR conform to how that primitive token family's values are defined. Never introduce arbitrary values at the component level that don't align with the underlying token family's value system.
+
+**Why semantic first?** Semantic tokens are self-documenting, theme-aware, and encode design intent. Using `tapAreaRecommended` instead of `space600` makes code readable and maintainable.
+
+**Token-First in Specs:**
+- Specs reference tokens, not pixel values: `icon.size100` not `24px`
+- Hard values in source docs (design-outlines) **must** be translated to token references when available
+- Format: `token.name` with value as comment only when needed for clarity
+- Query Token Quick Reference via MCP when uncertain which token to use
+
+**For detailed token guidance, see:**
+- Token governance: `Token-Governance.md` (Layer 2, MCP-accessible) — Selection, usage, and creation governance
+- Component development: `Component-Development-Guide.md` (Layer 3, conditional)
+- Token selection: Component Development Guide's "Token Selection Decision Framework"
+
+**Documentation Approach:**
+- Maintain concept-based documentation preventing contamination vectors
+- Apply process-first tool development: prove manual processes before automation

package/dist/consumer-canonical/always-set/designerpunk-systems-overview.dispositions.yaml

@@ -0,0 +1,16 @@
+# canonical/profiles/consumer/always-set/designerpunk-systems-overview.dispositions.yaml — Spec 123 Task 15.4 (design C19; DD25)
+# An always-set member: body rows only; the shipped doc's own frontmatter is dropped, never carried (C19).
+# Re-pointed units re-ground the member at the consumer's repo (Req 12.1: the always-set re-grounds as a class).
+source: .kiro/steering/DesignerPunk-Systems-Overview.md
+counterpart: .kiro/steering/DesignerPunk-Systems-Overview.md
+body:
+  "#designerpunk-systems-overview:preamble": {"disposition": "retained"}
+  "#overview": {"disposition": "re-pointed", "removals": [{"text": "(./Civitas-System-Overview.md)", "cites": "subtraction-5"}], "destination": "#overview"}
+  "#pointer-1-module-resolution-contract-spec-118": {"disposition": "retained"}
+  "#high-level-designerpunk-three-system-architecture": {"disposition": "retained"}
+  "#rosetta-system-token-pipeline-and-layers": {"disposition": "retained"}
+  "#stemma-system-families-and-inheritance": {"disposition": "retained"}
+  "#civitas-system-governance-infrastructure": {"disposition": "retained"}
+  "#integration-tokens-components-platforms": {"disposition": "retained"}
+  "#combined-overview-single-diagram": {"disposition": "retained"}
+  "#related-documentation": {"disposition": "re-pointed", "removals": [{"text": "(./Civitas-System-Overview.md)", "cites": "subtraction-5"}], "destination": "#related-documentation"}

package/dist/consumer-canonical/always-set/designerpunk-systems-overview.overlay.md

@@ -0,0 +1,44 @@
+## @unit #overview @ sha256:4f50e69ed22fe9e8024e017d05ad08a6cf807613016abb64a5c12af3d8b741d2
+## Overview
+
+DesignerPunk is built on three complementary foundation systems:
+
+- **Rosetta System** — Mathematical foundation for visual consistency (tokens, scales, relationships)
+- **Stemma System** — Relational foundation for behavioral consistency (components, contracts, inheritance)
+- **Civitas System** — Governance foundation for operational consistency (steering docs, MCP servers, agent coordination, processes)
+
+This document provides visual diagrams showing how these systems work individually and how they integrate to create the complete design system.
+
+For detailed Civitas documentation, see [Civitas System Overview](./designerpunk-civitas-system-overview.md).
+
+---
+
+## @unit #related-documentation @ sha256:cdd4df7d51710aa622848052c914bc58765bb44f7ea9cd1309a089dd9bdf4dac
+## Related Documentation
+
+**Civitas System:**
+- [Civitas System Overview](./designerpunk-civitas-system-overview.md) — Governance layer definition, three-layer boundary, processes
+
+**Rosetta System:**
+- [Rosetta System Principles](rosetta-system-principles) — Mathematical foundation and token philosophy
+- [Rosetta System Architecture](rosetta-system-architecture) — Detailed pipeline, generation subsystem, validation
+
+**Stemma System:**
+- [Stemma System Principles](stemma-system-principles) — Component philosophy and inheritance patterns
+- [Contract System Reference](contract-system-reference) — Behavioral contracts, Concept Catalog, classification rules
+- [Component Quick Reference](component-quick-reference) — Routing table for component family docs
+
+**Component Families:**
+- [Component-Family-Button.md](component-family-button)
+- [Component-Family-Form-Inputs.md](component-family-form-inputs)
+- [Component-Family-Icon.md](component-family-icon)
+- [Component-Family-Container.md](component-family-container)
+- [Component-Family-Avatar.md](component-family-avatar)
+- [Component-Family-Badge.md](component-family-badge)
+- [Component-Family-Chip.md](component-family-chip)
+- [Component-Family-Progress.md](progress-indicator-components)
+- [Component-Family-Divider.md](component-family-divider) (placeholder)
+- [Component-Family-Loading.md](component-family-loading) (placeholder)
+- [Component-Family-Modal.md](component-family-modal) (placeholder)
+- [Component-Family-Navigation.md](component-family-navigation)
+- [Component-Family-Data-Display.md](component-family-data-display) (placeholder)

package/dist/consumer-canonical/always-set/spec-feedback-protocol.dispositions.yaml

@@ -0,0 +1,21 @@
+# canonical/profiles/consumer/always-set/spec-feedback-protocol.dispositions.yaml — Spec 123 Task 15.4 (design C19; DD25)
+# An always-set member: body rows only; the shipped doc's own frontmatter is dropped, never carried (C19).
+# Re-pointed units re-ground the member at the consumer's repo (Req 12.1: the always-set re-grounds as a class).
+source: .kiro/steering/Spec-Feedback-Protocol.md
+counterpart: .kiro/steering/Spec-Feedback-Protocol.md
+body:
+  "#spec-feedback-protocol:preamble": {"disposition": "retained"}
+  "#purpose": {"disposition": "retained"}
+  "#the-feedback-document": {"disposition": "re-pointed", "removals": [{"text": ".kiro/specs/[spec-name]/", "cites": "subtraction-4"}], "destination": "#the-feedback-document", "signature": {"signer": "stacy", "canonicalHash": "sha256:d00728b168aff102e37150a194326db06961716079b11fc526ab1304d15f021d", "renderedHash": "sha256:06296fd8eadb805f7c04e1e95017593b9d05fa1151ab791ffd977dab95ba570f", "assent": {"surviving": ["the-feedback-document-1", "single-file-path", "split-path", "the-feedback-document-2", "single-file-valid", "feedback-location", "the-feedback-document-3"]}, "evidence": "canonical/profiles/consumer/signatures/spec-feedback-protocol.md#the-feedback-document"}}
+  "#feedback-checkpoints": {"disposition": "retained"}
+  "#stakeholder-identification": {"disposition": "retained"}
+  "#sequential-formalization-gate": {"disposition": "re-pointed", "removals": [{"text": "Peter", "cites": "subtraction-2"}], "destination": "#sequential-formalization-gate", "signature": {"signer": "stacy", "canonicalHash": "sha256:b7a5853defd008b54f28db5575277efa12f3a247ebed7cf8e587cdec5f3c0b8c", "renderedHash": "sha256:5a4d8113e8b28abb218e0e5db1c93a5d6af4f713d5da227ede4493a8a46a7b6a", "assent": {"surviving": ["sequential-formalization-1", "sequential-formalization-2", "sequential-formalization-3", "sequential-formalization-4", "sequential-formalization-5", "waiver"]}, "evidence": "canonical/profiles/consumer/signatures/spec-feedback-protocol.md#sequential-formalization-gate"}}
+  "#mandatory-mention-scanning": {"disposition": "retained"}
+  "#stamp-format": {"disposition": "retained"}
+  "#standard-feedback": {"disposition": "retained"}
+  "#directed-questions": {"disposition": "retained"}
+  "#incorporation-notes": {"disposition": "retained"}
+  "#context-for-reviewers": {"disposition": "retained"}
+  "#resolution-tracking": {"disposition": "retained"}
+  "#spec-feedback-template": {"disposition": "retained"}
+  "#document-access": {"disposition": "re-pointed", "removals": [{"text": "This is an identity doc (Spec 119) — never MCP-served,", "cites": "subtraction-2"}], "destination": "#document-access", "signature": {"signer": "stacy", "canonicalHash": "sha256:6ffb28191285a1ff3707dd24043c0e7f2a4a6e5c3d988a6c11398fed9bbccf81", "renderedHash": "sha256:994385d110832b792173e7e3be6163c5622648555bcbc4b3b0e07f8770d67994", "assent": {"surviving": ["document-access-1", "document-access-2"]}, "evidence": "canonical/profiles/consumer/signatures/spec-feedback-protocol.md#document-access"}}

package/dist/consumer-canonical/always-set/spec-feedback-protocol.overlay.md

@@ -0,0 +1,44 @@
+## @unit #the-feedback-document @ sha256:d00728b168aff102e37150a194326db06961716079b11fc526ab1304d15f021d
+## The Feedback Document
+
+Every spec MUST have feedback documents created alongside the design outline. Two structures are supported:
+
+**Single file** (for smaller specs):
+```
+specs/[spec-name]/feedback.md
+```
+
+**Split by phase** (for larger specs — reduces token cost per agent review):
+```
+specs/[spec-name]/feedback/
+  design-outline.md
+  requirements.md
+  design.md
+  tasks.md
+```
+
+The split structure is preferred for specs with multiple feedback rounds. Each agent only reads the feedback doc for the current phase, not the entire history. The single-file structure remains valid for specs where feedback is lightweight.
+
+Either way, the feedback document(s) are the location for all agent feedback. See the Spec Feedback Template section below for the required structure within each file.
+
+---
+
+## @unit #sequential-formalization-gate @ sha256:b7a5853defd008b54f28db5575277efa12f3a247ebed7cf8e587cdec5f3c0b8c
+## Sequential Formalization Gate
+
+Spec formalization MUST pause for agent feedback between each document phase:
+
+1. Write **requirements.md** → request feedback → incorporate → proceed
+2. Write **design.md** → request feedback → incorporate → proceed
+3. Write **tasks.md** → request feedback → incorporate → finalize
+
+**Rationale**: Requirements inform design, design informs tasks. Feedback on an earlier document can invalidate assumptions in a later one. Writing all three without pausing creates rework risk.
+
+**Waiver**: Your human lead may waive sequential gates for lightweight specs where cascading risk is low. The waiver must be explicit (e.g., "write all three, we'll review collectively").
+
+---
+
+## @unit #document-access @ sha256:6ffb28191285a1ff3707dd24043c0e7f2a4a6e5c3d988a6c11398fed9bbccf81
+## Document Access
+
+This is a generated identity member (`designerpunk-spec-feedback-protocol.md`) — never MCP-served, always loaded in full into every agent's context. No query is needed to access it. If you need to point to a specific part of it, use an in-document § reference (e.g., this doc's § "Stamp Format" or § "Mandatory @ Mention Scanning"), not an MCP call.

package/dist/consumer-canonical/always-set/start-up-tasks.dispositions.yaml

@@ -0,0 +1,15 @@
+# canonical/profiles/consumer/always-set/start-up-tasks.dispositions.yaml — Spec 123 Task 15.4 (design C19; DD25)
+# An always-set member: body rows only; the shipped doc's own frontmatter is dropped, never carried (C19).
+# Re-pointed units re-ground the member at the consumer's repo (Req 12.1: the always-set re-grounds as a class).
+source: .kiro/steering/start-up-tasks.md
+counterpart: .kiro/steering/start-up-tasks.md
+body:
+  "#start-up-tasks:preamble": {"disposition": "retained"}
+  "#item-check-the-current-date": {"disposition": "retained"}
+  "#item-civitas-governance-health-check": {"disposition": "re-pointed", "removals": [{"text": "**[2026-09-19]**", "cites": "subtraction-3"}, {"text": "the monthly health check", "cites": "subtraction-3"}], "destination": "#item-civitas-governance-health-check", "signature": {"signer": "stacy", "canonicalHash": "sha256:81d0a0079ab252f6cd829b654d963401e76ae66dfc084bb0634844041c06552b", "renderedHash": "sha256:31182e31459fb9f012ab3acadf77fa2d5c7ccb72e909a95e32fd51d3e16d0afe", "assent": {"surviving": ["hc-1", "hc-2", "hc-3", "hc-4"]}, "evidence": "canonical/profiles/consumer/signatures/start-up-tasks.md#item-civitas-governance-health-check"}}
+  "#item-critical-wait-for-user-authorization-before-starting-new-tasks": {"disposition": "retained"}
+  "#item-critical-this-project-uses-jest-not-vitest": {"disposition": "re-pointed", "removals": [{"text": "4. **CRITICAL: This project uses Jest, NOT Vitest**\n   \n   **WHEN running tests THEN you MUST use Jest commands (NOT Vitest commands)**\n   \n   ✅ **CORRECT Jest commands** (durations measured 2026-07-03, warm cache, dev machine — first/cold runs are slower):\n   - `npm test` - Run unit/integration tests (functional lanes only, timing-assertion-free; ~1 min)\n   - `npm run test:all` - Run ALL tests including performance (~1 min — no longer a costlier lane)\n   - `npm run test:performance` - Run the performance-lane suites (seconds)\n   - `npm run test:performance:isolated` - Run the serialized PerformanceValidation suite (seconds). **NOT included in `test:performance`** — full performance validation requires BOTH commands (or `test:all`)\n   - `npm test -- <test-file-path>` - Run specific test file\n   - `npm run test:watch` - Run tests in watch mode\n   - `npm run test:coverage` - Run tests with coverage\n   \n   > **Lane semantics reworked 2026-07-03** (commit `29bba7de`; Spec 125 design-outline addendum): default lanes are timing-assertion-free and deterministic; wall-clock assertions live only in the performance lanes. Historical note: `test:performance`/`test:all` silently selected ZERO performance tests from ~May 2026 (Spec 025 config interaction) until this rework — treat any pre-July-2026 lane-duration claim as void.\n   \n   ❌ **WRONG - These are Vitest commands that will FAIL:**\n   - `npm test -- --run` - Jest doesn't have a `--run` flag\n   - `vitest` - This project doesn't use Vitest\n   \n   **Key difference:** Jest runs tests once by default. Vitest uses `--run` for single execution, but Jest doesn't need or support this flag.", "cites": "subtraction-1"}], "destination": "#item-critical-this-project-uses-jest-not-vitest", "signature": {"signer": "stacy", "canonicalHash": "sha256:f75f87b00a0dafa053d0b2da2229ab451e79ced7621723927163505605e171d0", "renderedHash": "sha256:eb82a3054260399f3879a88d3f6f7385542b4bcb071cb7d6ff419012af92eb81", "assent": {"surviving": ["critical-this-projec-2", "critical-this-projec-10", "critical-this-projec-11"]}, "evidence": "canonical/profiles/consumer/signatures/start-up-tasks.md#item-critical-this-project-uses-jest-not-vitest"}}
+  "#item-test-command-selection-guidelines": {"disposition": "re-pointed", "removals": [{"text": "5. **Test Command Selection Guidelines**\n   \n   **WHEN validating regular task completion THEN:**\n   - Use `npm test` (default - excludes performance tests)\n   - Fast, deterministic feedback loop (~1 minute warm)\n   - Sufficient for most development validation\n   \n   **WHEN validating parent task completion THEN:**\n   - **Default**: Use `npm test` (comprehensive functional validation)\n   - **If task is performance-critical**: Use `npm run test:all` (adds the performance suites; the cost difference is now seconds, so when in doubt, run `test:all`)\n   \n   **WHEN task involves performance changes THEN:**\n   - Run BOTH `npm run test:performance` AND `npm run test:performance:isolated` (perf coverage is split across the two lanes), or simply `npm run test:all`\n   - Performance assertions are wall-clock-sensitive: run them on an otherwise-idle machine, not concurrently with other suites\n   \n   **Decision tree:**\n   ```\n   Is this a parent task completion?\n   ├─ YES → Does task modify performance systems?\n   │   ├─ YES → npm run test:all (includes performance regression tests)\n   │   └─ NO → npm test (comprehensive functional validation)\n   └─ NO → Does task involve performance changes?\n       ├─ YES → npm run test:performance + test:performance:isolated (or test:all)\n       └─ NO → npm test (default)\n   ```\n   \n   **Key distinction:**\n   - `npm test` validates all functionality (functional lanes only; timing-assertion-free)\n   - `npm run test:all` additionally runs the performance suites (seconds of extra cost, but wall-clock-sensitive — avoid under heavy machine load)\n   - Most parent tasks only need functional validation\n   \n   **Default assumption**: Use `npm test` for parent tasks unless working on performance systems.", "cites": "subtraction-1"}], "destination": "#item-test-command-selection-guidelines", "signature": {"signer": "stacy", "canonicalHash": "sha256:b4c82938bb3f353c5f5b20b055bddfd411f747dc8ab748e7bbe89cb86c9e6974", "renderedHash": "sha256:bbaa8516c8db0c0b8e23f439eb09de243e7b998d2552e90f0031c967a73fbcc5", "assent": {"surviving": ["test-command-selecti-5", "test-command-selecti-6", "test-command-selecti-7", "test-command-selecti-8", "test-command-selecti-11", "default-assumption"]}, "evidence": "canonical/profiles/consumer/signatures/start-up-tasks.md#item-test-command-selection-guidelines"}}
+  "#item-delegation-and-model-tier-before-delegating-and-before-deciding-whether-to": {"disposition": "retained"}
+  "#item-ending-a-task-see-task-completion-protocol": {"disposition": "retained"}
+  "#item-starting-a-parent-task-write-its-instruments-block-first": {"disposition": "re-pointed", "removals": [{"text": "8. **Starting a PARENT task: write its Instruments block first**\n\n   Before a parent's first subtask starts, the PRIMARY writes `.kiro/specs/<spec>/completion/task-<N>-instruments.md` — one row per instrument each success criterion's evidence depends on (test, check, fixture, file, command, upstream artifact), each `exists (<path> @ <sha>)` with a one-line fit clause, `built here (<subtask>)`, or `MISSING → <owner>: <record>`; a criterion needing no instrument gets a `none — <why>` row — and commits it on the unit branch. **Any MISSING stops the subtasks that depend on it, before code**; report it for routing (a consult, then an amendment if the plan changes). A `MISSING` row is never overwritten: its resolution is appended in the row. A gap found later is appended under `## Found later` with its kind (`unlisted` or `misfit`), never silently fixed. Format and the completion-doc header line: Completion Documentation Guide § \"The instruments line and block\". *(Ballot 2026-09-28-parent-instrument-existence-check.)*\n\n   **From the first tasks round after `P`** (the instruments parser PR's squash SHA — ballot § 4a, M4), a spec also declares its instruments in `tasks.md` at planning time; for such a spec this file is written at branch cut as M4's execution file — the pasted command-output existence delta, one fit line per row keyed by row id, rows found at the cut, `## Found later` — never restating a plan row's state or path.", "cites": "subtraction-4"}], "destination": "#item-starting-a-parent-task-write-its-instruments-block-first", "signature": {"signer": "stacy", "canonicalHash": "sha256:450bc8ccda0592e81e09ec9b06ec82b08cf7c6a8512572d7a7674f27df86a2d2", "renderedHash": "sha256:efcc0cd64ec429ae5f89d12787a4689cb76a6f923ff2867550321faf34d2f717", "assent": {"surviving": ["write-block", "missing-stops", "starting-a-parent-ta-3"]}, "evidence": "canonical/profiles/consumer/signatures/start-up-tasks.md#item-starting-a-parent-task-write-its-instruments-block-first"}}

package/dist/consumer-canonical/always-set/start-up-tasks.overlay.md

@@ -0,0 +1,25 @@
+## @unit #item-civitas-governance-health-check @ sha256:81d0a0079ab252f6cd829b654d963401e76ae66dfc084bb0634844041c06552b
+2. **Civitas Governance Health Check**
+   
+   IF it's been longer than your team's cadence since the last governance health check (keep its date recorded here), THEN flag: "Governance health check overdue — Thurgood (Civitas steward) should run the health check before proceeding."
+   
+   *Only Thurgood runs the health check. All agents check the date and flag if overdue.*
+
+## @unit #item-critical-this-project-uses-jest-not-vitest @ sha256:f75f87b00a0dafa053d0b2da2229ab451e79ced7621723927163505605e171d0
+4. **CRITICAL: Use your repo's own test runner**
+   
+   **WHEN running tests THEN you MUST use the commands your repo defines** — read them from its `package.json` (or its build tool's config) before you run anything, and never guess a runner's flags.
+
+## @unit #item-test-command-selection-guidelines @ sha256:b4c82938bb3f353c5f5b20b055bddfd411f747dc8ab748e7bbe89cb86c9e6974
+5. **Test Command Selection Guidelines**
+   
+   **WHEN validating a subtask THEN** run the tests relevant to the change (not the full suite).
+   
+   **WHEN validating a parent task THEN** run your repo's full functional suite.
+   
+   **WHEN the task involves performance changes THEN** also run your performance suites, on an otherwise-idle machine (they are wall-clock-sensitive).
+
+## @unit #item-starting-a-parent-task-write-its-instruments-block-first @ sha256:450bc8ccda0592e81e09ec9b06ec82b08cf7c6a8512572d7a7674f27df86a2d2
+8. **Starting a PARENT task: list its instruments first**
+
+   Before a parent's first subtask starts, list every instrument each success criterion's evidence depends on (test, check, fixture, file, command, upstream artifact) — each one that exists (with where, and what in it the criterion reads), is built by one of this parent's subtasks, or is MISSING (with who owns it). **Any MISSING stops the subtasks that depend on it, before code**; route it. A gap found later is recorded with its kind (never listed, or listed but not fit for the criterion), never silently fixed.

package/dist/consumer-canonical/always-set/task-completion-protocol.dispositions.yaml

@@ -0,0 +1,19 @@
+# canonical/profiles/consumer/always-set/task-completion-protocol.dispositions.yaml — Spec 123 Task 15.4 (design C19; DD25)
+# An always-set member: body rows only; the shipped doc's own frontmatter is dropped, never carried (C19).
+# Re-pointed units re-ground the member at the consumer's repo (Req 12.1: the always-set re-grounds as a class).
+source: .kiro/steering/Task-Completion-Protocol.md
+counterpart: .kiro/steering/Task-Completion-Protocol.md
+body:
+  "#task-completion-protocol:preamble": {"disposition": "retained"}
+  "#critical-do-not-mark-a-task-complete-before-its-required-steps": {"disposition": "re-pointed", "removals": [{"text": "the Completion Documentation Guide MCP query", "cites": "subtraction-4"}], "destination": "#critical-do-not-mark-a-task-complete-before-its-required-steps", "signature": {"signer": "stacy", "canonicalHash": "sha256:ebe9ae3c776f236e195e92ffc5c5fd5f80cd00fd41083417e4fa6c49cc46500d", "renderedHash": "sha256:a741101445e7d18b6e85c7963366b0dd787fcd2591f56a8ec7e8316b09f909b9", "assent": {"surviving": ["critical-do-not-mark-1"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#critical-do-not-mark-a-task-complete-before-its-required-steps"}}
+  "#for-subtasks": {"disposition": "re-pointed", "removals": [{"text": "`complete-task.sh --subtask`, the S-4 ruling and the unit-branch CI dispatch", "cites": "subtraction-1"}], "destination": "#for-subtasks", "signature": {"signer": "stacy", "canonicalHash": "sha256:d3441b73b9ced68042b67726692b8f87d3ce9e086d7e68336292da8b69895d75", "renderedHash": "sha256:00a53d7ed2926558ddcb2c3eaebc535b02eab5506713926280fd734dce676716", "assent": {"surviving": ["for-subtasks-1", "for-subtasks-2", "for-subtasks-3", "for-subtasks-5"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#for-subtasks"}}
+  "#for-parent-tasks-implementation-or-architecture-type": {"disposition": "re-pointed", "removals": [{"text": "`./.kiro/hooks/complete-task.sh \"...\"`, the `taskStatus` tool and the Completion Documentation Guide pointers", "cites": "subtraction-1"}, {"text": "Peter merges the UNIT's PR", "cites": "subtraction-2"}], "destination": "#for-parent-tasks-implementation-or-architecture-type", "signature": {"signer": "stacy", "canonicalHash": "sha256:e2958dd6f1a60a5f2b1054e109efe5e8ebd176f263302b87d096772c9243a1c5", "renderedHash": "sha256:d62ae8286a803b0a75b1925351534ce2a10bb9c17ef4b92199fca40dfe0dc194", "assent": {"surviving": ["for-parent-tasks-imp-1", "for-parent-tasks-imp-2", "for-parent-tasks-imp-4", "for-parent-tasks-imp-5", "for-parent-tasks-imp-6", "for-parent-tasks-imp-8"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#for-parent-tasks-implementation-or-architecture-type"}}
+  "#for-parent-tasks-setup-or-documentation-type": {"disposition": "re-pointed", "removals": [{"text": "`./.kiro/hooks/complete-task.sh \"...\"`, the `taskStatus` tool and the Completion Documentation Guide pointers", "cites": "subtraction-1"}, {"text": "Peter merges the UNIT's PR", "cites": "subtraction-2"}], "destination": "#for-parent-tasks-setup-or-documentation-type", "signature": {"signer": "stacy", "canonicalHash": "sha256:d74afc384873f1861a195770544dcb456c4e952028d9ca37e3e5d6e39b19a6e4", "renderedHash": "sha256:9c275da8b7c69d21d220b1e0931c29826be35f43c3deaf7ee43b5ee15fc6b7df", "assent": {"surviving": ["for-parent-tasks-set-1", "for-parent-tasks-set-2", "for-parent-tasks-set-4", "for-parent-tasks-set-5", "for-parent-tasks-set-6", "for-parent-tasks-set-8"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#for-parent-tasks-setup-or-documentation-type"}}
+  "#completion-state-in-the-pr-flow:preamble": {"disposition": "re-pointed", "removals": [{"text": "the 125-A workflow-law ballot, the hook ergonomics and the B-CI annotations", "cites": "subtraction-2"}, {"text": "Peter merges on green; branch protection, admins included", "cites": "subtraction-2"}], "destination": "#completion-state-in-the-pr-flow:preamble", "signature": {"signer": "stacy", "canonicalHash": "sha256:b59a35369cc72af0278db7c994f6fcdd75e5dc9202494bcc80a59ec96bb9c955", "renderedHash": "sha256:eb5a8ca0e6712c02392b8f44121f051307a602225fde087379d51c4df53b9dc2", "assent": {"surviving": ["completion-state-in--1", "merge-unit-definition", "completion-state-in--2", "one-branch-per-unit", "completion-state-in--7", "completion-state-in--9", "complete-at-merge", "completion-state-in--12", "completion-state-in--13", "completion-state-in--15", "completion-state-in--16", "completion-state-in--17", "completion-state-in--18", "completion-state-in--19", "completion-state-in--20"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#completion-state-in-the-pr-flow:preamble"}}
+  "#coherent-units-the-merge-granularity": {"disposition": "re-pointed", "removals": [{"text": "the tasks-row write-scope grant (ballot 2026-09-26)", "cites": "subtraction-2"}], "destination": "#coherent-units-the-merge-granularity", "signature": {"signer": "stacy", "canonicalHash": "sha256:4bd3b64a6e82bcdcc9065d9eb7c42162e1da6c6fbd00988fa2d3f74137684632", "renderedHash": "sha256:0a669e677ce606e61ffe812a9de2b238170a23e3e1f457283ecab9bbf7f5806a", "assent": {"surviving": ["coherent-units-the-m-1", "coherent-units-the-m-2", "coherent-units-the-m-3"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#coherent-units-the-merge-granularity"}}
+  "#branch-cleanup": {"disposition": "re-pointed", "removals": [{"text": "a repo Settings toggle Peter enables; the monthly Civitas health check (Thurgood's cadence)", "cites": "subtraction-2"}], "destination": "#branch-cleanup", "signature": {"signer": "stacy", "canonicalHash": "sha256:f6e97dd4c99e8e9e2143a984ccf2fb4b85e62a04da4965d0a6f01fc341c4ff8e", "renderedHash": "sha256:481a55a8854363458c943908f2ec748d2bc4a585ae4e63902dac162982faf512", "assent": {"surviving": ["branch-cleanup-1", "branch-cleanup-2", "branch-cleanup-3"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#branch-cleanup"}}
+  "#branch-and-pr-conventions": {"disposition": "re-pointed", "removals": [{"text": "the `125-A` / `052` examples and `Peter` as the human-direct agent", "cites": "subtraction-2"}], "destination": "#branch-and-pr-conventions", "signature": {"signer": "stacy", "canonicalHash": "sha256:920fbf9e608725a083053d158bcb195209a2993b1e00037764621cbf1a71b2cf", "renderedHash": "sha256:8f675184378d4b3c945ec8ec6331abc41e090d755ce601a531645f0960bcf768", "assent": {"surviving": ["branch-and-pr-conven-1", "branch-and-pr-conven-2", "branch-and-pr-conven-3", "branch-and-pr-conven-4", "branch-and-pr-conven-5"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#branch-and-pr-conventions"}}
+  "#the-merge-rule": {"disposition": "re-pointed", "removals": [{"text": "Peter merges on green during bake-in (Spec 125-A Task 5's gate); the 125-B CODEOWNERS carve-out", "cites": "subtraction-2"}], "destination": "#the-merge-rule", "signature": {"signer": "stacy", "canonicalHash": "sha256:d9fdd24e86b6c31126977969bbe4d47e0df9b05bc4c3a2bf6274d8cfd801e34e", "renderedHash": "sha256:0bbd3bb417578928e95d3545171190c3de40019bbc5868c6d5a69affeff4d3be", "assent": {"surviving": ["the-merge-rule-1", "the-merge-rule-2", "the-merge-rule-3"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#the-merge-rule"}}
+  "#emergency-procedure": {"disposition": "re-pointed", "removals": [{"text": "Peter lifts branch protection in Settings; 125-A's findings ledger; the in-repo rollback note", "cites": "subtraction-2"}], "destination": "#emergency-procedure", "signature": {"signer": "stacy", "canonicalHash": "sha256:fcb97d3f697a6b4cc3bd45b2478e22e305abdf1626258e220b5ac507f4bcbb4d", "renderedHash": "sha256:854dfb5676192c73eb4bc1b5959fb516bb5c789d2691abd1b4e93c1fd9804bb0", "assent": {"surviving": ["emergency-procedure-1"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#emergency-procedure"}}
+  "#tier-selection-which-docs-how-much-detail": {"disposition": "re-pointed", "removals": [{"text": "`.kiro/specs/[spec]/completion/`, `docs/specs/[spec]/` and the Completion Documentation Guide pointer", "cites": "subtraction-4"}], "destination": "#tier-selection-which-docs-how-much-detail", "signature": {"signer": "stacy", "canonicalHash": "sha256:d1d5429b6114ae0abd5e62cfd4a88039d25755d3c8ea249057c2dd971fa03c60", "renderedHash": "sha256:e32f2399887792d0b541b294b004a80c2fa6948deaa1924d3780cb926bcb5051", "assent": {"surviving": ["tier-selection-which-1", "tier-selection-which-2"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#tier-selection-which-docs-how-much-detail"}}
+  "#key-rules": {"disposition": "re-pointed", "removals": [{"text": "Peter merges on green; branch protection; the record-first ballot protocol; the delegated-tier capture rule", "cites": "subtraction-2"}], "destination": "#key-rules", "signature": {"signer": "stacy", "canonicalHash": "sha256:80c2462bf7a9e6c1e7a3bd7edc6e36abb523168f644fe3c777eec59993d53977", "renderedHash": "sha256:f25591f51f38a1b45a76f52dee732682d663e787ff5c42fce9feaddeab3ebba9", "assent": {"surviving": ["key-rules-1", "key-rules-2", "key-rules-3", "key-rules-8"]}, "evidence": "canonical/profiles/consumer/signatures/task-completion-protocol.md#key-rules"}}

package/dist/consumer-canonical/always-set/task-completion-protocol.overlay.md

@@ -0,0 +1,116 @@
+## @unit #critical-do-not-mark-a-task-complete-before-its-required-steps @ sha256:ebe9ae3c776f236e195e92ffc5c5fd5f80cd00fd41083417e4fa6c49cc46500d
+## CRITICAL: Do Not Mark a Task Complete Before Its Required Steps
+
+**DO NOT mark a task complete before completing the required steps for that task type.** Task types are defined in `tasks.md` — check the `**Type**:` field (Setup / Implementation / Architecture / Documentation).
+
+---
+
+## @unit #for-subtasks @ sha256:d3441b73b9ced68042b67726692b8f87d3ce9e086d7e68336292da8b69895d75
+### For SUBTASKS
+1. [ ] Run targeted tests relevant to the change (not the full suite)
+2. [ ] Create a completion doc: `specs/[spec]/completion/task-N-M-completion.md` — three light elements: what changed · targeted tests + result · application-time adaptations (`none` written, never implied). A ticked subtask without its doc is a finding.
+3. [ ] Mark the subtask complete in `tasks.md`
+4. [ ] **Commit and push the unit branch at judgment-based checkpoints** — delicate or potentially-breaking work, backup-worthy accumulation, or a session/handoff boundary — not mechanically per subtask. No PR opens until the unit completes; subtasks never open PRs.
+5. [ ] **STOP** and wait for user authorization
+
+## @unit #for-parent-tasks-implementation-or-architecture-type @ sha256:e2958dd6f1a60a5f2b1054e109efe5e8ebd176f263302b87d096772c9243a1c5
+### For PARENT TASKS (Implementation or Architecture type)
+1. [ ] Local validation: run your repo's full functional suite before completion — the unit's required checks run it again at the merge
+2. [ ] Mark the parent task complete in `tasks.md` — the status change travels with the work and takes effect at merge
+3. [ ] Create the completion doc: `specs/[spec]/completion/task-N-completion.md` (on the task branch) — reproduce every success-criterion row verbatim with its Status and Evidence
+4. [ ] Create the concise summary doc: `specs/[spec]/task-N-summary.md` (on the task branch)
+5. [ ] Complete the parent on its unit branch: if this parent IS its own merge unit, open the PR; if it is one of several in a declared multi-parent unit, commit its docs on the branch — the PR opens when the unit completes. Completion docs declare where their test results were measured (locally, or which CI run).
+6. [ ] **STOP** — report the PR URL or the on-branch completion. **The task is accepted when your human lead merges the unit's PR.** Never merge your own PR.
+
+## @unit #for-parent-tasks-setup-or-documentation-type @ sha256:d74afc384873f1861a195770544dcb456c4e952028d9ca37e3e5d6e39b19a6e4
+### For PARENT TASKS (Setup or Documentation type)
+1. [ ] Verify the artifacts are created or updated as specified
+2. [ ] Mark the parent task complete in `tasks.md`
+3. [ ] Create the completion doc: `specs/[spec]/completion/task-N-completion.md` (on the task branch) — reproduce every success-criterion row verbatim with its Status and Evidence
+4. [ ] Create the concise summary doc: `specs/[spec]/task-N-summary.md` (on the task branch)
+5. [ ] Complete the parent on its unit branch: open the PR if this parent is its own merge unit; otherwise commit its docs on the branch. Completion docs declare where their test results were measured (locally, or which CI run).
+6. [ ] **STOP** — report the PR URL or the on-branch completion. **The task is accepted when your human lead merges the unit's PR.** Never merge your own PR.
+
+## @unit #completion-state-in-the-pr-flow:preamble @ sha256:b59a35369cc72af0278db7c994f6fcdd75e5dc9202494bcc80a59ec96bb9c955
+## Completion State in the PR Flow
+
+Branch → PR → required checks → merge.
+
+**The merge unit is the coherent unit.** A PR carries a **coherent unit** — the smallest chunk of a spec's work that is coherent on its own AND reviewable as a single diff. For a small spec the unit is the whole spec (one PR). For a large spec the units are **declared in that spec's own tasks.md** — named up front, never judged at merge time. One branch per unit; the unit's completion opens the PR; your human lead merges the unit.
+
+1. Work happens on a **task branch**, never on `main`.
+2. Subtask commits are optional and judgment-based; when made, commit AND push the branch (the push is the off-machine backup). No PR opens until unit completion.
+3. **Dependent units branch from `main` after the prior unit's PR merges.** Stacking only on your human lead's explicit direction: branch from the prior unit's branch, declare `Stacked-on: #<PR>` in the PR body, and merge stacked PRs in base-first order.
+4. At unit completion, commit, push, **open a PR**, and report the PR URL.
+5. Required checks run on the PR; a failing check blocks the merge.
+6. **Your human lead merges on green.**
+
+**A task is complete at MERGE, not at PR-open.** The PR is the submission; the merge is the acceptance.
+
+1. Finish the work and run tier-appropriate validation locally.
+2. Write the completion documentation (and the summary doc, for parents) **on the task branch** — it traverses the gate with the work it documents.
+3. Mark the task complete **on the branch**; until the unit merges, that status is an assertion awaiting acceptance.
+4. Open the PR, **report the PR URL, and STOP.** Opening a PR is submission for authorization, not completion.
+5. **The merge is the authorization act.** It accepts the whole unit — every task in it and its completion claims.
+6. **Stop-and-wait composes unchanged**: authorization to START the next task remains a separate, explicit grant (Start Up Tasks #3).
+7. **A change request is authorization to resume, not a completion**: fix, push, re-report the PR URL, and STOP again.
+8. If required checks fail, the task is not complete: fix on the same branch. If the PR is green but unmergeable (the branch conflicts with an advanced `main`), update the branch from `main` on the same branch. Every push re-runs the checks.
+9. **A checks-only merge is NOT ratification** of a governance change: governance changes ratify through your team's own decision record.
+
+## @unit #coherent-units-the-merge-granularity @ sha256:4bd3b64a6e82bcdcc9065d9eb7c42162e1da6c6fbd00988fa2d3f74137684632
+### Coherent Units (the merge granularity)
+
+- **What a unit is**: the smallest chunk of a spec that is coherent on its own AND reviewable as a single diff. The merge of a unit's PR is the completion event for every task the unit contains.
+- **Small spec → one unit → one PR** (the default and common case).
+- **Large spec → units DECLARED in tasks.md**, named up front and reviewed in the tasks round — never judged at merge time.
+- **One branch per unit**; the unit's completion opens the PR; your human lead merges.
+- **Dependent units branch from `main` after the prior unit's PR merges** — the unit is the dependency grain.
+- **On merge, the unit's branch is deleted.**
+
+## @unit #branch-cleanup @ sha256:f6e97dd4c99e8e9e2143a984ccf2fb4b85e62a04da4965d0a6f01fc341c4ff8e
+### Branch Cleanup
+
+- **On merge — the remote branch is deleted** (a repository setting your human lead enables, or by hand).
+- **On merge — the local branch is deleted** on returning to `main` (`git branch -d <branch>`).
+- **Stale or unmerged branches** (abandoned or superseded units) are pruned in your team's periodic health check, so one long-lived branch never quietly accumulates unrelated work.
+
+## @unit #branch-and-pr-conventions @ sha256:920fbf9e608725a083053d158bcb195209a2993b1e00037764621cbf1a71b2cf
+### Branch and PR Conventions
+
+- **The `<spec>` token**: the spec ID — the leading identifier of the spec directory name.
+- **Branch names**: `task/<spec>-<task-number>-<short-slug>` for spec tasks; `fix/<slug>` or `chore/<slug>` for non-spec work.
+- **PR title** = the commit-message standard, spec-suffixed: `Task <N> Complete: <Description> (<spec>)`. If PRs squash-merge, the title becomes the commit subject.
+- **PR body** carries `Spec:`, `Task:`, `Agent:` (the authoring agent, or your human lead for human-direct work), the path(s) to the completion doc(s) on the branch, and a one-line validation note.
+- **Unit-grain naming (multi-parent units)**: branch `task/<spec>-<unit-slug>`; PR title `<Unit description> (<spec>)`; the PR body adds a `Unit:` field.
+
+## @unit #the-merge-rule @ sha256:d9fdd24e86b6c31126977969bbe4d47e0df9b05bc4c3a2bf6274d8cfd801e34e
+### The Merge Rule
+
+- **Agents open PRs; your human lead merges on green.** Agents NEVER merge their own PRs.
+- Any delegation of merge-on-green must be a recorded rule (a committed record with its date and scope) — never a verbal grant. Authority is a record.
+- PRs touching your team's governance docs or agent charters stay human-merged — a standing carve-out that survives any delegation of merge-on-green.
+
+## @unit #emergency-procedure @ sha256:fcb97d3f697a6b4cc3bd45b2478e22e305abdf1626258e220b5ac507f4bcbb4d
+### Emergency Procedure
+
+When the gate must be bypassed (a broken gate, an urgent fix the checks themselves block): your human lead lifts the protection, performs the change, restores the protection immediately, and records the use — date, reason, what was pushed, how long protection was off, and the follow-up PR if the change needs regularizing. No agent requests the lift as a convenience path.
+
+## @unit #tier-selection-which-docs-how-much-detail @ sha256:d1d5429b6114ae0abd5e62cfd4a88039d25755d3c8ea249057c2dd971fa03c60
+## Tier Selection (which docs, how much detail)
+
+- **Subtasks**: a single completion doc (`task-N-M-completion.md`). No summary doc.
+- **Parent tasks**: BOTH a detailed completion doc (`specs/[spec]/completion/`) AND a concise summary doc (`specs/[spec]/task-N-summary.md`).
+
+---
+
+## @unit #key-rules @ sha256:80c2462bf7a9e6c1e7a3bd7edc6e36abb523168f644fe3c777eec59993d53977
+## Key Rules
+
+- **Implementation / Architecture tasks**: the unit's required checks enforce a green suite at merge — local validation before completion catches failures early.
+- **All parent tasks**: create BOTH the completion doc AND the summary doc, on the task branch.
+- **All tasks**: STOP after completion — never auto-proceed to the next task. Authorization to START the next task is governed by Start Up Tasks; the merge that completes this task is not that authorization.
+- **Parent vs. subtask** is the load-bearing distinction: subtasks get targeted tests + a completion doc + an **optional, judgment-based** branch commit-and-push; parents get full validation + completion doc + summary doc, committed on the branch.
+- **The merge unit is the coherent unit**, DECLARED in the spec's tasks.md. The unit's completion opens the PR; a parent inside a multi-parent unit is done-on-branch, accepted at the unit's merge.
+- **A task is accepted at the MERGE of its unit.** Agents open PRs at unit completion; your human lead merges on green. Never merge your own PR.
+- **On merge, the unit's branch is cleaned up.**
+- **A checks-only merge is NOT ratification**: governance changes ratify through your team's own decision record.

package/dist/consumer-canonical/consumer-profile.yaml

@@ -0,0 +1,9 @@
+# canonical/consumer-profile.yaml — the consumer generation profile's declared targets (Spec 123
+# design C12, Task 15.0).
+#
+# THE SINGLE DECLARED TARGET LIST: everything that needs the set of targets imports it through
+# tools/agent-generator/consumer-profile.ts (`loadConsumerProfile`) — the generator (generate.ts,
+# via the adapter registry in adapters/index.ts) and Task 14's per-target guard. No second list.
+# `defaultTarget` is the target bare `init` emits (design DD9).
+targets: [cc, kiro]
+defaultTarget: cc