panic-attack (advisory): 10 critical + 1 high on standards — 8 come from an outdated pin, 3 are already tracked #1306

Summary

Since #1256, the Hypatia scan workflow really runs panic-attack, as an advisory step that never gates. On main it reports 10 critical, 1 high and 25 medium unsuppressed findings for this repository. Nothing has been tracking them; the earlier panic-attack triage issues (#178, #313) closed in August.

Most of the count comes from the scanner's pinned version, not from this repository's code:

Both rows come from a local build of each commit (cargo install --git … --rev <sha> --locked), run as CI runs it: panic-attack assail . --output report.json, counting weak_points with suppressed != true. The pinned row matches CI's step warning on main ("10 critical and 1 high").

The 11 critical and high findings

1. Eight of the ten criticals come from the outdated pin

UnboundedAllocation is a keyword heuristic. It fires on a whole file, with no line number, when the file contains, for example, read_to_string or read_to_end without .take( or a limit word. panic-attack downgraded it upstream in 3f7d0bb (2026-06-13), "fix(assail): UnboundedAllocation is Medium, not Critical". The comment in src/assail/analyzer.rs says that at Critical this one matcher was about 70% of all Criticals across the estate. CI's pin 2dc1393c predates that fix by 11 days and is 86 commits behind panic-attack main. The four live tools in rows 5–8 are local CLIs that read files from the repository itself.

Bumping PANIC_ATTACK_SHA changes the advisory counts for every caller of the reusable workflow, which is the point, so the bump should be measured first.

2. The three real items are already owned elsewhere

• Rows 9–10 are archived satellite demo scripts. Hypatia already acknowledges them (Hypatia shell-exec patterns: download_then_run_shell + eval_in_shell (13 instances) #939), and WO-4 (docs(reorg): work orders for the first execution wave (2026-10-19) #1298) freezes the archive.
• Row 11 disappears when WO-5 deletes the Python deed tools. deed_lint.js is the validator .claude/CLAUDE.md names.

3. Rows 9–10 cannot currently be acknowledged in panic-attack

panic-attack at both commits has two suppression routes, and neither works here:

• The inline marker // panic-attack: accepted applies only to a finding that carries a line number. That is the "same or preceding line" rule in apply_v255_context_suppression, and these findings have none.
• The classification file is .panic-attack-classifications.a2ml (or audits/assail-classifications.a2ml), and A2ML is retired in this estate (D99, D269c, D312, D313). This repository cannot add one.

That leaves an owner decision, either:

• exclude 9-archive/ from the assail scope, which is consistent with WO-4's archive freeze, or
• have panic-attack accept a deed-format classification file upstream.

Readiness grades

The Grade B evidence line now reads "status: ran with zero critical and zero high". READINESS.md declares Grade C, so nothing conflicts today. After the pin bump and WO-5, rows 9–10 are the only blockers left for that line.

Proposed steps

• Bump PANIC_ATTACK_SHA in .github/workflows/hypatia-scan-reusable.yml to a current panic-attack commit. Re-measure, and check that the panic-attack-v1-… cache key follows the SHA. This is an estate-wide reusable workflow, so the step stays advisory.
• Land WO-5, deleting the Python deed tools. That clears row 11.
• Owner decision on the archive: exclude 9-archive/ from assail, or ask for a non-A2ML classification format upstream. That clears rows 9–10.
• Re-measure on main. Close this issue when the step reports status: ran with 0 critical and 0 high, or when the remaining items have an explicit, recorded acknowledgement.

Out of scope: the 25 medium findings (37 on current panic-attack). They are mostly CommandInjection and PathTraversal heuristics in scripts/.

Nothing was changed to open this issue. No licence content is involved.