Skip to content

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

Description

@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

Activity

  1. hyperpolymath commented on May 30, 2026

    @hyperpolymath
    OwnerAuthor

    Temporal.chpl::writeTemporalHexad is the Chapel-side producer for
    mass-panic temporal snapshots, which feed the VeriSimDB hexad readers
    this issue tracks (S1 per-finding, S2 campaign-state, S3 query).

    PR feat/chapel-ci-strict-gates lands six strict CI gates on the
    chapel/ tree and the Chapel↔Rust contract:

    Gate What it catches
    chapel-parse-check Chapel syntax regressions in any of 4 modules + smoke
    chapel-build Cross-module build break (stock ubuntu .deb, no toolbox)
    chapel-smoke RepoResult → SystemImage → JSON data-flow regressions
    chapel-e2e mass-panic full pipeline end-to-end (single-locale)
    chapel-cli-contract Rust clap drift breaking Chapel's argv shape
    chapel-rust-diff Aggregate divergence between rayon and Chapel paths

    The four silent-loss fixes (path, high_count, error,
    category_breakdown previously dropped by writeNodeJson) mean
    the producer side now preserves every ImageNode field the hexad
    consumer can persist. Mapping of Chapel writers → hexad facets:

    • provenance ← Temporal.chpl (tool, version, locales, scan_surface)
    • temporal ← Temporal.chpl (timestamp, sequence_number, label)
    • semantic ← Imaging.chpl (global_health, global_risk, totals)
    • structural ← Imaging.chpl (totalFiles, totalLines, riskDistribution)
    • document ← Imaging.chpl::writeSystemImageJson (full SystemImage)

    Out of scope here, tracked for Wave 2:

    • True multi-locale CI (CHPL_COMM=gasnet install).
    • Subprocess kill-path on hang.
    • NFS journal lock semantics.
    • BoJ-estate scheduler benchmark to back the "~5–15% slower" claim.

    See docs/adr/0001-chapel-distributed-scanner.md for the full
    rollout decision record.

  2. hyperpolymath commented on May 30, 2026

    @hyperpolymath
    OwnerAuthor

    ✅ Resolution

    All three slices specified in the issue body have shipped to main. The full closure trail (verified against the code in main at 2d35425):

    S1. Persist per-finding rows from assemblyline — DONE

    S2. Campaign state hexads — DONE

    S3. Cross-repo query — DONE

    Bonus surface

    • panic-attack sweep-tracker subcommand (src/sweep_tracker/mod.rs) joins S1 + S2 hexads into a hierarchical (by_repo / by_category / both) Markdown report, in addition to the flat per-finding table from campaign status.

    Out of scope (deferred — not blocking close)

    • HTTP push to a remote verisim-api (VERISIMDB_URL) — listed as out-of-scope in the issue itself.
    • New PA-categories (PA026+) — explicitly out-of-scope in the issue.
    • Replacing audits/assail-classifications.a2ml — explicitly out-of-scope in the issue.

    Verification

    Closing — TOPOLOGY's "VerisimDB Storage 60%" line can move to 100%, and the Patch Bridge "Phase 2 adds VeriSimDB hexad persistence" note can be marked complete for the campaign-state path (auto-retire-on-upstream-fix is the next slice on the bridge registry side, tracked separately).

  3. added 5 commits that reference this issue on May 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions