@tgoodington/intuition 8.1.3 → 9.2.1

package/docs/project_notes/trunk/planning_brief.md

@@ -0,0 +1,96 @@
+# Planning Brief: Rename Plan Phase to Outline
+
+## Discovery Summary
+
+The `intuition-plan` skill and all "planning" phase references throughout the Intuition framework need to be renamed to `intuition-outline` / "outlining." This is a pure rename refactor — behavior stays identical. The rename touches: the skill folder, every other skill's SKILL.md that routes to or mentions the plan phase, the state schema (`planning` field → `outlining`), the handoff migration handler, the initialize template, install/uninstall scripts, package.json, MEMORY.md, and likely some docs.
+
+A v7→v8 state migration handler is required so existing `.project-memory-state.json` files from prior projects automatically rename the `planning` field to `outlining` when handoff next runs.
+
+**Standing directive (no judgment calls needed):** Every place where "plan" refers to the workflow phase name becomes "outline." Generic English uses of "plan" (e.g., "research plan," "action plan," "planning research") are NOT renamed.
+
+## Problem Statement
+
+The planning phase skill is named `intuition-plan` but should be called `intuition-outline`. Every reference to "plan" as a phase name across the entire framework needs to become "outline" while keeping behavior identical.
+
+## Goals & Success Criteria
+
+1. `grep -r "intuition-plan" skills/` returns zero results
+2. `grep -r '"planning"' docs/project_notes/.project-memory-state.json` returns zero results after migration
+3. `/intuition-outline` invokes correctly from the CLI
+4. Handoff correctly routes to "Run `/clear` then `/intuition-outline`" in all transition messages
+5. `intuition-start` correctly detects the outline phase and routes to `/intuition-outline`
+6. v7→v8 migration runs cleanly on a v7.0 state file and produces a v8.0 file with `outlining` field
+7. No skill behavioral changes — output quality and logic unchanged
+
+## Key Constraints
+
+- State schema must bump to v8.0 (not v7.1 or v8.1)
+- Migration handler must follow the exact same pattern as v5→v6 and v6→v7 handlers in handoff
+- Handoff is the ONLY skill that writes state — migration must live there
+- Generic English "plan" must not be touched (this will require careful grep filtering)
+- Package must continue to install and deploy correctly post-rename
+
+## Architectural Context
+
+### Files almost certainly requiring changes
+
+**Skill folders and SKILL.md files:**
+- `skills/intuition-plan/` → rename folder to `skills/intuition-outline/`
+- `skills/intuition-plan/SKILL.md` → update all internal self-references from "plan" to "outline"
+- `skills/intuition-handoff/SKILL.md` → multiple transition references to "plan", route messages like "Run `/intuition-plan`", state field references (`planning`), migration handlers, mode detection, schema definition
+- `skills/intuition-start/SKILL.md` → routing to plan phase, phase detection
+- `skills/intuition-prompt/SKILL.md` → route message "Run `/intuition-plan`"
+- `skills/intuition-assemble/SKILL.md` → references to plan output, planning brief
+- `skills/intuition-detail/SKILL.md` → references to plan, planning context
+- `skills/intuition-build/SKILL.md` → references to plan, planning brief
+- `skills/intuition-test/SKILL.md` → references to plan
+- `skills/intuition-design/SKILL.md` → [v8 compat] references to plan phase
+- `skills/intuition-engineer/SKILL.md` → [v8 compat] references to plan phase
+- `skills/intuition-debugger/SKILL.md` → may reference plan phase
+- `skills/intuition-initialize/SKILL.md` → state schema template has `planning` field
+
+**Scripts and config:**
+- `scripts/install-skills.js` → skill list and directory names
+- `scripts/uninstall-skills.js` (if exists) → skill list
+- `package.json` → skill name in scripts/description/skill list
+
+**Memory and docs:**
+- `memory/MEMORY.md` → extensive references to "plan" phase, `planning` field, workflow descriptions
+- `docs/v9/` design documents — investigate whether to update or leave as historical
+
+**Output file naming (within intuition-outline/intuition-plan skill):**
+- The skill currently writes `plan.md` and `plan_output.json`; these should become `outline.md` and `outline_output.json`
+- Any skill that reads `plan.md` as its input must be updated to read `outline.md`
+
+### Key disambiguation rule for planning
+
+When grepping for "plan," distinguish:
+- **Phase-name**: `/intuition-plan`, `intuition-plan`, `planning phase`, `"planning"` (JSON key), `planning_brief.md`, `plan.md`, `planning.completed`, `planning.started`, `Run /intuition-plan`, `planning: {`, `status == "planning"`, `status: "planning"` — ALL become "outline" variants
+- **Generic English**: "research plan," "research planning," "action plan," "plan of action," "planning context," "planning research," "ARCH planning," "capacity planning" — DO NOT rename
+
+## Assumptions & Risks
+
+| Assumption | Confidence | Risk if Wrong |
+|-----------|-----------|---------------|
+| `planning` is the only state field that needs renaming | High | Miss a field, state breaks |
+| No external consumers depend on skill naming (self-contained npm package) | High | Breaking change for users |
+| v8 compat skills (design, engineer) reference the plan phase in routing messages | Medium | Miss references if they don't |
+| Specialist/producer profiles do NOT reference the plan phase | Medium | Miss references; low impact |
+| docs/v9/ design docs CAN be updated without historical concern | Medium | May want to treat as immutable records |
+
+## Recommended Approach
+
+This is a systematic search-and-replace job. The planning phase should:
+
+1. **Audit first**: Run comprehensive grep across the entire codebase to enumerate every file and line containing "plan" in a phase-name context. Produce a complete hit list.
+2. **Group by file**: Organize the hit list by file to understand the blast radius per file before proposing tasks.
+3. **Task per file or per logical group**: Each SKILL.md file is a separate task. Scripts together. Docs together. State migration is its own task (most complex).
+4. **Migration handler task**: The v7→v8 handler in handoff is the most structurally significant change — should be its own task with clear before/after state schema.
+5. **Verification task**: Final grep to confirm zero stale references + functional test of routing.
+
+## References
+
+- `docs/project_notes/trunk/prompt_brief.md` — full brief with scope, constraints, decision posture
+- `docs/project_notes/trunk/prompt_output.json` — structured output
+- `docs/project_notes/decisions.md` — ADR-P001
+- `docs/project_notes/key_facts.md` — rename directive and project facts

package/docs/project_notes/trunk/prompt_brief.md

@@ -0,0 +1,60 @@
+# Prompt Brief: Rename Plan Phase to Outline
+
+## Problem Statement
+The planning phase skill is named `intuition-plan` but should be called `intuition-outline`. Every reference to "plan" as a phase name across the entire framework — skill files, state schema, handoff routing, install scripts, docs, and memory — needs to become "outline." The phase behavior stays identical; this is a pure rename refactor.
+
+## Commander's Intent
+**Desired end state:** A user invokes `/intuition-outline`, sees "outline" in all handoff messages, state tracking, and documentation — with no trace of "plan" as a phase name anywhere in the framework.
+**Non-negotiables:** Complete consistency (no stale "plan" references as a phase name), functional routing still works end-to-end.
+**Boundaries:** Pure rename — no behavioral changes to the phase itself. Generic English uses of "plan" (e.g., "research plan") are not touched.
+
+## Success Criteria
+- Grep for "plan" as a phase name returns zero hits across all skill files, state schema, install script, and docs (excluding generic English usage)
+- `/intuition-outline` invokes correctly and handoff routes to/from it
+- State schema migrates cleanly from v7 to v8 (renaming `planning` → `outlining`)
+- Output files renamed from `plan.md` / `plan_output.json` to `outline.md` / `outline_output.json`
+
+## Scope
+**In scope:**
+- Skill folder rename (`intuition-plan` → `intuition-outline`)
+- SKILL.md content updates within the renamed skill
+- All other skills' references to "plan" as a phase (handoff, start, prompt, detail, build, test, assemble, engineer, design, debugger, etc.)
+- State schema field rename (`planning` → `outlining`) + v7→v8 migration handler in handoff
+- Initialize skill template (v8.0 state schema)
+- Install/uninstall scripts
+- MEMORY.md and any docs referencing the plan phase
+- package.json if it references the plan skill
+- Output file naming (`plan.md` → `outline.md`, `plan_output.json` → `outline_output.json`)
+
+**Out of scope:**
+- Behavioral changes to the outline phase
+- Changes to v8 compat skills (design, engineer) beyond updating their references to the phase name
+- Generic English uses of "plan" that don't refer to this specific workflow phase
+
+## Constraints
+- Must add v7→v8 state migration handler in handoff (following pattern of existing v5→v6 and v6→v7 handlers)
+- Must follow existing naming conventions (`/intuition-outline`)
+- State schema version bumps to 8.0
+- Standing directive: everywhere "plan" referred to this phase, it becomes "outline" — no exceptions, no judgment calls needed
+
+## Key Assumptions
+| Assumption | Confidence | Basis |
+|-----------|-----------|-------|
+| `planning` is the only state field that needs renaming | High | State schema has one plan-phase field with sub-fields (started, completed, approved) |
+| No external consumers depend on the "plan" naming | High | Self-contained npm package |
+| v8 compat skills (design, engineer) reference the plan phase in routing/deprecation messages | Medium | Likely mention "planning phase" in deprecated notices |
+| Output files are currently named `plan.md` and `plan_output.json` | High | Convention matches other skills (prompt_brief.md, prompt_output.json) |
+
+## Open Questions for Planning
+- Exact list of files referencing "plan" as a phase (planning phase should grep comprehensively)
+- Whether any specialist profiles or producer profiles reference the plan phase
+- Whether docs/v9/ design documents need updating or are treated as historical records
+
+## Decision Posture
+| Area | Posture | Notes |
+|------|---------|-------|
+| State field naming | Team handles | `planning` → `outlining` (consistent with plan → outline) |
+| Output file naming | Team handles | `plan.md` → `outline.md`, `plan_output.json` → `outline_output.json` |
+| Migration handler design | Team handles | Follow existing v6→v7 pattern |
+| Reference disambiguation | Team handles | Phase references become "outline"; generic English "plan" stays |
+| All other decisions | Team handles | Standing directive: plan → outline everywhere it refers to this phase |

package/docs/project_notes/trunk/prompt_output.json

@@ -0,0 +1,98 @@
+{
+  "summary": {
+    "title": "Rename Plan Phase to Outline",
+    "one_liner": "Rename the plan skill to outline and update all references across the framework",
+    "problem_statement": "The planning phase skill is named intuition-plan but should be called intuition-outline. Every reference to 'plan' as a phase name across the entire framework needs to become 'outline' while keeping behavior identical.",
+    "success_criteria": "Zero stale 'plan' phase references via grep, /intuition-outline invokes and routes correctly, state schema migrates v7→v8 cleanly"
+  },
+  "commander_intent": {
+    "desired_end_state": "A user invokes /intuition-outline, sees 'outline' in all handoff messages, state tracking, and documentation — with no trace of 'plan' as a phase name anywhere in the framework",
+    "non_negotiables": [
+      "Complete consistency — no stale 'plan' references as a phase name",
+      "Functional routing still works end-to-end"
+    ],
+    "boundaries": [
+      "Pure rename — no behavioral changes to the phase itself",
+      "Generic English uses of 'plan' (e.g., 'research plan') are not touched"
+    ]
+  },
+  "scope": {
+    "in": [
+      "Skill folder rename (intuition-plan → intuition-outline)",
+      "SKILL.md content updates within the renamed skill",
+      "All other skills' references to 'plan' as a phase",
+      "State schema field rename (planning → outlining) + v7→v8 migration handler",
+      "Initialize skill template (v8.0 state schema)",
+      "Install/uninstall scripts",
+      "MEMORY.md and docs referencing the plan phase",
+      "package.json skill references",
+      "Output file naming (plan.md → outline.md, plan_output.json → outline_output.json)"
+    ],
+    "out": [
+      "Behavioral changes to the outline phase",
+      "Changes to v8 compat skills beyond updating phase name references",
+      "Generic English uses of 'plan' that don't refer to this workflow phase"
+    ]
+  },
+  "constraints": [
+    "Must add v7→v8 state migration handler in handoff",
+    "Must follow existing naming conventions (/intuition-outline)",
+    "State schema version bumps to 8.0",
+    "Standing directive: plan → outline everywhere it refers to this phase"
+  ],
+  "assumptions": [
+    {
+      "assumption": "'planning' is the only state field that needs renaming",
+      "confidence": "high",
+      "basis": "State schema has one plan-phase field with sub-fields"
+    },
+    {
+      "assumption": "No external consumers depend on the 'plan' naming",
+      "confidence": "high",
+      "basis": "Self-contained npm package"
+    },
+    {
+      "assumption": "v8 compat skills reference the plan phase in routing/deprecation messages",
+      "confidence": "medium",
+      "basis": "Likely mention 'planning phase' in deprecated notices"
+    },
+    {
+      "assumption": "Output files are currently named plan.md and plan_output.json",
+      "confidence": "high",
+      "basis": "Convention matches other skill output naming patterns"
+    }
+  ],
+  "decision_posture": [
+    {
+      "area": "State field naming",
+      "posture": "team_handles",
+      "notes": "planning → outlining"
+    },
+    {
+      "area": "Output file naming",
+      "posture": "team_handles",
+      "notes": "plan.md → outline.md, plan_output.json → outline_output.json"
+    },
+    {
+      "area": "Migration handler design",
+      "posture": "team_handles",
+      "notes": "Follow existing v6→v7 pattern"
+    },
+    {
+      "area": "Reference disambiguation",
+      "posture": "team_handles",
+      "notes": "Phase references become outline; generic English 'plan' stays"
+    },
+    {
+      "area": "All other decisions",
+      "posture": "team_handles",
+      "notes": "Standing directive: plan → outline everywhere it refers to this phase"
+    }
+  ],
+  "research_performed": [],
+  "open_questions": [
+    "Exact list of files referencing 'plan' as a phase (outline phase should grep comprehensively)",
+    "Whether specialist or producer profiles reference the plan phase",
+    "Whether docs/v9/ design documents need updating or are treated as historical records"
+  ]
+}

package/docs/project_notes/trunk/scratch/database-architect-decisions.json

@@ -0,0 +1,72 @@
+{
+  "specialist": "database-architect",
+  "gate_started": "2026-03-05T00:00:00.000Z",
+  "gate_completed": "2026-03-05T00:00:01.000Z",
+  "decision_policy": "aggressive",
+  "assumptions": [
+    {
+      "id": "A1",
+      "title": "V3 migration historical file references preserved",
+      "status": "accepted",
+      "user_override": null,
+      "default": "Keep planning_brief.md, plan.md, .planning_research/ in V3 handler as-is",
+      "rationale": "V3 handler moves files that exist on disk with those names in v3.0 projects"
+    },
+    {
+      "id": "A2",
+      "title": "Transition 2v9 status value renames to outline",
+      "status": "accepted",
+      "user_override": null,
+      "default": "Transition 2v9 sets status to 'outline' after rename",
+      "rationale": "Status value represents the phase being renamed, not generic English"
+    },
+    {
+      "id": "A3",
+      "title": "Migration handler is JSON-only, no disk file renames",
+      "status": "accepted",
+      "user_override": null,
+      "default": "v7->v8 handler renames workflow.planning -> workflow.outline in JSON only",
+      "rationale": "File renames on disk handled by other tasks (T6 scripts)"
+    },
+    {
+      "id": "A4",
+      "title": "Newest-first migration handler placement",
+      "status": "accepted",
+      "user_override": null,
+      "default": "V7 handler inserted before V5 (line 192)",
+      "rationale": "Follows existing convention: newer migrations appear first in file"
+    }
+  ],
+  "decisions": [
+    {
+      "id": "D1",
+      "title": "V3 migration handler — preserve historical artifact references",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "V3 handler references planning_brief.md, plan.md, .planning_research/ as files to move during v3.0 restructuring",
+      "options": ["Preserve V3 handler exactly as-is", "Rename historical references to new names"],
+      "chosen": "Preserve V3 handler exactly as-is",
+      "user_input": null
+    },
+    {
+      "id": "D2",
+      "title": "Status value remapping scope in migration handler",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "Status field and workflow key are tightly coupled in transition detection",
+      "options": ["Remap status 'planning' -> 'outline' for trunk and all branches", "Only rename workflow key, leave status untouched"],
+      "chosen": "Remap status 'planning' -> 'outline' for trunk and all branches",
+      "user_input": null
+    },
+    {
+      "id": "D3",
+      "title": "Migration trigger condition — simple vs fallback",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "V4 has a fallback trigger but v7.0 states always have a version field",
+      "options": ["Simple trigger: version == '7.0' only", "Add fallback: version == '7.0' OR planning key exists without outline key"],
+      "chosen": "Simple trigger: version == '7.0' only",
+      "user_input": null
+    }
+  ]
+}

package/docs/project_notes/trunk/scratch/database-architect-research-plan.md

@@ -0,0 +1,10 @@
+## Research Plan
+
+### R1: Complete inventory of phase-name `planning`/`plan` references in handoff SKILL.md with line numbers and disambiguation classification
+Scan the full handoff SKILL.md for every occurrence of `planning`, `plan`, `/intuition-plan`, `planning_brief.md`, `plan.md`, `.planning_research/`, and the `"planning"` JSON key. For each hit, record the line number, the surrounding context (5 lines), and classify it as either PHASE-NAME (must rename to `outline`/`outline_brief.md`/`outline.md`/`.outline_research/`/`/intuition-outline`) or GENERIC-ENGLISH (must keep as-is). Known generic patterns to preserve: "research plan" (as in "research plan items"), "ARCH planning" (methodology name), "planning context" when meaning general context rather than the phase. The V3 migration handler (line 206) references `planning_brief.md` and `.planning_research/` as historical file paths that were moved -- these must ALSO be renamed because they describe actual phase artifacts. This inventory is the foundation for all edits in T3.
+
+### R2: Existing migration handler pattern analysis -- trigger, body, report, and ordering conventions
+Examine the four existing migration handlers (V3 at line 204, V4 at line 200, V5 at line 192, V6 at line 196) to extract the exact structural pattern the V7->V8 handler must follow: (a) section heading format (`## VN STATE MIGRATION`), (b) trigger condition format ("Fires when handoff detects `version == X`"), (c) body structure (for trunk and every branch: [mutation]. Set `version: "Y"`, preserve all other fields, write state), (d) report message format, (e) closing sentence ("Then continue with the original transition."), (f) placement order relative to other handlers. Also check whether there's any detection/dispatch code that lists migration versions -- if so, V7 must be added there. Note: V5 handler jumps directly to 7.0 (skips 6.0), so confirm whether the V7->V8 handler should also be placed before or after V6 in the file.
+
+### R3: State field `planning` usage in workflow status values and transition condition checks
+Map every place in handoff SKILL.md where `workflow.planning` is used in conditional logic (e.g., `workflow.planning.started`, `workflow.planning.completed`, `planning.approved`) and where `status == "planning"` appears. These are the critical structural references that must change to `workflow.outline` and `status == "outline"` respectively. Also check the status enum on line 131 (`"none | prompt | planning | design | engineering | building | testing | detail | complete"`) -- this must change to include `outline` instead of `planning`. Additionally, check Transition 2v9 (line 243) which sets `status` to `"planning"` even though it's a v9 transition -- confirm this is intentional and must also change.

package/docs/project_notes/trunk/scratch/database-architect-stage1.md

@@ -0,0 +1,226 @@
+# Database Architect — Stage 1 Analysis (T3)
+
+## Research Findings
+
+### RF1: Complete reference inventory in handoff SKILL.md
+
+All `planning`/`plan` references in the handoff file are PHASE-NAME references. Zero generic English instances exist. This eliminates the disambiguation challenge entirely for this file.
+
+The 17 unique lines 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 in the 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 phase-name 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`
+- Line 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 restructuring
+
+### RF2: Migration handler pattern (structural template)
+
+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 should be placed BEFORE V5 (at line ~192, pushing others down).
+
+**Closest precedent**: V4 handler — it 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 structural 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.
+
+### RF3: State field coupling analysis
+
+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 must use `outline` consistently.
+
+### RF4: V3 migration historical artifact question
+
+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 (`planning_brief.md`, etc.) 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.
+
+## ECD Analysis
+
+### Elements (State Schema Components)
+
+1. **Schema version header** (line 121-128): `## STATE SCHEMA (v7.0)` heading + `"version": "7.0"` in JSON — both must bump to 8.0
+2. **Workflow phase object key** (line 134): `"planning": { "started": false, "completed": false, "completed_at": null, "approved": false }` — key renames to `"outline"`
+3. **Status enum** (line 131): `planning` value in the pipe-delimited list — renames to `outline`
+4. **V7 migration handler**: New section to add — renames `planning` -> `outline` in workflow objects for trunk and all branches, remaps status values
+5. **Transition headings**: 3 headings contain `PLANNING` or `PLAN` as the phase name
+6. **Transition routing messages**: 2 messages route to `/intuition-plan`
+7. **File path references**: `planning_brief.md` (2 occurrences), `plan.md` (3 occurrences as the outline artifact, not counting V3 migration historical refs)
+8. **State write instructions**: `planning.started`, `planning.completed`, `planning.approved` field paths (~8 occurrences)
+9. **Critical rules and protocol steps**: Lines 24, 62 reference `planning` as the phase name
+
+### Connections (Dependencies Between Elements)
+
+- **Schema version <-> Migration handler**: The handler fires on `version == "7.0"` and sets `version: "8.0"`. The schema header must match the target version.
+- **Status enum <-> Transition conditions**: Line 74 and 77 check `planning` in conditions. The enum (line 131) must list `outline` for these checks to be valid post-rename.
+- **State write instructions <-> Migration handler**: The handler renames the key once at migration time. All subsequent state writes use `outline.*` paths.
+- **V3 migration <-> V7 migration**: V3 references historical file names on disk. V7 renames JSON keys only. These are independent — V3 must NOT be modified.
+- **T3 <-> T5 coupling**: T5 (technical-writer) renames the same status checks and field paths in other skills (start, prompt, etc.). T3 renames them in handoff only. Both must use identical target names.
+
+### Dynamics (Migration Execution Flow)
+
+When a v7.0 project runs any handoff transition:
+1. Handoff reads `.project-memory-state.json`, detects `version: "7.0"`
+2. V7 migration handler fires: renames `workflow.planning` -> `workflow.outline` in trunk and every branch, remaps any `status == "planning"` -> `"outline"`, sets `version: "8.0"`
+3. State is written with the new structure
+4. Original transition continues, now using `outline.*` field paths
+
+Post-migration, all handoff transitions write to `workflow.outline.*` and set `status: "outline"`. Start skill (updated by T5) reads `workflow.outline.*`.
+
+## Assumptions
+
+### A1: V3 migration historical file references must NOT be renamed
+- **Default**: Keep `planning_brief.md`, `plan.md`, `.planning_research/` in the V3 handler as-is
+- **Rationale**: The V3 handler moves files that exist on disk with those names in v3.0 projects. Renaming them would break migration for any project still at v3.0. The files on disk are not renamed by any migration handler — only the JSON state key changes.
+
+### A2: Status value "planning" in Transition 2v9 is intentional and must also rename
+- **Default**: Transition 2v9 (line 243) sets `status` to `"outline"` after rename
+- **Rationale**: Research R3 confirmed this transition intentionally keeps the status at "planning" (now "outline") until assemble advances it. The status value represents the phase, which is being renamed. This is not a generic English usage.
+
+### A3: The migration handler only needs to rename the JSON key, not files on disk
+- **Default**: The v7->v8 handler renames `workflow.planning` -> `workflow.outline` in JSON and remaps `status == "planning"` -> `"outline"`. No file renames.
+- **Rationale**: The plan's acceptance criteria and task description focus exclusively on state schema changes. File renames on disk (e.g., `planning_brief.md` -> `outline_brief.md`) are handled by T6 (the install/uninstall script task) or as a separate concern. The migration handler's job is to ensure existing state files remain valid under the new schema.
+
+### A4: Migration handler placement follows "newest first" convention
+- **Default**: Insert the V7 handler before V5 (currently line 192), making it the first migration section
+- **Rationale**: Existing ordering is V5, V6, V4, V3 (newest target version first). V7->V8 targets the highest version and goes first.
+
+## Key Decisions
+
+### D1: V3 migration handler — rename historical artifact references or preserve them
+- **Tier**: [SILENT]
+- **Options**:
+  - (A) Rename `planning_brief.md`, `plan.md`, `.planning_research/` in V3 handler to new names
+  - (B) Preserve V3 handler exactly as-is (these reference files on disk in v3.0 projects)
+- **Recommendation**: Option B. The V3 handler moves files that exist with old names on disk. Renaming these references would break migration for v3.0 projects. The acceptance criteria explicitly say "Existing v5->v6 and v6->v7 migration handlers are preserved unchanged" — by extension, all prior handlers should be preserved.
+- **Risk if wrong**: If option A is chosen, any v3.0 project attempting migration would fail to find the files to move. Low probability of encountering v3.0 projects but high impact if it happens.
+
+### D2: Status value remapping scope in the migration handler
+- **Tier**: [SILENT]
+- **Options**:
+  - (A) Remap `status == "planning"` -> `"outline"` for trunk and all branches
+  - (B) Only rename the workflow key, leave status values untouched
+- **Recommendation**: Option A. The status field and the workflow key are tightly coupled. If status says `"planning"` but the workflow key is `outline`, condition checks like `status == "outline" AND workflow.outline.completed == true` would fail (status still says "planning"). Both must change together.
+- **Risk if wrong**: Option B would leave a mismatch between status values and workflow keys, causing all transition detection to fail silently.
+
+### D3: Whether to add a secondary trigger condition (like V4's fallback)
+- **Tier**: [SILENT]
+- **Options**:
+  - (A) Simple trigger: `version == "7.0"` only
+  - (B) Add fallback: `version == "7.0"` OR (`planning` key exists but no `outline` key)
+- **Recommendation**: Option A. The V4 handler's fallback (`execution` exists but no `engineering`) was needed because V4 handled a structural rename that could occur in unversioned states. V7.0 states always have a version field (added in V3 migration). A fallback adds complexity without benefit.
+- **Risk if wrong**: Negligible. Any edge case where version is "7.0" but `planning` key is missing would indicate a corrupted state, handled by the existing "Corrupted state" edge case (line 500).
+
+## Risks Identified
+
+### Risk 1: T3 and T5 applied in wrong order
+- **Severity**: Low (mitigated by plan sequencing)
+- **Description**: T5 (technical-writer) also modifies handoff SKILL.md — renaming prose references, routing messages, and file paths. T3 adds the migration handler and bumps the schema version. If T5 runs first and changes `planning` references before T3's migration handler is added, the handler might reference stale field names.
+- **Mitigation**: The plan specifies T3 depends on T1 (audit hit list). T5 also depends on T1. Both can technically run in parallel since T3 adds a new section (migration handler) while T5 modifies existing text. The build phase must apply both to the same file — the technical-writer blueprint already notes "Both blueprints must be read together."
+
+### Risk 2: Migration handler misses branch-level status fields
+- **Severity**: Medium
+- **Description**: The handler must iterate trunk AND every branch. If it only patches trunk, branches with `status: "planning"` and `workflow.planning` will break.
+- **Mitigation**: Follow V4/V5/V6 pattern exactly — all say "For trunk and every branch."
+
+### Risk 3: Approved field lost during key rename
+- **Severity**: Low
+- **Description**: The `planning` object has an `approved` field not present in other workflow phases. The migration must preserve this field when renaming the key.
+- **Mitigation**: The handler instruction should explicitly state "rename the key from `planning` to `outline`, preserving the entire object value (started, completed, completed_at, approved)."
+
+## Recommended Approach
+
+### Step 1: Bump schema version (2 edits)
+
+Change the section heading from `## STATE SCHEMA (v7.0)` to `## STATE SCHEMA (v8.0)` (line 121).
+
+Change `"version": "7.0"` to `"version": "8.0"` in the JSON schema block (line 128).
+
+### Step 2: Rename schema definition key (1 edit)
+
+Change `"planning": { "started": false, "completed": false, "completed_at": null, "approved": false }` to `"outline": { ... }` (line 134). Keep the object value identical.
+
+### Step 3: Update status enum (1 edit)
+
+Change `planning` to `outline` in the pipe-delimited status list on line 131.
+
+### Step 4: Add V7 STATE MIGRATION handler (new section)
+
+Insert before the existing V5 handler (before line 192). Use this exact text:
+
+```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 the entire value (started, completed, completed_at, approved). If `status == "planning"`, change it to `"outline"`. Set `version: "8.0"`, preserve all other fields, write state. Report: "Migrated state from v7.0 to v8.0 (renamed planning phase to outline)." Then continue with the original transition.
+```
+
+### Step 5: Update all transition headings (3 edits)
+
+- Line 208: `TRANSITION 1: PROMPT -> PLANNING` -> `TRANSITION 1: PROMPT -> OUTLINE`
+- Line 220: `TRANSITION 2: PLANNING -> DESIGN` -> `TRANSITION 2: OUTLINE -> DESIGN`
+- Line 230: `TRANSITION 2B: PLANNING -> ENGINEER` -> `TRANSITION 2B: OUTLINE -> ENGINEER`
+
+Note: Transition 2v9 heading says `PLAN -> ASSEMBLE` which becomes `OUTLINE -> ASSEMBLE` (but check — the technical-writer blueprint T5 may own this rename since it's a prose reference, not a state/schema change).
+
+### Step 6: Update all routing messages to `/intuition-outline` (2 edits)
+
+- Line 218: `/intuition-plan` -> `/intuition-outline`
+- Line 244: `/intuition-assemble` routing message — check if it references `/intuition-plan` (research shows it doesn't, so this may be only line 218)
+
+### Step 7: Update all file path references (multiple edits)
+
+- `planning_brief.md` -> `outline_brief.md` (lines 216, 218, and any other occurrences)
+- `plan.md` -> `outline.md` (lines 222, 238, 242 — but NOT line 206 in V3 migration)
+
+### Step 8: Update all state field references (multiple edits)
+
+- `planning.started` -> `outline.started` (lines 74, 218)
+- `planning.completed` -> `outline.completed` (lines 77, 228, 234, 243)
+- `planning.approved` -> `outline.approved` (line 228, 234, 243 where `approved = true`)
+- `status` to `"planning"` -> `status` to `"outline"` (lines 218, 243)
+- `status == "planning"` -> `status == "outline"` (line 77)
+
+### Step 9: Update critical rules and protocol references (2 edits)
+
+- Line 24: `prompt->planning` -> `prompt->outline`
+- Line 62: `prompt->planning only` -> `prompt->outline only`
+
+### Step 10: Preserve all prior migration handlers unchanged
+
+V3, V4, V5, V6 handlers remain exactly as they are. The V3 handler's references to `planning_brief.md`, `plan.md`, `.planning_research/` are historical artifact names and must NOT be renamed.
+
+### Coordination note
+
+This blueprint covers the **structural/schema** changes to handoff SKILL.md (migration handler, schema definition, version bump, state field paths, status values). The **technical-writer blueprint (T5)** covers the remaining ~48 prose/routing renames in the same file. The build phase must apply both blueprints to the same file. There is no conflict between them — T3 touches the schema block and adds a new migration section, while T5 touches transition prose and routing messages. Where they overlap (e.g., transition headings, routing messages), the rename target is identical (`outline`).

package/docs/project_notes/trunk/scratch/devops-infrastructure-decisions.json

@@ -0,0 +1,71 @@
+{
+  "specialist": "devops-infrastructure",
+  "gate_started": "2026-03-04T18:00:00.000Z",
+  "gate_completed": "2026-03-04T18:00:01.000Z",
+  "decision_policy": "aggressive",
+  "assumptions": [
+    {
+      "id": "A1",
+      "title": "Legacy cleanup ordering is correct",
+      "default": "Legacy cleanup block runs before skill deployment, so adding intuition-plan removal will work correctly",
+      "status": "accepted",
+      "user_override": null
+    },
+    {
+      "id": "A2",
+      "title": "Package.json keywords 'planning' is generic English",
+      "default": "The keyword 'planning' describes package purpose and will be preserved",
+      "status": "accepted",
+      "user_override": null
+    },
+    {
+      "id": "A3",
+      "title": "Debugger 'plan diverged from intent' is a phase-name reference",
+      "default": "This references the plan.md artifact, so it should become 'outline diverged from intent'",
+      "status": "accepted",
+      "user_override": null
+    }
+  ],
+  "decisions": [
+    {
+      "id": "D1",
+      "title": "Version annotation for legacy cleanup comment",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "Legacy cleanup comments annotate which version introduced the change",
+      "options": ["v9.1 annotation", "v9.2/v10 annotation", "No version annotation"],
+      "chosen": "v9.1 annotation — matches existing pattern (v8.0, v6.0)",
+      "user_input": null
+    },
+    {
+      "id": "D2",
+      "title": "Uninstall script legacy entry placement",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "Where to place intuition-plan in uninstall script",
+      "options": ["Add to existing legacy section in array", "Separate legacy block outside array"],
+      "chosen": "Add to existing legacy section in array — follows intuition-execute/intuition-discovery pattern",
+      "user_input": null
+    },
+    {
+      "id": "D3",
+      "title": "Package.json description wording",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "How to update the phase name in package description",
+      "options": ["Replace 'plan' with 'outline'", "Reword entirely", "Keep 'plan' as generic"],
+      "chosen": "Replace 'plan' with 'outline' — minimal change, reads naturally",
+      "user_input": null
+    },
+    {
+      "id": "D4",
+      "title": "Help text update in install script",
+      "tier": "SILENT",
+      "classified_by": "plan",
+      "context": "Whether to update skill description alongside name",
+      "options": ["Update both name and description", "Update name only"],
+      "chosen": "Update both name and description — maintains consistency",
+      "user_input": null
+    }
+  ]
+}