@tgoodington/intuition 11.6.0 → 11.7.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.6.0",
+  "version": "11.7.1",
   "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-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`. 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` or `## Branch Goals` sections in `project_map.md`. Those are owned by discovery. Update only your own sections (Overview, Components, Component Interactions, What Exists vs What's New, Map History).
+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`.
 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
@@ -358,52 +358,56 @@ The `decisions` array on each task is optional — only include when decisions a
 
 ### Update `docs/project_notes/project_map.md`
 
-The project map scaffold was created by initialize. Discovery authored the `## Project North Star` section (trunk) and/or `## Branch Goals` subsection (branch). **You do not touch those sections.** Fill in only the sections below with real content from the experience mapping and task decomposition, and append a Map History row.
+The project map scaffold was created by initialize. Discovery authored the `## Project North Star` section (trunk) and/or `## Branch Goals` subsection (branch). **You do not touch those sections.** Fill in only the sections below with real content from the experience mapping and task decomposition.
 
-Sections you own (write/update these):
+Sections you own:
 - `## Overview`
-- `## Components`
-- `## Component Interactions`
-- `## What Exists vs What's New`
-- `## Map History` (append a row — never rewrite existing rows)
+- `## Capabilities` — slice-organized narrative, the stakeholder spine of the map
+- `## Component Reference` — flat lookup list, one sentence per component
 
-Sections you do NOT touch (owned by discovery):
-- `## Project North Star`
-- `## Branch Goals`
+Sections you do NOT touch:
+- `## Project North Star` (owned by discovery)
+- `## Branch Goals` (owned by discovery)
+- `## Operational Foundation` (owned by design — leave it alone, even if empty)
 
 Format for the sections you own:
 
 ```markdown
 ## Overview
-[2-3 sentences: what this project is, who it's for, how it's delivered]
-
-## Components
-[For each distinct component identified during task decomposition:]
-
-### [Component Name]
-- **Purpose**: [what it does in plain language]
-- **Status**: New | Exists | Modifying existing
-- **Stakeholder touchpoints**: [which experience slices it serves]
-- **Connects to**: [other components it interacts with]
-
-## Component Interactions
-[How components connect — plain language, not technical specs]
-- [Component A] sends [what] to [Component B]
-- [Component C] reads from [Component D]
-
-## What Exists vs What's New
-**Existing**: [list of things already in place]
-**New**: [list of things being built]
-**Modified**: [list of existing things being changed]
+[2–3 sentences: what this project is, who it's for, how it's delivered. No tech here.]
+
+## Capabilities
+[One subsection per experience slice from tasks.json. Phrase slice names stakeholder-facing. Body is the three fixed fields — nothing else.]
+
+### [Slice name — stakeholder-facing phrasing]
+- **What stakeholders can do:** [one sentence]
+- **Components:** [Component A], [Component B], [Component C]
+- **Key connections:** [concise flow — A→B summary, B→external summary]
+
+## Component Reference
+[Flat list — one line per component. Body is ONE sentence.]
+
+- **[Component name]** — [one sentence: what it does; where in code if non-obvious]
 ```
 
-Append to `## Map History`:
+Anti-bloat rules:
+- No task IDs (T1, T2…) in `project_map.md` — they belong in `tasks.json`.
+- No stakeholder-touchpoint tags (ES-1, ES-2…) on components — the `## Capabilities` section IS the slice view.
+- No status fields on slices or components — presence in the map means in use.
+- 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 | Change | Reason |
-|------|-------|--------|--------|
-| [today ISO date] | Compose | Initial outline draft | Created from experience mapping |
+| Date | Phase | Branch | Change | Reason |
+|------|-------|--------|--------|--------|
+| [today ISO date] | Compose | [active_context] | Initial outline | Created from experience mapping |
 
-For greenfield projects, "What Exists" will be minimal or empty. That's fine — the map grows as specialists fill it in.
+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.
 
 ### Alignment Check
 
@@ -452,7 +456,7 @@ The branch `tasks.json` is a complete document (not a diff) but includes a `pare
 }
 ```
 
-Update `docs/project_notes/project_map.md` with the branch's changes. Update the Map History table with the branch entry.
+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.
 
 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 MUST NOT overwrite the `## Project North Star` or `## Branch Goals` sections in `project_map.md`. Those are owned by discovery. Update only your own sections (Operational Foundation, Components, Component Interactions, Map History).
+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`.
 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
@@ -209,20 +209,24 @@ If something drifts, flag it to the user before proceeding.
 
 After designing each group, present it to the user **before moving to the next group**. Do NOT batch all groups together. One group at a time keeps the review digestible.
 
+**Default to succinct.** The user is reviewing groups back-to-back — dense walls of tables, data models, and algorithmic detail make that exhausting. Lead with a tight summary; hold the full detail in reserve and offer it on request.
+
 Present the group's design as plain text (not AskUserQuestion — that's reserved for the final gate):
 
 ```
 **Group [N] of [total]: [Group Name] ([slice refs])**
 
-[Technical approach — tables, data models, algorithms, whatever this group needs]
+[Succinct technical approach — 2–5 sentences or a short bullet list. What it's built with, the key structural choice, how it connects to adjacent groups. No tables, no full data models, no file-by-file breakdowns at this level.]
 
-[Any decisions that need user input per decision posture]
+[Any decisions that need user input per decision posture — surface these even in succinct mode; they require input regardless.]
 
-[Any questions about this group]
+[Any questions about this group.]
 
-When you're good with this group, say so and I'll move to the next one.
+Say "expand" for full detail (data models, file layout, algorithms), ask about a specific aspect, or confirm to move to the next group.
 ```
 
+If the user says "expand" or asks about a specific aspect, present the deeper detail (tables, data models, algorithms, file layout) then re-offer confirmation. Decisions and surprises still surface by default regardless of density — succinct mode reduces elaboration, not signal.
+
 Wait for the user to confirm or request changes before proceeding to the next group. If the user asks for changes, revise and re-present the same group.
 
 This is the primary user interaction loop of the design phase. Each group gets the user's full attention.
@@ -292,11 +296,21 @@ Write the enriched `{context_path}/tasks.json` back to disk with all design fiel
 
 Refine the map with real architecture from the design phase. **Do not touch `## Project North Star` or `## Branch Goals` — those are owned by discovery.**
 
-Sections you own (write/update these):
-- `## Operational Foundation` (new section for code projects): deployment model, repository structure, environment management, developer workflow — from Phase 2.5
-- `## Components` — update descriptions with actual technology and patterns chosen, add concrete interfaces between components
-- `## Component Interactions` — update with data formats and protocols
-- `## Map History` — append a row for this design phase
+Sections you own:
+- `## Operational Foundation` — tech stack, deployment, auth pattern, repo structure, developer workflow. Each facet: a short paragraph or bullet group. Point to code for anything that would otherwise be verbose (e.g., "Authoritative schema: `app/models/`").
+- `## Capabilities` — refine per-slice "Components" and "Key connections" fields based on real architecture. Keep the three-field shape; do not add fields. Do not add status tags.
+- `## Component Reference` — keep one-sentence entries. If design surfaces a new component, add it here and wire it into the relevant slice's Components list.
+
+Anti-bloat rules:
+- Operational Foundation names WHAT, not HOW. "`SchoolContextMiddleware` resolves school_id from `X-Auth-User`" is fine. Listing fallback chains, header names, exception types is not.
+- 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] |
 
 ### Alignment Check
 

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

@@ -133,7 +133,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. Note the amendment in the Map History table (Phase: "Discovery (branch revisit)", 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. 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.
 - **User wants to think about it** — move on to Opening, and come back to this before writing the brief.
 
 #### Opening
@@ -331,13 +331,13 @@ Read the current `docs/project_notes/project_map.md` first (it was created by in
 
 ### 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`, `## Components`, etc. — compose will fill those.
+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.
 
-Add a Map History entry:
+Append a row to `docs/project_notes/map_history.md` (see Backfill below if the file doesn't exist yet):
 
-| Date | Phase | Change | Reason |
-|------|-------|--------|--------|
-| [today ISO date] | Discovery | Authored Project North Star | Trunk discovery complete |
+| Date | Phase | Branch | Change | Reason |
+|------|-------|--------|--------|--------|
+| [today ISO date] | Discovery | trunk | Authored Project North Star | Trunk discovery complete |
 
 ### Branch Mode
 
@@ -350,15 +350,19 @@ 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.
 
-Add a Map History entry:
+Append a row to `docs/project_notes/map_history.md`:
 
-| Date | Phase | Change | Reason |
-|------|-------|--------|--------|
-| [today ISO date] | Discovery (branch) | Authored Branch Goal for `[branch key]` | Branch discovery complete |
+| 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. This backfill runs silently — no user notification needed; the map now conforms.
+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.
+
+This backfill runs silently — no user notification needed; the map now conforms.
 
 ## EXIT PROTOCOL
 

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

@@ -91,7 +91,7 @@ Step 7: Route to next phase
 Read these files:
 1. `{context_path}/discovery_brief.md` — North Star, decision posture, constraints, stakeholders
 2. `{context_path}/tasks.json` — experience slices, tasks with design enrichment (technical approach, interfaces, file paths, decisions)
-3. `docs/project_notes/project_map.md` — component landscape, interactions, what exists vs what's new
+3. `docs/project_notes/project_map.md` — operational foundation, capabilities (by slice), component reference
 
 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.
 
@@ -279,7 +279,13 @@ Non-code deliverables (documents, spreadsheets, etc.) skip security review.
 
 ### Update `docs/project_notes/project_map.md`
 
-If implementation revealed anything not in the map — new components, changed interactions, unexpected dependencies — update the map. Add a Map History entry for the build phase. **Do not touch `## Project North Star` or `## Branch Goals`.**
+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] |
 
 ### Display Summary
 

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

@@ -94,6 +94,7 @@ docs/
     ├── trunk/
     ├── branches/
     ├── project_map.md
+    ├── map_history.md
     ├── bugs.md
     ├── decisions.md
     ├── key_facts.md
@@ -112,6 +113,7 @@ 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.
 
@@ -237,7 +239,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`
+- `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`, `project_map_history_template.md`
 
 **State template** (Step 3):
 - `state_template.json` — Enuncia v11 workflow state

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

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

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

@@ -17,17 +17,31 @@ Altitude rules for this section:
 -->
 
 ## Overview
-[Filled by compose — what this project is, who it's for, how it's delivered]
+[Filled by compose — 2–3 sentences: what this project is, who it's for, how it's delivered. No tech here; that lives in Operational Foundation.]
 
-## Components
-[Filled by compose — components identified during task decomposition]
+## Operational Foundation
+[Filled by design. Tech stack, deployment, auth pattern, repo structure, developer workflow. Each facet: short paragraph or bullet group. Point to code for anything that would otherwise be verbose (e.g., "Authoritative schema: `app/models/`"). Do not list class names, method signatures, enum values, or config keys here — those live in code.]
 
-## Component Interactions
-[Filled by compose — how components connect]
+## Capabilities
+[Filled by compose; refined by design. Organized by experience slice — this is the stakeholder-value spine of the map. Each slice is a subsection. A slice present in this section is understood to be part of the current product; no status tagging needed.]
 
-## What Exists vs What's New
-[Filled by compose — existing, new, and modified items]
+<!-- Per-slice subsections go here, e.g.:
+### [Slice name — stakeholder-facing phrasing]
+- **What stakeholders can do:** [one sentence]
+- **Components:** [Component A], [Component B]
+- **Key connections:** [concise flow — A→B summary, B→external summary]
+-->
+
+## Component Reference
+[Filled by compose; refined by design. Flat lookup list — one sentence per component. No tech detail, no task IDs, no slice tags. If you're tempted to expand an entry, expand the slice narrative instead or point to code. A component present here is understood to be in use.]
+
+<!-- Per-component entries, e.g.:
+- **[Component name]** — [one sentence: what it does; where it lives in code if non-obvious]
+-->
 
-## Map History
-| Date | Phase | Change | Reason |
-|------|-------|--------|--------|
+## Pointers
+- Bugs → `docs/project_notes/bugs.md`
+- 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-verify/SKILL.md

@@ -93,7 +93,8 @@ Phase 2: UX validation
   Step 8: Systematic walkthrough — test every interaction surface
   Step 9: Fix cycle
   Step 10: Final verification against discovery brief
-  Step 11: Exit
+  Step 11: Consolidate into trunk architecture (branch mode only)
+  Step 12: Exit
 ```
 
 ---
@@ -108,7 +109,7 @@ Read these files:
 1. `{context_path}/discovery_brief.md` — North Star, stakeholders, constraints
 2. `{context_path}/tasks.json` — experience slices, tasks with design enrichment, acceptance criteria
 3. `{context_path}/build_output.json` — what was built, files created/modified, any deviations
-4. `docs/project_notes/project_map.md` — component landscape, interactions
+4. `docs/project_notes/project_map.md` — operational foundation, capabilities (by slice), component reference
 
 From build_output.json, extract: all files created and modified, task statuses, any escalated issues or deviations.
 
@@ -402,11 +403,29 @@ After the walkthrough is clean (all interactions work):
 
 If something drifts, flag it: "All interactions work, but [specific concern about North Star alignment]."
 
-**Update `docs/project_notes/project_map.md`** if integration or testing revealed anything new. **Do not touch `## Project North Star` or `## Branch Goals`.**
+**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.
 
-### STEP 11: EXIT
+### STEP 11: CONSOLIDATE INTO TRUNK ARCHITECTURE (branch mode only)
+
+Skip this step on trunk — there's nothing to consolidate.
+
+On a branch, before marking the branch complete, consolidate this branch's additions into trunk architecture in `docs/project_notes/project_map.md`:
+
+1. **`## Capabilities`**: Drop any branch-scoped phrasing from slices this branch added or modified. A slice present in Capabilities is understood to be part of the product — no "(new in X branch)" tags, no status markers, no branch attribution.
+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):
+
+| Date | Phase | Branch | Change | Reason |
+|------|-------|--------|--------|--------|
+| [today ISO date] | Verify | [active_context] | Consolidated into trunk | [one sentence — what this branch delivered] |
+
+### STEP 12: EXIT
 
 **Update state.** Read `.project-memory-state.json`. Target active context. Set: `status` → `"complete"`, `workflow.verify.completed` → `true`, `workflow.verify.completed_at` → current ISO timestamp. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"verify_to_complete"`. Write back.