@tgoodington/intuition 11.9.1 → 11.10.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.9.1",
+  "version": "11.10.0",
   "description": "Domain-adaptive workflow system for Claude Code. Includes the Enuncia pipeline (discovery, compose, design, execute, verify) and the classic pipeline (prompt, outline, assemble, detail, build, test, implement).",
   "keywords": [
     "claude-code",

package/skills/intuition-debugger/SKILL.md

@@ -19,7 +19,7 @@ These are non-negotiable. Violating any of these means the protocol has failed.
 7. You MUST delegate code changes to subagents for anything beyond trivial fixes (1-3 lines in a single file).
 8. You MUST analyze architectural implications of every issue. When a fix requires design-level changes, generate a fast-track brief — do NOT punt with a vague "go run the workflow."
 9. You MUST NOT implement architectural or design-level changes directly. Present the analysis, generate the fast-track brief, and let the user route it.
-10. You MUST NOT modify outline.md, design specs, prompt_brief.md, or any workflow planning artifacts directly.
+10. You MUST NOT modify workflow planning artifacts directly — `discovery_brief.md` and `tasks.json` (Enuncia), or `outline.md`, `prompt_brief.md`, and design specs (classic).
 11. You MUST verify fixes don't break dependent code.
 12. You MUST log every fix to `docs/project_notes/bugs.md` AND save an Intuition memory when findings have cross-conversation value.
 13. You MUST maintain session context across the feedback loop. Follow-up issues inherit the full diagnostic picture — never restart from scratch.
@@ -93,7 +93,19 @@ Resolve `context_path` from selected context:
 
 # STEP 3: LOAD CONTEXT ARTIFACTS
 
-Read ALL of these before proceeding — build your understanding of what was built and why:
+Check `state.pipeline` and load the artifact set for the pipeline that built this context. Read ALL that apply before proceeding — build your understanding of what was built and why.
+
+**Enuncia pipeline (`state.pipeline == "enuncia"`):**
+
+- `{context_path}/discovery_brief.md` — the foundation: stakeholders, delivery, requirements, North Star, decision posture
+- `{context_path}/tasks.json` — experience slices and tasks with design enrichment (technical approach, interfaces, files, decisions)
+- `{context_path}/build_output.json` — what was actually built, review outcomes, deviations, escalations
+- `docs/project_notes/project_map.md` — the living architecture document: capabilities by slice, component reference, operational foundation, key connections. This is your primary map of how the pieces connect — trace the reported issue through it to understand upstream/downstream impact before reading source code. (Check its truth-window line: a map not yet reconciled with code describes the design, not necessarily reality.)
+- `docs/project_notes/key_facts.md` — project-wide knowledge
+- `docs/project_notes/decisions.md` — architectural decisions (ADRs)
+- `docs/project_notes/bugs.md` — previously logged bugs
+
+**Classic pipeline (anything else):**
 
 - `{context_path}/outline.md` — what was planned
 - `{context_path}/code_specs.md` — engineering decisions (if exists)
@@ -104,12 +116,10 @@ Read ALL of these before proceeding — build your understanding of what was bui
 - `docs/project_notes/decisions.md` — architectural decisions (ADRs)
 - `docs/project_notes/bugs.md` — previously logged bugs
 - `{context_path}/scratch/*-decisions.json` — specialist decisions (if any exist)
-
-Also check for blueprints and process flow:
 - `{context_path}/blueprints/*.md` — detailed specialist blueprints (if detail phase ran)
-- `{context_path}/process_flow.md` (if exists) — end-to-end user flows, component interactions, data paths, error paths, state mutations, integration seams, known invariants. This is your primary map of how the app works. Use it to understand upstream/downstream impact before reading source code.
+- `{context_path}/process_flow.md` (if exists) — end-to-end user flows, component interactions, data paths, error paths, state mutations, integration seams, known invariants. This is your primary map of how the app works.
 
-The gap between intended approach and actual implementation is where bugs hide. The decisions files tell you what constraints MUST be preserved. The process flow document tells you how the pieces connect — trace the reported issue through the flow to understand the full impact chain.
+The gap between intended approach and actual implementation is where bugs hide. The decisions files tell you what constraints MUST be preserved. The map (Enuncia) or process flow document (classic) tells you how the pieces connect — trace the reported issue through it to understand the full impact chain.
 
 Do NOT read source code files yet. Read targeted code only after the user describes the issue.
 
@@ -155,7 +165,7 @@ Start with the immediate issue:
 With the root cause identified, evaluate through EVERY lens:
 
 **Architectural Alignment:**
-- Re-read the outline goals and any design specs. Does the root cause reveal a conflict with the system's design intent?
+- Re-read the planning artifacts loaded in Step 3 — the discovery brief's goals/North Star and enriched tasks.json (Enuncia), or the outline goals and design specs (classic). Does the root cause reveal a conflict with the system's design intent?
 - Does the affected code follow the patterns established elsewhere, or is it an outlier?
 - Cross-reference `docs/project_notes/decisions.md` — does the issue violate any architectural decisions?
 
@@ -165,7 +175,7 @@ With the root cause identified, evaluate through EVERY lens:
 - Check: input validation, output encoding, auth boundaries, data exposure.
 
 **Ripple Effects:**
-- If `{context_path}/process_flow.md` exists, start with it: identify which Core Flows pass through the affected area, what's upstream and downstream, and what state mutations or integration seams are involved. Use the Component Dependencies and Integration Seams sections to pre-map the blast radius before launching a researcher.
+- On an Enuncia context, start from `docs/project_notes/project_map.md` (already loaded in Step 3): identify which Capabilities pass through the affected area and use the slices' Key connections and the Component Reference to pre-map the blast radius before launching a researcher. On a classic context, if `{context_path}/process_flow.md` exists, start with it: identify which Core Flows pass through the affected area, what's upstream and downstream, and what state mutations or integration seams are involved.
 - Launch an `intuition-researcher` agent to verify and extend the process flow mapping against actual code:
   ```
   "Map all imports, usages, and dependents of [affected module/function/interface]
@@ -173,7 +183,7 @@ With the root cause identified, evaluate through EVERY lens:
   on this module, and whether any usage makes assumptions about behavior that
   the fix would change. Under 500 words."
   ```
-- Check `{context_path}/scratch/*-decisions.json` — will the fix contradict any `[USER]` decisions? If so, you MUST escalate to the user before proceeding.
+- Check the recorded user decisions — the `decisions` and `design_decisions` fields in `{context_path}/tasks.json` (Enuncia), or `{context_path}/scratch/*-decisions.json` (classic). Will the fix contradict any `[USER]` decisions? If so, you MUST escalate to the user before proceeding.
 
 **Maintenance:**
 - Does the root cause suggest a pattern that will recur? Is this a one-off or systemic?
@@ -183,7 +193,7 @@ With the root cause identified, evaluate through EVERY lens:
 **Functionality:**
 - Does the obvious fix fully resolve the issue, including edge cases?
 - Are there error states or boundary conditions the fix must handle?
-- Cross-reference the outline's acceptance criteria — does the fix preserve them?
+- Cross-reference the acceptance criteria — in `tasks.json` (Enuncia) or the outline (classic). Does the fix preserve them?
 
 ---
 
@@ -235,7 +245,7 @@ Not every issue needs all three types. Use judgment. But NEVER present only one
 Before presenting to the user, review your own options:
 
 For each option, ask:
-- Does this fix work WITH the system's architectural intent? (Re-read outline goals)
+- Does this fix work WITH the system's architectural intent? (Re-read the North Star and tasks.json on Enuncia; the outline goals on classic)
 - Have I accounted for every ripple effect the researcher identified?
 - Am I confident this doesn't introduce a security surface?
 - Is there a simpler approach I haven't considered?
@@ -397,13 +407,10 @@ After the subagent returns:
 - **Prevention**: [How to avoid in future — what should the build process catch?]
 ```
 
-**Update process flow (conditional)** — If `{context_path}/process_flow.md` exists AND the fix changes how a flow actually works (e.g., adds error handling that changes an error path, restructures a component interaction, or modifies state mutations):
-1. Read the current process_flow.md
-2. Update ONLY the specific flow section affected by the fix
-3. Add an entry to the Flow History table: `| [YYYY-MM-DD] | Debugger | [What changed] | [Fix for: brief issue description] |`
-4. Add or update the Known Fragile Areas section if the investigation revealed a fragile pattern
+**Update the architecture document (conditional)** — only when the fix changes how something actually works (e.g., adds error handling that changes an error path, restructures a component interaction, or modifies state mutations). Skip for fixes that don't change behavior (a typo, a calculation correction that doesn't change the data path). When generating a fast-track brief (upstream fix), do NOT update — the upstream workflow will update it after implementing changes.
 
-Do NOT update process_flow.md for fixes that don't change flow behavior (e.g., fixing a typo, correcting a calculation that doesn't change the data path). Do NOT rewrite the Overview or restructure the document. When generating a fast-track brief (upstream fix), do NOT update process_flow.md — the upstream workflow will update it after implementing changes.
+- **Enuncia context**: update `docs/project_notes/project_map.md` — refine ONLY the affected `## Capabilities` slice or `## Component Reference` entries, at the map's existing terseness. Never touch `## Project North Star` or `## Branch Goals`, and do not stamp the truth-window line (that belongs to the pipeline phases).
+- **Classic context**: if `{context_path}/process_flow.md` exists, update ONLY the specific flow section affected by the fix, add an entry to the Flow History table (`| [YYYY-MM-DD] | Debugger | [What changed] | [Fix for: brief issue description] |`), and add or update the Known Fragile Areas section if the investigation revealed a fragile pattern. Do NOT rewrite the Overview or restructure the document.
 
 **Save Intuition memory** — When the investigation reveals something with cross-conversation value, save a memory file to `C:\Users\tgoodington\.claude\projects\C--Claude-Projects-Intuition\memory\`:
 
@@ -504,7 +511,7 @@ If "done" → close.
 
 When an issue's root cause is upstream (plan or design was wrong) or the best fix requires architectural adjustment beyond the debugger's implementation authority, generate a brief designed to be fast-track eligible.
 
-The debugger's diagnostic work IS the research that prompt/outline phases would normally perform. Carry that intelligence forward.
+The debugger's diagnostic work IS the research the early workflow phases would normally perform (discovery/compose on Enuncia; prompt/outline on classic). Carry that intelligence forward.
 
 **Write to `{context_path}/debugger_brief.md`:**
 
@@ -522,18 +529,18 @@ The debugger's diagnostic work IS the research that prompt/outline phases would
 - **Causal chain**: [full chain from investigation]
 
 ## Scope
-[1-4 specific, bounded tasks needed — written as outline-ready items]
+[1-4 specific, bounded tasks needed — written as decomposition-ready items]
 
 Each task:
 - **Task N**: [title]
   - Description: [what needs to change]
   - Acceptance criteria: [how to verify]
-  - Depth: Light
-  - Rationale: [why Light — the debugger already analyzed this thoroughly]
+  - Sizing: small — express track (Enuncia) / Light depth (classic)
+  - Rationale: [why it's small — the debugger already analyzed this thoroughly]
 
 ## Constraints
 - MUST preserve: [interfaces, behaviors, contracts that cannot change]
-- MUST NOT violate: [list any [USER] decisions from decisions.json]
+- MUST NOT violate: [list any [USER] decisions — from tasks.json (Enuncia) or decisions.json (classic)]
 - Security considerations: [from five-lens analysis]
 - Dependent code: [files/modules that must remain compatible]
 
@@ -546,7 +553,8 @@ Each task:
 
 **After writing the brief:**
 - Update `.project-memory-state.json`: Do NOT change `status` from `"complete"`. The brief is a recommendation, not a state transition. The user decides when to act on it.
-- Tell the user: "I've written a fast-track brief at `{context_path}/debugger_brief.md`. It's scoped to [N] tasks, all Light depth — should be eligible for fast track when you run it through `/intuition-start`. The diagnostic evidence is included so the workflow won't repeat this investigation."
+- Tell the user (Enuncia context): "I've written a fast-track brief at `{context_path}/debugger_brief.md`, scoped to [N] small tasks. Run `/intuition-enuncia-handoff` to branch this work — it should triage as a focused change (express track). The diagnostic evidence is included so the workflow won't repeat this investigation."
+- Tell the user (classic context): "I've written a fast-track brief at `{context_path}/debugger_brief.md`. It's scoped to [N] tasks, all Light depth — should be eligible for fast track when you run it through `/intuition-start`. The diagnostic evidence is included so the workflow won't repeat this investigation."
 
 ---
 

package/skills/intuition-enuncia-compose/SKILL.md

@@ -25,7 +25,7 @@ You are a decomposition thinker. You see a vision and ask "what needs to be true
 7. You MUST write `tasks.json`, `docs/project_notes/project_map.md`, and update state before routing.
 8. You MUST route to `/intuition-enuncia-design` — EXCEPT on the express track when you fold design in (no genuine technical decision), where you route to `/intuition-enuncia-execute` (see EXPRESS MODE). NEVER to `/intuition-enuncia-handoff`.
 9. You MUST load three goals at activation (Project North Star, Branch Goal if on a branch, and your own Skill Goal) and hold them in working memory throughout the skill's run. See GOAL ALIGNMENT.
-10. You MUST NOT overwrite the `## Project North Star`, `## Branch Goals`, or `## Operational Foundation` sections in `project_map.md`. The first two are owned by discovery; the third is owned by design. You own `## Overview`, `## Capabilities`, and `## Component Reference`. Append history rows to `docs/project_notes/map_history.md`, not inside `project_map.md`.
+10. You MUST NOT overwrite the `## Project North Star`, `## Branch Goals`, or `## Operational Foundation` sections in `project_map.md`. The first two are owned by discovery; the third is owned by design. You own `## Overview`, `## Capabilities`, and `## Component Reference`, plus updating the truth-window line.
 11. You MUST run the alignment check before routing — output must serve Project North Star, Branch Goal (if branch), and Skill Goal. See GOAL ALIGNMENT → Alignment Check.
 
 ## CONTEXT PATH RESOLUTION
@@ -74,11 +74,34 @@ Before writing outputs or routing, run the last-stop check:
 - **Skill Goal**: Is the output decomposition-level work (experience slices, producer-ready tasks, project map updates) — not technical decisions that belong to design, not specs that belong to producers?
 - **Project map consistency**: Does every slice you wrote to `## Capabilities` trace to a stakeholder in the brief, and does every component you listed in `## Component Reference` correspond to the output of at least one task in tasks.json? No orphan slices, no components without a producing task.
 
-If any check fails, correct the output before presenting. If you cannot correct it within this skill (e.g., a missing stakeholder coverage that needs to go back to discovery), flag it explicitly to the user rather than shipping misaligned output.
+### How the Check Runs
+
+**Express track:** run the four checks yourself (self-check). Scale-to-task — no subagent.
+
+**Full track:** the check is independent — fresh eyes, not the author grading its own work. Spawn ONE `intuition-reviewer` agent via the Task tool:
+
+```
+You are an alignment reviewer. You did not write these artifacts — judge them skeptically against the goals below.
+
+Project North Star:
+[paste verbatim]
+
+[If branch] Branch Goal for "{active_context}":
+[paste verbatim]
+
+Skill under review: compose. Its output must be decomposition-level work — experience slices, producer-ready tasks, map updates.
+
+Read {context_path}/tasks.json and docs/project_notes/project_map.md, then verify each item of this rubric:
+[paste the four Alignment Check bullets above, with the brief's stakeholder list included for the map-consistency check]
+
+Return: PASS + one-line confirmation, OR specific findings — each naming the slice, task, or map section it points at.
+```
+
+On findings: correct the output, then re-run the reviewer once. If findings persist after the correction, surface them to the user rather than shipping misaligned output. Either way, if a failure cannot be corrected within this skill (e.g., missing stakeholder coverage that needs to go back to discovery), flag it explicitly to the user.
 
 ## EXPRESS MODE
 
-Read `track` from the active context (missing = `"full"`). When `track == "express"`:
+Read `track` from the active context (missing or null = `"full"`). When `track == "express"`:
 - Skip Phase 2's full experience-mapping dialogue. Draft the experience slices directly from the brief and confirm them in a single pass.
 - Decompose into tasks as usual — expect few. The producer-ready test still applies.
 - Do NOT create test tasks (see Test Coverage).
@@ -422,17 +445,9 @@ Anti-bloat rules:
 - No class names, method names, enum values, file paths, or CSS selectors — those live in code.
 - Component Reference entries are ONE sentence. If you can't fit it, the component is doing too much or you're describing at the wrong level.
 
-Append a row to `docs/project_notes/map_history.md` (NOT to `project_map.md`):
-
-- If `map_history.md` does not exist, create it from `references/project_map_history_template.md`.
-- If `project_map.md` contains a legacy `## Map History` section (pre-v11.7 scaffold), move its rows into `map_history.md` preserving order, then delete the section from `project_map.md`.
-- Then append:
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Compose | [active_context] | Initial outline | Created from experience mapping |
+**Truth-window line:** update the `_Reflects: …_` line directly under the `# Project Map` title to `_Reflects: compose ([today ISO date]) · Reconciled with code: [keep existing value]_`. If the line is absent (older project), add it with `Reconciled with code: never`.
 
-Legacy section cleanup (one-time, transparent): if `project_map.md` still contains `## Components`, `## Component Interactions`, or `## What Exists vs What's New` from a pre-v11.7 scaffold, delete those sections and write the new shape above in their place. This backfill runs silently.
+Legacy section cleanup (one-time, transparent): if `project_map.md` still contains `## Components`, `## Component Interactions`, or `## What Exists vs What's New` from a pre-v11.7 scaffold, delete those sections and write the new shape above in their place. If it contains a legacy inline `## Map History` section, delete it — map history is no longer tracked (v11.10). This backfill runs silently.
 
 ### Alignment Check
 
@@ -481,7 +496,7 @@ The branch `tasks.json` is a complete document (not a diff) but includes a `pare
 }
 ```
 
-Update `docs/project_notes/project_map.md` — add new slices to `## Capabilities` in place, refine existing slices if the branch modifies them, and add any new components to `## Component Reference`. Do not tag slices or components with the branch name; presence in the map means in use. Append the branch's entry to `docs/project_notes/map_history.md` per the format above.
+Update `docs/project_notes/project_map.md` — add new slices to `## Capabilities` in place, refine existing slices if the branch modifies them, and add any new components to `## Component Reference`. Do not tag slices or components with the branch name; presence in the map means in use. Update the truth-window line per the format above.
 
 Branch outlines should be faster — most of the experience mapping is inherited. Focus the conversation on what's new.
 

package/skills/intuition-enuncia-design/SKILL.md

@@ -27,7 +27,7 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
 9. You MUST route to `/intuition-enuncia-execute` after completion. NEVER to `/intuition-enuncia-handoff`.
 10. You MUST NOT write code. You write specs that describe what code to write. Producers write code.
 11. You MUST load three goals at activation (Project North Star, Branch Goal if on a branch, and your own Skill Goal) and hold them in working memory throughout the skill's run. See GOAL ALIGNMENT.
-12. You own `## Operational Foundation` in `project_map.md`. You may refine compose's `## Capabilities` and `## Component Reference` sections with real architecture detail, but keep their shape and terseness. You MUST NOT touch `## Project North Star` or `## Branch Goals` — those are owned by discovery. Append history rows to `docs/project_notes/map_history.md`, not inside `project_map.md`.
+12. You own `## Operational Foundation` in `project_map.md`. You may refine compose's `## Capabilities` and `## Component Reference` sections with real architecture detail, but keep their shape and terseness. You MUST NOT touch `## Project North Star` or `## Branch Goals` — those are owned by discovery. Update the truth-window line when you write the map.
 13. You MUST run the alignment check before routing — output must serve Project North Star, Branch Goal (if branch), and Skill Goal. See GOAL ALIGNMENT → Alignment Check.
 
 ## CONTEXT PATH RESOLUTION
@@ -74,11 +74,34 @@ Before writing outputs or routing, run the last-stop check:
 - **Skill Goal**: Is the output design-level specs — not code (that's producers), not decomposition (that's compose), not implementation (that's execute)?
 - **Project map consistency**: Do the components and connections you wrote into `## Operational Foundation`, `## Capabilities`, and `## Component Reference` match the interfaces and files in the enriched tasks.json? Every component you name should be produced by some task's `files`; every cross-task interface should surface as a "Key connection" in the relevant slice. The map and tasks.json must tell the same architectural story.
 
-If any check fails, correct before proceeding. If you cannot correct within this skill, flag it explicitly to the user.
+### How the Check Runs
+
+**Express track:** run the four checks yourself (self-check). Scale-to-task — no subagent.
+
+**Full track:** the check is independent — fresh eyes, not the author grading its own work. Spawn ONE `intuition-reviewer` agent via the Task tool:
+
+```
+You are an alignment reviewer. You did not write these artifacts — judge them skeptically against the goals below.
+
+Project North Star:
+[paste verbatim]
+
+[If branch] Branch Goal for "{active_context}":
+[paste verbatim]
+
+Skill under review: design. Its output must be design-level specs — technical approach, interfaces, files, decisions on each task — not code, not decomposition.
+
+Read {context_path}/tasks.json (the enriched design fields) and docs/project_notes/project_map.md, then verify each item of this rubric:
+[paste the four Alignment Check bullets above]
+
+Return: PASS + one-line confirmation, OR specific findings — each naming the task, field, or map section it points at.
+```
+
+On findings: correct the output, then re-run the reviewer once. If findings persist after the correction, surface them to the user rather than shipping misaligned output. Either way, if a failure cannot be corrected within this skill, flag it explicitly to the user.
 
 ## EXPRESS MODE
 
-Read `track` from the active context (missing = `"full"`). On the express track, compose may have already folded design in and skipped this phase — if you were routed here at all, the work carries a real technical decision that needs you.
+Read `track` from the active context (missing or null = `"full"`). On the express track, compose may have already folded design in and skipped this phase — if you were routed here at all, the work carries a real technical decision that needs you.
 
 When `track == "express"`:
 - Design only what's necessary. Skip Phase 2.5 (Operational Foundation) unless the change actually touches deployment/infra.
@@ -183,6 +206,8 @@ Launch `intuition-researcher` agents to gather technical context. Research is ta
 
 Research agents are optional — skip them when the technical approach is obvious from the tasks and map.
 
+**Specialist lens.** When a slice group sits squarely in a domain with a matching profile in the `specialists/` registry (scan `.claude/specialists/`, then `~/.claude/specialists/`) — e.g., database architecture, legal analysis, business analysis — read that profile and fold its question-set and risk knowledge into this group's research prompts and your own design thinking. This is a lens, not a gate: no extra approval step, no separate specialist phase. Skip it when no profile clearly matches.
+
 ### 3b. Design Decisions
 
 For each group, determine:
@@ -300,7 +325,7 @@ The principle: design tells the UI producer what must be TRUE about the interfac
 - **`files`**: the test file paths to create.
 - **`producer_notes`**: fixtures, mocks, or seed data the tests need; and what NOT to test (don't test framework internals or third-party code).
 
-Record the suite run command in `## Operational Foundation` (or `key_facts.md`) so verify can find and run it later — verify's regression step depends on knowing how to invoke the suite.
+Record the suite run command in the map's `## Operational Foundation` — that is its canonical home, and verify's regression step reads it from there.
 
 After enrichment, each task object should contain everything a producer needs. No ambiguity, no open questions.
 
@@ -345,11 +370,7 @@ Anti-bloat rules:
 - Never expand a Component Reference entry past one sentence. If the architectural detail is important, point to code.
 - No task IDs, no status fields, no stakeholder-touchpoint tags. If a decision or tradeoff is worth recording, write to `docs/project_notes/decisions.md`, not the map.
 
-Append a row to `docs/project_notes/map_history.md`. Create the file from `references/project_map_history_template.md` if missing; migrate any legacy inline `## Map History` section out of `project_map.md` and delete it.
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Design | [active_context] | Architecture finalized | [one sentence] |
+**Truth-window line:** update the `_Reflects: …_` line directly under the `# Project Map` title to `_Reflects: design ([today ISO date]) · Reconciled with code: [keep existing value]_`. If the line is absent (older project), add it with `Reconciled with code: never`. If the map still contains a legacy inline `## Map History` section, delete it — map history is no longer tracked (v11.10).
 
 ### Alignment Check
 

package/skills/intuition-enuncia-discovery/SKILL.md

@@ -30,7 +30,7 @@ You help users figure out what they're building. You do this through focused con
 12. On branches, you MUST revisit the existing Project North Star at the start of the conversation and confirm it still stands (or propose a trunk-level amendment). See BRANCH MODE → Revisit Project North Star.
 13. You MUST run the Exit Protocol after writing the brief and updating the map. Route to `/intuition-enuncia-compose`.
 14. You MUST NOT launch research agents proactively. Research fires ONLY when the user asks something you cannot confidently answer (see REACTIVE RESEARCH).
-15. You MUST read `track` from the active context and, when `track == "express"`, compress the conversation per EXPRESS MODE. A missing `track` defaults to `"full"`.
+15. You MUST read `track` from the active context and, when `track == "express"`, compress the conversation per EXPRESS MODE. A missing or null `track` reads as `"full"` for depth — but null also means triage never ran (see EXPRESS MODE).
 16. At activation, after reading state, you MUST set `workflow.discovery.started = true` on the active context and write state back — before any dialogue. This closes the TRIAGE gate so a re-run of `start` mid-discovery does not re-fire triage and re-ask the scope question.
 
 ## THE FOUR DIMENSIONS
@@ -85,7 +85,7 @@ When authoring a Project North Star or a Branch Goal, apply these three rules. T
 
 ## EXPRESS MODE
 
-Read `track` from the active context in `.project-memory-state.json` at activation (a missing value means `"full"`). If `track` is unset AND discovery hasn't started, the entry bypassed start's triage — ask the one Scope question from start's TRIAGE yourself, record the answer as `track` on the active context, then proceed.
+Read `track` from the active context in `.project-memory-state.json` at activation. A null or missing `track` means triage never ran — initialize and handoff seed it as null ("nobody asked yet"), so the direct `initialize → discovery` and `handoff → discovery` routes land here. If `track` is null or missing AND discovery hasn't started, ask the one Scope question from start's TRIAGE yourself, record the answer as `track` on the active context, then proceed. (If discovery already started with track still null — a legacy state — read it as `"full"` and don't re-ask.)
 
 When `track == "express"`, compress hard:
 - Open by stating your read of all four dimensions inferred from the user's request, and ask only what you genuinely cannot infer — target one question, two at most.
@@ -148,7 +148,7 @@ Does the Project North Star still hold for this work, or does the scope of this
 
 Accept one of three outcomes:
 - **Holds as-is** — keep it unchanged, proceed to Opening.
-- **Needs amendment** — work with the user to refine the Project North Star at altitude (apply the three rules). Then update the `## Project North Star` section of `docs/project_notes/project_map.md` in place. Also update the trunk discovery brief's Why section to match so the two stay in sync. Append a row to `docs/project_notes/map_history.md` (Phase: "Discovery (branch revisit)", Branch: `[active_context]`, Change: "Amended Project North Star", Reason: "[branch-provided rationale]"). Proceed to Opening.
+- **Needs amendment** — work with the user to refine the Project North Star at altitude (apply the three rules). Then update the `## Project North Star` section of `docs/project_notes/project_map.md` in place. Also update the trunk discovery brief's Why section to match so the two stay in sync. Proceed to Opening.
 - **User wants to think about it** — move on to Opening, and come back to this before writing the brief.
 
 #### Opening
@@ -191,7 +191,7 @@ Add a `## Parent Context` section at the top:
 - **Parent**: [trunk or branch name]
 - **Inherited dimensions**: [list dimensions unchanged from parent]
 - **Changed dimensions**: [list dimensions this branch modifies, with brief rationale]
-- **Project North Star**: Holds as-is | Amended this session (see Map History)
+- **Project North Star**: Holds as-is | Amended this session
 ```
 
 This lets downstream skills know what's new without reading the parent brief.
@@ -297,7 +297,7 @@ After confirm and posture, write `{context_path}/discovery_brief.md`. The Why se
 - **Parent**: [trunk or branch name]
 - **Inherited dimensions**: [list dimensions unchanged from parent]
 - **Changed dimensions**: [list what changed and why]
-- **Project North Star**: Holds as-is | Amended this session (see Map History)
+- **Project North Star**: Holds as-is | Amended this session
 
 ## Who — Stakeholders
 [Stakeholders and their relationship to the project]
@@ -342,18 +342,14 @@ Keep every section terse. Bullets over prose. No redundancy between sections. Th
 
 After writing `discovery_brief.md`, propagate the goal statement into `docs/project_notes/project_map.md`. This is the single source of truth that every downstream skill loads at activation.
 
-Read the current `docs/project_notes/project_map.md` first (it was created by initialize; in trunk mode it may still contain the scaffold placeholder). Preserve every other section — only touch the `## Project North Star` section (trunk) or the `## Branch Goals` section (branch).
+Read the current `docs/project_notes/project_map.md` first (it was created by initialize; in trunk mode it may still contain the scaffold placeholder). Preserve every other section — only touch the `## Project North Star` section (trunk) or the `## Branch Goals` section (branch), plus the truth-window line.
+
+**Truth-window line:** update the `_Reflects: …_` line directly under the `# Project Map` title to `_Reflects: discovery ([today ISO date]) · Reconciled with code: [keep existing value]_`. If the line is absent (older project), add it with `Reconciled with code: never`.
 
 ### Trunk Mode
 
 Replace the `## Project North Star` section body with the verbatim content from the brief's `## Why — Project North Star` section. Remove any scaffold placeholder text in that section. Do not touch `## Branch Goals`, `## Overview`, `## Capabilities`, `## Component Reference`, `## Operational Foundation`, or any other section — compose and design fill those.
 
-Append a row to `docs/project_notes/map_history.md` (see Backfill below if the file doesn't exist yet):
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Discovery | trunk | Authored Project North Star | Trunk discovery complete |
-
 ### Branch Mode
 
 Under the `## Branch Goals` section, add a subsection for this branch (or update if one already exists):
@@ -365,17 +361,11 @@ Under the `## Branch Goals` section, add a subsection for this branch (or update
 
 Place branch subsections in creation order. Do not touch the `## Project North Star` section here — that was either left unchanged (Holds as-is) or already amended during the Revisit step.
 
-Append a row to `docs/project_notes/map_history.md`:
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Discovery (branch) | [active_context] | Authored Branch Goal | Branch discovery complete |
-
 ### Backfill (Existing Projects)
 
 If `project_map.md` lacks a `## Project North Star` section entirely (project created before v11.6.0), insert one immediately after the `# Project Map` title. If `## Branch Goals` is missing, insert it immediately below the Project North Star section.
 
-If `docs/project_notes/map_history.md` does not exist (project created before v11.7.0), create it from `references/project_map_history_template.md`. If `project_map.md` contains a legacy inline `## Map History` section, move those rows into `map_history.md` preserving order, then delete the section from `project_map.md`. Legacy rows that predate the Branch column: set Branch to "trunk" or the best inferable value.
+If `project_map.md` contains a legacy inline `## Map History` section (pre-v11.7), delete it — map history is no longer tracked (v11.10). The truth-window line replaces it.
 
 This backfill runs silently — no user notification needed; the map now conforms.
 

package/skills/intuition-enuncia-execute/SKILL.md

@@ -96,7 +96,7 @@ Read these files:
 
 Validate: every task in `tasks.json` has a `technical_approach` field (indicating design enrichment). If any task lacks a `technical_approach`, inform the user and ask whether to proceed with partial specs or run design first.
 
-Also read `track` from the active context (missing = `"full"`). On the express track, expect a small plan and no `test/*` tasks — keep the plan confirmation brief. On the full track, `test/*` tasks should be present for logic-bearing slices; produce them after the code they cover (their dependencies enforce the order).
+Also read `track` from the active context (missing or null = `"full"`). On the express track, expect a small plan and no `test/*` tasks — keep the plan confirmation brief. On the full track, `test/*` tasks should be present for logic-bearing slices; produce them after the code they cover (their dependencies enforce the order).
 
 From each task object, extract:
 - `task.technical_approach` and `task.files`
@@ -299,11 +299,7 @@ Non-code deliverables (documents, spreadsheets, etc.) skip security review.
 
 If implementation revealed anything not in the map — new components, changed dependencies, refined connections — update the relevant `## Capabilities` slice or add to `## Component Reference`. Keep entries at the same terseness compose and design used; don't introduce implementation-detail paragraphs. **Do not touch `## Project North Star` or `## Branch Goals`.**
 
-Append a row to `docs/project_notes/map_history.md` for the execute phase. Create the file from template if missing; migrate any legacy inline `## Map History` out of `project_map.md` if present.
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Execute | [active_context] | [summary of what was built] | [one sentence] |
+If you wrote to the map, update the truth-window line directly under the `# Project Map` title to `_Reflects: execute ([today ISO date]) · Reconciled with code: [keep existing value]_` (add the line with `Reconciled with code: never` if absent).
 
 ### Display Summary
 
@@ -313,9 +309,23 @@ Present a concise summary to the user: task count, pass/fail, files produced, an
 
 **Alignment Check.** Before updating state or routing, run the GOAL ALIGNMENT → Alignment Check against the three loaded goals. If any check fails, re-delegate, escalate, or flag. Do not ship misaligned output.
 
-**Update state.** Read `.project-memory-state.json`. Target active context. Set: `status` → `"verify"`, `workflow.execute.completed` → `true`, `workflow.execute.completed_at` → current ISO timestamp, `workflow.verify.started` → `true`. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"execute_to_verify"`. Write back.
+**Update state and route** — branch on what was produced:
+
+**If any deliverable is code, configuration, or scripts** (anything that runs): Read `.project-memory-state.json`. Target active context. Set: `status` → `"verify"`, `workflow.execute.completed` → `true`, `workflow.execute.completed_at` → current ISO timestamp, `workflow.verify.started` → `true`. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"execute_to_verify"`. Write back. Route to `/intuition-enuncia-verify`.
+
+**If only non-code deliverables** (documents, spreadsheets, presentations, data files): there is no live system to verify, and verify must not be left dangling in state. Ask via AskUserQuestion:
+
+```
+Question: "All deliverables are [types] — there's no live system for the verify phase to test. Mark the workflow complete?"
+Header: "Wrap Up"
+Options:
+- "Complete — the deliverables are what I needed"
+- "Not yet — something's missing"
+```
+
+On "Complete": set on target: `status` → `"complete"`, `workflow.execute.completed` → `true`, `workflow.execute.completed_at` → now, `workflow.verify.completed` → `true`, `workflow.verify.completed_at` → now. Set on root: `last_handoff` → now, `last_handoff_transition` → `"execute_to_complete"`. Write back. Tell the user the workflow is complete.
 
-**Route.** Tell the user the next step. If code was produced, route to `/intuition-enuncia-verify`. If only non-code deliverables, workflow may be complete — ask the user.
+On "Not yet": leave state untouched — `workflow.execute.completed` stays `false` so `start` routes back to execute, and RESUME LOGIC picks up the task board. Work out with the user what's missing: re-delegation of a deliverable, or a gap that needs a new branch.
 
 ## BRANCH MODE
 

package/skills/intuition-enuncia-handoff/SKILL.md

@@ -49,7 +49,7 @@ If the user hasn't provided branch details, collect via AskUserQuestion:
   "created_at": "ISO timestamp",
   "purpose": "User-provided purpose",
   "status": "none",
-  "track": "full",
+  "track": null,
   "workflow": {
     "discovery": { "started": false, "completed": false, "completed_at": null },
     "compose": { "started": false, "completed": false, "completed_at": null },
@@ -72,7 +72,7 @@ Branch "[display_name]" created.
 Run /clear then /intuition-enuncia-discovery
 ```
 
-Discovery, when it runs on this branch, will revisit the Project North Star from the project map (confirming or proposing amendment) and author a Branch Goal at the same altitude. You do not need to do anything with goals here — handoff only creates the branch.
+Discovery, when it runs on this branch, will triage the work's track (`track` starts as null — "nobody asked yet"), revisit the Project North Star from the project map (confirming or proposing amendment), and author a Branch Goal at the same altitude. You do not need to do anything with goals or track here — handoff only creates the branch.
 
 ## VOICE
 

package/skills/intuition-enuncia-initialize/SKILL.md

@@ -94,7 +94,6 @@ docs/
     ├── trunk/
     ├── branches/
     ├── project_map.md
-    ├── map_history.md
     ├── bugs.md
     ├── decisions.md
     ├── key_facts.md
@@ -113,7 +112,6 @@ For each file, use the Read tool to read the template, then use Write to create
 | `references/key_facts_template.md` | `docs/project_notes/key_facts.md` |
 | `references/issues_template.md` | `docs/project_notes/issues.md` |
 | `references/project_map_template.md` | `docs/project_notes/project_map.md` |
-| `references/project_map_history_template.md` | `docs/project_notes/map_history.md` |
 
 The project map template is a scaffold — compose and design fill it with real content during the workflow.
 
@@ -133,7 +131,7 @@ The state file uses the Enuncia v11 schema:
   "active_context": "trunk",
   "trunk": {
     "status": "none",
-    "track": "full",
+    "track": null,
     "workflow": {
       "discovery": {
         "started": false,
@@ -240,7 +238,7 @@ or /intuition-enuncia-start to check project status.
 These template files are in the `references/` directory. Use Read tool to access them:
 
 **Memory file templates** (Step 2):
-- `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`, `project_map_history_template.md`
+- `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`
 
 **State template** (Step 3):
 - `state_template.json` — Enuncia v11 workflow state

package/skills/intuition-enuncia-initialize/references/project_map_template.md

@@ -1,5 +1,9 @@
 # Project Map
 
+_Reflects: scaffold · Reconciled with code: never_
+
+<!-- Truth-window line. Every pipeline skill that writes this map updates the "Reflects" half with its phase name and today's date. Verify's Map Integrity Pass sets "Reflects: verified" and stamps "Reconciled with code". Until reconciled, sections below describe the design, not necessarily the running system. -->
+
 ## Project North Star
 [Populated by trunk discovery. The outcome this project is held to — specific about what "good" looks like, flexible about the how. Every Enuncia skill, on every branch, loads this at activation and checks its output against it before presenting.
 
@@ -44,4 +48,3 @@ Altitude rules for this section:
 - Decisions → `docs/project_notes/decisions.md`
 - Config, credentials, URLs → `docs/project_notes/key_facts.md`
 - Work log → `docs/project_notes/issues.md`
-- Map evolution by phase → `docs/project_notes/map_history.md`

package/skills/intuition-enuncia-initialize/references/state_template.json

@@ -5,7 +5,7 @@
   "active_context": "trunk",
   "trunk": {
     "status": "none",
-    "track": "full",
+    "track": null,
     "workflow": {
       "discovery": {
         "started": false,

package/skills/intuition-enuncia-start/SKILL.md

@@ -74,7 +74,7 @@ Default state schema:
   "active_context": "trunk",
   "trunk": {
     "status": "none",
-    "track": "full",
+    "track": null,
     "workflow": {
       "discovery": { "started": false, "completed": false, "completed_at": null },
       "compose": { "started": false, "completed": false, "completed_at": null },
@@ -163,6 +163,8 @@ Track: [express | full]   Where you are: [phase status line]
 
 Keep it to ~4 lines. Pull only from the map's `## Project North Star`, `## Overview`, and `## Capabilities` headings — never dump the full map. If the map is still the blank scaffold (first_time / pre-compose), skip the summary and give only the status line.
 
+Check the map's truth-window line (the `_Reflects: … · Reconciled with code: …_` line under the title). If "Reconciled with code" is "never" or older than the "Reflects" date, append one caveat line to the summary: `(map reflects [phase] — not yet verified against code)`. If the line is absent (older project), say nothing.
+
 ## STEP 5: ROUTING TABLE
 
 | Phase | Status Line | Route |
@@ -188,13 +190,13 @@ Project Status:
 ```
 
 Use AskUserQuestion:
-- Question: "All current work is complete. What's next?"
+- Question: "All current work is complete. New work happens on a branch — want to start one?"
 - Header: "Next Step"
-- Options: "Create a new branch" / "Start a new project on trunk"
+- Options: "Create a new branch" / "Nothing for now"
 
 **If "Create a new branch":** Collect branch name, purpose, and parent via AskUserQuestion. Then route: "Run `/intuition-enuncia-handoff` to register the branch. Pass along: branch name, purpose, parent."
 
-**If "Start a new project on trunk":** Route to `/intuition-enuncia-discovery`.
+**If "Nothing for now":** End with the status display. Do NOT offer to restart the pipeline on trunk — trunk's workflow ran once to establish the foundation; everything after completion is branch work so the Project North Star and the map stay coherent.
 
 ## EDGE CASES
 

package/skills/intuition-enuncia-verify/SKILL.md

@@ -165,7 +165,7 @@ Run the project's toolchain to verify basic code health. Execute in order:
 
 1. **Type check / lint** (if applicable): `[type check command]`, `[lint command]`
 2. **Build / compile** (if applicable): `[build command]`
-3. **Test suite (if one exists)**: On the full track, design recorded the suite command in `## Operational Foundation` / `key_facts.md` and execute produced `test/*` deliverables — run the FULL suite to catch regressions. On the express track, or any project with no authored tests, there is no suite to run: skip this step and note in the final results that there is no automated regression net. Do NOT hand-write tests here — verify validates, it does not author tests.
+3. **Test suite (if one exists)**: On the full track, design recorded the suite command in the map's `## Operational Foundation` (its canonical home — check `key_facts.md` only on older projects) and execute produced `test/*` deliverables — run the FULL suite to catch regressions. On the express track, or any project with no authored tests, there is no suite to run: skip this step and note in the final results that there is no automated regression net. Do NOT hand-write tests here — verify validates, it does not author tests.
 
 Also run `mcp__ide__getDiagnostics` to catch IDE-visible issues.
 
@@ -335,7 +335,7 @@ Work through the interaction map methodically, using your Tier 1 browser driver
 
 #### 8a. Load the Page
 
-Use WebFetch to load the page. Analyze what comes back:
+Load the page via your browser-control tier — Tier 1 driver navigation, or WebFetch on Tier 2. Analyze what comes back:
 - **Does the page render?** (non-error HTTP status, meaningful HTML content)
 - **Are key elements present?** (navigation, expected headings, expected content sections)
 - **Are there broken references?** (missing images, broken CSS/JS links, 404 resources)
@@ -425,16 +425,12 @@ If something drifts, flag it: "All interactions work, but [specific concern abou
 
 Correct the map in place. If reconciliation reveals real architectural drift the user should know about — a capability silently dropped, a connection that never actually worked — surface it in the final results. A quietly wrong map is worse than no map: it's the next session's starting truth.
 
+After reconciling, stamp the truth-window line directly under the `# Project Map` title: `_Reflects: verified ([today ISO date]) · Reconciled with code: [today ISO date]_` (add the line if absent). This is the only phase that updates the "Reconciled with code" half — it tells the next session the map was checked against reality, not just written from plans.
+
 **Update `docs/project_notes/project_map.md`** if integration or testing revealed anything new — refine `## Capabilities` slices or `## Component Reference` entries. Keep the shape and terseness. **Do not touch `## Project North Star` or `## Branch Goals`.**
 
 **Run the GOAL ALIGNMENT → Alignment Check** against the three loaded goals. Any failures must be fixed or explicitly flagged in the final results.
 
-**Append a Verify row to `docs/project_notes/map_history.md`** (create from template if missing). On a branch, Step 11 appends the consolidation row instead — do NOT double-log; skip this append on branches. On trunk:
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Verify | trunk | Verified live; map reconciled | [one sentence — what was verified] |
-
 ### STEP 11: CONSOLIDATE INTO TRUNK ARCHITECTURE (branch mode only)
 
 Skip this step on trunk — there's nothing to consolidate.
@@ -445,13 +441,9 @@ On a branch, before marking the branch complete, consolidate this branch's addit
 2. **`## Component Reference`**: Remove any branch markers (e.g., "(school-org branch)", "(new)") from component entries. Components belong to the product, not to the branch that delivered them.
 3. **`## Operational Foundation`**: Fold any branch-specific language into the main prose. If the branch added auth/deployment/tech-stack detail, it's now just the way the system works.
 
-Do not touch `## Project North Star`. Leave `## Branch Goals` alone — the historical record of what each branch was for stays put; it's small and explains why slices exist.
-
-Append a row to `docs/project_notes/map_history.md` (create from template if missing; migrate any legacy inline `## Map History` out of `project_map.md` if present):
+4. **Coherence pass (map gardening)**: branches add and modify slices one delivery at a time, which fragments `## Capabilities` over the project's life. Check whether this branch's slices substantially overlap an existing capability — if so, merge or rename so the section describes the product's current shape, not its delivery history. Update `## Component Reference` entries and each slice's Components list to match the merged structure. Keep the three-field slice shape and stakeholder-facing phrasing; presence in the map still means in use.
 
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|
-| [today ISO date] | Verify | [active_context] | Consolidated into trunk | [one sentence — what this branch delivered] |
+Do not touch `## Project North Star`. Leave `## Branch Goals` alone — the historical record of what each branch was for stays put; it's small and explains why slices exist.
 
 ### STEP 12: EXIT
 

package/skills/intuition-enuncia-initialize/references/project_map_history_template.md

@@ -1,8 +0,0 @@
-# Project Map History
-
-Phase-by-phase log of how the project architecture evolved. Split from `project_map.md` so the map stays oriented on current architecture — this file is the time-series log that grows forever.
-
-Append one row per phase completion (discovery, compose, design, execute, verify, or a branch consolidation). Do NOT rewrite existing rows.
-
-| Date | Phase | Branch | Change | Reason |
-|------|-------|--------|--------|--------|