bossbuild 0.97.0

package/stages/L1-mvp/template/.claude/skills/ai-first-init/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: ai-first-init
+description: Bake the AI-first discipline into {{PROJECT_NAME}} from day one. Conductor skill — walks the founder through declaring what's AI-mediated (docs/ai-first.md), seeding structured outputs (Liu — docs/schemas/), running the eval set early (Husain — /evals), declaring the cost budget upfront (/ai-cost), and designing failure states before they happen (/ai-failure-states). The "from day one" sequence. Cohort-aware. Run during MVP unlock for AI-native projects, or any time the project becomes AI-mediated. Usage - /ai-first-init
+---
+
+# /ai-first-init — bake the AI-first discipline upfront
+
+Most AI-mediated apps bolt on discipline after a surprise. Cost budget after the bill. Eval
+set after the bug report. Failure-states after the production incident. Structured outputs
+after the third schema-violation bug. This skill is the upfront sequence: declare the
+discipline *before* shipping the first user-visible LLM call, so the next FEAT inherits a
+spine instead of inventing one under pressure.
+
+It's the move that earns BOSS its name. Cursor + a folder is "AI-native." BOSS + this skill
+is *"AI-first with discipline from day one."*
+
+## What "AI-first" means here
+
+A project is **AI-first** when the model is *load-bearing* — the product doesn't work without
+it. Not "we have a chat feature." Not "we use Claude to summarize." AI-first means:
+
+- The core value proposition depends on the model behaving correctly.
+- Failure modes (garbage / refusal / hallucination / timeout / cost-spike) are user-visible.
+- Unit economics live or die on token math.
+- The "engineering" task is half prompt design, half eval design, half schema discipline.
+  (Yes, that's 1.5 — the AI part *crowds out* deterministic work.)
+
+If you're using AI as a feature inside a non-AI app, you may not need this whole sequence —
+run pieces (`/ai-cost` for sure; `/evals` for any LLM in control flow). If you're building
+something the model can't be removed from, run this whole skill.
+
+## The five-step AI-first sequence
+
+This skill is the **conductor**. Each step calls a sub-skill or writes a doc. The founder
+runs them in order; the skill keeps state in `docs/ai-first.md`.
+
+### Step 1 — Declare what's AI-mediated
+
+Write `docs/ai-first.md` with the founder's answer to four questions:
+- **What's AI-mediated?** Which features depend on the model.
+- **What's deterministic?** Which features explicitly DON'T touch the model (and why —
+  keeping a deterministic core is usually correct).
+- **What's the load-bearing model decision?** Which model, which version, what would change
+  if it got swapped.
+- **What's the cost shape?** Order-of-magnitude tokens per user-action; whether this is
+  a per-user-day or per-action cost model.
+
+Template:
+
+```markdown
+---
+id: ai-first
+type: declaration
+owner: pm
+status: declared
+updated: {{DATE}}
+---
+
+# AI-first declaration — {{PROJECT_NAME}}
+
+## What's AI-mediated
+- <feature 1> — uses <model> for <purpose>; the output drives <user-visible behavior>.
+- <feature 2> — ...
+
+## What's deterministic (and stays deterministic)
+- <feature> — no LLM. Reason: <correctness requires it / cost-prohibitive at scale / etc.>
+
+## Load-bearing model decisions
+- **Primary model:** <e.g., claude-sonnet-4-6>
+- **Why this one:** <quality / speed / cost rationale>
+- **Pinned version:** <yes/no — pin during MVP; unpin when evals cover regressions>
+- **Fallback model (when primary fails):** <e.g., claude-haiku-4-5; deterministic only>
+
+## Cost shape (order-of-magnitude)
+- Per user-action: ~<N> input tokens, ~<M> output tokens
+- Per user-day: ~<N> actions → ~$<X>/user/day (matches docs/ai-cost-budget.md)
+
+## The five failure states (cross-references docs/ai-failure-states.md)
+- Designed: <yes/no — set to yes when /ai-failure-states has run>
+
+## Eval discipline (cross-references docs/evals/)
+- Eval set exists: <yes/no — set to yes when /evals has seeded the first set>
+- Categorization: <yes/no — Husain failure-mode categorization in place>
+
+## Structured outputs (Liu)
+- Schemas declared: <yes/no — set to yes when docs/schemas/ has stubs>
+- Schema enforcement: <none / runtime validation / both>
+```
+
+### Step 2 — Seed structured outputs (Liu)
+
+Free-form prose is for human eyeballs only. If the LLM output drives subsequent code (control
+flow, data routing, decisions), **schema it**. Pydantic-first / Zod-first / any-structured-
+output. Single practice that eliminates ~80% of LLM-pipeline brittleness.
+
+Create `docs/schemas/` with one starter file per AI-mediated feature:
+
+```typescript
+// docs/schemas/feature-name.schema.ts (or .py for Pydantic)
+import { z } from 'zod';
+
+export const FeatureOutputSchema = z.object({
+  // Define the strict shape the model is expected to return.
+  // Validation at runtime; tests against this schema in evals.
+  result: z.string(),
+  confidence: z.number().min(0).max(1),
+  // ...
+});
+
+export type FeatureOutput = z.infer<typeof FeatureOutputSchema>;
+```
+
+The schema becomes the **contract** between the model and the rest of the code. Evals assert
+on the schema; failure-state handler #1 (garbage) IS schema-validation-failure.
+
+### Step 3 — Seed the eval set early (Husain)
+
+Don't wait for production. Run `/evals --new <feature-name>` (creates `docs/evals/FEAT-NNN.yml`)
+for each AI-mediated feature in step 1. Even 5 cases per feature beats 0. Categorize:
+should-pass / should-fail-by-mode (hallucinates / refuses-wrongly / format-violation / over-
+applies / etc.).
+
+Set the eval as a **gate before shipping the FEAT**, not retrofitted after. The MVP rule:
+*"20 examples beats 0."*
+
+### Step 4 — Declare the cost budget (`/ai-cost`)
+
+Run `/ai-cost`. It walks the founder through `docs/ai-cost-budget.md` — per-user/day budget
+(cohort-aware default), per-call model rationale, the cost-logger wrapper, the review
+cadence. Cross-reference the cost shape from step 1.
+
+This step is non-negotiable for AI-first projects. The bill IS the design constraint; you
+cannot design around something you haven't named.
+
+### Step 5 — Design failure states (`/ai-failure-states`)
+
+Run `/ai-failure-states`. It walks the founder through the five failure modes (garbage /
+refusal / hallucination / timeout / cost-spike), each with a project-specific declared
+response, and writes stub handlers in code so the discipline is wired before the first user
+sees a failure.
+
+This step closes `ai-failure-state-loop` and finalizes the AI-first declaration.
+
+### Step 5.5 — Name the security surface (the lethal trifecta)
+
+The moment an AI feature reads untrusted input (a web page, a user's pasted text, an email, a
+dependency), takes consequential action, *and* can reach private data, you've assembled the
+attacker's ideal surface. Security here is **architectural, not a prompt** — you can't ask a model
+to never be tricked, only constrain what a tricked model can *do*. Name it once now:
+
+- **Lethal trifecta** — danger needs all three together: *untrusted input* + *access to private
+  data* + *ability to act/exfiltrate*. Remove any one for a given step and the attack can't complete.
+- **Rule of Two** — prefer that any single step has at most two of the three. Reading untrusted web
+  content? Don't also hand that step secrets and an open network.
+- **Enforce in the harness, not the prose** — the `permissions.deny` floor ships with every BOSS
+  project; high-stakes/regulated cohorts add the `secrets-guard` hook (a *deterministic* guard;
+  never trust a non-deterministic safety classifier alone). Sandbox untrusted-input steps; pin deps;
+  put a real stop on the irreversible (push / deploy / delete / send).
+
+Full practice: `library/practices/agent-security.md` (Willison 2026). For a day-one Quickstart this
+is one sentence; it earns more ceremony as the app reads untrusted input or handles regulated data.
+
+### Step 6 — Update `docs/ai-first.md` cross-reference fields
+
+After the sub-skills run, return to `docs/ai-first.md` and flip the cross-reference fields:
+- Failure states designed: **yes**
+- Eval set exists: **yes**
+- Categorization: **yes**
+- Schemas declared: **yes** / **partial**
+
+The doc becomes the **AI-first checklist** for this project. Future-you reads it before
+starting work; new contributors read it to onboard.
+
+## Cohort-aware delivery
+
+| Cohort | Posture |
+|---|---|
+| `first-product` | Walk through each step as a teaching moment. Name what the discipline is *for* (not just what to do). Show the failure-mode-that-this-prevents in each step. |
+| `vibe-coder-newbie` | Show + do. Don't lecture. After step 1 they may want to skip to building; gently insist on cost + failure-states upfront (those bite hardest). |
+| `non-tech-founder` | Plain-language framing. Each step described as *"the answer to a question the model will ask you later when it breaks."* They likely don't need to write schemas themselves; they need to know they exist + delegate. |
+| `eng-builder` | Terse. Hand them the checklist; they'll execute. The discipline names + citations matter to them (Liu, Husain). Skip the patter. |
+| `vibe-virtuoso` | They've shipped a lot. They likely *skipped* the discipline last time. *Don't coach the discipline they've read books about.* Ask sharper: "which of these did the last project burn you on? Start there." |
+| `indie-hacker` | Calm-company framing. The discipline IS the calm; each declared response is a non-panic posture. Frame cost as % of revenue. |
+| `returning-founder` | Skip the 101. *"Which of these is non-obvious for THIS project?"* Likely they want to focus on one or two steps; let them. |
+| `domain-expert` | **Stakes are real.** Hallucination handling defaults to **human-in-the-loop**; cost budget is privacy-first; failure states cite the regulatory frame. Take the full sequence seriously; this is the cohort where AI-first discipline most reduces real harm. |
+
+## When to run it
+
+- During `boss unlock mvp` when the project is AI-native — the `/boss` skill should have
+  recommended it during spin-up.
+- When a Quickstart project pivots to AI-mediated (e.g., the founder runs `/canvas` and the
+  Promises cell becomes "the model writes the answer").
+- After a real-production AI-failure surprise — re-run to extend the doc with the new mode.
+
+## Connection to other loops + skills
+
+- **Subroutines:** `/evals`, `/ai-cost`, `/ai-failure-states`.
+- **Upstream:** `canvas-loop` closed (riskiest assumption named — the model is the bet).
+- **Downstream:** future FEAT specs reference `docs/ai-first.md`; future `/spec` runs include
+  the failure-states field; the conscience surfaces `cost` and `failure-mode` moments when
+  drift accumulates against the declarations.
+- **Adjacent:** `/spec` — for AI-mediated FEATs, the spec template includes failure-states
+  field (v0.26.0+); `/evals` — eval set sits alongside the failure-state design.
+
+## What this skill is NOT
+
+- **Not a code generator.** It walks the founder through *declarations*; it stubs handlers
+  but doesn't implement them. The founder owns the implementation.
+- **Not a one-time ritual.** Re-run when the AI-mediated surface changes substantially.
+- **Not for AI-as-a-feature apps.** If the model is bolted onto a deterministic core, run
+  pieces (`/ai-cost`, maybe `/ai-failure-states` for the AI-touching code paths) but skip
+  the conductor.
+
+## Rules
+
+- **Day one means day one.** This skill runs *before* the first AI-mediated FEAT ships. Not
+  after the first user. Not after the first bill. Not after the first hallucination report.
+- **The doc IS the contract.** Future FEATs read `docs/ai-first.md`; if it says
+  "deterministic" for a feature and a PR puts an LLM call in there, that's a real change
+  worth a re-spec.
+- **Override grammar applies (IDEA-008).** Skipping a step is legitimate when the founder
+  has a real reason; record it in devlog. Skipping silently is the failure mode.
+- **Domain-expert cohort doesn't skip.** In high-stakes domains, every step matters
+  disproportionately. The hour spent here saves harm later.
+- **Cite the lineage.** When you author this skill in real practice, cite the spine: Husain
+  (evals + failure-mode categorization), Liu (structured outputs), Karpathy/Willison (the
+  failure surface IS the design surface), Mollick (cost as design input).

package/stages/L1-mvp/template/.claude/skills/close/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: close
+description: Session-end ritual — update docs/RESUME.md (state + next tasks + open decisions), append a /log entry, and let the conscience update its read on the venture (.boss/brain/). Run this before stepping away so the next session starts with full context. Usage - /close
+---
+
+# /close — leave the project ready for next session
+
+A session that ends without `/close` costs the next session 20 minutes of *what was I doing*. `/close`
+is the small ritual that prevents that: it writes the current state to `docs/RESUME.md`, captures
+what landed in the devlog (via `/log`), and leaves the working tree in a state your future self can
+walk back into cold.
+
+It's the counterpart to *read `docs/RESUME.md` first thing*.
+
+## Before the housekeeping: mark what was crossed
+
+`/close` is also the natural moment to *register a threshold* — because the relentless build never makes
+room for it, and a builder who only ever measures what's left slowly forgets that anything was achieved
+(see the `celebration-of-done` practice). If this session genuinely crossed one — a FEAT closed, the
+first live URL, a mode graduation, the riskiest assumption finally tested — pause and mark it **before**
+the forward-looking housekeeping below. The order matters: look back at what you crossed before you look
+ahead to what's next.
+
+- **Name what's real, specifically** — not "great session," but *what* got done and *what it now unlocks*.
+- **Re-anchor on the why and the who** — reconnect the thing you crossed to the bet (why it mattered) and
+  the person you built it for. The build pulls you into the *how*; this pulls you back to the *why*.
+- **Let it turn into curiosity** — *"does this land for them now?"* is the honest next feeling, and it's
+  the bridge back to the real user. A well-marked threshold makes the founder *want* to go find out — the
+  validation instinct, arriving through satisfaction instead of obligation.
+- **Proportional, no performed warmth, no streak.** Real thresholds only; most sessions cross none, and
+  silence is correct. This is the conscience's restraint with the polarity flipped — never "🎉 great job!"
+  (the exact flattery the brain-read step below forbids). Emotional acknowledgement is *making space for
+  the founder to feel it*, not BOSS emoting at them.
+
+## How to run it
+
+1. **Append a devlog entry** by running the `/log` flow (FEAT, landed, next, surprises). If `/log`
+   already ran this session, skip — don't duplicate.
+
+2. **Update `docs/RESUME.md`** (create if missing — template below). Rewrite, don't append:
+   - **State (current):** the one paragraph someone re-entering the project needs. What's true *now*.
+   - **Next tasks (in order):** the 1–3 concrete things to pick up. Concrete = "wire `/foo` to call
+     bar()", not "improve the feature."
+   - **Open decisions:** things waiting on a call (yours or someone else's). Each with a tentative
+     direction so you don't re-litigate from scratch.
+   - **Prompt for the next session:** keep it **evergreen** — a pointer + procedure, never a
+     status report. *State* and *Next tasks* already carry the current-state surface; restating
+     them here just doubles the drift surface. Save kickoff prompts somewhere stable (a shell
+     alias, a snippets app, the `Prompt for the next session` block) so they don't bit-rot
+     against the actual RESUME. If you find yourself writing *"we're at v0.X"* or *"X just
+     shipped"* in this block, delete it — that's what *State* is for.
+
+3. **Update the venture brain** (`.boss/brain/read.md`) — *the conscience's read on this venture,
+   not the task state*. This is the one thing in `/close` that isn't a status report: it's the
+   conscience forming a point of view it will *remember next session*. That continuity is what makes
+   the conscience feel like its own mind instead of a hook that forgets you. See the discipline below
+   — it is strict on purpose. Skip this step entirely if the session didn't reveal anything about the
+   *shape of the venture or how the founder is working* (a pure mechanical session has nothing to read).
+
+   - **Append, don't rewrite.** Add a dated `## YYYY-MM-DD` section to `.boss/brain/read.md` (create
+     the file if absent). The brain is append-mostly — history is the point.
+   - **The brain evolves; it doesn't just accrete (staleness is a write-side job).** Before you append,
+     re-read the standing summary at the top: has the work *overtaken* any claim in it? A riskiest
+     assumption that shifted, a pivot that happened, a "they keep doing X" that's no longer true — a
+     once-accurate read becomes *confidently wrong* the moment the venture moves past it. **Revise or
+     retire stale lines** in the standing summary as you write the new dated block. The most dangerous
+     brain isn't the empty one — it's the one citing yesterday's truth with today's confidence.
+   - **Living memory, not infinite memory — compress when the read gets long.** If `boss brain` flags
+     that the read spans many sessions (the recency-window nudge), fold the *oldest* dated reads' lasting
+     conclusions into the standing summary at the **top** of `read.md` (the preamble, above the first
+     dated header), then drop those verbatim old blocks. Keep the recent ~8 dated reads as-is. Compression
+     is the model's job (you can summarize meaning); the founder can also evict directly with
+     `boss brain forget --before <date>`. The standing summary is what survives; the dated blocks are the
+     working history that ages out.
+   - **First-person, from the conscience.** "I'm noticing…", "Three sessions in, the pattern is…".
+     It's a read, not a log.
+   - **Interpretation across time, never facts or claims.** Facts live in the canvas/RESUME/devlog. The
+     brain holds *only* what those can't: "they keep rebuilding onboarding instead of talking to a
+     user," "conviction on the wedge is hardening, not drifting," "last session they pushed back on the
+     drift nudge — and they were right." If a sentence could be a canvas edit or a RESUME task, it
+     belongs there, not here.
+   - **The must-nots (this is the trust line):** no flattery ("great work!"), no diagnosing the
+     founder, no certainty the sessions don't support. If you're not sure, say less. A wrong, confident
+     read about a *person* is the one mistake that makes BOSS feel creepy instead of alive.
+   - **Ground every claim.** Name what in the actual work supports the read (a FEAT, a devlog pattern,
+     a repeated capture). No claim the artifacts can't back. This groundedness is exactly what makes the
+     read land as "how did it know that" rather than a fortune cookie.
+   - **Honest when thin.** One session in, you don't have a read yet — write that, or write nothing.
+     Don't manufacture depth.
+   - **Confirmable.** Show the founder the section you're about to write and let them correct it before
+     it lands. It's an opinion *about them* — they get the edit. (This stays confirmable until the
+     brain-write eval proves the reads are trustworthy; then it can graduate to silent-but-inspectable.)
+   - **Stamp the index** after the prose lands: `boss brain record --headline "<one-line of the read>"`
+     so `boss brain` / `boss brain --diff` stay truthful without parsing the prose.
+   - The founder owns it: it's plain markdown they can read with `boss brain` and correct by editing
+     `.boss/brain/read.md` directly.
+
+3b. **Update the relationship log** (`.boss/brain/relationship.md`) — *only if the conscience actually
+   said something this session.* This is the loop the frequency ledger only *counts*: did the nudge
+   **land**? Append a dated `## YYYY-MM-DD` entry recording, honestly and briefly:
+   - **What the conscience flagged** (which moment, in one line — "drift: named retention as the bet but
+     built onboarding").
+   - **What the founder did with it** — and tag the outcome plainly: *landed* (acted on it), *ignored*
+     (moved past without engaging), *overrode* (declined with a stated reason — note the reason; a good
+     override is data, not a failure), or *pushed back and was right* (the nudge was wrong — the most
+     valuable entry; it's how the conscience learns to fire better).
+   - **The must-nots carry over:** no scoring the founder, no "you should have listened." This is the
+     conscience being honest about *its own* hit rate, not grading the person.
+   - If the conscience stayed silent all session (nothing fired), write nothing here — an empty
+     relationship log is the honest state, not a gap to fill.
+   - **Stamp it:** `boss brain record --kind relationship --headline "<flagged X → they did Y>"`. The
+     conscience reads this next session (bounded) to *calibrate* — it won't re-nag a point you've
+     already answered, and it can build on a nudge that landed. View it: `boss brain --relationship`.
+
+4. **Check the working tree.** If there are uncommitted changes the user wants to keep but isn't
+   committing now, mention them in RESUME's *State* so next-you isn't surprised. Don't auto-commit.
+
+5. **Report what you wrote.** One line: "RESUME updated · devlog entry added · brain read appended ·
+   N uncommitted change(s) noted." Then stop — don't summarize the session further; the artifacts are
+   the summary.
+
+## The RESUME template (used when none exists yet)
+
+```markdown
+---
+id: RESUME
+type: resume
+owner: pm
+status: active
+updated: {{today}}
+---
+
+# RESUME — {{PROJECT_NAME}}
+
+**Read this first each session.** State + next tasks + open decisions.
+
+## What this project is
+_One paragraph. The current articulation — sharpen as the project sharpens._
+
+## State (current)
+- _What's real right now: shipped FEATs, the smoke command, the stack._
+- _Anything uncommitted worth knowing about._
+
+## Next tasks (in order)
+1. _Concrete. Single-session-shaped if possible._
+2. …
+
+## Open decisions
+- _Question — tentative lean — what would close it._
+
+## Prompt for the next session
+> _**Keep this evergreen** — a pointer + procedure, never a status report._
+>
+> Continue {{PROJECT_NAME}}. Read `docs/RESUME.md` (this file — *State* + *Next tasks* +
+> *Open decisions*), `CLAUDE.md`, then `VERSION` + `CHANGELOG`. Cross-check `git log -3`
+> against what RESUME claims — if they disagree, RESUME is stale; re-establish ground truth
+> first. Then pick up *Next tasks* top down.
+
+## Working reminders
+- _Commands, env vars, things easy to forget._
+```
+
+## Rules
+
+- RESUME is rewritten, devlog is appended. The devlog is history; RESUME is the current pointer.
+- Keep RESUME short — under a page. If it grows past that, you're putting reference material in the
+  wrong file; move it to its own doc and link.
+- Don't run `/close` if the session was a one-line conversation; reserve it for sessions that moved the project.
+- If there's *real* unfinished work (a half-applied refactor), call it out in **State** in plain language.
+  Surprises in the next session are the failure mode this skill exists to prevent.

package/stages/L1-mvp/template/.claude/skills/consult/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: consult
+description: Convene the mentor board on a cross-cutting question — route it to the mentors who actually have a stake, get each one's take in their own lens, and synthesize the answer with the disagreements kept visible (not averaged away). The humane lens can override. Advisory only — the mentors inform; you decide. Usage - /consult <question>
+---
+
+# /consult — convene the board on a real question
+
+Some questions don't belong to one mentor. *"Should I raise now, or grow to profitability first?"*
+touches fundraising, business model, GTM, and the humane lens at once. `/consult` puts the question in
+front of the mentors who actually have a stake, gets each one's honest take **in their own lens**, and
+hands you a synthesis that **keeps the disagreement visible** — because where seasoned advisors
+disagree is exactly where the real decision lives.
+
+It's the orchestration layer over the individual `mentor-*` agents: instead of asking them one at a
+time and holding the threads in your head, `/consult` runs the panel and composes the result.
+
+## When to run it
+
+- A decision spans more than one domain (raise vs. bootstrap, pricing vs. positioning, hire vs.
+  contract, ship-fast vs. get-it-right).
+- You're about to make a call you can't easily reverse and want the board's read first.
+- A single mentor gave advice and you want to pressure-test it against the others' lenses.
+
+## How to run it
+
+**1. Read the question.** If none given, ask for it in one line. Note what's really being decided.
+
+**2. Pick the mentors who have a stake** — only the relevant ones, not the whole roster (convening
+mentors who have nothing to add is noise). Read which mentors are installed (`.boss/manifest.json`
+`agents`, the `mentor-*` ones) — the board grows by mode, so consult what's seated:
+- MVP seats `mentor-architect` + `mentor-gtm`; V1+ adds `mentor-business`, `mentor-fundraising`,
+  `mentor-talent`; `mentor-humane` + `mentor-venture` are seated early and **always** get a voice on a
+  real decision.
+- Map the question to lenses: a raise question → fundraising + business + venture (+ humane); a
+  build-speed question → architect + venture (+ humane); a pricing question → business + gtm.
+
+**3. Get each mentor's take in their own voice.** Consult each relevant mentor (their agent), with the
+*same* question + enough context (read the canvas / RESUME / the relevant FEAT so they're grounded).
+Each returns their honest read — including pushback. Don't homogenize; a mentor's job is their lens,
+not consensus.
+
+**4. Synthesize — keep the disagreement visible.** Compose the panel's answer:
+- **Where they converge** — the points all (or most) lenses agree on. Usually the safe ground.
+- **Where they diverge** — name it plainly: *"fundraising says raise now to fund the GTM motion;
+  business says your unit economics aren't ready and a raise just buys time you'll burn."* The
+  divergence is the actual decision — don't paper over it with an average.
+- **The humane override** — `mentor-humane` has explicit override authority. If it flags a real
+  agency/dignity/attention harm, that lens wins regardless of the viability case, and say so.
+- **The riskiest assumption** — tie the decision back to the canvas's named bet where relevant.
+
+**5. Hand the decision back.** End with the call that's *yours* to make, framed: *"the board's split is
+real; the question under the question is <X> — which way you lean depends on <the thing only you
+know>."* Mentors are advisory. They inform; you decide. Record the call (and which lens you followed,
+and why) in `docs/devlog.md` so future-you sees the reasoning, not just the outcome.
+
+## If a venture brain exists
+If `.boss/brain/` is present (the conscience's persistent read on this venture — IDEA-022), read it
+for context before convening, and append a one-line note on what was decided after. The board's reads
+sharpen the brain; the brain grounds the board. (Skip silently if it isn't there.)
+
+## Rules
+
+- **Relevant mentors only.** Convening a mentor with no stake is noise. Pick the lenses that bear on
+  *this* question.
+- **Disagreement is the product.** Never average seasoned advisors into mush. The split is where the
+  decision is — surface it.
+- **Humane can override.** A real humane concern outranks the viability case (mentor-humane's standing
+  authority). Say when it's been invoked.
+- **Advisory, never a gate.** `/consult` informs; it never blocks or decides. The founder decides and
+  records the call.
+- **Ground them.** Mentors reading nothing give generic advice. Feed each the canvas + relevant
+  context so the read is about *this* venture, not ventures-in-general.