@polderlabs/bizar 8.1.0 → 9.0.0

package/.claude/worktrees/kanban-overhaul/.claude/commands/init.md

@@ -0,0 +1,29 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/learn.md

@@ -0,0 +1,44 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/plan.md

@@ -0,0 +1,35 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/plow-through.md

@@ -0,0 +1,50 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/pr-review.md

@@ -0,0 +1,49 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/setup-provider.md

@@ -0,0 +1,96 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/tailscale-serve.md

@@ -0,0 +1,100 @@
+---
+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/worktrees/kanban-overhaul/.claude/commands/team.md

@@ -0,0 +1,132 @@
+---
+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.

package/.claude/worktrees/kanban-overhaul/.claude/commands/test.md

@@ -0,0 +1,62 @@
+---
+description: Run the project's test suite via the Bizar test gate. Auto-detects jest/vitest/bun/pytest/cargo/go. Exits non-zero on failure.
+allowed-tools: Read, Bash
+---
+
+# /test — Run the Project's Test Suite
+
+The `/test` command is a thin wrapper around `bizar test-gate`. It
+auto-detects the project's test runner and runs the full suite.
+
+## What It Does
+
+1. Detects the project stack (one of: npm, pytest, cargo, go).
+2. Runs the matching test command:
+   - `package.json` present → `npm test`
+   - `pyproject.toml` present → `pytest`
+   - `Cargo.toml` present → `cargo test`
+   - `go.mod` present → `go test ./...`
+3. Streams the test output to the user.
+4. Exits non-zero on test failures.
+
+## Exit Codes
+
+| Code | Meaning                          |
+|------|----------------------------------|
+| 0    | All tests passed                 |
+| 1    | Tests failed                     |
+| 2    | No test runner detected          |
+
+## How to Use
+
+Invoke `/test` from the project root. The test gate inspects the
+current directory and picks the right runner.
+
+To run a specific Bizar test scope instead, pass arguments to
+`/test`. The arguments are forwarded to the underlying runner and
+are available as `$ARGUMENTS` (or `$1`, `$2`, ...):
+
+- `/test plugins/bizar` — run only the Bizar plugin tests (bun)
+- `/test --testPathPattern=auth` — pass a flag to the runner
+
+## When to Use
+
+- After any non-trivial code change
+- Before committing (`@hermod` should always run `/test` first)
+- As the final step of a `/team` mission — gate quality with tests
+
+## Common Patterns
+
+- **Post-implementation gate** — after Thor and Tyr finish their
+  parallel work, dispatch `thor` to run `/test`. If failures, fix
+  and re-run.
+- **PR check** — run `/test` in CI before merging.
+- **Debug a flaky test** — run `/test` twice; if the second run
+  passes, the test is order-dependent (fix or quarantine).
+
+## Related
+
+- `bizar test-gate` — the underlying CLI command
+- `bizar doctor` — checks the Bizar install itself (not project tests)
+- `make check` — typecheck + tests (full pipeline, dev only)
+- `make e2e` — Bizar plugin end-to-end (dev only)

package/.claude/worktrees/kanban-overhaul/.claude/commands/validate.md

@@ -0,0 +1,68 @@
+---
+description: Validate the Bizar install end-to-end — settings.json parses, plugin entry resolves, all agent files are installed, all skills/rules/hooks/commands are in place, provider config is sane, and the 9router gateway is reachable.
+allowed-tools: Read, Bash
+---
+
+# /validate — Validate the Bizar Install
+
+The `/validate` command runs `bizar doctor` with the full check
+battery. It is the fastest way to confirm the install is healthy
+and Claude Code will see every Bizar component on the next session
+start.
+
+## What It Checks
+
+1. **claude-reachable** — `claude --version` exits 0.
+2. **claude-config-valid** — `~/.claude/settings.json` parses as JSON.
+3. **plugin-entry-present** — `settings.json` has a Bizar plugin entry.
+4. **plugin-path-resolves** — the plugin path on disk actually exists.
+5. **agent-files-installed** — all agent files in `~/.claude/agents/`
+   (odin, vor, frigg, quick, mimir, heimdall, hermod, thor, baldr,
+   tyr, vidarr, forseti, semble-search, agent-browser).
+6. **tools-available** — at least one of `headroom`, `semble`, `skills`
+   is on PATH.
+7. **provider-config-sanity** — `provider.9router` (preferred) or
+   `provider.minimax` (legacy) has at least one sane model entry.
+8. **9router-reachable** — 9Router gateway responds at
+   `http://localhost:20128/api/health` (lenient — warn, don't fail).
+9. **slash-commands-installed** — all Bizar slash commands
+   (`/audit`, `/explain`, `/init`, `/learn`, `/plan`, `/plow-through`,
+   `/pr-review`, `/tailscale-serve`, `/visual-plan`, `/bizar`,
+   `/team`, `/test`, `/validate`) are present in `~/.claude/commands/`.
+10. **skills-installed** — every subdir of `config/skills/` is
+    mirrored to `~/.claude/skills/`.
+11. **rules-installed** — every `.md` in `config/rules/` is mirrored
+    to `~/.claude/rules/`.
+12. **hooks-installed** — `config/hooks/` is mirrored to
+    `~/.claude/hooks/`.
+
+## How to Use
+
+Invoke `/validate` (no arguments) from anywhere. It is read-only and
+never modifies the system.
+
+If any check fails, the user should run `bizar update` to refresh the
+install, or `bizar repair` to fix common issues.
+
+## Output
+
+Each check prints ✓ or ✗ with a one-line message. The summary line
+shows the total pass/fail count. Exits non-zero if any check fails.
+
+For machine-readable output, the user can run `bizar doctor --json`
+directly.
+
+## When to Use
+
+- After a manual config edit — confirm nothing broke.
+- Before a `/team` mission — confirm the install is healthy so the
+  team has all the tools it needs.
+- After `bizar install` or `bizar update` — the install already
+  calls doctor, but a manual re-run is cheap.
+- When a user asks "why is Claude Code misbehaving?" — start here.
+
+## Related
+
+- `bizar doctor` — the underlying CLI command
+- `bizar update` — refreshes the install (re-runs syncConfigExtras)
+- `bizar repair` — fixes common issues (stale symlinks, version drift)