@polderlabs/bizar 3.20.17 → 3.22.0

package/config/opencode.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://opencode.ai/config.json",
-  "model": "openrouter/minimax/minimax-m3",
-  "small_model": "openrouter/minimax/minimax-m2.7",
+  "model": "minimax/MiniMax-M3",
+  "small_model": "minimax/MiniMax-M2.7",
   "default_agent": "odin",
   "permission": "allow",
   "snapshot": false,
@@ -53,7 +53,7 @@
     "odin": {
       "description": "Odin — Pure router that delegates all work to subagents. Routes across Frigg (DeepSeek/Q&A), Vör (DeepSeek/clarify), Mimir (DeepSeek/research), Heimdall (DeepSeek/simple), Hermod (M2.7/git), Thor (M2.7/mid), Baldr (M2.7/design), Tyr (M3/top), Vidarr (GPT-5.5/ultra), Forseti (verifier/M3).",
       "mode": "primary",
-      "model": "openrouter/minimax/minimax-m3",
+      "model": "minimax/MiniMax-M3",
       "color": "#6366f1",
       "permission": {
         "task": "allow",
@@ -102,7 +102,7 @@
     "quick": {
       "description": "Quick — Fast single-shot tasks. No delegation, no parallel streams. Use for small edits, mechanical changes, one-shot questions. Routes to no one.",
       "mode": "primary",
-      "model": "openrouter/minimax/minimax-m2.7",
+      "model": "minimax/MiniMax-M2.7",
       "color": "#22d3ee",
       "permission": {
         "read": "allow",
@@ -162,7 +162,7 @@
     "hermod": {
       "description": "Hermod — Git and GitHub operations specialist using MiniMax M2.7. Branching, commits, PRs, merge/rebase, conflict resolution, CI/CD, releases, gh CLI.",
       "mode": "subagent",
-      "model": "openrouter/minimax/minimax-m2.7",
+      "model": "minimax/MiniMax-M2.7",
       "color": "#06b6d4",
       "permission": {
         "read": "allow",
@@ -180,7 +180,7 @@
     "thor": {
       "description": "Thor — Handles medium-complexity tasks using MiniMax M2.7 from minimax.io. Strong and reliable, cheaper than Tyr but more capable than Heimdall.",
       "mode": "subagent",
-      "model": "openrouter/minimax/minimax-m2.7",
+      "model": "minimax/MiniMax-M2.7",
       "color": "#a855f7",
       "permission": {
         "read": "allow",
@@ -199,7 +199,7 @@
     "baldr": {
       "description": "Baldr — UI/UX design system specialist. Creates DESIGN.md files using Google's design.md standard. Focuses on visual consistency, usability, accessibility, and design tokens.",
       "mode": "subagent",
-      "model": "openrouter/minimax/minimax-m2.7",
+      "model": "minimax/MiniMax-M2.7",
       "color": "#ec4899",
       "permission": {
         "read": "allow",
@@ -218,7 +218,7 @@
     "tyr": {
       "description": "Tyr — Handles the most complex implementation, debugging, and architectural work using MiniMax M3 via minimax.io. Unmatched wisdom for the hardest problems.",
       "mode": "subagent",
-      "model": "openrouter/minimax/minimax-m3",
+      "model": "minimax/MiniMax-M3",
       "color": "#f59e0b",
       "permission": {
         "read": "allow",
@@ -235,9 +235,9 @@
       }
     },
     "vidarr": {
-      "description": "Vidarr — The ultimate fallback using GPT-5.5 via OpenAI ChatGPT subscription. For the hardest problems when debugging stalls or nothing else works. Use sparingly — highest cost.",
+      "description": "Vidarr — The ultimate fallback using MiniMax M3 via MiniMax direct provider. For the hardest problems when debugging stalls or nothing else works. Use sparingly — highest cost.",
       "mode": "subagent",
-      "model": "openai/gpt-5.5",
+      "model": "minimax/MiniMax-M3",
       "color": "#dc2626",
       "permission": {
         "read": "allow",
@@ -256,7 +256,7 @@
     "forseti": {
       "description": "Forseti — Audits, criticizes, and corrects implementation plans before execution using MiniMax M3. No write permissions — review only.",
       "mode": "subagent",
-      "model": "openrouter/minimax/minimax-m3",
+      "model": "minimax/MiniMax-M3",
       "color": "#ef4444",
       "permission": {
         "read": "allow",
@@ -347,18 +347,6 @@
           "reasoning": true
         }
       }
-    },
-    "openrouter": {
-      "models": {
-        "minimax/minimax-m3": {
-          "interleaved": { "field": "reasoning_details" },
-          "reasoning": true
-        },
-        "minimax/minimax-m2.7": {
-          "interleaved": { "field": "reasoning_details" },
-          "reasoning": true
-        }
-      }
     }
   }
 }

package/config/skills/bizar/SKILL.md

@@ -67,6 +67,48 @@ Free (Mimir, Heimdall) → $Mid (Thor, Hermod) → $$High (Tyr) → $$$Ultra (Vi
 
 Never use a paid agent for work a free agent can do. Never use Tyr for what Thor can handle.
 
+## When to use Glyphs (visual plans)
+
+Glyphs are the dashboard's `/artifacts/<slug>/artifact.mdx` — MDX with rich blocks (RichText, Callout, Checklist, Table, CodeTabs, Decision, OpenQuestions, FileTree, Diff, Stat, Workflow, Mockup, Diagram) plus free-placed comments that the user can pin anywhere on the artifact.
+
+**Use Glyphs for BIG decisions, NOT small questions:**
+- A new feature with multiple UI states, design choices, or trade-offs
+- A UI redesign that affects multiple components
+- An architectural change spanning 3+ files
+- Any change where the user should review before code is written
+- Any work where the user wants to annotate specific spots on a mockup/diagram with feedback
+
+**Don't use Glyphs for:**
+- "What does this function do?" — use `@frigg` or the `read` tool
+- A simple bug fix with one obvious cause — just fix it
+- Single-file changes with no design questions
+- Anything that can be answered in one sentence
+
+When the user says "show me a plan", "let's review the design", "I want to see the UI options", or "what should this look like" — that's a Glyph trigger. When they say "fix this bug", "what does X do", "rename this" — that's a direct edit, not a Glyph.
+
+## How to create a Glyph
+
+1. Write `artifacts/<slug>/artifact.mdx` with frontmatter (`title`, `status`, `kind: plan|recap`) and blocks
+2. Write `artifacts/<slug>/meta.json` with `{ title, slug, status, author, created, lastEdited }`
+3. Write `artifacts/<slug>/comments.json` as `[]` initially (comments added via the dashboard)
+4. Use the full block vocabulary — see `glyphs-research.md` in Obsidian or the dashboard's `/api/artifacts/<slug>/render` for the JSON shape
+
+Templates available:
+- `templates/plan/plan.mdx.template` — forward planning (before code)
+- `templates/plan/plan.canvas.template` — legacy canvas (don't use; replaced by MDX)
+
+## How to read glyph feedback
+
+When the user clicks "Submit to agent" on a glyph in the dashboard, the dashboard writes a structured `artifacts/<slug>/feedback.md` file and marks `meta.json` `status: review`. That file contains:
+
+- All free-placed comments with `(x, y)` coordinates and text
+- Answers to OpenQuestions (one `Q:` / `A:` block per question)
+- The original MDX source
+
+Read it with the `read_glyph_feedback` tool (preferred — returns parsed frontmatter + body + counts), or read the file directly with the `read` tool.
+
+After reading the feedback, regenerate the glyph's `artifact.mdx` to address every comment and apply every answer. Then write the regenerated MDX back to `artifacts/<slug>/artifact.mdx` (and update `meta.json` if the title/summary changes).
+
 ## Troubleshooting
 
 ### Odin Self-Handles Instead of Routing

package/config/skills/glyph/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: glyph
+description: Create and consume Bizar glyphs — visual plan/recap artifacts in `artifacts/<slug>/`. Glyphs are MDX files with frontmatter and a block vocabulary. Use for design proposals, decision recaps, and postmortems.
+version: 1
+---
+
+# Glyphs — Visual Plan Artifacts
+
+A **glyph** is a visual artifact used for plans, recaps, and design proposals. It's an MDX file in `artifacts/<slug>/artifact.mdx` that the dashboard renders with comment pin overlay and right-click context menu.
+
+## When to create a glyph
+
+- **Design proposal** — you're proposing a new component, system, or workflow
+- **Decision recap** — multiple options were considered; one was chosen; the reasoning matters
+- **Postmortem** — something broke; here's the timeline and root cause
+- **Implementation plan** — breaking down a non-trivial feature into phases
+- **Handoff** — work moving from one agent to another
+
+If it's a one-line fix, don't make a glyph. If it's a 5-minute edit, don't make a glyph. Glyphs are for work that needs visible structure.
+
+## File structure
+
+```
+artifacts/<slug>/
+├── meta.json          # title, slug, status, author, created
+├── artifact.mdx       # ← source of truth (git-tracked, diff-friendly)
+└── comments.json      # ← free-placed pins (mutable)
+```
+
+The `meta.json` is metadata, `artifact.mdx` is the content, `comments.json` is the only mutable side-channel.
+
+## Frontmatter
+
+```yaml
+---
+title: "Short, action-oriented title"
+brief: "One sentence: what this glyph is about."
+status: draft | review | shipped | archived
+kind: plan | postmortem | recap | design
+---
+```
+
+## Block vocabulary
+
+```mdx
+<RichText id="...">markdown content (headings, lists, code blocks, etc.)</RichText>
+
+<Callout id="..." tone="info|warn|success|danger">markdown content</Callout>
+
+<Stat id="..." label="..." value="..." trend="up|down|flat" hint="..." />
+
+<Checklist
+  id="..."
+  items={[
+    { id: "i1", label: "...", checked: true },
+    { id: "i2", label: "...", checked: false }
+  ]}
+/>
+
+<Table
+  id="..."
+  columns={["A", "B"]}
+  rows={[["x", "y"], ["p", "q"]]}
+/>
+
+<CodeTabs
+  id="..."
+  tabs={[
+    { id: "t1", label: "file.ts", language: "typescript", code: "...", caption: "..." }
+  ]}
+/>
+
+<Decision
+  id="..."
+  title="..."
+  question="..."
+  options={[
+    { id: "a", label: "...", detail: "...", recommended: true }
+  ]}
+/>
+
+<OpenQuestions
+  id="..."
+  questions={[
+    { id: "q1", label: "...", kind: "choice|text|multi", options: ["A", "B"] }
+  ]}
+/>
+
+<FileTree
+  id="..."
+  title="..."
+  entries={[
+    { path: "src/foo.ts", change: "added|modified|removed|renamed", note: "..." }
+  ]}
+/>
+
+<Workflow
+  id="..."
+  steps={[
+    { id: "s1", label: "...", type: "task|decision|note" }
+  ]}
+  connections={[
+    { from: "s1", to: "s2", label: "yes" }
+  ]}
+/>
+
+<Mockup
+  id="..."
+  title="..."
+  x={40} y={120} w={280} h={180}
+  html="<div class='mockup-card'>...</div>"
+/>
+
+<Diagram
+  id="..."
+  title="..."
+  dataHtml="<svg>...</svg>"
+  dataCss=".diagram-node { fill: var(--bg-1); }"
+/>
+```
+
+## Common pitfalls
+
+### FileTree `change` field
+
+`change` must be exactly one of: `added`, `modified`, `removed`, `renamed`. Use the `note` field for nuance ("rewritten from scratch", "kept as-is", "deprecated").
+
+```mdx
+<FileTree
+  entries={[
+    { path: "src/chat/Composer.tsx", change: "modified", note: "rewritten as pill composer" }
+  ]}
+/>
+```
+
+### MDX heading with `<N`
+
+A heading like `## Mobile (under 768px)` is fine. But `## Mobile <768px` breaks the MDX validator because `<7` looks like a malformed JSX tag. Always escape or rephrase.
+
+### Block IDs must be unique within a glyph
+
+If you copy a `<RichText>` block, change its `id`. The compiler may warn but won't fail.
+
+### Children vs self-closing
+
+Blocks with content (RichText, Callout) use open/close tags with children. Blocks with only data (Stat, Table, FileTree, Decision, etc.) are self-closing.
+
+## meta.json example
+
+```json
+{
+  "title": "Chat UI — Complete Rewrite (Gemini-Inspired)",
+  "slug": "chat-ui-rewrite",
+  "status": "draft",
+  "author": "drb0rk",
+  "created": "2026-06-26T20:30:00.000Z",
+  "lastEdited": "2026-06-26T20:30:00.000Z"
+}
+```
+
+## How to view in the dashboard
+
+Glyphs are rendered at `/artifacts/<slug>`. The dashboard shows them with:
+- Section grouping (by block id prefix: `overview`, `implementation`, `questions`)
+- Comment pin overlay (right-click to add)
+- Floating toolbar (Send to agent, share)
+- Read-only by default; `status: shipped` locks editing
+
+## See also
+
+- `bizar-dash/src/web/views/glyphs/components.tsx` — block component implementations
+- `bizar-dash/src/server/glyphs/mdx-compiler.mjs` — MDX parser
+- `artifacts/sample-plan-login/` — a complete worked example
+- The user's Obsidian vault for the project's design notes

package/config/skills/obsidian/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: obsidian
+description: Use the project's Obsidian vault (`.obsidian/`) for persistent project knowledge. Read it before decisions, write to it after work. Every Bizar agent follows this rule.
+version: 1
+---
+
+# Obsidian Vault — Project Knowledge
+
+**Project knowledge lives in `.obsidian/`. Read it before you start, write to it when you learn.**
+
+Every Bizar project has an Obsidian vault at `.obsidian/` with index files (`index/`), agent-specific memory (`agents/`), bug postmortems (`bugs/`), design decisions, and ongoing work notes. The user has been working on this project — their notes contain the real context, the gotchas, the failed approaches, the preferred patterns. **Read the relevant vault entries before making any non-trivial decision.**
+
+## When to read
+
+- At the start of every session (skim the index)
+- Before any non-trivial implementation decision
+- When you're about to suggest something the user has already tried
+- When the codebase feels like it's working around something you don't understand
+- When you encounter a `// FIXME` or `// HACK` comment — there's probably a vault entry explaining it
+
+## When to write
+
+- After completing a meaningful piece of work
+- On discovering a bug or postmortem
+- When you find a pattern that should be reused
+- When the user corrects you
+- When you make a design decision that should be remembered
+
+## What to write
+
+Date-stamped entry under the appropriate category:
+
+- `index/` — high-level project context, decisions, handoffs
+- `bugs/` — bug postmortems, root-cause analyses
+- `agents/<name>/` — per-agent memory (what you learned, what to do differently)
+- `reference/` — external API docs, tool notes
+- `workflows/` — multi-step procedures
+- `daily/` — running log of what happened today
+
+Each entry:
+
+```markdown
+---
+title: "What happened"
+date: 2026-06-26
+tags: [tag1, tag2]
+---
+
+# Title
+
+## Context
+What was happening. What was the user trying to do.
+
+## Lesson
+What you learned. Why it matters.
+
+## Pattern
+What to do next time. Code examples welcome.
+
+## Files changed
+- path/to/file.ts (added, modified, removed)
+```
+
+Link to related entries with `[[wikilinks]]`.
+
+## What NOT to write
+
+- Secrets, API keys, tokens (use `auth.json`)
+- Temporary scratch (use a TODO comment in code)
+- Anything already obvious from reading the code
+- Long code dumps (link to file with `path:line`)
+
+## How to use the vault
+
+### Via Obsidian CLI (preferred)
+
+```bash
+obsidian search "<query>"          # full-text search
+obsidian read "<path>"             # read a file
+obsidian create "<path>" "<content>"  # create a file
+obsidian append "<path>" "<content>"  # append to a file
+obsidian daily "<content>"          # append to today's daily note
+obsidian tasks                     # list open tasks
+obsidian backlinks "<path>"         # find what links to this file
+```
+
+### Via MCP server (if available)
+
+The `obsidian` MCP server exposes tools like `obsidian_search`, `obsidian_read_file`, `obsidian_create_file`, `obsidian_append_content`, `obsidian_list_directory`, `obsidian_dataview_query`. Use whichever interface is available.
+
+## The O in Odin
+
+Odin always updates the vault after significant work, regardless of who did the work. The other agents read; Odin writes. This is a hard rule — if Odin completes a task without leaving a vault trace, that task isn't really done.
+
+## See also
+
+- [[AGENTS_SELF_IMPROVEMENT]] — project-specific lessons in `.bizar/AGENTS_SELF_IMPROVEMENT.md`
+- [[Architecture]] — system structure (in `index/`)
+- [[Dashboard]] — dashboard conventions
+- [[Patterns]] — code patterns
+- [[Tools]] — tool documentation

package/config/skills/read-the-damn-docs/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: read-the-damn-docs
+description: When using a library, tool, or API you don't fully understand, READ THE DOCS before guessing. Don't infer behavior from function names. The source of truth is the official documentation and source code, not your prior assumptions.
+version: 1
+---
+
+# Read the Damn Docs
+
+When you reach for a library, tool, or API you haven't used recently (or ever), **read the actual documentation** before writing code. Don't guess. Don't infer from function names. Don't assume "it probably works like X". The source of truth is the docs, then the source code, then examples. Everything else is noise.
+
+## Why this skill exists
+
+LLMs are confidently wrong. They have a strong prior for "this is what libraries usually look like" — and that prior is sometimes right but often subtly wrong. Common failure modes:
+
+- "The function is called `parseFoo` so it probably takes a string and returns an object" — wrong, it takes `{format, version}` and returns a promise
+- "I'll just try it and see what error comes back" — wastes a turn, often hallucinates the fix
+- "The README has an example, that's enough" — examples are cherry-picked; edge cases will bite you
+
+The fix: spend 30-90 seconds reading the docs first. The cost is a single tool call. The benefit is a correct first attempt.
+
+## Hierarchy of truth
+
+When resolving how a library/tool/API works, use this priority order:
+
+1. **Official documentation** (the canonical reference) — most authoritative
+2. **Source code** (the actual implementation) — definitive when docs are vague
+3. **Examples** (in the docs or repo) — show typical use, but don't trust edge cases
+4. **StackOverflow / GitHub issues** — useful for known footguns
+5. **Your prior model** — last resort, often wrong
+
+**Stop at step 1 unless the docs are unclear.** If they are, drop to step 2.
+
+## Practical workflow
+
+```
+1. IDENTIFY: "I'm about to use library X for the first time (or first time in months)"
+2. READ: webfetch the official docs for the specific function/method I'll call
+   - Don't read the entire docs — read the specific section
+3. VERIFY: cross-check against source if anything is ambiguous
+4. NOTE: write down the gotchas in your agent memory or a relevant file
+5. USE: now write the code, knowing the actual API
+```
+
+## When to invoke this skill
+
+Use it whenever:
+
+- You're using a library you haven't touched in this session
+- You're using a function/method whose exact signature you don't remember
+- The function name is misleading or you have low confidence
+- You're upgrading to a new major version of a library
+- You're switching between similar libraries (axios vs fetch, etc.)
+- You're using a CLI tool you don't have muscle memory for
+- You're hitting an error you don't recognize and "guessing" the fix
+
+## Anti-patterns
+
+### "I'll just try it"
+
+Don't write code, run it, see the error, and fix from there. That works for trivial cases but burns turns on anything non-trivial. Read the docs first.
+
+### "The function name tells me what it does"
+
+`Array.prototype.flatMap`, `Promise.allSettled`, `fs.opendirSync` — names are hints, not specs. The actual behavior (sync vs async, return shape, error cases) is in the docs.
+
+### "I used this library before, I know it"
+
+Libraries change. APIs deprecate. Defaults shift. Even if you used something 6 months ago, a quick doc check (30 seconds) saves 10 minutes of debugging when your prior knowledge is stale.
+
+### "The README example is enough"
+
+README examples are demos, not documentation. They show one happy path. The real API has edge cases, error modes, and options that aren't in the example.
+
+### "The error message is enough to fix it"
+
+Sometimes. But error messages are often misleading or incomplete. Reading the docs for the function that errored often reveals the actual constraint.
+
+## Examples
+
+### Good: Read first
+
+```
+[Agent wants to use the Vite `defineConfig` API for the first time]
+Agent: "Let me check the Vite docs for the exact shape of `defineConfig`."
+[webfetch https://vitejs.dev/config/]
+Agent: "OK, `defineConfig` accepts a UserConfig object with `plugins`, `build`, etc.
+       I need a `define` key for compile-time constants."
+[Writes correct config]
+```
+
+### Bad: Guess
+
+```
+[Agent wants to use the Vite `defineConfig` API for the first time]
+Agent: "defineConfig is probably a function that takes a config object with
+       common options like plugins and build. Let me just write it."
+[Writes config with `define: { __VERSION__: '1.0' }`]
+[Runs vite build, gets a warning about an unexpected option]
+Agent: "Hmm, the docs must have changed. Let me guess it's a different syntax."
+[Wastes 2-3 turns guessing before reading the docs]
+```
+
+## Where to read
+
+- **Webfetch** the official docs URL: `webfetch <url>` — fast, gives you the actual current docs
+- **Source code** via Semble search: `semble search "functionName" <repo>` — useful when docs are vague
+- **Local docs** if available: `semble search "<query>" --content docs` for the project's own docs
+
+## See also
+
+- [[obsidian]] — write postmortems and patterns to the project vault
+- [[glyph]] — create a glyph when the design decision is non-trivial
+- The agent baseline — `simplest thing that works` rule