@tgoodington/intuition 11.4.0 → 11.5.1

package/docs/project_notes/issues.md

@@ -1,101 +0,0 @@
-# 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

@@ -1,88 +0,0 @@
-# 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/discovery_brief.md

@@ -1,40 +0,0 @@
-# Discovery Brief: Elementary School Coverage Scheduling Tool
-
-## Who — Stakeholders
-- **Primary users**: School admins and admin assistants — they operate the tool daily
-- **Affected stakeholders**: Teachers, substitute staff, and any other staff who work with students and could be pulled for coverage — they act on the tool's output but don't use the tool directly
-
-## Where — Delivery
-- District-hosted application deployed through existing district app infrastructure
-- Local AI server handles scheduling inference
-
-## What — The Idea
-**Goals:**
-- Admins input the day's coverage needs (absences, gaps)
-- System reads staff availability from Microsoft Calendar integration
-- AI generates a coverage schedule proposal based on availability, constraints, and staff qualifications
-- Output is a coverage plan that teachers and staff can act on
-
-**Requirements:**
-- Microsoft Calendar integration for staff availability
-- Ability to tag calendar commitments as "can be pulled" vs "cannot be pulled"
-- Constraint-aware scheduling that respects staff qualifications, availability, and priority
-
-**Constraints:**
-- Must deploy on existing district app infrastructure
-- Must use local AI server for inference (not cloud-based)
-- Does NOT own the master schedule — consumes calendar data and focuses on gap-filling
-
-**Out of scope:**
-- Substitute teacher management/hiring
-- Master schedule creation or ownership
-- Direct teacher/staff-facing interface (output communication TBD)
-
-## Why — North Star
-Minimal time investment for admins — what currently takes 1-2 hours daily per school should take minutes. Coverage proposals must accurately reflect staff constraints, needs, and potential. Speed without accuracy is failure; accuracy without speed is the status quo.
-
-## Decision Posture
-Both — user wants to weigh in on all major creative and technical decisions.
-
-## Open Questions
-- How does the coverage plan get communicated to teachers/staff?

package/docs/project_notes/v9.2-optimization-plan.md

@@ -1,193 +0,0 @@
-# v9.2 Optimization Plan: Ceremony Reduction + Human-Centric Producers
-
-**Date:** 2025-03-05
-**Status:** All workstreams complete
-
-## Problem Statement
-
-The v9 pipeline requires 17 manual skill invocations for a 3-specialist project. Half of those are `/intuition-handoff` calls that add zero creative value. Small branches feel worse than base Claude. Briefs are never read by users. Non-code producers generate structurally correct but visually bland deliverables.
-
-The framework should make users feel like a creative director with a dynamic team — not a project manager routing work between departments.
-
-## Workstream 1: Eliminate Handoff Ceremony
-
-### Goal
-The user never types `/intuition-handoff` for v9 workflows. Each skill handles its own phase transition.
-
-### Design
-
-**Each v9 skill gets an Exit Protocol (~15-20 lines) that:**
-1. Updates `.project-memory-state.json` directly (read-modify-write)
-2. Optionally spawns a haiku subagent for memory extraction (key_facts.md, decisions.md, issues.md)
-3. Routes the user to the next skill
-
-**Detail handles the specialist loop internally:**
-- After completing one specialist's blueprint, reads `team_assignment.json`, finds next specialist, prepares context, continues
-- User gate still happens per specialist (natural interaction point)
-- Recommends `/clear` between Deep specialists, handles Light/Standard in one session
-- Adds ~30-40 lines (detail: 354 → ~390)
-
-**Conflict detection moves to build startup:**
-- Build already validates blueprints; add cross-blueprint comparison
-- Spawn haiku subagent to check for contradictions before confirming build plan
-
-**Briefs eliminated except detail_context.md:**
-- Outline reads `prompt_brief.md` directly (already does)
-- Build reads `blueprints/*.md` + `team_assignment.json` + `outline.md` directly (already does)
-- Test reads `build_report.md` + `scratch/*-decisions.json` + `outline.md` directly (already does)
-- Detail writes lightweight `detail_context.md` for itself between specialists (which specialist, which tasks, prior blueprint paths, known research)
-
-**Handoff skill becomes v8-only + branch creation + state migration:**
-- All v9 transitions removed
-- Retains: Transition 0 (branch creation), Transitions 1-5 (v8), Transition 6 (completion protocol for v8), state migrations
-- Eventually deprecated entirely when v8 is dropped
-
-### Skills Modified
-
-| Skill | Change | Line Impact |
-|-------|--------|-------------|
-| prompt | Add exit protocol: state update, memory extraction subagent, route to outline | +15-20 |
-| outline | Add exit protocol: state update, memory extraction subagent, route to assemble (or fast track) | +15-20 |
-| assemble | Add exit protocol: state update, route to detail | +15-20 |
-| detail | Add specialist loop + exit protocol: iterate specialists, write detail_context.md between them, conflict check when done, route to build | +30-40 |
-| build | Add conflict detection at startup + exit protocol: state update, route to test or completion | +20-25 |
-| test | Add exit protocol: state update, completion logic (git commit offer, specialist saving), mark done | +15-20 |
-| handoff | Remove all v9 transitions (2v9, 2.5v9, 3v9, 4v9, 6.5v9, 7). Keep v8 + branch creation + migrations | -200+ |
-| start | Update routing: remove handoff intermediary for v9 "ready_for" states | ~0 (logic change) |
-
-### User Flow After (3-specialist standard project)
-```
-/intuition-prompt     → [dialogue] → "Run /clear then /intuition-outline"
-/intuition-outline    → [dialogue] → "Run /clear then /intuition-assemble"
-/intuition-assemble   → [team confirmation] → "Run /clear then /intuition-detail"
-/intuition-detail     → [spec 1 gate] → [spec 2 gate] → [spec 3 gate] → "Run /clear then /intuition-build"
-/intuition-build      → [confirmation + production + review] → "Run /clear then /intuition-test"
-/intuition-test       → [tests + fixes] → done
-```
-**6 invocations** instead of 17.
-
-### State Write Safety
-
-The "handoff is the only state writer" rule is relaxed for v9. Each skill writes to state as part of its exit. Risk assessment:
-- Skills run sequentially in one conversation — no concurrent write risk
-- Each skill uses consistent read-modify-write pattern
-- State corruption was a theoretical risk; ceremony cost was a real one paid every session
-
-### Memory Extraction Strategy
-
-Each skill's exit protocol spawns a haiku Explore subagent:
-```
-"Read {artifact_path}. Extract to shared memory files:
-- Key facts → docs/project_notes/key_facts.md (append new facts under appropriate category)
-- Architectural decisions → docs/project_notes/decisions.md (append as ADRs)
-- Issues/risks → docs/project_notes/issues.md (append with date and source)
-Do NOT duplicate existing entries. Read each target file first."
-```
-
-This is lighter than handoff's sonnet extraction but sufficient for the mechanical task.
-
----
-
-## Workstream 2: Fast Track for Simple Projects
-
-### Goal
-Small tasks (1-4 Light-depth tasks) skip assemble + detail entirely.
-
-### Design
-
-**Outline adds Fast Track Assessment after task sequence:**
-- Triggers when: tier is Lightweight AND all tasks classified as Light depth
-- Asks user: "This looks straightforward — build directly from the outline, or run the full specialist pipeline?"
-- If fast track: outline writes `team_assignment.json` with `fast_track: true`, skips Section 6.5 specialist assignments. State goes to `"building"` directly.
-
-**Build gets fast track mode:**
-- Detects `fast_track: true` in `team_assignment.json`
-- Reads outline tasks directly as specifications (no blueprints)
-- Review chain: builder verification + security only (no specialist review — there was no specialist)
-- Producer selection: infer from task domain or default to code-writer
-
-**Prompt gets adaptive convergence:**
-- The 6-9 turn target becomes a ceiling, not a floor
-- If initial CAPTURE covers scope, success criteria, and constraints, REFINE skips satisfied dimensions
-- Minimum: CAPTURE (1) + 1-2 REFINE + REFLECT (1) + POSTURE (1) + CONFIRM (1) = 4-6 turns
-- The question "does this pass the load-bearing test?" already gates unnecessary questions — just enforce it harder
-
-### Fast Track User Flow
-```
-/intuition-prompt    → 3-4 turns
-/intuition-outline   → lightweight plan, fast track approved
-/intuition-build     → produces deliverables
-/intuition-test      → if code produced
-```
-**3-4 invocations** for a simple branch.
-
----
-
-## Workstream 3: Human-Centric Producer Design
-
-### Goal
-Deliverables that a person opens should look professional without the blueprint specifying every visual detail.
-
-### Principle
-**Specialists own content and structure. Producers own visual execution.** Blueprint styling directives override producer defaults. If the blueprint is silent on styling, the producer makes it look good.
-
-### Changes Per Producer
-
-**presentation-creator:**
-- Professional color scheme (dark blue/white/accent or similar corporate palette)
-- Font hierarchy: title font (28-36pt), body font (18-24pt), consistent throughout
-- Layout variety: section dividers between major topics, not all title-and-content
-- Visual hierarchy within slides: proper bullet indentation, spacing
-- Speaker notes styled separately
-- Master slide setup for deck cohesion
-
-**document-writer:**
-- Cover page for documents with 5+ sections
-- Table of contents for substantial documents
-- Professional typography: styled headings with accent color, readable body font
-- Table styling: alternating row shading, proper borders, distinct header row
-- Page numbers, headers/footers
-- Section breaks between major parts
-
-**spreadsheet-builder:**
-- Frozen header row (always)
-- Auto-fit column widths
-- Number formatting by data type (currency, percentages, dates)
-- Alternating row shading
-- Print-ready: page setup, print area, repeat headers
-- Summary rows visually distinct
-
-**form-filler:**
-- Clear visual hierarchy in PDFs (section headers larger, proper field spacing)
-- Professional typography
-- Required field indicators (asterisk + legend)
-- Styled signature lines (gray rules, not underscores)
-- Consistent field alignment
-
-**NOT changed:** code-writer, data-file-writer (machine-consumed output)
-
-### Implementation Approach
-Each producer gets a new `## Design Standards` section between Critical Rules and Input Protocol. The standards are default behaviors the producer applies unless the blueprint overrides them. The Python scripts (pptx, docx, xlsx, pdf) include professional styling in the generated code.
-
----
-
-## Implementation Order
-
-1. **Workstream 1** — Biggest impact on daily usage. Start here.
-   - Phase A: Add exit protocols to each skill (state update + routing)
-   - Phase B: Add specialist loop to detail
-   - Phase C: Move conflict detection to build startup
-   - Phase D: Eliminate briefs (update skill startup sections to read source artifacts)
-   - Phase E: Strip v9 transitions from handoff
-   - Phase F: Update start routing
-
-2. **Workstream 2** — Biggest impact on small projects.
-   - Phase A: Add fast track assessment to outline
-   - Phase B: Add fast track mode to build
-   - Phase C: Adaptive convergence in prompt
-
-3. **Workstream 3** — Self-contained, no pipeline dependencies.
-   - Update each human-facing producer independently
-
-## Version
-These changes constitute v9.3.0 (or v10.0.0 if the handoff elimination is considered a breaking change for v8 compat).