Complete VeriSimDB hexad persistence (S1–S3) — campaign-driven

[hyperpolymath]

Problem

panic-attack already has a VeriSimDB hexad storage mode (src/storage/mod.rs, StorageMode::VerisimDb) but it only wraps AssaultReport files. The TOPOLOGY dashboard lists "VerisimDB Storage ██████░░░░ 60% — File I/O works, API planned" and the Patch Bridge section says "Phase 2 adds VeriSimDB hexad persistence and auto-retire on upstream fix".

Running the estate sweep campaign (#32) surfaces three concrete places this gap hurts:

1. AssemblylineReport.results[].report is #[serde(skip)]

src/assemblyline.rs:57 skips the embedded AssailReport when the assemblyline summary is serialized — sensible, because for 303 repos the full weak_points[] would blow up to hundreds of MB. So today, the campaign has to do two passes: assemblyline for the repo list, then per-repo assail --output <repo>.json for the WeakPoints. With a hexad store, the assemblyline pass could persist per-finding rows under a repo:<name> partition and queries like "all PA001 in repos with critical count > 0" would be a single DB call instead of N JSON parses.

2. Cross-run state has no native home

The campaign needs to remember: which findings have been turned into PRs, which were classified as legitimate, which are parked. Today this lives in:

• Per-repo audits/assail-classifications.a2ml (suppression)
• mass-panic-results/*.json timestamped scratch
• A GitHub tracker issue checklist (manual)

A hexad with (finding-id, state, pr-url, classified-as, seen-in-runs[…]) modalities would replace all three. panic-attack diff could then natively answer "what's new since 2026-04-12" instead of being a JSON-vs-JSON delta.

3. Cross-repo taint chains can't be queried

src/kanren/crosslang.rs derives FFI-boundary vulnerability chains but emits them as in-memory facts per scan. A persistent fact-base would let panic-attack signatures and a future panic-attack query reason across the whole estate without re-scanning.

Proposal

Complete the 60% → 100% on VeriSimDB integration in three slices (one PR each):

S1. Persist per-finding rows from assemblyline

• New StorageMode path: AssemblylineReport writes one hexad per WeakPoint instead of one envelope per repo.
• Subject = finding:<repo>:<sha>:<file>:<line>:<category> (stable across runs).
• Modalities: severity, description, language, framework, rule-id, first-seen-run, last-seen-run.
• Backwards-compatible: existing JSON output paths unchanged; hexad write is additive behind --store-hexads or env var.

S2. Campaign state hexads

• New subcommand: panic-attack campaign {start, register-pr, dismiss, status}.
• register-pr <finding-id> <pr-url> writes a pr-state: open modality.
• Polls GitHub (with http feature) to update modalities as PRs merge/close.
• status renders a Markdown report identical to the manual tracker checklist used in panic-attack estate sweep — 2026-05-26 #32.

S3. Cross-repo query

• panic-attack query <relational-expr> evaluates kanren over the persisted hexads.
• Examples:
  • (crosslang :from FFI :to ProofDrift) — proof code reachable from FFI
  • (category PA001 :severity Critical :pr-state nil) — open work
  • (diff :since 2026-04-12 :category PA022) — new CryptoMisuse since baseline

Why now

The estate sweep #32 is the first real consumer at scale: ~300 repos × tens-to-hundreds of findings each = the regime where JSON files become friction. If S1 lands during the sweep, the campaign becomes its own validation.

Out of scope

• HTTP push to a remote verisim-api service (VERISIMDB_URL env var) — useful eventually, not part of this issue.
• Replacing the audits/assail-classifications.a2ml file format (the a2ml registry is human-reviewable; the hexad store is machine state).
• New PA-categories (PA026+).

References

• src/storage/mod.rs — current StorageMode::{Filesystem, VerisimDb}
• src/assemblyline.rs:57 — report: Option<AssailReport> with #[serde(skip)]
• verisimdb-data/ — two prior AssaultReport hexads (2026-02-09, 2026-02-11)
• TOPOLOGY.md — "VerisimDB Storage 60%" line
• #32 — campaign tracker