@tgoodington/intuition 9.2.0 → 9.2.1

package/README.md

@@ -18,7 +18,7 @@ This installs 12 skills globally to `~/.claude/skills/`. Verify by typing `/` in
 Five phases with handoff transitions between each:
 
 ```
-prompt → plan → [design] → engineer → build
+prompt → outline → [design] → engineer → build
 ```
 
 The first cycle is the **trunk**. After completion, create **branches** for new features or changes.
@@ -29,8 +29,8 @@ The first cycle is the **trunk**. After completion, create **branches** for new
 /intuition-initialize          # Set up project memory (once per project)
 /intuition-start               # Check status, get routed to next step
 /intuition-prompt              # Describe what you want to build
-/intuition-handoff             # Process → move to planning
-/intuition-plan                # Create the blueprint
+/intuition-handoff             # Process → move to outlining
+/intuition-outline             # Create the blueprint
 /intuition-handoff             # Review design flags
 /intuition-design              # Elaborate flagged items (if any)
 /intuition-handoff             # Prepare for engineering
@@ -40,7 +40,7 @@ The first cycle is the **trunk**. After completion, create **branches** for new
 /intuition-handoff             # Complete the cycle
 ```
 
-Run `/clear` before each phase skill to keep context clean. Not every project needs design — if the plan is clear enough, handoff skips straight to engineer.
+Run `/clear` before each phase skill to keep context clean. Not every project needs design — if the outline is clear enough, handoff skips straight to engineer.
 
 ## Skills
 
@@ -48,8 +48,8 @@ Run `/clear` before each phase skill to keep context clean. Not every project ne
 
 | Skill | Model | Purpose |
 |-------|-------|---------|
-| `/intuition-prompt` | opus | Refines a rough idea into a planning-ready brief |
-| `/intuition-plan` | opus | Strategic blueprint with tasks, dependencies, design flags |
+| `/intuition-prompt` | opus | Refines a rough idea into an outline-ready brief |
+| `/intuition-outline` | opus | Strategic blueprint with tasks, dependencies, design flags |
 | `/intuition-design` | opus | ECD framework design exploration for flagged items |
 | `/intuition-engineer` | opus | Code-level specs through research + interactive dialogue |
 | `/intuition-build` | sonnet | Delegates implementation, verifies against specs |
@@ -86,14 +86,14 @@ Run `/clear` before each phase skill to keep context clean. Not every project ne
 
 ### Design Loop
 
-The plan flags tasks needing design exploration. Handoff manages a loop: design one item → check for more → design next or advance to engineer.
+The outline flags tasks needing design exploration. Handoff manages a loop: design one item → check for more → design next or advance to engineer.
 
 ### Project Memory
 
 All workflow state and knowledge lives in `docs/project_notes/`:
 - Shared memory: `bugs.md`, `decisions.md`, `key_facts.md`, `issues.md`
 - State: `.project-memory-state.json` (owned by handoff)
-- Phase outputs: briefs, plan, code specs, build report (in context-specific paths)
+- Phase outputs: briefs, outline, code specs, build report (in context-specific paths)
 
 ## Project Structure
 
@@ -102,7 +102,7 @@ intuition/
 ├── skills/
 │   ├── intuition-start/           # Session primer + routing
 │   ├── intuition-prompt/          # Discovery refinement
-│   ├── intuition-plan/            # Strategic planning
+│   ├── intuition-outline/         # Strategic outlining
 │   ├── intuition-design/          # ECD design exploration
 │   ├── intuition-engineer/        # Code spec creation
 │   ├── intuition-build/           # Implementation + verification

package/docs/project_notes/.project-memory-state.json

@@ -0,0 +1,100 @@
+{
+  "initialized": true,
+  "version": "8.0",
+  "active_context": "trunk",
+  "trunk": {
+    "status": "complete",
+    "workflow": {
+      "prompt": {
+        "started": true,
+        "completed": true,
+        "started_at": null,
+        "completed_at": "2026-03-04T00:00:00.000Z",
+        "output_files": [
+          "docs/project_notes/trunk/prompt_brief.md",
+          "docs/project_notes/trunk/prompt_output.json"
+        ]
+      },
+      "outline": {
+        "started": true,
+        "completed": true,
+        "completed_at": "2026-03-04T00:00:00.000Z",
+        "approved": true
+      },
+      "design": {
+        "started": false,
+        "completed": false,
+        "completed_at": null,
+        "items": [],
+        "current_item": null
+      },
+      "engineering": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      },
+      "build": {
+        "started": true,
+        "completed": true,
+        "completed_at": "2026-03-05T00:00:00.000Z"
+      },
+      "test": {
+        "started": true,
+        "completed": true,
+        "completed_at": "2026-03-05T00:00:00.000Z",
+        "skipped": true
+      },
+      "detail": {
+        "started": true,
+        "completed": true,
+        "completed_at": "2026-03-05T00:00:00.000Z",
+        "team_assignment": "team_assignment.json",
+        "specialists": [
+          {
+            "name": "devops-infrastructure",
+            "tasks": [
+              {"task_id": "T1", "depth": "Light"},
+              {"task_id": "T6", "depth": "Light"},
+              {"task_id": "T8", "depth": "Standard"}
+            ],
+            "status": "completed",
+            "stage": "done",
+            "stage1_path": "docs/project_notes/trunk/scratch/devops-infrastructure-stage1.md",
+            "decisions_path": "docs/project_notes/trunk/scratch/devops-infrastructure-decisions.json",
+            "blueprint_path": "docs/project_notes/trunk/blueprints/devops-infrastructure.md"
+          },
+          {
+            "name": "technical-writer",
+            "tasks": [
+              {"task_id": "T2", "depth": "Standard"},
+              {"task_id": "T4", "depth": "Light"},
+              {"task_id": "T5", "depth": "Standard"},
+              {"task_id": "T7", "depth": "Standard"}
+            ],
+            "status": "completed",
+            "stage": "done",
+            "stage1_path": "docs/project_notes/trunk/scratch/technical-writer-stage1.md",
+            "decisions_path": "docs/project_notes/trunk/scratch/technical-writer-decisions.json",
+            "blueprint_path": "docs/project_notes/trunk/blueprints/technical-writer.md"
+          },
+          {
+            "name": "database-architect",
+            "tasks": [
+              {"task_id": "T3", "depth": "Deep"}
+            ],
+            "status": "completed",
+            "stage": "done",
+            "stage1_path": "docs/project_notes/trunk/scratch/database-architect-stage1.md",
+            "decisions_path": "docs/project_notes/trunk/scratch/database-architect-decisions.json",
+            "blueprint_path": "docs/project_notes/trunk/blueprints/database-architect.md"
+          }
+        ],
+        "current_specialist": "database-architect",
+        "execution_phase": 2
+      }
+    }
+  },
+  "branches": {},
+  "last_handoff": "2026-03-05T00:00:00.000Z",
+  "last_handoff_transition": "transition_7_test_to_complete"
+}

package/docs/project_notes/bugs.md

@@ -0,0 +1,41 @@
+# Bug Log Template
+
+This file demonstrates the format for logging bugs and their solutions. Keep entries brief and chronological.
+
+## Format
+
+Each bug entry should include:
+- Date (YYYY-MM-DD)
+- Brief description of the bug/issue
+- Solution or fix applied
+- Any prevention notes (optional)
+
+Use bullet lists for simplicity. Older entries can be manually removed when they become irrelevant.
+
+## Example Entries
+
+### 2025-01-15 - Docker Architecture Mismatch
+- **Issue**: Container failing to start with "exec format error"
+- **Root Cause**: Built on ARM64 Mac but deploying to AMD64 Cloud Run
+- **Solution**: Added `--platform linux/amd64` to docker build command
+- **Prevention**: Always specify platform in Dockerfile and build scripts
+
+### 2025-01-20 - Cloud Scheduler HTTPS Requirement
+- **Issue**: Cloud Scheduler jobs failing with "URL must use HTTPS"
+- **Root Cause**: Forgot Cloud Run URLs require HTTPS by default
+- **Solution**: Updated all scheduler job URLs from http:// to https://
+- **Prevention**: Remember GCP services enforce HTTPS; check URLs in infrastructure code
+
+### 2025-01-22 - Database Connection Pool Exhaustion
+- **Issue**: API returning 500 errors under load
+- **Root Cause**: Connection pool size too small (default 5)
+- **Solution**: Increased pool_size to 20 and max_overflow to 10 in SQLAlchemy config
+- **Prevention**: Load test APIs before production deployment
+
+## Tips
+
+- Keep descriptions under 2-3 lines
+- Focus on what was learned, not exhaustive details
+- Include enough context for future reference
+- Date entries so you know how recent the issue is
+- Periodically clean out very old entries (6+ months)

package/docs/project_notes/decisions.md

@@ -0,0 +1,147 @@
+# Architectural Decisions Template
+
+This file demonstrates the format for logging architectural decisions (ADRs). Use bullet lists for clarity.
+
+## Format
+
+Each decision should include:
+- Date and ADR number
+- Context (why the decision was needed)
+- Decision (what was chosen)
+- Alternatives considered
+- Consequences (trade-offs, implications)
+
+## Example Entries
+
+### ADR-001: Use Workload Identity Federation for GitHub Actions (2025-01-10)
+
+**Context:**
+- Need secure authentication from GitHub Actions to GCP
+- Service account keys are deprecated and considered insecure
+- Want to avoid managing long-lived credentials
+
+**Decision:**
+- Use Workload Identity Federation (WIF) for GitHub Actions authentication
+- Configure via `WIF_PROVIDER` and `WIF_SERVICE_ACCOUNT` secrets
+
+**Alternatives Considered:**
+- Service account JSON keys → Rejected: security risk, manual rotation required
+- Environment-specific credentials → Rejected: harder to manage across repos
+
+**Consequences:**
+- ✅ More secure (no long-lived credentials)
+- ✅ Automatic credential rotation
+- ✅ Better audit trail
+- ❌ Slightly more complex initial setup
+- ❌ Requires GitHub OIDC support
+
+### ADR-002: Use Alembic for Database Migrations (2025-01-12)
+
+**Context:**
+- Need version control for database schema changes
+- Multiple developers working on database schema
+- Want to avoid manual SQL scripts and migration conflicts
+
+**Decision:**
+- Use Alembic as the database migration tool
+- Store migrations in `alembic/versions/` directory
+- Use auto-generate feature for model changes
+
+**Alternatives Considered:**
+- Raw SQL scripts → Rejected: no versioning, error-prone
+- Flask-Migrate → Rejected: too tied to Flask framework
+- Django migrations → Rejected: using FastAPI, not Django
+
+**Consequences:**
+- ✅ Version-controlled schema changes
+- ✅ Automatic migration generation from models
+- ✅ Easy rollback capability
+- ❌ Learning curve for team
+- ❌ Must remember to generate migrations after model changes
+
+### ADR-003: Use AlloyDB Instead of Cloud SQL (2025-01-15)
+
+**Context:**
+- Need PostgreSQL-compatible database in GCP
+- Require high availability and automatic backups
+- Performance-critical application with complex queries
+
+**Decision:**
+- Use AlloyDB for PostgreSQL instead of Cloud SQL
+- Configure with automated backups and point-in-time recovery
+
+**Alternatives Considered:**
+- Cloud SQL PostgreSQL → Rejected: slower query performance
+- Self-managed PostgreSQL on GCE → Rejected: high operational overhead
+- Firestore → Rejected: need relational data model and SQL
+
+**Consequences:**
+- ✅ Better query performance (2-4x faster than Cloud SQL)
+- ✅ PostgreSQL compatibility
+- ✅ Managed service (automated backups, HA)
+- ❌ Higher cost than Cloud SQL
+- ❌ Newer service, less community documentation
+
+## Tips
+
+- Number decisions sequentially (ADR-001, ADR-002, etc.)
+- Always include date for context
+- Be honest about trade-offs (use ✅ and ❌)
+- Keep alternatives brief but clear
+- Update decisions if they're revisited/changed
+- Focus on "why" not "how" (implementation details go elsewhere)
+
+### ADR-P002: "build plan" and "test plan" Are Preserved as Generic English (2026-03-04)
+
+**Status:** Decided — Technical Writer specialist consultation
+
+**Context:**
+- The rename refactor replaces all phase-name "plan" references with "outline"
+- `intuition-build/SKILL.md` uses "build plan" (lines 20, 61, 106, 109) meaning "the builder's execution strategy"
+- `intuition-test/SKILL.md` uses "test plan" (lines 44, 102, 161, 181, 184, 197, 203) meaning "the testing strategy"
+- These are standard English compound nouns, not references to the planning phase or plan.md artifact
+
+**Decision:**
+- "build plan" and "test plan" are KEPT unchanged in all skill files
+- These terms refer to execution/testing strategies, not the workflow phase
+
+**Alternatives Considered:**
+- Reword to "build strategy" / "test strategy" → Rejected: unnecessary churn, "test plan" is universally understood
+- Reword to "build sequence" / "test approach" → Rejected: slightly less clear than original terms
+
+**Consequences:**
+- ✅ Minimal disruption, established terminology preserved
+- ✅ Consistent with disambiguation rule (generic English "plan" stays)
+- ⚠️ Minor potential reader confusion in first few sessions post-rename (low impact)
+
+**Discovered During:** Technical Writer specialist consultation (2026-03-04)
+
+---
+
+### ADR-P001: Rename Plan Phase to Outline Across Entire Framework (2026-03-04)
+
+**Status:** Approved
+
+**Context:**
+- The `intuition-plan` skill and "planning" phase are being renamed to `intuition-outline` / "outlining"
+- All phase-name references across SKILL.md files, state schema, routing, scripts, and docs must be updated
+- Existing state files (v7.0) have a `planning` field that would break without migration
+
+**Decision:**
+- Full rename: `plan` → `outline` wherever it refers to the workflow phase
+- State schema field: `planning` → `outline` (base form, matches majority of existing fields), schema version bumps v7.0 → v8.0
+- v7→v8 migration handler added to handoff (following v5→v6 and v6→v7 patterns)
+- Output files: `plan.md` → `outline.md`, derived files use base form: `outline_brief.md`, `.outline_research/`
+- Generic English "plan" (e.g., "research plan", "action plan") is NOT renamed
+
+**Alternatives Considered:**
+- Partial rename (surface only) → Rejected: user wants full consistency
+- Keep state field as `planning` → Rejected: user wants complete rename
+- No migration handler → Rejected: would break existing project state files
+
+**Consequences:**
+- ✅ Complete naming consistency — no stale references
+- ✅ Existing state files migrate automatically via v7→v8 handler
+- ✅ Pure rename — no behavioral changes
+- ❌ Wide blast radius — many files touched
+- ❌ Anyone with local installs needs to re-install or the skill command changes

package/docs/project_notes/issues.md

@@ -0,0 +1,101 @@
+# Issues/Work Log Template
+
+This file demonstrates the format for logging work completed on tickets. Keep it simple - just enough to remember what was done. Full details live in Jira/GitHub.
+
+## Format
+
+Each entry should include:
+- Date (YYYY-MM-DD)
+- Ticket ID
+- Brief description (1-2 lines)
+- URL to ticket (if available)
+- Status (optional: completed, in-progress, blocked)
+
+Use bullet lists for simplicity. This is NOT a replacement for your ticket system - it's a quick reference log.
+
+## Example Entries
+
+### 2025-01-15 - PROJ-123: Implement Contact API
+- **Status**: Completed
+- **Description**: Created FastAPI endpoints for contact CRUD operations with validation
+- **URL**: https://jira.company.com/browse/PROJ-123
+- **Notes**: Added unit tests, coverage at 85%
+
+### 2025-01-16 - PROJ-124: Fix Docker Build Issues
+- **Status**: Completed
+- **Description**: Fixed architecture mismatch for Cloud Run deployment
+- **URL**: https://jira.company.com/browse/PROJ-124
+- **Notes**: See bugs.md for details on the fix
+
+### 2025-01-18 - PROJ-125: Database Migration to AlloyDB
+- **Status**: Completed
+- **Description**: Migrated from Cloud SQL to AlloyDB with Pulumi infrastructure code
+- **URL**: https://jira.company.com/browse/PROJ-125
+- **Notes**: Multi-phase migration completed over 3 days
+
+### 2025-01-20 - GH-45: Add OAuth2 Authentication
+- **Status**: In Progress
+- **Description**: Implementing OAuth2 flow with Google provider
+- **URL**: https://github.com/company/repo/issues/45
+- **Notes**: Backend complete, frontend integration pending
+
+### 2025-01-22 - PROJ-130: Performance Optimization
+- **Status**: Blocked
+- **Description**: Optimize slow queries in contact search endpoint
+- **URL**: https://jira.company.com/browse/PROJ-130
+- **Notes**: Waiting for DBA review of proposed indexes
+
+## Alternative Format (Grouped by Week)
+
+### Week of 2025-01-15
+
+**Completed:**
+- PROJ-123: Contact API implementation → https://jira.company.com/browse/PROJ-123
+- PROJ-124: Docker build fix → https://jira.company.com/browse/PROJ-124
+
+**In Progress:**
+- PROJ-125: AlloyDB migration (phase 2 of 3)
+
+### Week of 2025-01-22
+
+**Completed:**
+- PROJ-125: AlloyDB migration completed → https://jira.company.com/browse/PROJ-125
+- GH-45: OAuth2 backend done → https://github.com/company/repo/issues/45
+
+**Blocked:**
+- PROJ-130: Query optimization (waiting on DBA) → https://jira.company.com/browse/PROJ-130
+
+## Tips
+
+- Keep descriptions brief (1-2 lines max)
+- Always include ticket URL for easy reference
+- Update status if work gets blocked or resumed
+- Optional: Group by week or sprint for better organization
+- Don't duplicate ticket details - link to source of truth
+- Clean out very old entries periodically (3+ months)
+- Include both Jira and GitHub tickets as appropriate
+
+### 2026-03-04 - OQ-001: Exact file list for plan→outline rename
+- **Status**: Resolved — planning audit launched during planning phase
+- **Description**: Blast radius confirmed: 15 skills, 3 scripts, state schema, docs/v9/, memory/MEMORY.md, root-level docs. Specialists and producers are clean (zero phase-name references).
+- **Notes**: Task 1 (full audit) will produce the final categorized hit list
+
+### 2026-03-04 - OQ-002: Do specialist/producer profiles reference the plan phase?
+- **Status**: Resolved — confirmed NO
+- **Description**: Grepped all specialists/ and producers/ — no phase-name "plan" references found. Only generic English "plan" (campaign planning, resource plan, etc.).
+- **Notes**: No tasks needed for specialists/producers
+
+### 2026-03-05 - BUILD-001: Rename Plan Phase to Outline — Build Complete
+- **Status**: Completed
+- **Description**: 8/8 tasks PASS. ~530+ edits across ~30 files + 8 reference files (scope expansion). State schema migrated v7.0→v8.0. Verification sweep: 34/34 checks PASS. 13 legacy docs classified out-of-scope (not blocking).
+- **Notes**: Scope expanded mid-build to cover `references/` subdirectories (39 stale refs found post-T5). See build_report.md for full task results.
+
+### 2026-03-05 - TEST-001: Test phase — Rename Plan Phase to Outline
+- **Status**: Skipped (user elected)
+- **Description**: Test phase skipped. Rationale: pure text rename, no behavioral changes, T8 verification sweep already passed 34/34 checks, no test framework exists in project.
+- **Notes**: No implementation fixes applied. Workflow cycle complete.
+
+### 2026-03-04 - OQ-003: docs/v9/ design documents — update or treat as historical?
+- **Status**: Resolved — update as living docs
+- **Description**: Decision: treat docs/v9/ as living architecture docs, update all phase-name references to "outline". Covered in Task 7.
+- **Notes**: These docs mix phase-name and generic "plan" usage heavily — disambiguation required

package/docs/project_notes/key_facts.md

@@ -0,0 +1,88 @@
+# Key Facts Template
+
+This file demonstrates the format for storing project constants, configuration, and frequently-needed **non-sensitive** information. Organize by category using bullet lists.
+
+## ⚠️ SECURITY WARNING: What NOT to Store Here
+
+**NEVER store passwords, API keys, or sensitive credentials in this file.** This file is typically committed to version control and should only contain non-sensitive reference information.
+
+**❌ NEVER store:**
+- Passwords or passphrases
+- API keys or authentication tokens
+- Service account JSON keys or credentials
+- Database passwords
+- OAuth client secrets
+- Private keys or certificates
+- Session tokens
+- Any secret values from environment variables
+
+**✅ SAFE to store:**
+- Database hostnames, ports, and cluster names
+- Client names and project identifiers
+- JIRA project keys and Confluence space names
+- AWS/GCP account names and profile names
+- API endpoint URLs (public URLs only)
+- Service account email addresses (not the keys!)
+- GCP project IDs and region names
+- Docker registry names
+- Environment names and deployment targets
+
+**Where to store secrets:**
+- `.env` files (excluded via `.gitignore`)
+- Password managers (1Password, LastPass, Bitwarden)
+- Secrets managers (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault)
+- CI/CD environment variables (GitHub Secrets, GitLab Variables)
+- Platform credential stores (Kubernetes Secrets, Cloud Run)
+
+## Tips
+
+- Keep entries current (update when things change)
+- Remove deprecated information after migration is complete
+- Include both production and development details
+- Add URLs to make navigation easier
+- Use consistent formatting (same structure for similar items)
+- Group related information together
+- Mark deprecated items clearly with dates
+
+## Project: Intuition Framework
+
+- **Package**: `@tgoodington/intuition` — Claude Code skill system
+- **Skills dir**: `C:\Projects\Intuition\skills\`
+- **Specialists dir**: `C:\Projects\Intuition\specialists\`
+- **Producers dir**: `C:\Projects\Intuition\producers\`
+- **Install script**: `scripts/install-skills.js`
+- **Current state schema version**: v8.0 (migrated 2026-03-05; `planning` → `outline` key)
+
+## Rename Directive (discovered 2026-03-04)
+
+- **Rename**: `intuition-plan` → `intuition-outline` (skill folder, command, all phase references)
+- **State field**: `planning` → `outline` (base form, matches majority of existing state fields; with v7→v8 migration handler)
+- **State schema**: bumps to v8.0 after rename
+- **Output files**: `plan.md` → `outline.md`, `planning_brief.md` → `outline_brief.md`, `.planning_research/` → `.outline_research/`
+- **Standing rule**: generic English "plan" (e.g., "research plan") is NOT renamed — only phase-name usage
+- **Scope**: full framework — all skill SKILL.md files, handoff, start, prompt, assemble, detail, build, test, initialize, install/uninstall scripts, package.json, MEMORY.md, docs
+- **Blast radius**: ~177 lines across ~39 files; specialists and producers are clean (zero refs)
+- **Skills breakdown**: intuition-plan/SKILL.md (~78 renames), intuition-handoff/SKILL.md (~48), intuition-engineer/SKILL.md (~22), intuition-detail/SKILL.md (~25), intuition-build/SKILL.md (~15), remaining skills 9-12 each
+- **Docs breakdown**: MEMORY.md (~30+), TESTING_SUMMARY.md (~25), ARCHITECTURE_OVERVIEW.txt (~19), README.md (~10), docs/v9/ files (5-11 each)
+- **KEEP items confirmed**: "build plan"/"test plan" in build/test skills (generic English — ADR-P002); "research plan"/"research-plan.md"/"Research Planning" in detail skill; "plan against" in prompt skill; "Waldo doesn't plan" in ARCHITECTURE_OVERVIEW.txt; "ARCH planning" throughout docs; "research planning" in decision-framework-direction.md line 96
+- **Critical detail-skill disambiguation**: `classified_by: "plan"` IS a phase-name ref (RENAME to "outline"). All "research-plan.md", "Research Planning", "research-planning framing" instances are generic English (KEEP).
+- **Section heading renames**: "PLAN.MD OUTPUT FORMAT" → "OUTLINE.MD OUTPUT FORMAT"; "Planning Context for Engineer" → "Outline Context for Engineer" (both in outline skill and engineer skill must match)
+- **"Layer 2: Plan"** in domain-adaptive-team-architecture.md → "Layer 2: Outline" (confirmed per disambiguation guidance)
+- **package.json keywords**: "planning" in keywords array is generic English (package purpose) — NOT renamed (confirmed 2026-03-04)
+- **install-skills.js**: `intuition-plan` at line 48; legacy cleanup pattern at lines 98-110 (fs.existsSync + fs.rmSync, version-annotated comments)
+- **uninstall-skills.js**: `intuition-plan` at line 48; legacy entries at lines 60-63 (flat array pattern)
+
+## Build Lessons — Rename Plan to Outline (2026-03-05)
+
+- **Reference files scope gap**: Blueprints scoped to `SKILL.md` files; `references/` subdirectories in skills were NOT in any blueprint scope. After build, 39 stale references found in 8 reference files. Lesson: future audits must include `references/**` alongside SKILL.md.
+- **MEMORY.md is NOT in project root**: Auto-memory file lives at `C:\Users\tgoodington\.claude\projects\C--Projects-Intuition\memory\MEMORY.md`, not `docs/project_notes/` or project root. Blueprints and producer prompts must use absolute path.
+- **T3/T5 overlap resolution**: When two specialists target the same file, run the Deep-depth specialist (T3, database-architect) first; the Standard-depth specialist (T5, technical-writer) then verifies and finds zero remaining edits.
+- **team_assignment.json producer vs blueprint producer**: team_assignment.json listed `document-writer` for technical-writer tasks, but individual blueprint Section 9 specified `code-writer` for SKILL.md edits (T2/T4/T5) and `document-writer` only for docs (T7). Blueprint Section 9 is authoritative over team_assignment.json.
+
+## V7→V8 Migration Handler (discovered 2026-03-05)
+
+- **Handler pattern**: Follows V4 handler as template (field rename + status remap). Simple trigger: `version == "7.0"` only (no fallback — v7.0 states always have version field)
+- **Mutations**: Rename `workflow.planning` → `workflow.outline` (preserving all sub-fields: started, completed, completed_at, approved); remap `status == "planning"` → `"outline"` for trunk AND every branch
+- **Placement**: Insert before V5 handler (newest-first ordering convention)
+- **Report message**: "Migrated state from v7.0 to v8.0 (renamed planning → outline)."
+- **V3 preservation rule**: V3 migration handler references `planning_brief.md`, `plan.md`, `.planning_research/` as historical on-disk filenames for v3.0 projects — these must NOT be renamed (they move actual files with those legacy names)

package/docs/project_notes/trunk/.planning_research/decision_file_naming.md

@@ -0,0 +1,15 @@
+# Research: File Naming Convention
+
+## Current Pattern
+- Skill: `intuition-plan` → state field: `planning` → brief: `planning_brief.md` → dir: `.planning_research/`
+- Pattern: gerund form of the skill name used for state field, brief filename, and research directory
+
+## Options
+1. **Gerund form (outlining)**: `outlining_brief.md`, `.outlining_research/`, state field `outlining` — matches current pattern exactly
+2. **Base form (outline)**: `outline_brief.md`, `.outline_research/`, state field `outlining` — inconsistent (state is gerund, files are base)
+
+## Affected File Counts
+- `planning_brief.md`: 40+ references across codebase
+- `.planning_research/`: 10 references (mostly within plan skill)
+- `plan.md` → `outline.md`: 100+ references
+- `plan_output.json`: NOT actually referenced anywhere (may not exist as a convention)

package/docs/project_notes/trunk/.planning_research/decisions_log.md

@@ -0,0 +1,32 @@
+# Decisions Log
+
+## File Naming Convention
+- **Decision**: Use base form "outline" for all derived file names
+- **Choice**: `outline_brief.md`, `.outline_research/`, `outline.md`
+- **Status**: Locked
+- **Rationale**: User preference for base form; cleaner naming
+- **Alternatives**: Gerund form "outlining" (matching current `planning_brief.md` pattern)
+
+## State Schema Field Name
+- **Decision**: State field uses base form `outline` instead of gerund `outlining`
+- **Choice**: `planning` → `outline` in state schema
+- **Status**: Locked
+- **Rationale**: Matches 5 of 7 existing state fields (prompt, design, build, test, detail). More internally consistent.
+- **Alternatives**: `outlining` (direct gerund match to `planning`)
+
+## Stakeholders
+- **Decision**: Framework author, end users, skill system itself
+- **Choice**: Confirmed as-is, no additional stakeholders
+- **Status**: Locked
+
+## docs/v9/ Treatment
+- **Decision**: Update design documents to reflect "outline" naming
+- **Choice**: Full update — treat as living architecture docs
+- **Status**: Locked
+- **Rationale**: Stale terminology defeats their purpose as reference material
+- **Alternatives**: Leave as historical, update selectively
+
+## Planning Depth
+- **Decision**: Standard tier
+- **Choice**: 5-10 tasks with testing strategy and risks
+- **Status**: Locked

package/docs/project_notes/trunk/.planning_research/orientation.md

@@ -0,0 +1,51 @@
+# Orientation Research
+
+## Codebase Topology
+
+- npm package `@tgoodington/intuition` v9.2.0, MIT, Node >= 14
+- No build step, no transpilation — source is distribution
+- 15 skills in `skills/intuition-*/SKILL.md` (YAML frontmatter + Markdown body)
+- 14 specialist profiles in `specialists/`
+- 6 producer profiles in `producers/`
+- 3 JS files: `bin/intuition.js`, `scripts/install-skills.js`, `scripts/uninstall-skills.js` (CommonJS)
+- No automated tests — manual testing only
+- State: `docs/project_notes/.project-memory-state.json` (v7.0, handoff-owned)
+- Install: npm postinstall copies skills/specialists/producers to `~/.claude/` directories
+
+## Key Files Affected by "plan" Phase Name
+
+### Skills (each has SKILL.md)
+- `skills/intuition-plan/` — the skill being renamed
+- `skills/intuition-handoff/` — transitions, routing, state field refs, migration handlers
+- `skills/intuition-start/` — phase detection, routing
+- `skills/intuition-prompt/` — route message to plan
+- `skills/intuition-assemble/` — reads plan output
+- `skills/intuition-detail/` — reads plan, planning context
+- `skills/intuition-build/` — reads plan
+- `skills/intuition-test/` — references plan
+- `skills/intuition-design/` — v8 compat, plan refs
+- `skills/intuition-engineer/` — v8 compat, plan refs
+- `skills/intuition-debugger/` — may reference plan
+- `skills/intuition-initialize/` — state template has `planning` field
+
+### Scripts/Config
+- `scripts/install-skills.js` — skill list includes `intuition-plan`
+- `scripts/uninstall-skills.js` — skill list includes `intuition-plan`
+- `package.json` — may reference plan skill
+
+### Docs/Memory
+- `memory/MEMORY.md` — extensive plan phase references
+- `docs/` — design documents (historical vs updatable TBD)
+
+## Architecture Patterns
+
+- Pipeline/phase orchestration: skills are stateless, communicate via files on disk
+- No class hierarchy, no shared modules — each JS script is self-contained
+- Handoff is sole state writer; all other skills read state + write output files
+- Skill dependency graph is protocol-enforced (Markdown instructions), not code-imported
+- kebab-case directories, camelCase JS functions, YAML frontmatter convention
+
+## Disambiguation Rule
+
+- Phase-name refs: `/intuition-plan`, `planning phase`, `"planning"` JSON key, `plan.md`, `planning_brief.md` → rename
+- Generic English: "research plan," "ARCH planning," "planning context," "planning research" → keep