bossbuild 0.97.0

package/stages/L2-v1/template/.claude/skills/board/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: board
+description: The cross-FEAT sequencing surface for {{PROJECT_NAME}}. Reads INDEX + FEAT frontmatter + smoke state + evals state + override entries to produce a live board view — what's open, what's blocked, what's next, what's parallelizable. Owned by `program-manager` (the *when*; distinct from `pm`'s *what*). Usage - /board  (or /board --next, /board --blocked, /board --by-cohort)
+---
+
+# /board — the cross-FEAT sequencing surface
+
+At MVP the queue was small; `program-manager`'s next-up list lived in conversation. At V1
+there are usually 5+ FEATs in flight, real dependencies between them, real blockers, and a
+real need to surface *what is the project actually working on right now.* `/board` is that
+view.
+
+It's a *live read*, not a maintained document. The skill computes it from the frontmatter +
+state of the actual FEAT files. If you want to change the board, change the FEATs — don't
+edit the board view.
+
+## What the board shows
+
+By default (`/board` with no flags):
+
+```
+{{PROJECT_NAME}} — board
+  mode: {{MODE}}
+  smoke: ✓ green  (last run: <when>)
+  evals: 12 / 14 cases passing across 3 FEATs  (2 failing in FEAT-007)
+
+  In flight (3):
+    ⊙ FEAT-005  user-onboarding-flow      acceptance: 3/5  smoke: ✓  evals: n/a
+    ⊙ FEAT-007  AI-summarization-prompt   acceptance: 1/4  smoke: ✓  evals: 4/6 ⚠
+    ⊙ FEAT-008  schema-migration-v2       acceptance: 0/3  smoke: ✗  blocked: db-architect review
+
+  Next-up (2, ordered):
+    ◯ FEAT-009  empty-state-illustrations  deps: FEAT-005 done
+    ◯ FEAT-010  hover-state-microinteractions  deps: design-tokens-loop closed
+
+  Blocked (1):
+    ▣ FEAT-006  team-permissions           blocked: needs mentor-business call (pricing tier shape)
+
+  Deferred (1):
+    ⌀ FEAT-011  ai-suggest-completion      override: skipped — rationale: re-open after FEAT-007 evals stabilize
+
+  Recently shipped (3, last 14 days):
+    ✓ FEAT-002 ✓ FEAT-003 ✓ FEAT-004
+```
+
+## How to run it
+
+1. **Walk `docs/ideas/FEAT-*.md`** to enumerate every FEAT. Read each one's frontmatter
+   (`status`), acceptance-criteria checklist progress, smoke field, evals field.
+2. **Walk `docs/devlog.md`** for override entries naming FEATs. Filter recent ones.
+3. **Walk `docs/loops/*.md` state** (use the same logic `boss status --conscience` uses) to
+   identify loops that gate any FEATs (e.g., a FEAT depends on `design-tokens-loop` being
+   closed).
+4. **Compute the board.** Group FEATs by status:
+   - **In flight** — `status: building`; show acceptance progress + smoke + evals state
+   - **Next-up** — `status: ready` (specced, not yet started); show dependencies + suggested order
+   - **Blocked** — `status: building` AND smoke is red, or a dep is unclosed, or an override
+     was recorded
+   - **Deferred** — `status: deferred` or an override entry naming this FEAT exists
+   - **Recently shipped** — `status: shipped` within last 14 days (cap at 5)
+5. **Output the board** in a readable Markdown-friendly text format.
+
+## Flags
+
+- `--next` — show only Next-up, ordered with rationale
+- `--blocked` — show only Blocked, with the specific blocker for each
+- `--by-cohort` — group by which persona-cohort the FEAT primarily serves (reads
+  `.boss/config.json` cohort + FEAT frontmatter `serves_cohort` if present)
+- `--deferred` — show only Deferred + the re-open conditions from each override
+- `--evals` — show evals state across FEATs; highlight FEATs with failing cases
+
+## How the board interacts with the conscience
+
+The board is `program-manager`'s view; the conscience's loops are independent. But they
+intersect at the boundaries:
+- A FEAT in *Next-up* whose `spec-loop`'s entry isn't satisfied (canvas-loop not closed) is
+  arguably premature; flag with `⚠` and a one-liner.
+- A FEAT in *Blocked* on `design-tokens-loop` is signal that `/design-tokens-init` should run.
+- Multiple FEATs *Deferred* with overrides pointing at the same upstream concern is signal
+  for `pm` or `mentor-venture` — there's a real bottleneck, not just incidental skips.
+
+## What this skill does NOT do
+
+- Doesn't edit FEAT files. View-only. To change priority, change the FEAT's frontmatter or
+  acceptance state.
+- Doesn't run smoke / evals. It reports their *last known result* per FEAT. To get fresh
+  state, run `/smoke` or `/evals` first.
+- Doesn't track dependencies that aren't declared. If `FEAT-008` actually depends on `FEAT-005`
+  but the FEAT files don't say so, the board can't show it. Declaring deps in FEAT frontmatter
+  (`requires: [FEAT-005]`) is the discipline that makes the board honest.
+
+## Rules
+
+- **Live read, not maintained doc.** Don't write a `docs/board.md`. The view IS the board.
+- **Frontmatter is truth.** If the board is wrong, fix the source FEAT file, not the board view.
+- **Brief.** A board view longer than one screen is failing — group, summarize, link to detail.
+- **`program-manager`-owned.** This skill is the program-manager agent's primary surface; when
+  ambiguity about priority emerges, route to `program-manager`.

package/stages/L2-v1/template/.claude/skills/design-review/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: design-review
+description: Before-code design review for {{PROJECT_NAME}}. Runs the proposed UI through `ui-designer` (token + visual authority) and `ux-designer` (flows + 5-state requirement) in sequence. Reads `docs/design/DESIGN_TOKENS.md` + `docs/design/STYLE_GUIDE.md` + the relevant FEAT spec. Outputs concrete diffs or numbered issues. Catches token violations + missing states + brand drift BEFORE code commits. Pairs with `/ux-check` (after-code review). Usage - /design-review [FEAT-NNN | path-to-component-spec]
+---
+
+# /design-review — before-code design review
+
+Catch design failures *before* they're in production code, where they're cheapest to fix. Most
+of the AI-generated-UI failure modes from IDEA-010 (the 47 blues, pattern reinvention, billion-
+line drift, missing states, brand-default) are catchable at this stage with a structured
+review. After-code review (`/ux-check`) is the second gate; this is the first.
+
+## When to run it
+
+- A FEAT introduces or significantly modifies UI — *before* `coder-generalist` writes the code.
+- A new component is being added — *before* the file lands.
+- The founder wants a second look on a design decision they made — anytime.
+
+## How to run it
+
+1. **Read the spec.** The FEAT being reviewed, the proposed component (sketch / mockup /
+   description), and the relevant section of any design brief.
+2. **Read the system.** `docs/design/DESIGN_TOKENS.md` (authoritative tokens), `docs/design/
+   STYLE_GUIDE.md` (how tokens compose into patterns), `docs/ideas/CANVAS.md` (Promises cell —
+   the brand anchor).
+3. **Run `ui-designer` first** — pass the spec + the design system; ask for review against:
+   - Token compliance (no raw hex; no raw spacing; no font-family inlined)
+   - Three-layer architecture preserved (semantic tokens used, not primitives)
+   - Brand-anchored choices (matches canvas Promises voice, not internet-default)
+   - Reuse-before-creation: does a similar pattern exist in `src/components/`?
+4. **Run `ux-designer` next** — pass the spec + ui-designer's notes; ask for review against:
+   - All 5 states named (default / hover / active / disabled / empty) — plus loading + error
+     for async / interactive elements
+   - Affordances clear (Norman's lens — the user can tell what's interactive)
+   - Nielsen heuristics (visibility, recognition, error prevention, recovery)
+   - Accessibility floor: keyboard nav, focus visibility, screen reader output, color-isn't-
+     the-only-signal, WCAG 2 AA contrast
+   - AI-specific UX (if applicable): options-not-truth, visible confidence, undo/edit/regenerate,
+     deliberate failure states
+5. **Synthesize.** Output:
+   - **Token violations** — list each; propose the right token; flag if a new token is
+     legitimately needed and which layer
+   - **Missing states** — list each missing state; propose what each should be
+   - **Brand drift** — flag any visual choices that contradict the canvas Promises voice
+   - **Accessibility issues** — listed by WCAG / Nielsen heuristic violated
+   - **AI-UX issues** (where applicable) — listed
+6. **Capture the review** in `docs/design/reviews/<feat-nnn-or-date>.md`. The review is a
+   diff against the proposed design, not a critique-only doc — propose every change concretely.
+
+## What this skill does NOT do
+
+- Doesn't write the implementation. After review passes, `coder-generalist` writes the code.
+- Doesn't run on existing shipped code. That's `/ux-check`'s job.
+- Doesn't approve when an override is recorded. The founder can override a finding (record in
+  the review doc with substantive rationale); the review respects.
+
+## Cohort-aware delivery
+
+Per `.boss/config.json` cohort declaration (v0.20+):
+- `vibe-coder-newbie` / `first-product`: explain *why* each token-compliance / state-coverage
+  point matters; this cohort is most likely to find design discipline foreign
+- `eng-builder` / `returning-founder`: terse list of violations; assume context
+- `vibe-virtuoso`: lean into the architecture (atomic discipline, token layer-cake); skip the
+  101 explanations
+- `non-tech-founder` / `domain-expert`: plain language; emphasize the user-facing consequences
+  of each issue
+- `indie-hacker`: right-sized — avoid suggesting heavier discipline than the project earns
+
+## Rules
+
+- **Before code.** This review is BEFORE the implementation. If you're reviewing shipped code,
+  you're running the wrong skill — use `/ux-check`.
+- **Propose, don't just critique.** Every finding includes a specific change suggestion.
+- **Reuse first.** The first question on every new component: *does a similar pattern exist?*
+- **Cite the practitioner / heuristic.** "Violates Nielsen #4 — consistency and standards"
+  beats "this is inconsistent."
+- **Capture the review.** Without `docs/design/reviews/`, the discipline doesn't compound.

package/stages/L2-v1/template/.claude/skills/ux-check/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: ux-check
+description: After-code UX review for {{PROJECT_NAME}}. Run against shipped UI to catch what slipped through `/design-review` or accumulated as drift. Walks the actual user journey (not the spec), checks the 5 states are real (not just designed), runs accessibility heuristics, applies AI-specific UX where relevant. Pairs with `/design-review` (before-code) — same lens, different timing. Usage - /ux-check [route-or-component-path | FEAT-NNN]
+---
+
+# /ux-check — after-code UX review
+
+The before-code review catches design-spec failures; this skill catches *implementation*
+failures — the gap between what was specced and what shipped. Most production UX failures
+live in this gap: the empty state was designed but never built; the loading state defaults to
+a spinner instead of the designed skeleton; the error state shows raw stack traces because
+the recovery path was an afterthought.
+
+This is also where AI-generated drift becomes visible. Even with `/design-review` upstream, the
+`coder-generalist` (or AI doing the same role) sometimes ships a slight variant that
+accumulates. `/ux-check` catches that.
+
+## When to run it
+
+- A FEAT just landed and is functionally working — *before* it's considered "shipped."
+- A user reported a UX issue — start `/ux-check` here, walk to where the issue surfaces.
+- Routine audit — run against the most-recently-shipped FEATs every 1-2 weeks.
+- A new persona-reaction (v0.19) surfaced a UX concern — `/ux-check` validates whether the
+  persona's read matches the shipped reality.
+
+## How to run it
+
+1. **Pick the surface.** A specific route, a component, or the FEAT-NNN whose UI is being
+   reviewed.
+2. **Walk the actual flow.** Not the spec — the SHIPPED experience. Open the page; click
+   through; trigger every state.
+3. **Check the 5 states are real:**
+   - Default — does it look like the design?
+   - Hover — feedback visible?
+   - Active — feedback during the action?
+   - Disabled — *and the reason for disabled* (so the user can act on it)?
+   - Empty — designed copy + visual, not "no results"
+   - Loading — skeleton (almost always) not spinner
+   - Error — recovery path, not just error text
+4. **Accessibility heuristics:**
+   - Tab through every interactive element; focus visible at each step?
+   - Read with screen reader (or use semantic HTML inspection); does the announced output
+     make sense in isolation?
+   - Color isn't the only signal (red alone for error, green alone for success — fail)
+   - Contrast ratios meet WCAG 2 AA
+   - Touch targets ≥ 44×44 px on mobile / responsive
+5. **Nielsen heuristics walk:**
+   - **#1 Visibility of system status** — does the user always know what's happening?
+   - **#3 User control and freedom** — is undo / cancel / back available where consequential?
+   - **#5 Error prevention** — does the design avoid errors rather than just handle them?
+   - **#9 Help users recognize/diagnose/recover from errors** — error states with recovery
+     paths?
+6. **AI-specific UX (where applicable):**
+   - AI as **options**, not truth — visible confidence; multiple plausible answers where
+     uncertainty exists
+   - **Human-in-the-loop** on consequential actions (no auto-apply on irreversible)
+   - **Undo / edit / regenerate** on AI outputs
+   - **Deliberate failure states** — what does the user get when the AI is unavailable / wrong /
+     slow?
+7. **Capture findings** in `docs/design/ux-check-<feat-or-date>.md`. Each issue: severity
+   (blocking / serious / minor / nit), the specific scene, the proposed fix.
+
+## What this skill does NOT do
+
+- Doesn't fix the code. Findings route to `coder-generalist` (or stack-specific coder) for
+  fixes.
+- Doesn't replace usability testing with real users (Erika Hall's discipline — *Just Enough
+  Research*). Heuristic walkthroughs catch a lot but miss what real users do.
+- Doesn't approve when issues are recorded as overrides. Same override discipline as
+  everywhere else: skip with substantive rationale + re-open conditions.
+
+## How findings feed back
+
+- **Token violations** (raw hex in shipped code) → `design-drift-loop` is detecting this; this
+  skill cross-confirms
+- **Pattern reinvention** (new component that duplicates existing) → flag the duplicate;
+  propose consolidation
+- **Missing states** → these are the most common shipped-UX failures; track them as a category
+  in `docs/design/ux-check-summary.md` so you can see if a particular state-category is your
+  pattern weakness
+- **AI-UX issues** → may surface needs for the v0.20 cohort-aware-conscience design (the
+  conscience speaks differently per cohort about how to fix AI-UX)
+
+## Rules
+
+- **Walk the actual flow.** The spec might say the empty state is designed; the shipped
+  reality might say "No results." Trust the experience, not the spec.
+- **Severity matters.** A blocking accessibility issue is not the same as a polish issue;
+  don't flatten the list.
+- **Capture every check.** Without `docs/design/ux-check-*.md` files, the discipline doesn't
+  compound.
+- **Pair with personas (v0.19) where relevant.** A persona's reaction to a flow can surface
+  cohort-specific UX failures that the heuristic walk misses.

package/stages/L2-v1/template/claude-append.md

@@ -0,0 +1,59 @@
+## V1 working rules (added on `boss unlock v1`)
+
+> {{MODE}} mode is *ready for a real, shippable release*. The design layer turns on, the second
+> tier of mentors arrives, and discipline tightens on the parts that matter when real users meet
+> the product. Same JIT principle — nothing imposed until earned — but the V1-stage ceremonies
+> are now earned.
+
+1. **Design tokens are authoritative.** Every style value comes from `docs/design/DESIGN_TOKENS.md`
+   + the corresponding code file. The `design-drift-loop` watches for drift — raw hex codes,
+   near-duplicate components, tokens-file-untouched-while-components-grow. New colors are added
+   to the tokens, never inline. (Future: PostToolUse hook for hardcoded-style detection lands in
+   v0.23.)
+2. **`/design-review` before code; `/ux-check` after.** Design choices that touch user-facing
+   surfaces run through both. Review by `ui-designer` (token + visual authority) and `ux-designer`
+   (flows + states). The 5-state requirement is non-optional: every interactive element specifies
+   default / hover / active / disabled / empty (and loading where relevant).
+3. **`/board` is the sequencing surface.** Cross-FEAT prioritization. Read by `program-manager`
+   (the *when*, not the *what*). What's blocked, what's parallelizable, what's next.
+4. **Data shape is a decision, not an accident.** `db-architect` reviews schema before code, even
+   in solo-builder mode. Schema migrations are first-class; ad-hoc column adds are flagged.
+5. **The mentor board has full V1 quorum.** `mentor-business` (model + pricing — Patrick Campbell,
+   Madhavan Ramanujam, the right-sized voices). `mentor-fundraising` (Janz, Skok — defaulting to
+   "don't raise" unless earned). `mentor-pitch` (Raskin spine, Miller story-driven, Neumeier
+   simplicity). `mentor-talent` (Hughes Johnson, the right-sized team voices). All advisory; never
+   binding legal/financial/medical.
+6. **The conscience still runs.** Every prior moment (caution, Done, restraint, coherence) keeps
+   firing — V1 doesn't replace earlier discipline, it adds the V1-specific surface.
+
+## What V1 adds (alongside MVP)
+
+- **Skills:**
+  - `/board` — cross-FEAT sequencing surface (`program-manager`'s authoritative view)
+  - `/design-review` — before-code design review against tokens + brand + 5 states
+  - `/ux-check` — after-code review of flows, interaction patterns, Nielsen heuristics
+- **Builder agents:**
+  - `ui-designer` — token + visual authority. Cites Brad Frost (Atomic Design), Nathan Curtis
+    (layer-cake tokens), Jina Anne (W3C DTCG). Refuses raw hex unless overridden; pairs with
+    `voice-keeper` (BOSS-internal) when copy is involved.
+  - `ux-designer` — flows + states + interactions. Cites Don Norman (affordances), Jakob
+    Nielsen (10 heuristics), Steve Krug (clarity), Luke Wroblewski (forms/mobile).
+  - `db-architect` — schema design, indexes, query patterns. Cites the AI-native data voices
+    (Liu on structured outputs) + classical (Stonebraker, Date, Codd).
+- **Mentor agents** (promoted from BOSS-local in v0.15 to template here):
+  - `mentor-business` — model, pricing, packaging, willingness-to-pay
+  - `mentor-fundraising` — whether / when / how to raise; defaults to *don't*
+  - `mentor-pitch` — story + deck + 60-second-version + demo arc
+  - `mentor-talent` — first hires, contractor vs employee, operating cadence
+- **Loops:**
+  - `design-drift-loop` — V1-stage; emits the `coherence` moment when system-vs-code drift
+    exceeds threshold (raw hex codes appearing, near-duplicate components, tokens file
+    stale while components grow)
+- **Conventions:**
+  - `docs/design/DESIGN_TOKENS.md` is authoritative (created at MVP via `/design-tokens-init`;
+    enforced at V1)
+  - `docs/design/STYLE_GUIDE.md` documents how tokens compose into patterns
+  - `docs/architecture/` carries db-architect's schema decisions
+  - `docs/board.md` (or live-state computed from FEAT frontmatter) drives `/board`
+- **Graduation:** when the team grows, the org gets real, and a product council needs to be a
+  thing — `boss unlock scale`.

package/stages/L2-v1/template/docs/loops/design-drift-loop.md

@@ -0,0 +1,108 @@
+---
+id: design-drift-loop
+type: loop
+stage: L2-v1
+runner_type: hook
+attributed_to: [Brad Frost, Nathan Curtis, Diana Mounter]
+also_relevant: [Dan Mall, Jina Anne, Ajesh Shah]
+entry:
+  - exists: { path: docs/design/DESIGN_TOKENS.md }
+exit:
+  - count_at_least:
+      path_glob: src/**
+      pattern: '#[0-9a-fA-F]{3,8}\b'
+      min: 1
+      exclude_files_matching: '\.tokens?\.|\.theme\.|DESIGN_TOKENS'
+drift_moment: coherence
+---
+
+# Loop: design-drift (V1)
+
+The V1-stage counterpart to `design-tokens-loop` (MVP). MVP-stage gates *whether the tokens
+exist*; V1-stage gates *whether the tokens are still authoritative.* The drift signal: raw hex
+codes appearing in source files, near-duplicate components multiplying, the tokens file going
+stale while components grow. The IDEA-010 failure mode catalog (47 blues, pattern
+reinvention, billion-line drift) materializing despite the MVP-stage discipline.
+
+`runner_type: hook` — the conscience hook evaluates this on every UserPromptSubmit at V1. The
+entry predicate (tokens file exists) is met for any project that has unlocked V1 with the
+MVP-stage `/design-tokens-init` having been run. The exit predicate is **inverted** — when the
+exit predicate *fires* (≥1 raw hex code in code, excluding the tokens-file itself), the loop
+is "stalled" and the conscience emits `coherence`.
+
+This is a subtle pattern worth naming: most loops have *positive* exit predicates ("the
+artifact exists"). This loop's exit predicate is *the bad signal* — "raw hex codes exist" —
+and the loop is "drift-emitting" when that bad-signal is present. The IDEA-008 primitive
+supports this without modification (predicate ok-ness is just boolean state).
+
+## Entry artifact
+
+`docs/design/DESIGN_TOKENS.md` exists. Set during MVP-stage via `/design-tokens-init`. If a
+project is in V1 mode without this file, design-tokens-loop should re-open (founder skipped
+it at MVP).
+
+## Purpose
+
+Catch design-system drift early. When a raw hex code lands in committed source code, the
+conscience surfaces a `coherence` nudge — "you shipped `#FF6B35` directly in
+`src/components/<X>`; should this be a new token in the system (and then referenced by
+name)?" The founder either:
+- Routes the value through the token system (the fix)
+- Records an override (legitimate when the value is genuinely one-off / debug / non-shipping)
+
+## Exit artifact
+
+This loop is "closed" when **no raw hex codes** exist in source code (excluding the tokens
+file itself and any `*.tokens.*` / `*.theme.*` config files where raw values legitimately
+live).
+
+## Drift
+
+`entry: satisfied` (tokens file exists) AND `exit: not satisfied` (raw hex codes exist) →
+loop open → conscience emits `coherence`.
+
+Confidence scales with the count of raw hex codes:
+- 1-3: low (might be transient — feature in flight)
+- 4-10: medium (real accumulation)
+- 11+: high (the 47-blues failure mode is in progress)
+
+The voice (cohort-aware per v0.20):
+- `vibe-coder-newbie` / `first-product`: explain *why* this matters; route to the token
+- `eng-builder` / `returning-founder`: terse — list the files, propose the consolidation
+- `vibe-virtuoso`: lean into the architecture — "your component pattern's drifting; want me
+  to consolidate to the token?"
+- `non-tech-founder` / `domain-expert`: plain language — "the visual system is drifting; the
+  AI will compound this if we don't fix it now"
+- `indie-hacker`: right-sized — "if this is throwaway, override; if it's keeping, consolidate"
+
+## How to remix
+
+- **Skip:** legitimate when the UI is genuinely one-off (a debug page, an internal admin
+  tool, a transient feature). Override grammar:
+  ```
+  - **OVERRIDE:** proceeded with raw hex in `src/<file>` — rationale: <one-off /
+    debug / not-user-facing>; expires <date or never>.
+  ```
+- **Swap predicate scope:** add `not_path_glob` filters to exclude specific directories
+  (e.g., `src/admin/**`) if a whole directory legitimately operates outside the design system.
+  Edit this loop spec's frontmatter; record the rationale in `docs/devlog.md`.
+- **Tighten predicate:** add detection for near-duplicate components (similar file sizes,
+  similar import patterns) — V1+ heuristic. Author the predicate; consider promoting via
+  `/boss-learn` if it generalizes.
+
+## When this loop re-opens
+
+- A raw hex code is added to a source file
+- The tokens file is renamed or deleted (entry fails — re-open as unopenable; route to
+  `/design-tokens-init` to re-establish)
+- A new stack is introduced where the predicate's regex doesn't match — update the spec
+  with the new stack's pattern
+
+## Future v0.23+: PostToolUse hook
+
+A PostToolUse hook (fires *after* Edit/Write tool calls) can catch raw style values *at
+write-time* — before they're committed. The hook would flag the value, propose the token,
+and let the founder accept/override. Deferred from v0.22 because PostToolUse is a different
+hook surface than UserPromptSubmit (BOSS's only hook type today). The pre-commit drift
+detection (this loop) is the v0.22 substitute; the at-write-time detection is the
+v0.23+ upgrade.

package/stages/L3-scale/README.md

@@ -0,0 +1,13 @@
+# L3 · Scale — NOT YET AUTHORED
+
+The full agentic-org mode — "a fully blown-out, complex app." Planned contents (generalized from dhun):
+
+- PM org: Chief of Staff (`pm`) + Principal-PM pattern, `/pm`, `/pm-roundup`, `/product-council`
+- lab governance tiers (3-tier change control for algorithm-like subsystems)
+- `/refactor-wave` (Saaf/Dabba wave decomposition) + rollback
+- `/code-health`, `/perf-check`
+- `/saturday` cadence chain, `/reflect`
+- full IDS: `RFC-NNN`, `DEC-...`, `EXP-NNN`, `AUDIT-NNN`
+- agents: `historian`, `code-health-lead`, `release-manager`, Principal PMs
+
+To author: add `manifest.json` + `template/` here.