oh-my-opencode 5.0.0-beta.3 → 5.0.0-beta.30

package/packages/shared-skills/skills/ulw-plan/references/intent-unclear.md

@@ -7,7 +7,7 @@ metadata:
 
 # ulw-plan - UNCLEAR intent
 
-Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$start-work` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
+Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$ulw-execute` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
 
 <stance>
 PRIME DIRECTIVE: do NOT interrogate the user. Resolve ambiguity by RESEARCH, not questions. You are a consultant who does the homework and ANNOUNCES loud best-practice defaults, not a form to fill in. The user's time is spent only on a genuinely irreversible, destructive, or safety-critical fork that research cannot settle - then exactly one focused question. Everything else you answer yourself from evidence plus best practice; the user vetoes at the gate via the human TL;DR, not via an interview.
@@ -20,19 +20,19 @@ TOPOLOGY LOCK still applies: enumerate the 1-6 independently-succeed/fail compon
 </research_protocol>
 
 <default_selection>
-For each open decision, adopt the defensible best-practice default (industry standard or repo convention), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is one that is irreversible, destructive, or safety-critical and research cannot settle.
+For each open decision - including the extrinsic axes the sweep names (budget, mandated stack, expected scale, target audience / compliance) - adopt the defensible best-practice default (industry standard or repo convention), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is one that is irreversible, destructive, or safety-critical, or commits real spend the user never authorized, and research cannot settle.
 
 Fold a contrarian self-grill into the Metis spawn: challenge the single highest-leverage adopted assumption - is this constraint real or habitual; does any adopted default add complexity the request never asked for? - and return concrete reframes. The grill targets incidental complexity (unneeded abstraction, speculative capacity), NEVER the feature set: reducing, phasing, or deferring part of the request is not a reframe. Fold a reframe into the plan only as a recommended default plus rationale, never as a forced change.
 </default_selection>
 
 <high_accuracy_auto>
-Because the human did not steer, adversarial review SUBSTITUTES for the interview you skipped - this is what catches a bad default. Metis runs during plan generation as always; after Metis findings are folded and the plan file is complete, run the dual high-accuracy review defined in `full-workflow.md` AUTOMATICALLY - no "do you want a review?" question - and resubmit fresh until BOTH passes APPROVE, fixing every cited issue.
+Because the human did not steer, adversarial review SUBSTITUTES for the interview you skipped - this is what catches a bad default. Metis runs during plan generation as always; after Metis findings are folded and the plan file is complete, run the dual high-accuracy review defined in `full-workflow.md` AUTOMATICALLY - no "do you want a review?" question - and drive it to convergence under the bounded convergence contract in `full-workflow.md`: fix every eligible blocker and resubmit fresh, record ineligible findings as non-blocking notes, and on cap exhaustion stop and ask the user.
 
 TRIVIAL-TIER GUARD: if Classify sized the work Trivial, the auto-Momus loop is SUPPRESSED (Metis still runs once) - a vague-but-tiny request ("clean this up") must not trigger the full adversarial loop. UNCLEAR raises the research-plus-default posture; it does not override the Trivial cost guard for Momus.
 </high_accuracy_auto>
 
 <approval_gate>
-Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($start-work bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's start-work rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
+Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($ulw-execute bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's ulw-execute rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
 </approval_gate>
 
 <worked_example>
@@ -40,5 +40,5 @@ Request: "make auth better".
 1. Research waves -> current auth at `src/auth/*` and evidence for the requested improvement; best-practice baselines via librarian.
 2. Topology lock as an ANNOUNCEMENT, not a question: components refine the evidenced auth intent in full, such as session hardening, brute-force protection, and password policy when the repository supports them. MFA is an adjacent capability and stays in Scope OUT unless the user asks for it or evidence establishes it as part of the requested outcome.
 3. Adopted-defaults table (assumption | default | rationale | reversible?): bcrypt rounds 8 -> 12 (reversible), add 5/min-per-IP login limit (reversible), rotate session id on privilege change (reversible).
-4. Metis folded -> auto dual review (fix cited gaps until both approve) -> brief LEADING with the approach and the defaults, surfaced in the human TL;DR for veto.
+4. Metis folded -> auto dual review (fix eligible gaps under the bounded convergence contract) -> brief LEADING with the approach and the defaults, surfaced in the human TL;DR for veto.
 </worked_example>

package/packages/shared-skills/skills/ulw-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ulw-research
-description: "Maximum-saturation research orchestration: ALWAYS proposes the final materials first (PDF+DOCX default), then parallel explore+librarian swarms across codebase, web, official docs, and OSS repos — max-roster teammode when the harness has it — with live journaling, a recursive EXPAND loop driven by leads workers return in message text, empirical verification by running code, and a cited synthesis with charts/Mermaid/assets behind a mandatory visual-QA gate. ACTIVATES ONLY on an explicit user demand for research — the word 'ulw-research' ('/ulw-research', '$ulw-research'), any 'ulw' research wording, 'ultradebate' or 'hyperdebate' research requests, or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
+description: "Maximum-saturation research orchestration: ALWAYS proposes the final materials first (PDF+DOCX default), then parallel explore+librarian swarms across codebase, web, official docs, and OSS repos — max-roster teammode when the harness has it — with live journaling, a recursive EXPAND loop driven by leads workers return in message text, empirical verification by running code, and a cited synthesis with charts/Mermaid/assets behind a mandatory visual-QA gate. ACTIVATES ONLY on an explicit user demand for research — the word 'ulw-research' in any prefix form, any 'ulw' research wording including combined invocations like 'mass ulw research', 'ultradebate' or 'hyperdebate' research requests, or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
 ---
 
 ## Codex Harness Tool Compatibility
@@ -161,7 +161,9 @@ Record the answer in the journal; Phase 5 opens by turning it into `design-spec.
 
 ## Phase 1 — Saturation wave
 
-Launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
+**When the user asked for MASS research, the wave is sized by the topic's angles, not by the roster ceiling.** "mass ulw research", "mulw research", "ulw mass research" — in any language — order over-collection that a team of 8 cannot produce. Where the harness has a dependency-graph surface (the `mass-ulw` skill and its `references/planning.md`), run collection through it instead: a 60+ node opening wave covering every angle the topic has, routed across the whole difficulty ladder in one graph — mechanical sweeps and per-item harvest batches on the cheapest tier, judgment-shaped angles a step up, cross-territory angles a step above that, and the deepest tier reserved for genuinely hairy contradictions. Each wave's EXPAND leads define the next wave's nodes, and the synthesis reduces through several parallel architect-tier nodes into ONE architect-tier reducer (the strongest reasoning tier substitutes wherever no architect tier exists). Absent that surface, hold the same shape with background workers in batched waves. Everything else in this skill still binds: the format gate, the journal, the claim graph, the convergence rules, and the delivery gates.
+
+Otherwise launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
 
 Scaling floor — more angles always justify more workers:
 

package/packages/shared-skills/skills/visual-qa/AGENTS.md

@@ -0,0 +1,58 @@
+# visual-qa — Bundled Visual-Evidence CLI
+
+**Generated:** 2026-08-24 (f3642fcda)
+
+## OVERVIEW
+
+The visual-QA skill's executable core: a zero-dependency Node CLI that produces machine evidence (`image-diff`, `tui-check`) plus the TypeScript sources it is bundled from. Earned this file: the only shared skill shipping a built bundle whose runtime and development sources must be kept in lockstep.
+
+## STRUCTURE
+
+```
+visual-qa/
+├── SKILL.md                      # reviewer workflow (dual oracle, evidence gates) — the prose contract
+├── references/agent-browser-setup.md
+└── scripts/
+    ├── visual-qa.mjs             # SHIPPED RUNTIME: bun-build bundle of cli.ts (+ embedded modules)
+    ├── cli.ts                    # development source; dispatches image-diff / tui-check
+    ├── image-diff.ts             # diffImages — 8x8 grid cells, hotspots, rounded metrics
+    ├── tui-grid.ts               # checkTui — column overflow + border alignment verdicts
+    ├── east-asian-width.ts       # charWidth / stringWidth — CJK-aware width math
+    ├── ansi.ts                   # ANSI escape stripping (width must be escape-aware)
+    ├── png-decode.ts / png-crc.ts / png-synth.ts   # stdlib PNG codec (no deps)
+    ├── types.ts
+    └── *.test.ts                 # co-located bun tests for every module above
+```
+
+## BUNDLE/SOURCE DUALITY
+
+`visual-qa.mjs` is the artifact the skill's commands invoke (`node "$SKILL_DIR/scripts/visual-qa.mjs" …`); the `.ts` files exist for development and tests only. A behavior fix lands in the TS source AND the bundle is regenerated from `cli.ts` — editing one without the other makes tests and runtime disagree. Never hand-edit the `.mjs`.
+
+## SURFACE
+
+- Commands: `image-diff <reference.png> <actual.png>` and `tui-check <capture.txt> --cols <N>`; JSON verdict output (hotspot cells, overflow lines, wide-char columns, border alignment).
+- Module exports: `diffImages`, `checkTui`, `charWidth`/`stringWidth`, ANSI + PNG helpers. `cli.ts` owns `CliError`, `parseColumns`, `run`, `main`.
+
+## CONVENTIONS
+
+- Zero runtime dependencies — PNG decode/synthesis and ANSI handling are hand-rolled in `scripts/`; keep it that way (the bundle must stay require-free apart from `node:` builtins).
+- Width is never `String.length`: CJK wide characters and ANSI escapes are accounted for before any column math.
+- Tests are co-located `bun test scripts/*.test.ts`, given/when/then style per repo convention.
+
+## ANTI-PATTERNS
+
+- NEVER hand-edit `visual-qa.mjs`; regenerate from source.
+- Don't add an npm dependency to make PNG/diff easier — the no-dep bundle is the point.
+- Column math that ignores CJK width or ANSI escapes is wrong by construction; `tui-check` exists because text-diff tools get terminal grids wrong.
+- Skill-level rule worth repeating for code changes: `tmux capture-pane` is forbidden as a capture mechanism.
+
+## COMMANDS
+
+```bash
+# from packages/shared-skills/skills/visual-qa/
+node scripts/visual-qa.mjs image-diff <reference.png> <actual.png>
+node scripts/visual-qa.mjs tui-check <capture.txt> --cols 80
+bun test scripts/*.test.ts
+```
+
+- Parent: [`packages/shared-skills/AGENTS.md`](../../AGENTS.md).

package/packages/shared-skills/skills/visual-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: visual-qa
-description: "MUST USE after building/changing any UI or when asked whether a page, component, or TUI looks right. Rigorous visual QA across web/page and terminal UIs. Prefer browser:control-in-app-browser for unauthenticated browser/page QA in Codex, then Playwright/agent-browser/dev-browser. Captures screenshot/TUI evidence with bundled diff scripts, runs design-system/functional and visual-fidelity/CJK reviewer passes, then synthesizes a good/bad verdict. Triggers: visual QA, screenshot/pixel diff, UI looks wrong, reference fidelity, design system check, responsive check, CJK text clipping, TUI alignment, box-drawing drift."
+description: "MUST USE after building/changing any UI or when asked whether a page, component, or TUI looks right. Rigorous visual QA across web/page, terminal, and paginated-document surfaces. Prefer browser:control-in-app-browser for unauthenticated browser/page QA in Codex, then Playwright/agent-browser/dev-browser. Captures screenshot/TUI evidence with bundled diff scripts, runs design-system/functional and visual-fidelity/CJK reviewer passes, then synthesizes a good/bad verdict. Triggers: visual QA, screenshot/pixel diff, UI looks wrong, reference fidelity, design system check, responsive check, CJK text clipping, TUI alignment, box-drawing drift, PDF page check, deck review, blank or near-empty page, wrong page break."
 ---
 
 # Visual QA - Dual-Oracle Web and TUI Verification
@@ -9,7 +9,7 @@ Verify a rendered UI against intent using objective script evidence plus two par
 
 ## Purpose and when to use
 
-- Use after you build or change any UI, before calling it done. Covers web/page UIs and TUI/terminal UIs.
+- Use after you build or change any UI, before calling it done. Covers web/page UIs, TUI/terminal UIs, and paginated documents.
 - Use when output must match a mock, a baseline, or a stated design intent; when you suspect a regression; when CJK (Korean/Japanese/Chinese) text may clip, misalign, or wrap awkwardly; when a claimed design system might actually be a flat image; when a terminal layout may overflow or its borders may break.
 - Skip when there is no rendered surface (pure backend or library logic with no visual or terminal output). For broad post-implementation review use review-work; this skill is the visual specialist.
 
@@ -19,6 +19,7 @@ In the commands below, `$SKILL_DIR` is this skill's own directory (the folder co
 
 - Web/page UI: renders in a browser (HTML/CSS/JS, components, canvas, SVG). Evidence is screenshots.
 - TUI/terminal UI: renders as text in a terminal (box-drawing, panes, status lines, REPL/TUI apps). Evidence is terminal captures.
+- Paginated document: renders as ordered pages (PDF report, printed HTML, exported deck). Evidence is every page rendered to an image - `pdftoppm -png -r 150 <file>.pdf <prefix>` or the pipeline's own renderer. Extracted text is not evidence here: layout is exactly what extraction discards, so a stranded block, a split table, or a near-empty page survives a clean text check.
 - Reference-fidelity UI: any web/page UI built from a concrete reference packet, including screenshots, generated Imagen/Stitch mockups, Figma exports, overview text, annotations, or source-site captures. Evidence is the full reference packet plus same-size actual captures.
 
 If the change touches both, run both capture tracks and feed both into the passes.

package/script/qa/web-terminal-visual-qa.mjs

@@ -30,6 +30,8 @@ Inputs:
   --from-file <path>     Render an existing raw terminal byte stream through xterm.js (replay; no interaction).
   --input <token>        Scripted interaction, repeatable, applied in order THROUGH the browser terminal.
                          Literal text is typed; {Enter} {Tab} {Escape} {ArrowDown} {Ctrl+C} etc. are pressed as keys.
+                         {WheelUp} and {WheelDown} send real browser mouse-wheel input over the xterm viewport.
+                         {CtrlSlashByte} and {Ctrl7Byte} send their shared exact terminal control byte.
   --cwd <path>           Working directory for --command. Default: current directory.
   --cols <n> / --rows <n>  Terminal geometry. Default: 120 x 32.
   --dwell-ms <n>         Milliseconds to let the TUI settle after input before capture. Default: 1500.

package/script/qa/xterm-live-terminal.mjs

@@ -80,10 +80,26 @@ const NAMED_KEYS = new Set([
 // An `input` token wrapped in {Braces} is pressed as a named key; anything else
 // is typed literally. Both flow through the browser terminal (xterm onData ->
 // pty), so the interaction is genuinely driven in the web terminal.
-async function driveInput(page, inputs, keyDelayMs) {
+export async function driveInput(page, inputs, keyDelayMs) {
   for (const raw of inputs) {
     const match = /^\{(.+)\}$/.exec(raw);
-    if (match && NAMED_KEYS.has(match[1])) {
+    if (
+      match?.[1] === "CtrlSlashByte" ||
+      match?.[1] === "Ctrl7Byte"
+    ) {
+      await page.evaluate((data) => window.__ptyInput(data), "\u001f");
+    } else if (match && /^(WheelUp|WheelDown)$/.test(match[1])) {
+      const terminal = await page.$(".xterm-screen");
+      const bounds = await terminal?.boundingBox();
+      if (!bounds) throw new Error("xterm viewport unavailable for wheel input");
+      await page.mouse.move(
+        bounds.x + bounds.width / 2,
+        bounds.y + bounds.height / 2,
+      );
+      await page.mouse.wheel({
+        deltaY: match[1] === "WheelDown" ? 720 : -720,
+      });
+    } else if (match && NAMED_KEYS.has(match[1])) {
       await page.keyboard.press(match[1] === "Space" ? " " : match[1], { delay: 15 });
     } else if (match && /^Ctrl\+(.)$/i.test(match[1])) {
       const key = /^Ctrl\+(.)$/i.exec(match[1])[1];

package/dist/config/schema/start-work.d.ts

@@ -1,5 +0,0 @@
-import { z } from "zod";
-export declare const StartWorkConfigSchema: z.ZodObject<{
-    auto_commit: z.ZodDefault<z.ZodBoolean>;
-}, z.core.$strip>;
-export type StartWorkConfig = z.infer<typeof StartWorkConfigSchema>;

package/dist/features/builtin-commands/templates/start-work.d.ts

@@ -1 +0,0 @@
-export declare const START_WORK_TEMPLATE = "You are starting an Atlas work session.\n\n## ARGUMENTS\n\n- `/start-work [plan-name] [--worktree <path>] [--make-pr] [--ship]`\n  - `plan-name` (optional): name or partial match of the plan to start\n  - `--worktree <path>` (optional): absolute path to an existing git worktree to work in\n    - If specified and valid: hook pre-sets worktree_path in boulder.json\n    - If specified but invalid: you must run `git worktree add <path> <branch>` first\n    - If omitted: work directly in the current project directory (no worktree)\n  - `--make-pr` (optional): deliver the work as a pull request. IMPLIES worktree mode - when `--worktree` is omitted, create a task-owned worktree before implementation. On completion push the branch, open a reviewer-readable PR, and hand off with the PR URL (merge only on explicit user ask)\n  - `--ship` (optional): full delivery lifecycle; implies `--make-pr`. After the PR opens, keep working until it is MERGED (CI + review gates, feedback addressed), then clean up the worktree and sync `.omo/` state back\n\n## WHAT TO DO\n\n1. **Find available plans**: Search for Prometheus-generated plan files at `.omo/plans/`\n\n2. **Check for active boulder state**: Read `.omo/boulder.json` if it exists\n\n3. **Decision logic**:\n   - If multiple active works are listed in your context:\n     - This means boulder.json has more than one work with status: `active` or `paused`\n     - Use the Question tool to ask the user which plan to resume\n     - Resume by running `/start-work {plan-name}` for the selected plan\n     - If the user says \"start a new plan\", continue with cold-start auto-selection logic\n   - If exactly one active work is listed and the user did not name a plan:\n     - Auto-resume that single active work\n   - If no active plan OR plan is complete:\n     - List available plan files\n     - If ONE plan: auto-select it\n     - If MULTIPLE plans: show list with timestamps, ask user to select\n\n4. **Worktree Setup** (ONLY when `--worktree` was explicitly specified and `worktree_path` not already set in boulder.json):\n   1. `git worktree list --porcelain` - see available worktrees\n   2. Create: `git worktree add <absolute-path> <branch-or-HEAD>`\n   3. Update boulder.json to add `\"worktree_path\": \"<absolute-path>\"`\n   4. All work happens inside that worktree directory\n\n5. **Create/Update boulder.json**:\n   ```json\n   {\n     \"active_plan\": \"/absolute/path/to/plan.md\",\n     \"started_at\": \"ISO_TIMESTAMP\",\n     \"session_ids\": [\"session_id_1\", \"session_id_2\"],\n     \"plan_name\": \"plan-name\",\n     \"worktree_path\": \"/absolute/path/to/git/worktree\"\n   }\n   ```\n\n6. **Read the plan file** and start executing tasks according to atlas workflow\n\n## OUTPUT FORMAT\n\nWhen listing plans for selection:\n```\nAvailable Work Plans\n\nCurrent Time: {ISO timestamp}\nSession ID: {current session id}\n\n1. [plan-name-1.md] - Modified: {date} - Progress: 3/10 tasks\n2. [plan-name-2.md] - Modified: {date} - Progress: 0/5 tasks\n\nWhich plan would you like to work on? (Enter number or plan name)\n```\n\nWhen resuming existing work:\n```\nResuming Work Session\n\nActive Plan: {plan-name}\nProgress: {completed}/{total} tasks\nSessions: {count} (appending current session)\nWorktree: {worktree_path}\n\nReading plan and continuing from last incomplete task...\n```\n\nWhen auto-selecting single plan:\n```\nStarting Work Session\n\nPlan: {plan-name}\nSession ID: {session_id}\nStarted: {timestamp}\nWorktree: {worktree_path}\n\nReading plan and beginning execution...\n```\n\n## CRITICAL\n\n- The session_id is injected by the hook - use it directly\n- Always update boulder.json BEFORE starting work\n- If worktree_path is set in boulder.json, all work happens inside that worktree directory\n- Read the FULL plan file before delegating any tasks\n- Follow atlas delegation protocols (7-section format)\n\n## GOAL + TASK BREAKDOWN (MANDATORY)\n\nDo BOTH of these immediately after reading the plan file, BEFORE starting any work. Skipping either is a defect.\n\n**1. Set the goal, in detail.** When a goal tool is available (`create_goal`), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase/task counts, the delivery mode (direct, `--make-pr`, or `--ship`), and how completion will be verified. One work session = one goal. No goal tool -> record the same objective as the first `.omo/start-work/ledger.jsonl` entry.\n\n**2. Register every phase and task as todos.** Decompose every plan task into granular, implementation-level sub-steps and register ALL of them as task/todo items, grouped phase by phase (one phase per plan wave), BEFORE starting any work. Keep them current at every moment: mark in_progress when work dispatches and done immediately after its verification passes - never batch-complete at the end, never execute work that is not a registered todo. Discovered work is appended as a todo before it runs.\n\n**How to break down**:\n- Each plan checkbox item (e.g., `- [ ] Add user authentication`) must be split into concrete, actionable sub-tasks\n- Sub-tasks should be specific enough that each one touches a clear set of files/functions\n- Include: file to modify, what to change, expected behavior, and how to verify\n- Do NOT leave any task vague - \"implement feature X\" is NOT acceptable; \"add validateToken() to src/auth/middleware.ts that checks JWT expiry and returns 401\" IS acceptable\n\n**Example breakdown**:\nPlan task: `- [ ] Add rate limiting to API`\n\u2192 Todo items:\n  1. Create `src/middleware/rate-limiter.ts` with sliding window algorithm (max 100 req/min per IP)\n  2. Add RateLimiter middleware to `src/app.ts` router chain, before auth middleware\n  3. Add rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining) to response in `rate-limiter.ts`\n  4. Add test: verify 429 response after exceeding limit in `src/middleware/rate-limiter.test.ts`\n  5. Add test: verify headers are present on normal responses\n\nRegister these as task/todo items so progress is tracked and visible throughout the session.\n\n## WORKTREE COMPLETION\n\nWhen working in a worktree (`worktree_path` is set in boulder.json) and ALL plan tasks are complete:\n1. Commit all remaining changes in the worktree\n2. **Sync .omo state back**: Copy `.omo/` from the worktree to the main repo before removal.\n   This is CRITICAL when `.omo/` is gitignored - state written during worktree execution would otherwise be lost.\n   ```bash\n   cp -r <worktree-path>/.omo/* <main-repo>/.omo/ 2>/dev/null || true\n   ```\n3. Switch to the main working directory (the original repo, NOT the worktree)\n4. Merge the worktree branch into the current branch: `git merge <worktree-branch>`\n5. If merge succeeds, clean up: `git worktree remove <worktree-path>`\n6. Remove the boulder.json state\n\nThis is the DEFAULT behavior when `--worktree` was used alone. When `--make-pr` or `--ship` is active, skip the local merge and follow the PR Delivery Mode instructions in the session context instead: push the branch and open a PR (`--make-pr` hands off with the PR URL; `--ship` keeps working until the PR is merged), then clean up. Otherwise skip merge only if the user explicitly instructs otherwise (e.g., asks to create a PR instead).";

package/dist/hooks/start-work/start-work-hook.d.ts

@@ -1,23 +0,0 @@
-import type { PluginInput } from "@opencode-ai/plugin";
-export declare const HOOK_NAME: "start-work";
-interface StartWorkHookInput {
-    sessionID: string;
-    messageID?: string;
-}
-interface StartWorkCommandExecuteBeforeInput {
-    sessionID: string;
-    command: string;
-    arguments: string;
-}
-interface StartWorkHookOutput {
-    message?: Record<string, unknown>;
-    parts: Array<{
-        type: string;
-        text?: string;
-    }>;
-}
-export declare function createStartWorkHook(ctx: PluginInput): {
-    "chat.message": (input: StartWorkHookInput, output: StartWorkHookOutput) => Promise<void>;
-    "command.execute.before": (input: StartWorkCommandExecuteBeforeInput, output: StartWorkHookOutput) => Promise<void>;
-};
-export {};

package/dist/plugin/chat-message/start-work-message.d.ts

@@ -1,5 +0,0 @@
-import type { ChatMessageHooks, ChatMessageInput, ChatMessageHandlerOutput, StartWorkHookOutput, WorkStartingCommand } from "./types";
-export declare function isStartWorkHookOutput(value: unknown): value is StartWorkHookOutput;
-export declare function isStartWorkFallbackTemplate(promptText: string): boolean;
-export declare function clearStoppedContinuationBeforeWorkStart(hooks: ChatMessageHooks, sessionID: string, command: WorkStartingCommand): void;
-export declare function runStartWorkHookIfApplicable(hooks: ChatMessageHooks, input: ChatMessageInput, output: ChatMessageHandlerOutput): Promise<void>;

package/dist/skills/data-scientist/references/common-scenarios.md

@@ -1,176 +0,0 @@
-# Common Scenarios with Tool Selection
-
-## Scenario 1: Simple Calculation
-
-**Decision: Python (always)**
-
-```python
-uv run --with numpy python -c "
-import numpy as np
-result = np.sum([1, 2, 3, 4, 5])
-print(f'Result: {result}')
-"
-```
-
-## Scenario 2: CSV Quick Analysis
-
-**Decision: DuckDB (direct query, no memory load)**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-result = duckdb.sql('''
-    SELECT * FROM 'data.csv'
-    LIMIT 10
-''').pl()
-print(result)
-"
-```
-
-## Scenario 3: Filter + Sort on Large Dataset
-
-**Decision: Polars (128x faster filtering, 12x faster sorting)**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-result = (
-    pl.scan_csv('large.csv')
-    .filter(pl.col('value') > 1000)
-    .sort('value', descending=True)
-    .head(100)
-    .collect()
-)
-print(result)
-"
-```
-
-## Scenario 4: Multi-Table Join + Aggregation
-
-**Decision: DuckDB (best for joins and aggregations)**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-result = duckdb.sql('''
-    SELECT
-        a.category,
-        COUNT(*) as count,
-        SUM(b.amount) as total
-    FROM 'table1.csv' a
-    JOIN 'table2.csv' b ON a.id = b.id
-    GROUP BY a.category
-    ORDER BY total DESC
-''').pl()
-print(result)
-"
-```
-
-## Scenario 5: Data Exploration
-
-**Decision: DuckDB for quick exploration**
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-
-# Show first few rows
-print('**Sample Data**')
-print(duckdb.sql('SELECT * FROM \"data.csv\" LIMIT 5').pl())
-
-# Show summary statistics
-print('\\n**Summary Statistics**')
-print(duckdb.sql('DESCRIBE SELECT * FROM \"data.csv\"').pl())
-
-# Show row count
-print('\\n**Row Count**')
-print(duckdb.sql('SELECT COUNT(*) as total_rows FROM \"data.csv\"').pl())
-"
-```
-
-## Scenario 6: Time-Series Analysis
-
-**Decision: DuckDB for aggregation + matplotlib for visualization**
-
-```python
-uv run --with numpy --with duckdb --with pyarrow --with matplotlib python -c "
-import duckdb
-import matplotlib.pyplot as plt
-
-# Aggregate by date
-result = duckdb.sql('''
-    SELECT
-        DATE_TRUNC('day', timestamp) as date,
-        COUNT(*) as count,
-        AVG(value) as avg_value
-    FROM 'timeseries.csv'
-    GROUP BY date
-    ORDER BY date
-''').pl()
-
-# Plot
-plt.figure(figsize=(12, 6))
-plt.subplot(2, 1, 1)
-plt.plot(result['date'], result['count'])
-plt.title('Daily Count')
-
-plt.subplot(2, 1, 2)
-plt.plot(result['date'], result['avg_value'])
-plt.title('Daily Average Value')
-
-plt.tight_layout()
-plt.savefig('timeseries.png')
-print('Saved to timeseries.png')
-"
-```
-
-## Scenario 7: Complex Transformation
-
-**Decision: Polars for efficient transformations**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-result = (
-    pl.scan_csv('data.csv')
-    .with_columns([
-        # Create new calculated columns
-        (pl.col('price') * pl.col('quantity')).alias('total'),
-        pl.col('date').str.strptime(pl.Date, '%Y-%m-%d').alias('parsed_date'),
-        pl.col('name').str.to_uppercase().alias('upper_name'),
-    ])
-    .filter(pl.col('total') > 100)
-    .select(['parsed_date', 'upper_name', 'total'])
-    .collect()
-)
-
-print(result)
-"
-```
-
-## Scenario 8: Large File Processing
-
-**Decision: Polars streaming mode**
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Process file larger than RAM
-result = (
-    pl.scan_csv('huge_file.csv')
-    .filter(pl.col('active') == True)
-    .groupby('category')
-    .agg([
-        pl.count().alias('count'),
-        pl.sum('amount').alias('total'),
-        pl.mean('amount').alias('average'),
-    ])
-    .collect(streaming=True)  # Streaming mode
-)
-
-print(result)
-print(f'\\nProcessed {result[\"count\"].sum():,} rows')
-"
-```

package/dist/skills/data-scientist/references/execution-templates.md

@@ -1,197 +0,0 @@
-# Execution Templates
-
-## Template 1: DuckDB for Simple/Complex SQL Queries
-
-**Use when:**
-- Simple aggregation on single file
-- Complex multi-table joins
-- Heavy GROUP BY operations
-- Window functions with complex SQL logic
-- Ad-hoc exploration queries
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-
-# Simple query - direct file access
-result = duckdb.sql('''
-    SELECT
-        category,
-        COUNT(*) as count,
-        AVG(amount) as avg_amount,
-        SUM(amount) as total
-    FROM 'data.csv'
-    WHERE date >= '2024-01-01'
-    GROUP BY category
-    ORDER BY total DESC
-    LIMIT 10
-''').pl()
-
-print('**Results**')
-print(result)
-print(f'\\nProcessed {len(result)} categories')
-"
-```
-
-## Template 2: Polars for Filtering & Sorting
-
-**Use when:**
-- Primary operation is filtering large dataset
-- Sorting required
-- Chain transformations
-- Memory-efficient processing needed
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Lazy evaluation for optimal performance
-result = (
-    pl.scan_csv('data.csv')  # Lazy scan
-    .filter(
-        (pl.col('amount') > 1000) &
-        (pl.col('status') == 'active') &
-        (pl.col('date') >= '2024-01-01')
-    )
-    .sort('amount', descending=True)
-    .head(100)
-    .collect()  # Execute optimized plan
-)
-
-print('**Filtered and Sorted Results**')
-print(result)
-print(f'\\nFound {len(result)} matching rows')
-"
-```
-
-## Template 3: Hybrid Approach (Best of Both)
-
-**Use when:**
-- Need joins AND heavy filtering
-- Complex SQL followed by transformations
-- Optimize different operation stages
-
-```python
-uv run --with numpy --with duckdb --with polars --with pyarrow python -c "
-import duckdb
-import polars as pl
-
-print('Phase 1: DuckDB for complex join (3x faster)')
-# DuckDB excels at joins
-joined = duckdb.sql('''
-    SELECT
-        o.order_id,
-        o.amount,
-        c.customer_id,
-        c.region,
-        p.category
-    FROM 'orders.csv' o
-    JOIN 'customers.csv' c ON o.customer_id = c.customer_id
-    JOIN 'products.csv' p ON o.product_id = p.product_id
-    WHERE o.date >= '2024-01-01'
-''').pl()  # Convert to Polars
-
-print(f'Joined {len(joined):,} rows')
-
-print('\\nPhase 2: Polars for ultra-fast filtering (128x faster)')
-# Polars excels at filtering
-filtered = (
-    joined
-    .filter(
-        (pl.col('amount') > 100) &
-        (pl.col('region').is_in(['North', 'South', 'East']))
-    )
-    .with_columns([
-        (pl.col('amount') * 1.1).alias('amount_with_tax')
-    ])
-)
-
-print(f'Filtered to {len(filtered):,} rows')
-
-print('\\nPhase 3: DuckDB for final aggregation (4x faster)')
-# Back to DuckDB for aggregation
-duckdb.register('filtered_data', filtered)
-final = duckdb.sql('''
-    SELECT
-        region,
-        category,
-        COUNT(DISTINCT customer_id) as customers,
-        SUM(amount_with_tax) as total_revenue,
-        AVG(amount_with_tax) as avg_transaction
-    FROM filtered_data
-    GROUP BY region, category
-    HAVING total_revenue > 10000
-    ORDER BY total_revenue DESC
-''').pl()
-
-print('\\n**Final Results**')
-print(final)
-"
-```
-
-## Template 4: Polars Streaming for Large Files
-
-**Use when:**
-- Dataset larger than available RAM
-- Need to process data in batches
-- Memory constraints
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Streaming mode - processes data in chunks
-result = (
-    pl.scan_csv('huge_file.csv')
-    .filter(pl.col('status') == 'active')
-    .with_columns([
-        (pl.col('amount') * 1.1).alias('adjusted_amount')
-    ])
-    .groupby('category')
-    .agg([
-        pl.sum('adjusted_amount').alias('total'),
-        pl.count().alias('count')
-    ])
-    .collect(streaming=True)  # Streaming mode for large data
-)
-
-print('**Streaming Results**')
-print(result)
-print(f'\\nProcessed {result[\"count\"].sum():,} total rows')
-"
-```
-
-## Template 5: Visualization with Matplotlib
-
-**Use when:**
-- User requests charts, graphs, or plots
-- Exploratory data analysis (EDA)
-- Time-series or distribution analysis
-
-```python
-uv run --with numpy --with duckdb --with polars --with pyarrow --with matplotlib python -c "
-import duckdb
-import matplotlib.pyplot as plt
-
-# Query data
-result = duckdb.sql('''
-    SELECT
-        date,
-        SUM(amount) as total
-    FROM 'data.csv'
-    GROUP BY date
-    ORDER BY date
-''').pl()
-
-# Create visualization
-plt.figure(figsize=(10, 6))
-plt.plot(result['date'], result['total'])
-plt.xlabel('Date')
-plt.ylabel('Total Amount')
-plt.title('Daily Total Trends')
-plt.xticks(rotation=45)
-plt.tight_layout()
-plt.savefig('output.png')
-print('Chart saved to output.png')
-"
-```