@xaccefy/pi-casefile 0.8.2 → 0.9.0

package/README.md

@@ -44,8 +44,8 @@ hypothesis → investigating → confirmed → reported
 ```
 
 - **investigating** needs `evidence` + `confidence`
-- **confirmed** only by running the PoC (`PromoteFinding`, exit 0 + verification marker in output) — you can't just set status to confirmed. Promotion additionally requires an EvidenceAdd `observation` item (the initial signal) — the ledger rejects a `confirmed` with no evidence chain.
-- **Live findings (`local:true`) also require `control_path`**: the same PoC run against a control lacking the vuln must NOT print the marker. The harness checks the control output itself — an unconditional-marker or mock-target PoC is blocked. The control run is stored as `controlVerified`. A control or disconfirmation script that **crashes** (killed / timeout / spawn error — no completion marker) is blocked too: a crash is not a clean control verdict and not a survived disproof. This applies at the ledger level, not just the tool: a local (sandbox:false) promotion without `controlVerification` is rejected by `promoteFindingResult` itself.
+- **confirmed** only through the two-phase gate — `PromoteFinding` (evidence bundle: PoC 2× target + 1× same-script control, every run completing with nonce-bound `evidence.json`; machine-checks nonce binding, determinism, target/control differential) → confirmer subagent verdict → `ConfirmFinding` (CONFIRMED requires re_executed + target_only + disconfirmation_attempt). You can't just set status to confirmed, and markers/exit codes are diagnostics. Promotion additionally requires an EvidenceAdd `observation` item (the initial signal) — the ledger rejects a `confirmed` with no evidence chain.
+- **Every promotion requires `control_path`** (the same bytes as the PoC — sha256 enforced) and a distinct `control_target`; a run whose control evidence matches the target's is blocked as not-target-dependent. The control run is stored as `controlVerified`. Runs that **crash** (killed / timeout / spawn error / missing evidence.json) are blocked too: a crash is not a verdict.
 - **New cases require `disproveIf`** — falsification conditions (what would disprove this hypothesis). A hypothesis that can't say what kills it isn't one yet.
 - **A kill must be justified**: either an EvidenceAdd `refutation` item, or a kill-reason token (intended_behavior, duplicate, framework_protection, out_of_scope, skeptic-disproven, no_attack_path, ...) in assumptions/nextStep. Bare `status: "killed"` is rejected.
 - **reported** needs `CaseContext` first (records the report path; the report writer produces the final file)
@@ -62,7 +62,8 @@ hypothesis → investigating → confirmed → reported
 | `CaseAdd` | Open a case (`title` + `disproveIf` required; start as `hypothesis` or `investigating`) |
 | `CaseUpdate` | Evidence, impact, severity, status (not direct confirm) |
 | `EvidenceAdd` | Role-typed, hashed evidence item on a case (refutation justifies kills; cleanup tracks cleanup) |
-| `PromoteFinding` | Run on-disk PoC (Docker sandbox by default; `local:true` = host-network sandbox, host execution operator-gated via `PI_POC_ALLOW_LOCAL=1`) → confirm on exit 0 + marker; `control_path` + `control_liveness_marker` REQUIRED for every promotion |
+| `PromoteFinding` | Phase 1: run on-disk PoC (Docker sandbox by default; `local:true` = host-network sandbox, host execution operator-gated via `PI_POC_ALLOW_LOCAL=1`) 2× target + 1× control; validates nonce-bound evidence.json, determinism, differential; records the 1h pending bundle + confirmer dispatch instruction |
+| `ConfirmFinding` | Phase 2: commit the confirmer's verdict (CONFIRMED promotes; NOT_CONFIRMED keeps investigating — no tie-breaker) |
 | `CaseGet` / `CaseList` / `CaseSearch` | Read / filter / search |
 | `CaseLink` / `CaseUnlink` | Bidirectional exploit chains |
 | `ChainSuggest` | Scan cases for exploitable chain combinations (credential+endpoint→ATO, redirect+OAuth→token theft, XSS+state-change→CSRF, IDOR+user-data, SSTI→RCE, race+payment, info-disclosure+SSRF), ranked by confidence |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xaccefy/pi-casefile",
-  "version": "0.8.2",
+  "version": "0.9.0",
   "description": "Offensive security case tracker for Pi Agent — bug bounties, CTFs, security audits",
   "keywords": [
     "pi-package",
@@ -51,9 +51,6 @@
       "./skills"
     ]
   },
-  "dependencies": {
-    "@sinclair/typebox": "^0.32.34"
-  },
   "devDependencies": {
     "@types/bun": "^1.3.14",
     "typescript": "^6.0.3"
@@ -61,6 +58,7 @@
   "peerDependencies": {
     "@earendil-works/pi-ai": "*",
     "@earendil-works/pi-coding-agent": "*",
-    "@earendil-works/pi-tui": "*"
+    "@earendil-works/pi-tui": "*",
+    "typebox": "*"
   }
 }

package/skills/casefile/SKILL.md

@@ -13,7 +13,7 @@ Use Casefile to maintain durable security investigation state across agent turns
 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 PromoteFinding after a real PoC exit 0 (evidence, impact, severity, poc required).
+4. Mark `confirmed` only via the two-phase gate — `PromoteFinding` (runs the PoC 2× against the target + 1× against a distinct control target; every run must write nonce-bound `evidence.json` and complete with captured output) → dispatch the `confirmer` subagent → commit its verdict with `ConfirmFinding`. Markers and exit codes are diagnostics, not gates.
 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 have the report written (reporter agent in the full pipeline; yourself in lite mode) and CaseUpdate status=`reported`.
 7. Use `killed` for disproven, duplicate, or dead-end leads, and include evidence, blockers, next step, or assumptions explaining why.
@@ -27,14 +27,15 @@ hypothesis → investigating → confirmed → reported
 ```
 
 - investigating requires evidence + confidence
-- confirmed requires PromoteFinding (not CaseUpdate)
+- 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`: run an on-disk PoC script (Docker sandbox or local) and promote a case to confirmed on exit 0.
+- `PromoteFinding`: phase 1 of confirmation — run an on-disk PoC script (Docker sandbox or local) against the target 2× plus a same-script control run; machine-validates nonce-bound evidence.json, determinism, and the target/control differential; records a 1h pending bundle and returns the confirmer dispatch instruction.
+- `ConfirmFinding`: phase 2 — commit the confirmer's verdict (CONFIRMED promotes to confirmed; NOT_CONFIRMED keeps investigating, no tie-breaker).
 - `CaseGet`: read one case by ID.
 - `CaseList`: list cases with filters and pagination.
 - `CaseSearch`: search all fields or a scoped field.