@tgoodington/intuition 8.1.3 → 9.2.1

package/docs/project_notes/trunk/blueprint-conflicts.md

@@ -0,0 +1,109 @@
+# Blueprint Conflict Analysis
+
+> Blueprints reviewed: devops-infrastructure.md, technical-writer.md, database-architect.md
+> Analysis date: 2026-03-05
+
+---
+
+## Summary
+
+One minor documentation inconsistency found. No contradictory decisions, no conflicting file modifications, no inconsistent interface assumptions, and no duplicated deliverables.
+
+---
+
+## 1. Contradictory Decisions
+
+None found.
+
+All three blueprints share the same rename direction (`plan`/`planning` -> `outline`/`outline`), the same KEEP/RENAME disambiguation rules (generic English preserved, phase-name references renamed), and the same task dependency ordering (T3 before T4/T5, T2 before T6, all before T8).
+
+---
+
+## 2. Overlapping File Modifications
+
+### `skills/intuition-handoff/SKILL.md` — documented overlap, not a conflict
+
+Both database-architect (T3, Sections 5.5-5.11, Edits 5-25) and technical-writer (T5, handoff section) specify renames to this file.
+
+Per the review instructions, this is NOT a conflict. The database-architect blueprint explicitly documents the overlap in Section 7 ("Cross-Blueprint Overlap") and states: "both blueprints target the same old strings and specify the same new strings." Spot-checking confirms this — e.g., both specify `planning_brief.md` -> `outline_brief.md`, `/intuition-plan` -> `/intuition-outline`, `workflow.planning.started` -> `workflow.outline.started`, `status == "planning"` -> `status == "outline"`, transition headings `PROMPT -> PLANNING` -> `PROMPT -> OUTLINE`, etc.
+
+The edits unique to each blueprint are non-overlapping:
+- database-architect owns: schema heading version bump (Edit 1), JSON version field bump (Edit 2), JSON key rename in template (Edit 3), status enum update in template (Edit 4), V7 migration handler insertion (Section 5.4).
+- technical-writer owns: no handoff-specific structural changes beyond the prose renames, which match database-architect's overlap list exactly.
+
+No other files are targeted by more than one blueprint. `scripts/install-skills.js`, `scripts/uninstall-skills.js`, and `package.json` are exclusively owned by devops-infrastructure (T6). `skills/intuition-initialize/SKILL.md` is exclusively owned by technical-writer (T4). All documentation files are exclusively owned by technical-writer (T7).
+
+---
+
+## 3. Inconsistent Interface Assumptions
+
+None found.
+
+The state field coupling is internally consistent across all three blueprints:
+
+- database-architect T3 renames the handoff's schema template and writes `workflow.outline.*` and `status: "outline"`.
+- technical-writer T4 renames the initialize template's `"planning"` key to `"outline"` (consistent target name).
+- technical-writer T5 updates the start skill's reads of `workflow.planning.*` and `status == "planning"` to `workflow.outline.*` and `status == "outline"` (consistent with what handoff will write).
+
+All three blueprints agree that the dependency chain is T3 → T4 → T5. database-architect Section 1 states "T4 and T5 depend on T3." technical-writer T4 states "Dependencies: T3."
+
+---
+
+## 4. Duplicated Work
+
+None found.
+
+Each deliverable is owned by exactly one task:
+- Audit hit list: T1 (devops-infrastructure)
+- Outline skill rename: T2 (technical-writer)
+- Handoff schema + migration handler: T3 (database-architect)
+- Initialize template update: T4 (technical-writer)
+- All other skill prose renames: T5 (technical-writer)
+- Script and package config updates: T6 (devops-infrastructure)
+- Documentation and memory renames: T7 (technical-writer)
+- Verification sweep: T8 (devops-infrastructure)
+
+---
+
+## 5. Minor Documentation Inconsistency (non-blocking)
+
+### T8 test fixture uses `workflow_pipeline` instead of `workflow`
+
+**Location**: devops-infrastructure.md, Section 5 (T8 deliverable), Phase 3 (Migration Handler Validation).
+
+The test fixture provided in the devops-infrastructure blueprint uses `workflow_pipeline` as the state field name:
+
+```json
+"active_context": {
+  "status": "planning",
+  "workflow_pipeline": {
+    "planning": { "status": "in_progress" }
+  }
+}
+```
+
+However, the actual state schema field is `workflow` (not `workflow_pipeline`), as confirmed by the database-architect blueprint's schema template (Edit 3 targets `"planning": { "started": false, ...}` within the `workflow` object) and the handoff skill's transition condition references (`workflow.planning.started`, `workflow.planning.completed`).
+
+**Impact**: The T8 verification fixture does not match the real state schema structure. When the code-writer producer implements the T8 verification, it should use the correct field name `workflow` (not `workflow_pipeline`) for the test fixture and expected output to exercise the actual migration handler correctly.
+
+**Severity**: Low. This affects only the T8 test document content, not the migration handler itself. The migration handler (specified by database-architect) correctly targets `workflow.planning`. The T8 producer should use the corrected fixture:
+
+```json
+{
+  "schema_version": "8.0",
+  "active_context": {
+    "status": "outline",
+    "workflow": {
+      "outline": { "status": "in_progress" }
+    }
+  }
+}
+```
+
+Note: the fixture also uses `schema_version` at the root level while the actual state schema uses `version` at the root level (per database-architect Edit 2 which targets `"version": "7.0"`). The T8 producer should align the fixture field names with the real schema before executing the test.
+
+---
+
+## 6. Informational: Imprecise Cross-Reference (not a conflict)
+
+devops-infrastructure Section 7 ("State Schema Integration") notes that the v7->v8 migration handler "is NOT written by T6 (devops-infrastructure). It is written by another task (likely T4 or T5)." The actual owner is T3 (database-architect), not T4 or T5. This is an imprecise guess in informational commentary only — devops-infrastructure correctly acknowledges it does not own this work. No action needed.

package/docs/project_notes/trunk/blueprints/database-architect.md

@@ -0,0 +1,416 @@
+# Database Architect Blueprint
+
+> Specialist: database-architect
+> Tasks: T3 (Handoff migration handler + schema update)
+> Decision Policy: aggressive (fully delegated)
+> Generated: 2026-03-05
+
+---
+
+## 1. Task Reference
+
+### T3: Add v7->v8 migration handler to handoff skill (Standard)
+- **Acceptance Criteria**:
+  1. Schema version is 8.0 in the handoff SKILL.md header and schema definition
+  2. v7->v8 migration handler exists and renames `planning` -> `outline` in state objects
+  3. All transition messages route to `/intuition-outline` (not `/intuition-plan`)
+  4. All file path references use `outline_brief.md`, `outline.md`
+  5. State field references use `outline` throughout
+  6. Existing v5->v6 and v6->v7 migration handlers are preserved unchanged
+- **Dependencies**: None (T3 is execution phase 1; T4 and T5 depend on T3)
+
+---
+
+## 2. Research Findings
+
+### Target File
+
+- **File**: `skills/intuition-handoff/SKILL.md` (~520 lines)
+- **Engine**: Not applicable (prose-based state schema, not a database engine). The "schema" is a JSON template embedded in a Markdown skill file that Claude reads and interprets at runtime.
+- **Naming conventions**: JSON keys use `snake_case`. Status enum values use `lowercase`. Migration handler sections use `## V{N} STATE MIGRATION` heading format. Transitions use `## TRANSITION {N}: SOURCE -> TARGET` heading format.
+
+### Reference Inventory (RF1)
+
+All 17 unique lines containing `planning`/`plan` in the handoff file are PHASE-NAME references. Zero generic English instances exist. This eliminates disambiguation concerns entirely for this file.
+
+The references break into four categories:
+
+**Category A -- Schema definition (2 lines)**
+- Line 131: Status enum includes `planning` as a valid status value
+- Line 134: `"planning": { ... }` workflow phase object key in JSON schema template
+
+**Category B -- Transition condition checks (2 lines)**
+- Line 74: `workflow.planning.started == false` (Transition 1 detection)
+- Line 77: `status == "planning" AND workflow.planning.completed == true` (Transition 2/2v9 detection)
+
+**Category C -- Transition state writes and routing (12 lines)**
+- Line 24: Critical rule mentioning `prompt->planning`
+- Line 62: Protocol step scoped to `prompt->planning only`
+- Line 208: Transition 1 heading `PROMPT -> PLANNING`
+- Line 216: `planning_brief.md` generation instruction
+- Line 218: Sets `status` to `"planning"`, `planning.started = true`, routes to `/intuition-plan`, references `planning_brief.md` (3 hits in one line)
+- Line 220: Transition 2 heading `PLANNING -> DESIGN`
+- Line 222: Reads `plan.md`, references "planning work"
+- Line 228: `planning.completed = true`
+- Line 230: Transition 2B heading `PLANNING -> ENGINEER`
+- Line 234: `planning.completed = true`
+- Line 236: Transition 2v9 heading `PLAN -> ASSEMBLE`
+- Lines 238, 242, 243, 248: Various `plan.md`, `planning` state writes in v9 transitions
+
+**Category D -- Historical migration artifacts (1 line)**
+- Line 206: V3 migration references `planning_brief.md`, `plan.md`, `.planning_research/` as files to move during v3.0 restructuring
+
+### Migration Handler Pattern (RF2)
+
+All four existing handlers follow a rigid pattern:
+
+```
+## V{N} STATE MIGRATION
+
+Fires when handoff detects `version == "{N}.0"` [optional: OR fallback condition].
+For trunk and every branch: [mutation description].
+Set `version: "{target}"`, preserve all other fields, write state.
+Report: "Migrated state from v{N}.0 to v{target}.0 ({change description})."
+Then continue with the original transition.
+```
+
+**Ordering convention**: Newer migrations appear first in the file. Current order: V5 (line 192), V6 (line 196), V4 (line 200), V3 (line 204). The V7 handler belongs BEFORE V5 (at line ~192, pushing others down).
+
+**Closest structural precedent**: V4 handler -- renames a field (`execution` -> `build`) and remaps a status value (`"executing"` -> `"building"`). T3's v7->v8 handler must rename `planning` -> `outline` and remap `"planning"` -> `"outline"` in status, making V4 the exact template.
+
+**No centralized dispatch**: Handlers are inline prose instructions, not code. Claude reads them sequentially and applies whichever matches the detected version. No registry or dispatch table to update.
+
+### State Field Coupling (RF3)
+
+The `planning` field participates in a read-write cycle across skills:
+
+- **Initialize** (T4, technical-writer): Sets the template with `"planning": {...}` for new projects
+- **Handoff** (T3, this task): Writes `planning.started`, `planning.completed`, `planning.approved`, and sets `status: "planning"`
+- **Start** (T5, technical-writer): Reads `workflow.planning.*` and `status == "planning"` for routing decisions
+
+T3 handles the handoff side. The technical-writer blueprint (T4, T5) handles initialize and start. Both use `outline` as the target name.
+
+### V3 Migration Historical Context (RF4)
+
+Line 206 references `planning_brief.md`, `plan.md`, `.planning_research/` as artifacts the V3 handler moves from `docs/project_notes/` to `docs/project_notes/trunk/`. These are historical file names from v3.0 state. The V3 handler must continue to reference the OLD names because it migrates projects that have those old-named files on disk. The v7->v8 handler does NOT need to rename files on disk -- it only renames the JSON key in the state object.
+
+### Existing Migration Handlers (exact content for preservation verification)
+
+- **V5** (line 192-193): Adds `detail` and `test` phases, migrates 5.0 -> 7.0
+- **V6** (line 196-198): Adds `test` phase, migrates 6.0 -> 7.0
+- **V4** (line 200-202): Renames `execution` -> `build`, adds `engineering`, migrates 4.0 -> 5.0
+- **V3** (line 204-206): Creates trunk directory, restructures state, migrates 3.0 -> 5.0
+
+---
+
+## 3. Approach
+
+### Schema Strategy
+
+This is a key-rename migration with status-value remapping. The JSON "schema" is a prose template embedded in SKILL.md, not a formal database schema. The migration renames the `planning` workflow key to `outline` and remaps the `"planning"` status enum value to `"outline"` across all context objects (trunk and every branch).
+
+### Migration Approach
+
+A single V7 STATE MIGRATION handler is added, following the established prose-handler pattern. It fires on `version == "7.0"` (simple trigger, no fallback condition needed since v7.0 states always have a version field). The handler:
+
+1. Renames `workflow.planning` -> `workflow.outline` in trunk and every branch
+2. Remaps `status == "planning"` -> `"outline"` in trunk and every branch
+3. Preserves all sub-fields within the renamed object (started, completed, completed_at, approved)
+4. Sets `version: "8.0"`
+5. Does NOT rename files on disk (JSON key rename only)
+
+### Scope Division with Technical-Writer Blueprint
+
+This blueprint (T3) owns:
+- Schema version bump (header + JSON template)
+- Schema key rename (`"planning"` -> `"outline"` in template)
+- Status enum update (`planning` -> `outline` in template)
+- New V7 migration handler
+- Preservation of V3/V4/V5/V6 handlers
+
+The technical-writer blueprint (T5) owns:
+- Transition heading renames
+- Routing messages (`/intuition-plan` -> `/intuition-outline`)
+- File path references (`planning_brief.md` -> `outline_brief.md`, `plan.md` -> `outline.md`)
+- State field write references (`planning.started` -> `outline.started`, etc.)
+- Critical rule/protocol step references
+
+However, plan acceptance criteria AC3-AC5 require ALL changes to be present in the final file. Since both blueprints target the same file, the build phase applies both. This blueprint specifies ALL changes needed for T3's acceptance criteria, plus documents the overlap where the technical-writer blueprint specifies the same edits independently.
+
+### Indexing / Performance
+
+Not applicable. There are no database indexes. The state file is a single JSON document read and written in full on each handoff transition.
+
+---
+
+## 4. Decisions Made
+
+### D1: V3 migration handler -- preserve historical artifact references
+- **Tier**: [SILENT]
+- **Chosen**: Preserve V3 handler exactly as-is
+- **Alternatives considered**: (A) Preserve as-is. (B) Update V3 references to use new names.
+- **Why A**: V3 handler moves files that exist on disk with old names in v3.0 projects. Renaming would break migration of legacy projects. AC6 explicitly requires preserving existing handlers unchanged.
+- **Source**: RF4 (Stage 1 research on V3 handler purpose)
+
+### D2: Status value remapping scope
+- **Tier**: [SILENT]
+- **Chosen**: Remap status `"planning"` -> `"outline"` for trunk and all branches
+- **Alternatives considered**: (A) Remap in all contexts. (B) Remap only in trunk.
+- **Why A**: Status field and workflow key are tightly coupled in transition detection (RF3). Leaving branch statuses un-remapped would break transition detection for any branch in the `"planning"` state at migration time.
+- **Source**: RF3 (state field coupling analysis), V4 handler precedent ("For trunk and every branch")
+
+### D3: Migration trigger condition
+- **Tier**: [SILENT]
+- **Chosen**: Simple trigger: `version == "7.0"` only
+- **Alternatives considered**: (A) Simple trigger. (B) Compound trigger with fallback detection (e.g., OR `planning` key exists but no `outline` key).
+- **Why A**: V7.0 states always have a version field (added in V3 migration). Fallback adds complexity without benefit. All four existing handlers use simple version checks (V4 is the only one with a fallback, and only because it predates reliable version tagging).
+- **Source**: RF2 (migration handler pattern analysis)
+
+---
+
+## 5. Deliverable Specification
+
+### 5.1 Schema Version Bump
+
+**Location**: Line 121 (section heading) and line 128 (JSON template)
+
+**Edit 1 -- Section heading**:
+- Old: `## STATE SCHEMA (v7.0)`
+- New: `## STATE SCHEMA (v8.0)`
+
+**Edit 2 -- Version field in JSON template**:
+- Old: `"version": "7.0",`
+- New: `"version": "8.0",`
+
+### 5.2 Schema Key Rename
+
+**Location**: Line 134 (JSON template, workflow object)
+
+**Edit 3 -- Workflow phase key**:
+- Old: `"planning": { "started": false, "completed": false, "completed_at": null, "approved": false },`
+- New: `"outline": { "started": false, "completed": false, "completed_at": null, "approved": false },`
+
+All four sub-fields (started, completed, completed_at, approved) are preserved exactly. Only the key name changes.
+
+### 5.3 Status Enum Update
+
+**Location**: Line 131 (status enum in JSON template)
+
+**Edit 4 -- Status enum value**:
+- Old: `"status": "none | prompt | planning | design | engineering | building | testing | detail | complete",`
+- New: `"status": "none | prompt | outline | design | engineering | building | testing | detail | complete",`
+
+### 5.4 New V7 Migration Handler
+
+**Location**: Insert immediately BEFORE the V5 handler (currently at line 192). The new section goes between the end of Transition 0 (line 191) and the current V5 handler.
+
+**New content to insert**:
+
+```markdown
+## V7 STATE MIGRATION
+
+Fires when handoff detects `version == "7.0"`. For trunk and every branch: rename the `planning` key to `outline` in the `workflow` object (preserving all sub-fields: started, completed, completed_at, approved), and change any `status == "planning"` to `"outline"`. Set `version: "8.0"`, preserve all other fields, write state. Report: "Migrated state from v7.0 to v8.0 (renamed planning → outline)." Then continue with the original transition.
+```
+
+**Structural notes**:
+- Follows the exact pattern established by V4 (field rename + status remap)
+- Single paragraph, consistent with V5/V6 handler format
+- "For trunk and every branch" matches the universal scope phrase used by all handlers
+- Explicitly lists all four sub-fields to preserve, preventing accidental data loss (Risk 3 mitigation)
+
+### 5.5 Transition Condition Updates (T3 scope: state field paths)
+
+These edits change the state field paths read during transition detection. They overlap with the technical-writer blueprint (T5 for handoff), but are required for T3's acceptance criteria AC5 ("State field references use `outline` throughout").
+
+**Edit 5 -- Transition 1 detection** (line 74):
+- Old: `workflow.planning.started == false`
+- New: `workflow.outline.started == false`
+
+**Edit 6 -- Transition 2/2v9 detection** (line 77):
+- Old: `status == "planning" AND workflow.planning.completed == true`
+- New: `status == "outline" AND workflow.outline.completed == true`
+
+### 5.6 Transition State Write Updates (T3 scope: state writes)
+
+**Edit 7 -- Transition 1 state write** (line 218):
+- Old: `set status to "planning"`, `planning.started = true`
+- New: `set status to "outline"`, `outline.started = true`
+
+**Edit 8 -- Transition 2 state write** (line 228):
+- Old: `planning.completed = true`
+- New: `outline.completed = true`
+
+**Edit 9 -- Transition 2B state write** (line 234):
+- Old: `planning.completed = true`
+- New: `outline.completed = true`
+
+**Edit 10 -- Transition 2v9 state write** (line 243):
+- Old: `status to "planning"`, `planning.completed = true`, `approved = true`
+- New: `status to "outline"`, `outline.completed = true`, `approved = true`
+
+### 5.7 Transition Heading Updates (overlap with T5)
+
+These are documented for completeness. The technical-writer blueprint specifies identical changes.
+
+**Edit 11** (line 208): `PROMPT -> PLANNING` to `PROMPT -> OUTLINE`
+
+**Edit 12** (line 220): `PLANNING -> DESIGN` to `OUTLINE -> DESIGN`
+
+**Edit 13** (line 230): `PLANNING -> ENGINEER` to `OUTLINE -> ENGINEER`
+
+**Edit 14** (line 236): `PLAN -> ASSEMBLE` to `OUTLINE -> ASSEMBLE`
+
+### 5.8 Routing Message Updates (overlap with T5)
+
+**Edit 15** (line 218): `/intuition-plan` to `/intuition-outline`
+
+### 5.9 File Path Reference Updates (overlap with T5)
+
+**Edit 16** (line 216): `planning_brief.md` to `outline_brief.md`
+
+**Edit 17** (line 218): `planning_brief.md` to `outline_brief.md` (second occurrence on same line)
+
+**Edit 18** (line 222): `plan.md` to `outline.md`
+
+**Edit 19** (line 243): `plan.md` to `outline.md` (Transition 2v9 reference)
+
+### 5.10 Critical Rule and Protocol Updates (overlap with T5)
+
+**Edit 20** (line 24): `prompt→planning` to `prompt→outline`
+
+**Edit 21** (line 62): `prompt→planning only` to `prompt→outline only`
+
+### 5.11 Additional Prose References (overlap with T5)
+
+**Edit 22** (line 48): `plan.md` to `outline.md` (mode detection)
+
+**Edit 23** (line 84): `Planning → Design` to `Outline → Design` and `Planning → Engineer` to `Outline → Engineer`
+
+**Edit 24** (line 238): `planning completes` to `outline completes` (Transition 2v9 description)
+
+**Edit 25** (line 505): `v9 plan detected` to `v9 outline detected` (edge case)
+
+### 5.12 Preservation Requirements
+
+The following MUST NOT be modified:
+
+1. **V3 migration handler** (lines 204-206): References `planning_brief.md`, `plan.md`, `.planning_research/` as historical file names for v3.0 disk artifacts. These are correct as-is.
+2. **V4 migration handler** (lines 200-202): References `execution` -> `build` rename. Unrelated to T3.
+3. **V5 migration handler** (lines 192-194): Adds `detail` and `test` phases. Unrelated to T3.
+4. **V6 migration handler** (lines 196-198): Adds `test` phase. Unrelated to T3.
+5. **Branch entry schema** (line 150): Text references "identical to trunk's workflow structure" -- this is generic and does not name `planning` explicitly.
+6. **All content outside the specific edit targets listed above**.
+
+---
+
+## 6. Acceptance Mapping
+
+| Acceptance Criterion | Satisfied By |
+|---------------------|-------------|
+| AC1: Schema version is 8.0 in header and definition | Edit 1 (heading v7.0 -> v8.0) + Edit 2 (JSON version field v7.0 -> v8.0) |
+| AC2: v7->v8 migration handler exists and renames planning -> outline | Section 5.4: New V7 STATE MIGRATION handler inserted before V5, fires on version=="7.0", renames workflow key + status value, sets version to 8.0 |
+| AC3: All transition messages route to /intuition-outline | Edit 15 (line 218 routing). Additional routing references on other lines are covered by the technical-writer blueprint (T5) applying to the same file. |
+| AC4: All file path references use outline_brief.md, outline.md | Edits 16-19 (planning_brief.md -> outline_brief.md, plan.md -> outline.md). V3 handler's historical references are correctly excluded per D1. |
+| AC5: State field references use outline throughout | Edits 3-10 (schema key, status enum, transition conditions, state writes). All `planning.*` field paths and `status == "planning"` values updated to `outline`. |
+| AC6: Existing v5->v6 and v6->v7 handlers preserved unchanged | Section 5.12 preservation requirements. V3, V4, V5, V6 handlers are explicitly excluded from all edits. |
+
+---
+
+## 7. Integration Points
+
+### Files Modified
+
+| File | Absolute Path | Change Summary |
+|------|--------------|---------------|
+| Handoff skill | `skills/intuition-handoff/SKILL.md` | Schema version bump (2 edits), key rename (1 edit), status enum update (1 edit), new V7 migration handler (1 insertion), transition condition updates (2 edits), state write updates (4 edits), transition heading updates (4 edits), routing update (1 edit), file path updates (4 edits), critical rule updates (2 edits), prose reference updates (4 edits). Total: ~25 distinct edit operations. |
+
+### Field Name Coupling
+
+| Old Field/Value | New Field/Value | Writer (this blueprint) | Readers (other blueprints) |
+|----------------|----------------|------------------------|---------------------------|
+| `workflow.planning` (JSON key) | `workflow.outline` | Handoff schema template (Edit 3) | Initialize template (T4, technical-writer), Start skill (T5, technical-writer) |
+| `status: "planning"` (enum value) | `status: "outline"` | Handoff schema template (Edit 4), transition writes (Edits 7, 10) | Start skill (T5, technical-writer) |
+| `planning.started` | `outline.started` | Transition 1 write (Edit 7) | Start skill routing check (T5, technical-writer) |
+| `planning.completed` | `outline.completed` | Transition 2/2B/2v9 writes (Edits 8-10) | Start skill routing check (T5, technical-writer) |
+| `planning.approved` | `outline.approved` | (written by handoff at transition time) | Start skill (T5, technical-writer) |
+
+### Cross-Blueprint Overlap
+
+The technical-writer blueprint (T5) specifies 48 renames in `skills/intuition-handoff/SKILL.md`. This blueprint specifies ~25 edits to the same file. The overlapping edits produce identical results -- both blueprints target the same old strings and specify the same new strings. The build phase can apply either blueprint's edits first; the second will find its targets already renamed and can skip those specific edits.
+
+**Non-overlapping edits unique to this blueprint**:
+- Schema version heading bump (Edit 1)
+- Schema JSON version field bump (Edit 2)
+- Schema JSON key rename (Edit 3)
+- Status enum update in template (Edit 4)
+- V7 migration handler insertion (Section 5.4)
+
+**Non-overlapping edits unique to technical-writer blueprint**:
+- Mode detection prose (line 49-50 references to "Detail Assessment" / "Design Recommendations" -- no `planning` references)
+- Branch creation section (line 187 mentions `engineering`, `build`, `test`, `detail` but not `planning`)
+- Edge case prose updates beyond line 505
+
+---
+
+## 8. Open Items
+
+| ID | Type | Description |
+|----|------|-------------|
+| V1 | [VERIFY] | At build time, confirm exact line numbers have not shifted due to prior edits. Use content matching (exact old-string search), not line numbers, for all edit operations. |
+| V2 | [VERIFY] | After applying edits and inserting the V7 handler, verify that V3/V4/V5/V6 handlers are byte-identical to their pre-edit content. Read each handler section and confirm no accidental modification. |
+
+No unresolved design questions remain. All decisions recorded in Section 4.
+
+---
+
+## 9. Producer Handoff
+
+### Producer Assignment
+
+- **Producer**: code-writer
+- **Output format**: Direct file edits to a single Markdown file
+- **Filename**: `skills/intuition-handoff/SKILL.md`
+- **Target edit count**: ~25 distinct edit operations (content replacements + 1 section insertion)
+- **Instruction tone**: Precise and mechanical. Each edit is an exact string replacement or a block insertion at a known location. Use content matching to locate edit targets, not line numbers. Apply edits in the order specified. After all edits, verify preservation of all four existing migration handlers.
+
+### Execution Order
+
+Apply edits in this order to avoid partial-match interference:
+
+**Phase 1 -- Schema updates (Edits 1-4)**
+1. Replace `## STATE SCHEMA (v7.0)` with `## STATE SCHEMA (v8.0)` (heading)
+2. Replace `"version": "7.0"` with `"version": "8.0"` in the JSON template block (not in migration handlers)
+3. Replace `"planning": { "started": false` with `"outline": { "started": false` in the JSON template block
+4. Replace `planning` with `outline` in the status enum line (the `"status": "none | prompt | planning |...` line)
+
+**Phase 2 -- Migration handler insertion (Section 5.4)**
+5. Locate `## V5 STATE MIGRATION` and insert the V7 handler block immediately before it, with a blank line separator
+
+**Phase 3 -- Transition condition and state write updates (Edits 5-10)**
+6. In the transition detection block: replace `workflow.planning.started` with `workflow.outline.started`
+7. In the transition detection block: replace `status == "planning" AND workflow.planning.completed` with `status == "outline" AND workflow.outline.completed`
+8. In Transition 1 state write: replace `"planning"` status and `planning.started` with `"outline"` and `outline.started`
+9. In Transition 2 state write: replace `planning.completed` with `outline.completed`
+10. In Transition 2B state write: replace `planning.completed` with `outline.completed`
+11. In Transition 2v9 state write: replace `"planning"` status and `planning.completed` with `"outline"` and `outline.completed`
+
+**Phase 4 -- Remaining renames (Edits 11-25, overlap with T5)**
+12. Replace transition headings: `PROMPT -> PLANNING` to `PROMPT -> OUTLINE`, `PLANNING -> DESIGN` to `OUTLINE -> DESIGN`, `PLANNING -> ENGINEER` to `OUTLINE -> ENGINEER`, `PLAN -> ASSEMBLE` to `OUTLINE -> ASSEMBLE`
+13. Replace routing: `/intuition-plan` to `/intuition-outline` (all instances)
+14. Replace file paths: `planning_brief.md` to `outline_brief.md` (all instances EXCEPT in V3 migration handler), `plan.md` to `outline.md` (all instances EXCEPT in V3 migration handler)
+15. Replace critical rules: `prompt→planning` to `prompt→outline` (lines 24, 62)
+16. Replace remaining prose: `planning completes` to `outline completes`, `v9 plan detected` to `v9 outline detected`, `Planning →` to `Outline →` in transition detection block
+
+**Phase 5 -- Verification**
+17. Read the V3 migration handler section and confirm it still references `planning_brief.md`, `plan.md`, `.planning_research/` (unchanged)
+18. Read the V4, V5, V6 migration handler sections and confirm they are unchanged
+19. Confirm the new V7 handler appears before V5 and after Transition 0
+20. Search the file for any remaining `"planning"` (as JSON key or status value) outside the V3 handler -- should find zero
+
+### Content Block: V7 Migration Handler (for insertion)
+
+```markdown
+## V7 STATE MIGRATION
+
+Fires when handoff detects `version == "7.0"`. For trunk and every branch: rename the `planning` key to `outline` in the `workflow` object (preserving all sub-fields: started, completed, completed_at, approved), and change any `status == "planning"` to `"outline"`. Set `version: "8.0"`, preserve all other fields, write state. Report: "Migrated state from v7.0 to v8.0 (renamed planning → outline)." Then continue with the original transition.
+```