@xaccefy/pi-casefile 0.7.1 → 0.7.3

package/src/workflow.ts

@@ -1,31 +1,26 @@
 /**
  * Cyber workflow injected into agent context when XP mode is ON.
  *
- * Skills (pipeline, web-pentest) already 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.
- *
- * The case lifecycle (HYPOTHESIS -> INVESTIGATING -> CONFIRMED -> REPORTED)
- * maps to the pipeline's discovery stages. This file explains the gate
- * discipline applied at each transition.
+ * 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.
  */
 export const STATIC_CYBER_WORKFLOW = `
 # Cyber Workflow (Attacker-Oriented)
 
-Think like a real external attacker, not a code reviewer. Technical bugs are cheap; **reachable attacker impact** is what matters for bounty-valid findings.
-
-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. 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.
 
 ## Tool Reference
 
-**Casefile (state tracking):** CaseAdd, CaseUpdate, CaseGet, CaseList, CaseSearch, CaseLink, CaseUnlink, CaseReport, PromoteFinding
+**Casefile (state tracking):** CaseAdd, CaseUpdate, CaseGet, CaseList, CaseSearch, CaseLink, CaseUnlink, CaseContext, PromoteFinding, PipelineSubmit
 
 **Scratchpad (pipeline artifacts):** ScratchpadInit, ScratchpadResume, ScratchpadCheckpoint, ScratchpadWrite, ScratchpadRead, ScratchpadPhaseDone, ScratchpadClear
 
 **Web lookup (research):** web_search, web_fetch, exploit_search, context7, deepwiki, http_request
 
-**Subagent dispatch:** \`subagent({agent: "auditor"|"tracer"|"skeptic"|"exploit"|"chain", task: "..."})\` — use this to dispatch specialist agents. Do NOT do the specialist work yourself.
+**Subagent dispatch:** \`subagent({agent: "auditor"|"tracer"|"skeptic"|"exploit"|"chain"|"reporter", task: "..."})\` — dispatch specialists; do NOT do the specialist work yourself.
 
 ## Case Lifecycle (State Machine)
 
@@ -42,145 +37,117 @@ RECON -> HYPOTHESIS --+
                                 +--> KILLED (insufficient impact, duplicate, etc.)
 \`\`\`
 
-### Phase -> State map
+### Phase → State map
 
 | Phase | Case State | What happens |
 |-------|-----------|-------------|
-| RECON | (none yet) | Map attack surface, fingerprint, search CVEs. When something interesting appears -> HYPOTHESIS. |
-| HUNT | HYPOTHESIS | Document the lead. Impact not required yet. If it's a clear intended-behavior or artifact -> KILLED. Otherwise -> INVESTIGATING. |
-| CHAIN | INVESTIGATING | Test the hypothesis, chain primitives, build PoC. Explore combinations (open redirect + SSRF, leak + other endpoint, etc.). |
-| VALIDATE | CONFIRMED | Prove impact against production target, adversarial review, root-cause trace. Survive the gates below, or fall back to INVESTIGATING / KILLED. |
-| REPORT | REPORTED | Write up, report-readiness gate, submit. |
+| 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. |
+| CHAIN | INVESTIGATING | Test the hypothesis, chain primitives, build PoC. Explore combinations (open redirect + SSRF, leak + endpoint, …). |
+| VALIDATE | CONFIRMED | Prove impact, adversarial review, root-cause trace. Survive the gates below or fall back to INVESTIGATING / KILLED. |
+| REPORT | REPORTED | CaseContext → reporter agent → report-readiness gate. |
 
 ### Preconditions Per State Transition (MANDATORY)
 
-| Advance To | Required Case Fields | Must Exist on Disk |
-|-----------|---------------------|--------------------|
-| HYPOTHESIS -> INVESTIGATING | evidence (observations or initial findings), confidence | Notes on what was observed |
-| INVESTIGATING -> **CONFIRMED** | evidence, poc (steps/script), **impact (see below for content requirements)**, severity, **target (host/repo/scope this affects)**, **disconfirmation (your documented attempt to disprove the finding)** | PoC script + exit 0 + **verification_marker present in output** (proves the exploit actually worked, not just that the script ran). Optionally, disconfirmation script run.log exit non-0 (finding survived the attempt to disprove). |
-| Any -> KILLED | assumptions (why it died) | --- |
-| CONFIRMED -> REPORTED | Only after CaseReport(id) succeeds | Report file |
+| 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** (your documented disprove attempt) | PoC script, exit 0, **verification_marker in output** (proves the exploit ran, not just the script). Optional disconfirmation script exit non-0. |
+| Any → KILLED | assumptions (why it died) | — |
+| CONFIRMED → REPORTED | CaseContext(id) succeeded (records report path) AND the reporter agent wrote the report file | Context bundle + report file |
 
-**Rule: If a required field is empty, you cannot advance.** The fields are the gates.
+**Empty required field = you cannot advance.** The fields ARE the gates.
 
-### When to advance vs kill vs stay
+### Advance vs kill vs stay
 
-Staying in HYPOTHESIS or INVESTIGATING is **fine** --- it means you're still working. Do not force a transition.
+Staying in HYPOTHESIS/INVESTIGATING is fine — you're still working. Do not force a transition.
 
-- **HYPOTHESIS -> KILLED only when**: it's documented intended behavior, duplicate, artifact/noise, or you proved no attack path exists after testing.
-- **HYPOTHESIS -> INVESTIGATING**: you have something real and are actively testing. Source-sink not required yet.
-- **INVESTIGATING -> KILLED**: you proved insufficient impact, environmental issue, unreliable exploit, or duplicate after investigation.
-- **INVESTIGATING -> CONFIRMED**: strict gates below must pass.
+- **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 (just found something)
-
-Document what you know without worrying about impact proof:
+## At HYPOTHESIS
 
-1. **What happened?** (behavior, error, timing, leak)
-2. **Where?** (endpoint, parameter, component, line)
-3. **Who can reach it?** (unauth, any user, admin only)
-4. **What you don't know yet** -> next experiments
+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 a hypothesis only when:**
-- It's clearly documented/intended behavior (after checking docs)
-- It's a duplicate
-- It's a test artifact, cache noise, browser quirk
-- You tested and proved no attack path exists (not "I can't see one")
+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)
 
-Many findings start as primitives: open redirect, limited SSRF, info leak of non-sensitive data, reflected XSS on non-sensitive page, CSRF on public-only action.
+Primitives: open redirect, limited SSRF, info leak of non-sensitive data, reflected XSS on non-sensitive page, CSRF on public-only action. For each:
 
-For each primitive, ask:
 1. **What can this combine with?** (SSRF + internal service, open redirect + OAuth callback, leak + other endpoint)
-2. **Does the primitive cross a trust boundary?** Can an unauth user trigger it? Can a low-priv user reach an admin endpoint?
-3. **What's the worst-case chain expressed in C/I/A?**
+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 as INVESTIGATING while you explore. Only KILL if you prove no chain exists after testing.
+Record chains via CaseLink. Keep the primitive INVESTIGATING while exploring; KILL only if you prove no chain exists after testing.
 
 ---
 
-## At VALIDATE (before advancing to CONFIRMED)
+## At VALIDATE (before CONFIRMED)
 
-Before promoting to CONFIRMED, the following must be fully answered and documented in the case fields (evidence + impact). Incomplete answers = stay INVESTIGATING.
+All of the following must be answered and documented in evidence + impact. Incomplete = stay INVESTIGATING.
 
-### 0. Attacker Model (must be in evidence or impact field)
+### 0. Attacker Model
 
-1. **Who is the attacker?** (unauth internet, low-priv user, tenant peer, SSRF pivot, etc.)
-2. **What can they already do without the bug?** (baseline privileges)
+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 required?)
+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)
 
-If you cannot name a concrete attacker who gains something they should not have -> do **not** confirm. Stay INVESTIGATING or KILL with documented reason.
+The finding must survive an attempt to disprove it. Two tiers, gated on \`confidence\` (severity comes later, from the PoC):
 
-### 1. Disconfirmation (mandatory before CONFIRMED)
+**\`confidence: high\` → skeptic subagent (MANDATORY):** dispatch \`subagent({agent: "skeptic", task: "..."})\` BEFORE the exploit agent. It independently re-reads the source (or re-probes live), verifies scope, and tries to disprove. Its \`disconfirmation_attempt\` becomes the case's \`disconfirmation\` — stronger than self-disconfirmation. DISPROVEN → killed directly, no tie-breaker. Do NOT skip; do NOT self-disconfirm high-confidence findings.
 
-Before promoting to CONFIRMED, the finding must survive an attempt to disprove it. There are two tiers, gated on the auditor's \`confidence\` (severity doesn't exist yet — the exploit agent assigns it only after the PoC runs):
+**Below high → self-disconfirmation:** actively try to disprove your own finding; document it. Not a formality.
 
-**\`confidence: high\` → skeptic subagent (MANDATORY):** You MUST dispatch a skeptic subagent via \`subagent({agent: "skeptic", task: "..."})\` BEFORE the exploit agent runs. The skeptic independently re-reads the source (or re-probes live), verifies the finding is in scope per the program's scope instruction, and tries to disprove it. The skeptic's \`disconfirmation_attempt\` is written into the case's \`disconfirmation\` field — it satisfies this gate and is stronger than self-disconfirmation because a separate agent produced it. If the skeptic says DISPROVEN, the finding is killed directly — no tie-breaker. Do NOT skip this step. Do NOT self-disconfirm high-confidence findings.
+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.
 
-**Below confidence high → self-disconfirmation:** You must actively attempt to disprove your own finding. Document the attempt in the \`disconfirmation\` field. This is not a formality.
+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.
 
-**What a disconfirmation attempt looks like:**
+If the disconfirmation script (\`disconfirmation_path\`) exits 0, promotion is blocked. If you cannot write a meaningful disconfirmation script, you don't understand the finding well enough to promote it.
 
-- Reproduce the finding under different conditions (different auth, different config, different network position). If it fails, you disproved the scope.
-- Check if the behavior is intentional by testing against documentation or by trying to get the same result on a known-baseline endpoint.
-- Attempt to trigger protections (WAF, CSP, CSRF, rate limits) that would block the path in production.
-- Try to prove the root cause is wrong: can the same behavior be triggered without the attacker-controlled input you identified?
+### 2. Design & Runtime Check — non-intentionality gate (mandatory)
 
-**Document the attempt in \`disconfirmation\` field.** Must include:
-1. What you tried to do to disprove the finding
-2. How you did it (conditions, inputs, target)
-3. What result you got (if it failed to disprove, that's the expected outcome)
-4. Why you believe the disconfirmation attempt was valid
+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.
 
-**Strong disconfirmation that passes the gate:**
-"Attempted to read /api/users/123 as user B after confirming user A owns record 123. The endpoint returned 403 for user B, confirming the IDOR protection works as expected. However, when we modified the request to include the X-Override-User header seen in admin traffic, the endpoint returned user A's data. The protection is bypassed via the admin header."
+**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)?
 
-**Weak disconfirmation:**
-"Tried to disprove. Could not."
+**Outcomes:**
 
-If the disconfirmation script (\`disconfirmation_path\` in PromoteFinding) exits 0, the finding is considered disproven and promotion is blocked. If you cannot write a meaningful disconfirmation script, you may not understand the finding well enough to promote it.
+- **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).
 
-### 2. Production Path Verification (must be in impact field)
+A finding reaching CONFIRMED without this search documented is not report-ready.
 
-The **impact** field for CONFIRMED must explicitly answer:
+### 3. Production Path Verification (in impact)
 
-1. **Target environment:** Which host/repo/instance was this tested against? (prod, staging, dev, local?)
-2. **Production protections:** What protections exist in production that could block this path? (WAF, CSRF tokens, CORS, CSP, rate limiting, network segmentation, auth, feature flags, admin-only access)
-3. **Bypass verification:** For each protection, have you confirmed it is bypassed or absent?
-4. **Target comparison:** If tested against dev/staging/local, what differs in production that could affect exploitability? Have you verified the path still works in the production configuration?
+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?
 
-**Weak impact that fails this gate:**
-- "Attacker can read files" without specifying which target and whether protections block it
-- "This works on localhost" without verifying production differences
-- "The code path exists" without proving a real victim asset is reachable
-- "Could be dangerous" or "may lead to RCE" without a concrete production path
+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.
 
-You must name the **specific target host/repo** in the target field. If the finding only works on a dev instance with non-default config, document that honestly and consider whether it's KILL-worthy.
+Name the **specific target host/repo** in the target field. Dev-only with non-default config → document honestly; consider KILL.
 
-### 3. KILL at Validate stage
+### 4. KILL at Validate stage
 
-Documented intended behavior
-- Self-XSS / self-DoS only (attacker harms only their own session)
-- Requires admin/root role that already has the same power
-- Local-only, offline, or impossible deployment assumptions
-- Needs physical access, social engineering with no trust-boundary break
-- No C/I/A/financial effect for anyone but the attacker
-- PoC proves a code path exists but not that any victim asset is affected
-- Protections in production block the path and are not bypassed
+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.
 
-### 4. Evidence-First Doctrine
+### 5. Evidence-First Doctrine
 
-Every claim must be traceable to observed/reproduced behavior, source code, or documented platform behavior. If evidence is insufficient: state uncertainty and propose the next experiment. Never assume success where verification is incomplete.
+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.
 
-### 5. Impact Gate
+### 6. Impact Gate
 
 Prove at least **one** real attacker-facing violation against a production-viable target:
 
@@ -191,53 +158,121 @@ Prove at least **one** real attacker-facing violation against a production-viabl
 | **Availability** | Attacker degrades service for **others** |
 | **Financial / authz** | Direct money, privilege, or account takeover path |
 
-Impact text must answer: *who is hurt, what is lost, how the attacker reaches it from production.*
+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.
 
-If impact is theoretical, needs a second unproven bug, or is not yet reachable from the attacker's position -> stay INVESTIGATING (chain it) or KILL.
-
-**Severity is derived from PROVEN impact, not guessed.** Do not set severity until the PoC has exited 0 and the output demonstrates the impact. Map severity to what the PoC output actually shows:
-- **critical** = RCE, account takeover, or direct fund theft — proven in PoC output
-- **high** = sensitive data read/write, privilege escalation, SSRF to internal services — proven in PoC output
-- **medium** = limited data exposure, XSS on sensitive page, IDOR on non-critical resources — proven in PoC output
-- **low** = info leak, open redirect, self-only impact with a victim path — proven but minimal harm
+**Severity is derived from PROVEN impact, not guessed** — set only after the PoC exits 0 and its output demonstrates the impact:
+- **critical** = RCE, account takeover, or direct fund theft (in PoC output)
+- **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 the level the PoC output actually demonstrates. Under-claiming is safe; over-claiming gets the finding rejected at triage.
+"Could lead to"/"may allow"/"theoretically" = NOT proven — drop to what the PoC output shows. Under-claiming is safe; over-claiming gets rejected at triage.
 
-### 6. Adversarial Self-Review
+### 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 a program triage reject this as informative/N/A?
+4. What blocks a real attacker in production today, and whether each is bypassed.
+5. Would triage reject this as informative/N/A?
 
-### 7. Root Cause -> Boundary -> Impact
+### 8. Root Cause → Boundary → Impact
 
 \`\`\`
-Entry (attacker-controlled) -> Code path -> Trust boundary crossed -> Victim impact
+Entry (attacker-controlled) → Code path → Trust boundary crossed → Victim impact
 \`\`\`
 
 Reproduce at least twice or via two methods.
 
 ---
 
-## At REPORT (before advancing to REPORTED)
+## At REPORT
 
-- Another researcher can reproduce deterministically
+1. **Run CaseContext(case_id)** — writes the context bundle (complete record, PoC + disconfirmation logs, links, pipeline artifacts) and records the report path.
+2. **Dispatch the reporter subagent**: \`subagent({agent: "reporter", task: "Write the final report for case <id>. case_id=<id>, context_path=<path from CaseContext>, report_path=<path from CaseContext>, program_name=<program if known>. Apply the fixed report format rules in your prompt (title convention, body template, tone rules). Output: the report file written to report_path + CaseUpdate(status: 'reported')."})\`. It writes the polished report and flips the case to REPORTED.
+3. **Report-readiness gate** (YOU check this on the reporter's output before accepting; on failure, re-dispatch with the gap list):
+- Deterministic reproduction by another researcher
 - Steps realistic in production
 - Impact justified without inflation (would the vendor agree?)
-- Root cause + fix guidance are concrete
+- 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
 
 ---
 
 ## KILLED cataloging
 
-When a case is definitively dead (not "I don't know yet"), record the reason:
-- intended_behavior / duplicate / framework_protection
-- exploit_unreliable / insufficient_impact / environmental_issue
-- not_applicable (true bug / interesting behavior, no realistic attacker value)
+When a case is definitively dead (not "I don't know yet"), record the reason: intended_behavior / duplicate / framework_protection / exploit_unreliable / insufficient_impact / environmental_issue / not_applicable (true bug, no realistic attacker value). Documenting kills prevents re-opening dead ends. Cases with unresolved unknowns stay INVESTIGATING, not killed.
+`.trim();
+
+/**
+ * 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, exploit, 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, 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 tool.** In lite mode you do not call \`subagent\`. All specialist work is yours.
+
+## Case Lifecycle (State Machine)
+
+\`\`\`
+                     +--- KILLED (dead end, documented why)
+                     |
+RECON -> HYPOTHESIS --+
+                       |
+                       +--> INVESTIGATING --> CONFIRMED --> REPORTED
+                                |   ^                 |
+                                |   |  chain/primitive |
+                                |   +-----------------+
+                                |
+                                +--> KILLED (insufficient impact, duplicate, etc.)
+\`\`\`
+
+## Stage discipline (all done by you, inline)
+
+1. **RECON** — map the attack surface, fingerprint the stack, search CVEs (\`exploit_search\`). Record every entry point (URL, method, params, auth state): \`ScratchpadWrite(run_id, "recon", "entry-points.md", ...)\`.
+2. **HUNT** — for each attack class, examine every entry point. \`CaseAdd\` each lead as a hypothesis. Track coverage per class.
+3. **TRACE** — prove reachability yourself: read the source (grep/find) or probe the live endpoint (\`http_request\`). Only reachable findings advance.
+4. **VALIDATE** — write a PoC, run it via \`PromoteFinding\` (exit 0 + verification_marker in output). 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 (no reporter subagent in lite mode) 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 → concrete C/I/A outcome, under-claimed) → 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.
+- **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, and a PoC that exited 0 **with the verification_marker in the output**. No mocks for the exploitation step.
+- **Severity is derived from proven PoC impact, not theory.** Under-claiming is safe; over-claiming 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
 
-Documenting kills prevents re-opening dead ends. Cases with unresolved unknowns should stay INVESTIGATING, not killed.
+When a case is definitively dead (not "I don't know yet"), record the reason: intended_behavior / duplicate / framework_protection / exploit_unreliable / insufficient_impact / environmental_issue / not_applicable. Documenting kills prevents re-opening dead ends. Cases with unresolved unknowns stay INVESTIGATING, not killed.
 `.trim();