eai-cli 0.0.0-bootstrap.0

package/resources/gofer/templates/tasks-template.md

@@ -0,0 +1,323 @@
+---
+description: 'Task list template for feature implementation'
+---
+
+# Tasks: [FEATURE NAME]
+
+**Input**: Design documents from `.specify/specs/[###-feature-name]/`
+
+**Prerequisites**: plan.md (required), spec.md (required for user stories),
+research.md, goal-ledger.json, data-model.md, contracts/
+
+**Note**: This template is filled in by `/4_gofer_tasks` (or legacy
+`/4_gofer_tasks`). Recommended: Use `/0_gofer_start` to auto-chain the entire
+pipeline.
+
+> **EAI CLI Version Pin** (enterpriseai profile only): deployment tasks in this
+> list inherit the `major.minor` pin recorded in `plan.md` so builds in CI and
+> on developer machines use the same `eai` toolchain. Standard-profile runs
+> ignore this section.
+
+**Tests**: The examples below include test tasks. Tests are OPTIONAL - only
+include them if explicitly requested in the feature specification.
+
+**Organization**: Tasks are grouped by user story to enable independent
+implementation and testing of each story.
+
+## App-Delivery Preconditions
+
+When the feature is classified as application delivery, tasks must preserve the
+shared numbered stages **and** enforce these prerequisites before downstream
+implementation:
+
+- `goal-ledger.json` exists and records goals, metrics, delivery states, and
+  re-loop triggers
+- `ui-approval.md` exists and is approved
+- `service-fit-matrix.md` exists and distinguishes accessible now, purchasable,
+  and unavailable platform capabilities
+- normal build tasks use the EAI app template, EAI platform services, and
+  Azure-compatible support services before any custom or third-party app
+  substrate
+- preview work stays inside approved EAI App Template blocks unless an exception
+  task is recorded
+- package lane, coupling status, Storybook story IDs, theme override points,
+  custom-block exceptions, and external/internal/hybrid profile choice are
+  recorded before UI implementation tasks begin
+
+External and hybrid profiles must include first-class public-readiness,
+block-porting, and source-platform decoupling tasks before user-story
+implementation.
+
+For explicit non-app work, mark this section "Not applicable" and continue with
+the shared stages without app-only gates.
+
+## Format: `[ID] [P?] [Story] Description`
+
+- **[P]**: Can run in parallel (different files, no dependencies)
+- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
+- Include exact file paths in descriptions
+
+## Path Conventions
+
+- **Single project**: `src/`, `tests/` at repository root
+- **Web app**: `backend/src/`, `frontend/src/`
+- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
+- Paths shown below assume single project - adjust based on plan.md structure
+
+<!--
+  ============================================================================
+  IMPORTANT: The tasks below are SAMPLE TASKS for illustration purposes only.
+
+  The /4_gofer_tasks command (or legacy /4_gofer_tasks) MUST replace these
+  with actual tasks based on:
+  - User stories from spec.md (with their priorities P1, P2, P3...)
+  - Feature requirements from plan.md
+  - Entities from data-model.md
+  - Endpoints from contracts/
+
+  Tasks MUST be organized by user story so each story can be:
+  - Implemented independently
+  - Tested independently
+  - Delivered as an MVP increment
+
+  DO NOT keep these sample tasks in the generated tasks.md file.
+  ============================================================================
+-->
+
+## Phase 1: Setup (Shared Infrastructure)
+
+**Purpose**: Project initialization and basic structure
+
+- [ ] T001 Create project structure per implementation plan
+- [ ] T002 Initialize [language] project with [framework] dependencies
+- [ ] T003 [P] Configure linting and formatting tools
+
+---
+
+## Phase 2: Foundational (Blocking Prerequisites)
+
+**Purpose**: Core infrastructure that MUST be complete before ANY user story can
+be implemented
+
+**⚠️ CRITICAL**: No user story work can begin until this phase is complete
+
+Examples of foundational tasks (adjust based on your project):
+
+- [ ] T004 Setup database schema and migrations framework
+- [ ] T005 [P] Implement authentication/authorization framework
+- [ ] T006 [P] Setup API routing and middleware structure
+- [ ] T007 Create base models/entities that all stories depend on
+- [ ] T008 Configure error handling and logging infrastructure
+- [ ] T009 Setup environment configuration management
+- [ ] T010 Lock external/internal/hybrid package profile and package lane from
+      `ui-preview-brief.md`
+- [ ] T011 Run `eai --describe`, `eai blocks list`, `eai blocks describe <id>`,
+      and `eai resources schema`; record block IDs, resource bindings, coupling
+      status, Storybook story IDs, theme override points, and custom-block
+      exceptions
+- [ ] T012 Update `goal-ledger.json` with planned requirement, task, code, and
+      test links plus any new delivery-state promotion criteria
+- [ ] T013 Add block-porting, source-platform decoupling, and public-readiness
+      work for external or hybrid package lanes
+
+**Checkpoint**: Foundation ready - user story implementation can now begin in
+parallel
+
+---
+
+## Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️
+
+> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
+
+- [ ] T010 [P] [US1] Contract test for [endpoint] in
+      tests/contract/test\_[name].py
+- [ ] T011 [P] [US1] Integration test for [user journey] in
+      tests/integration/test\_[name].py
+
+### Implementation for User Story 1
+
+- [ ] T012 [P] [US1] Create [Entity1] model in src/models/[entity1].py
+- [ ] T013 [P] [US1] Create [Entity2] model in src/models/[entity2].py
+- [ ] T014 [US1] Implement [Service] in src/services/[service].py (depends on
+      T012, T013)
+- [ ] T015 [US1] Implement [endpoint/feature] in src/[location]/[file].py
+- [ ] T016 [US1] Add validation and error handling
+- [ ] T017 [US1] Add logging for user story 1 operations
+
+**Checkpoint**: At this point, User Story 1 should be fully functional and
+testable independently
+
+---
+
+## Phase 4: User Story 2 - [Title] (Priority: P2)
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
+
+- [ ] T018 [P] [US2] Contract test for [endpoint] in
+      tests/contract/test\_[name].py
+- [ ] T019 [P] [US2] Integration test for [user journey] in
+      tests/integration/test\_[name].py
+
+### Implementation for User Story 2
+
+- [ ] T020 [P] [US2] Create [Entity] model in src/models/[entity].py
+- [ ] T021 [US2] Implement [Service] in src/services/[service].py
+- [ ] T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
+- [ ] T023 [US2] Integrate with User Story 1 components (if needed)
+
+**Checkpoint**: At this point, User Stories 1 AND 2 should both work
+independently
+
+---
+
+## Phase 5: User Story 3 - [Title] (Priority: P3)
+
+**Goal**: [Brief description of what this story delivers]
+
+**Independent Test**: [How to verify this story works on its own]
+
+### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
+
+- [ ] T024 [P] [US3] Contract test for [endpoint] in
+      tests/contract/test\_[name].py
+- [ ] T025 [P] [US3] Integration test for [user journey] in
+      tests/integration/test\_[name].py
+
+### Implementation for User Story 3
+
+- [ ] T026 [P] [US3] Create [Entity] model in src/models/[entity].py
+- [ ] T027 [US3] Implement [Service] in src/services/[service].py
+- [ ] T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py
+
+**Checkpoint**: All user stories should now be independently functional
+
+---
+
+[Add more user story phases as needed, following the same pattern]
+
+---
+
+## Phase N: Polish & Cross-Cutting Concerns
+
+**Purpose**: Improvements that affect multiple user stories
+
+- [ ] TXXX [P] Documentation updates in docs/
+- [ ] TXXX Code cleanup and refactoring
+- [ ] TXXX Performance optimization across all stories
+- [ ] TXXX [P] Additional unit tests (if requested) in tests/unit/
+- [ ] TXXX Security hardening
+- [ ] TXXX Run quickstart.md validation
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Setup (Phase 1)**: No dependencies - can start immediately
+- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user
+  stories
+- **User Stories (Phase 3+)**: All depend on Foundational phase completion
+  - User stories can then proceed in parallel (if staffed)
+  - Or sequentially in priority order (P1 → P2 → P3)
+- **Polish (Final Phase)**: Depends on all desired user stories being complete
+
+### User Story Dependencies
+
+- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No
+  dependencies on other stories
+- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - May integrate
+  with US1 but should be independently testable
+- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate
+  with US1/US2 but should be independently testable
+
+### Within Each User Story
+
+- Reference the supporting goal IDs, requirement IDs, and planned code/test
+  files in `traceability.md`
+- Keep `goal-ledger.json` current whenever a task changes the target metric,
+  owner, delivery state, or re-loop trigger
+
+- Tests (if included) MUST be written and FAIL before implementation
+- Models before services
+- Services before endpoints
+- Core implementation before integration
+- Story complete before moving to next priority
+
+### Parallel Opportunities
+
+- All Setup tasks marked [P] can run in parallel
+- All Foundational tasks marked [P] can run in parallel (within Phase 2)
+- Once Foundational phase completes, all user stories can start in parallel (if
+  team capacity allows)
+- All tests for a user story marked [P] can run in parallel
+- Models within a story marked [P] can run in parallel
+- Different user stories can be worked on in parallel by different team members
+
+---
+
+## Parallel Example: User Story 1
+
+```bash
+# Launch all tests for User Story 1 together (if tests requested):
+Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
+Task: "Integration test for [user journey] in tests/integration/test_[name].py"
+
+# Launch all models for User Story 1 together:
+Task: "Create [Entity1] model in src/models/[entity1].py"
+Task: "Create [Entity2] model in src/models/[entity2].py"
+```
+
+---
+
+## Implementation Strategy
+
+### MVP First (User Story 1 Only)
+
+1. Complete Phase 1: Setup
+2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
+3. Complete Phase 3: User Story 1
+4. **STOP and VALIDATE**: Test User Story 1 independently
+5. Deploy/demo if ready
+
+### Incremental Delivery
+
+1. Complete Setup + Foundational → Foundation ready
+2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
+3. Add User Story 2 → Test independently → Deploy/Demo
+4. Add User Story 3 → Test independently → Deploy/Demo
+5. Each story adds value without breaking previous stories
+
+### Parallel Team Strategy
+
+With multiple developers:
+
+1. Team completes Setup + Foundational together
+2. Once Foundational is done:
+   - Developer A: User Story 1
+   - Developer B: User Story 2
+   - Developer C: User Story 3
+3. Stories complete and integrate independently
+
+---
+
+## Notes
+
+- [P] tasks = different files, no dependencies
+- [Story] label maps task to specific user story for traceability
+- Each user story should be independently completable and testable
+- Verify tests fail before implementing
+- Commit after each task or logical group
+- Stop at any checkpoint to validate story independently
+- Avoid: vague tasks, same file conflicts, cross-story dependencies that break
+  independence

package/resources/gofer/templates/ui-approval-template.md

@@ -0,0 +1,32 @@
+---
+feature: '{{feature-name}}'
+created: '{{ISO-timestamp}}'
+workflowProfile: enterpriseai
+status: pending
+---
+
+# UI Approval: {{feature-name}}
+
+## Approved Preview
+
+- **Preview reference**: {{preview-ref}}
+- **Approver**: {{approver}}
+- **Approved at**: {{timestamp}}
+
+## Approved Design Constraints
+
+- **EAI App Template baseline preserved**: {{yes-no}}
+- **Approved profile choice**: {{external-internal-hybrid}}
+- **Approved package lane**:
+  {{public-package-internal-app-hybrid-adapter-app-local}}
+- **Approved coupling status**:
+  {{source-platform-coupled-source-platform-decoupled-hybrid-adapter}}
+- **Approved Storybook story IDs**: {{storybook-story-ids-or-exceptions}}
+- **Approved theme override points**: {{theme-override-points}}
+- **Approved create-new exceptions**: {{exceptions-or-none}}
+- **Approved branding/logo scope**: {{branding-scope}}
+- **Approved public-readiness target**: {{required-deferred-not-applicable}}
+
+## Approval Notes
+
+- {{note}}

package/resources/gofer/templates/ui-preview-brief-template.md

@@ -0,0 +1,65 @@
+---
+feature: '{{feature-name}}'
+created: '{{ISO-timestamp}}'
+workflowProfile: enterpriseai
+status: draft
+---
+
+# UI Preview Brief: {{feature-name}}
+
+## Goal
+
+- **Smallest useful MVP to show first**: {{mvp-slice}}
+- **Primary users**: {{users}}
+- **Workflow goal**: {{workflow-goal}}
+
+## Preview Scope
+
+| Area                                      | Requirement      |
+| ----------------------------------------- | ---------------- |
+| Must-have screens                         | {{screens}}      |
+| Must-have interactions                    | {{interactions}} |
+| Explicitly out of scope for first preview | {{out-of-scope}} |
+
+## Package Profile
+
+| Field                   | Decision                                                             |
+| ----------------------- | -------------------------------------------------------------------- |
+| Profile choice          | {{external-internal-hybrid}}                                         |
+| Package lane            | {{public-package-internal-app-hybrid-adapter-app-local}}             |
+| Coupling status         | {{source-platform-coupled-source-platform-decoupled-hybrid-adapter}} |
+| Public-readiness target | {{required-deferred-not-applicable}}                                 |
+
+## EAI App Template Constraints
+
+| Constraint                    | Decision                                          |
+| ----------------------------- | ------------------------------------------------- |
+| Default layout / blocks       | {{approved-template-blocks}}                      |
+| Block catalog evidence        | {{eai-blocks-list-and-describe-evidence}}         |
+| Resource bindings             | {{eai-resources-schema-bindings}}                 |
+| Storybook story IDs           | {{storybook-story-ids-or-exceptions}}             |
+| Theme override points         | {{theme-presentation-copy-data-action-overrides}} |
+| Allowed create-new exceptions | {{approved-exceptions-or-none}}                   |
+| Accessibility baseline        | {{expectation}}                                   |
+
+## Block Porting And source platform Decoupling
+
+| Block ID     | Package Lane | Storybook Story ID | Coupling Status | Porting Decision                | Theme Override Points     | Custom-Block Exception    |
+| ------------ | ------------ | ------------------ | --------------- | ------------------------------- | ------------------------- | ------------------------- |
+| {{block-id}} | {{lane}}     | {{story-id-or-na}} | {{status}}      | Reuse / Port / Custom Exception | {{tokens-slots-css-vars}} | {{none-or-approval-path}} |
+
+## Branding Inputs
+
+| Input                | Status              |
+| -------------------- | ------------------- |
+| Logo / marks         | {{provided-or-not}} |
+| Colors / styling     | {{provided-or-not}} |
+| Voice / copy tone    | {{provided-or-not}} |
+| Corporate references | {{provided-or-not}} |
+
+## Preview Validation Before Presentation
+
+- [ ] Local render proof captured
+- [ ] Screenshot or Playwright-style self-review captured
+- [ ] Brief-to-preview mismatch list recorded
+- [ ] Open visual risks called out before stakeholder review

package/resources/gofer/templates/ui-review-log-template.md

@@ -0,0 +1,11 @@
+---
+feature: '{{feature-name}}'
+created: '{{ISO-timestamp}}'
+workflowProfile: enterpriseai
+---
+
+# UI Review Log: {{feature-name}}
+
+| Round | Preview Ref | Evidence | Package Lane | Coupling Status | Storybook Story IDs | Theme Override Points | Stakeholder Feedback | Changes Accepted | Open Issues |
+| ----- | ----------- | -------- | ------------ | --------------- | ------------------- | --------------------- | -------------------- | ---------------- | ----------- |
+| 1 | {{preview-ref}} | {{screenshot-or-playwright}} | {{lane}} | {{coupling-status}} | {{story-ids}} | {{theme-overrides}} | {{feedback}} | {{accepted}} | {{open}} |

package/resources/gofer/templates/visuals/bounded-context-map.md

@@ -0,0 +1,19 @@
+---
+template: bounded-context-map
+version: 1.0
+---
+
+# Bounded Context Map: {{FEATURE_NAME}}
+
+```mermaid
+flowchart TB
+    subgraph BC1[{{CONTEXT_1}}]
+        E1[{{ENTITY_1}}]
+    end
+    subgraph BC2[{{CONTEXT_2}}]
+        E2[{{ENTITY_2}}]
+    end
+    BC1 -->|{{INTEGRATION_TYPE}}| BC2
+```
+
+**Integration Patterns**: {{PATTERNS}}

package/resources/gofer/templates/visuals/bounded-context-template.md

@@ -0,0 +1,47 @@
+---
+template: bounded-context-template
+version: 1.0
+preamble_min_words: 30
+preamble_max_words: 200
+---
+
+# Bounded Context Map — {{FEATURE_NAME}}
+
+<!-- preamble: ≥30 ≤200 words plain-language explanation of bounded contexts and integrations -->
+
+This bounded-context map shows the logical domain partitions inside the system
+and the named integration patterns between them. Each subgraph represents a
+single bounded context: a region of the model with consistent language,
+ownership, and responsibility. The arrows between contexts are not arbitrary
+calls; they describe the relationship type, such as anti-corruption layer,
+shared kernel, customer-supplier, or open-host service. Use this view to align
+team boundaries with code boundaries and to spot integration patterns that might
+leak domain concepts across contexts. Reading this diagram complements the C4
+Container view by adding domain-driven design semantics on top of deployable
+units, which is what reviewers and new joiners need to reason about
+responsibility ownership.
+
+## Diagram
+
+```mermaid
+flowchart TB
+    subgraph BC1[{{CONTEXT_1}}]
+        E1[{{ENTITY_1}}]
+    end
+    subgraph BC2[{{CONTEXT_2}}]
+        E2[{{ENTITY_2}}]
+    end
+    subgraph BC3[{{CONTEXT_3}}]
+        E3[{{ENTITY_3}}]
+    end
+    BC1 -->|{{INTEGRATION_TYPE_1}}| BC2
+    BC2 -->|{{INTEGRATION_TYPE_2}}| BC3
+```
+
+## Integration Patterns
+
+{{PATTERNS}}
+
+## Notes
+
+{{NOTES}}

package/resources/gofer/templates/visuals/c4-container-template.md

@@ -0,0 +1,38 @@
+---
+template: c4-container-template
+version: 1.0
+preamble_min_words: 30
+preamble_max_words: 200
+---
+
+# C4 Container: {{FEATURE_NAME}}
+
+<!-- preamble: ≥30 ≤200 words plain-language explanation of containers and their interactions -->
+
+This C4 Container diagram shows the runnable units that make up the system
+implementing this feature. Each container is a separately deployable or
+independently runnable process, application, data store, or service. The arrows
+describe how containers communicate at runtime and which protocol or message
+style they use. Reading this diagram tells a developer where to put new code,
+which container owns which responsibility, and which integrations cross a
+process boundary. Use this view together with the C4 Context diagram (one level
+higher) and the data-model ERD (one level deeper) to keep the architectural
+intent consistent across documents and reviews.
+
+```mermaid
+C4Container
+    title Containers for {{FEATURE_NAME}}
+
+    Person({{PRIMARY_PERSONA}}, "{{PERSONA_DESCRIPTION}}")
+    Container_Boundary(c1, "{{SYSTEM_NAME}}") {
+        Container({{CONTAINER_1}}, "{{TYPE_1}}", "{{DESCRIPTION_1}}")
+        Container({{CONTAINER_2}}, "{{TYPE_2}}", "{{DESCRIPTION_2}}")
+    }
+
+    Rel({{PRIMARY_PERSONA}}, {{CONTAINER_1}}, "Uses")
+    Rel({{CONTAINER_1}}, {{CONTAINER_2}}, "Calls")
+```
+
+## Notes
+
+{{NOTES}}

package/resources/gofer/templates/visuals/c4-container.md

@@ -0,0 +1,20 @@
+---
+template: c4-container
+version: 1.0
+---
+
+# C4 Container: {{FEATURE_NAME}}
+
+```mermaid
+C4Container
+    title Containers for {{FEATURE_NAME}}
+
+    Person({{PRIMARY_PERSONA}}, "{{PERSONA_DESCRIPTION}}")
+    Container_Boundary(c1, "{{SYSTEM_NAME}}") {
+        Container({{CONTAINER_1}}, "{{TYPE_1}}", "{{DESCRIPTION_1}}")
+        Container({{CONTAINER_2}}, "{{TYPE_2}}", "{{DESCRIPTION_2}}")
+    }
+
+    Rel({{PRIMARY_PERSONA}}, {{CONTAINER_1}}, "Uses")
+    Rel({{CONTAINER_1}}, {{CONTAINER_2}}, "Calls")
+```

package/resources/gofer/templates/visuals/c4-context-template.md

@@ -0,0 +1,46 @@
+---
+template: c4-context
+version: 1.0
+preamble_min_words: 30
+preamble_max_words: 200
+---
+
+# C4 Context — {{FEATURE_NAME}}
+
+<!-- preamble: ≥30 ≤200 words plain-language explanation of system context -->
+
+This C4 Context diagram shows the system boundary and the external actors and
+systems it interacts with. The single central box represents the system being
+built; surrounding entities are people who use it (Person) or external services
+it integrates with (System_Ext). Arrows show direction of interaction and label
+the high-level purpose of each integration. This is the highest-level
+architectural view: it tells you who needs the system, what it depends on, and
+what it depends on having available. Reading this diagram is sufficient to
+understand integration scope without needing to read the implementation plan.
+Use it as a checklist when planning integration work, security reviews, or
+onboarding documentation: every external dependency must show up here, and every
+persona who interacts with the system must be represented as a Person box.
+
+## Diagram
+
+```mermaid
+C4Context
+    title System Context for {{FEATURE_NAME}}
+
+    Person({{PRIMARY_PERSONA}}, "{{PERSONA_DESCRIPTION}}")
+    Person({{SECONDARY_PERSONA}}, "{{SECONDARY_PERSONA_DESCRIPTION}}")
+
+    System({{SYSTEM_NAME}}, "{{SYSTEM_DESCRIPTION}}")
+
+    System_Ext({{EXT_SYSTEM_1}}, "{{EXT_DESCRIPTION_1}}")
+    System_Ext({{EXT_SYSTEM_2}}, "{{EXT_DESCRIPTION_2}}")
+
+    Rel({{PRIMARY_PERSONA}}, {{SYSTEM_NAME}}, "{{PRIMARY_REL}}")
+    Rel({{SECONDARY_PERSONA}}, {{SYSTEM_NAME}}, "{{SECONDARY_REL}}")
+    Rel({{SYSTEM_NAME}}, {{EXT_SYSTEM_1}}, "{{EXT_REL_1}}")
+    Rel({{SYSTEM_NAME}}, {{EXT_SYSTEM_2}}, "{{EXT_REL_2}}")
+```
+
+## Notes
+
+{{NOTES}}

package/resources/gofer/templates/visuals/capability-heatmap-template.md

@@ -0,0 +1,54 @@
+---
+template: capability-heatmap
+version: 1.0
+preamble_min_words: 30
+preamble_max_words: 200
+---
+
+# Capability Heatmap — {{FEATURE_NAME}}
+
+<!-- preamble: ≥30 ≤200 words plain-language explanation of capability impact -->
+
+This heatmap places each business capability the feature touches on two axes:
+how mature the capability is today (x-axis) and how strategically valuable it is
+to the organization (y-axis). Capabilities in the upper-right are mature and
+high-value, suitable for optimization. Upper-left capabilities are strategically
+important but lack maturity, indicating investment opportunity. Lower-right are
+mature but low-value, candidates for deprecation. Lower-left are quick wins. Use
+this view to align stakeholders on which capabilities deserve enhancement,
+replacement, or rationalization through this feature. Each entry below the chart
+records whether the capability is being touched, replaced, or extended, plus
+context on why the placement is justified. Capability owners should be able to
+read this without consulting the implementation plan and reach the same
+conclusion about priority order.
+
+## Quadrant Chart
+
+```mermaid
+quadrantChart
+    title Capability Maturity vs Strategic Value
+    x-axis Low Maturity --> High Maturity
+    y-axis Low Value --> High Value
+    quadrant-1 Strategic Investment
+    quadrant-2 Optimize
+    quadrant-3 Deprecate
+    quadrant-4 Quick Wins
+    {{CAPABILITY_1}}: [{{X1}}, {{Y1}}]
+    {{CAPABILITY_2}}: [{{X2}}, {{Y2}}]
+    {{CAPABILITY_3}}: [{{X3}}, {{Y3}}]
+```
+
+## Capabilities Table
+
+| Capability       | Action       | Current Maturity | Strategic Value | Notes       |
+| ---------------- | ------------ | ---------------- | --------------- | ----------- |
+| {{CAPABILITY_1}} | {{ACTION_1}} | {{MATURITY_1}}   | {{VALUE_1}}     | {{NOTES_1}} |
+| {{CAPABILITY_2}} | {{ACTION_2}} | {{MATURITY_2}}   | {{VALUE_2}}     | {{NOTES_2}} |
+| {{CAPABILITY_3}} | {{ACTION_3}} | {{MATURITY_3}}   | {{VALUE_3}}     | {{NOTES_3}} |
+
+## Action Legend
+
+- **touch** — capability is consulted or read by the feature but not changed
+- **extend** — capability gains new behaviour while existing behaviour is
+  preserved
+- **replace** — capability's existing behaviour is superseded by the feature