@xaccefy/pi-casefile 0.9.4 → 0.10.0

package/src/workflow.ts

@@ -1,374 +1,93 @@
 /**
- * Cyber workflow injected into agent context when XP mode is SWARM.
+ * Recon workflow injected once per session into the agent's system prompt.
  *
- * Skills (cyberwf, web-pentest) cover tool usage and methodology. This file
- * adds the unique attacker discipline: state machine with preconditions,
- * attacker model, impact validation, adversarial review, kill checklist, and
- * report-readiness criteria. Token-disciplined: every rule here is load-bearing;
- * wording is compressed, nothing is dropped.
+ * Scope: RECON only — attack-surface mapping and intel collection, fanned out
+ * to recon subagents. Everything after recon (hunting the leads, PoC work, the
+ * confirmation gate, reporting) is the main agent's own inline job through the
+ * casefile tools; this file does NOT orchestrate a hunt/trace/validate pipeline.
  */
-import { KILL_REASON_VALUES } from "./ledger.ts";
-
-const KILL_REASONS_TEXT = KILL_REASON_VALUES.join(" / ");
-
-/** Case-lifecycle diagram, shared by the FULL and LITE workflows. */
-const LIFECYCLE_DIAGRAM = `
-\`\`\`
-                     +--- KILLED (dead end, documented why)
-                     |
-RECON -> HYPOTHESIS --+
-                       |
-                       +--> INVESTIGATING --> CONFIRMED --> REPORTED
-                                |   ^                 |
-                                |   |  chain/primitive |
-                                |   +-----------------+
-                                |
-                                +--> KILLED (insufficient impact, duplicate, etc.)
-\`\`\``;
 
 /**
  * Subagent-dispatch conventions per host. Pi (pi-subagents extension) dispatches
- * through \`subagent({ workflowScript: runs.run(...) })\`; OMP (fork, @oh-my-pi)
- * dispatches through its native \`task\` tool with a tasks array. The workflow
- * body is identical — only the launch mechanics differ.
+ * through `subagent({ workflowScript: runs.run(...) })`; OMP (fork, @oh-my-pi)
+ * dispatches through its native `task` tool with a tasks array. The recon body
+ * is identical — only the launch mechanics differ.
  */
 type DispatchSpec = {
-  /** Tool-reference paragraph. */
+  /** How to launch a recon subagent on this host. */
   reference: string;
-  /** HARD GATE launch sentence (after "record the entry-point inventory, then STOP..."). */
-  hardGate: string;
-  /** Crash-handling paragraph. */
+  /** The parallel recon fan-out line. */
+  fanout: string;
+  /** Retry discipline when a recon subagent fails. */
   crash: string;
-  /** Skeptic dispatch snippet (follows "dispatch it before main-agent validation with "). */
-  skeptic: string;
 };
 
 const PI_DISPATCH: DispatchSpec = {
   reference:
-    "**Subagent dispatch:** every launch uses `subagent({ workflowScript: \"return runs.run('stable-key', { agent: 'tracer', task: '...' })\", context: 'fresh', async: true })`. Parallel HUNT uses one workflowScript with `return runs.all([...])`, capped at 3 auditor tasks per round. Batch related classes by surface/family instead of spawning one agent per bug class. Stable keys include run, stage, batch/case, and attempt.",
-  hardGate:
-    "Your next tool call MUST launch one async workflowScript whose `runs.all([...])` dispatches at most 3 batched HUNT auditors.",
+    "**Subagent dispatch:** each recon launch uses `subagent({ workflowScript: \"return runs.run('recon-<area>-1', { agent: 'recon', task: '...' })\", context: 'fresh', async: true })`. Fan out a round with ONE workflowScript using `return runs.all([...])`, at most 3 recon tasks. Stable keys include run, recon area, and attempt.",
+  fanout:
+    "Launch ONE async workflowScript whose `runs.all([...])` dispatches at most 3 recon subagents, one per intel area (surface map, client-side / JS mining, passive intel + fingerprint/CVE).",
   crash:
-    "**Subagent failure handling:** a crash, timeout, hung run, unparseable output, or schema-invalid output is a RETRY, not a verdict. Launch one new workflowScript with the same specialist task, a new stable attempt key, and a stronger model. Failure again → record `blocked: <agent> failed` in the pipeline-run case and continue; never silently drop the stage.",
-  skeptic:
-    "`subagent({ workflowScript: \"return runs.run('skeptic-<case>-1', { agent: 'skeptic', task: '...' })\", context: 'fresh', async: true })`",
+    "**Subagent failure handling:** a crash, timeout, hung run, or unparseable output is a RETRY, not a result. Re-launch the same recon area with a new attempt key and a stronger model; on repeat failure, record `blocked: recon <area> failed` on the recon case and continue with the areas that returned.",
 };
 
 const OMP_DISPATCH: DispatchSpec = {
   reference:
-    "**Subagent dispatch (OMP):** every launch uses `task({ context: 'fresh', tasks: [{ name: 'stable-key', agent: 'tracer', task: '...' }] })`. Parallel HUNT dispatches ONE task call whose `tasks` array carries at most 3 auditor tasks per round, batching related classes by surface/family instead of spawning one agent per bug class. Stable names include run, stage, batch/case, and attempt. Results deliver automatically; steer with `hub`.",
-  hardGate:
-    "Your next tool call MUST launch one async `task` call whose `tasks` array dispatches at most 3 batched HUNT auditors. When their results are delivered, submit each output through PipelineSubmit.",
+    "**Subagent dispatch (OMP):** each recon launch uses `task({ context: 'fresh', tasks: [{ name: 'recon-<area>-1', agent: 'recon', task: '...' }] })`. Fan out a round with ONE `task` call whose `tasks` array carries at most 3 recon tasks. Stable names include run, recon area, and attempt. Results deliver automatically; steer with `hub`.",
+  fanout:
+    "Launch ONE async `task` call whose `tasks` array dispatches at most 3 recon subagents, one per intel area (surface map, client-side / JS mining, passive intel + fingerprint/CVE).",
   crash:
-    "**Subagent failure handling:** a failed or hung task, timeout, unparseable output, or schema-invalid output is a RETRY, not a verdict. Re-dispatch the same specialist task with a new attempt name and a stronger model. Failure again → record `blocked: <agent> failed` in the pipeline-run case and continue; never silently drop the stage.",
-  skeptic:
-    "`task({ context: 'fresh', tasks: [{ name: 'skeptic-<case>-1', agent: 'skeptic', task: '...' }] })`",
+    "**Subagent failure handling:** a failed or hung task, timeout, or unparseable output is a RETRY, not a result. Re-dispatch the same recon area with a new attempt name and a stronger model; on repeat failure, record `blocked: recon <area> failed` on the recon case and continue with the areas that returned.",
 };
 
-/** Build the full cyber workflow for a host's dispatch convention. */
-function buildCyberWorkflow(d: DispatchSpec): string {
+/** Build the recon workflow for a host's dispatch convention. */
+function buildReconWorkflow(d: DispatchSpec): string {
   return `
-# Cyber Workflow (Attacker-Oriented)
+# Recon Workflow (Attack-Surface Mapping & Intel Collection)
 
-Think like a real external attacker, not a code reviewer. Technical bugs are cheap; **reachable attacker impact** is what matters. Every lead starts HYPOTHESIS; nothing reaches CONFIRMED without a proven attacker path and demonstrated impact against a real production target or faithful replica.
+Think like a real external attacker, not a code reviewer. This workflow covers ONE job: turn a target into a rich attack-surface map and intel picture that later hunting can act on. Recon fans out to subagents; hunting the leads, validation, the PoC confirmation gate, and reporting are yours to run afterward, inline, through the casefile tools.
 
 ## Tool Reference
 
-**Casefile (state tracking):** CaseAdd, CaseUpdate, CaseGet, CaseList, CaseSearch, CaseLink, CaseUnlink, CaseContext, PromoteFinding, ConfirmFinding, PipelineSubmit
+**Casefile (state tracking):** CaseAdd, CaseUpdate, CaseGet, CaseList, CaseSearch, CaseLink, CaseUnlink, CaseContext, EvidenceAdd
 
-**Scratchpad (pipeline artifacts):** ScratchpadInit, ScratchpadResume, ScratchpadCheckpoint, ScratchpadWrite, ScratchpadRead, ScratchpadPhaseDone, ScratchpadClear
+**Scratchpad (recon artifacts):** ScratchpadInit, ScratchpadWrite, ScratchpadRead, ScratchpadResume, ScratchpadCheckpoint, ScratchpadPhaseDone, ScratchpadClear
 
-**Web lookup (research):** web_search, web_fetch, exploit_search, context7, deepwiki, http_request
+**Web lookup / intel:** web_search, web_fetch, exploit_search, context7, deepwiki, http_request
 
 ${d.reference}
 
-**Swarm delegation boundary:** only auditor (HUNT rounds), tracer (TRACE), skeptic (high-confidence challenge), and chain (CHAIN) run as subagents. You, the main coordinator, own RECON, VALIDATE/PoC writing, ConfirmFinding, patching, final reports, state decisions, and all orchestration.
-
-## Dispatch Discipline (fewer calls, batched, verifier-in-the-loop)
-
-This pipeline is SEQUENTIAL-dependent: each stage consumes the previous stage's output, so only HUNT genuinely fans out. Do NOT scatter one async subagent call per finding — that pays full coordination cost for no parallel payoff and turns you into a message router. Two rules keep it cheap:
-
-1. **Two dispatch points, each ONE batched call.** (a) **HUNT** — one call whose \`runs.all\`/\`tasks\` carries ≤3 batched auditors (related classes grouped by surface/family). (b) **TRACE+SKEPTIC** — one call carrying a trace task per prioritized finding, plus a skeptic task for each \`confidence: high\` finding; batch the whole round in a single dispatch, never one dispatch per finding. RECON, VALIDATE/PoC, ConfirmFinding, CHAIN, and REPORT stay INLINE with you.
-2. **Barrier, then submit the whole batch in one pass.** Let the batched call return ALL of its results, then \`PipelineSubmit\` each output back-to-back before choosing the next stage. Do not interleave fresh dispatches with the delivery of a prior batch. A crash / timeout / unparseable / schema-invalid result for one item is a RETRY for THAT item in the next batch — never a verdict, never a reason to drop the stage.
-
-Every stage boundary is a \`PipelineSubmit\` gate (schema + pre-filter, in code): nothing advances on prose. This is the verifier-in-the-loop — the same principle the machine PoC gate applies at CONFIRMED, applied at every stage transition.
-
-## Stage Machine (run in order — you are the coordinator)
+**Delegation boundary:** recon/intel gathering runs as subagents (the \`recon\` agent). You, the main coordinator, own scoping, consolidating recon results into the attack-surface map, filing hypotheses, and every state decision. Everything past recon is your inline job — there is no hunt/trace/validate subagent pipeline.
 
-RECON (you, inline) → **HUNT** (2-3 batched auditor subagents) → TRACE (tracer for prioritized findings) → SKEPTIC (bounded high-risk review) → VALIDATE (you, inline) → CHAIN (chain subagent) → REPORT (you, inline)
+## Recon — what to gather
 
-### Blackbox recon — attack-surface mapping (no source access)
+Live web target, CTF, or bounty box: gather high-signal intel and turn it into the map hunting will use — entry-point inventory (URL, method, params, auth state), attacker model, auth/role boundaries, trust boundaries, likely vuln-class batches, and known gaps. Aim for the richest useful map, not the largest raw pile.
 
-Live web target, CTF, or bounty box: RECON aggressively gathers high-signal intel and turns it into the map HUNT will use: entry-point inventory, attacker model, auth/role boundaries, trust boundaries, likely vuln-class batches, and known gaps. Aim for the richest useful map, not the largest raw pile. Choose the next recon move from the target and current unknowns. Use JS/source maps, \`robots.txt\`, \`sitemap.xml\`, \`/.well-known/\`, OpenAPI/Swagger, GraphQL introspection, passive archives, and exposed backup/VCS checks when they are likely to change class selection, target selection, or attacker modeling. Stop when additional collection is unlikely to change the HUNT plan; re-enter RECON when HUNT/TRACE exposes missing surface.
-- **Client-side code can be high signal** — pull JS bundles/source maps when the app is SPA/API-heavy or routes are hidden, then bank discovered endpoints, params, and secrets as leads.
-- **Zero-traffic intel is optional, not ritual** — check public metadata, schemas, and passive archives when scope allows and the result can change target selection, auth modeling, or class selection.
-- **Fingerprint for decisions** — stack + version confidence should drive \`exploit_search\` and HUNT class selection; record uncertainty instead of forcing a guess.
-- **Bank useful leads** — write the entry-point map, selected HUNT class batches, and open gaps to the scratchpad; file high-value leaks (source map, origin IP, exposed schema, leaked creds) as \`EvidenceAdd role=observation\`. Tactical commands: web-pentest skill §2.
+- **Surface mapping** — routes, endpoints, parameters, auth models; \`robots.txt\`, \`sitemap.xml\`, \`/.well-known/\`, OpenAPI/Swagger, GraphQL introspection.
+- **Client-side mining** — pull JS bundles / source maps for SPA or API-heavy apps; bank discovered endpoints, params, and secrets as leads.
+- **Passive intel** — public metadata, schemas, passive archives, exposed backup/VCS checks, when scope allows and the result can change target, auth, or class selection.
+- **Fingerprint for decisions** — stack + version confidence drives \`exploit_search\` and class selection; record uncertainty instead of guessing.
 
-**Observe behavior, then analyze — static intel is only half.** Interrogate the target empirically and infer its internals from how it *reacts*; the differential (vary one input, watch what changes) is the signal. **Web/API:** status vs length vs timing vs body vs error across crafted inputs; how auth actually gates (401 vs 302 vs 200-with-error); reflected vs stored; timing oracles for blind bugs; state changes across a request sequence. **Binary/local target:** map the I/O contract, trace syscalls + library calls (\`strace\`/\`ltrace\`), feed malformed/boundary input and watch crashes, signals, and return codes, and diff behavior across inputs to expose the parse/branch logic. **Protocol/service:** walk the handshake + state machine, then replay and mutate one field and observe the divergence and side effects. Loop: stimulus → observe → infer the internal model → craft a discriminating probe → repeat. Every observed anomaly (crash, error leak, timing gap, unexpected 200, state change) is a HYPOTHESIS — \`CaseAdd\` it with its \`disproveIf\`, don't just note it.
+## Dispatch discipline (recon fans out; consolidation is yours)
 
-**HARD GATE — after RECON:** record the entry-point inventory, then STOP all inline reading/probing. ${d.hardGate} When its completion is delivered, submit each output through PipelineSubmit. If you catch yourself mapping a sink, reading a handler, or probing an endpoint beyond the recon inventory, stop and add it to a HUNT task.
+Scope the target first, then fan recon out ONCE per round: ${d.fanout} Let the batched call return ALL results, then consolidate them yourself. Do NOT scatter one subagent per URL — group by intel area. Re-enter recon only when a gap actually blocks a decision.
 
 ${d.crash}
 
-**TRACE verdicts:** only schema-valid \`trace_result: "REACHABLE"\` advances toward validation. \`UNREACHABLE\` requires a concrete blocker for the stated attacker model; \`UNDETERMINED\` means missing context/auth/WAF/source ambiguity and blocks or re-dispatches, never kills.
-
-## Case Lifecycle (State Machine)
-${LIFECYCLE_DIAGRAM}
-
-### Phase → State map
-
-| Phase | Case State | What happens |
-|-------|-----------|-------------|
-| RECON | (none) | Map attack surface, fingerprint, search CVEs. Something interesting → HYPOTHESIS. |
-| HUNT | HYPOTHESIS | Document the lead (impact not required yet). Clear intended-behavior/artifact → KILLED; else INVESTIGATING. |
-| TRACE / SKEPTIC / VALIDATE | INVESTIGATING | Trace reachability, attempt disconfirmation, and produce the pending PoC evidence bundle. Failure stays INVESTIGATING or becomes KILLED. |
-| MAIN REVIEW | CONFIRMED | The main agent judges whether the machine differential actually establishes the vulnerability and impact, then commits through ConfirmFinding. |
-| CHAIN | CONFIRMED | Link confirmed findings and evaluate multi-step exploit paths; this stage does not confirm new cases. |
-| REPORT | REPORTED | CaseContext → main-agent report writing → report-readiness gate. |
-
-### Preconditions Per State Transition (MANDATORY)
-
-| Advance To | Required Case Fields | On Disk |
-|-----------|---------------------|---------|
-| HYPOTHESIS → INVESTIGATING | evidence (observations), confidence | Notes on what was observed |
-| INVESTIGATING → **CONFIRMED** | evidence, poc, **impact** (content below), severity, **target**, **disconfirmation** (the main agent's documented disprove attempt) | PromoteFinding phase 1: PoC runs 2× against target + 1× against an operator-approved \`control_target\` (same script, sha256-enforced); every run completes at exit zero with output fully captured and writes nonce-bound \`evidence.json\` with a response-body predicate; the harness obtains conclusive target/control responses and requires \`target_only\`. Then the **main/coordinator agent itself** reviews and calls **ConfirmFinding**, which captures a fresh second harness replay before commit. Worker agents cannot submit phase 2. Zero exit is necessary run integrity, never vulnerability proof; output markers are diagnostic only. |
-| Any → KILLED | assumptions (why it died) | — |
-| CONFIRMED → REPORTED | CaseContext(id) succeeded (records report path) AND you wrote the report file | Context bundle + report file |
-
-**Empty required field = you cannot advance.** The fields ARE the gates.
-
-### Advance vs kill vs stay
-
-Staying in HYPOTHESIS/INVESTIGATING is fine — you're still working. Do not force a transition.
-
-- **HYPOTHESIS → KILLED only when:** documented intended behavior, duplicate, artifact/noise, or you proved no attack path exists after testing.
-- **HYPOTHESIS → INVESTIGATING:** something real, actively testing (source-sink not required yet).
-- **INVESTIGATING → KILLED:** proved insufficient impact, environmental issue, unreliable exploit, or duplicate after investigation.
-- **INVESTIGATING → CONFIRMED:** the gates below must pass.
-
----
-
-## At HYPOTHESIS
-
-Document without impact proof: **what happened** (behavior/error/timing/leak), **where** (endpoint/parameter/component/line), **who can reach it** (unauth/user/admin), **unknowns → next experiments**.
-
-Do NOT kill a hypothesis just because impact is unclear — impact may come from chaining. Kill only when: clearly documented/intended behavior (after checking docs), duplicate, test artifact/cache noise/browser quirk, or you tested and proved no attack path (not "I can't see one").
-
----
-
-## At INVESTIGATING (chaining primitives)
-
-Primitives: open redirect, limited SSRF, info leak of non-sensitive data, reflected XSS on non-sensitive page, CSRF on public-only action. For each:
-
-1. **What can this combine with?** (SSRF + internal service, open redirect + OAuth callback, leak + other endpoint)
-2. **Does it cross a trust boundary?** Unauth trigger? Low-priv user reaching an admin endpoint?
-3. **Worst-case chain in C/I/A?**
-
-Record chains via CaseLink. Keep the primitive INVESTIGATING while exploring; KILL only if you prove no chain exists after testing.
-
----
-
-## At VALIDATE (before CONFIRMED)
-
-All of the following must be answered and documented in evidence + impact. Incomplete = stay INVESTIGATING.
-
-### 0. Attacker Model
-
-1. **Who is the attacker?** (unauth internet, low-priv user, tenant peer, SSRF pivot)
-2. **What can they already do without the bug?** (baseline)
-3. **What extra power does the bug grant beyond that baseline?**
-4. **Is the path realistic in production?** (auth, CSRF, WAF, network, feature flags, admin-only)
-
-If you cannot name a concrete attacker who gains something they should not have → do NOT confirm; stay INVESTIGATING or KILL with reason.
-
-### 1. Disconfirmation (mandatory)
-
-The finding must survive an attempt to disprove it. Two tiers, gated on \`confidence\` (severity comes later, from the PoC):
-
-**\`confidence: high\` → skeptic subagent (MANDATORY):** dispatch it before main-agent validation with ${d.skeptic}. It independently re-reads the source (or re-probes live), verifies scope, tries to disprove, and audits any PoC file you already have for cheats. Its schema-validated CONFIRMED verdict must carry its own \`disconfirmation_attempt\` (CONFIRMED verdicts without one are rejected by PipelineSubmit). DISPROVEN → add EvidenceAdd role=refutation, then killed directly, no tie-breaker. UNDETERMINED → block/re-dispatch; do not validate yet. Do NOT skip; do NOT self-disconfirm high-confidence findings.
-
-**Below high → self-disconfirmation:** actively try to disprove your own finding; document it (see the strong/weak example below). Not a formality.
-
-An attempt: reproduce under different conditions (auth/config/network position); test the behavior against docs/baseline endpoints; trigger protections (WAF/CSP/CSRF/rate limits); try to trigger the same behavior without your attacker-controlled input. Document in \`disconfirmation\`: what you tried, how (conditions/inputs/target), result (failing to disprove is the expected outcome), why the attempt was valid.
-
-Strong example: "Read /api/users/123 as user B after confirming user A owns 123 → 403. Repeated with X-Override-User header (seen in admin traffic) → user A's data returned. Protection bypassed via the admin header."
-Weak: "Tried to disprove. Could not." — insufficient.
-
-**The CONFIRMED disconfirmation comes from the main agent, not a script or worker.** There is no \`disconfirmation_path\` gate: after PromoteFinding, the main/coordinator must write its own failed disproof attempt, which becomes the case's \`disconfirmation\`, and call ConfirmFinding to capture the fresh phase-2 replay. A worker/subagent cannot call PromoteFinding or ConfirmFinding, and a verdict without the main agent's \`disconfirmation_attempt\` is rejected.
-
-**Evidence chain closure (before PromoteFinding):** promotion is rejected unless the case carries an **artifact-backed** \`observation\` evidence item (EvidenceAdd role=observation with \`artifact_path\` — the initial signal, stored with its SHA-256) in addition to the auto-recorded reproduction item. Record observations as you go, not at promote time.
-
-**Main-agent validation only:** do not dispatch validation. You write the smallest reliable PoC that demonstrates the **maximum reachable impact** of the vulnerability, set the case's poc/evidence/impact/severity/target fields, and run PromoteFinding yourself. "Smallest" means no fragile ceremony, mocks, or unrelated exploit steps — not a weaker impact demonstration. Do not stop at a benign marker if a stronger in-scope, non-destructive primitive is reachable (read/write, privilege change, account takeover path, data exposure, etc.). If the PoC fails, refine it yourself up to the local budget; if proof cannot meet the gate, kill or keep the case investigating with the exact blocker.
-
-**PromoteFinding (phase 1) — evidence bundle, not markers.** Pick the differential \`mode\` that fits the class:
-
-- **\`mode: "inter_host"\` (default)** — body-carried proof that is the same on any host (file read, injection exfil, info leak, reflection). Call with \`poc_path\`, an operator-approved \`control_target\` from \`PI_POC_CONTROL_TARGETS\`, optional same-byte \`control_path\` (defaults to \`poc_path\`), and \`local: true\` when the bug needs network. The harness sends the SAME request to target and control and requires \`target_only\`.
-- **\`mode: "intra_target"\`** — access-control and business-logic classes (IDOR/BOLA, auth bypass, privilege escalation, mass assignment, logic/price tampering) where the discriminating variable is the attacker's IDENTITY or a PARAMETER, not the host. A different host lacks the victim's object/state, so inter-host proves nothing. Instead the evidence declares \`verify.mode: "intra_target"\` and a \`baseline\` (a legitimate SAME-host request — the attacker's own object, a properly-authorized request, the field omitted); the harness sends attack + baseline to the case target and requires the proof on the attack response only. No \`control_target\`/\`control_path\`.
-
-Every run must complete with fully captured output and write nonce-bound \`evidence.json\` whose \`expect\` includes \`body_contains\` or \`body_regex\`; status-only evidence is rejected. The harness pins DNS at connect time and keeps redirects on the bound host. Private replay requires operator authorization. Blind/OOB classes fail closed until a source-separated oracle exists.
-
-**ConfirmFinding (phase 2) — main-agent-only commit.** After PromoteFinding succeeds, do not dispatch confirmation. The main/coordinator agent must inspect the exact PoC/evidence, hunt trivial predicates/fabrication, attempt disconfirmation, and call \`ConfirmFinding(case_id, verdict)\` itself. A CONFIRMED call performs and stores a fresh harness-owned target/control replay; a caller-supplied re-execution checkbox is not accepted. CONFIRMED requires \`re_execution_note\`, \`differential: "target_only"\`, and the main agent's \`disconfirmation_attempt\`. Worker processes are rejected. **Never \`CaseUpdate(status: "confirmed")\` directly.**
-
-**PoC audit (anti-cheat, before PromoteFinding):** have an independent eye on the PoC script itself. For \`confidence: high\` findings the skeptic agent re-reads the PoC file hunting unconditional success, trivial checks, constants, and local mocks. Record the audit as EvidenceAdd \`observation\` (or \`refutation\` if cheated). The main agent must re-read the exact script before ConfirmFinding; workers may challenge evidence but never run validation or decide promotion. Deterministic backstops are code: output completeness, nonce binding, response-body predicates, deterministic runs, operator-approved control, DNS-pinned conclusive replay, same-file sha256, and PoC byte-identity re-check at commit.
-
-### 2. Design & Runtime Check — non-intentionality gate (mandatory)
-
-A finding is report-worthy only if the behavior is a genuine flaw — not documented intent and not already neutralized by the runtime the target ships on. Prove the difference by searching before you confirm; record the search (what you looked at, what you found) in \`disconfirmation\`/\`evidence\` for the report's non-intentionality proof.
-
-**Search:** (1) project docs — README/docs/comments near the sink; (2) changelog/release notes — deliberate feature or known issue?; (3) git history/blame — commit messages/PRs ("fix:", "feat:", "intentional", "trade-off"); (4) issue tracker/accepted PRs; (5) runtime/framework docs — does the shipped version already mitigate (patched version, middleware, WAF, CSRF, CSP, runtime defaults)?
-
-**Outcomes:**
-
-- **BY DESIGN** — docs/history show intent → KILL \`intended_behavior\`, UNLESS the documented intent IS the flaw ("we knowingly accept this risk" on a security-sensitive path with real impact is still a finding — say why in evidence).
-- **FIXED IN THE RUNTIME** — the runtime already blocks the path → KILL \`framework_protection\`, or downgrade to \`info\` if only a hardening note.
-- **NEITHER** — no documented intent and no runtime mitigation → this is the non-intentionality evidence; cite what you searched (docs read, commits checked, versions compared).
+## Bank the results
 
-A finding reaching CONFIRMED without this search documented is not report-ready.
+- Write the entry-point map, selected class batches, and open gaps to the scratchpad: \`ScratchpadWrite(run_id, "recon", "entry-points.md", ...)\`.
+- File high-value leaks (source map, origin IP, exposed schema, leaked creds) as \`EvidenceAdd role=observation\`.
+- Turn each credible lead into a hypothesis: \`CaseAdd\` it with its \`disproveIf\` (what would rule it out). Every observed anomaly — an unexpected 200, an error leak, a timing gap, an exposed endpoint — is a HYPOTHESIS, not just a note.
 
-### 3. Production Path Verification (in impact)
+## Hand-off
 
-The CONFIRMED \`impact\` must answer: **target environment** tested (prod/staging/dev/local?); **production protections** that could block the path (WAF, CSRF, CORS, CSP, rate limiting, network segmentation, auth, feature flags, admin-only); **bypass verification** for each; **target comparison** — if tested on dev/staging/local, what differs in prod and is the path verified there?
-
-Fails the gate: "attacker can read files" without target + protections; "works on localhost" without prod differences; "the code path exists" without a reachable victim asset; "could be dangerous / may lead to RCE" without a concrete production path.
-
-Name the **specific target host/repo** in the target field. Dev-only with non-default config → document honestly; consider KILL.
-
-### 4. KILL at Validate stage
-
-Documented intended behavior · self-XSS/self-DoS only · requires admin/root role that already has the power · local-only/offline/impossible deployment · needs physical access or social engineering with no trust-boundary break · no C/I/A/financial effect for anyone but the attacker · PoC proves a code path but no victim asset · protections block the path and are not bypassed. **Kill gate:** killing a case that reached \`investigating\`/\`confirmed\` requires a refutation evidence item (EvidenceAdd role=refutation — the disprove attempt that ended the lead); a keyword in free text is not enough once the case advanced past hypothesis.
-
-### 5. Evidence-First Doctrine
-
-Every claim must be traceable to observed/reproduced behavior, source code, or documented platform behavior. Insufficient evidence → state uncertainty and propose the next experiment. Never assume success where verification is incomplete.
-
-### 6. Impact Gate
-
-Prove at least **one** real attacker-facing violation against a production-viable target:
-
-| Category | Required proof |
-|----------|----------------|
-| **Confidentiality** | Attacker reads data they must not see |
-| **Integrity** | Attacker changes data/state they must not control |
-| **Availability** | Attacker degrades service for **others** |
-| **Financial / authz** | Direct money, privilege, or account takeover path |
-
-Impact text answers: *who is hurt, what is lost, how the attacker reaches it from production.* Theoretical impact, a second unproven bug, or unreachable-from-attacker → stay INVESTIGATING (chain it) or KILL.
-
-**Severity is derived from PROVEN impact, not guessed** — set only after the machine differential and the main-agent review demonstrate the impact; a zero exit or PoC output alone is insufficient:
-- **critical** = RCE, account takeover, or direct fund theft demonstrated in confirmed evidence
-- **high** = sensitive data read/write, privilege escalation, SSRF to internal services
-- **medium** = limited data exposure, XSS on sensitive page, IDOR on non-critical resources
-- **low** = info leak, open redirect, self-only impact with a victim path
-- **info** = best-practice gap, no demonstrated impact
-
-"Could lead to"/"may allow"/"theoretically" = NOT proven — drop to what the confirmed harness evidence shows. Claim the highest impact the harness and main-agent review actually prove; unsupported escalation gets rejected at triage.
-
-### 7. Adversarial Self-Review
-
-1. Why this might NOT be a vulnerability.
-2. Alternative explanations for the observation.
-3. Why each alternative was rejected **with evidence**.
-4. What blocks a real attacker in production today, and whether each is bypassed.
-5. Would triage reject this as informative/N/A?
-
-### 8. Root Cause → Boundary → Impact
-
-\`\`\`
-Entry (attacker-controlled) → Code path → Trust boundary crossed → Victim impact
-\`\`\`
-
-Reproduce at least twice or via two methods.
-
----
-
-## At REPORT
-
-1. **Run CaseContext(case_id)** — writes the context bundle (complete record, PoC + disconfirmation logs, links, pipeline artifacts) and records the report path.
-2. **Write the report yourself** at the returned report path using the context bundle. In XP swarm, reporting stays with the main agent.
-3. **Report-readiness gate** (YOU check this before accepting; on failure, edit the report yourself):
-- Deterministic reproduction by another researcher
-- Steps realistic in production
-- Impact justified without inflation (would the vendor agree?)
-- Root cause + fix guidance concrete
-- Attacker model + victim impact + target explicit
-- No internal identifiers: no case IDs, ledger paths, PoC filenames, or local paths in the report file
-
-The ledger enforces a machine floor on the report file before accepting \`reported\`: non-trivial size, required section headings (Summary / Impact / Remediation), and a forbidden-identifier scan (case id, ledger/report paths, PoC/control/disconfirmation basenames). A report that fails the scan keeps the case CONFIRMED — fix the file, then retry the transition.
-
----
-
-## KILLED cataloging
-
-When a case is definitively dead (not "I don't know yet"), record the reason: ${KILL_REASONS_TEXT} (true bug, no realistic attacker value). Documenting kills prevents re-opening dead ends. Cases with unresolved unknowns stay INVESTIGATING, not killed.
+Recon ends when more collection is unlikely to change the hunt plan. Hand off to yourself: the filed HYPOTHESIS cases are the hunt queue. Investigate them inline through the casefile. Recon does not confirm findings — the PoC confirmation gate (PromoteFinding → ConfirmFinding) is unchanged and stays the main agent's job.
 `.trim();
 }
 
-/** Cyber workflow for Pi Agent (pi-subagents dispatch). */
-export const STATIC_CYBER_WORKFLOW = buildCyberWorkflow(PI_DISPATCH);
-
-/** Cyber workflow for OMP (fork of Pi; native `task` dispatch). */
-export const STATIC_CYBER_WORKFLOW_OMP = buildCyberWorkflow(OMP_DISPATCH);
+/** Recon workflow for Pi Agent (pi-subagents dispatch). */
+export const STATIC_RECON_WORKFLOW = buildReconWorkflow(PI_DISPATCH);
 
-/**
- * Cyber workflow for XP LITE mode — single-agent, no subagent dispatch.
- *
- * Same attacker discipline as the full workflow, but the main agent does every
- * stage itself (recon, hunt, trace, validate, chain, report). Built for CTF and
- * single-shot engagements where subagent orchestration is overkill.
- */
-export const STATIC_CYBER_WORKFLOW_LITE = `
-# Cyber Workflow — LITE (Single-Agent)
-
-You are the ONLY agent. Do NOT dispatch subagents (no auditor, tracer, skeptic, or chain agents). You do every stage yourself, inline: recon, hunt, trace, validate, chain, report — the full attacker discipline without subagent orchestration overhead. Great for CTF and focused single-target engagements.
-
-Think like a real external attacker, not a code reviewer. Technical bugs are cheap; **reachable attacker impact** is what matters.
-
-## Tool Reference
-
-**Casefile (state tracking):** CaseAdd, CaseUpdate, CaseGet, CaseList, CaseSearch, CaseLink, CaseUnlink, CaseContext, PromoteFinding, ConfirmFinding, PipelineSubmit
-
-**Scratchpad (pipeline artifacts):** ScratchpadInit, ScratchpadResume, ScratchpadCheckpoint, ScratchpadWrite, ScratchpadRead, ScratchpadPhaseDone, ScratchpadClear
-
-**Web lookup (research):** web_search, web_fetch, exploit_search, context7, deepwiki, http_request
-
-**No subagent/task tool.** In lite mode you do not dispatch subagents (pi's \`subagent\` or OMP's \`task\`). All specialist work is yours.
-
-## Case Lifecycle (State Machine)
-${LIFECYCLE_DIAGRAM}
-
-## Stage discipline (all done by you, inline)
-
-1. **RECON — attack-surface mapping.** Blackbox/CTF: aggressively gather high-signal intel and turn it into entry points, auth models, trust boundaries, attacker model, vuln-class batches, and gaps. Fingerprint credible stack/version signals and search CVEs (\`exploit_search\`) when the version confidence is useful. Use JS/source maps, \`robots.txt\`, \`sitemap.xml\`, \`/.well-known/\`, OpenAPI/Swagger, GraphQL introspection, exposed backup/VCS checks, and passive archives when they can change class selection, target selection, or attacker modeling. Record discovered entry points (URL, method, params, auth state), selected class targets, and gaps/assumptions: \`ScratchpadWrite(run_id, "recon", "entry-points.md", ...)\`.
-2. **HUNT** — choose attack classes from recon and examine relevant entry points. \`CaseAdd\` each lead as a hypothesis. Track coverage per class.
-3. **TRACE / observe** — prove reachability and understand the mechanism by observing how the target behaves, then analyzing the reaction. Read the source (grep/find); probe the live endpoint (\`http_request\`) and diff responses (status vs length vs timing vs error) as you vary one input; or for a binary/local target trace syscalls + library calls (\`strace\`/\`ltrace\`) and watch crashes, signals, and return codes under malformed/boundary input. Infer the internal model from the differential, feed anomalies back as hypotheses, and only advance reachable findings.
-4. **VALIDATE** — write a PoC that emits nonce-bound \`evidence.json\`, run it via \`PromoteFinding\` (2 target runs + same-script control), review and disconfirm it yourself, and commit via \`ConfirmFinding\`, which performs the fresh phase-2 replay (see the gates below). Derive severity from the proven impact.
-5. **CHAIN** — link confirmed findings via \`CaseLink\` to find exploit chains.
-6. **REPORT** — run \`CaseContext\` to write the context bundle, then write the final report yourself per the report style checklist below, then \`CaseUpdate(status: "reported")\`.
-
-## Report style checklist (lite — you are the writer)
-
-Write the final report as a self-contained markdown file at the report path CaseContext recorded, applying the fixed report format rules:
-
-- **Title:** \`<vuln class>: <exact trigger/location> — <honest impact>\` (e.g. "IDOR: order delivery address of any user", "SQLi: blind boolean-based via GET").
-- **Structure:** Summary (2-3 sentences) → Vulnerability Details (CWE, CVSS 3.1 vector + score, affected asset/version) → Description (root cause + why NOT intended behavior, citing the docs/git search) → Steps to Reproduce (numbered, verbatim requests/responses/scripts, deterministic) → Impact (attacker model → maximum proven C/I/A outcome, not speculation) → Mitigation / Remediation → References → Disclosure timeline (only if dates are known).
-- **Tone:** factual, calm, evidence-carried. NO case IDs, ledger paths, PoC filenames, local paths, or "I discovered" narratives. Never invent evidence — "version not determined" beats a guess. Severity from proven impact only.
-
-## Gates (unchanged — these keep findings honest)
-
-- **No finding is confirmed until its target is verified in scope** per the program's scope instruction. Out-of-scope findings are killed, not confirmed.
-- **No finding is validated without a reachability trace** showing REACHABLE. UNREACHABLE requires a concrete blocker; unresolved auth/WAF/source ambiguity stays INVESTIGATING or BLOCKED, not killed.
-- **High-confidence findings: do your own adversarial disconfirmation.** No skeptic subagent in lite mode — actively try to disprove your own finding and document the attempt in \`disconfirmation\`. Failing to disprove is the expected outcome.
-- **Confirmed requires** evidence + poc + impact + severity + target + disconfirmation, via the two-phase gate: **PromoteFinding** in the differential \`mode\` that fits the class — \`inter_host\` (default) with an operator-approved \`control_target\` for body-carried proof (file read, injection exfil, info leak, reflection), or \`intra_target\` for access-control/logic classes (IDOR, auth bypass, privilege escalation, logic), where the evidence declares \`verify.mode:"intra_target"\` + a same-host \`baseline\` and the harness requires the proof on the attack response only (no control target). Then you, the main agent, inspect the bundle, attempt disconfirmation, and call **ConfirmFinding** yourself. That call captures a fresh second replay before commit. Do not delegate validation or confirmation. The machine gate requires zero-exit complete runs, nonce binding, body evidence, determinism, a DNS-pinned conclusive \`target_only\` differential, and script identity; zero exit is never proof and markers are diagnostic only. \`local:true\` and private replay remain operator-gated. No mocks and no direct \`CaseUpdate(status: "confirmed")\`.
-- **Severity is derived from proven PoC impact, not theory.** Demonstrate and claim the highest impact the attacker can actually reach; claiming less than a proven escalation is wrong, and over-claiming an unproven one gets the finding rejected at triage.
-- **Evidence-first:** every claim must be traceable to observed/reproduced behavior, source code, or documented platform behavior.
-- **Design & runtime check (mandatory before CONFIRMED):** actively search the target's docs, git history, changelog, and runtime/framework docs for evidence the behavior is BY DESIGN or already FIXED IN THE RUNTIME. Found it → KILL (\`intended_behavior\` / \`framework_protection\`), unless the documented intent is itself the flaw with real attacker impact. Not found → document the search in \`disconfirmation\` as non-intentionality proof.
-
-## KILLED cataloging
-
-When a case is definitively dead (not "I don't know yet"), record the reason: ${KILL_REASONS_TEXT}. **A kill without a reason is rejected by the ledger** — add an EvidenceAdd \`refutation\` item or state the reason token in assumptions/nextStep. Documenting kills prevents re-opening dead ends. Cases with unresolved unknowns stay INVESTIGATING, not killed.
-
-## Stall rule (deferred)
-
-3 rounds without new signal, new surface, or new techniques → CaseUpdate(status: 'blocked', blockers: ["deferred after 3 rounds — revisit when: <exact condition>"]). Blocked-with-revisit-condition is the deferred state; do not kill leads that are merely stalled.
-`.trim();
+/** Recon workflow for OMP (fork of Pi; native `task` dispatch). */
+export const STATIC_RECON_WORKFLOW_OMP = buildReconWorkflow(OMP_DISPATCH);

package/skills/casefile/SKILL.md

@@ -1,44 +0,0 @@
----
-name: casefile
-description: Use when tracking security investigations, bug bounty findings, CTF leads, audit evidence, exploit chains, dead ends, or reports in the Casefile ledger.
-license: MIT
----
-
-# Casefile Tracker
-
-Use Casefile to maintain durable security investigation state across agent turns.
-
-## Workflow
-
-1. Check existing cases before opening a new one with CaseList or CaseSearch.
-2. Open new leads with CaseAdd as `hypothesis` or `investigating`.
-3. Promote cases with CaseUpdate only after materially new evidence, proof, impact, blockers, remediation, or status changes.
-4. Mark `confirmed` only via the two-phase gate — main-agent `PromoteFinding` (PoC 2× target + 1× operator-approved control, nonce-bound body evidence, then a DNS-pinned conclusive `target_only` replay; use the post-PoC harness-generated canary for reflection-capable requests) → the main agent personally reviews → `ConfirmFinding`, which captures a fresh second harness replay before commit. Never delegate validation or confirmation; worker/subagent gate calls are rejected. Exit zero is run integrity, never vulnerability proof. A predicate differential is evidence, not an automatic exploit verdict. Blind/OOB findings remain investigating without a source-separated oracle.
-5. Use CaseLink and CaseUnlink for exploit chains. Do not edit linked case IDs directly.
-6. Use CaseContext only for confirmed or already reported cases: it writes the full context bundle (complete record, verification logs, links, pipeline artifacts) and records the report path. Then write the report and CaseUpdate status=`reported`.
-7. Use `killed` for disproven, duplicate, or dead-end leads, and include evidence, blockers, next step, or assumptions explaining why.
-
-## State machine
-
-```
-hypothesis → investigating → confirmed → reported
-                 ↓               ↓
-              blocked         killed (terminal)
-```
-
-- investigating requires evidence + confidence
-- confirmed requires PromoteFinding + ConfirmFinding (never CaseUpdate)
-- killed/reported are terminal (no field edits or re-links)
-
-## Tool Map
-
-- `CaseAdd`: create a new case.
-- `CaseUpdate`: update an existing case.
-- `PromoteFinding`: phase 1 — require a body predicate, bind the verify URL, pin DNS, and send the same request to target and an operator-approved `PI_POC_CONTROL_TARGETS` control. Both responses must be conclusive and only `target_only` passes. For reflection, place `{{PI_POC_CANARY}}` exactly once in the request and declare `verify.canary`; the harness creates the secret after the PoC exits and requires target-only reflection. Network/private access remains operator-gated; OOB fails closed without source separation.
-- `ConfirmFinding`: phase 2 — main-agent-only review and fresh harness replay before commit (CONFIRMED promotes; NOT_CONFIRMED keeps investigating; worker/subagent calls are rejected). Record `canary_assessment=verified` when requested, otherwise `not_applicable` with a concrete reason.
-- `CaseGet`: read one case by ID.
-- `CaseList`: list cases with filters and pagination.
-- `CaseSearch`: search all fields or a scoped field.
-- `CaseLink`: bidirectionally link two cases.
-- `CaseUnlink`: remove a bidirectional case link.
-- `CaseContext`: write the case context bundle (complete record, PoC/disconfirmation logs, links, pipeline artifacts) for a confirmed or reported case and record the report path for the main agent.

package/src/ledger-worker-entry.ts

@@ -1,35 +0,0 @@
-/**
- * Worker-thread entry for heavy ledger reads (suggestChains, writeCaseContext).
- *
- * Runs in a dedicated thread so an O(n²) chain scan or a multi-megabyte
- * context-bundle build never blocks the agent's event loop. Each call spawns
- * a fresh worker — rare operations, no lifecycle to manage, no stale state.
- * The worker opens its OWN connection to the same WAL database (read-mostly
- * work + one small reportPath write); WAL + busy_timeout make multi-connection
- * access safe.
- */
-
-import { parentPort, workerData } from "node:worker_threads";
-import { suggestChains, writeCaseContext } from "./ledger.ts";
-import { setScratchpadRoot } from "./scratchpad.ts";
-
-process.env.PI_CASEFILE_PATH = workerData.casefilePath as string;
-setScratchpadRoot(workerData.workspaceRoot as string | undefined);
-
-type WorkerRequest =
-  | { op: "suggestChains"; caseId?: string }
-  | { op: "writeCaseContext"; id: string };
-
-parentPort?.on("message", (req: WorkerRequest) => {
-  try {
-    if (req.op === "suggestChains") {
-      parentPort?.postMessage({ ok: true, result: suggestChains(req.caseId) });
-    } else if (req.op === "writeCaseContext") {
-      parentPort?.postMessage({ ok: true, result: writeCaseContext(req.id) });
-    } else {
-      parentPort?.postMessage({ ok: false, error: `unknown ledger worker op` });
-    }
-  } catch (e) {
-    parentPort?.postMessage({ ok: false, error: (e as Error).message });
-  }
-});

package/src/ledger-worker.ts

@@ -1,77 +0,0 @@
-/**
- * Async offload for the two heavy ledger reads — main-thread side.
- *
- * suggestChains is O(rules × cases²) over the whole ledger; writeCaseContext
- * reads every artifact of every matching scratchpad run and builds a
- * multi-hundred-KB bundle. Both ran synchronously inside async tool handlers,
- * stalling the event loop. Each call here spawns a short-lived worker thread
- * (ledger-worker-entry.ts) and falls back to the inline sync function when
- * the worker cannot run (Node < 22.18 has no default type stripping for the
- * TS entry) or times out. Writes stay sync on the main thread: they are
- * single-row upserts, bounded by the 5s busy_timeout.
- */
-
-import { Worker } from "node:worker_threads";
-import {
-  type CaseContextResult,
-  type ChainSuggestion,
-  getCasefilePath,
-  suggestChains,
-  writeCaseContext,
-} from "./ledger.ts";
-import { detectWorkspaceRoot } from "./scratchpad.ts";
-
-type WorkerResponse = { ok: true; result: unknown } | { ok: false; error: string };
-
-const WORKER_TIMEOUT_MS = 30_000;
-
-function runInLedgerWorker(
-  request:
-    | {
-        op: "suggestChains";
-        caseId?: string;
-      }
-    | {
-        op: "writeCaseContext";
-        id: string;
-      },
-): Promise<unknown> {
-  const { promise, resolve, reject } = Promise.withResolvers<unknown>();
-  const worker = new Worker(new URL("./ledger-worker-entry.ts", import.meta.url), {
-    workerData: { casefilePath: getCasefilePath(), workspaceRoot: detectWorkspaceRoot() },
-  });
-  const timer = setTimeout(() => {
-    void worker.terminate();
-    reject(new Error("ledger worker timed out"));
-  }, WORKER_TIMEOUT_MS);
-  worker.once("message", (msg: WorkerResponse) => {
-    clearTimeout(timer);
-    void worker.terminate();
-    if (msg.ok) resolve(msg.result);
-    else reject(new Error(msg.error));
-  });
-  worker.once("error", (e) => {
-    clearTimeout(timer);
-    reject(e);
-  });
-  worker.postMessage(request);
-  return promise;
-}
-
-/** suggestChains on a worker thread; inline fallback keeps behavior identical. */
-export async function suggestChainsAsync(caseId?: string): Promise<ChainSuggestion[]> {
-  try {
-    return (await runInLedgerWorker({ op: "suggestChains", caseId })) as ChainSuggestion[];
-  } catch {
-    return suggestChains(caseId);
-  }
-}
-
-/** writeCaseContext on a worker thread; inline fallback keeps behavior identical. */
-export async function writeCaseContextAsync(id: string): Promise<CaseContextResult> {
-  try {
-    return (await runInLedgerWorker({ op: "writeCaseContext", id })) as CaseContextResult;
-  } catch {
-    return writeCaseContext(id);
-  }
-}