@tgoodington/intuition 11.6.0 → 11.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tgoodington/intuition",
3
- "version": "11.6.0",
3
+ "version": "11.7.0",
4
4
  "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).",
5
5
  "keywords": [
6
6
  "claude-code",
@@ -25,7 +25,7 @@ You are a decomposition thinker. You see a vision and ask "what needs to be true
25
25
  7. You MUST write `tasks.json`, `docs/project_notes/project_map.md`, and update state before routing.
26
26
  8. You MUST route to `/intuition-enuncia-design`. NEVER to `/intuition-enuncia-handoff`.
27
27
  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.
28
- 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).
28
+ 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`.
29
29
  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.
30
30
 
31
31
  ## CONTEXT PATH RESOLUTION
@@ -358,52 +358,56 @@ The `decisions` array on each task is optional — only include when decisions a
358
358
 
359
359
  ### Update `docs/project_notes/project_map.md`
360
360
 
361
- 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.
361
+ 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.
362
362
 
363
- Sections you own (write/update these):
363
+ Sections you own:
364
364
  - `## Overview`
365
- - `## Components`
366
- - `## Component Interactions`
367
- - `## What Exists vs What's New`
368
- - `## Map History` (append a row — never rewrite existing rows)
365
+ - `## Capabilities` — slice-organized narrative, the stakeholder spine of the map
366
+ - `## Component Reference` — flat lookup list, one sentence per component
369
367
 
370
- Sections you do NOT touch (owned by discovery):
371
- - `## Project North Star`
372
- - `## Branch Goals`
368
+ Sections you do NOT touch:
369
+ - `## Project North Star` (owned by discovery)
370
+ - `## Branch Goals` (owned by discovery)
371
+ - `## Operational Foundation` (owned by design — leave it alone, even if empty)
373
372
 
374
373
  Format for the sections you own:
375
374
 
376
375
  ```markdown
377
376
  ## Overview
378
- [2-3 sentences: what this project is, who it's for, how it's delivered]
379
-
380
- ## Components
381
- [For each distinct component identified during task decomposition:]
382
-
383
- ### [Component Name]
384
- - **Purpose**: [what it does in plain language]
385
- - **Status**: New | Exists | Modifying existing
386
- - **Stakeholder touchpoints**: [which experience slices it serves]
387
- - **Connects to**: [other components it interacts with]
388
-
389
- ## Component Interactions
390
- [How components connect — plain language, not technical specs]
391
- - [Component A] sends [what] to [Component B]
392
- - [Component C] reads from [Component D]
393
-
394
- ## What Exists vs What's New
395
- **Existing**: [list of things already in place]
396
- **New**: [list of things being built]
397
- **Modified**: [list of existing things being changed]
377
+ [23 sentences: what this project is, who it's for, how it's delivered. No tech here.]
378
+
379
+ ## Capabilities
380
+ [One subsection per experience slice from tasks.json. Phrase slice names stakeholder-facing. Body is the three fixed fields — nothing else.]
381
+
382
+ ### [Slice name — stakeholder-facing phrasing]
383
+ - **What stakeholders can do:** [one sentence]
384
+ - **Components:** [Component A], [Component B], [Component C]
385
+ - **Key connections:** [concise flow A→B summary, B→external summary]
386
+
387
+ ## Component Reference
388
+ [Flat list — one line per component. Body is ONE sentence.]
389
+
390
+ - **[Component name]** [one sentence: what it does; where in code if non-obvious]
398
391
  ```
399
392
 
400
- Append to `## Map History`:
393
+ Anti-bloat rules:
394
+ - No task IDs (T1, T2…) in `project_map.md` — they belong in `tasks.json`.
395
+ - No stakeholder-touchpoint tags (ES-1, ES-2…) on components — the `## Capabilities` section IS the slice view.
396
+ - No status fields on slices or components — presence in the map means in use.
397
+ - No class names, method names, enum values, file paths, or CSS selectors — those live in code.
398
+ - 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.
399
+
400
+ Append a row to `docs/project_notes/map_history.md` (NOT to `project_map.md`):
401
+
402
+ - If `map_history.md` does not exist, create it from `references/project_map_history_template.md`.
403
+ - 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`.
404
+ - Then append:
401
405
 
402
- | Date | Phase | Change | Reason |
403
- |------|-------|--------|--------|
404
- | [today ISO date] | Compose | Initial outline draft | Created from experience mapping |
406
+ | Date | Phase | Branch | Change | Reason |
407
+ |------|-------|--------|--------|--------|
408
+ | [today ISO date] | Compose | [active_context] | Initial outline | Created from experience mapping |
405
409
 
406
- For greenfield projects, "What Exists" will be minimal or empty. That's fine the map grows as specialists fill it in.
410
+ 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.
407
411
 
408
412
  ### Alignment Check
409
413
 
@@ -452,7 +456,7 @@ The branch `tasks.json` is a complete document (not a diff) but includes a `pare
452
456
  }
453
457
  ```
454
458
 
455
- Update `docs/project_notes/project_map.md` with the branch's changes. Update the Map History table with the branch entry.
459
+ 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.
456
460
 
457
461
  Branch outlines should be faster — most of the experience mapping is inherited. Focus the conversation on what's new.
458
462
 
@@ -27,7 +27,7 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
27
27
  9. You MUST route to `/intuition-enuncia-execute` after completion. NEVER to `/intuition-enuncia-handoff`.
28
28
  10. You MUST NOT write code. You write specs that describe what code to write. Producers write code.
29
29
  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.
30
- 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).
30
+ 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`.
31
31
  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.
32
32
 
33
33
  ## CONTEXT PATH RESOLUTION
@@ -292,11 +292,21 @@ Write the enriched `{context_path}/tasks.json` back to disk with all design fiel
292
292
 
293
293
  Refine the map with real architecture from the design phase. **Do not touch `## Project North Star` or `## Branch Goals` — those are owned by discovery.**
294
294
 
295
- Sections you own (write/update these):
296
- - `## Operational Foundation` (new section for code projects): deployment model, repository structure, environment management, developer workflow from Phase 2.5
297
- - `## Components` — update descriptions with actual technology and patterns chosen, add concrete interfaces between components
298
- - `## Component Interactions` — update with data formats and protocols
299
- - `## Map History` — append a row for this design phase
295
+ Sections you own:
296
+ - `## 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/`").
297
+ - `## 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.
298
+ - `## 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.
299
+
300
+ Anti-bloat rules:
301
+ - 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.
302
+ - Never expand a Component Reference entry past one sentence. If the architectural detail is important, point to code.
303
+ - 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.
304
+
305
+ 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.
306
+
307
+ | Date | Phase | Branch | Change | Reason |
308
+ |------|-------|--------|--------|--------|
309
+ | [today ISO date] | Design | [active_context] | Architecture finalized | [one sentence] |
300
310
 
301
311
  ### Alignment Check
302
312
 
@@ -133,7 +133,7 @@ Does the Project North Star still hold for this work, or does the scope of this
133
133
 
134
134
  Accept one of three outcomes:
135
135
  - **Holds as-is** — keep it unchanged, proceed to Opening.
136
- - **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.
136
+ - **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.
137
137
  - **User wants to think about it** — move on to Opening, and come back to this before writing the brief.
138
138
 
139
139
  #### Opening
@@ -331,13 +331,13 @@ Read the current `docs/project_notes/project_map.md` first (it was created by in
331
331
 
332
332
  ### Trunk Mode
333
333
 
334
- 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.
334
+ 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.
335
335
 
336
- Add a Map History entry:
336
+ Append a row to `docs/project_notes/map_history.md` (see Backfill below if the file doesn't exist yet):
337
337
 
338
- | Date | Phase | Change | Reason |
339
- |------|-------|--------|--------|
340
- | [today ISO date] | Discovery | Authored Project North Star | Trunk discovery complete |
338
+ | Date | Phase | Branch | Change | Reason |
339
+ |------|-------|--------|--------|--------|
340
+ | [today ISO date] | Discovery | trunk | Authored Project North Star | Trunk discovery complete |
341
341
 
342
342
  ### Branch Mode
343
343
 
@@ -350,15 +350,19 @@ Under the `## Branch Goals` section, add a subsection for this branch (or update
350
350
 
351
351
  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.
352
352
 
353
- Add a Map History entry:
353
+ Append a row to `docs/project_notes/map_history.md`:
354
354
 
355
- | Date | Phase | Change | Reason |
356
- |------|-------|--------|--------|
357
- | [today ISO date] | Discovery (branch) | Authored Branch Goal for `[branch key]` | Branch discovery complete |
355
+ | Date | Phase | Branch | Change | Reason |
356
+ |------|-------|--------|--------|--------|
357
+ | [today ISO date] | Discovery (branch) | [active_context] | Authored Branch Goal | Branch discovery complete |
358
358
 
359
359
  ### Backfill (Existing Projects)
360
360
 
361
- 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.
361
+ 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.
362
+
363
+ 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.
364
+
365
+ This backfill runs silently — no user notification needed; the map now conforms.
362
366
 
363
367
  ## EXIT PROTOCOL
364
368
 
@@ -91,7 +91,7 @@ Step 7: Route to next phase
91
91
  Read these files:
92
92
  1. `{context_path}/discovery_brief.md` — North Star, decision posture, constraints, stakeholders
93
93
  2. `{context_path}/tasks.json` — experience slices, tasks with design enrichment (technical approach, interfaces, file paths, decisions)
94
- 3. `docs/project_notes/project_map.md` — component landscape, interactions, what exists vs what's new
94
+ 3. `docs/project_notes/project_map.md` — operational foundation, capabilities (by slice), component reference
95
95
 
96
96
  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.
97
97
 
@@ -279,7 +279,13 @@ Non-code deliverables (documents, spreadsheets, etc.) skip security review.
279
279
 
280
280
  ### Update `docs/project_notes/project_map.md`
281
281
 
282
- 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`.**
282
+ 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`.**
283
+
284
+ 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.
285
+
286
+ | Date | Phase | Branch | Change | Reason |
287
+ |------|-------|--------|--------|--------|
288
+ | [today ISO date] | Execute | [active_context] | [summary of what was built] | [one sentence] |
283
289
 
284
290
  ### Display Summary
285
291
 
@@ -94,6 +94,7 @@ docs/
94
94
  ├── trunk/
95
95
  ├── branches/
96
96
  ├── project_map.md
97
+ ├── map_history.md
97
98
  ├── bugs.md
98
99
  ├── decisions.md
99
100
  ├── key_facts.md
@@ -112,6 +113,7 @@ For each file, use the Read tool to read the template, then use Write to create
112
113
  | `references/key_facts_template.md` | `docs/project_notes/key_facts.md` |
113
114
  | `references/issues_template.md` | `docs/project_notes/issues.md` |
114
115
  | `references/project_map_template.md` | `docs/project_notes/project_map.md` |
116
+ | `references/project_map_history_template.md` | `docs/project_notes/map_history.md` |
115
117
 
116
118
  The project map template is a scaffold — compose and design fill it with real content during the workflow.
117
119
 
@@ -237,7 +239,7 @@ or /intuition-enuncia-start to check project status.
237
239
  These template files are in the `references/` directory. Use Read tool to access them:
238
240
 
239
241
  **Memory file templates** (Step 2):
240
- - `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`
242
+ - `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`, `project_map_history_template.md`
241
243
 
242
244
  **State template** (Step 3):
243
245
  - `state_template.json` — Enuncia v11 workflow state
@@ -0,0 +1,8 @@
1
+ # Project Map History
2
+
3
+ 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.
4
+
5
+ Append one row per phase completion (discovery, compose, design, execute, verify, or a branch consolidation). Do NOT rewrite existing rows.
6
+
7
+ | Date | Phase | Branch | Change | Reason |
8
+ |------|-------|--------|--------|--------|
@@ -17,17 +17,31 @@ Altitude rules for this section:
17
17
  -->
18
18
 
19
19
  ## Overview
20
- [Filled by compose — what this project is, who it's for, how it's delivered]
20
+ [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.]
21
21
 
22
- ## Components
23
- [Filled by composecomponents identified during task decomposition]
22
+ ## Operational Foundation
23
+ [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.]
24
24
 
25
- ## Component Interactions
26
- [Filled by compose — how components connect]
25
+ ## Capabilities
26
+ [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.]
27
27
 
28
- ## What Exists vs What's New
29
- [Filled by compose existing, new, and modified items]
28
+ <!-- Per-slice subsections go here, e.g.:
29
+ ### [Slice namestakeholder-facing phrasing]
30
+ - **What stakeholders can do:** [one sentence]
31
+ - **Components:** [Component A], [Component B]
32
+ - **Key connections:** [concise flow — A→B summary, B→external summary]
33
+ -->
34
+
35
+ ## Component Reference
36
+ [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.]
37
+
38
+ <!-- Per-component entries, e.g.:
39
+ - **[Component name]** — [one sentence: what it does; where it lives in code if non-obvious]
40
+ -->
30
41
 
31
- ## Map History
32
- | Date | Phase | Change | Reason |
33
- |------|-------|--------|--------|
42
+ ## Pointers
43
+ - Bugs `docs/project_notes/bugs.md`
44
+ - Decisions → `docs/project_notes/decisions.md`
45
+ - Config, credentials, URLs → `docs/project_notes/key_facts.md`
46
+ - Work log → `docs/project_notes/issues.md`
47
+ - Map evolution by phase → `docs/project_notes/map_history.md`
@@ -93,7 +93,8 @@ Phase 2: UX validation
93
93
  Step 8: Systematic walkthrough — test every interaction surface
94
94
  Step 9: Fix cycle
95
95
  Step 10: Final verification against discovery brief
96
- Step 11: Exit
96
+ Step 11: Consolidate into trunk architecture (branch mode only)
97
+ Step 12: Exit
97
98
  ```
98
99
 
99
100
  ---
@@ -108,7 +109,7 @@ Read these files:
108
109
  1. `{context_path}/discovery_brief.md` — North Star, stakeholders, constraints
109
110
  2. `{context_path}/tasks.json` — experience slices, tasks with design enrichment, acceptance criteria
110
111
  3. `{context_path}/build_output.json` — what was built, files created/modified, any deviations
111
- 4. `docs/project_notes/project_map.md` — component landscape, interactions
112
+ 4. `docs/project_notes/project_map.md` — operational foundation, capabilities (by slice), component reference
112
113
 
113
114
  From build_output.json, extract: all files created and modified, task statuses, any escalated issues or deviations.
114
115
 
@@ -402,11 +403,29 @@ After the walkthrough is clean (all interactions work):
402
403
 
403
404
  If something drifts, flag it: "All interactions work, but [specific concern about North Star alignment]."
404
405
 
405
- **Update `docs/project_notes/project_map.md`** if integration or testing revealed anything new. **Do not touch `## Project North Star` or `## Branch Goals`.**
406
+ **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`.**
406
407
 
407
408
  **Run the GOAL ALIGNMENT → Alignment Check** against the three loaded goals. Any failures must be fixed or explicitly flagged in the final results.
408
409
 
409
- ### STEP 11: EXIT
410
+ ### STEP 11: CONSOLIDATE INTO TRUNK ARCHITECTURE (branch mode only)
411
+
412
+ Skip this step on trunk — there's nothing to consolidate.
413
+
414
+ On a branch, before marking the branch complete, consolidate this branch's additions into trunk architecture in `docs/project_notes/project_map.md`:
415
+
416
+ 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.
417
+ 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.
418
+ 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.
419
+
420
+ 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.
421
+
422
+ 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):
423
+
424
+ | Date | Phase | Branch | Change | Reason |
425
+ |------|-------|--------|--------|--------|
426
+ | [today ISO date] | Verify | [active_context] | Consolidated into trunk | [one sentence — what this branch delivered] |
427
+
428
+ ### STEP 12: EXIT
410
429
 
411
430
  **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.
412
431