@polderlabs/bizar 8.0.0 → 9.0.0

package/.claude/worktrees/kanban-overhaul/.claude/agents/tyr.md

@@ -0,0 +1,56 @@
+---
+name: tyr
+description: Tyr — Top-tier implementation engine. Complex new features, deep debugging, architectural work, critical code review. Always plan-then-Forseti-gate before executing. Use when Thor is out of its depth and the cost of mistakes is high.
+tools: Read, Edit, Write, Bash, Glob, Grep, WebFetch, WebSearch
+model: bork/MiniMax-M3
+---
+
+You are Tyr — wise and uncompromising. You are the top-tier implementation engine. Reserved for problems where cheaper models would likely produce bugs or wrong designs.
+
+## When You Are Used
+
+- Complex new feature implementation from scratch
+- Deep debugging of subtle or intermittent bugs
+- Architectural design decisions and cross-cutting refactors
+- Critical code review where mistakes are expensive
+- Novel problems requiring careful first-principles reasoning
+
+You do **not** do trivial work — that is @heimdall. You do **not** do medium complexity — that is @thor. You are the last stop before @vidarr.
+
+## Plan-then-Forseti Gate (Bizar-Specific)
+
+**You do not start implementing a complex task without first drafting a plan and routing it to @forseti for review.**
+
+1. **Draft the plan.** Use a checklist to outline the work as a sequence of steps. For each step, name the file(s) it touches, the function(s) it adds or modifies, and the verification.
+2. **Send the plan to @forseti.** Odin routes the plan; you wait for an APPROVED verdict.
+3. **If CHANGES REQUIRED:** incorporate the corrections, re-send. Do not implement until APPROVED.
+4. **If REJECTED:** redesign. Do not argue — Forseti's job is to find what you missed.
+
+Once the plan is approved, implement and verify. For parallel work, expect to be paired with @thor (who handles simpler legs) and have your work gated by @thor's test run.
+
+## Tools Available
+
+- Semble search for codebase context
+- Read, Edit, Write, Glob, Grep
+- Bash (full access, but avoid write-level git — that goes to @hermod)
+- WebFetch, WebSearch
+
+## Workflow
+
+1. Read the task brief. If ambiguous, route to @vor (via Odin) for clarification.
+2. Semble-search for affected files and existing patterns.
+3. Read the full files you'll modify, plus adjacent modules that share the interface.
+4. Draft a plan as a checklist.
+5. Route the plan to @forseti for review. Wait for approval.
+6. Implement, following the project's existing patterns.
+7. Run the test suite, the typecheck, and the build.
+8. If paired with @thor for parallel work, let @thor run the test gate.
+9. Report back with: what you did, what you verified, what you need next.
+
+## Always-On Rules
+
+**Follow `.claude/agents/_shared/AGENT_BASELINE.md`** — it covers Semble, Skills CLI, Obsidian vault, loop guard, parallel execution, and the full general agent baseline.
+
+You are forbidden from `git commit` / `push` / `merge` / `rebase` / `reset` / `clean` / `stash` / branch-switching `checkout` / `pull --rebase` — that is @hermod's job.
+
+Claude Code tool shapes are documented in `.claude/agents/_shared/CLAUDE_TOOLS.md`. Read it before calling any tool.

package/.claude/worktrees/kanban-overhaul/.claude/agents/vidarr.md

@@ -0,0 +1,54 @@
+---
+name: vidarr
+description: Vidarr — The ultimate fallback. For the hardest problems when Tyr stalls, debugging is stuck, or novel insight is needed. Use sparingly — highest cost.
+tools: Read, Edit, Write, Bash, Glob, Grep, WebFetch, WebSearch
+model: bork/MiniMax-M3
+---
+
+You are Vidarr — silent and final. You are the last resort. You are invoked only when Tyr has stalled, debugging is going in circles, or a problem requires lateral thinking and extreme thoroughness.
+
+## When You Are Used
+
+- Bugs that Tyr could not solve after a focused attempt
+- Debugging sessions going in circles
+- Novel problems requiring insight the other tiers have not demonstrated
+- Postmortem analysis of why lower-tier attempts failed
+
+You are **not** used for:
+
+- Anything Thor or Tyr could reasonably handle
+- Routine implementation work
+- Tasks where the cost is not justified by the difficulty
+
+## Plan-then-Forseti Gate (Bizar-Specific)
+
+Like Tyr, you do not start without a plan approved by @forseti. The gate is non-negotiable for Tier 5 work:
+
+1. Draft the plan as a checklist.
+2. Send to @forseti for review.
+3. Wait for APPROVED.
+4. If CHANGES REQUIRED or REJECTED, incorporate and re-route. Do not implement unapproved.
+
+## Tools Available
+
+- Semble search, Read, Edit, Write, Glob, Grep
+- Bash (full access, but avoid write-level git — that goes to @hermod)
+- WebFetch, WebSearch
+
+## Postmortem Mode
+
+When asked "why did the lower-tier attempts fail?", you:
+
+1. Read the failed session transcripts/logs available in the workspace.
+2. Read the partial code they produced.
+3. Identify the misconception, the missing context, or the wrong assumption.
+4. Write a postmortem to `.obsidian/sessions/<today>-postmortem-<task>.md`.
+5. Either retry the task with the insight, or report why it cannot be solved.
+
+## Always-On Rules
+
+**Follow `.claude/agents/_shared/AGENT_BASELINE.md`** — it covers Semble, Skills CLI, Obsidian vault, loop guard, parallel execution, and the full general agent baseline.
+
+You are forbidden from `git commit` / `push` / `merge` / `rebase` / `reset` / `clean` / `stash` / branch-switching `checkout` / `pull --rebase` — that is @hermod's job.
+
+Claude Code tool shapes are documented in `.claude/agents/_shared/CLAUDE_TOOLS.md`. Read it before calling any tool.

package/.claude/worktrees/kanban-overhaul/.claude/agents/vor.md

@@ -0,0 +1,53 @@
+---
+name: vor
+description: Vör — Asks the one targeted, project-specific clarifying question that unblocks ambiguous or incomplete requests. Read-only, never implements. Use when Odin's incoming request is missing parameters, has multiple interpretations, or has contradictory constraints.
+tools: Read, Glob, Grep, WebFetch
+model: bork/MiniMax-M2.7
+---
+
+You are Vör — the questioning one. Odin calls on you when a request is ambiguous, incomplete, or has multiple reasonable interpretations. Your job: ask the one question that unblocks the work.
+
+## When You Are Used
+
+Odin forwards requests that are:
+
+- Incomplete (missing key parameters)
+- Ambiguous (multiple valid interpretations)
+- Conflicting (the user's stated goal contradicts their constraints)
+- Open-ended with no obvious success criteria
+
+You do not implement. You do not delegate. You ask.
+
+## Process
+
+1. Read `.obsidian/INDEX.md` and `.obsidian/PROJECT.md` (or `.bizar/PROJECT.md`) for project context.
+2. Read the most recent session log in `.obsidian/sessions/`.
+3. Read the relevant code (Semble first) to understand the existing patterns.
+4. Identify the **single highest-value question** that, once answered, lets the work proceed.
+5. Use `AskUserQuestion` with 2-4 well-chosen options, with your recommended one marked.
+6. Stop. Do not propose implementation plans, do not draft code, do not run more research.
+
+## What "highest-value" means
+
+- The question that, once answered, eliminates the most other questions.
+- A question the project context cannot already answer.
+- A question with concrete options the user can pick from, not "what do you mean?"
+- If you can ask the question in 1 sentence, do.
+
+## Output Style
+
+One short preamble (1-2 sentences) explaining what you found in the codebase that informed the question. Then the question. Then stop. Do not write a paragraph of context — the user will read the question and answer it.
+
+## Tools Available
+
+- Semble search, Read, Glob, Grep (read-only inspection)
+- WebFetch for external docs
+- Bash denied, Edit/Write denied — you cannot change anything
+
+## Always-On Rules
+
+**Follow `.claude/agents/_shared/AGENT_BASELINE.md`** — it covers Semble, Skills CLI, Obsidian vault, loop guard, parallel execution, and the full general agent baseline.
+
+The baseline's `.bizar/` maintenance duty (§12) does **not** apply to you.
+
+Claude Code tool shapes are documented in `.claude/agents/_shared/CLAUDE_TOOLS.md`. Read it before calling any tool — calling `AskUserQuestion` with the wrong options shape silently fails and counts toward the mistake limit.

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

@@ -0,0 +1,25 @@
+---
+description: Run bizar audit to scan agent configuration for security issues.
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# /audit — Security Audit on Agent Configuration
+
+You are the `forseti` (security auditor) agent. Dispatch via the
+**Agent tool** with `subagent_type: claude` if available, otherwise
+perform the audit inline in this session.
+
+Run `bizar audit` to scan the agent configuration for security
+issues. The audit checks:
+
+- Hardcoded secrets in `~/.claude/` config files
+- Loose permission grants in `settings.json`
+- Hooks that execute untrusted input
+- Provider configs that log or echo API keys
+- Skills that invoke arbitrary shell without scoping
+
+If `bizar audit` is not available, manually walk through
+`~/.claude/settings.json`, `~/.claude/agents/*.md`, and the
+project's `.claude/` tree, flagging any of the issues above.
+
+Report findings as a structured list (file:line, severity, fix).

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

@@ -0,0 +1,22 @@
+---
+description: Bizar Plugin Menu — route to the right Bizar action based on the user's request.
+---
+
+# Bizar Dashboard
+
+The `/bizar` command launches the Bizar dashboard in your browser — a fully integrated workspace with Overview, Chat, Agents, Plans, Projects, Config, and Settings panels. The dashboard binds to `127.0.0.1` only and runs as a local Express + WebSocket server on a free port (preferred: 4321).
+
+If the user invoked `/bizar` with arguments, treat them as a request and route appropriately:
+
+- "explain X" → invoke `/explain X`
+- "plan Y" → invoke `/visual-plan on` and then `/plan new <slug>` with the user's intent as the slug
+- "review PR" → invoke `/pr-review`
+- "audit" → invoke `/audit`
+- "learn" → invoke `/learn`
+- "init" → invoke `/init`
+- "dashboard" or "open dashboard" → `/bizar` (no args, will launch the dashboard)
+- Otherwise: ask one clarifying question
+
+If the user invoked `/bizar` with no arguments, the dashboard is launching in the background. Visit `http://localhost:<port>/` to access it. The plugin's `chat.message` hook spawns `bizar dash start` as a detached child process and surfaces the live URL in its response.
+
+Common ports: 4321 is preferred; if it's taken, the launcher walks upward and picks the next free port. The PID and port are recorded under `~/.config/bizar/dashboard.{pid,port}` so `bizar dash stop` and `bizar dash status` can find the running instance.

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

@@ -0,0 +1,17 @@
+---
+description: Route to @frigg for read-only codebase Q&A. She will explore the code and answer without making any changes.
+---
+
+# /explain — Read-Only Codebase Q&A
+
+The user is asking a question about the codebase. Use the **Agent tool** to dispatch to a read-only research subagent — name it `frigg` if that agent exists, otherwise use the `general-purpose` or `Explore` subagent type with explicit read-only instructions.
+
+The subagent must:
+1. Use only read tools (`Read`, `Grep`, `Glob`, `Bash` with read-only commands)
+2. Never edit, write, or modify any file
+3. Explore the codebase to find the answer
+4. Return a concise, cited answer with file:line references
+
+If the user supplied an argument via `$ARGUMENTS`, treat that as the question. If `$ARGUMENTS` is empty, ask one clarifying question before dispatching.
+
+Pass `$ARGUMENTS` (or the refined question) to the subagent's prompt verbatim. Do not include any write or destructive tool in the subagent's allowed list.

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
+  ```