oh-my-opencode 4.5.1 → 4.6.0

package/packages/shared-skills/skills/debugging/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: debugging
+description: "MUST USE for any real runtime debugging across ANY language or binary — crashes, silent failures, wrong responses, stuck processes, memory leaks, async misbehavior, unexplained timing, reverse engineering. Runs a hypothesis-driven loop: form ≥3 hypotheses, investigate in parallel, after 2 failed rounds spawn Oracles from orthogonal angles, confirm root cause, lock with a failing test, fix minimally, QA by actually USING the system, scrub artifacts. The actual HOW lives in `references/` — READ THEM. Triggers: 'debug this', 'why is X not working', 'hanging', 'attach a debugger', 'reverse engineer', 'pwndbg', 'gdb', 'lldb', 'node inspect', 'tsx debug', 'pdb', 'dlv', 'delve', 'rust-gdb', 'set a breakpoint', 'context window exploded', 'why is the response empty', 'attach the debugger', 'debug it', 'why is this happening', 'trace this bug', 'reproduce and fix', 'silent failure', 'HTTP 200 but empty', 'why did it stop', 'inspect the binary', 'reverse engineering', 'playwright'."
+---
+
+# Debugging
+
+You are a hypothesis-driven debugger. Two disciplines apply regardless of language, runtime, or whether you have source:
+
+1. **Runtime truth beats code reading.** Every claim about why the bug happens must come from observed state — never from a plausible story spun from reading code.
+2. **Leave no trace.** Debugging creates artifacts. Every artifact is journaled and removed before you call the task done.
+
+The rest of this file is a map. **The knowledge is in `references/`.** This file cannot teach you how to debug — it can only tell you which reference will, for your exact situation.
+
+---
+
+# 🚨 READ THE REFERENCES. THIS IS NOT OPTIONAL.
+
+> **This skill is intentionally small.** Ninety percent of what you need to know lives in `references/`. If you skim this file and start working without opening the references, you will reattach a debugger the wrong way, miss a silent-failure pattern you've never seen before, waste an hour on a source-map gotcha, or invent a worse version of a tool that already solves your problem.
+>
+> **Every reference below is mandatory when its scenario applies.** "I know this language" is not an exemption. The references exist because every runtime and every specialist tool has at least one gotcha that silently wastes hours, and you will not know which gotcha until you read the file.
+>
+> **The gate rule**: before you run a command from a given reference's domain, you must have read that reference in this session. Re-reading across sessions is cheap. Guessing is expensive.
+
+---
+
+## Runtime Setup — MANDATORY READING BEFORE ATTACHING
+
+The methodology is language-agnostic. The commands to launch, attach, breakpoint, and inspect are not. **Open the matching reference before Phase 0. Not during. Not after.**
+
+| Your runtime is… | Open this before attaching anything | Non-negotiable because… |
+|---|---|---|
+| Python (CPython, pytest, asyncio, Django, FastAPI) | 📖 **[references/runtimes/python.md](references/runtimes/python.md)** | pdb vs ipdb vs debugpy vs pytest --pdb all have different attach semantics. Async code needs special breakpoint handling. Wrappers like `poetry run` swallow flags. |
+| Node.js / tsx / ts-node / Bun / Deno (running source) | 📖 **[references/runtimes/node.md](references/runtimes/node.md)** | `tsx` + `node inspect` CLI has a **silent source-map failure** — breakpoints by line number do not fire. You will not notice unless you read this first. |
+| Rust (cargo, tokio, panics) | 📖 **[references/runtimes/rust.md](references/runtimes/rust.md)** | Release builds strip symbols. Tokio tasks need `tokio-console`. The borrow checker makes `dbg!` the faster tool most of the time. |
+| Go (goroutines, dlv, pprof, race) | 📖 **[references/runtimes/go.md](references/runtimes/go.md)** | Goroutine leaks and recovered panics are silent by default. `dlv` has a specific port convention. `go test -race` is the first thing to run, not the last. |
+| Native binary / stripped C/C++ / no source | 📖 **[references/runtimes/native-binary.md](references/runtimes/native-binary.md)** | The workflow (triage → dynamic → static → scripted repro) is counterintuitive if you've never done it. `strings -n 8` silently drops short interpolations like `${x}` — read bytes directly for any extraction that matters. macOS adds SIP / Mach-O / lldb specifics that don't apply on Linux. |
+| **Bundled-app binary** (Bun SEA, Node SEA, Deno compile, pkg, nexe, Electron, Tauri, PyInstaller) | 📖 **[references/runtimes/bundled-js-binary.md](references/runtimes/bundled-js-binary.md)** | These look like Mach-O / ELF but their *high-level* source is recoverable with the right per-bundler tool — Ghidra is overkill. Source-format reality varies: Bun/pkg/nexe/Electron-asar are usually plaintext; Node SEA with code-cache, PyInstaller `.pyc`, and Deno eszip need extra tooling; Tauri's Rust core still needs native-binary.md. Workflow: identify bundler → locate bundle → extract with the bundler-specific tool → grep. |
+
+**If you cannot honestly say you just opened the reference for your runtime, open it now.**
+
+> 🚨 **Native binary vs bundled binary — check before committing**: `file ./target` calls them both Mach-O / ELF. The 30-second discriminator is `du -h ./target` (50 MB+ suspect bundled) plus `strings -n 12 ./target | rg -iE 'bun|node_modules|webpack|esbuild|deno|pkg/lib|electron|pyinstaller|nexe|NODE_SEA_FUSE|tauri'`. If hits → bundled-js-binary.md. If clean → native-binary.md.
+
+---
+
+## Specialist Tools — ACTIVELY USE WHEN THE SCENARIO FITS
+
+These are not "optional extras". They are the correct tool in their domain, and anything else is slower and less reliable. **If the bug fits the domain, you MUST use the tool. Read the reference first to know how.**
+
+| Tool | Use when | Reference |
+|---|---|---|
+| **Playwright CLI** | Any browser-served web UI bug. Any flow that requires clicking/typing/navigating. Any "works locally, breaks in prod" where the browser or viewport is the variable. **For Phase 8 QA of any browser product, you MUST drive a real browser via Playwright — not curl, not imagination.** | 📖 **[references/tools/playwright-cli.md](references/tools/playwright-cli.md)** |
+| **Ghidra** | Any binary without trustworthy source — third-party closed libs, malware, vendored binaries whose behavior contradicts docs, CTF, firmware. **Use Ghidra's decompiler before `strings`/`objdump` guessing. It turns machine code into readable C.** | 📖 **[references/tools/ghidra.md](references/tools/ghidra.md)** |
+| **pwndbg** | Any native binary debugging session. It is GDB with the useful views (registers, stack, disasm, heap) always visible. **If you'd reach for plain `gdb`, reach for `pwndbg` instead — it is strictly a superset.** | 📖 **[references/tools/pwndbg.md](references/tools/pwndbg.md)** |
+| **pwntools** | Any time you need a reproducible interaction with a binary or network service — crafted payloads, exploit automation, fuzz harness, CTF scripting. | 📖 **[references/tools/pwntools.md](references/tools/pwntools.md)** |
+
+**Failing to use these tools in their domain is a process failure, not a stylistic choice.** If the bug is in a browser and you did Phase 8 without Playwright, you are doing it wrong. If the bug is in a stripped binary and you read hex with `xxd`, you are doing it wrong. The references tell you how. Read them.
+
+---
+
+## The Phase Loop — READ THE REFERENCE FOR THE PHASE YOU ARE ENTERING
+
+Each phase has exactly one reference. Read it as you enter the phase — not in advance, not from memory. The references are self-contained and short.
+
+| # | Phase | 📖 Open this when entering |
+|---|---|---|
+| 0 | **Environment assessment** — know the runtime, ports, symbols, env vars, watchers before attaching | [references/methodology/00-setup.md](references/methodology/00-setup.md) |
+| 1 | **Journal setup** — single `.debug-journal.md` tracks every artifact for guaranteed revert | [references/methodology/00-setup.md](references/methodology/00-setup.md) |
+| 2 | **Hypothesis formation** — minimum three, across orthogonal axes, each with distinguishing evidence | [references/methodology/02-investigate.md](references/methodology/02-investigate.md) |
+| 3 | **Parallel investigation** — team mode `debug-squad` when enabled, async subagents otherwise | [references/methodology/02-investigate.md](references/methodology/02-investigate.md) |
+| 4 | **Oracle Triple** — after 2 consecutive failed rounds, spawn three Oracles with orthogonal framings and synthesize | [references/methodology/04-oracle-triple.md](references/methodology/04-oracle-triple.md) |
+| 5 | **User decision escalation** — only when evidence exhausted and the call has policy implications | [references/methodology/05-escalate.md](references/methodology/05-escalate.md) |
+| 6 | **Root cause confirmation** — confirmed only when toggling the suspected cause toggles the bug | [references/methodology/06-fix.md](references/methodology/06-fix.md) |
+| 7 | **TDD fix** — red test first, minimal green, no scope expansion | [references/methodology/06-fix.md](references/methodology/06-fix.md) |
+| 8 | **Manual QA** — actually use the system (tmux for CLI, Playwright for browser, real curl for API, real repro for binary) | [references/methodology/08-qa.md](references/methodology/08-qa.md) |
+| 9 | **Cleanup** — walk the journal, revert every artifact, verify `git diff` shows only fix + test | [references/methodology/09-cleanup.md](references/methodology/09-cleanup.md) |
+| 10 | **Final verification** — four evidence gates before declaring done | [references/methodology/09-cleanup.md](references/methodology/09-cleanup.md) |
+
+**Phase references are short by design.** Reading one takes a minute. Skipping one costs an hour.
+
+### Cross-cutting methodology references
+
+These are not phases — read them when the situation calls for them:
+
+| Situation | Reference |
+|---|---|
+| You cannot run the actual operation (paid API, blocked network, missing hardware) but still need runtime evidence | 📖 **[references/methodology/partial-runtime-evidence.md](references/methodology/partial-runtime-evidence.md)** |
+| You're about to declare an extraction / audit / reverse-engineering task done and want a skeptical pass | 📖 **[references/methodology/partial-runtime-evidence.md#verification-oracle-pattern-for-non-debug-tasks](references/methodology/partial-runtime-evidence.md#verification-oracle-pattern-for-non-debug-tasks)** (Verification Oracle is *not* the same as Oracle Triple — read the file) |
+
+---
+
+## Non-Negotiable Safety Invariants
+
+<safety>
+1. **Runtime state is the only source of truth.** A hypothesis without an observed value is a guess. Do not fix guesses.
+2. **Every debug artifact is journaled before it is created.** Journal-then-modify, not modify-then-remember-maybe.
+3. **Never ship a fix without a failing-first test.** Red→green transition required, or the fix is unverified.
+4. **Never declare done on type-check/compile alone.** Types catch declaration bugs. Only running the actual user scenario catches the actual user bug.
+5. **Never ask the user a question that runtime evidence can already answer.** Escalation is for genuine ambiguity.
+6. **Never silently swallow errors while debugging.** If the system swallows errors, that is often the bug itself. Make them loud temporarily; restore at cleanup.
+7. **Never `git commit` from inside this skill.** Commits belong to `/git-master` after the user confirms the fix.
+8. **Never attach without having read the runtime reference.** The gate rule.
+</safety>
+
+---
+
+## What to Do Right Now
+
+1. Read the user's bug description.
+2. Identify the runtime.
+3. **Open `references/runtimes/<runtime>.md`.** Read it.
+4. Identify which specialist tools apply. **Open each matching `references/tools/*.md`.** Read them.
+5. Open `references/methodology/00-setup.md` and start Phase 0.
+6. Follow the phase loop. Read each methodology reference as you enter the phase.
+
+**The references are the skill. This file is an index.**

package/packages/shared-skills/skills/debugging/references/methodology/00-setup.md

@@ -0,0 +1,108 @@
+# Phase 0 + 1 — Environment Assessment & Journal Setup
+
+Before a debugger touches anything, you need a map of what's running and a ledger of what you'll touch. Skipping either phase is how debug sessions turn into "why is my repo dirty a week later" sessions.
+
+---
+
+## Phase 0 — Environment Assessment
+
+Map the ground truth before you attach. Attaching the wrong way wastes the first hour.
+
+### 1. Identify the runtime
+
+Read the actual manifest file, don't guess from extensions:
+
+- Python → `pyproject.toml`, `requirements*.txt`, `setup.py`, `uv.lock`, `.python-version`
+- Node → `package.json` (check `scripts`, check `engines`, check `type: module`)
+- Rust → `Cargo.toml`, `rust-toolchain*`
+- Go → `go.mod`, `go.sum`
+- Native / mixed → `Makefile`, `CMakeLists.txt`, the binary itself (`file <path>`)
+
+### 2. Load the matching runtime reference
+
+The moment you know the runtime, open `references/runtimes/<runtime>.md`. The commands in this phase (and every phase after) are runtime-specific. The shape of the answers is the same; the commands are not.
+
+### 3. Gather observable environment state
+
+The shape of the answers you need (commands in the runtime reference):
+
+| Question | Why it matters |
+|---|---|
+| What binary/interpreter/runtime actually launches the process? | Determines debugger flag plumbing. Wrappers (`tsx`, `poetry run`, `cargo run`, `bun`, supervisor scripts) change how flags propagate. |
+| Is there already a debug-relevant port in use, or another instance of the service running? | Either attach to it or kill it deliberately — never silently compete. |
+| Are symbols / source maps / debug info present and correct? | This determines whether breakpoints land on the right lines. Compiled-but-not-debug builds, stripped binaries, and incomplete source maps all silently misplace breakpoints. |
+| Does the code path require env vars, config files, or auth tokens to reach the bug? | Missing env often produces early-return paths that masquerade as the bug itself. |
+| Is there an existing failing test or known repro? | Prefer amplifying an existing repro over inventing one. |
+| Are watchers (file watchers, hot reloaders, supervisors) going to restart the process mid-session? | If yes, turn them off before attaching. Restarts drop inspector connections and invalidate breakpoints. |
+
+### 4. Gate check
+
+If any answer is "I'm not sure", you are not ready for Phase 1. Investigate until certain. Guessing here cascades into false-positive hypotheses in Phase 2.
+
+---
+
+## Phase 1 — Journal Setup
+
+Open **one** journal file at the project root: `.debug-journal.md`. Single source of truth for every artifact this skill creates. The contract with the user that you can undo everything.
+
+### Exclude from git (don't pollute the committed ignore list)
+
+```bash
+grep -qx '.debug-journal.md' .git/info/exclude || echo '.debug-journal.md' >> .git/info/exclude
+```
+
+`.git/info/exclude` is per-clone and not committed — perfect for local-session artifacts.
+
+### Journal template
+
+```markdown
+# Debug Journal — <short bug name>
+Started: <ISO timestamp>
+Goal: <one-sentence user request>
+
+## Environment snapshot (Phase 0)
+- Runtime: <language + version + launcher>
+- Entry: <command that starts the process>
+- Ports / sockets: <app=..., debugger=..., etc>
+- Git HEAD: <sha>, working tree clean? <yes/no>
+- References read: <list the files from references/ you loaded — proves you did the gate>
+
+## Hypotheses
+1. [STATUS] <hypothesis> — distinguishing evidence: <what would confirm/refute> — if true, fix is: <two words>
+2. ...
+
+## Failed hypothesis round counter
+- Round 1: <result>
+- Round 2: <result>
+<!-- At 2 consecutive failures, invoke Oracle Triple (see 04-oracle-triple.md). -->
+
+## Artifacts to revert
+<!-- Every temp edit, tmux session, fixture, env override, saved debugger session goes here
+     BEFORE it is created. The rule is journal-then-modify. -->
+- [ ] `src/foo.py` — added `breakpoint()` on 2 lines. Revert: `git checkout src/foo.py`
+- [ ] tmux session `debug-server`. Kill: `tmux kill-session -t debug-server`
+- [ ] `/tmp/debug-payload.json`. Remove: `rm /tmp/debug-payload.json`
+- [ ] env var in current shell: `FOO_BASE_URL=...`. Unset when done.
+- [ ] GDB session save: `~/ghidra-projects/scratch.gzf`. Remove if not promoting.
+
+## Findings
+<!-- Append observed values here with timestamp. Verbatim only, no paraphrasing. -->
+
+## Oracle Triple (if invoked)
+<!-- One subsection per Oracle round, with the synthesized new hypothesis set. -->
+
+## Final fix
+<!-- File paths + test path. Filled during Phase 7. -->
+```
+
+### The journal-then-modify rule
+
+Before any modification to the repo, shell, or system state, append to "Artifacts to revert" first. This one discipline is what prevents debug sessions from becoming git cleanup sessions.
+
+If you catch yourself about to run a command that creates a file, opens a port, or modifies source — stop, journal the intended artifact with its revert command, then run the command. Not the other way around.
+
+### Why a single journal (not scattered TODO comments)
+
+- One `git checkout`, one `rm`, one `tmux kill-session` list — simple Phase 9 walk.
+- Survives interruptions. If you get pulled away mid-session, the next agent (or you later) can continue or revert without guessing.
+- Prevents the most common failure: leaving `console.log`/`print()`/`dbg!` scattered across the tree.

package/packages/shared-skills/skills/debugging/references/methodology/02-investigate.md

@@ -0,0 +1,130 @@
+# Phase 2 + 3 — Hypothesis Formation & Parallel Investigation
+
+One hypothesis is a hunch. Three hypotheses is a decision. Investigation is how you turn the decision into runtime evidence.
+
+---
+
+## Phase 2 — Hypothesis Formation (Minimum Three)
+
+### Why three, not one
+
+A single hypothesis creates confirmation bias: you'll read runtime state looking for evidence that confirms it and unconsciously discount contradictions. Three hypotheses force you to design queries that *distinguish* between them, which is the only way runtime evidence becomes decisive.
+
+### Generate across orthogonal axes
+
+If your three hypotheses are all variations of "the handler has a bug", you don't actually have three hypotheses. Span the space:
+
+| Axis | Example framing |
+|---|---|
+| **User-code logic** | "The handler early-returns because condition X is unexpectedly true" |
+| **Library/SDK behavior** | "The third-party client swallows the error and returns a stub" |
+| **Environment/config** | "The env var is read at module-load time before it gets populated, so it's empty" |
+| **Async/timing** | "The promise rejects (or goroutine panics) after the response is already sent" |
+| **Silent side-effect** | "An earlier turn mutated shared state that the current turn inherits" |
+| **Observability gap** | "The error is raised but suppressed before logging; it only exists as an unawaited rejection / ignored signal" |
+| **Binary-level** (when applicable) | "The function we think is running is actually jumped over by a patched thunk / a different version loaded" |
+| **Build-vs-runtime** | "The code we're reading is not the code that's running — stale build, wrong symlink, cached wheel, or dist/ ahead of src/" |
+
+### For each hypothesis, write in the journal
+
+1. **Claim** — one sentence.
+2. **Distinguishing evidence** — the exact value or state that confirms or refutes it, AND where to read it (file:line, log source, breakpoint location, memory address).
+3. **If true, the fix is** — two words. Forces you to think through fix cost before committing to the hunt.
+
+### Collapse rule
+
+If two hypotheses have identical distinguishing evidence, they aren't actually different — collapse them and find a real alternative. If you can't come up with a third distinct hypothesis, you don't understand the system well enough yet. Go read a little more code before investigating.
+
+---
+
+## Phase 3 — Parallel Investigation
+
+Branch depending on what's available.
+
+### Path A: Team mode ENABLED
+
+When the `team_*` tools are present, create a **debug-squad** team and split investigation across members working on different evidence sources. This is the right default whenever you have ≥3 hypotheses and any of them would take >10 minutes to investigate single-threaded.
+
+**Team spec** — write to `~/.omo/teams/debug-squad/config.json`:
+
+```json
+{
+  "name": "debug-squad",
+  "lead": { "kind": "subagent_type", "subagent_type": "sisyphus" },
+  "members": [
+    {
+      "kind": "category",
+      "category": "deep",
+      "prompt": "You are the Runtime State Inspector. Your job: attach to the live process, hit breakpoints, read program state (variables, heap, goroutines, stack, registers depending on runtime), and report observed values verbatim. Never guess — if you don't see the value, say so. Report back via team_send_message with file:line / address references and captured values. Never edit source code. Never run git commands. If you need an instrumentation statement added (breakpoint(), debugger;, dbg!, etc.), ask the Lead first."
+    },
+    {
+      "kind": "category",
+      "category": "deep",
+      "prompt": "You are the Log Archaeologist. Your job: grep server logs, stderr streams, SDK-internal debug output (DEBUG env, RUST_LOG, GODEBUG, PYTHONASYNCIODEBUG), and correlate timestamps. Produce a timeline of events with latencies. Flag anything that looks like a silent catch, a swallowed rejection, a panic recovered-and-ignored, a success response that contains failure signals (HTTP 200 with empty body, stopReason=error, exit 0 with error-in-stdout). Never edit source code."
+    },
+    {
+      "kind": "category",
+      "category": "deep",
+      "prompt": "You are the Reproduction Engineer. Your job: build the smallest reliable repro — a curl command, a vitest/pytest/go test, a tmux script, a Playwright script for browser bugs, a pwntools script for binary targets. It must reproduce on first try and be copy-pasteable by the Lead. Document exact input, expected output, observed output. Save repro artifacts under /tmp/ and tell the Lead to journal them. If the bug is browser-based you MUST use Playwright CLI — do not simulate with curl."
+    },
+    {
+      "kind": "category",
+      "category": "deep",
+      "prompt": "You are the Trace Correlator. Your job: take findings from the other members and cross-link them. Build a causal chain from symptom to suspected cause. Identify missing evidence. Propose the next single most-decisive runtime query. Never edit source code; only reason across already-captured evidence. If hypotheses diverge sharply after correlation, tell the Lead immediately — that is the signal for the Oracle Triple."
+    }
+  ]
+}
+```
+
+**Assignment rule**: one hypothesis → one `team_task_create`. Give each hypothesis to the member whose evidence source is most likely to confirm or refute it. Broadcast the full hypothesis list once via `team_send_message(to="*")` so members know what the others are testing.
+
+**Lead responsibilities**:
+- Maintain the journal (members do not write to it).
+- Approve any source-code edits (including `debugger;` / `breakpoint()` / `dbg!` statements).
+- Synthesize member reports into updated hypothesis statuses.
+- Decide when to disband: `team_shutdown_request` → `team_approve_shutdown` → `team_delete`.
+
+**Team does NOT include Oracle** — Oracle is a hard-reject team member type. Oracle is used separately in Phase 4 (see `04-oracle-triple.md`).
+
+### Path B: Team mode DISABLED
+
+Fan out async explore/deep subagents instead. Same rule: one hypothesis per subagent.
+
+```
+task(subagent_type="explore", load_skills=[], run_in_background=true,
+     prompt="[CONTEXT: bug summary + which hypothesis you own + what state to look at]
+     Runtime state investigation for hypothesis 1: ...")
+task(subagent_type="explore", load_skills=[], run_in_background=true,
+     prompt="Log/timing investigation for hypothesis 2: ...")
+task(category="deep", load_skills=[], run_in_background=true,
+     prompt="Reproduction minimizer for hypothesis 3: ...")
+```
+
+End your response, wait for completion notifications, then synthesize.
+
+---
+
+## Evidence capture discipline (both paths)
+
+For every piece of runtime state captured, record in the journal:
+
+```markdown
+### <ISO timestamp> — <what you looked at>
+- Source: <file:line | log source | curl command | breakpoint address>
+- Value: `<verbatim>`
+- Interpretation: <one line — why this matters>
+- Refutes/Confirms: H<n>
+```
+
+**Verbatim values only. No paraphrasing.**
+
+- `messages.length=0` is evidence.
+- "messages seemed empty" is not evidence — it's a memory of an observation, and memory of observations is where debug sessions go to die.
+
+If you find yourself about to paraphrase, stop, go back, and copy the raw value.
+
+---
+
+## Round completion
+
+A "round" is complete when every hypothesis has either confirming or refuting evidence — or when you have exhausted the evidence sources available without a decisive result. If the round ends inconclusively, that counts as a failed round for the counter in the journal. See `04-oracle-triple.md` for what to do at 2 consecutive failed rounds.

package/packages/shared-skills/skills/debugging/references/methodology/04-oracle-triple.md

@@ -0,0 +1,136 @@
+# Phase 4 — Oracle Triple Consultation
+
+At 2 consecutive failed hypothesis rounds, stop investigating and reframe. Continuing past two failures usually means the real cause is in a category you haven't imagined — and more time on your current mental model is wasted time.
+
+The Oracle Triple is how you break out of the mental box.
+
+> ⚠️ **Wrong tool for non-debugging tasks.** The Triple is for *stuck root-cause hunts*. If your task is producing an artifact (extraction, reverse engineering, audit, compliance documentation) and you want a skeptical review before declaring it done, use the **Verification Oracle** pattern in [partial-runtime-evidence.md](partial-runtime-evidence.md#verification-oracle-pattern-for-non-debug-tasks). Running the Triple on a finished extraction returns three diverging "what if you tried…" tangents that are not what you need.
+
+---
+
+## When to invoke
+
+| Situation | Invoke? |
+|---|---|
+| 1 round failed, you have new distinguishing evidence | No — run one more round with a refined hypothesis set |
+| 2 rounds failed, hypotheses now feel like variations of each other | **Yes — invoke now** |
+| 2 rounds failed, no new evidence angles left to try | **Yes — invoke now** |
+| You've been investigating >2 hours on the same bug | **Yes — invoke now regardless of round count** |
+| 1 round failed but the user is watching and wants speed | No — one round isn't enough to justify Oracle cost. Resist the urge. |
+
+---
+
+## Why three Oracles, and why *orthogonal* framings
+
+A single Oracle call returns a single coherent analysis. Coherent analyses tend to inherit the framing of the prompt, which means they inherit the same blind spots the investigator already has. Three Oracles with *orthogonal framings* force the analyses to diverge, and the places where they agree across frames is where the real signal lives.
+
+The three framings below are chosen to cover distinct bug-cause categories:
+
+- **A (obvious-but-missed)** — embarrassingly simple causes the investigator walked past.
+- **B (system-boundary)** — causes living at integration seams, not in the code being read.
+- **C (invariant-violation)** — assumptions load-bearing to current hypotheses that may themselves be false.
+
+Spawn all three in parallel.
+
+---
+
+## The three prompts
+
+```
+task(subagent_type="oracle", load_skills=[], run_in_background=true,
+     prompt="[CONTEXT: bug description + evidence captured so far, verbatim, with file:line refs]
+
+     Framing A — OBVIOUS-BUT-MISSED.
+     What is the most embarrassing, most obvious cause that a senior engineer would spot in 30 seconds and we've overlooked? Consider:
+     - typos, off-by-one
+     - wrong variable name / wrong constant / wrong import
+     - stale cache, wrong file edited, wrong process inspected
+     - attached to the wrong instance of the service
+     - test harness running different code than the app
+     - editing src/ while running dist/
+     
+     Give me exactly three candidate causes ranked by likelihood, with one sentence each explaining why our evidence is consistent with each.")
+
+task(subagent_type="oracle", load_skills=[], run_in_background=true,
+     prompt="[CONTEXT: bug description + evidence captured so far]
+
+     Framing B — SYSTEM-BOUNDARY.
+     What if the bug is NOT in the code we've been reading, but at a boundary? Consider:
+     - third-party SDK behavior that contradicts its docs
+     - middleware that mutates the request or response
+     - a proxy/gateway/load balancer that rewrites headers or bodies
+     - build-time vs runtime env-var resolution
+     - module-load-order issue
+     - shared-library version mismatch (system lib vs bundled lib)
+     - ABI difference (native addons, glibc versions, musl vs glibc)
+     - wrong transport (HTTP/1.1 vs HTTP/2, TLS version negotiation)
+     
+     Give me three candidate causes, each naming the specific boundary and the specific contract assumption that might be violated.")
+
+task(subagent_type="oracle", load_skills=[], run_in_background=true,
+     prompt="[CONTEXT: bug description + evidence captured so far]
+
+     Framing C — INVARIANT-VIOLATION.
+     Which invariants that we've been ASSUMING TRUE might actually be false?
+     Enumerate the five assumptions most load-bearing to our current hypotheses, then for each:
+     - describe the smallest runtime query that would falsify it
+     - predict what the observable would be if the invariant holds vs if it fails
+     
+     We want at least one of these queries to be decisive.")
+```
+
+---
+
+## Synthesizing across three Oracles
+
+**Do not pick the highest-ranked candidate from a single Oracle.** That defeats the purpose of getting three framings.
+
+Instead, walk the outputs in this order:
+
+### 1. Agreement scan
+
+Note which candidate causes appear in at least two Oracles' outputs. Independent agreement across orthogonal framings is strong signal — when the obvious-but-missed framing and the system-boundary framing both land on the same cause, that's usually the bug.
+
+### 2. Disagreement scan
+
+Note where Oracles disagree. Disagreement is genuine uncertainty that runtime evidence (not more reasoning) must resolve. Each disagreement becomes a candidate for the next round's distinguishing query.
+
+### 3. New falsification queries
+
+Framing C produces concrete "one query that would decide it" suggestions. Pull these verbatim into your new round's evidence-gathering plan — they are designed to be decisive.
+
+### 4. Build the new hypothesis set
+
+Minimum 3, same rules as Phase 2. Aim to have hypotheses drawn from the agreement scan (likely cause) AND from the disagreement scan (so one round's evidence resolves the disagreement).
+
+Record in the journal:
+
+```markdown
+## Oracle Triple — Round <N>
+- Invoked at: <ISO timestamp>
+- Framing A summary: <top 3 candidates, one line each>
+- Framing B summary: <top 3 candidates>
+- Framing C summary: <5 load-bearing assumptions + falsification queries>
+
+### Cross-framing agreement
+- <candidate> appeared in A + B
+- <candidate> appeared in B + C
+
+### New hypothesis set
+1. <hypothesis> — evidence to gather: <one-liner>
+2. ...
+```
+
+### 5. Reset the counter
+
+Reset the "consecutive failed rounds" counter to 0. Return to Phase 3 (parallel investigation) with the new set.
+
+---
+
+## If *another* 2 rounds fail after the Oracle Triple
+
+You are genuinely stuck. This is the escalation threshold.
+
+Escalate to the user (see `05-escalate.md`) with the full trace: every hypothesis tried, every piece of evidence captured, both Oracle syntheses. Do not guess a fix.
+
+This is rare — in practice, the Oracle Triple resolves almost all stuck debugging sessions within one round, because it pulls in framings the investigator was too close to the code to see.

package/packages/shared-skills/skills/debugging/references/methodology/05-escalate.md

@@ -0,0 +1,69 @@
+# Phase 5 — User Decision Escalation
+
+Escalation is for genuine ambiguity, not for skipping investigation. Most "should I ask the user" moments are really "I don't want to do one more query" moments, and those are wrong.
+
+---
+
+## Ask the user ONLY when
+
+- **Evidence exhausted**, contradictions remain, and further investigation would require a decision with policy implications (e.g. "patch the third-party SDK vs wrap it vs change architecture").
+- The bug has **multiple valid fixes with different scope/risk tradeoffs** and the user's preference drives the choice.
+- A proposed fix would **change observable product behavior** for the end user (not just fix the internal bug).
+- You've **exhausted the Oracle Triple** and another 2 rounds failed after synthesis.
+
+## Do NOT ask when
+
+- You haven't tried the Oracle Triple yet.
+- The question can be answered by one more runtime query.
+- You're asking for permission to do the obvious thing.
+- You're asking because you're tired.
+
+---
+
+## Escalation format (paste into the reply)
+
+Keep it short. Evidence-dense. One decision, not a status update.
+
+```markdown
+## Decision needed
+
+**What we know** (verbatim evidence, not paraphrase):
+- <fact 1 with file:line or address>
+- <fact 2 with source>
+- <what the evidence rules IN>
+- <what the evidence rules OUT>
+
+**What the decision is** (one sentence):
+<the fork in the road>
+
+**Options**:
+
+| # | Fix | Scope | Risk | Effort |
+|---|-----|-------|------|--------|
+| A | <short label> | <files touched / layers> | <regressions possible> | <rough> |
+| B | ... | ... | ... | ... |
+| C | ... | ... | ... | ... |
+
+**Recommendation**: <A/B/C> because <one-sentence reason>.
+
+Which direction do you want?
+```
+
+---
+
+## Anti-patterns in escalation
+
+- **Asking without evidence.** "What do you want me to do?" is not an escalation, it's abandonment. Every escalation includes the evidence the user needs to decide.
+- **Two questions in one.** One decision per escalation. Multi-part questions lead to partial answers and re-escalation.
+- **Escalating before Phase 4.** If you haven't tried the Oracle Triple, you haven't earned the right to escalate.
+- **Presenting options you don't actually have.** If option C requires a library the user doesn't use, don't list it. The options are only things you can actually do today.
+- **Hiding a recommendation.** The user hired you to think — always end with a recommendation, even if you're low-confidence. Say so explicitly: "Recommendation (low confidence): B, because X. If you have context about Y that I don't, it might change to A."
+
+---
+
+## What happens after the user responds
+
+- **User picks an option**: return to Phase 6 (root cause confirmation) with the chosen direction. The user's choice is not itself confirmation — you still need runtime evidence that the cause you're fixing is the cause in play.
+- **User proposes a different option you hadn't considered**: treat it as new information. Update hypotheses. May trigger another Phase 3 round.
+- **User gives more context that resolves the disagreement**: skip to Phase 6.
+- **User is also unsure**: that's a signal you need more evidence, not more opinions. Run one more targeted query before asking again.