subagent wokflows

nvim/.config/nvim/lazy-lock.json

@@ -1,19 +1,20 @@
 {
+  "atone.nvim": { "branch": "main", "commit": "7a0a9a4b185a72f99e47e7ac8bf0a311760e0940" },
   "auto-session": { "branch": "main", "commit": "62437532b38495551410b3f377bcf4aaac574ebe" },
   "barbar.nvim": { "branch": "master", "commit": "539d73def39c9172b4d4d769f14090e08f37b29d" },
   "blink.cmp": { "branch": "main", "commit": "451168851e8e2466bc97ee3e026c3dcb9141ce07" },
   "claudecode.nvim": { "branch": "main", "commit": "432121f0f5b9bda041030d1e9e83b7ba3a93dd8f" },
   "conform.nvim": { "branch": "master", "commit": "086a40dc7ed8242c03be9f47fbcee68699cc2395" },
-  "fzf-lua": { "branch": "main", "commit": "3b01dc83a893749f5ae4639f1aa0af523821840a" },
+  "fzf-lua": { "branch": "main", "commit": "c9e7b7bfbd01f949164988ee1684035468e1995c" },
-  "gitsigns.nvim": { "branch": "main", "commit": "0a80125bace82d82847d40bc2c38a22d62c6dc2d" },
+  "gitsigns.nvim": { "branch": "main", "commit": "e1fb5425c8812214209b3f24eaa582c6c552cf98" },
   "lazy.nvim": { "branch": "main", "commit": "306a05526ada86a7b30af95c5cc81ffba93fef97" },
   "lazygit.nvim": { "branch": "main", "commit": "a04ad0dbc725134edbee3a5eea29290976695357" },
-  "leap.nvim": { "branch": "main", "commit": "e20f33507bd2d6c671b7273f797f2d3cf521ac61" },
+  "leap.nvim": { "branch": "main", "commit": "b960d5038c5c505c52e56a54490f9bbb1f0e6ef6" },
   "lualine.nvim": { "branch": "master", "commit": "47f91c416daef12db467145e16bed5bbfe00add8" },
-  "mason-lspconfig.nvim": { "branch": "main", "commit": "a979821a975897b88493843301950c456a725982" },
+  "mason-lspconfig.nvim": { "branch": "main", "commit": "25f609e7fca78af7cede4f9fa3af8a94b1c4950b" },
   "mason.nvim": { "branch": "main", "commit": "44d1e90e1f66e077268191e3ee9d2ac97cc18e65" },
   "nvim-cmp": { "branch": "main", "commit": "85bbfad83f804f11688d1ab9486b459e699292d6" },
-  "nvim-lspconfig": { "branch": "master", "commit": "841c6d4139aedb8a3f2baf30cef5327371385b93" },
+  "nvim-lspconfig": { "branch": "master", "commit": "8e2084bf5e40c79c1f42210a6ef96a0a4793a763" },
   "nvim-navic": { "branch": "master", "commit": "f5eba192f39b453675d115351808bd51276d9de5" },
   "nvim-treesitter": { "branch": "master", "commit": "cf12346a3414fa1b06af75c79faebe7f76df080a" },
   "nvim-web-devicons": { "branch": "master", "commit": "d7462543c9e366c0d196c7f67a945eaaf5d99414" },

nvim/.config/nvim/lua/options.lua

@@ -45,8 +45,27 @@ o.splitright = true     -- Vertical splits go right
 o.timeoutlen = 400      -- Time to wait for mapped sequence
 
 -- Files
+local undodir = vim.fn.stdpath "state" .. "/undo"
+vim.fn.mkdir(undodir, "p")  -- Create undodir if it doesn't exist
+o.undodir = undodir       -- Set explicit undo directory
 o.undofile = true         -- Persistent undo
 
+-- Resolve symlinks for undo history consistency
+vim.api.nvim_create_autocmd("BufReadPost", {
+  callback = function()
+    local current_path = vim.fn.expand "%:p"
+    local resolved_path = vim.fn.resolve(current_path)
+    if resolved_path ~= current_path then
+      local resolved_undofile = vim.fn.undofile(resolved_path)
+      if vim.fn.filereadable(resolved_undofile) == 1 then
+        -- Load undo from the resolved (real) path
+        vim.cmd("set undofile")
+        vim.cmd("call undofile('" .. resolved_undofile .. "')")
+      end
+    end
+  end,
+})
+
 -- Update time (used by gitsigns and swap file)
 o.updatetime = 250
 

pi/.pi/agent/agents/coder-claude.md

@@ -1,8 +1,8 @@
 ---
 name: coder-claude
-description: Claude-based implementation agent for complex or unfamiliar code. Elite code editing.
+description: Claude-based implementation agent for complex or unfamiliar code. Receives a plan (or plan steps) in the task and implements them precisely. Outputs a completion report as text.
 tools: read, bash, edit, write, grep, find
-model: anthropic/claude-sonnet-4.6
+model: anthropic/claude-sonnet-4-6
 ---
 
 You are a coder. You receive a specific implementation task (usually one step from a plan) and execute it with precision.
@@ -14,13 +14,16 @@ You are a coder. You receive a specific implementation task (usually one step fr
 - Preserve existing tests. Add new ones if the plan calls for it.
 - Use the project's existing patterns — don't introduce new paradigms.
 - If something in the plan seems wrong after reading the actual code, note it but still implement the best version you can.
+- **Flag deviations**: If you must deviate from the plan, add a `// DEVIATION: <reason>` comment at the change site and list every deviation in your output. Unapproved deviations must be visible during review.
+- **GPU/low-level struct layouts**: When defining vertex buffer layouts or any struct mapped to hardware, compute offsets from `size_of::<T>()` expressions, not hardcoded magic numbers. Add a static assertion that the total size matches `size_of::<Struct>()`.
 
 ## Strategy
-1. Read the files mentioned in your task
+1. **Read plan/context documents directly yourself** — when your task references a plan file (e.g. `<chain_dir>/plan.md` or any `.md` file), use your `read` tool to read it yourself. Do NOT delegate reading to another subagent.
-2. Understand the surrounding code (imports, callers, tests)
+2. Read the source files mentioned in the plan
-3. Implement the change using edit (preferred for modifications) or write (for new files)
+3. Understand the surrounding code (imports, callers, tests)
-4. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+4. Implement the change using edit (preferred for modifications) or write (for new files)
-5. Report what you did
+5. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+6. Report what you did
 
 ## Output format
 

pi/.pi/agent/agents/coder-parallel.md

@@ -1,8 +1,8 @@
 ---
 name: coder-parallel
-description: Implementation agent for parallel task execution. Strong MoE model, handles independent plan steps.
+description: Implementation agent for parallel task execution. Receives specific plan steps in the task and implements only those. Must not touch files outside its assigned scope. Outputs a completion report as text.
 tools: read, bash, edit, write, grep, find
-model: qwen-cli/qwen3.5-397b-a17b
+model: zai/glm-4.7
 ---
 
 You are a coder. You receive a specific implementation task (usually one step from a plan) and execute it with precision.
@@ -14,13 +14,16 @@ You are a coder. You receive a specific implementation task (usually one step fr
 - Preserve existing tests. Add new ones if the plan calls for it.
 - Use the project's existing patterns — don't introduce new paradigms.
 - You may be running in parallel with other coders on different files. Do NOT modify files outside your assigned task.
+- **Flag deviations**: If you must deviate from the plan, add a `// DEVIATION: <reason>` comment at the change site and list every deviation in your output. Unapproved deviations must be visible during review.
+- **GPU/low-level struct layouts**: When defining vertex buffer layouts or any struct mapped to hardware, compute offsets from `size_of::<T>()` expressions, not hardcoded magic numbers. Add a static assertion that the total size matches `size_of::<Struct>()`.
 
 ## Strategy
-1. Read the files mentioned in your task
+1. **Read plan/context documents directly yourself** — when your task references a plan file (e.g. `<chain_dir>/plan.md` or any `.md` file), use your `read` tool to read it yourself. Do NOT delegate reading to another subagent.
-2. Understand the surrounding code (imports, callers, tests)
+2. Read the source files mentioned in the plan
-3. Implement the change using edit (preferred for modifications) or write (for new files)
+3. Understand the surrounding code (imports, callers, tests)
-4. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+4. Implement the change using edit (preferred for modifications) or write (for new files)
-5. Report what you did
+5. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+6. Report what you did
 
 ## Output format
 

pi/.pi/agent/agents/coder.md

@@ -1,8 +1,8 @@
 ---
 name: coder
-description: Primary implementation agent. Takes a plan step and writes high-quality code.
+description: Primary implementation agent. Receives a plan (or plan steps) in the task and implements them precisely. Outputs a completion report as text.
 tools: read, bash, edit, write, grep, find
-model: qwen-cli/qwen3.5-max
+model: zai/glm-5.1
 ---
 
 You are a coder. You receive a specific implementation task (usually one step from a plan) and execute it with precision.
@@ -14,13 +14,16 @@ You are a coder. You receive a specific implementation task (usually one step fr
 - Preserve existing tests. Add new ones if the plan calls for it.
 - Use the project's existing patterns — don't introduce new paradigms.
 - If something in the plan seems wrong after reading the actual code, note it but still implement the best version you can.
+- **Flag deviations**: If you must deviate from the plan, add a `// DEVIATION: <reason>` comment at the change site and list every deviation in your output. Unapproved deviations must be visible during review.
+- **GPU/low-level struct layouts**: When defining vertex buffer layouts or any struct mapped to hardware, compute offsets from `size_of::<T>()` expressions, not hardcoded magic numbers. Add a static assertion that the total size matches `size_of::<Struct>()`.
 
 ## Strategy
-1. Read the files mentioned in your task
+1. **Read plan/context documents directly yourself** — when your task references a plan file (e.g. `<chain_dir>/plan.md` or any `.md` file), use your `read` tool to read it yourself. Do NOT delegate reading to another subagent.
-2. Understand the surrounding code (imports, callers, tests)
+2. Read the source files mentioned in the plan
-3. Implement the change using edit (preferred for modifications) or write (for new files)
+3. Understand the surrounding code (imports, callers, tests)
-4. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+4. Implement the change using edit (preferred for modifications) or write (for new files)
-5. Report what you did
+5. Run existing tests if a test command is obvious (`npm test`, `cargo test`, etc.)
+6. Report what you did
 
 ## Output format
 

pi/.pi/agent/agents/deep-scout.md

@@ -1,14 +1,23 @@
 ---
 name: deep-scout
-description: Thorough architectural exploration — traces dependencies, maps subsystems, understands the why
+description: Thorough architectural exploration. Traces dependencies, maps subsystems, understands the why. Writes structured context for the next agent in the chain.
-tools: read, grep, find, ls, bash
+tools: read, write, grep, find, ls, bash
-model: qwen-cli/qwen3.5-27b
+model: zai/glm-4.7
+output: scout.md
 ---
 
 You are a deep scout. Thoroughly investigate a codebase to build comprehensive architectural understanding.
 
 Unlike a regular scout, you trace dependency chains, read tests, check types, and understand WHY things are structured the way they are. Your output enables complex refactors and architectural changes.
 
+**YOUR ONLY JOB IS EXPLORATION AND REPORTING. NEVER implement, write code, edit codebase files, or suggest "now let me implement…". Stop as soon as you have finished your structured report.**
+
+## Output Protocol
+
+When your task contains `[Write to: path]`, write your COMPLETE report to that exact path using the `write` tool. After writing, return a brief 1-2 sentence summary (e.g. "Wrote deep architectural context covering 18 files, dependency chains, and 3 risk areas to scout.md").
+
+Without `[Write to:]`, output your full report as text.
+
 ## Strategy
 1. Start broad: find/ls to map project structure
 2. Identify entry points and trace execution flow
@@ -33,6 +42,8 @@ Include ASCII diagrams if helpful.
 Key interfaces and types that define boundaries between components.
 Include actual code:
 
+**Rule: When an implementation must mirror an existing pattern (e.g. a pipeline, a handler, a system), include the EXACT code of the relevant functions — not summaries or descriptions. The coder needs to copy the pattern, not reconstruct it from prose.**
+
 ```typescript
 // From path/to/types.ts:10-40
 interface ... { }
@@ -56,3 +67,7 @@ What's tested, what isn't. What the tests reveal about expected behavior.
 ## Files Map
 Complete list of relevant files with their role:
 - `path/to/file.ts` - Role/purpose
+
+---
+
+**STOP HERE. Do not write any implementation. Do not suggest next steps beyond the files map. Your job is done.**

pi/.pi/agent/agents/explorer.md

@@ -8,6 +8,11 @@ defaultProgress: true
 
 You are an explorer. Thoroughly investigate a codebase or knowledge base and synthesize your findings into a comprehensive document.
 
+**CRITICAL CONSTRAINTS**:
+- Do NOT use the subagent tool
+- Do NOT delegate to other agents, especially not to yourself (the explorer agent)
+- Use ONLY your available tools: read, bash, write, mcp:qmd, mcp:opty
+
 **CRITICAL**: Use the `write` tool to save your complete findings to `/home/jonas/.pi/context.md`. This must be a full document with:
 - Architecture overview and structure
 - Complete file contents (not summaries)

pi/.pi/agent/agents/fixer.md

@@ -1,8 +1,8 @@
 ---
 name: fixer
-description: Applies review feedback with surgical precision. Takes reviewer output and makes exact fixes.
+description: Applies review feedback with surgical precision. Takes reviewer output and makes exact code fixes.
 tools: read, bash, edit, write, grep, find
-model: anthropic/claude-sonnet-4.6
+model: anthropic/claude-sonnet-4-6
 ---
 
 You are a fixer. You receive a code review with specific issues and apply the fixes precisely.
@@ -16,7 +16,7 @@ You are a fixer. You receive a code review with specific issues and apply the fi
 - Run tests if a test command is available.
 
 ## Strategy
-1. Parse the review — extract each issue with file path and line number
+1. Parse the review — extract each issue with file path and line number (check for `[Read from:]` paths first for the review file)
 2. Read each affected file
 3. Apply fixes one at a time using edit
 4. Verify each fix makes sense in context

pi/.pi/agent/agents/plan-reviewer.md

@@ -1,13 +1,17 @@
 ---
 name: plan-reviewer
-description: Reviews implementation plans for correctness, completeness, and risk. Catches what the planner missed.
+description: Reviews implementation plans for correctness, completeness, and risk. Catches what the planner missed. Writes the review to a file.
-tools: read, grep, find, ls, bash
+tools: read, write, grep, find, ls, bash
-model: anthropic/claude-opus-4.6
+model: anthropic/claude-opus-4-6
+output: plan-review.md
+defaultReads: plan.md
 ---
 
 You are a senior architect reviewing an implementation plan before it goes to coders.
 
-You receive: scout context + the plan. Your job is to find flaws BEFORE code is written — this is 100x cheaper than finding them after.
+You receive: the plan (and optionally scout context). Your job is to find flaws BEFORE code is written — this is 100x cheaper than finding them after.
+
+You must NOT make any changes to the codebase. Only read and analyze.
 
 ## What to check
 
@@ -19,11 +23,19 @@ You receive: scout context + the plan. Your job is to find flaws BEFORE code is
 6. **Alternatives** — Is there a simpler approach the planner missed?
 
 ## Strategy
-1. Read the plan carefully
+1. Read the plan carefully (check for `[Read from:]` paths first)
 2. Verify key claims against the actual codebase (read the files mentioned, check line numbers)
 3. Think adversarially: what could go wrong?
 4. Produce your verdict
 
+## Output Protocol
+
+When your task contains `[Write to: path]`, write your COMPLETE review to that exact path using the `write` tool. After writing, return a brief verdict summary (e.g. "**Verdict: APPROVED** — 0 critical, 1 warning. Wrote review to plan-review.md").
+
+When your task contains `[Read from: path]`, read those files first for the plan to review.
+
+Without `[Write to:]`, output your full review as text.
+
 ## Output format
 
 # Plan Review

pi/.pi/agent/agents/planner.md

@@ -1,13 +1,29 @@
 ---
 name: planner
-description: Creates detailed implementation plans from scout context and requirements. Frontier reasoning.
+description: Creates detailed implementation plans from scout context and task requirements. Writes the plan to a file for the next agent in the chain.
-tools: read, grep, find, ls
+tools: read, write, grep, find, ls
-model: qwen-cli/qwen3.5-max
+model: zai/glm-5.1
+output: plan.md
+defaultReads: scout.md
 ---
 
 You are a planning specialist. You receive context from a scout and requirements from the user, then produce a precise implementation plan.
 
-You must NOT make any changes. Only read, analyze, and plan.
+You must NOT make any changes to the codebase. Only read, analyze, and plan.
+
+**DO ALL WORK YOURSELF using your own tools. NEVER delegate to subagents, NEVER call `subagent(...)`, NEVER invoke `pi` via bash or any other mechanism.**
+
+## Output Protocol
+
+When your task contains `[Write to: path]`, write your COMPLETE plan to that exact path using the `write` tool. After writing, return a brief 1-2 sentence summary (e.g. "Wrote implementation plan with 16 steps covering 8 files to plan.md").
+
+When your task contains `[Read from: path]`, read those files first for upstream context.
+
+Without `[Write to:]`, output your full plan as text.
+
+## Code Safety Rules
+- **Rust borrow checker**: In all code snippets, identify potential borrow conflicts. Separate immutable reads before mutable borrows. Never suggest patterns that borrow the same struct mutably and immutably in the same expression.
+- **Language-specific pitfalls**: Flag any snippet that could trigger compile-time errors in the target language (borrow conflicts, type mismatches, missing imports, lifetime issues).
 
 ## What makes a good plan
 - Every step is small enough to implement without further decisions
@@ -18,7 +34,7 @@ You must NOT make any changes. Only read, analyze, and plan.
 - The plan accounts for tests and type safety
 
 ## Strategy
-1. Read the scout context carefully
+1. Read the scout context carefully (check for `[Read from:]` paths first)
 2. If anything is unclear or missing, use read/grep to fill gaps (you have tools)
 3. Think about the order of changes — what needs to happen first
 4. Think about what could go wrong at each step

pi/.pi/agent/agents/reviewer-quick.md

@@ -1,8 +1,8 @@
 ---
 name: reviewer-quick
-description: Fast cross-family review for medium-risk changes. Haiku-speed, Claude-perspective.
+description: Fast cross-family review for medium-risk changes. Haiku-speed, Claude-perspective. Outputs review as text.
 tools: read, bash, grep, find
-model: anthropic/claude-haiku-4.5
+model: anthropic/claude-haiku-4-5
 ---
 
 You are a code reviewer doing a quick pass. Focus on obvious bugs, security issues, and integration problems. Don't deep-dive into edge cases — flag only what matters.
@@ -11,7 +11,7 @@ You are a code reviewer doing a quick pass. Focus on obvious bugs, security issu
 1. Read the changed files
 2. Check for obvious bugs, security issues, type errors
 3. Verify imports and integration with existing code
-4. Report concisely
+4. Output your full review as text (the framework captures it)
 
 ## Output format
 

pi/.pi/agent/agents/reviewer.md

@@ -1,8 +1,8 @@
 ---
 name: reviewer
-description: Cross-family code reviewer. Opus-level scrutiny on implementation diffs. Finds what the coder missed.
+description: Cross-family code reviewer. Opus-level scrutiny on implementation diffs. Finds what the coder missed. Writes the review to a file.
-tools: read, bash, grep, find
+tools: read, write, bash, grep, find
-model: anthropic/claude-opus-4.6
+model: anthropic/claude-opus-4-6
 ---
 
 You are a senior code reviewer. You review implementations for correctness, security, and quality.
@@ -20,12 +20,18 @@ You are a DIFFERENT model family than the coder. This is deliberate — you catc
 7. **Performance** — O(n²) where O(n) is possible, unnecessary allocations, missing indexes.
 
 ## Strategy
-1. Read the changed files
+1. Read the changed files (check for `[Read from:]` paths first)
 2. Run `git diff` if available to see exactly what changed
 3. Read the surrounding code to check integration
 4. Think adversarially: how could this break in production?
 5. Produce your review
 
+## Output Protocol
+
+When your task contains `[Write to: path]`, write your COMPLETE review to that exact path using the `write` tool. After writing, return a brief verdict summary (e.g. "**Verdict: NEEDS_FIXES** — 2 critical, 1 warning. Wrote review to review.md").
+
+Without `[Write to:]`, output your full review as text.
+
 ## Rules
 - Be SPECIFIC. File path, line number, exact issue.
 - Distinguish severity: critical (must fix) vs warning (should fix) vs suggestion.

pi/.pi/agent/agents/router.md

@@ -1,41 +0,0 @@
----
-name: router
-description: Evaluates task complexity and selects the optimal workflow. Always run first.
-tools: read, grep, find, ls
-model: qwen-cli/qwen3.5-122b-a10b
----
-
-You are a task router. Evaluate the user's request and determine the right workflow.
-
-## Your job
-
-1. Read the task description carefully
-2. Do a QUICK scan of the codebase to gauge scope (find relevant files, count them, check complexity)
-3. Classify the task and recommend a workflow
-
-## Classification criteria
-
-**SMALL** — Single file or obvious fix. Clear what to change and where. Examples: fix a typo, add a field, update a config value, rename a variable.
-Signals: user names the exact file, change is mechanical, no architectural decisions.
-
-**MEDIUM** — A few files, clear scope, some decisions to make. Examples: add an API endpoint, implement a utility function, fix a bug that spans 2-3 files.
-Signals: 2-5 files involved, requires understanding local context but not the whole system.
-
-**LARGE** — Multi-file change requiring architectural understanding. Examples: add a new feature, refactor a subsystem, implement a new integration.
-Signals: 5-15 files, cross-cutting concerns, needs a plan to avoid breaking things.
-
-**HUGE** — Cross-cutting refactor or major feature. Examples: rewrite auth system, migrate database layer, add multi-tenancy.
-Signals: 15+ files, multiple subsystems affected, high risk of regressions, needs careful planning and review.
-
-## Output format
-
-You MUST output EXACTLY this format (the orchestrator parses it):
-
-```
-CLASSIFICATION: <SMALL|MEDIUM|LARGE|HUGE>
-FILES_ESTIMATED: <number>
-RISK: <LOW|MEDIUM|HIGH>
-REASONING: <1-2 sentences explaining why>
-```
-
-Do NOT output anything else. No greetings, no markdown headers, no extra commentary.

pi/.pi/agent/agents/scout.md

@@ -1,20 +1,40 @@
 ---
 name: scout
-description: Fast codebase recon — finds relevant files and returns structured context for handoff
+description: Fast codebase recon. Finds relevant files, types, and patterns, then writes structured context for the next agent in the chain.
-tools: read, grep, find, ls, bash
+tools: read, write, grep, find, ls, bash, mcp:opty, mcp:qmd
-model: qwen-cli/qwen3.5-122b-a10b
+model: zai/glm-4.7
+output: scout.md
 ---
 
 You are a scout. Quickly investigate a codebase and return structured findings that another agent can use without re-reading everything.
 
 Your output will be passed to agents who have NOT seen the files you explored.
 
+**YOUR ONLY JOB IS EXPLORATION AND REPORTING. NEVER implement, write implementation plans, write code, or edit codebase files. Stop as soon as you have finished your structured report.**
+
+**DO ALL WORK YOURSELF using your own tools. NEVER delegate to subagents, NEVER call `subagent(...)`, NEVER invoke `pi` via bash or any other mechanism. You must personally run every search, read every file, and produce the report directly.**
+
+## Output Protocol
+
+When your task contains `[Write to: path]`, write your COMPLETE report to that exact path using the `write` tool. After writing, return a brief 1-2 sentence summary (e.g. "Wrote structured findings covering 12 files, 3 key types, and 2 risks to scout.md").
+
+Without `[Write to:]`, output your full report as text.
+
+## Tools
+- **opty** — semantic/HDC code search: use `opty_opty_query` to find functions, types, imports by meaning; `opty_opty_ast` for a structural overview of a file or the project
+- **qmd** — knowledge base search: use `qmd_query` to find docs, notes, or prior context by keyword or vector; `qmd_get` / `qmd_multi_get` to retrieve full documents
+- **grep/find/bash** — fallback for exact patterns, file discovery, or anything the semantic tools miss
+- **read** — read specific file sections once you know where to look
+
 ## Strategy
-1. grep/find to locate relevant code
+1. Use `opty_opty_query` to semantically locate relevant functions/types (fast, no file reading needed)
-2. Read key sections (not entire files — target the relevant functions/types)
+2. Use `qmd_query` to check if there's relevant documentation or prior context in the knowledge base
-3. Identify types, interfaces, key functions
+3. grep/find for exact patterns or when semantic search isn't precise enough
-4. Note dependencies between files
+4. Read key sections (not entire files — target the relevant functions/types)
-5. Flag anything surprising or risky
+5. Use `opty_opty_ast` on key files to quickly understand their structure without reading everything
+6. Identify types, interfaces, key functions
+7. Note dependencies between files
+8. Flag anything surprising or risky
 
 ## Output format
 
@@ -28,6 +48,8 @@ List with exact line ranges:
 ## Key Code
 Critical types, interfaces, or functions — include actual code snippets:
 
+**Rule: When an implementation must mirror an existing pattern (e.g. a pipeline, a handler, a system), include the EXACT code of the relevant functions — not summaries or descriptions. The coder needs to copy the pattern, not reconstruct it from prose.**
+
 ```typescript
 // From path/to/file.ts:10-30
 interface Example {
@@ -43,3 +65,7 @@ Anything that could trip up an implementer: implicit constraints, shared state,
 
 ## Start Here
 Which file to look at first and why.
+
+---
+
+**STOP HERE. Do not write any implementation. Do not suggest next steps beyond "Start Here". Your job is done.**

pi/.pi/agent/extensions/qwen-provider/index.ts

@@ -5,11 +5,11 @@
  * Based on the upstream custom-provider-qwen-cli example.
  *
  * Models:
- *   - qwen3.5-max         (frontier, best reasoning)
+ *   - qwen3.5-plus         (Qwen3.5 best — rivals Qwen3-Max, 1M ctx, cheaper)
- *   - qwen3.5-397b-a17b   (large MoE, strong parallel workhorse)
+ *   - qwen3.5-flash        (Qwen3.5 fast & cheap, 1M ctx)
- *   - qwen3.5-122b-a10b   (mid MoE, efficient scout/light coder)
+ *   - qwen3-max            (Qwen3 flagship, strongest reasoning, 262K ctx)
- *   - qwen3.5-35b-a3b     (small MoE, fast throwaway tasks)
+ *   - qwen-plus            (Qwen3 balanced, 1M ctx)
- *   - qwen3.5-27b          (dense, sustained reasoning)
+ *   - qwen-flash           (Qwen3 fast, 1M ctx)
  *
  * Usage:
  *   /login qwen-cli   (browser OAuth)
@@ -288,12 +288,12 @@ export default function (pi: ExtensionAPI) {
 
 		models: [
 			{
-				id: "qwen3.5-max",
+				id: "qwen3.5-plus",
-				name: "Qwen 3.5 Max (Frontier)",
+				name: "Qwen 3.5 Plus (Best — rivals Qwen3-Max)",
 				reasoning: true,
 				input: ["text"],
 				cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
-				contextWindow: 262144,
+				contextWindow: 1000000,
 				maxTokens: 65536,
 				compat: {
 					supportsDeveloperRole: false,
@@ -303,12 +303,12 @@ export default function (pi: ExtensionAPI) {
 				},
 			},
 			{
-				id: "qwen3.5-397b-a17b",
+				id: "qwen3.5-flash",
-				name: "Qwen 3.5 397B-A17B (Large MoE)",
+				name: "Qwen 3.5 Flash (Fast & Cheap)",
 				reasoning: true,
 				input: ["text"],
 				cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
-				contextWindow: 262144,
+				contextWindow: 1000000,
 				maxTokens: 65536,
 				compat: {
 					supportsDeveloperRole: false,
@@ -318,13 +318,13 @@ export default function (pi: ExtensionAPI) {
 				},
 			},
 			{
-				id: "qwen3.5-122b-a10b",
+				id: "qwen3-max",
-				name: "Qwen 3.5 122B-A10B (Mid MoE)",
+				name: "Qwen 3 Max (Flagship, strongest reasoning)",
 				reasoning: true,
 				input: ["text"],
 				cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
 				contextWindow: 262144,
-				maxTokens: 65536,
+				maxTokens: 32768,
 				compat: {
 					supportsDeveloperRole: false,
 					supportsReasoningEffort: false,
@@ -333,13 +333,13 @@ export default function (pi: ExtensionAPI) {
 				},
 			},
 			{
-				id: "qwen3.5-35b-a3b",
+				id: "qwen-plus",
-				name: "Qwen 3.5 35B-A3B (Small MoE)",
+				name: "Qwen 3 Plus (Balanced)",
 				reasoning: true,
 				input: ["text"],
 				cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
-				contextWindow: 262144,
+				contextWindow: 1000000,
-				maxTokens: 65536,
+				maxTokens: 32768,
 				compat: {
 					supportsDeveloperRole: false,
 					supportsReasoningEffort: false,
@@ -348,13 +348,13 @@ export default function (pi: ExtensionAPI) {
 				},
 			},
 			{
-				id: "qwen3.5-27b",
+				id: "qwen-flash",
-				name: "Qwen 3.5 27B (Dense)",
+				name: "Qwen 3 Flash (Fast)",
 				reasoning: true,
 				input: ["text"],
 				cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
-				contextWindow: 262144,
+				contextWindow: 1000000,
-				maxTokens: 65536,
+				maxTokens: 32768,
 				compat: {
 					supportsDeveloperRole: false,
 					supportsReasoningEffort: false,

pi/.pi/agent/extensions/subagent/agents.ts

@@ -1 +0,0 @@
-/home/jonas/.npm-global/lib/node_modules/@mariozechner/pi-coding-agent/examples/extensions/subagent/agents.ts

pi/.pi/agent/extensions/subagent/index.ts

@@ -1 +0,0 @@
-/home/jonas/.npm-global/lib/node_modules/@mariozechner/pi-coding-agent/examples/extensions/subagent/index.ts

pi/.pi/agent/models.json

@@ -1,39 +1,36 @@
 {
   "providers": {
-    "llama-cpp": {
+    "zai": {
-      "baseUrl": "http://localhost:8080/v1",
+      "baseUrl": "https://api.z.ai/api/coding/paas/v4",
       "api": "openai-completions",
-      "apiKey": "sk-no-key",
+      "apiKey": "ZAI_API_KEY",
       "models": [
         {
-          "id": "unsloth/Qwen3.5-9B-GGUF:Q5_K_M",
+          "id": "glm-5.1",
-          "name": "Qwen 3.5 9B Q5_K_M (Local M1 Max - Unsloth)",
+          "name": "GLM-5.1",
           "reasoning": true,
           "input": ["text"],
-          "contextWindow": 262144,
+          "contextWindow": 204800,
-          "maxTokens": 32768,
+          "maxTokens": 131072,
-          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+          "cost": { "input": 1.0, "output": 3.2, "cacheRead": 0.2, "cacheWrite": 0 }
-          "compat": {
-            "supportsDeveloperRole": false,
-            "supportsReasoningEffort": false,
-            "maxTokensField": "max_tokens",
-            "thinkingFormat": "qwen"
-          }
         },
         {
-          "id": "unsloth/Qwen3.5-4B-GGUF:Q5_K_M",
+          "id": "glm-4.7",
-          "name": "Qwen 3.5 4B Q5_K_M (Local M1 Max - Unsloth)",
+          "name": "GLM-4.7",
           "reasoning": true,
           "input": ["text"],
-          "contextWindow": 262144,
+          "contextWindow": 131072,
-          "maxTokens": 32768,
+          "maxTokens": 65536,
-          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+          "cost": { "input": 0.6, "output": 2.2, "cacheRead": 0.1, "cacheWrite": 0 }
-          "compat": {
+        },
-            "supportsDeveloperRole": false,
+        {
-            "supportsReasoningEffort": false,
+          "id": "glm-4.7-flash",
-            "maxTokensField": "max_tokens",
+          "name": "GLM-4.7-Flash",
-            "thinkingFormat": "qwen"
+          "reasoning": false,
-          }
+          "input": ["text"],
+          "contextWindow": 131072,
+          "maxTokens": 16384,
+          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }
         }
       ]
     }

pi/.pi/agent/prompts/implement-critical.md

@@ -7,33 +7,38 @@ Use the subagent tool to implement with maximum quality. This is for high-risk o
 ## Step 1: Deep scout + Plan + Plan review
 ```
 { chain: [
-  { agent: "deep-scout", task: "Thoroughly investigate all code relevant to: $@" },
+  { agent: "deep-scout", task: "Deep architectural investigation for: $@\n\nTrace all dependency chains, read tests, check types, understand WHY things are structured the way they are. Map subsystems and their boundaries. Your output enables a complex high-risk change." },
-  { agent: "planner", task: "Create a detailed implementation plan for: $@\n\nDeep context:\n\n{previous}" },
+  { agent: "planner", task: "Create a detailed implementation plan for: $@\n\nDeep scout context:\n\n{previous}\n\nBe precise: every step must name exact files, functions, and line ranges. Address edge cases and error handling explicitly. Specify which steps can run in parallel. This is a high-risk change — be thorough." },
   { agent: "plan-reviewer", task: "Review this plan critically. Verify all file paths, line numbers, and assumptions against the codebase. Check for missing steps, edge cases, and risks.\n\n{previous}" }
 ]}
 ```
 
 ## Step 2: APPROVAL GATE
 
-**STOP. Present the plan and the Opus review to the user.**
+**STOP. Present the plan and the plan-reviewer verdict to the user.**
 
 Show clearly:
 - The implementation plan (steps, files, risks)
-- Opus's verdict and any issues found
+- Plan-reviewer's verdict (APPROVED / NEEDS_REVISION / REJECTED) and any issues found
 - Ask: "Approve this plan, or want changes?"
 
 Do NOT proceed until the user explicitly approves.
-If the user requests changes, revise the plan and present again.
+If the user requests changes, revise the plan (re-run planner with the feedback) and present again.
 
 ## Step 3: Implement (only after approval)
-- Use "coder-claude" (Sonnet 4.6) for the implementation steps
+- Use "coder-claude" for the implementation steps
-- For multiple independent steps, run them in parallel using separate coder-claude tasks
+- For each coder run, include the approved plan verbatim: "Implement the following plan step(s). Do NOT deviate.\n\n<plan>\n{the approved plan steps}\n</plan>"
+- For multiple independent steps, run them in parallel using separate coder-claude tasks, each assigned to specific files/plan steps to avoid conflicts
 
 ## Step 4: Opus review
-Run the "reviewer" agent on all changes.
+Run the "reviewer" agent on all changes with this task: "Review all changes made for: $@\n\nCheck for correctness, edge cases, error handling, type safety, and consistency with the approved plan."
 
 ## Step 5: Fix
 If the reviewer says NEEDS_FIXES, run the "fixer" agent with the review output.
 
 ## Step 6: Report
 Summarize everything: what was planned, what was implemented, what was reviewed, what was fixed, and any remaining concerns.
+
+## Failure handling
+
+- **If any subagent fails, retry it once.** If it fails again, stop and inform the user which agent failed, what the error was, and what had been completed so far. Do NOT continue with remaining steps after a second failure.

pi/.pi/agent/prompts/implement.md

@@ -1,54 +1,68 @@
 ---
-description: "Adaptive implementation workflow — routes, plans, waits for approval, then implements"
+description: "Implementation workflow — scouts, plans, waits for approval, then implements"
 ---
 
-Use the subagent tool to implement the following task. The workflow is ADAPTIVE — first evaluate, then plan, get user approval, then execute.
+# Task: $@
 
-## Step 1: Route
+Use the subagent tool to implement the task.
 
-Run the "router" agent with this task: $@
+## Step 1: Scout and Plan
 
-The router will return a classification (SMALL, MEDIUM, LARGE, or HUGE).
+Run this chain:
 
-## Step 2: Execute based on classification
+```
+{ chain: [
+  { agent: "scout", task: "Thoroughly investigate the codebase for: $@\n\nFind all relevant files, types, functions, dependencies, and tests. Report file paths with line ranges. Trace how the pieces connect. Flag anything surprising or risky that an implementer needs to know." },
+  { agent: "planner", task: "Create a detailed implementation plan for: $@\n\nScout context:\n\n{previous}\n\nBe precise: every step must name exact files, functions, and line ranges. Address edge cases and error handling. Specify which steps can run in parallel." },
+  { agent: "plan-reviewer", task: "Review this plan critically. Verify all file paths, line numbers, and assumptions against the codebase. Check for missing steps, edge cases, and risks.\n\n{previous}" }
+]}
+```
 
-### If SMALL:
+## Step 2: Approval gate
-Run a single "coder" agent. No planning or review needed.
-After implementation, present what was done. Done.
 
-### If MEDIUM:
+**STOP. Present the plan AND the plan-reviewer verdict to the user. Ask for approval before continuing.**
-Run the "scout" agent, then the "planner" agent as a chain.
 
-**STOP. Present the plan to the user and ask for approval before continuing.**
+When presenting, highlight: what will change, which files, risks, and the plan-reviewer verdict.
-
-Once approved (user says ok, go, approved, looks good, etc):
-- Run the "coder" agent to implement the plan
-- Run "reviewer-quick" on the result
-- If NEEDS_FIXES, run the "fixer" agent
-
-### If LARGE:
-Run a chain: "scout" → "planner" → "plan-reviewer"
-
-**STOP. Present the plan AND the Opus review to the user. Ask for approval before continuing.**
-
-Once approved:
-- Execute the plan steps using "coder" for sequential steps, or "coder-parallel" with parallel tasks if the plan identified parallelizable steps
-- Run the "reviewer" agent on all changes
-- If NEEDS_FIXES, run the "fixer" agent
 
 If the user requests changes to the plan, revise and present again before implementing.
 
-### If HUGE:
+## Step 3: Implement
-Same as LARGE but use "deep-scout" instead of "scout", and prefer parallel execution with "coder-parallel" for independent steps.
 
-**STOP after planning. Same approval gate as LARGE.**
+Once approved:
+- Execute the plan steps using "coder" for sequential steps, or "coder-parallel" with parallel tasks if the plan identified parallelizable steps
+- When running coder, always wrap the plan step(s) in the task: "Implement the following plan step(s). Do NOT deviate.\n\n<plan>\n{the approved plan steps}\n</plan>"
+- Run the "reviewer" agent on all changes
+- If NEEDS_FIXES, run the "fixer" agent with the review output
+
+## Step 4: Summary
+
+After the final step, summarize: what was done, what files changed, what was reviewed, and any remaining concerns.
 
 ## Important
 
-- **NEVER skip the approval gate** for MEDIUM, LARGE, or HUGE tasks. Always present the plan and wait.
+- **NEVER skip the approval gate**. Always present the plan and wait.
-- When presenting the plan, format it clearly. Highlight: what will change, which files, risks, and the Opus review verdict (if applicable).
+- Always pass scout context forward using {previous} in chain mode — this is how the planner and plan-reviewer receive the scout's findings.
-- If the user says "with changes" or gives feedback, revise the plan and present again.
+- When running the coder, always include the approved plan verbatim in the task so the coder has full context.
-- Always pass scout/planner context forward using {previous} in chain mode.
+- For parallel coder tasks, clearly assign each coder to specific files/plan steps to avoid conflicts.
-- For parallel coder tasks, clearly assign each coder to specific files to avoid conflicts.
+
-- If any step fails, report what happened and stop.
+## Agent Failure and Fallback
-- After the final step, summarize: what was done, what files changed, what was reviewed, and any remaining concerns.
+
+When a subagent returns empty output or an error (rate limit, credit exhaustion, connection failure):
+
+1. **Retry once** with the same agent and model — transient failures are common.
+2. **If still failing, retry with the cross-family fallback model** using the `model` override parameter:
+
+| Agent | Primary model | Fallback model |
+|-------|--------------|----------------|
+| scout | zai/glm-4.7-flash | anthropic/claude-haiku-4-5 |
+| deep-scout, coder-parallel | zai/glm-4.7 | anthropic/claude-sonnet-4-6 |
+| planner, coder | zai/glm-5.1 | anthropic/claude-opus-4-6 |
+| reviewer-quick, explorer | anthropic/claude-haiku-4-5 | zai/glm-4.7-flash |
+| coder-claude, fixer | anthropic/claude-sonnet-4-6 | zai/glm-5.1 |
+| plan-reviewer, reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |
+
+Example: `subagent({ agent: "scout", task: "...", model: "anthropic/claude-haiku-4-5" })`
+
+3. **If the fallback also fails**, do the work yourself (read the relevant files directly and produce the scout/plan/review output inline). Inform the user which agent failed, what error was returned, and what you did instead.
+
+Do NOT silently absorb failures. Always surface them to the user even when working around them.

pi/.pi/agent/prompts/plan.md

@@ -13,3 +13,14 @@ Use the subagent tool with a chain to plan (but NOT implement) the following:
 ```
 
 Present the plan and the review to me. Do NOT proceed to implementation.
+
+## Agent Failure and Fallback
+
+If any agent returns empty output or an error (rate limit, credit exhaustion, connection failure):
+
+1. Retry once with the same agent.
+2. If still failing, retry with the cross-family fallback using the `model` override:
+   - scout (zai/glm-4.7-flash fails) → `model: "anthropic/claude-haiku-4-5"`
+   - planner (zai/glm-5.1 fails) → `model: "anthropic/claude-opus-4-6"`
+   - plan-reviewer (anthropic/claude-opus-4-6 fails) → `model: "zai/glm-5.1"`
+3. If the fallback also fails, do the work yourself and tell me which agent failed and why.

pi/.pi/agent/skills/subagent-implement-critical/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: subagent-implement-critical
+description: "Maximum-quality implementation pipeline: deep-scout → plan → review → Claude coder → build verify → review → fix. Use when the user invokes /implement-critical."
+---
+
+# /implement-critical — Maximum Quality Pipeline
+
+Same structure as `/implement` but with deeper scouting and a stronger coder.
+
+## Agent Roster
+
+| Agent | Role |
+|-------|------|
+| deep-scout | Thorough architectural exploration |
+| planner | Detailed implementation plans |
+| plan-reviewer | Reviews plans for correctness and risk |
+| coder-claude | Complex/unfamiliar implementation (elite coder) |
+| reviewer | Cross-family code review |
+| fixer | Applies review feedback precisely |
+
+## Phase 1: Deep Scout → Plan → Review (chain)
+
+```js
+await subagent({ chain: [
+  { agent: "deep-scout",     task: "Explore the codebase for: {task}" },
+  { agent: "planner",        task: "Create a detailed implementation plan for: {task}" },
+  { agent: "plan-reviewer",  task: "Review the plan for correctness, completeness, and risk." }
+]})
+```
+
+The chain creates `scout.md`, `plan.md`, `plan-review.md` in the chain artifact dir.
+
+Read `plan-review.md` from the artifact dir. If **NEEDS_REVISION** or **REJECTED**, loop: tell the planner what to fix, re-run the reviewer. If **APPROVED**, proceed to Phase 2.
+
+## Phase 2: Implement
+
+```js
+await subagent({ agent: "coder-claude", task: `Read and implement the plan at <chain_dir>/plan.md` })
+```
+
+Use the chain dir path from Phase 1's result.
+
+## Phase 3: Build Verification
+
+After the coder finishes, independently verify the build — don't trust the coder's report:
+
+```bash
+# Run a full build, not just type-check. Shaders, linkers, and bundlers may fail.
+# Adapt to project: cargo build, npm run build, etc.
+```
+
+## Phase 4: Review → Fix
+
+```js
+await subagent({ agent: "reviewer", output: `${chainDir}/review.md`, task: "Review all changes made" })
+```
+
+Read `review.md`. If issues found:
+
+```js
+await subagent({ agent: "fixer", task: `Read and apply the review feedback in ${chainDir}/review.md` })
+```
+
+## Phase 5: Workflow Summary
+
+After all phases complete, give the user a brief honest summary:
+
+- **What happened**: which phases ran, any plan review loops, whether fixes were needed
+- **Issues**: any agent silent failures, fallbacks used, build errors, or unexpected behavior
+- **Agent quality**: did any agent misinterpret the task, produce poor output, or need hand-holding? Name the agent and the problem
+- **Skill improvements**: did this workflow reveal gaps in the skill instructions or agent prompts? Note what should change
+
+Be concise — a few lines is enough when things went well. Only expand on problems.
+
+## Chain Mechanics
+
+Chain mode (`subagent({ chain: [...] })`) runs agents sequentially in a shared temp directory (`{chain_dir}`). Each step:
+1. The framework injects `[Read from:]` and `[Write to:]` directives from the agent's `defaultReads` and `output` frontmatter
+2. The agent reads upstream files, does its work, and writes its deliverable to the `[Write to:]` path using the `write` tool
+3. The agent returns a brief text summary; `{previous}` carries this summary to the next step
+4. Variable substitution: `{task}` = original task, `{previous}` = prior step's brief ack, `{chain_dir}` = artifact dir path
+
+Key behaviors:
+- Data flows through FILES (`scout.md` → `plan.md` → `plan-review.md`), not through `{previous}`
+- `{previous}` contains only a brief summary from the prior step — do NOT rely on it for full context
+- The framework validates that the expected output file was created
+- The chain result includes `📁 Artifacts: /tmp/pi-chain-runs/<id>/` — use this path to read files for branching decisions
+
+## Fallback Strategy
+
+When a subagent call returns no output (silent failure), apply cross-family model fallback. **Do not fall back to doing the work yourself** — always retry with the fallback model first.
+
+1. **First attempt**: Use the agent's default model
+2. **If silent failure or error**: Retry with the fallback model using `model` override
+3. **If the fallback also fails**: Report the double-failure to the user. Still do not do the work yourself.
+
+```js
+// Example: deep-scout fails silently, retry with fallback
+subagent({ agent: "deep-scout", task: "...", model: "anthropic/claude-sonnet-4-6" })
+```
+
+| Agent | Primary | Fallback |
+|-------|---------|----------|
+| deep-scout | zai/glm-4.7 | anthropic/claude-sonnet-4-6 |
+| planner | zai/glm-5.1 | anthropic/claude-opus-4-6 |
+| plan-reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |
+| coder-claude | anthropic/claude-sonnet-4-6 | zai/glm-5.1 |
+| reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |
+| fixer | anthropic/claude-sonnet-4-6 | zai/glm-5.1 |

pi/.pi/agent/skills/subagent-implement/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: subagent-implement
+description: "Full implementation pipeline: scout → plan → review → code → build verify → review → fix. Use when the user invokes /implement."
+---
+
+# /implement — Standard Implementation Pipeline
+
+## Agent Roster
+
+| Agent | Role |
+|-------|------|
+| scout | Fast codebase recon |
+| planner | Detailed implementation plans |
+| plan-reviewer | Reviews plans for correctness and risk |
+| coder | Primary implementation |
+| coder-parallel | Parallel implementation tasks (fan-out) |
+| reviewer | Cross-family code review |
+| fixer | Applies review feedback precisely |
+
+## Phase 1: Scout → Plan → Review (chain)
+
+```js
+await subagent({ chain: [
+  { agent: "scout",         task: "Explore the codebase for: {task}" },
+  { agent: "planner",       task: "Create a detailed implementation plan for: {task}" },
+  { agent: "plan-reviewer", task: "Review the plan for correctness, completeness, and risk." }
+]})
+```
+
+The chain creates `scout.md`, `plan.md`, `plan-review.md` in the chain artifact dir.
+
+Read `plan-review.md` from the artifact dir. If **NEEDS_REVISION** or **REJECTED**, loop: tell the planner what to fix, re-run the reviewer. If **APPROVED**, proceed to Phase 2.
+
+## Phase 2: Implement
+
+```js
+// Single coder:
+await subagent({ agent: "coder", task: `Read and implement the plan at <chain_dir>/plan.md` })
+
+// Or parallel coders (if plan has independent sections):
+await subagent({ tasks: [
+  { agent: "coder-parallel", task: `Implement Part A from <chain_dir>/plan.md` },
+  { agent: "coder-parallel", task: `Implement Part B from <chain_dir>/plan.md` }
+]})
+```
+
+Use the chain dir path from Phase 1's result.
+
+## Phase 3: Build Verification
+
+After the coder finishes, independently verify the build — don't trust the coder's report:
+
+```bash
+# Run a full build, not just type-check. Shaders, linkers, and bundlers may fail.
+# Adapt to project: cargo build, npm run build, etc.
+```
+
+## Phase 4: Review → Fix
+
+```js
+await subagent({ agent: "reviewer", output: `${chainDir}/review.md`, task: "Review all changes made" })
+```
+
+Read `review.md`. If issues found:
+
+```js
+await subagent({ agent: "fixer", task: `Read and apply the review feedback in ${chainDir}/review.md` })
+```
+
+## Phase 5: Next Steps & Workflow Summary
+
+After all phases complete, give the user a brief summary of what is next to take use of the implementation and an honoest evaluation of the workflow:
+
+- **What needs wiring and where**: Point to where the user can take the implementation into use
+- **What happened**: which phases ran, any plan review loops, whether fixes were needed
+- **Issues**: any agent silent failures, fallbacks used, build errors, or unexpected behavior
+- **Agent quality**: did any agent misinterpret the task, produce poor output, or need hand-holding? Name the agent and the problem.
+- **Skill improvements**: did this workflow reveal gaps in the skill instructions or agent prompts? Note what should change
+
+Be concise — a few lines is enough when things went well. Only expand on problems.
+
+## Parallel Coders Within a Chain
+
+Fan-out/fan-in inside a chain (useful when plan sections are independent):
+
+```js
+await subagent({ chain: [
+  { agent: "scout", task: "Explore the codebase for: {task}" },
+  { agent: "planner", task: "..." },
+  { parallel: [
+    { agent: "coder-parallel", task: "Read the plan at {chain_dir}/plan.md. Implement Part A" },
+    { agent: "coder-parallel", task: "Read the plan at {chain_dir}/plan.md. Implement Part B" }
+  ]},
+  { agent: "reviewer", task: "Review all changes from {previous}" }
+]})
+```
+
+## Step Overrides
+
+Override agent defaults per step:
+
+```js
+await subagent({ chain: [
+  { agent: "scout", output: "context.md" },
+  { agent: "planner", reads: ["context.md"], output: "plan.md" },
+  { agent: "plan-reviewer", reads: ["plan.md"] }
+]})
+```
+
+## Chain Mechanics
+
+Chain mode (`subagent({ chain: [...] })`) runs agents sequentially in a shared temp directory (`{chain_dir}`). Each step:
+1. The framework injects `[Read from:]` and `[Write to:]` directives from the agent's `defaultReads` and `output` frontmatter
+2. The agent reads upstream files, does its work, and writes its deliverable to the `[Write to:]` path using the `write` tool
+3. The agent returns a brief text summary; `{previous}` carries this summary to the next step
+4. Variable substitution: `{task}` = original task, `{previous}` = prior step's brief ack, `{chain_dir}` = artifact dir path
+
+Key behaviors:
+- Data flows through FILES (`scout.md` → `plan.md` → `plan-review.md`), not through `{previous}`
+- `{previous}` contains only a brief summary from the prior step — do NOT rely on it for full context
+- The framework validates that the expected output file was created
+- The chain result includes `📁 Artifacts: /tmp/pi-chain-runs/<id>/` — use this path to read files for branching decisions
+
+Reviewer and fixer run as single agents (not in chains). Pass file paths in the task string and use the `output` parameter to capture their output.
+
+## Fallback Strategy
+
+When a subagent call returns no output (silent failure), apply cross-family model fallback. **Do not fall back to doing the work yourself** — always retry with the fallback model first.
+
+1. **First attempt**: Use the agent's default model
+2. **If silent failure or error**: Retry with the fallback model using `model` override
+3. **If the fallback also fails**: Report the double-failure to the user. Still do not do the work yourself.
+
+```js
+// Example: scout fails silently, retry with fallback
+subagent({ agent: "scout", task: "...", model: "anthropic/claude-haiku-4-5" })
+```
+
+| Agent | Primary | Fallback |
+|-------|---------|----------|
+| scout | zai/glm-4.7-flash | anthropic/claude-haiku-4-5 |
+| planner, coder | zai/glm-5.1 | anthropic/claude-opus-4-6 |
+| coder-parallel | zai/glm-4.7 | anthropic/claude-sonnet-4-6 |
+| plan-reviewer, reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |
+| fixer | anthropic/claude-sonnet-4-6 | zai/glm-5.1 |
+
+## Adaptive Routing
+
+Do not run the full pipeline for a one-line fix. Use your judgment — a single coder call may suffice.

pi/.pi/agent/skills/subagent-plan/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: subagent-plan
+description: "Plan-only pipeline: scout → plan → review. Produces a reviewed implementation plan without coding. Use when the user invokes /plan."
+---
+
+# /plan — Plan Only (No Implementation)
+
+## Agent Roster
+
+| Agent | Role |
+|-------|------|
+| scout | Fast codebase recon |
+| planner | Detailed implementation plans |
+| plan-reviewer | Reviews plans for correctness and risk |
+
+## Workflow (single chain)
+
+```js
+await subagent({ chain: [
+  { agent: "scout",         task: "Explore the codebase for: {task}" },
+  { agent: "planner",       task: "Create a detailed implementation plan for: {task}" },
+  { agent: "plan-reviewer", task: "Review the plan for correctness, completeness, and risk." }
+]})
+```
+
+The chain creates `scout.md`, `plan.md`, `plan-review.md` in the chain artifact dir (`/tmp/pi-chain-runs/<id>/`).
+
+## Handling the Verdict
+
+Read `plan-review.md` from the artifact dir. If **NEEDS_REVISION** or **REJECTED**, loop: tell the planner what to fix, re-run the reviewer. If **APPROVED**, present the plan path to the user.
+
+Show the user the path to `plan.md`.
+
+## Workflow Summary
+
+After the chain completes, give the user a brief honest summary:
+
+- **What happened**: did the plan pass review on the first try, or did it need revision loops?
+- **Issues**: any agent silent failures, fallbacks used, or unexpected behavior
+- **Agent quality**: did any agent misinterpret the task, produce poor output, or need hand-holding? Name the agent and the problem
+- **Skill improvements**: did this workflow reveal gaps in the skill instructions or agent prompts? Note what should change
+
+Be concise — a few lines is enough when things went well. Only expand on problems.
+
+## Chain Mechanics
+
+Chain mode (`subagent({ chain: [...] })`) runs agents sequentially in a shared temp directory (`{chain_dir}`). Each step:
+1. The framework injects `[Read from:]` and `[Write to:]` directives from the agent's `defaultReads` and `output` frontmatter
+2. The agent reads upstream files, does its work, and writes its deliverable to the `[Write to:]` path using the `write` tool
+3. The agent returns a brief text summary; `{previous}` carries this summary to the next step
+4. Variable substitution: `{task}` = original task, `{previous}` = prior step's brief ack, `{chain_dir}` = artifact dir path
+
+Key behaviors:
+- Data flows through FILES (`scout.md` → `plan.md` → `plan-review.md`), not through `{previous}`
+- `{previous}` contains only a brief summary from the prior step — do NOT rely on it for full context
+- The framework validates that the expected output file was created
+- The chain result includes `📁 Artifacts: /tmp/pi-chain-runs/<id>/` — use this path to read files for branching decisions
+
+## Fallback Strategy
+
+When a subagent call returns no output (silent failure), apply cross-family model fallback. **Do not fall back to doing the work yourself** — always retry with the fallback model first.
+
+1. **First attempt**: Use the agent's default model
+2. **If silent failure or error**: Retry with the fallback model using `model` override
+3. **If the fallback also fails**: Report the double-failure to the user. Still do not do the work yourself.
+
+```js
+// Example: scout fails silently, retry with fallback
+subagent({ agent: "scout", task: "...", model: "anthropic/claude-haiku-4-5" })
+```
+
+| Agent | Primary | Fallback |
+|-------|---------|----------|
+| scout | zai/glm-4.7-flash | anthropic/claude-haiku-4-5 |
+| planner | zai/glm-5.1 | anthropic/claude-opus-4-6 |
+| plan-reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |

pi/.pi/agent/skills/subagent-review/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: subagent-review
+description: "Code review using a cross-family reviewer. Use when the user invokes /review."
+---
+
+# /review — Code Review
+
+## Agent Roster
+
+| Agent | Role |
+|-------|------|
+| reviewer | Cross-family code review (finds blind spots the author's model family misses) |
+| fixer | Applies review feedback precisely |
+
+## Workflow
+
+Single reviewer call — no chain needed:
+
+```js
+await subagent({ agent: "reviewer", output: `${chainDir}/review.md`, task: "Review the following changes: <description or files>" })
+```
+
+Read `review.md`. If issues found, apply fixes:
+
+```js
+await subagent({ agent: "fixer", task: `Read and apply the review feedback in ${chainDir}/review.md` })
+```
+
+## Workflow Summary
+
+After review (and optional fix), give the user a brief honest summary:
+
+- **What happened**: did the reviewer find issues, were fixes applied?
+- **Issues**: any agent silent failures, fallbacks used, or unexpected behavior
+- **Agent quality**: did any agent misinterpret the task, produce poor output, or need hand-holding? Name the agent and the problem
+- **Skill improvements**: did this workflow reveal gaps in the skill instructions or agent prompts? Note what should change
+
+Be concise — a few lines is enough when things went well. Only expand on problems.
+
+## Fallback Strategy
+
+When a subagent call returns no output (silent failure), apply cross-family model fallback. **Do not fall back to doing the work yourself** — always retry with the fallback model first.
+
+1. **First attempt**: Use the agent's default model
+2. **If silent failure or error**: Retry with the fallback model using `model` override
+3. **If the fallback also fails**: Report the double-failure to the user. Still do not do the work yourself.
+
+```js
+// Example: reviewer fails silently, retry with fallback
+subagent({ agent: "reviewer", task: "...", model: "zai/glm-5.1" })
+```
+
+| Agent | Primary | Fallback |
+|-------|---------|----------|
+| reviewer | anthropic/claude-opus-4-6 | zai/glm-5.1 |
+| fixer | anthropic/claude-sonnet-4-6 | zai/glm-5.1 |

pi/.pi/agent/skills/subagent-workflows/SKILL.md

@@ -1,44 +0,0 @@
----
-name: subagent-workflows
-description: "Reference for the subagent catalog, workflows, and model assignments. Load when working with /implement, /plan, /review, /implement-critical, or when deciding which agents to use."
----
-
-# Subagent Catalog & Workflows
-
-## Agent Roster
-
-| Agent | Model | Role | Cost Profile |
-|-------|-------|------|-------------|
-| **router** | Qwen 122B-A10B | Evaluates task complexity, picks workflow | Cheap MoE |
-| **scout** | Qwen 122B-A10B | Fast codebase recon, structured findings | Cheap MoE |
-| **deep-scout** | Qwen 27B (dense) | Thorough architectural exploration | Moderate |
-| **planner** | Qwen Max (frontier) | Detailed implementation plans | Frontier, free via qwen.ai |
-| **plan-reviewer** | Claude Opus 4.6 | Reviews plans before implementation | $$$ but low volume |
-| **coder** | Qwen Max | Primary implementation | Frontier, free via qwen.ai |
-| **coder-parallel** | Qwen 397B-A17B | Parallel implementation tasks | Strong MoE, parallelizable |
-| **coder-claude** | Claude Sonnet 4.6 | Complex/unfamiliar implementation | $$ elite coder |
-| **reviewer** | Claude Opus 4.6 | Cross-family code review | $$$ but low volume |
-| **reviewer-quick** | Claude Haiku 4.5 | Fast cross-family sanity check | $ |
-| **fixer** | Claude Sonnet 4.6 | Applies review feedback precisely | $$ |
-
-## Workflows
-
-### `/implement <task>` — Adaptive (auto-selects pipeline)
-Router evaluates → SMALL/MEDIUM/LARGE/HUGE → runs appropriate chain.
-
-### `/plan <task>` — Plan only
-Scout → Planner (Max) → Plan Reviewer (Opus). No implementation.
-
-### `/review <files or description>` — Opus review
-Direct Opus review on changes.
-
-### `/implement-critical <task>` — Maximum quality
-Deep Scout → Planner → Opus Plan Review → Sonnet Coder → Opus Review → Fixer.
-
-## Design Principles
-
-1. **Qwen-first**: Max for planning and primary coding (free, frontier). MoE models for volume tasks.
-2. **Cross-family review**: Qwen codes → Claude reviews. Different training = different blind spots caught.
-3. **Opus for review, not implementation**: Low output tokens, maximum leverage. Finding bugs > writing code.
-4. **Sonnet 4.6 for precision edits**: Best instruction-following for applying review fixes.
-5. **Adaptive routing**: Don't run 5-agent pipeline for a one-line fix.

zshrc/.zshrc

@@ -42,6 +42,7 @@ export EDITOR="nvim"
 export VISUAL="nvim"
 export SUDO_EDITOR="nvim"
 export OPENROUTER_API_KEY=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
+export ZAI_API_KEY=80a53d7e46724e9aa913b06e1f8fa4f0.Yeq45xsosX3LfWxk
 export USE_BUILTIN_RIPGREP=0
 export REAL_DEBRID_API_KEY="HQVUOC3ALUHIIQCFQK4UOV2GVGVLQKKHEWFWKN77G6URFBTQMUTQ"
 export HF_TOKEN=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