@tgoodington/intuition 11.4.0 → 11.5.1

package/docs/archive/v9-test/phase5b/test-5B-9-results.md

@@ -1,76 +0,0 @@
-# Test 5B-9: Crash Recovery — Gate Already Complete
-
-**Date:** 2026-02-27
-**Verdict:** PASS
-
----
-
-## Simulation Walkthrough
-
-**Scenario:** The user completed the entire gate (all assumptions + all decisions resolved), but the session crashed before Stage 2 could run. No blueprint exists yet.
-
-**Pre-existing state:** `decisions/5B-9-complete-decisions.json` — all items resolved, `gate_completed: "2026-02-27T17:18:00Z"`.
-
-### Step 1: Detail skill starts fresh
-
-Skill re-reads the detail brief from disk. Identifies specialist (code-architect), task, and file paths.
-
-### Step 2: Skill checks for existing decisions.json
-
-Finds `decisions.json` with `gate_completed` set to a timestamp — gate is complete.
-
-### Step 3: Skill checks for existing blueprint
-
-Looks for `{context_path}/blueprints/code-architect.md` — does not exist.
-
-### Step 4: Skill presents skip message
-
-```
-Found completed consultation from 2026-02-27T17:18:00Z. Proceeding to blueprint generation.
-
-Summary of resolved items:
-- 3 assumptions accepted
-- 3 decisions resolved (D1: A, D2: B, D3: A)
-```
-
-### Step 5: Skill proceeds to Stage 2
-
-Spawns Stage 2 subagent with stage1.md + decisions.json injected.
-
----
-
-## Criterion-by-Criterion Evaluation
-
-### 1. Skill detects completed gate
-
-**PASS** — `gate_completed` is non-null, signaling all items are resolved.
-
-### 2. Presents summary with timestamp
-
-**PASS** — "Found completed consultation from 2026-02-27T17:18:00Z" with item count summary.
-
-### 3. Skips directly to Stage 2
-
-**PASS** — No questions presented. No Phase 1 or Phase 2 prompts. Gate is entirely bypassed.
-
-### 4. Does NOT re-ask any questions
-
-**PASS** — All items are resolved in decisions.json. Skill treats the file as authoritative and moves to Stage 2.
-
----
-
-## Protocol Validation Notes
-
-1. **The complete-gate-skip is the simplest recovery path.** Just check `gate_completed != null` and proceed.
-2. **The summary is a courtesy, not a requirement.** It helps the user remember what they decided in the previous session. The skill could skip it and go straight to Stage 2, but the summary builds confidence that the right decisions are being used.
-3. **What if the blueprint already exists?** This test explicitly requires no blueprint at the expected path. If a blueprint DID exist, the skill should present: "Found completed blueprint from [timestamp]. Nothing to do." This is a different scenario (full recovery, not mid-pipeline recovery).
-
-### Additional Edge Case: User Wants to Change a Decision
-
-If the user sees the summary and says "wait, I want to change D2" — the current protocol doesn't support this. The skill would need to:
-1. Re-open decisions.json
-2. Clear D2's `chosen` and `user_input` fields
-3. Set `gate_completed` back to null
-4. Re-present D2
-
-**Recommendation for implementation:** Don't build this initially. If the user wants to change a decision after completion, they can delete decisions.json and restart the gate. Add a "restart gate" option in the summary message as a simple escape hatch. A more granular "edit one decision" feature is a nice-to-have for later.

package/docs/archive/v9-test/producers/document-writer.producer.md

@@ -1,62 +0,0 @@
----
-name: document-writer
-type: producer
-display_name: Document Writer
-description: >
-  Produces formatted long-form documents from specialist blueprints.
-  Faithful rendering of blueprint content — no domain interpretation.
-
-output_formats:
-  - markdown
-  - docx
-
-tooling:
-  markdown:
-    required: []
-  docx:
-    required:
-      - python>=3.8
-      - python-docx>=0.8.11
-    optional:
-      - pandoc
-
-model: sonnet
-tools: [Read, Write, Edit, Glob, Grep]
----
-
-# Document Writer
-
-You produce formatted documents from specialist blueprints. You do NOT interpret, expand, or editorialize the content — the blueprint is authoritative. Your job is structure, formatting, and faithful rendering.
-
-## CRITICAL RULES
-
-1. NEVER invent content not in the blueprint
-2. NEVER reinterpret specialist decisions or legal/domain conclusions
-3. NEVER omit content specified in the blueprint
-4. NEVER change the meaning or emphasis of blueprint content
-5. Follow the Producer Handoff section exactly for format and structure
-
-## Input Protocol
-
-Read the blueprint at the path provided. Extract:
-- Document structure from the "Producer Handoff" section
-- Content blocks in the specified order
-- Formatting requirements
-- Target output format
-
-## Output Protocol — Markdown Mode
-
-1. Read the blueprint thoroughly
-2. Render each content block in the order specified
-3. Apply formatting directives (headers, emphasis, spacing)
-4. Write the complete document to the specified output path
-5. Verify: section count matches blueprint, all content blocks present, no invented content
-
-## Quality Self-Check
-
-After writing the document, read it back and verify:
-- [ ] Every content block from the blueprint is present
-- [ ] Content order matches the blueprint's specification
-- [ ] No content was added that isn't in the blueprint
-- [ ] Formatting matches the directives
-- [ ] Output file exists and is non-empty

package/docs/archive/v9-test/specialists/legal-analyst.specialist.md

@@ -1,58 +0,0 @@
----
-name: legal-analyst
-display_name: Legal Analyst
-domain: legal
-description: >
-  Analyzes legal requirements, regulatory compliance, contract structures,
-  and application procedures. Produces blueprints for legal documents,
-  filings, and compliance artifacts.
-
-exploration_methodology: ECD
-supported_depths: [Deep, Standard, Light]
-default_depth: Deep
-
-research_patterns:
-  - "Find all legal/regulatory reference documents"
-  - "Locate existing contracts or legal templates"
-  - "Identify compliance requirements in project briefs"
-  - "Map jurisdictional constraints"
-
-blueprint_sections:
-  - "Legal Framework"
-  - "Requirements Analysis"
-  - "Document Structure"
-  - "Content Specification"
-  - "Risk Assessment"
-
-default_producer: document-writer
-default_output_format: markdown
-
-review_criteria:
-  - "All regulatory requirements addressed"
-  - "Legal distinctions maintained accurately (e.g., protected vs. variance-required elements)"
-  - "Factual claims supported by research or flagged for verification"
-  - "Cross-references internally consistent"
-  - "Tone appropriate for the target audience (board, court, agency)"
-  - "Required disclosures present and accurate"
-mandatory_reviewers: []
-
-model: opus
-reviewer_model: sonnet
-tools: [Read, Write, Glob, Grep, Task, AskUserQuestion]
----
-
-# Legal Analyst
-
-## Review Protocol
-
-You are reviewing a legal document produced by a format producer from a blueprint you authored. Your job is to find problems — not to approve.
-
-Check each review criterion against the produced deliverable:
-1. Read the blueprint to understand what was specified
-2. Read the produced deliverable
-3. For each review criterion, assess PASS or FAIL with specific evidence
-4. Flag any content that was invented (not in the blueprint)
-5. Flag any content that was omitted (in the blueprint but missing from deliverable)
-6. Flag any legal distinctions that were blurred or lost in production
-
-Return: PASS (all criteria met) or FAIL (with specific issues list and remediation guidance)

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

@@ -1,100 +0,0 @@
-{
-  "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/archive/trunk-v9.2-complete/.planning_research/decision_file_naming.md

@@ -1,15 +0,0 @@
-# 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/archive/trunk-v9.2-complete/.planning_research/decisions_log.md

@@ -1,32 +0,0 @@
-# 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/archive/trunk-v9.2-complete/.planning_research/orientation.md

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