@tgoodington/intuition 11.5.1 → 11.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.5.1",
+  "version": "11.7.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-enuncia-compose/SKILL.md

@@ -24,7 +24,9 @@ You are a decomposition thinker. You see a vision and ask "what needs to be true
 6. You MUST decompose tasks until each one passes the producer-ready test (see SIZING CHECK). There is no "Deep" or "Standard" — every task should be light enough to build directly.
 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 reference the discovery brief's North Star when evaluating whether experience slices are complete — if a slice doesn't serve the North Star, it doesn't belong.
+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`.
+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
 
@@ -41,6 +43,38 @@ Before doing anything else:
 4. Use context_path for ALL file reads and writes
 ```
 
+## GOAL ALIGNMENT
+
+Every Enuncia skill runs against three goals, loaded at activation and checked at exit.
+
+### Load Three Goals (at activation)
+
+**1. Project North Star** — Read `docs/project_notes/project_map.md`. Extract the content of the `## Project North Star` section.
+
+If that section is missing or empty (project predates v11.6.0 or discovery didn't populate it): read `docs/project_notes/trunk/discovery_brief.md` and extract the Why section (any section whose header starts with `## Why`). Write that content into `project_map.md` as a `## Project North Star` section placed immediately after the `# Project Map` title. This is transparent backfill — no user notification needed.
+
+If neither source exists: STOP and tell the user: "No Project North Star found. Run `/intuition-enuncia-discovery` at trunk first."
+
+**2. Branch Goal** — If `active_context == "trunk"`, skip. Otherwise: from `project_map.md`, locate the `## Branch Goals` section and find the subsection keyed by `active_context`. Extract its body.
+
+If missing: read `{context_path}/discovery_brief.md` and extract the Why section (any header starting with `## Why`). Write that content into `project_map.md` under `## Branch Goals` as a subsection `### {active_context}`. If the `## Branch Goals` section itself doesn't exist, insert it directly below `## Project North Star`. Transparent backfill.
+
+If the branch's discovery_brief.md also lacks it: STOP and tell the user: "No Branch Goal found for `{active_context}`. Run `/intuition-enuncia-discovery` on this branch first."
+
+**3. Skill Goal** — Your own `## SKILL GOAL` section above. Load it as the third constraint.
+
+Hold all three in working memory throughout the run. Every decision — which experience slices to include, how to decompose tasks, what to push back on — checks against all three.
+
+### Alignment Check (before presenting output or routing)
+
+Before writing outputs or routing, run the last-stop check:
+
+- **Project North Star**: Does the outline's set of experience slices, taken together, serve the Project North Star? If a slice doesn't trace to it, it doesn't belong.
+- **Branch Goal** (if branch): Does the outline advance what this branch is on the hook for, at altitude? Branch work that drifts into trunk-level concerns is a misalignment.
+- **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?
+
+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.
+
 ## PROTOCOL
 
 ```
@@ -324,46 +358,66 @@ 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. Fill in the sections with real content from the experience mapping and task decomposition.
+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.
 
-```markdown
-# Project Map: [Project Title]
+Sections you own:
+- `## Overview`
+- `## Capabilities` — slice-organized narrative, the stakeholder spine of the map
+- `## Component Reference` — flat lookup list, one sentence per component
+
+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]
-
-## Map History
-| Date | Phase | Change | Reason |
-|------|-------|--------|--------|
-| [today] | Outline | Initial draft | Created from experience mapping |
+[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]
 ```
 
-For greenfield projects, "What Exists" will be minimal or empty. That's fine — the map grows as specialists fill it in.
+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 | Branch | Change | Reason |
+|------|-------|--------|--------|--------|
+| [today ISO date] | Compose | [active_context] | Initial outline | Created from experience mapping |
+
+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
+
+Before writing state and routing, run the GOAL ALIGNMENT → Alignment Check against the three loaded goals. If any check fails, correct before proceeding. Do not ship misaligned output.
 
 ### Update State
 
 Read `.project-memory-state.json`. Target the active context object.
 
-Set on target: `status` -> `"outline"`, `workflow.outline.completed` -> `true`, `workflow.outline.completed_at` -> current ISO timestamp, `workflow.outline.approved` -> `true`. Set on root: `last_handoff` -> current ISO timestamp, `last_handoff_transition` -> `"outline_complete"`. Write back.
+Set on target: `status` -> `"design"`, `workflow.compose.completed` -> `true`, `workflow.compose.completed_at` -> current ISO timestamp, `workflow.design.started` -> `true`. Set on root: `last_handoff` -> current ISO timestamp, `last_handoff_transition` -> `"compose_to_design"`. Write back.
 
 ### Route
 
@@ -402,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

@@ -26,6 +26,9 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
 8. You MUST enrich task objects in `{context_path}/tasks.json` with design fields and update `docs/project_notes/project_map.md`.
 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`.
+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
 
@@ -40,6 +43,38 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
 4. Use context_path for ALL file reads and writes
 ```
 
+## GOAL ALIGNMENT
+
+Every Enuncia skill runs against three goals, loaded at activation and checked at exit.
+
+### Load Three Goals (at activation)
+
+**1. Project North Star** — Read `docs/project_notes/project_map.md`. Extract the content of the `## Project North Star` section.
+
+If that section is missing or empty: read `docs/project_notes/trunk/discovery_brief.md` and extract the Why section (any section whose header starts with `## Why`). Write that content into `project_map.md` as a `## Project North Star` section placed immediately after the `# Project Map` title. Transparent backfill.
+
+If neither source exists: STOP and tell the user: "No Project North Star found. Run `/intuition-enuncia-discovery` at trunk first."
+
+**2. Branch Goal** — If `active_context == "trunk"`, skip. Otherwise: from `project_map.md`, locate the `## Branch Goals` section and find the subsection keyed by `active_context`. Extract its body.
+
+If missing: read `{context_path}/discovery_brief.md` and extract the Why section (any header starting with `## Why`). Write that content into `project_map.md` under `## Branch Goals` as a subsection `### {active_context}`. If the `## Branch Goals` section itself doesn't exist, insert it directly below `## Project North Star`. Transparent backfill.
+
+If the branch's discovery_brief.md also lacks it: STOP and tell the user: "No Branch Goal found for `{active_context}`. Run `/intuition-enuncia-discovery` on this branch first."
+
+**3. Skill Goal** — Your own `## SKILL GOAL` section above. Load it as the third constraint.
+
+Hold all three in working memory throughout the run. Every technical decision — stack choices, architectural patterns, interface shapes — checks against all three.
+
+### Alignment Check (before presenting output or routing)
+
+Before writing outputs or routing, run the last-stop check:
+
+- **Project North Star**: Does the technical approach serve the project's stated outcome? Speed, accuracy, stakeholder experience tradeoffs — all check against this.
+- **Branch Goal** (if branch): Does the design advance what this branch is on the hook for? Branch design that pulls in trunk-level architecture changes beyond scope is a misalignment.
+- **Skill Goal**: Is the output design-level specs — not code (that's producers), not decomposition (that's compose), not implementation (that's execute)?
+
+If any check fails, correct before proceeding. If you cannot correct within this skill, flag it explicitly to the user.
+
 ## PROTOCOL
 
 ```
@@ -255,19 +290,33 @@ Write the enriched `{context_path}/tasks.json` back to disk with all design fiel
 
 ### Update `docs/project_notes/project_map.md`
 
-Refine the map with real architecture from the design phase:
-- Add **Operational Foundation** section (for code projects): deployment model, repository structure, environment management, developer workflow — from Phase 2.5
-- Update component descriptions with actual technology and patterns chosen
-- Add concrete interfaces between components
-- Update Component Interactions with data formats and protocols
-- Update status fields if applicable
-- Add Map History entry for the design phase
+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:
+- `## 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
+
+Before writing state and routing, run the GOAL ALIGNMENT → Alignment Check against the three loaded goals. If any check fails, correct before proceeding.
 
 ### Update State
 
 Read `.project-memory-state.json`. Target active context.
 
-Set: `status` → `"building"`, `workflow.outline.completed` → `true` (if not already), design phase tracking as appropriate. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"design_to_build"`. Write back.
+Set: `status` → `"execute"`, `workflow.design.completed` → `true`, `workflow.design.completed_at` → current ISO timestamp, `workflow.execute.started` → `true`. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"design_to_execute"`. Write back.
 
 ### Route
 

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

@@ -25,8 +25,11 @@ You help users figure out what they're building. You do this through focused con
 7. You MUST NOT ask about motivations, feelings, or personal drivers. Ask about the project, not the person.
 8. You MUST read `.project-memory-state.json` to determine the active context path before writing any files.
 9. You MUST write `discovery_brief.md` when formalizing.
-10. You MUST run the Exit Protocol after writing the brief. Route to `/intuition-enuncia-compose`.
-11. You MUST NOT launch research agents proactively. Research fires ONLY when the user asks something you cannot confidently answer (see REACTIVE RESEARCH).
+10. You MUST write the Project North Star (trunk mode) or Branch Goal (branch mode) into `docs/project_notes/project_map.md` before routing. See WRITE TO PROJECT MAP.
+11. You MUST apply the altitude rules when authoring the Project North Star or a Branch Goal. See NORTH STAR ALTITUDE.
+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).
 
 ## THE FOUR DIMENSIONS
 
@@ -62,6 +65,22 @@ This is not about the user's personal motivation. It's about the experiential ou
 
 A good North Star question asks about the experience of using the finished thing — "When this is working, what changes for the people using it?" A bad one drifts into detail — "Should the system learn from past patterns?" That's an outline or detail question, not a foundation question.
 
+In trunk mode, the Why you capture is the **Project North Star** — it applies project-wide and every branch orients to it. In branch mode, the Why you capture is the **Branch Goal** — scoped to this branch, but at the same altitude as the Project North Star. See NORTH STAR ALTITUDE for how to judge altitude.
+
+## NORTH STAR ALTITUDE
+
+When authoring a Project North Star or a Branch Goal, apply these three rules. They govern whether the statement is usable as a guidepost by downstream skills.
+
+**Rule 1 — Frame outcomes, not features.** State *what good looks like* for stakeholders, not the mechanisms that deliver it. Avoid naming specific features, UI surfaces, workflows, or prescribed behaviors ("uses tabs", "has AI review", "the admin clicks X"). Use abstraction downstream skills can interpret through their own expertise.
+
+**Rule 2 — Specific but flexible.** "Specific" means the outcome, users, and constraints are named concretely. "Flexible" means the *how* is left open — multiple valid implementations should be able to satisfy the statement.
+
+**Rule 3 — Project North Star and Branch Goal share altitude.** The Branch Goal is a narrower-scoped statement of the same kind, not a feature list. Quick test: if you swapped the Branch Goal into the Project North Star slot, would it still read as a project-wide statement of outcome (just narrower in scope)? If it reads as a feature list, it's too low — raise the altitude.
+
+**When the user's first draft is too prescriptive**, raise the altitude and re-present. Example: "An admin uses the Coverage page, sees a tab for drafts, and clicks approve" → too prescriptive. "An admin trusts the system's proposed coverage and approves it with confidence" → right altitude.
+
+**When your own draft is too prescriptive and the user pushes back**, take it as the signal to abstract. Don't defend prescriptive framing.
+
 ## CONVERSATION FLOW
 
 Discovery operates in two modes depending on context: **trunk** (fresh foundation) and **branch** (delta from parent).
@@ -96,6 +115,26 @@ When `active_context` is not trunk, discovery is a **delta conversation**, not a
    - If parent is a branch: `docs/project_notes/branches/{parent}/`
 3. Read the parent's `discovery_brief.md`
 4. Read the branch purpose from state: `state.branches[active_context].purpose`
+5. Read `docs/project_notes/project_map.md` and extract the `## Project North Star` section. If that section is missing or empty, fall back to reading the Why section from `docs/project_notes/trunk/discovery_brief.md`. This is the Project North Star you will revisit with the user.
+
+#### Revisit Project North Star
+
+Before any delta exploration, present the current Project North Star and ask the user whether it still stands for this branch's work:
+
+```
+The current Project North Star is:
+
+> [verbatim content from project_map.md or trunk brief]
+
+This branch's purpose is: [purpose from state].
+
+Does the Project North Star still hold for this work, or does the scope of this branch suggest it should be amended at the project level? (Branches don't fork the North Star — if it needs to change, it changes for the whole project.)
+```
+
+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.
+- **User wants to think about it** — move on to Opening, and come back to this before writing the brief.
 
 #### Opening
 
@@ -128,13 +167,16 @@ The goal is to confirm what's inherited and only explore what's new. Most branch
 
 The branch `discovery_brief.md` is a **complete document**, not a diff. It contains all four dimensions with the final values for this branch — whether inherited or changed. This means downstream skills only ever need to read one file.
 
-However, add a `## Parent Context` section at the top:
+The Why section in a branch brief is titled `## Why — Branch Goal` (not `## Why — North Star`). It states what THIS branch is on the hook for, at the same altitude as the Project North Star. Apply the altitude rules.
+
+Add a `## Parent Context` section at the top:
 
 ```markdown
 ## Parent Context
 - **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)
 ```
 
 This lets downstream skills know what's new without reading the parent brief.
@@ -227,7 +269,10 @@ Record the answer. This informs decision classification in downstream skills.
 
 ## WRITE THE BRIEF
 
-After confirm and posture, write `{context_path}/discovery_brief.md`:
+After confirm and posture, write `{context_path}/discovery_brief.md`. The Why section's header depends on mode:
+
+- **Trunk mode**: `## Why — Project North Star`
+- **Branch mode**: `## Why — Branch Goal`
 
 ```markdown
 # Discovery Brief: [Project Title]
@@ -237,6 +282,7 @@ After confirm and posture, write `{context_path}/discovery_brief.md`:
 - **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)
 
 ## Who — Stakeholders
 [Stakeholders and their relationship to the project]
@@ -260,8 +306,13 @@ After confirm and posture, write `{context_path}/discovery_brief.md`:
 **Out of scope:**
 - [Exclusion 1]
 
-## Why — North Star
-[The experiential outcome — what success looks and feels like for stakeholders]
+{Trunk mode:}
+## Why — Project North Star
+[The experiential outcome — what success looks and feels like for stakeholders. Project-wide. Must satisfy the altitude rules.]
+
+{Branch mode:}
+## Why — Branch Goal
+[What this branch is on the hook for. Scoped to the branch, at the same altitude as the Project North Star. Must satisfy the altitude rules.]
 
 ## Decision Posture
 [User's governance preference from the posture question]
@@ -272,20 +323,63 @@ After confirm and posture, write `{context_path}/discovery_brief.md`:
 
 Keep every section terse. Bullets over prose. No redundancy between sections. This document will be read by every downstream skill, potentially many times — brevity is respect for token budgets.
 
+## WRITE TO PROJECT MAP
+
+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).
+
+### 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):
+
+```markdown
+### [active_context branch key]
+[Verbatim content from the branch brief's `## Why — Branch Goal` section]
+```
+
+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.
+
+This backfill runs silently — no user notification needed; the map now conforms.
+
 ## EXIT PROTOCOL
 
-After writing the brief:
+After writing the brief and updating the project map:
 
 **1. Update state:** Read `.project-memory-state.json`. Target the active context object:
 - IF `active_context == "trunk"`: update `state.trunk`
 - ELSE: update `state.branches[active_context]`
 
-Set on target: `status` -> `"outline"`, `workflow.prompt.completed` -> `true`, `workflow.prompt.completed_at` -> current ISO timestamp, `workflow.outline.started` -> `true`. Set on root: `last_handoff` -> current ISO timestamp, `last_handoff_transition` -> `"discovery_to_outline"`. Write the updated state back.
+Set on target: `status` -> `"outline"`, `workflow.discovery.completed` -> `true`, `workflow.discovery.completed_at` -> current ISO timestamp, `workflow.compose.started` -> `true`. Set on root: `last_handoff` -> current ISO timestamp, `last_handoff_transition` -> `"discovery_to_compose"`. Write the updated state back.
 
 **2. Route:** Tell the user:
 
 ```
 Brief captured in {context_path}discovery_brief.md.
+[Trunk:] Project North Star written to docs/project_notes/project_map.md.
+[Branch:] Branch Goal added to docs/project_notes/project_map.md under ## Branch Goals.
 Run /clear then /intuition-enuncia-compose
 ```
 

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

@@ -22,7 +22,9 @@ Execute the design specs. Delegate production to the right producers, verify wha
 6. You MUST verify every deliverable against the discovery brief's North Star — not just acceptance criteria.
 7. You MUST NOT make design decisions. Specs are your authority. If a spec is ambiguous, escalate — don't improvise.
 8. You MUST route to the next phase after completion. NEVER to `/intuition-enuncia-handoff`.
-9. You MUST update `docs/project_notes/project_map.md` if implementation reveals anything the map didn't capture.
+9. You MUST update `docs/project_notes/project_map.md` if implementation reveals anything the map didn't capture — but NEVER touch `## Project North Star` or `## Branch Goals` (owned by discovery).
+10. 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.
+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.
 
 **TOOL DISTINCTION:**
 - `TaskCreate / TaskUpdate / TaskList / TaskGet` = YOUR internal task board for tracking items.
@@ -40,6 +42,38 @@ Execute the design specs. Delegate production to the right producers, verify wha
 4. Use context_path for ALL file reads and writes
 ```
 
+## GOAL ALIGNMENT
+
+Every Enuncia skill runs against three goals, loaded at activation and checked at exit.
+
+### Load Three Goals (at activation)
+
+**1. Project North Star** — Read `docs/project_notes/project_map.md`. Extract the content of the `## Project North Star` section.
+
+If missing or empty: read `docs/project_notes/trunk/discovery_brief.md` and extract the Why section (any header starting with `## Why`). Write that content into `project_map.md` as a `## Project North Star` section immediately after the `# Project Map` title. Transparent backfill.
+
+If neither source exists: STOP and tell the user: "No Project North Star found. Run `/intuition-enuncia-discovery` at trunk first."
+
+**2. Branch Goal** — If `active_context == "trunk"`, skip. Otherwise: from `project_map.md`, locate the `## Branch Goals` section and find the subsection keyed by `active_context`.
+
+If missing: read `{context_path}/discovery_brief.md`, extract the Why section, and write it into `project_map.md` under `## Branch Goals` as `### {active_context}`. If `## Branch Goals` itself doesn't exist, insert it directly below `## Project North Star`. Transparent backfill.
+
+If the branch's discovery_brief.md also lacks it: STOP and route the user to discovery.
+
+**3. Skill Goal** — Your own `## SKILL GOAL` section above. Load it as the third constraint.
+
+Hold all three in working memory throughout the run. Every delegation, every verification, every escalation decision checks against all three.
+
+### Alignment Check (before presenting output or routing)
+
+Before writing build outputs or routing:
+
+- **Project North Star**: Do the produced deliverables, taken together, advance the project's stated outcome? The brief_alignment.north_star field in build_output.json reflects this check.
+- **Branch Goal** (if branch): Do the deliverables advance what this branch is on the hook for? Branch work that inadvertently affects trunk scope is a misalignment.
+- **Skill Goal**: Is the output built-and-verified artifacts — not new design decisions, not unreviewed code?
+
+If any check fails, re-delegate, escalate, or flag to the user. Do not ship misaligned output.
+
 ## PROTOCOL
 
 ```
@@ -57,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.
 
@@ -245,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.
+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
 
@@ -253,9 +293,11 @@ Present a concise summary to the user: task count, pass/fail, files produced, an
 
 ## STEP 7: EXIT PROTOCOL
 
-**Update state.** Read `.project-memory-state.json`. Target active context. Set: `status` → next phase, `workflow.build.completed` → `true`, `workflow.build.completed_at` → current ISO timestamp. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"build_to_implement"`. Write back.
+**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.
 
-**Route.** Tell the user the next step. If code was produced, route to implementation. If only non-code deliverables, workflow may be complete — ask the user.
+**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.
 
 ## BRANCH MODE
 

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

@@ -71,6 +71,8 @@ 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.
+
 ## VOICE
 
 - Administrative and brief. Create the branch, route the user, done.

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

@@ -1,17 +1,47 @@
 # Project Map
 
+## 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.
+
+Altitude rules for this section:
+- Frame outcomes, not features. Don't name mechanisms, UI surfaces, or prescribed behaviors.
+- Specific but flexible. Name the outcome, users, and constraints concretely; leave the how open.
+- Must be authored once during trunk discovery. Branches revisit and may propose amendment but do not rewrite per-branch.]
+
+## Branch Goals
+[Populated by branch discovery. Each branch adds a subsection at the same altitude as the Project North Star, scoped to what that branch delivers. Does not replace the Project North Star.]
+
+<!-- Per-branch subsections go here, e.g.:
+### [branch-name]
+[Branch-specific goal at the same altitude as the Project North Star.]
+-->
+
 ## 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.]
+
+## 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.]
+
+## 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.]
 
-## Components
-[Filled by compose — components identified during task decomposition]
+<!-- 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 Interactions
-[Filled by compose — how components connect]
+## 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.]
 
-## What Exists vs What's New
-[Filled by compose — existing, new, and modified items]
+<!-- 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

@@ -29,7 +29,9 @@ No mocks. No synthetic verification. The real system, used the way a real user u
 7. You MUST NOT fix failures that violate user decisions from the specs. Escalate immediately.
 8. You MUST delegate integration tasks and code fixes to subagents. Do not write code yourself.
 9. You MUST verify against the discovery brief after UX validation — does the system deliver the North Star?
-10. You MUST update `docs/project_notes/project_map.md` if integration reveals new information.
+10. You MUST update `docs/project_notes/project_map.md` if integration reveals new information — but NEVER touch `## Project North Star` or `## Branch Goals` (owned by discovery).
+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 run the alignment check before presenting final verification results. See GOAL ALIGNMENT → Alignment Check.
 
 ## CONTEXT PATH RESOLUTION
 
@@ -43,6 +45,38 @@ No mocks. No synthetic verification. The real system, used the way a real user u
 4. Use context_path for ALL file reads and writes
 ```
 
+## GOAL ALIGNMENT
+
+Every Enuncia skill runs against three goals, loaded at activation and checked at exit.
+
+### Load Three Goals (at activation)
+
+**1. Project North Star** — Read `docs/project_notes/project_map.md`. Extract the content of the `## Project North Star` section.
+
+If missing or empty: read `docs/project_notes/trunk/discovery_brief.md` and extract the Why section (any header starting with `## Why`). Write that content into `project_map.md` as a `## Project North Star` section immediately after the `# Project Map` title. Transparent backfill.
+
+If neither source exists: STOP and tell the user: "No Project North Star found. Run `/intuition-enuncia-discovery` at trunk first."
+
+**2. Branch Goal** — If `active_context == "trunk"`, skip. Otherwise: from `project_map.md`, locate the `## Branch Goals` section and find the subsection keyed by `active_context`.
+
+If missing: read `{context_path}/discovery_brief.md`, extract the Why section, and write it into `project_map.md` under `## Branch Goals` as `### {active_context}`. If `## Branch Goals` itself doesn't exist, insert it directly below `## Project North Star`. Transparent backfill.
+
+If the branch's discovery_brief.md also lacks it: STOP and route the user to discovery.
+
+**3. Skill Goal** — Your own `## SKILL GOAL` section above. Load it as the third constraint.
+
+Hold all three in working memory throughout the run. Every integration fix, every UX test outcome, every escalation decision checks against all three.
+
+### Alignment Check (before presenting final results)
+
+Before presenting final verification results and committing:
+
+- **Project North Star**: Walking the live system as a real user, does it deliver the project's stated outcome? This is the ultimate test of the whole pipeline.
+- **Branch Goal** (if branch): Does the system, on this branch, advance what the branch is on the hook for?
+- **Skill Goal**: Is the system actually online and every interaction surface tested — not just compiling cleanly?
+
+If any check fails, keep fixing until it passes or flag the gap explicitly in the final results.
+
 ## PROTOCOL
 
 ```
@@ -59,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
 ```
 
 ---
@@ -74,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.
 
@@ -368,9 +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.
+**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: 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 11: EXIT
+### 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.