@polderlabs/bizar 9.0.0 → 10.0.7

package/.claude/commands/goal.md

@@ -1,98 +0,0 @@
----
-description: Add or update a long-horizon goal in .bizar/PROGRESS.md — same source-of-truth as the v8 dashboard Goals view.
----
-
-# Goal — Track a Long-Horizon Commitment
-
-You are in `/goal` mode. The user has invoked this command to add or
-update a **goal** in `.bizar/PROGRESS.md`. This file is the single
-source of truth for goals — both the v8 dashboard's Goals view and
-Claude Code's `/goal` slash command read from and write to it.
-
-## Contract
-
-- **Goals live in `.bizar/PROGRESS.md`** in the active project root.
-  Parse the current file first so you don't clobber existing goals.
-- **Round-trip via the dashboard API.** The dashboard server is the
-  canonical writer — it owns the parsing + serialization logic
-  (`bizar-dash/src/server/progress-parser.mjs`) and broadcasts a
-  `goals:change` WebSocket event so the dashboard updates live. **Do
-  not edit PROGRESS.md directly** unless the dashboard is down.
-- **Use the dashboard's HTTP API by default.** Resolve the dashboard
-  port from `~/.cache/bizarharness/dash-auth.json` (`port` field), then
-  POST/PATCH. This keeps goals in lock-step with whatever the
-  dashboard user is looking at.
-
-## API surface (S10/S12)
-
-```
-GET    /api/goals                        # list all parsed goals
-POST   /api/goals    { title, owner?, due? }   # create
-GET    /api/goals/:id                    # single goal
-PATCH  /api/goals/:id { title?, owner?, due? } # rename / reassign / re-due
-PATCH  /api/goals/:id/status  { status }       # on-track | at-risk | done | blocked | active
-POST   /api/goals/:id/key-results  { title }   # append KR
-PATCH  /api/goals/:id/key-results/:krId { title?, done? }  # toggle / rename
-DELETE /api/goals/:id/key-results/:krId         # remove KR
-```
-
-## Examples
-
-### Add a goal
-
-```bash
-PORT=$(jq -r .port ~/.cache/bizarharness/dash-auth.json)
-curl -s -X POST http://127.0.0.1:$PORT/api/goals \
-  -H "Content-Type: application/json" \
-  -d '{"title":"Ship v8 dashboard","owner":"sam","due":"2026-09-30"}'
-```
-
-### Change a goal's status to at-risk
-
-```bash
-curl -s -X PATCH http://127.0.0.1:$PORT/api/goals/G-abc123/status \
-  -H "Content-Type: application/json" \
-  -d '{"status":"at-risk"}'
-```
-
-### Add a key result
-
-```bash
-curl -s -X POST http://127.0.0.1:$PORT/api/goals/G-abc123/key-results \
-  -H "Content-Type: application/json" \
-  -d '{"title":"Cut S9 polish time in half"}'
-```
-
-### Mark a key result done
-
-```bash
-curl -s -X PATCH http://127.0.0.1:$PORT/api/goals/G-abc123/key-results/KR-xyz \
-  -H "Content-Type: application/json" \
-  -d '{"done":true}'
-```
-
-## When the dashboard is unreachable
-
-Fallback path: write directly to `<active-project>/.bizar/PROGRESS.md`
-using the format the parser understands:
-
-```markdown
-## G-<id> — <Title>
-Owner: <name> · Due: <YYYY-MM-DD>
-Goal is **<status>**.
-
-- [ ] <key-result title>
-- [x] <done key-result title>
-```
-
-Then when the dashboard comes back up, `GET /api/goals` re-parses the
-file and broadcasts a `goals:change` event to refresh the UI.
-
-## Background: why this exists
-
-`/goal` was added in S12 of the v8 dashboard rewrite. Before this,
-goals lived only in the user's head and `FINAL_GOAL.md` (which is the
-user's own planning doc, not the harness's tracker). This command
-makes goals a **first-class dashboard entity** — they appear in the
-Goals view, the Overview stat tile, the Activity feed, and the
-command palette.

package/.claude/commands/init.md

@@ -1,29 +0,0 @@
----
-description: Run bizar init to detect project stack, install relevant skills, and create .bizar/PROJECT.md.
-allowed-tools: Read, Bash, Write, Glob
----
-
-# /init — Initialize `.bizar/` in the current project
-
-Run `bizar init` from the project root to:
-1. Detect the project stack (language, framework, database, tools)
-2. Install relevant skills from the skills registry
-3. Create `.bizar/PROJECT.md` with stack and conventions
-4. Create `.bizar/AGENTS_SELF_IMPROVEMENT.md` (only if missing)
-5. Build the per-project knowledge graph in `.bizar/graph/` (powered by graphify; skipped gracefully if graphify is not installed)
-
-After `bizar init` succeeds, run `bizar graph status` to confirm the graph exists.
-
-If the graph is missing after init, graphify is likely not installed. Tell the user to install it with one of:
-- `pip install graphifyy`
-- `pipx install graphifyy`
-- `uv tool install graphifyy`
-
-Then run `bizar graph build` to populate `.bizar/graph/`.
-
-Query the graph at any time with:
-- `bizar graph query "<concept>"` — find nodes related to a concept
-- `bizar graph path "<A>" "<B>"` — shortest path between concepts
-- `bizar graph explain "<X>"` — all nodes related to X
-
-Update the graph incrementally with `bizar graph update` after editing source files.

package/.claude/commands/learn.md

@@ -1,44 +0,0 @@
----
-description: Extract patterns from the current Claude Code session and append to .bizar/AGENTS_SELF_IMPROVEMENT.md.
-allowed-tools: Read, Write, Bash, Grep
----
-
-# /learn — Extract Patterns from the Current Session
-
-You are the `heimdall` (self-improvement) agent. Reflect on the
-current Claude Code session and extract reusable patterns, then
-append them to `.bizar/AGENTS_SELF_IMPROVEMENT.md`.
-
-## What to Extract
-
-1. **Recurring workflows** — anything you (or the user) repeated
-   three or more times in this session
-2. **Project-specific conventions** — stack quirks, naming patterns,
-   file layout choices that future sessions should know
-3. **Gotchas** — bugs you hit, footguns you discovered, workarounds
-   that worked
-4. **Tooling tips** — non-obvious `bizar` subcommands, project-level
-   scripts, MCP server tricks
-5. **Cross-session conventions** — anything that would help the next
-   agent hit the ground running
-
-## Process
-
-1. Re-read the session transcript. Identify 3-7 distinct patterns.
-2. For each, write a short block:
-   - **Pattern**: one-line title
-   - **Context**: when this applies
-   - **Action**: the concrete recipe
-   - **Example**: file:line or command snippet
-3. Append (do NOT overwrite) the formatted blocks to
-   `.bizar/AGENTS_SELF_IMPROVEMENT.md`. Add a dated header.
-4. If the file doesn't exist yet, create it with the standard
-   header first.
-5. Confirm the append succeeded by tailing the file.
-
-## Constraints
-
-- Don't duplicate content already in the file. Scan it first.
-- Don't extract one-off trivia. Patterns must be reusable.
-- Keep each block under ~10 lines. Long entries go in the per-agent
-  memory vault via `bizar memory add`.

package/.claude/commands/plan.md

@@ -1,35 +0,0 @@
----
-description: Open the Bizar visual plan canvas or manage existing plans.
-allowed-tools: Read, Write, Bash, WebFetch
----
-
-# /plan — Visual Plan Canvas
-
-Open or manage a Bizar visual plan. Plans are collaborative canvases for structuring work across agents.
-
-## Usage
-
-```
-/plan new <slug> [template]  — Create a new plan with a unique slug
-/plan list                   — List all existing plans
-/plan open <slug>            — Open a plan (returns the canvas URL)
-/plan get <slug>             — Get full plan content as JSON
-/plan add <slug> --title "..." — Add a new element to a plan
-/plan update <slug> <id> ...  — Update an element's content/title/status
-/plan delete <slug> <id>    — Delete an element from a plan
-/plan comment <slug> [id] "..." — Add a comment to a plan or element
-/plan comments <slug> [id]   — List comments on a plan or element
-/plan status <slug> <status> — Set plan status (draft|approved|rejected|in-progress|done)
-/plan wait <slug>            — Block until the plan receives feedback
-```
-
-## Routing
-
-- If the user wants to create a new plan → `/plan new <slug>`
-- If the user wants to see existing plans → `/plan list`
-- If the user wants to open/view a plan → `/plan open <slug>`
-- If the user wants to add content to a plan → `/plan add <slug> --title "..."`
-- If the user wants to modify a plan element → `/plan update <slug> <id> ...`
-- If the user wants to discuss/approve/reject → `/plan status <slug> <status>`
-
-The full arguments are available as `$ARGUMENTS`. Parse them and route to the matching subcommand above.

package/.claude/commands/plow-through.md

@@ -1,50 +0,0 @@
----
-description: Autonomous mode — work fully independently, make all decisions, complete the task end-to-end without asking the user anything.
----
-
-# Plow Through — Autonomous Mode
-
-You are in `/plow-through` mode. The user has invoked this command to tell you: **work autonomously, don't ask, decide things yourself, complete the task end-to-end.**
-
-## Contract
-
-- **No clarifying questions.** If the request is ambiguous, use the most reasonable interpretation based on project context. If you genuinely cannot proceed without user input (e.g., a destructive action requiring explicit authorization), log the blocker in your final report and continue with everything else.
-- **Decide things yourself.** Use your judgment. Read `.bizar/PROJECT.md`, `FINAL_GOAL.md`, `ROADMAP.md`, and search the memory vault (`bizar memory search "<topic>"`) for prior context before deciding.
-- **Split into parallel work streams.** Always dispatch 2+ subagents in parallel when the work is decomposable. Each stream must have a disjoint file scope. Use the **Agent tool** to spawn subagents — name them after the Bizar agent they represent (`thor`, `tyr`, `mimir`, `hermod`, etc.) so the audit trail stays readable.
-- **Work to completion.** Don't stop at "I did X, should I continue?". The task is complete when: the deliverable exists, tests pass, changes are committed and pushed (where applicable).
-- **Report at the end.** Summarize what was done, what tests ran, any blockers encountered.
-
-## Background agents for long-running work
-
-Use the **Agent tool** with `run_in_background: true` (or the
-dashboard UI) to spawn background agents for tasks that span more
-than a few minutes. Check on them later via the dashboard's
-Background Agents panel or by sending a message to the teammate
-agent.
-
-## When to use
-
-- Multi-file refactors that don't require user approval
-- Bug-fix sweeps across a known surface area
-- Implementing a clearly-spec'd feature from the roadmap
-- Migration tasks (e.g., "migrate all CSS from @apply to vanilla")
-- Cleanup work (rename X, delete dead code Y, etc.)
-
-## When NOT to use
-
-- Anything that touches auth, billing, or destructive operations on user data
-- Architectural decisions with multiple valid approaches (use `/plan` first)
-- Tasks where you genuinely need user input on a key decision
-- Anything where being wrong has high consequences (merges to main, security patches)
-
-## Execution pattern
-
-1. Read project context (`.bizar/PROJECT.md`, `FINAL_GOAL.md`, `ROADMAP.md`)
-2. Search memory for prior context (`bizar memory search "<topic>"`)
-3. Decompose into independent work streams
-4. Dispatch streams via the **Agent tool** in parallel, naming them `thor` and `tyr` (or whichever Bizar agents fit the scope)
-5. After streams return: run test gate (`bizar test-gate` or `/test`)
-6. Fix any test failures
-7. Update self-improvement log (`.bizar/AGENTS_SELF_IMPROVEMENT.md`)
-8. Commit + push (delegate to the `hermod` subagent)
-9. Report final outcome

package/.claude/commands/pr-review.md

@@ -1,49 +0,0 @@
----
-description: PR review mode. Launch @mimir (research) and @forseti (audit) in parallel, then post the combined review as a PR comment.
-allowed-tools: Read, Grep, Glob, Bash, WebFetch
----
-
-# /pr-review — PR Review
-
-You are the `hermod` agent running PR review mode. The full
-arguments are available as `$ARGUMENTS` — expect a PR number, URL,
-or branch name.
-
-## Protocol
-
-1. Resolve the PR. If `$ARGUMENTS` is empty, prompt for a PR
-   number. Use `gh pr view <ref>` to fetch the metadata.
-
-2. Dispatch two **parallel** subagents via the **Agent tool**:
-   - **`mimir` (research)** — trace the diff's blast radius:
-     - Files changed and their blast radius
-     - Related call sites / consumers that might break
-     - Historical context (search `bizar memory search "<feature>"`)
-     - Tests that should have run
-   - **`forseti` (audit)** — security and correctness review:
-     - Permission grants added or expanded
-     - Hardcoded secrets or PII
-     - Race conditions, TOCTOU, unbounded loops
-     - Missing input validation at trust boundaries
-
-   Spawn both in a **single message** with two Agent tool calls so
-   they run in parallel. Pass each agent a disjoint scope (the
-   research agent reads, the audit agent reads + flags).
-
-3. Synthesize. Wait for both subagents to finish, then combine:
-   - Verdict (`approve`, `request changes`, `comment`)
-   - Blocking issues (must-fix before merge)
-   - Non-blocking suggestions
-   - Test plan
-
-4. Post the review as a PR comment via `gh pr review <ref>
-   --comment --body-file -` (or `--approve` / `--request-changes`).
-
-5. Return the review summary to the user with the PR URL.
-
-## Constraints
-
-- Never merge on the user's behalf. Only post a review.
-- If the diff is huge (>1000 lines), narrow scope by file and
-  dispatch one subagent per logical chunk.
-- Always cite `file:line` for each finding.

package/.claude/commands/setup-provider.md

@@ -1,96 +0,0 @@
----
-description: Configure a provider in settings.json (apiKey, baseUrl, model catalog). The installer no longer touches provider config — use this command to set one up.
-allowed-tools: Read, Write, Bash, WebFetch
----
-
-# /setup-provider — Configure a provider in settings.json
-
-The Bizar installer no longer configures a provider for you (since
-v6.2.2 — the user owns provider config). Use this command to add
-or update a provider in `~/.claude/settings.json`.
-
-## What It Does
-
-Interactively (or non-interactively with flags), the setup-provider
-command writes a `provider` block to `~/.claude/settings.json` with:
-
-- `baseUrl` — the API endpoint (e.g. `http://localhost:20128/v1` for
-  the local 9Router gateway)
-- `apiKey` — the provider's API key (read from `env:` reference or
-  direct value)
-- `models` — the model catalog (the IDs returned by
-  `GET /v1/models`)
-
-## Default: 9Router Gateway
-
-If the user invokes `/setup-provider` with no arguments, default to
-the local 9Router gateway at `http://localhost:20128/v1`. The
-catalog comes from `GET http://localhost:20128/v1/models`. As of
-v6.2.2, that catalog includes:
-
-- `minimax/MiniMax-M3` (reasoning)
-- `minimax/MiniMax-M2.7` (reasoning)
-- `nvidia/minimaxai/minimax-m3` (reasoning)
-- `nvidia/minimaxai/minimax-m2.7` (reasoning)
-- `nvidia/z-ai/glm-5.2`
-- `nvidia/deepseek-ai/deepseek-v4-pro`
-- `nvidia/deepseek-ai/deepseek-v4-flash`
-- `nvidia/moonshotai/kimi-k2.6`
-- `nvidia/nemotron-3-ultra-550b-a55b`
-- `openrouter/cohere/north-mini-code:free`
-- `openrouter/poolside/laguna-m.1:free`
-- `openrouter/nvidia/nemotron-3-super-120b-a12b:free`
-- (and several more `minimax/MiniMax-M2.x` variants)
-
-## Flags
-
-- `--gateway <url>` — override the 9Router URL (default
-  `http://localhost:20128/v1`)
-- `--key <key>` — provider API key (writes `${env:KEY_NAME}` if it
-  looks like an env var name, otherwise writes the literal)
-- `--provider <name>` — provider name in settings.json (default `9router`)
-- `--model <id>` — add a single model instead of fetching the catalog
-- `--list` — print the model catalog from `/v1/models` and exit
-- `--remove <name>` — remove a provider by name
-
-## Examples
-
-```
-# Use the default 9Router gateway with the live model catalog
-/setup-provider
-
-# Custom provider
-/setup-provider --provider my-anthropic --gateway https://api.anthropic.com/v1 --key sk-ant-...
-
-# Just list the available models
-/setup-provider --list
-```
-
-## Implementation
-
-1. If `--list`, GET `${gateway}/v1/models` and pretty-print the IDs.
-2. If `--remove`, edit `~/.claude/settings.json` and remove the
-   `provider.<name>` block.
-3. Otherwise, read `~/.claude/settings.json`. If the file doesn't
-   exist, error — the user should run `bizar install` first.
-4. Build the new `provider.<name>` block from the flags + fetched
-   catalog.
-5. Write the file back atomically (write to `settings.json.tmp`,
-   then `rename`).
-6. Run `bizar validate` to confirm everything is wired up.
-
-## Security
-
-Never echo or log the full API key. If the user supplies a key on
-the command line, write it as a literal value (or `${env:KEY}`
-reference if it matches a `KEY_NAME` pattern). Never commit
-`~/.claude/settings.json` to source control — it may contain real
-secrets.
-
-## Related
-
-- `bizar connect` — interactive TUI for provider setup (alternative)
-- `bizar install` — installs the Bizar scaffolding (NOT provider config
-  since v6.2.2)
-- `bizar validate` — confirms provider config is wired correctly
-- Claude Code provider config: see https://docs.claude.com/en/docs/claude-code/settings

package/.claude/commands/tailscale-serve.md

@@ -1,100 +0,0 @@
----
-description: Authenticate Tailscale Serve and expose a local port on your tailnet
-allowed-tools: Read, Bash
----
-
-# Tailscale Serve Command
-
-Authenticate and configure Tailscale Serve to expose a local service on your
-tailnet. Auto-detects whether Serve is enabled on the tailnet and either
-provisions HTTPS automatically or surfaces the admin-enable URL clearly.
-
-## Usage
-
-```
-/tailscale-serve                 # expose port 8765 (the BizarHarness dashboard default)
-/tailscale-serve 3000            # expose port 3000
-/tailscale-serve --status        # show current serve config, no changes
-/tailscale-serve --reset         # remove the current serve config
-```
-
-The full arguments are available as `$ARGUMENTS` (and `$1` for the port).
-Parse them and route to the matching step below.
-
-## Steps
-
-1. **Parse the argument**: first arg is the port (default `8765`). If `--status`, run step 3 only. If `--reset`, run step 6 only.
-
-2. **Verify the local port is listening**:
-   ```bash
-   ss -lntp 2>/dev/null | grep -E ":${PORT}\b" || curl -sS -o /dev/null -w "HTTP %{http_code}\n" --max-time 2 http://127.0.0.1:${PORT}/
-   ```
-   If the port is not open, tell the user clearly which command starts the
-   service (e.g. `npm run host:start` for the BizarHarness demo, or
-   `python3 -m http.server 8765` for a quick static server). Do not proceed
-   without an upstream.
-
-3. **Check current Tailscale Serve status**:
-   ```bash
-   tailscale serve status
-   tailscale status --json | jq -r '.Self.DNSName, .Self.TailscaleIPs[0]'
-   ```
-   Capture the MagicDNS name and the Tailscale IP. The DNS name will look
-   like `devbox.tail2cdf4d.ts.net` (trim the trailing dot).
-
-4. **If already configured** (status shows `https://`):
-   - Print the current config
-   - Print the existing endpoints
-   - **Stop** — do not re-configure
-
-5. **Try to enable Serve** (with a hard timeout — it may try to open a browser):
-   ```bash
-   timeout 5 tailscale serve --bg --https=443 "http://127.0.0.1:${PORT}" 2>&1
-   ```
-   - **On success**: print the new config, print the `https://<dnsname>/` endpoint.
-   - **If the output contains "Serve is not enabled"**:
-     - Parse the admin-enable URL from the output (it's the
-       `https://login.tailscale.com/f/serve?node=...` line).
-     - Print it prominently with a clear message:
-       > **Tailscale Serve is not enabled on this tailnet.**
-       > An admin must visit this URL once to enable it:
-       > **<URL>**
-       > Then re-run `/tailscale-serve ${PORT}`.
-     - Do not fall back to plain HTTP automatically — the user asked for
-       authentication, not a workaround. They can run the demo's
-       `host:start` script for the HTTP fallback.
-   - **On any other error**: print the full error, suggest
-     `tailscale serve status` and `sudo tailscale up` as debug steps.
-
-6. **For `--reset`**:
-   ```bash
-   tailscale serve reset
-   ```
-   Confirm the reset succeeded by re-running `tailscale serve status`.
-
-7. **Final output** — always end with a clear status block:
-
-   ```
-   === Tailscale Serve ===
-   config:    <status>
-   upstream:  http://127.0.0.1:<port>
-   endpoints:
-     - https://<dnsname>/         (HTTPS, only if Serve is enabled)
-     - http://<dnsname>:<port>/   (HTTP fallback, only if upstream binds 0.0.0.0)
-
-   To remove: /tailscale-serve --reset
-   ```
-
-## Notes
-
-- `tailscale serve` requires a one-time tailnet admin enable. There is no
-  per-device flag — only the admin can authorize it. The command surfaces
-  the admin URL and stops rather than silently falling back.
-- This command does not start the upstream service. It assumes the service
-  is already running and only wires the HTTPS proxy.
-- For the BizarHarness Demo Dashboard, the typical flow is:
-  ```
-  /tailscale-serve --status       # see current state
-  npm run host:start              # upstream on port 8765
-  /tailscale-serve                # expose it on the tailnet
-  ```

package/.claude/commands/team.md

@@ -1,132 +0,0 @@
----
-description: Spawn a Claude Code agent team — coordinate Thor (M2.7), Tyr (M3), Mimir (research), and Hermod (git) to complete a complex mission end-to-end.
-allowed-tools: Read, Bash, Agent
----
-
-# Team — Spawn a Claude Code Agent Team
-
-The `/team` command spawns a **coordinated agent team** for a complex,
-multi-step mission. The lead agent coordinates teammates; each teammate
-owns a disjoint scope; results are synthesized and committed.
-
-The full mission is available as `$ARGUMENTS` (or composed from `$1`).
-
-## When to Use `/team`
-
-Use `/team` for any non-trivial mission that benefits from **parallel
-work + explicit coordination**. Examples:
-
-- **Refactor** — split a module across Thor (M2.7) and Tyr (M3) in parallel.
-- **Multi-feature build** — new feature A (Thor) + new feature B (Tyr) + tests (Heimdall).
-- **Research + implementation** — Mimir researches, Thor implements, Forseti audits.
-- **Migration / upgrade** — Hermod handles the git/PR lifecycle while Thor/Tyr write code.
-- **Bug hunt** — Mimir traces the data flow while Tyr writes the fix and tests.
-
-Do NOT use `/team` for trivial single-file edits or single-question
-clarifications. Use `@heimdall` directly for those.
-
-## Default Team Composition
-
-If the user does not specify a team composition, spawn this default:
-
-| Role          | Agent   | Model             | Job                                   |
-|---------------|---------|-------------------|---------------------------------------|
-| Lead          | @odin   | minimax/MiniMax-M3   | Coordinate, synthesize, gate quality  |
-| Implementer 1 | @thor   | minimax/MiniMax-M2.7 | Moderate-complexity implementation   |
-| Implementer 2 | @tyr    | minimax/MiniMax-M3   | Complex / cross-cutting work         |
-| Researcher    | @mimir  | 9router/kr/auto  | Codebase research, pattern discovery  |
-| Git ops       | @hermod | minimax/MiniMax-M2.7 | Branch, commit, push, PR             |
-| Reviewer      | @forseti| minimax/MiniMax-M3   | Audit plan + final output            |
-
-You can swap or remove any of these — but always keep at least one
-implementer and a reviewer.
-
-## Protocol (How Odin Runs a `/team` Invocation)
-
-1. **Read `.bizar/PROJECT.md`** if it exists. Factor the project
-   description into the team mission.
-2. **Read `bizar memory status`**. If the vault is reachable, run
-   `bizar memory search "<topic>"` for prior context on the mission.
-3. **Decompose** the mission into disjoint work items. Each item
-   names:
-   - The agent that owns it
-   - The file scope (paths/globs)
-   - The deliverable (a function, a test, a commit, a doc)
-   - The exit signal ("done when X is committed")
-4. **Launch in parallel** — use the **Agent tool** in a **single
-   message** with multiple `Agent` calls so all teammates run
-   concurrently. Each call's prompt names the Bizar agent
-   (`thor`, `tyr`, `mimir`, `hermod`, `forseti`) so the audit
-   trail stays readable. For long-running work, pass
-   `run_in_background: true`.
-5. **Monitor** — while the team runs, return control to the user.
-   The team runs asynchronously. Check teammate progress only
-   when the user asks (use `SendMessage` to the named agent).
-6. **Synthesize** — when teammates report back, gate through @forseti
-   (audit) and @hermod (commit/push). Then report the final outcome
-   to the user with file:line references.
-
-## Pre-Dispatch Checklist (MANDATORY)
-
-- [ ] Each teammate has a **disjoint file scope** — no two agents
-      edit the same file or directory
-- [ ] Lockfiles, `package.json`, root configs, `tsconfig.json`,
-      `vite.config.*`, `Dockerfile`, CI configs are assigned to ONE
-      agent or marked READ-ONLY for everyone else
-- [ ] No subagent has both `bash: allow` AND a write-level git task
-      in the same batch — Hermod is the only git writer
-- [ ] Each teammate's scope is named in plain English
-- [ ] You have prepended the **Sibling-Awareness Block** to every
-      prompt — see Odin baseline, "Parallel Dispatch Coordination"
-- [ ] You have called `bizar memory status` and confirmed the vault
-      is reachable
-
-## Example Mission Strings
-
-**Refactor a module:**
-```
-Refactor src/api/auth.ts into a clean module: extract JWT validation
-into src/auth/jwt.ts, rate-limiting into src/auth/rate-limit.ts, and
-keep the public surface stable. Add tests for each new module. Update
-docs/architecture.md with the new module map. Do not change the HTTP
-route handlers.
-```
-
-**Multi-feature build:**
-```
-Add a kanban board: (1) Thor — backend API at /api/tasks with CRUD
-endpoints and SQLite persistence. (2) Tyr — frontend React component
-in src/components/Kanban.tsx with 5 columns. (3) Heimdall — write
-the OpenAPI spec at docs/api/tasks.yaml. (4) Hermod — open a PR
-named feat/kanban-board.
-```
-
-**Bug hunt:**
-```
-Mimir — trace the data flow from POST /api/checkout through to the
-Stripe webhook handler; find any place where the order status is
-written before the payment is confirmed. Tyr — write a regression
-test that reproduces the race. Thor — fix the bug. Forseti —
-audit the fix for completeness. Hermod — commit + push.
-```
-
-## Tool Reference (Claude Code)
-
-- **Agent tool** — spawn one subagent per call. Use multiple
-  `Agent` calls in a single message for parallelism.
-- `run_in_background: true` on the Agent tool — for tasks that
-  span more than a few minutes.
-- `SendMessage` — talk to a running background agent by name.
-
-## Failure Modes
-
-- **Two agents write the same file** — STOP, revert one branch, reassign.
-- **One agent stalls** — use `TaskStop` to terminate, route the
-  remaining scope to another agent.
-- **Tests fail after team work** — dispatch `thor` to investigate;
-  do not paper over the failure.
-- **Git conflict** — route to `hermod` for `git rebase` / merge
-  resolution.
-- **A teammate goes silent** — send a `SendMessage` to the named
-  agent for a status report; if dead, kill and re-spawn with a
-  fresh prompt.