feat: implement Anti-Drift Workflow v2.0

2026-09-14 18:22:07 +08:00 · 2026-05-08 08:07:54 -04:00
parent d9b2de50c6
commit b202c728b2
10 changed files with 822 additions and 92 deletions
@@ -0,0 +1,146 @@
+# Changelog — Skill Workflow Anti-Drift
+
+**Version**: 2.0.0  
+**Date**: 2026-05-08  
+**Breaking Changes**: Yes — new status schema, new task metadata fields
+
+---
+
+## Summary
+
+This release addresses 8 systemic drift patterns identified in spec-driven development workflows. The changes span all 4 primary skills and 5 secondary skills, introducing unified status schemas, acceptance criteria taxonomy, bounded context validation, and an escalation path for design-level problems.
+
+---
+
+## Primary Skills
+
+### specs.brainstorm — v2.0
+
+**Added**:
+- **Phase 0: Input Mode Detection** — Detects if input is a structured document (ADR/RFC) and extracts architectural constraints
+- **Acceptance Criteria Taxonomy `[IMP]`/`[SEF]`/`[EXT]`** — Classifies every criterion as implementable, side-effect, or external verification
+- **60% Rule** — Ensures at least 60% of criteria are `[IMP]` (prescriptive)
+- **Bounded Context Impact Statement (Section 6)** — Documents primary/secondary bounded contexts and cross-boundary risk
+- **ADR Consistency Check** — Verifies spec does not silently contradict input ADR decisions
+
+**Breaking**:
+- Acceptance criteria MUST now include taxonomy tags in generated specs
+
+### specs.spec-to-tasks — v2.0
+
+**Added**:
+- **Spec Fidelity Gate** — Verifies spec has taxonomy before task decomposition
+- **`[IMP]`-only Task Decomposition** — Only `[IMP]` criteria generate implementation tasks
+- **Bounded Context Boundary Check** — Flags tasks that modify files outside primary context
+- **External Dependency Pre-Flight** — Flags tasks depending on unverified interfaces (e.g., ADR-038)
+- **File Collision Detection** — Merges/splits tasks that create/modify the same file
+- **Test Instructions Fidelity Check** — Removes test scenarios not in the functional spec
+- **Traceability Matrix with `[I]`/`[S]`/`[E]` types** — Separate coverage tracking per criterion type
+
+**Breaking**:
+- Task template now requires `imp-requirements`, `ac-mapping`, `cross-boundary`, `external-dep-risk` frontmatter fields
+- Tasks no longer generated for `[SEF]`/`[EXT]` criteria
+
+### specs.task-implementation — v2.0
+
+**Added**:
+- **Unified Status Schema** — `passed`/`needs_fix`/`partial`/`escalate` (4 states)
+- **Ralph Loop Circuit Breaker** — Escalates after 3 iterations on the same issue
+- **Contract Renegotiation Protocol** — Contracts are proposals for first 3 tasks, stable after
+- **Bounded Context Adherence Check (T-4.6)** — Validates file targets against bounded contexts
+- **Escalation Path (T-7)** — Generates escalation reports and returns to spec-to-tasks
+- **Spec Traceability Gate (T-1)** — Shows task position in overall feature context
+
+**Breaking**:
+- Review status `PASSED`/`FAILED` no longer accepted — must use unified schema
+- Contract validation now allows renegotiation for early tasks
+
+### specs.task-review — v2.0
+
+**Added**:
+- **Unified Status Schema** — `passed`/`needs_fix`/`partial`/`escalate` in output
+- **Spec Fidelity Check (Phase 4.5)** — Verifies task covers declared `[IMP]` criteria only
+- **Bounded Context Adherence Review (Phase 3.6)** — Checks cross-boundary modifications
+- **Architecture Boundary Review (Phase 5.5)** — Detects feature scattering across contexts
+- **Escalate state** — For design-level problems (undocumented cross-boundary, invented entities, etc.)
+
+**Breaking**:
+- Review output now uses 4-state schema instead of binary PASSED/FAILED
+- New review sections for bounded context and architecture checks
+
+---
+
+## Secondary Skills
+
+### specs.ralph-loop — v2.0
+
+**Added**:
+- State machine supports `escalate` as alternative to `fix`
+- Circuit Breaker: forces `escalate` after 3 Ralph Loop iterations on same issue
+- State transitions documented for all 4 review statuses
+
+### specs.task-manage — v2.0
+
+**Added**:
+- Task templates include `imp-requirements`, `ac-mapping`, `cross-boundary`, `external-dep-risk`
+- Action: Add populates new fields from spec automatically
+- Action: Split redistributes AC-IDs among subtasks
+- Complexity Score includes cross-boundary (+10) and external-dep-risk (+5) weights
+
+### specs.task-tdd — v2.0
+
+**Added**:
+- Test generation filters for `[IMP]` criteria only
+- `[SEF]` criteria get comments: "verified in e2e"
+- `[EXT]` criteria get comments: "verified externally"
+- Backward compatibility: generates tests for all ACs if `ac-mapping` is missing
+
+### specs.spec-quality-check — v2.0
+
+**Added**:
+- Quality Scan checks: AC taxonomy tags, 60% rule, Bounded Context Impact Statement
+- Coverage summary includes "AC Taxonomy" and "Bounded Context Impact" dimensions
+- Priority boost: missing taxonomy is the first question asked
+
+### specs.spec-sync-with-code — v2.0
+
+**Added**:
+- Architecture Deviations category in deviation report
+- Automatic task creation checks for escalation reports before proceeding
+- Taxonomy compliance verification in sync validation
+
+---
+
+## Migration Guide
+
+### For existing specs without taxonomy
+
+Run `specs.spec-quality-check` on existing specs. It will detect missing taxonomy as the first issue and guide you through tagging.
+
+### For existing tasks without new metadata
+
+Tasks without `imp-requirements`/`ac-mapping` are treated as "legacy" — backward compatibility is maintained. Run `specs.spec-sync-context --task=TASK-XXX` to enrich existing tasks.
+
+### For ralph-loop state files
+
+Existing `fix_plan.json` files without `iteration_count` are treated as iteration 0. The Circuit Breaker will start counting from the next review.
+
+---
+
+## Files Changed
+
+| File | Change Type |
+|------|-------------|
+| `specs.brainstorm.md` | Major — Phase 0 added, AC taxonomy, BC Impact Statement |
+| `specs.spec-to-tasks.md` | Major — 7 new gates/checks, updated templates |
+| `specs.task-implementation.md` | Major — Unified schema, Circuit Breaker, Escalation Path |
+| `specs.task-review.md` | Major — 4-state schema, Spec Fidelity, Architecture Review |
+| `specs.ralph-loop.md` | Minor — State machine updated for escalate |
+| `specs.task-manage.md` | Minor — New metadata fields, complexity update |
+| `specs.task-tdd.md` | Minor — [IMP] filter for test generation |
+| `specs.spec-quality-check.md` | Minor — Taxonomy checks added |
+| `specs.spec-sync-with-code.md` | Minor — Architecture deviations, escalation handling |
+| `specs.quick-spec.md` | No change — out of scope for this release |
+| `specs.spec-sync-context.md` | No change — Phase 5.5 handles drift detection |
+| `specs.ralph-loop-status.md` | No change — display only |
+| `specs.ralph-loop-cancel.md` | No change |
@@ -92,6 +92,7 @@ incrementally, generate professional documentation, review the document, and rec
 - **YAGNI ruthlessly**: Remove unnecessary features from all specifications
 - **Functional focus ONLY**: Describe WHAT the system should do, never HOW it will be implemented
 - **No technical decisions**: Do NOT mention frameworks, libraries, patterns, or code
+- **ADR constraint preservation**: When the input is an ADR, RFC, or technical analysis document, the architectural decisions it contains are treated as **immutable constraints** for the functional specification. If the brainstorming process identifies a need to override an ADR decision, the override MUST be explicitly documented in `decision-log.md` with a DEC entry referencing the original ADR.
 - **Incremental validation**: Present specification in sections, validate each
 - **Professional documentation**: Use specialist agent for high-quality documents
 - **Be flexible**: Go back and clarify when something doesn't make sense
@@ -101,15 +102,70 @@ incrementally, generate professional documentation, review the document, and rec

 ---

+## Phase 0: Input Mode Detection & ADR Discovery
+
+**Goal**: Determine whether the input is a free-form idea, an ADR/RFC, or a structured analysis document. If the input is a structured document, extract architectural decisions as constraints before proceeding.
+
+**Context**: The `$ARGUMENTS` parameter may contain:
+- A free-text idea (e.g., "Add user authentication with JWT tokens")
+- A path to an existing document (e.g., `@docs/adr/039-git-worktree-management.md`)
+- A reference to a file containing architectural decisions, RFC, or analysis
+
+**Actions**:
+
+1. **Detect input mode**:
+   - If `$ARGUMENTS` contains a file path pattern (starts with `/`, `./`, `docs/`, or `@docs/`): **Structured Document Mode**
+   - If `$ARGUMENTS` is free text describing a feature: **Free-Form Idea Mode**
+   - If `$ARGUMENTS` is empty: Ask user for input and detect mode from their response
+
+2. **If Structured Document Mode**:
+   - Read the referenced document
+   - Extract all **architectural decisions** documented in the file:
+     - Configuration values, defaults, and file paths
+     - CLI flags and command structures proposed
+     - Integration patterns with existing systems
+     - Error handling and edge-case strategies
+     - Directory structures and naming conventions
+   - Create a `constraints` list in memory with the extracted decisions
+   - **Do NOT re-evaluate these decisions** — they are the architectural foundation. The functional specification must work within them.
+   - If a decision in the ADR contradicts project conventions (e.g., architecture.md, ontology.md), flag it as a conflict, not as a candidate for change
+
+3. **If Free-Form Idea Mode**:
+   - Proceed directly to Phase 1 — no constraints to extract
+   - The brainstorming will discover all decisions collaboratively
+
+4. **Decision override protocol**:
+   - If during brainstorming you identify that an ADR decision should be overridden:
+     - Create a DEC entry in `decision-log.md` with:
+       - Reference to the original ADR (e.g., "Overrides ADR-039, Section 3: Configuration")
+       - Justification for the override
+       - Impact on the specification
+     - Only then modify the constraint
+   - Without a DEC entry, ADR constraints remain immutable
+
+5. **Summarize constraints** (Structured Document Mode only):
+   - After extraction, produce a brief summary:
+   ```
+   Input Mode: Structured Document (ADR-039)
+   Constraints extracted:
+   - Config: worktreeBasePath (default: ../<repo-name>-worktrees)
+   - CLI: No explicit flags mentioned
+   - Integration: ADR-038 branch creation
+   - Behavior: Worktree creation + manual cleanup command
+   Override DEC entries: None / DEC-XXX
+   ```
+
+---
+
 ## Phase 1: Context Discovery

-**Goal**: Understand the current project state and the initial idea
+**Goal**: Understand the current project state and the initial idea, within the bounds of any extracted constraints

 **Initial idea**: $ARGUMENTS

 **Actions**:

-1. Create todo list with all phases
+1. Create todo list with all phases (including Phase 0 if Structured Document Mode)
 2. Explore the current project state (for context only - do NOT include in specification):
    - Read recent commits to understand what's being worked on
    - Check for existing documentation (README, docs/, existing specs)
@@ -363,11 +419,25 @@ Task(
    - Clear, testable criteria for each user story
    - Success conditions in natural language
    - Edge case handling
+    - **MANDATORY: Acceptance Criteria Taxonomy** — Every criterion MUST be classified with one of:
+      - **`[IMP]` Implementable**: Requires new code, configuration, or explicit system behavior. **Only these generate implementation tasks.**
+      - **`[SEF]` Side-Effect**: A natural, automatic consequence of an `[IMP]` criterion being satisfied. These do NOT generate standalone tasks but should be verifiable in e2e tests.
+      - **`[EXT]` External Verification**: Verified by external tools, user observation, or existing system behavior. These do NOT generate tasks but should appear as e2e checkpoints.
+    - **60% Rule**: At least 60% of acceptance criteria should be `[IMP]`. If fewer than 60% are `[IMP]`, the specification is too descriptive and not prescriptive enough — return to Section 2 and refine.
+    - **Why this matters**: `spec-to-tasks` uses `[IMP]` criteria to generate atomic tasks. `[SEF]` and `[EXT]` criteria that are misclassified as `[IMP]` produce "false work" — tasks that verify natural behavior rather than implement functionality.

   **Section 5: Integration Requirements**
    - What existing systems must integrate with (capabilities, not implementation)
    - Data exchange requirements (not technical protocols)

+   **Section 6: Bounded Context Impact (Optional but Recommended)**
+    - **Primary Context**: The bounded context where the majority of new code will reside (e.g., "Git Worktree Management")
+    - **Secondary Contexts Touched**: Existing bounded contexts where files will be modified (e.g., "Core Engine — task_run.go will be modified")
+    - **Inbound Dependencies**: Services or interfaces this feature requires FROM other contexts (e.g., "ADR-038 BranchCreator from Core Engine")
+    - **Outbound Dependencies**: Services or interfaces this feature provides TO other contexts
+    - **Cross-Boundary Risk**: If this feature modifies files in a context different from its primary, flag as `HIGH RISK` and document the rationale
+    - **Why this matters**: `spec-to-tasks` uses this statement to validate that tasks respect bounded context boundaries. Features that silently cross boundaries produce tightly-coupled tasks that are hard to implement and review in isolation.
+
 4. **CRITICAL**: Throughout all sections, NEVER mention:
    - Frameworks, libraries, or tools
    - Technical patterns or architectural styles
@@ -443,14 +513,20 @@ Task(
    - Error scenarios: [from Section 3]

    **Acceptance Criteria**:
-    - Testable criteria: [from Section 4]
+    - Testable criteria: [from Section 4 — each MUST be tagged with [IMP], [SEF], or [EXT]]
    - Success conditions: [from Section 4]
    - Edge cases: [from Section 4]
+    - **60% Rule Check**: Ensure at least 60% of criteria are [IMP]; if not, flag for refinement

    **Integration Requirements**:
    - Systems to integrate: [from Section 5]
    - Data exchange: [from Section 5]

+    **Bounded Context Impact** (from Section 6):
+    - Primary context: [bounded context]
+    - Secondary contexts touched: [list or "None"]
+    - Cross-boundary risk: [NONE / LOW / HIGH]
+
    **Out of Scope**: [list]
    **Open Questions**: [list]

@@ -462,7 +538,8 @@ Task(
    - Do NOT mention any frameworks, libraries, or tools
    - Do NOT include code or pseudo-code
    - Focus on WHAT the system should do, not HOW
-    - Use professional markdown structure",
+    - Every acceptance criterion MUST include its taxonomy tag: [IMP], [SEF], or [EXT]
+    - Use professional markdown structure
  subagent_type: "developer-kit:document-generator-expert"
 )
 ```
@@ -595,15 +672,32 @@ Task(

    4. **Testability**: Acceptance criteria are clear and testable

-    5. **Formatting**: Proper markdown structure, consistent formatting
+    5. **Acceptance Criteria Taxonomy**: Verify that:
+       - Every acceptance criterion is tagged with `[IMP]`, `[SEF]`, or `[EXT]`
+       - No `[SEF]` or `[EXT]` is disguised as `[IMP]` (e.g., "git worktree list shows worktree" should be `[SEF]`, not `[IMP]`)
+       - At least 60% of criteria are `[IMP]`; if not, flag as "Under-specified — needs more prescriptive criteria"

-    6. **Clarity**: Language is professional, concise, and unambiguous
+    6. **Bounded Context Impact**: If Section 6 is present, verify it:
+       - Identifies a clear primary bounded context
+       - Lists all secondary contexts touched
+       - Flags cross-boundary modifications with appropriate risk level
+
+    7. **ADR Consistency** (if the input was a structured document):
+       - Verify that the functional specification does NOT silently contradict the ADR constraints
+       - Check that any override of an ADR decision has a corresponding DEC entry in the decision-log
+       - Flag any configuration defaults, paths, or naming conventions that differ from the ADR without justification
+
+    8. **Formatting**: Proper markdown structure, consistent formatting
+
+    9. **Clarity**: Language is professional, concise, and unambiguous

    Provide:
    - Overall assessment (Excellent / Good / Needs Revision)
    - List of any missing sections or content
    - Specific issues found (if any)
    - Any technical details that should be removed
+    - **AC Taxonomy issues**: List any ACs misclassified or missing classification
+    - **Bounded Context issues**: Flag any unannotated cross-boundary modifications
    - Recommendations for improvement (if needed)",
  subagent_type: "developer-kit:general-code-reviewer"
 )
@@ -671,6 +765,8 @@ Task(

 1. Mark all todos complete
 2. Summarize:
+    - **Input Mode**: Free-Form Idea / Structured Document (ADR/RFC)
+    - **ADR Constraints Preserved**: [If structured document: list key constraints extracted and whether any were overridden with DEC entries]
    - **Original Idea**: What was brainstormed
    - **Scope Assessment**: Small / Medium / Large (and user choice if large)
    - **Scope Split Decision**: [If applicable: "User chose to split into N specifications - focusing on Spec A: [name]" OR "User chose to continue with single specification despite large scope warning"]
@@ -680,7 +776,7 @@ Task(
    - **Spec ID**: `[id]` (e.g., `001-hotel-search-aggregation`)
    - **Document Location**: `docs/specs/[id]/YYYY-MM-DD--feature-name.md`
    - **Specification Review**: Review outcome and any revisions made
-    - **Recommended Next Step**: 
+    - **Recommended Next Step**:
      - If scope was split: "Complete this specification's implementation, then run /developer-kit-specs:specs.brainstorm for Spec B: [name]"
      - Otherwise: "Generate task list with /developer-kit-specs:specs.spec-to-tasks"

@@ -739,6 +835,7 @@ If implementation reveals specification issues, you can re-run `/developer-kit-s
 - The previous specification will be preserved in its folder
 - A new specification will be created with the current date
 - You can reference the previous specification during the new brainstorming session
+- **If the original input was an ADR**: Re-running brainstorming MUST re-read the ADR file to ensure constraints are still accurately captured. Do NOT rely on the previous spec for ADR constraints — the ADR is the source of truth.

 ## Todo Management

@@ -746,6 +843,7 @@ Throughout the process, maintain a todo list like:

 ```

+[ ] Phase 0: Input Mode Detection & ADR Discovery (if structured document)
 [ ] Phase 1: Context Discovery
 [ ] Phase 1.5: Complexity Assessment & Scope Validation (split if scope too large)
 [ ] Phase 2: Idea Refinement
@@ -755,8 +853,9 @@ Throughout the process, maintain a todo list like:
 [ ] Section 1: Business Context
 [ ] Section 2: Functional Requirements
 [ ] Section 3: User Interactions
-[ ] Section 4: Acceptance Criteria
+[ ] Section 4: Acceptance Criteria (with [IMP]/[SEF]/[EXT] taxonomy)
 [ ] Section 5: Integration Requirements
+[ ] Section 6: Bounded Context Impact Statement
 [ ] Phase 6: Functional Specification Generation
 [ ] Phase 6.1: Ontology Initialization/Enrichment (docs/specs/ontology.md)
 [ ] Phase 7: Specification Review
@@ -836,4 +935,23 @@ Update the status as you progress through each phase and section.
 /developer-kit-specs:specs.task-implementation --lang=spring --task="docs/specs/001-reporting-module/tasks/TASK-002.md"
 ```

+### Example 8: ADR-as-Input Mode (Structured Document)
+
+When the input is an existing ADR or RFC, the brainstorming extracts architectural constraints and preserves them:
+
+```bash
+# Step 1: Point to an ADR file — brainstorming will extract constraints automatically
+/developer-kit-specs:specs.brainstorm @docs/adr/039-git-worktree-management.md
+
+# Output will include:
+# - Phase 0: Extracts worktreeBasePath, CLI flags, ADR-038 integration as constraints
+# - Phase 5: Acceptance criteria tagged with [IMP]/[SEF]/[EXT]
+# - Phase 6: decision-log.md includes DEC entries for any ADR overrides
+
+# Step 2: Proceed to spec-to-tasks as normal
+/developer-kit-specs:specs.spec-to-tasks --lang=go docs/specs/025-git-worktree-per-spec/
+```
+
+**Key difference**: The ADR's decisions (e.g., `worktreeBasePath` default, cleanup model) are treated as immutable constraints. Any override requires a DEC entry in `decision-log.md`.
+
 This separates WHAT (functional specification) from HOW (implementation), following the "divide et impera" principle.
@@ -8,7 +8,20 @@ allowed-tools: Read, Glob, Grep, Bash(python3:*), Bash(git:*), AskUserQuestion

 The Ralph Loop applies the "Ralph Wiggum as a Software Engineer" technique to specification-driven development. It solves context window explosion by executing **one step per invocation**, persisting state in `fix_plan.json`.

-State machine: `init → choose_task → implementation → review → fix → cleanup → sync → update_done → (loop)`
+State machine: `init → choose_task → implementation → review → [fix | escalate] → cleanup → sync → update_done → (loop)`
+
+**States**:
+- `fix`: Normal review feedback — implementation needs fixes (Ralph Loop)
+- `escalate`: Design-level problem detected — requires returning to spec-to-tasks (Circuit Breaker)
+- **Ralph Loop Circuit Breaker**: If the same issue persists for 3+ iterations, force `escalate` even if review says `needs_fix`
+
+**State transitions**:
+```
+review_status = passed    → cleanup
+review_status = needs_fix → fix (if iteration < 3) OR escalate (if iteration >= 3)
+review_status = partial   → fix (if iteration < 3) OR escalate (if iteration >= 3)
+review_status = escalate  → escalate (always, regardless of iteration count)
+```

 ## Usage

@@ -203,6 +203,9 @@ For each category, mark the status: **Clear**, **Partial**, or **Missing**
 - [ ] Testable acceptance criteria
 - [ ] Measurable Definition of Done
 - [ ] Requirements → acceptance traceability
+- [ ] **Acceptance criteria tagged with [IMP]/[SEF]/[EXT]**
+- [ ] **At least 60% of AC are [IMP]**
+- [ ] **Bounded Context Impact Statement present (if feature crosses contexts)**

 #### Placeholders and TODOs
 - [ ] Resolved TODO markers
@@ -231,7 +234,8 @@ For each category, mark the status: **Clear**, **Partial**, or **Missing**
 **Actions**:

 1. For each category with Partial or Missing status, generate a potential question
-2. Apply constraints:
+2. **Priority boost**: If "Acceptance criteria tagged" is Missing → this is the FIRST question (taxonomy is foundational)
+3. Apply constraints:
   - **Maximum 5 questions total**
   - Each question must be answerable with:
     - **Multi-choice** (2-5 mutually exclusive options), OR
@@ -313,6 +317,9 @@ For each category, mark the status: **Clear**, **Partial**, or **Missing**
 | Placeholder/TODO | Resolve or quantify |
 | Architecture misalignment | Flag for `docs/specs/architecture.md` update or ADR |
 | Undefined domain term | Add term to `docs/specs/ontology.md` glossary |
+| Missing AC taxonomy | Apply [IMP]/[SEF]/[EXT] tags to all acceptance criteria |
+| Missing Bounded Context Impact | Add Section 6: Bounded Context Impact Statement |
+| < 60% [IMP] criteria | Return to brainstorming for more prescriptive criteria |

 **Integration rules**:
 - Preserve existing formatting
@@ -359,6 +366,8 @@ For each category, mark the status: **Clear**, **Partial**, or **Missing**
   | Edge Cases Coverage | Resolved/Clear/Deferred/Outstanding | ... |
   | Architecture Alignment | Resolved/Clear/Deferred/Outstanding/N/A | ... |
   | Ontology Consistency | Resolved/Clear/Deferred/Outstanding/N/A | ... |
+   | **AC Taxonomy ([IMP]/[SEF]/[EXT])** | Resolved/Clear/Deferred/Outstanding | ... |
+   | **Bounded Context Impact** | Resolved/Clear/Deferred/Outstanding/N/A | ... |

 3. **Status definitions**:
   - **Resolved**: Was Partial/Missing, has been addressed
@@ -121,6 +121,10 @@ If no matching spec folder is found for the current branch, stop and inform the
   ### Requirement Refinements
   - Changed "instant search" to "search with caching"

+   ### Architecture Deviations
+   - Cross-boundary modification in TASK-005 (modified Core Engine file)
+   - New cross-context dependency introduced
+
   ### Scope Reductions
   - Dropped "search by proximity" feature
   ```
@@ -181,6 +185,9 @@ If no matching spec folder is found for the current branch, stop and inform the
   - For each scope expansion: Create task for new feature/component
   - For each requirement refinement: Create task for updated requirement
   - For each scope reduction: Mark related tasks as optional or superseded
+   - For each architecture deviation: Check if escalation report exists in `docs/specs/[id]/escalations/`
+     - If YES: suggest returning to `/developer-kit-specs:specs.spec-to-tasks` instead of creating tasks
+     - If NO: flag as requiring ADR or architecture review before proceeding
   - Skip refinements that don't require new implementation (e.g., documentation clarifications)

 2. **Generate task proposals**:
@@ -288,6 +295,8 @@ For each deviation type, create task as follows:
   - Check if all tasks still map to updated spec
   - Identify tasks that need updates
   - Flag tasks with obsolete references
+   - **Verify taxonomy compliance**: Ensure no task claims to implement `[SEF]` or `[EXT]` criteria as `[IMP]`
+     - If a task's `imp-requirements` includes `[SEF]`/`[EXT]` ACs: flag as "Task Over-Specification — should be e2e only"

 2. **Report validation results**:
   ```markdown
@@ -703,21 +703,33 @@ Provide a comprehensive summary that will inform task generation.
   - Add `contracts/README.md` summarizing why no standalone interface contract files were extracted yet
   - Document any implicit boundaries that tasks must preserve

-5. **Treat artifacts as mandatory inputs for task generation**:
-   - Phase 4 and Phase 5 must read `data-model.md` and `contracts/*`
-   - Tasks must reference these artifacts in technical context, implementation details, and test instructions when relevant
+5. **ARTIFACT FIDELITY GATE (prevents Over-Specification Drift)**:
+   - Before proceeding to Phase 4, verify that every entity, field, and relationship in `data-model.md` can be traced back to the functional specification
+   - For each element in `data-model.md`, ask: "Is this explicitly required by the spec, or is it my technical interpretation?"
+   - **If an element is NOT derivable from the spec**: 
+     - Mark it with `(derived)` in the data-model.md
+     - Do NOT create acceptance criteria around it in task files
+     - It may appear in "Technical Context" as an implementation suggestion, never as a requirement
+   - Example: `WorktreeState` struct is NOT in the spec — it is a derived implementation detail. It must be marked `(derived)` and never appear as "WorktreeState must be defined" in any task's AC.

-6. **Do NOT update agent context files in this phase**:
+6. **Treat artifacts as advisory inputs for task generation**:
+   - Phase 4 and Phase 5 may read `data-model.md` and `contracts/*` for context
+   - Tasks must use these artifacts ONLY to inform implementation choices, NEVER as source of truth for acceptance criteria
+   - The **functional specification** (with its `[IMP]`/`[SEF]`/`[EXT]` taxonomy) is the ONLY source of truth for acceptance criteria
+   - **Critical distinction**: If `data-model.md` defines `WorktreeManager` but the spec does NOT mention it, the task cannot have "WorktreeManager interface must be defined" as an AC. The task AC must reflect the spec's language (e.g., "Worktree can be created via CLI command").
+
+7. **Do NOT update agent context files in this phase**:
   - Do not call `/developer-kit-specs:specs.spec-sync-context`
   - Do not create or modify `knowledge-graph.json`
   - Do not rewrite task files or any other context cache as part of artifact generation

-7. **Log and report**:
+8. **Log and report**:
   ```
   Specification artifacts generated:
   - Data model: docs/specs/[ID]/data-model.md
   - Contracts directory: docs/specs/[ID]/contracts/
   - Contract files: [list generated files]
+   - Fidelity Gate: [N] elements from spec, [M] elements derived (marked)
   ```

 **Note**: This phase always runs, even when a cached Knowledge Graph is reused in Phase 2.5.
@@ -726,14 +738,23 @@ Provide a comprehensive summary that will inform task generation.

 ## Phase 4: Technical Task Decomposition

-**Goal**: Break down requirements into atomic, executable tasks
+**Goal**: Break down `[IMP]` requirements into atomic, executable tasks. Respect bounded context boundaries and avoid over-specification.
+
+**CRITICAL: Spec Fidelity Gate** — Before decomposing tasks, verify:
+1. The functional specification contains acceptance criteria tagged with `[IMP]`, `[SEF]`, or `[EXT]`
+2. If tags are MISSING: apply taxonomy retroactively based on the spec's content, then proceed
+3. If the spec has a "Bounded Context Impact Statement" (Section 6): load it and use it for boundary validation
+4. If the spec has NO `[IMP]` criteria: STOP — the spec is purely descriptive. Return to brainstorming.

 **Actions**:

-1. **Always review generated specification artifacts**:
-   - Read `docs/specs/[id]/data-model.md` for entities, relationships, invariants, and states
-   - Read `docs/specs/[id]/contracts/*` for request/response, event, or boundary definitions
-   - Use these artifacts to define task boundaries, data responsibilities, integration points, and test expectations
+1. **Filter requirements by taxonomy — ONLY `[IMP]` criteria generate implementation tasks**:
+   - Read the functional specification's acceptance criteria
+   - Select ONLY criteria tagged `[IMP]` (Implementable) for task decomposition
+   - **`[SEF]` criteria**: Do NOT generate standalone tasks. They will be verified in the e2e task (TASK-N-1).
+   - **`[EXT]` criteria**: Do NOT generate standalone tasks. They will be listed as checkpoints in the e2e task.
+   - Example: If AC-5 (`git worktree list` shows worktree) is `[SEF]`, it does NOT get a task. It is a natural side effect of using `git worktree add`, which is covered by AC-1's task.
+   - **Why this matters**: Creating tasks for `[SEF]` criteria produces "false work" — tasks that verify natural behavior rather than implement functionality. In spec 025, AC-5 (`git worktree list`) and AC-2 (second run reuses) are `[SEF]` and should not generate dedicated tasks.

 1.1. **If Knowledge Graph context is available** (from Phase 2.5 cached only):
   - Review KG patterns: Architectural patterns to follow in each task
@@ -744,14 +765,39 @@ Provide a comprehensive summary that will inform task generation.
   - Example: "Follow existing Repository Pattern - extend JpaRepository"
   - Example: "Integrate with existing HotelService.searchHotels() method"

-1.2. **If Architecture context is available** (from Phase 1.5):
-   - Use the technology stack to inform implementation details in each task
-   - Ensure tasks reference the correct frameworks, libraries, and patterns from `docs/specs/architecture.md`
-   - If tasks require new infrastructure components not in the architecture document, flag them for ADR tracking using the `adr-drafting` skill
-   - Example: "Use NestJS module pattern as defined in architecture.md"
-   - Example: "Follow PostgreSQL with Drizzle ORM as specified in architecture"
+1.2. **BOUNDED CONTEXT BOUNDARY CHECK (prevents Boundary Confusion Drift)**:
+   - Load `docs/specs/ontology.md` and extract the bounded context definitions
+   - Load the spec's "Bounded Context Impact Statement" (Section 6) if present
+   - For each task, before assigning file targets, determine the bounded context of each file
+   - **If a task targets files in a bounded context DIFFERENT from the feature's primary context**:
+     - Flag the task as `CROSS-BOUNDARY`
+     - Add a warning in the task's Technical Context:
+       ```
+       ⚠️ BOUNDARY CROSSING: This task modifies [file] which belongs to [bounded context].
+       Primary context of this feature: [primary context].
+       Justification required: Why is this modification in [bounded context] necessary?
+       Recommended: Coordinate with [bounded context] owner or consider if the change belongs there.
+       ```
+     - Example: TASK-005 modifies `cmd/specs-kit/task_run.go` (Core Engine) for a Git Worktree feature. This is a HIGH RISK cross-boundary modification and must be flagged.
+   - **If Architecture context is available** (from Phase 1.5):
+     - Use the technology stack to inform implementation details in each task
+     - Ensure tasks reference the correct frameworks, libraries, and patterns from `docs/specs/architecture.md`
+     - If tasks require new infrastructure components not in the architecture document, flag them for ADR tracking using the `adr-drafting` skill

-1.3. **If Ontology context is available** (from Phase 1.5):
+1.3. **EXTERNAL DEPENDENCY PRE-FLIGHT (prevents Dependency Blindness)**:
+   - Before generating a task that depends on an external interface (e.g., "ADR-038 BranchCreator", "existing API", "third-party service"):
+     - Verify that the interface exists in the codebase OR is documented in a contract
+     - If the interface does NOT exist:
+       - Mark the task as `EXTERNAL_DEPENDENCY_RISK`
+       - Add a warning in the task's Technical Context:
+         ```
+         ⚠️ EXTERNAL DEPENDENCY: This task depends on [interface] which was not found in the codebase.
+         Risk: If [interface] does not exist or has a different signature, this task may fail at contract validation (T-3.6).
+         Mitigation: Verify [interface] exists before implementing this task, or implement it first.
+         ```
+     - Example: TASK-007 depends on `BranchCreator.EnsureBranch(specID, specName)` from ADR-038. If ADR-038 is not yet implemented, this task must be flagged.
+
+1.4. **If Ontology context is available** (from Phase 1.5):
   - Use domain terms from `docs/specs/ontology.md` consistently in task titles, descriptions, and acceptance criteria
   - Ensure task descriptions use the canonical term from the glossary (avoid synonyms not defined in the ontology)
   - If a task introduces NEW domain concepts not in the ontology, add them to `docs/specs/ontology.md` and update the `Last Updated` date
@@ -764,11 +810,15 @@ Provide a comprehensive summary that will inform task generation.

 2. For each task, define:
   - **Title**: Concise, descriptive name (e.g., "User login functionality")
-   - **Description**: What the task covers functionally
-   - **Acceptance Criteria**: 2-4 testable conditions
+   - **Description**: What the task covers functionally — must map to one or more `[IMP]` acceptance criteria
+   - **AC-ID Mapping**: List the acceptance criteria IDs this task implements (e.g., AC-1, AC-3)
+   - **REQ-ID Mapping**: List the requirement IDs this task covers (e.g., REQ-001)
+   - **Acceptance Criteria**: 2-4 testable conditions derived ONLY from `[IMP]` spec criteria
   - **Definition of Ready (DoR)**: Clear preconditions for starting (dependencies complete, technical context understood, blockers resolved)
   - **Definition of Done (DoD)**: Clear completion conditions covering implementation, tests, and task handoff
   - **Dependencies**: List task IDs this depends on (if any)
+   - **Cross-Boundary**: YES/NO — whether this task modifies files outside the feature's primary bounded context
+   - **External Dependency Risk**: YES/NO — whether this task depends on an unverified external interface

 3. Map dependencies explicitly:
   - Identify which tasks must complete before others can start
@@ -777,17 +827,38 @@ Provide a comprehensive summary that will inform task generation.
   - Identify potential circular dependencies (Task A depends on B, B depends on A)
   - Order tasks accordingly

-4. Validate dependencies before generating files:
+4. **FILE COLLISION DETECTION (prevents File Collision Drift)**:
+   - Before generating files, build a file-to-task mapping:
+   ```
+   File: pkg/domain/worktree.go
+     - TASK-001: creates WorktreeState
+     - TASK-003: creates WorktreeManager interface
+     → ⚠️ COLLISION: Two tasks create/modify the same file
+   
+   File: cmd/specs-kit/task_run.go
+     - TASK-005: adds cleanup call
+     - TASK-006: adds preserve-on-failure logic
+     → ⚠️ COLLISION: Two tasks modify the same file
+   ```
+   - **If collisions are detected**:
+     - Merge the colliding tasks into a SINGLE task with combined acceptance criteria
+     - OR split the file responsibilities so each task targets a different file
+     - Add a note in the merged task explaining the collision and the merge decision
+   - **For new files**: If two tasks create the same file, merge them.
+   - **For existing files**: If two tasks modify the same file, merge them OR split by having one task create a hook/extension point and the other use it.
+
+5. Validate dependencies before generating files:
   - Present the dependency structure in a clear table format:

-   | Task ID | Title | Dependencies |
-   |---------|-------|--------------|
-   | TASK-001 | [Title] | None |
-   | TASK-002 | [Title] | TASK-001 |
-   | TASK-003 | [Title] | TASK-001, TASK-002 |
-   | ... | ... | ... |
+   | Task ID | Title | Dependencies | Cross-Boundary? | Ext. Dependency Risk? |
+   |---------|-------|--------------|-----------------|----------------------|
+   | TASK-001 | [Title] | None | No | No |
+   | TASK-002 | [Title] | TASK-001 | No | Yes — ADR-038 |
+   | TASK-003 | [Title] | TASK-001 | **YES** — Core Engine | No |
+   | ... | ... | ... | ... | ... |

   - If there are circular dependencies, high coupling, or unclear ordering, use AskUserQuestion to confirm a fix
+   - **If cross-boundary tasks exist without justification**: warn and ask for confirmation
   - Otherwise proceed directly and include the dependency table in the generated summary

 5. **Identify Test Requirements for Each Task**:
@@ -813,6 +884,23 @@ Provide a comprehensive summary that will inform task generation.

    - **Link Tests to Acceptance Criteria**: Ensure that for each functional acceptance criterion, there is at least one test scenario that verifies it. This step is critical for guaranteeing traceability.

+    **5.1 TEST INSTRUCTIONS FIDELITY CHECK (prevents Self-Referential Test Drift)**:
+    - After generating test instructions, validate each test scenario against the functional specification:
+      - Ask: "Is this behavior explicitly mentioned in the spec's acceptance criteria or business rules?"
+      - **If YES**: Keep the test scenario
+      - **If NO — the scenario is a 'best practice' or 'common edge case'**: 
+        - Remove it from the task's test instructions
+        - Instead, add it to the e2e task (TASK-N-1) as a "Supplemental Verification" — a nice-to-have check, not a blocking requirement
+    - **Banned test scenarios** (unless explicitly in the spec):
+      - Network errors for local filesystem operations (e.g., git worktree)
+      - Mocking requirements for external tools unless the spec requires testability
+      - Performance tests unless the spec defines performance criteria
+      - Concurrency/race condition tests unless the spec mentions concurrent access
+    - **Example from spec 025**: 
+      - "Network error during branch creation" → REMOVE (git worktree is local filesystem)
+      - "Tests use mocking for git commands" → REMOVE (not a spec requirement)
+      - "Git is not available on system" → KEEP only if spec explicitly mentions it (AC-3 in 025 does)
+
 6. Present task structure to the user only if major restructuring, optional tasks, or scope gaps were detected. Otherwise generate the files directly and summarize the resulting plan.

 7. **CRITICAL: Add Mandatory Final Tasks** — After generating all implementation tasks, ALWAYS add these two final tasks:
@@ -887,16 +975,32 @@ spec: [resolved spec file path]
 lang: [java|spring|typescript|nestjs|react|python|general]
 status: pending
 dependencies: [TASK-YYY if applicable]
+imp-requirements: [REQ-IDs of [IMP] criteria this task covers]
 ---

 # TASK-XXX: [Task Title]

-**Functional Description**: [Functional description of what this task covers]
+**Functional Description**: [Functional description of what this task covers — must map to one or more `[IMP]` criteria]
+
+**Maps to Specification**: [AC IDs this task implements, e.g., AC-1, AC-3]
+
+## ⚠️ Cross-Boundary Warning (if applicable)
+<!-- Remove this section if not cross-boundary -->
+- **Primary Context**: [feature's bounded context]
+- **This Task Modifies**: [file] in [different bounded context]
+- **Risk**: HIGH / MEDIUM / LOW
+- **Justification**: [why this cross-boundary modification is necessary]
+
+## ⚠️ External Dependency Risk (if applicable)
+<!-- Remove this section if no external dependency -->
+- **Depends on**: [external interface, e.g., ADR-038 BranchCreator]
+- **Status**: Verified / Unverified / At Risk
+- **Mitigation**: [what to do if the interface doesn't exist or differs]

 ## Acceptance Criteria

- [ ] [Functional criterion 1]
- [ ] [Functional criterion 2]
+- [ ] [Functional criterion 1 — derived ONLY from [IMP] spec criteria, NOT from data-model.md]
+- [ ] [Functional criterion 2 — must be traceable to a specific AC-ID]
 - [ ] [Functional criterion 3 if needed]

 ## Definition of Ready (DoR)
@@ -1042,31 +1146,46 @@ Each task has its own detailed file with technical context:
   
   ## Coverage Summary
   
-   - **Requirements**: N total
-   - **Covered by Tasks**: N/N (100%)
+   - **Requirements**: N total ([I] Implementable / [S] Side-Effect / [E] External)
+   - **Covered by Tasks**: N/N (100%) — Note: Only [I] criteria have implementation tasks
   - **With Tests**: N/N (X%)
   - **Implemented**: N/N (X%)
   
+   ## Coverage Type Legend
+   
+   | Type | Meaning | Task Generated? | Verified In |
+   |------|---------|-----------------|-------------|
+   | `[I]` Implementable | Requires new code | YES — dedicated task(s) | Unit + Integration tests |
+   | `[S]` Side-Effect | Natural consequence of [I] | NO — e2e verification only | E2E test task only |
+   | `[E]` External | Verified externally | NO — e2e checkpoint only | E2E test task only |
+   
   ## Matrix
   
-   | REQ ID | Requirement | Task(s) | Test Files | Code Files | Status |
-   |--------|-------------|---------|------------|------------|--------|
-   | REQ-001 | User can search by destination | TASK-001, TASK-003 | - | - | Pending |
-   | REQ-002 | Results paginated | TASK-005 | - | - | Pending |
+   | REQ ID | Type | Requirement | Task(s) | E2E Checkpoint? | Test Files | Code Files | Status |
+   |--------|------|-------------|---------|-----------------|------------|------------|--------|
+   | REQ-001 | [I] | User can search by destination | TASK-001, TASK-003 | — | - | - | Pending |
+   | REQ-002 | [S] | Results appear in UI automatically | — (e2e only) | YES | - | - | Pending |
+   | REQ-003 | [E] | User receives email notification | — (manual) | YES | - | - | Pending |
   ```

 3. **Initialize matrix columns**:
   - **REQ ID**: Identifier from Phase 2
+   - **Type**: `[I]`, `[S]`, or `[E]` — copied from the spec's AC taxonomy
   - **Requirement**: Brief description (first 50 chars)
-   - **Task(s)**: Comma-separated TASK-XXX list that cover this requirement
+   - **Task(s)**: 
+     - For `[I]`: Comma-separated TASK-XXX list that cover this requirement
+     - For `[S]`/`[E]`: "— (e2e only)" or "— (manual)"
+   - **E2E Checkpoint?**: `YES` for `[S]`/`[E]`, "—" for `[I]`
   - **Test Files**: Leave empty "-" (will be filled by task-review)
   - **Code Files**: Leave empty "-" (will be filled by task-review)
   - **Status**: "Pending" until implementation, then "Implemented" after task-review

 4. **Calculate coverage summary**:
-   - Total requirements count (from REQ-IDs assigned)
-   - Count requirements covered by at least one task (should be 100%)
-   - Report coverage percentage in summary section
+   - Total requirements count (from REQ-IDs assigned), broken down by type
+   - Count `[I]` requirements covered by at least one task (should be 100%)
+   - Count `[S]`/`[E]` requirements with e2e checkpoint (should be 100%)
+   - **Report separate percentages**: "[I] tasks: N/N (100%), [S] e2e: N/N (100%), [E] e2e: N/N (100%)"
+   - **Why separate**: A 100% overall coverage that hides 0% [S]/[E] e2e coverage is misleading. Each type must be tracked independently.

 ## Phase 6: Review and Confirmation

@@ -1103,6 +1222,15 @@ Each task has its own detailed file with technical context:
      - Data model: `docs/specs/[id]/data-model.md`
      - Contracts: `docs/specs/[id]/contracts/*`
    - **Tasks Generated**: Number of tasks created (breakdown: X implementation, 1 e2e test, 1 cleanup)
+    - **[IMP] Criteria**: N criteria → X implementation tasks (each [IMP] should map to at least one task)
+    - **[SEF] Criteria**: N criteria → verified in e2e task (no standalone tasks)
+    - **[EXT] Criteria**: N criteria → e2e checkpoints (no standalone tasks)
+    - **Quality Gates Passed**:
+      - Spec Fidelity Gate: [PASS / FAIL — retroactive taxonomy applied?]
+      - BC Boundary Check: [N cross-boundary tasks flagged]
+      - Ext Dependency Pre-Flight: [N external dependencies flagged]
+      - File Collision Detection: [N collisions detected and resolved]
+      - Test Fidelity Check: [N invented test scenarios removed]
    - **Dependency Structure**: Brief overview of task dependencies
    - **Spec Size Status**: [If >15 tasks were detected: "WARNING: Spec exceeds 15-task limit. User chose to continue anyway" OR "Aborted: User returned to brainstorm to split specification"]
    - **Output Files**:
@@ -1211,17 +1339,16 @@ id: TASK-001
 title: "User registration endpoint"
 spec: docs/specs/001-user-auth/2026-03-07--user-auth-specs.md
 lang: spring
+status: pending
 dependencies: []
+imp-requirements: [REQ-001, REQ-004]
 ---

 # TASK-001: User registration endpoint

 **Functional Description**: Implement user registration with email validation

-## Acceptance Criteria
- [ ] Users can register with a valid email and password.
- [ ] Duplicate email registrations are rejected.
- [ ] Passwords are persisted only after encoding.
+**Maps to Specification**: AC-1 (User can register with email), AC-4 (Password must be encoded)

 ## Definition of Ready (DoR)
 - [ ] No prerequisite tasks are pending.
@@ -1251,22 +1378,22 @@ This section describes **what** to test, not **how** to implement test code.

 **1. Mandatory Unit Tests:**
   - `UserService`:
-     - [ ] Verify that the `register(userData)` method calls `UserRepository.save()` only if the email is unique.
-     - [ ] Verify that `EmailAlreadyExistsException` is thrown when the email is already registered.
-     - [ ] Verify that the password is encoded before saving.
+     - [ ] Verify that the `register(userData)` method calls `UserRepository.save()` only if the email is unique. *(AC-1)*
+     - [ ] Verify that `EmailAlreadyExistsException` is thrown when the email is already registered. *(AC-1)*
+     - [ ] Verify that the password is encoded before saving. *(AC-4)*
   - `AuthController`:
-     - [ ] Test email validation with valid, invalid, and missing formats.
-     - [ ] Verify that the controller returns status 201 for successful registration.
+     - [ ] Test email validation with valid, invalid, and missing formats. *(AC-1)*
+     - [ ] Verify that the controller returns status 201 for successful registration. *(AC-1)*

 **2. Mandatory Integration Tests:**
   - `Registration Flow`:
-     - [ ] Verify that a POST request to the `/api/v1/users/register` endpoint with valid data saves a new user in the database and returns status 201.
-     - [ ] Verify that a request with duplicate email returns status 409 and does not modify the database.
+     - [ ] Verify that a POST request to the `/api/v1/users/register` endpoint with valid data saves a new user in the database and returns status 201. *(AC-1)*
+     - [ ] Verify that a request with duplicate email returns status 409 and does not modify the database. *(AC-1)*

 **3. Edge Cases and Error Conditions to Test:**
-   - [ ] Send malformed email (e.g., without @).
-   - [ ] Send too short password (e.g., less than 8 characters).
-   - [ ] Send malformed JSON payload.
+   - [ ] Send malformed email (e.g., without @). *(AC-1 — validation rule)*
+   - [ ] Send too short password (e.g., less than 8 characters). *(AC-4 — business rule)*
+   - [ ] Send malformed JSON payload. *(AC-1 — input validation)*

 **Test Acceptance Criteria**:
   - [ ] All tests described above are implemented and pass.
@@ -1282,6 +1409,8 @@ This section describes **what** to test, not **how** to implement test code.
 /developer-kit-specs:specs.task-implementation --lang=spring --task="docs/specs/001-user-auth/tasks/TASK-001.md"
 ```

+**Note**: Each test scenario is annotated with `(AC-N)` to show which acceptance criterion it verifies. This prevents Self-Referential Test Drift by making it explicit when a test scenario is NOT traceable to the spec.
+
 ### Example 2: E-commerce Checkout (TypeScript)

 ```bash
@@ -1340,8 +1469,16 @@ Throughout the process, maintain a todo list like:
 [ ] Phase 2: Requirement Extraction
 [ ] Phase 3: Codebase Analysis
 [ ] Phase 4: Technical Task Decomposition (including e2e and cleanup tasks)
+  - [ ] Step 4.0: Spec Fidelity Gate (verify [IMP]/[SEF]/[EXT] taxonomy)
+  - [ ] Step 4.1: Filter [IMP] criteria only for task generation
+  - [ ] Step 4.2: Bounded Context Boundary Check
+  - [ ] Step 4.3: External Dependency Pre-Flight
+  - [ ] Step 4.4: File Collision Detection
+  - [ ] Step 4.5: Test Instructions Fidelity Check
+  - [ ] Step 4.6: Dependency validation with cross-boundary + ext-dep columns
 [ ] Phase 5: Task List Generation
-[ ] Phase 5.5: Spec Size Check (reject if >15 tasks and recommend brainstorm)
+[ ] Phase 5.5: Traceability Matrix Generation (with [I]/[S]/[E] type classification)
+[ ] Phase 5.6: Spec Size Check (reject if >15 tasks and recommend brainstorm)
 [ ] Phase 6: Review and Confirmation
 [ ] Phase 7: Summary
 ```
@@ -1349,11 +1486,19 @@ Throughout the process, maintain a todo list like:
 Update the status as you progress through each phase.

 **CRITICAL**: Phase 4 MUST generate:
-1. Implementation tasks (based on requirements)
-2. One e2e test task (depends on all implementation tasks)
-3. One cleanup task (depends on e2e test task, uses specs-code-cleanup skill)
+1. Implementation tasks (based ONLY on `[IMP]` requirements)
+2. E2E verification points for `[SEF]` and `[EXT]` criteria (included in the e2e task)
+3. One e2e test task (depends on all implementation tasks, verifies all `[IMP]`/`[SEF]`/`[EXT]` criteria)
+4. One cleanup task (depends on e2e test task, uses specs-code-cleanup skill)

-**Phase 5.5 (Spec Size Check)**: If >15 implementation tasks detected:
+**Phase 4 Quality Gates** (MUST pass before generating files):
+- Spec Fidelity Gate: Spec has `[IMP]`/`[SEF]`/`[EXT]` taxonomy
+- BC Boundary Check: All cross-boundary tasks are flagged with justification
+- Ext Dependency Pre-Flight: All external dependencies are flagged with risk level
+- File Collision Detection: No two tasks create/modify the same file without merging
+- Test Fidelity Check: No test scenario invented that isn't in the spec
+
+**Phase 5.6 (Spec Size Check)**: If >15 implementation tasks detected:
 1. STOP task generation immediately
 2. Present warning message explaining the spec is too large
 3. Recommend returning to /developer-kit-specs:specs.brainstorm to split the idea into 2+ specifications
@@ -77,6 +77,7 @@ This command implements a specific task following a focused workflow:
 - T-6: Task Completion
 - T-6.5: Update Specs Quality
 - T-6.6: Spec Deviation Check
+- T-7: Escalation Decision (if design-level problem detected)

 ---

@@ -113,8 +114,30 @@ This command implements a specific task following a focused workflow:
   - Definition of Ready (DoR) and Definition of Done (DoD) sections
   - Dependencies from YAML frontmatter
   - Reference to specification file
+   - **NEW: `imp-requirements` and `ac-mapping` from frontmatter** — which spec ACs this task implements
   - If either section is missing, stop and instruct the user to update the task document before implementation

+4. **Spec Traceability Gate (NEW)**:
+   - If the task file has `spec` reference, read the spec file to get full context:
+     - Load the spec's acceptance criteria list with their `[IMP]`/`[SEF]`/`[EXT]` taxonomy
+     - Identify which ACs this task covers (from `ac-mapping`)
+     - Identify which `[IMP]` ACs remain for other tasks
+   - Display to implementator:
+   ```
+   Task Traceability Context:
+   - This task: TASK-XXX — "[title]"
+   - Implements Spec ACs: [ac-mapping, e.g., AC-1, AC-3]
+   - Corresponding REQ-IDs: [imp-requirements, e.g., REQ-001, REQ-003]
+   
+   Full Specification Context:
+   - Total spec ACs: N ([I] implementable / [S] side-effect / [E] external)
+   - This task covers: X/[I] implementable criteria
+   - Remaining [IMP] criteria will be covered by: [list other tasks from task list]
+   - Primary bounded context: [from spec's Bounded Context Impact Statement, if present]
+   ```
+   - **Why this matters**: The implementator understands WHERE this task sits in the overall feature. This prevents "tunnel vision" where local optimization breaks global consistency.
+   - If the task has a **Cross-Boundary Warning** section: read it and note the risk level before proceeding
+
 ---

 ## T-2: Git State Check
@@ -278,7 +301,25 @@ This command implements a specific task following a focused workflow:
   - Ask user via AskUserQuestion how to proceed
   - If user chooses to proceed, log the unsatisfied contracts

-5. **If all expectations ARE satisfied**:
+5. **CONTRACT RENEGOTIATION PROTOCOL (NEW)**:
+   - **Contracts are proposals, not laws** — especially for the first 3 tasks of a new feature:
+     - **Phase 1 (Tasks 1-3)**: Contracts are "proposals" — can be modified without penalty
+     - **Phase 2 (After Task 3)**: Contracts become "stable" — modifications require changelog
+   - **If the current task discovers that a contract needs to change** (e.g., a struct needs a new field, a signature needs an extra parameter):
+     - Document the change in a **Contract Changelog** section in the task file:
+       ```markdown
+       ## Contract Changelog
+       - **Original contract**: `WorktreeState { SpecID, SpecName, WorktreePath }`
+       - **Modified to**: `WorktreeState { SpecID, SpecName, WorktreePath, CreatedAt }`
+       - **Reason**: Required for age-based cleanup logic (not in original spec)
+       - **Impact**: TASK-002, TASK-003 must update their expectations
+       - **Status**: proposal (Task ≤ 3) / stable (Task > 3)
+       ```
+     - If Task > 3 (stable phase): Warn that dependent tasks may fail contract validation and require re-review
+     - If Task ≤ 3 (proposal phase): Silently update the contract and proceed
+   - **Why this matters**: Early tasks of a feature often "discover" the correct interface shape. Rigid contracts force hacky workarounds or break downstream tasks.
+
+6. **If all expectations ARE satisfied**:
   - Log: "Contract validation passed: All expectations satisfied by completed dependencies"
   - Proceed to implementation with contract context

@@ -313,6 +354,7 @@ This command implements a specific task following a focused workflow:
     - `needs_fix` → Issues need to be addressed
     - `passed` → Review passed, no fixes needed
     - `partial` → Some issues fixed, others remain
+     - `escalate` → Problem is architectural/spec-level, cannot be fixed in this task
   - Extract issues list from the review content
   - Each issue should have:
     - `file`: File affected
@@ -323,7 +365,18 @@ This command implements a specific task following a focused workflow:

 3. **Process review feedback**:
   - If `review_status` is `passed`: Log "Review passed previously, proceeding with implementation"
+   - If `review_status` is `escalate`: Log "Review indicated escalation — proceeding to T-6.6 and T-7.5 for escalation handling. Do NOT attempt to fix."
+     - Skip to T-6.6 (Spec Deviation Check) then T-7.5 (Escalation Decision)
   - If `review_status` is `needs_fix` or `partial`:
+     - **Ralph Loop Circuit Breaker Check**:
+       - Count how many Ralph Loop iterations this task has gone through
+       - Check if the SAME issues appear in previous review files (look for `TASK-007--review-v1.md`, `TASK-007--review-v2.md`, etc.)
+       - **If 3+ iterations with same unresolved issues**:
+         - This is not an implementation bug — it's a design problem
+         - Change `review_status` to `escalate` for this iteration
+         - Log: "Circuit breaker triggered: Same issue persists across 3+ Ralph Loop iterations"
+         - Proceed to T-6.6 and T-7.5
+       - **If different issues each iteration**: Continue normal Ralph Loop
     - Filter issues where `fix_applied: false` or not marked as resolved
     - Group issues by file
     - Log: "Found X issues from previous review that need fixing"
@@ -396,6 +449,27 @@ overall_assessment: partial
 5. Write clean, focused code
 6. **Ralph Loop Mode**: If fixing review issues, focus only on the identified issues unless the user explicitly requests additional changes

+7. **BOUNDED CONTEXT ADHERENCE CHECK (NEW)**:
+   - Before creating or modifying files, determine the bounded context of each target file:
+     - Read `docs/specs/ontology.md` for bounded context definitions
+     - Use the spec's "Bounded Context Impact Statement" (if present) for the feature's primary context
+     - Map each file to its context based on path conventions (e.g., `internal/coreengine/` = Core Engine, `internal/worktree/` = Git Worktree Management)
+   - **If any target file is in a different bounded context from the feature's primary context**:
+     - Check the task file for a "Cross-Boundary Warning" section
+     - If the task file has a justification: review it — is it still valid given what you now know about the codebase?
+     - **If NO justification or weak justification**:
+       - PAUSE implementation
+       - Log: "Bounded Context Adherence Check FAILED: [file] is in [context], but feature's primary context is [primary context]. No valid justification found."
+       - Present options:
+         ```
+         Options:
+         - "Proceed anyway" (cross-boundary modification — will be flagged in review)
+         - "Escalate" (return to spec-to-tasks to redesign the boundary)
+         - "Refactor" (move the logic to a file in the primary context)
+         ```
+       - Ask user via AskUserQuestion
+   - **Why this matters**: Cross-boundary modifications are the #1 cause of architectural drift. They pass review because the code "works", but they corrupt the bounded context model over time.
+
 ---

 ## T-5: Verification
@@ -516,6 +590,86 @@ overall_assessment: partial
   - Treat specification files as deliverables whenever they directly shaped implementation decisions, not as read-only references.
   - If no spec changes are required, state that explicitly with a short rationale.

+6. **ESCALATION EVALUATION (NEW)**:
+   - After documenting deviations, analyze whether the pattern of deviations indicates a systemic problem:
+     - **Same AC violated across multiple tasks**: The acceptance criterion may be impossible or poorly defined. → Escalation type: `spec`
+     - **Cross-boundary modifications causing repeated issues**: The bounded context split is wrong. → Escalation type: `architecture`
+     - **External dependency not available or different from expected**: The task decomposition was based on false assumptions. → Escalation type: `planning`
+     - **Ralph Loop exhausted (3+ iterations on same issue)**: The problem is not implementation-level. → Escalation type: `design`
+   - **If any escalation pattern is detected**:
+     - Do NOT proceed to "Ask user to sync" — the problem is deeper than a sync
+     - Generate an escalation report (see T-7: Escalation Decision)
+     - Set task status to `escalated`
+     - Stop normal completion flow
+   - **If no escalation pattern**: Proceed with user question (point 3 above)
+
+---
+
+## T-7: Escalation Decision (NEW)
+
+**Goal**: Handle cases where implementation reveals a design-level problem that cannot be fixed within the task
+
+**Trigger**: T-6.6 detects an escalation pattern, OR T-3.7 receives `escalate` review status, OR T-4.6 (Bounded Context Check) user chooses "Escalate"
+
+**Actions**:
+
+1. **Generate Escalation Report**:
+   ```markdown
+   # ESCALATION REPORT: TASK-XXX
+   
+   **Date**: YYYY-MM-DD
+   **Task**: TASK-XXX
+   **Escalation Type**: [spec / architecture / planning / design]
+   
+   ## Problem Description
+   [What happened during implementation that revealed a deeper problem]
+   
+   ## Evidence
+   - [Specific deviation from decision-log, if any]
+   - [Ralph Loop iterations exhausted, if applicable]
+   - [Cross-boundary modification that failed, if applicable]
+   
+   ## Root Cause Analysis
+   [Why the task/spec/decomposition was wrong]
+   
+   ## Recommended Action
+   - **If type = spec**: Return to `/developer-kit-specs:specs.brainstorm` to revise the functional specification
+   - **If type = architecture**: Return to `/developer-kit-specs:specs.spec-to-tasks` to redesign the bounded context split
+   - **If type = planning**: Return to `/developer-kit-specs:specs.spec-to-tasks` to regenerate tasks with corrected dependencies
+   - **If type = design**: Return to `/developer-kit-specs:specs.spec-to-tasks` to redefine the interface contracts
+   
+   ## Impact
+   - Tasks affected: [list]
+   - Files that may need rework: [list]
+   - Estimated rework scope: [small/medium/large]
+   ```
+
+2. **Save report**:
+   - Save to `docs/specs/[id]/escalations/TASK-XXX-escalation.md`
+   - Create `escalations/` directory if it doesn't exist
+
+3. **Update task status**:
+   - Set task frontmatter `status: escalated`
+   - Do NOT set `implemented_date`
+   - Do NOT mark task as completed
+
+4. **Inform user**:
+   ```
+   ⚠️ ESCALATION TRIGGERED for TASK-XXX
+   
+   The implementation revealed a [type] problem that cannot be fixed within this task:
+   [Brief problem description]
+   
+   Recommended action: [action from report]
+   Escalation report: docs/specs/[id]/escalations/TASK-XXX-escalation.md
+   
+   Do NOT proceed with dependent tasks until this escalation is resolved.
+   ```
+
+5. **Provide commands for resolution**:
+   - For `spec` escalations: `/developer-kit-specs:specs.brainstorm docs/specs/[id]/`
+   - For `architecture`/`planning`/`design` escalations: `/developer-kit-specs:specs.spec-to-tasks --escalation=docs/specs/[id]/escalations/TASK-XXX-escalation.md docs/specs/[id]/`
+
 ---

 ## Task File Format
@@ -559,6 +713,10 @@ expects:
 | `completed_date` | No | Date cleanup completed (YYYY-MM-DD) |
 | `cleanup_date` | No | Date code cleanup finished (YYYY-MM-DD) |
 | `dependencies` | No | Array of task IDs this task depends on |
+| `imp-requirements` | No | Array of REQ-IDs this task implements (from spec) |
+| `ac-mapping` | No | Array of AC-IDs this task covers (e.g., [AC-1, AC-3]) |
+| `cross-boundary` | No | Boolean — true if task modifies files outside primary bounded context |
+| `external-dep-risk` | No | Boolean — true if task depends on unverified external interface |
 | `provides` | No | What this task makes available (see format below) |
 | `expects` | No | What this task requires from dependencies |
 | `complexity` | No | Complexity score (0-100) |
@@ -91,10 +91,23 @@ Adds a new task to an existing specification.
 4. Ask the user for:
   - Task title
   - Task description
-   - Acceptance criteria
+   - Acceptance criteria (must map to `[IMP]` criteria from spec)
   - Dependencies (if any)
   - Estimated complexity

+5. **Determine `imp-requirements` and `ac-mapping`**:
+   - Read the functional specification to extract `[IMP]` acceptance criteria
+   - Map each acceptance criterion to its AC-ID and REQ-ID
+   - Populate `imp-requirements` with the REQ-IDs this task implements
+   - Populate `ac-mapping` with the AC-IDs this task covers
+   - **If the task implements `[SEF]` or `[EXT]` criteria**: warn that these should not have standalone tasks — recommend e2e verification instead
+
+6. **Determine `cross-boundary` and `external-dep-risk`**:
+   - Read `docs/specs/ontology.md` for bounded context definitions
+   - For each file in `files_to_create`/`files_to_modify`: determine its bounded context
+   - If any file is outside the feature's primary context: set `cross-boundary: true`
+   - If the task depends on an external interface (e.g., ADR-XXX): set `external-dep-risk: true`
+
 5. Create the new task file following the standard task format

 6. Validate dependencies before saving:
@@ -122,11 +135,15 @@ Use this template for straightforward tasks with clear scope.
 ---
 id: "TASK-XXX"
 title: "[Task Title]"
-status: "pending"  # pending | in-progress | completed | superseded | optional
+status: "pending"  # pending | in-progress | completed | superseded | optional | escalated
 description: "[What this task implements]"
+imp-requirements: []  # REQ-IDs this task implements (only [IMP] criteria)
+ac-mapping: []        # AC-IDs this task covers (e.g., [AC-1, AC-3])
+cross-boundary: false  # true if task modifies files outside primary bounded context
+external-dep-risk: false  # true if task depends on unverified external interface
 acceptance_criteria:
-  - "[Criterion 1]"
-  - "[Criterion 2]"
+  - "[Criterion 1 — must map to an [IMP] AC]"
+  - "[Criterion 2 — must map to an [IMP] AC]"
 definition_of_ready:
  - "[Precondition 1]"
  - "[Precondition 2]"
@@ -183,11 +200,15 @@ Use this template for complex tasks that need business context, data contracts,
 ---
 id: "TASK-XXX"
 title: "[Task Title]"
-status: "pending"  # pending | in-progress | completed | superseded | optional
+status: "pending"  # pending | in-progress | completed | superseded | optional | escalated
 description: "[What this task implements]"
+imp-requirements: []  # REQ-IDs this task implements (only [IMP] criteria)
+ac-mapping: []        # AC-IDs this task covers (e.g., [AC-1, AC-3])
+cross-boundary: false  # true if task modifies files outside primary bounded context
+external-dep-risk: false  # true if task depends on unverified external interface
 acceptance_criteria:
-  - "[Criterion 1]"
-  - "[Criterion 2]"
+  - "[Criterion 1 — must map to an [IMP] AC]"
+  - "[Criterion 2 — must map to an [IMP] AC]"
 definition_of_ready:
  - "[Precondition 1]"
  - "[Precondition 2]"
@@ -338,6 +359,12 @@ Splits a complex task into smaller, more manageable subtasks.
   - The `superseded` status is automatically tracked by hooks
   - Add `supersedes` reference to new subtasks in the frontmatter

+7. **Redistribute `imp-requirements` and `ac-mapping`**:
+   - Read the parent task's `imp-requirements` and `ac-mapping`
+   - Distribute the AC-IDs among subtasks based on what each subtask implements
+   - Each subtask should have a NON-OVERLAPPING subset of the parent's AC-IDs
+   - Verify: union of all subtask AC-IDs == parent's AC-IDs
+
 7. Update task index with new structure

 8. Update traceability matrix
@@ -351,6 +378,13 @@ When splitting tasks, child tasks inherit context from parent:

 ```yaml
 # Parent task context (preserved)
+imp-requirements:
+  - "[Subset of parent's REQ-IDs assigned to this child]"
+ac-mapping:
+  - "[Subset of parent's AC-IDs assigned to this child]"
+cross-boundary: false  # inherited but re-evaluated for child's files
+external-dep-risk: false  # inherited but re-evaluated for child's dependencies
+
 business_goals:
  - "[Inherited from parent]"

@@ -500,7 +534,9 @@ COMPLEXITY SCORE =
  (Independent Components × 25) +
  (Design Decisions × 10) +
  (Integration Points × 15) +
-  (External Dependencies × 20)
+  (External Dependencies × 20) +
+  (Cross-Boundary Modification ? 10 : 0) +
+  (External Dependency Risk ? 5 : 0)

 Thresholds:
 - 0-30: Simple
@@ -100,6 +100,8 @@ If no task can be auto-detected, ask the user which task to review.
   - Definition of Ready (DoR) and Definition of Done (DoD) sections
   - Dependencies
   - Reference to specification file
+   - **NEW: `imp-requirements` and `ac-mapping` from frontmatter** — which spec ACs this task claims to implement
+   - **NEW: `cross-boundary` and `external-dep-risk` flags from frontmatter** — pre-identified risks
   - If either section is missing, stop the review and require the task document to be updated before continuing
 5. Read the functional specification file (from task's spec reference)
 6. Verify both files exist and are valid
@@ -161,11 +163,23 @@ If no task can be auto-detected, ask the user which task to review.
     - Update "Status" to "Implemented" for REQ-IDs covered by this task
   - Save updated matrix back to `docs/specs/[id]/traceability-matrix.md`

+6. **BOUNDED CONTEXT ADHERENCE CHECK (NEW)**:
+   - Read `docs/specs/ontology.md` for bounded context definitions
+   - Determine the primary bounded context of the feature (from spec or task frontmatter)
+   - For each file modified/created in the implementation (from git diff or file list):
+     - Determine its bounded context from path conventions or ontology
+     - If DIFFERENT from the feature's primary context:
+       - Check if the task file has a "Cross-Boundary Warning" section
+       - If YES and justification is valid: note in review as "acknowledged cross-boundary" (no issue)
+       - If YES but justification is weak: add `warning` issue — "Cross-boundary modification with weak justification"
+       - If NO warning section: add `blocking` issue — "Undocumented cross-boundary modification. Risks architectural drift."
+   - **Why this matters**: Tasks that silently cross bounded context boundaries are the #1 cause of architectural drift. They pass code review because the code "works", but they corrupt the bounded context model over time.
+
 ---

 ## Phase 4: Specification Compliance Check

-**Goal**: Ensure implementation aligns with functional specification
+**Goal**: Ensure implementation aligns with functional specification AND verify task necessity

 **Actions**:

@@ -178,6 +192,33 @@ If no task can be auto-detected, ask the user which task to review.
 3. Identify any gaps or misalignments
 4. Check if implementation introduces any out-of-scope changes

+5. **SPEC FIDELITY CHECK (NEW)**:
+   - Read the task's `imp-requirements` and `ac-mapping` from frontmatter
+   - For each AC-ID in `ac-mapping`:
+     - Verify the implementation actually satisfies the acceptance criterion
+     - Check the criterion's taxonomy in the spec: `[IMP]`, `[SEF]`, or `[EXT]`
+     - **If the task claims to implement `[SEF]` or `[EXT]` criteria**: 
+       - Flag as "Task Over-Specification" — the task should NOT have standalone ACs for side-effects or external verifications
+       - These should be verified only in e2e, not in individual task ACs
+   - **If the task has NO `ac-mapping` or `imp-requirements`**:
+     - Flag as "Legacy Task — no traceability metadata"
+     - Proceed with traditional review (backward compatibility)
+
+6. **Verify task necessity**:
+   - Ask: "Is this task implementing a criterion that requires new code?"
+   - If ALL the task's ACs are `[SEF]` or `[EXT]`: 
+     - Flag as "Unnecessary Task — no implementation needed"
+     - This task should not exist; its 'implementation' should be moved to e2e verification
+   - If the task creates entities/structs NOT mentioned in the functional spec:
+     - Check `data-model.md` for `(derived)` marking
+     - If NOT marked `(derived)`: Flag as "Invented Entity — not in spec"
+
+7. **Check for spec contradictions**:
+   - If the implementation does something DIFFERENT from the spec:
+     - Check `decision-log.md` for a DEC entry justifying the deviation
+     - If NO DEC entry: the deviation is undocumented — flag as critical issue
+     - If DEC entry exists: reference it in the review report
+
 ---

 ## Phase 5: Code Review
@@ -209,6 +250,35 @@ If no task can be auto-detected, ask the user which task to review.

 ---

+## Phase 5.5: Architecture Boundary Review (NEW)
+
+**Goal**: Verify that the implementation does not corrupt the bounded context model
+
+**Actions**:
+
+1. **Read the implementation's file list**:
+   - From git diff or from the files listed in the task's "Files to Create/Modify"
+   - Map each file to its bounded context using `docs/specs/ontology.md`
+
+2. **Check for context pollution**:
+   - Count how many files are in the feature's PRIMARY bounded context
+   - Count how many files are in SECONDARY contexts
+   - If >30% of files are in secondary contexts:
+     - The feature is scattered — sign of tight coupling
+     - Add `architecture_issue` to review findings
+
+3. **Check for new cross-context dependencies**:
+   - If the implementation introduces an import/reference from context A to context B that didn't exist before:
+     - Flag as `new_cross_context_dependency` — requires ADR
+     - Add to review findings as `major` issue
+
+4. **Impact on review status**:
+   - `architecture_issue` does NOT automatically fail the task (the code may work)
+   - But if the issue is SEVERE (feature scattered across 3+ contexts, or undocumented cross-boundary modifications):
+     - Force `review_status: escalate` — the design is wrong, not the code
+
+---
+
 ## Phase 6: Review Report Generation

 **Goal**: Create comprehensive review report
@@ -216,14 +286,26 @@ If no task can be auto-detected, ask the user which task to review.
 **Actions**:

 1. Compile all findings into a review report
-2. Determine `review_status` using this rule:
-   - **PASSED**: ALL acceptance criteria ✅ AND ALL DoD items ✅ AND no critical/major code issues
-   - **FAILED**: ANY criterion is ❌ or ⚠️, OR ANY DoD item is ❌ or ⚠️, OR critical/major code issues found
+2. **Determine `review_status` using the Unified Status Schema**:
+   - **`passed`**: ALL acceptance criteria ✅ AND ALL DoD items ✅ AND no critical/major code issues AND no architecture issues
+   - **`needs_fix`**: ANY criterion is ❌, OR ANY DoD item is ❌, OR critical/major code issues found (fixable in this task)
+   - **`partial`**: Multi-AC task where some ACs are ✅ and others are ❌ (fixable in this task)
+   - **`escalate`**: ANY of the following (NOT fixable in this task alone):
+     - "Task Over-Specification" from Phase 4.5 (task implements `[SEF]`/`[EXT]` as `[IMP]`)
+     - "Unnecessary Task" from Phase 4.5 (all ACs are `[SEF]`/`[EXT]`)
+     - "Invented Entity" from Phase 4.5 (entity not in spec and not marked `(derived)`)
+     - Undocumented cross-boundary modification from Phase 3.6 (blocking)
+     - Severe `architecture_issue` from Phase 5.5 (feature scattered across contexts)
+     - `new_cross_context_dependency` from Phase 5.5 (undocumented inter-context coupling)
+     - Spec AC is impossible to implement as written
+     - 3+ iterations of the same issue in Ralph Loop (task-implementation signals this)
+   - **Escalation means**: The problem is at the design/spec/decomposition level, NOT the code level. Do NOT trigger Ralph Loop — go to task-implementation T-7 (Escalation Decision).
+
 3. Generate the report in markdown format with YAML frontmatter:

 ```markdown
 ---
-review_status: PASSED   # or FAILED
+review_status: passed   # or needs_fix, partial, escalate
 task_id: TASK-XXX
 task_title: [Task Title]
 spec_file: [spec-file.md]
@@ -231,13 +313,16 @@ review_date: [ISO date]
 language: [language]
 summary:
  implementation: COMPLETE|INCOMPLETE
-  acceptance_criteria: ALL_MET|FAILED
-  definition_of_done: ALL_MET|FAILED
-  spec_compliance: COMPLIANT|DEVIATIONS|NON_COMPLIANT
+  acceptance_criteria: ALL_MET|PARTIAL|FAILED
+  definition_of_done: ALL_MET|PARTIAL|FAILED
+  spec_compliance: COMPLIANT|DEVIATIONS|NON_COMPLIANT|ESCALATE
  code_review: PASSED|ISSUES|FAILED
-critical_issues: N   # required if FAILED
-major_issues: N      # required if FAILED
+  bounded_context: CLEAN|ACKNOWLEDGED_CROSSING|UNDOCUMENTED_CROSSING
+  architecture: CLEAN|POLLUTED|NEW_DEPENDENCY
+critical_issues: N   # required if needs_fix or escalate
+major_issues: N      # required if needs_fix or escalate
 minor_issues: N
+escalation_reason: [spec / architecture / planning / design / none]  # required if escalate
 ---

 # Task Review Report: TASK-XXX
@@ -254,10 +339,12 @@ minor_issues: N
 | Implementation | ✅ Complete / ⚠️ Partial / ❌ Incomplete |
 | Acceptance Criteria | ✅ All Met / ⚠️ Partial / ❌ Failed |
 | Definition of Done | ✅ All Met / ⚠️ Partial / ❌ Failed |
-| Spec Compliance | ✅ Compliant / ⚠️ Deviations / ❌ Non-compliant |
+| Spec Compliance | ✅ Compliant / ⚠️ Deviations / ❌ Non-compliant / 🚨 Escalate |
 | Code Review | ✅ Passed / ⚠️ Issues Found / ❌ Failed |
+| Bounded Context | ✅ Clean / ⚠️ Acknowledged Crossing / ❌ Undocumented Crossing |
+| Architecture | ✅ Clean / ⚠️ Polluted / 🚨 New Cross-Context Dependency |

-**Overall Result**: ✅ PASSED / ❌ FAILED
+**Overall Result**: ✅ passed / ⚠️ needs_fix / ⚠️ partial / 🚨 escalate

 ## Implementation Verification

@@ -431,9 +518,12 @@ Throughout the process, maintain a todo list like:
 [ ] Phase 1: Task Analysis
 [ ] Phase 2: Implementation Verification
 [ ] Phase 3: Acceptance Criteria Validation
+  - [ ] Step 3.6: Bounded Context Adherence Check
 [ ] Phase 4: Specification Compliance Check
+  - [ ] Step 4.5: Spec Fidelity Check
 [ ] Phase 5: Code Review
-[ ] Phase 6: Review Report Generation
+[ ] Phase 5.5: Architecture Boundary Review
+[ ] Phase 6: Review Report Generation (Unified Status Schema)
 [ ] Phase 7: Review Confirmation
 [ ] Phase 8: Summary
 ```
@@ -25,7 +25,7 @@ brainstorm → spec-to-tasks → task-tdd (RED) → task-implementation (GREEN)

 ## What This Command Does

-1. **Read Task Specification**: Parse task file to extract requirements, acceptance criteria, and technical context
+1. **Read Task Specification**: Parse task file to extract requirements, acceptance criteria, and technical context — **FILTER: only [IMP] criteria generate unit/integration tests**
 2. **Generate Test Skeleton**: Create appropriate test file structure for the specified language/framework
 3. **Write Failing Tests**: Generate test cases based on task acceptance criteria that will fail
 4. **Verify RED Phase**: Execute tests to confirm they fail as expected (RED phase confirmation)
@@ -244,7 +244,13 @@ Both workflows are valid—the TDD command is **optional** and teams can choose

 Generated tests follow these principles:

-1. **Specification-Derived**: Tests are based on task acceptance criteria, not implementation details
+1. **Specification-Derived**: Tests are based on task `[IMP]` acceptance criteria, not implementation details
+   - Read the task's `ac-mapping` frontmatter field to know which AC-IDs this task covers
+   - For each AC-ID in `ac-mapping`, check its taxonomy in the spec: `[IMP]`, `[SEF]`, or `[EXT]`
+   - **Generate unit/integration tests ONLY for `[IMP]` criteria**
+   - **`[SEF]` criteria**: Add a note in the test file — `// [SEF] AC-N: verified in e2e test (natural side effect)`
+   - **`[EXT]` criteria**: Add a note — `// [EXT] AC-N: verified externally, no automated test needed`
+   - **If the task has NO `ac-mapping`**: generate tests for ALL acceptance criteria (backward compatibility)
 2. **Failing by Design**: Tests will fail because implementation doesn't exist yet (RED phase)
 3. **Language-Appropriate**: Test structure matches framework conventions for the specified language
 4. **Readable**: Test names and assertions clearly express requirements