@polderlabs/bizar 3.22.0 → 3.23.0

package/cli/bin.mjs

@@ -762,7 +762,22 @@ async function loadDashCli() {
     // fall through to file probing
   }
 
-  // Try 2: file path probing
+  // Try 2: dynamic npm root -g (most reliable for global installs)
+  try {
+    const { execFileSync } = await import('node:child_process');
+    const { pathToFileURL } = await import('node:url');
+    const { join } = await import('node:path');
+    const npmRoot = execFileSync('npm', ['root', '-g'], { encoding: 'utf8', timeout: 5000 }).trim();
+    if (npmRoot) {
+      const cliPath = join(npmRoot, '@polderlabs', 'bizar-dash', 'src', 'cli.mjs');
+      const mod = await import(pathToFileURL(cliPath).href);
+      return mod;
+    }
+  } catch (_e) {
+    /* fall through */
+  }
+
+  // Try 3: file path probing
   const { join } = await import('node:path');
   const { homedir } = await import('node:os');
   const candidates = [

package/config/agents/_shared/AGENT_BASELINE.md

@@ -651,3 +651,48 @@ Every Bizar project has a vault at `.obsidian/` with index files (`index/`), age
 - Anything already obvious from reading the code
 
 **The O in Odin stands for "oblige the system": Odin ALWAYS updates the vault after significant work, regardless of who did the work. The other agents read; Odin writes.**
+
+## 13. New Sessions Must Bootstrap Context from Obsidian + Graphify
+
+**Every new agent session starts blind. Before answering the user or doing any work, gather context from the project's two project-knowledge stores.**
+
+Both stores are git-tracked (`.obsidian/`, `.bizar/graph/`) and require no setup. The first minute of context-gathering saves an hour of wrong-direction work.
+
+**At the start of EVERY new session, do this in order:**
+
+1. **Skim the Obsidian vault index** at `.obsidian/index/`:
+   - `Home.md` (or whatever the entry doc is) — the project's high-level description, architecture, current state
+   - `Versions.md` — installed component versions
+   - `Architecture.md` — system structure
+   - `Dashboard.md` — dashboard conventions
+   - `Patterns.md`, `Tools.md`, `Workflows.md` — only if relevant to the current task
+   - Any `daily/` entries from the past week — what was being worked on
+
+2. **Check the Graphify graph** at `.bizar/graph/` (if the graphify mod is installed):
+   - `bizar graph query "<concept>"` — for cross-module code questions
+   - `bizar graph path <A> <B>` — for dependency tracing
+   - `bizar graph explain <file>` — for understanding an unfamiliar file
+
+3. **Read agent-specific memory** at `.obsidian/agents/<your-name>/`:
+   - Past sessions, gotchas, decisions
+   - Anything the user previously corrected you on
+
+4. **Skim recent context** at `.obsidian/daily/`:
+   - Last 3-7 days of running log entries
+   - What was in flight when the last session ended
+
+**When to re-bootstrap mid-session:**
+
+- After long pauses (>1 hour idle, the user's mental model may have shifted)
+- When the user references something you don't recognize ("the thing we did last week", "the migration")
+- Before any non-trivial decision
+- When the conversation pivots to a different subsystem
+
+**Anti-patterns:**
+
+- Don't ask the user "what is this project about?" — read the vault
+- Don't re-read the source tree top-to-bottom to get context — query the graph
+- Don't repeat work that was done in a previous session — the daily log has the outcome
+- Don't make assumptions about the user's preferences — check the vault and agent memory
+
+**The bootstrap is mandatory, not optional. A session that starts without checking Obsidian + Graphify is a session that's likely to suggest things the user already tried, break things that were already fixed, or contradict decisions that were already made.**

package/config/skills/lightrag/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: lightrag-instructions
+description: Always-on rules installed by the LightRAG mod. When the LightRAG server is running, prefer the knowledge graph for cross-document questions before re-reading source files.
+---
+
+# LightRAG — Installed Instructions
+
+These rules apply whenever the **lightrag** mod is enabled and the LightRAG server is running (default port 9621).
+
+## What is LightRAG?
+
+LightRAG is a graph-based Retrieval-Augmented Generation system. It builds a knowledge graph from ingested documents and answers questions by traversing entities and relationships, not just keyword-matching chunks.
+
+The Bizar dashboard exposes a LightRAG view at `/lightrag` that lets you:
+- Insert documents (text, file paths, URLs)
+- Query the knowledge graph (5 modes: local, global, hybrid, naive, mix)
+- Inspect entities and relationships
+- See query history
+
+The HTTP server runs at `http://127.0.0.1:9621` by default. The Bizar dashboard talks to it via the REST API.
+
+## When to Use LightRAG (vs grep / Semble)
+
+**Use LightRAG for:**
+- "What does this codebase say about X?" (semantic, not literal)
+- "What entities relate to Y?" (graph traversal)
+- "Summarize all documentation about Z"
+- "Find all decisions made about authentication"
+- Any cross-document question where grep would give 30+ results
+
+**Use grep / Semble for:**
+- Single-line, single-file lookups
+- "Does the string `TODO` exist?"
+- "Where is function X defined?"
+
+**Use Semble for:**
+- Code-aware semantic search
+- "What calls function X?" (with file:line)
+- "Find the line that handles auth"
+
+LightRAG is for **natural-language questions about content**, not code structure.
+
+## Rules by Agent
+
+### @mimir (research)
+- Before deep-diving into a research question with 20+ tool calls, query the LightRAG knowledge graph first: `POST /query` with the question text. The graph often points you at the right document in 1-2 calls.
+- If LightRAG returns no results, fall back to Semble and grep. Don't force-fit results.
+- After running any new document through LightRAG, the graph updates — query again to see the new context.
+
+### @frigg (Q&A)
+- When the user asks a project-specific question that grep can't answer (e.g. "what did we decide about X?"), check LightRAG first via `POST /query` with the question as the query text.
+- LightRAG returns retrieved context with the answer. Use that as the basis for the response.
+
+### @odin (router)
+- After completing a piece of work that produced documentation (decisions, postmortems, ADRs), consider whether the content should be ingested into LightRAG. If yes, call the dashboard's `/api/mods/lightrag/insert` with the file path.
+
+## API quick reference
+
+```
+POST /query              — body: { query: string, mode: "mix" | "local" | "global" | "hybrid" | "naive" }
+POST /insert/text        — body: { text: string, id?: string }
+POST /insert/file        — body: { path: string }   (file is read and ingested)
+GET  /entities            — list entities
+GET  /relations           — list relationships
+GET  /status              — server health + counts
+```
+
+All endpoints are at `http://127.0.0.1:9621` (or via the dashboard at `/api/mods/lightrag/proxy/*`).
+
+## Common pitfalls
+
+- **Embedding model must be set before indexing.** If you change it, re-embed all text chunks, entities, and relationships. (LightRAG does not provide a re-embedding tool.)
+- **Vector dimension depends on the embedding model.** Some storage backends (e.g. PostgreSQL) require the vector dimension to be defined when creating tables. If you change the embedding model, you may need to drop and recreate the vector tables.
+- **The server binds to 127.0.0.1 by default.** The dashboard proxies requests to it. If you want to access LightRAG from outside the host, set `host: 0.0.0.0` in the mod config.
+- **First query is slow** (~3s) because the graph cache is cold. Subsequent queries are faster.
+
+## See also
+
+- LightRAG docs: https://github.com/HKUDS/LightRAG
+- Bizar mod guide: `.obsidian/reference/mods.md`
+- Dashboard mod config: `Settings → Mods → LightRAG`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polderlabs/bizar",
-  "version": "3.22.0",
+  "version": "3.23.0",
   "description": "Norse-pantheon multi-agent system for opencode — 13 agents across 4 cost tiers with cost-aware routing, plans, and a configurable agent harness.",
   "type": "module",
   "bin": {