/sota-deep-audit

description: The heavy audit — a hostile review of a whole repository by someone who will inherit it: the threat model reconstructed from the code and a control-presence matrix built against it, then code, history, decisions, results and forward plan, fanned out across independent agents, load-bearing claims re-measured this session or labelled unverified, every serious finding handed to a refuter that is not you. Expensive; run it at a milestone, an inheritance or a go/no-go, not routinely.

A hostile review of this repository by someone who will inherit it and distrusts every prior claim. Discover the domain, stack and conventions yourself — read the agent file, README, docs and config first. Assume nothing about what this project does.

**This is expensive.** It fans work out across many agents, re-runs suites, and can re-measure benchmarks in heavyweight environments. That is the point of it, and it is the reason not to reach for it by default: [`/sota-audit`](sota-audit.md) answers *were the rules that own this surface applied?* in one context, cheaply enough to run repeatedly. **Tell me the plan and the split before you fan anything out**, so I can stop it if the scope is wrong.

What this adds that `/sota-audit` structurally cannot

<!-- count-check: ^[0-9]+\. \*\* --> Five things, and only these five justify the cost. If none of them is what I need, say so and point me back at the cheap command.

1. **Independence.** `/sota-audit` refutes its own findings from the context that produced them, which still holds the reasoning that produced them. Here every serious finding goes to an agent that did not find it, prompted to kill it. 2. **Scale.** `/sota-audit` also partitions a scope too large to hold at once, but it does so *within one context*, finishing each partition before the next — so the last partition is read by a context already full of the first. Here the partitions go to **separate agents**, each starting clean (`sota` router `rules/01` §1a). 3. **Decisions re-measured, not just reconstructed.** Where a past decision rests on a number, that number is produced again *this session*, including in environments that are slow or awkward to stand up. 4. **A forward look.** Whether the current plan is still the right one, given what the audit actually found. 5. **A reconstructed threat model.** `/sota-audit` checks the code against rules that already exist; it never asks what this system is *worth attacking for*. That reconstruction is a timeboxed pass of its own, run ahead of the lenses because its output decides what everything after it weights.

Ground rules

**Validate; never trust the prose.** Docs, comments, commit messages, roadmaps and any memory or notes describe *intent* or *the past*. Every load-bearing claim is verified against the code, the data and a real run this session, quoted as evidence — test counts, measured numbers, command output, `file:line`. A claim you cannot back with evidence you produced is labelled **UNVERIFIED**, with the thing that would confirm it named.

**Run what matters.** Execute the test suite and the cheap local checks. Where a decision hinges on a measured result — a benchmark, a recall or false-positive rate, a latency, any "this is faster/safer" — re-measure it, including in heavyweight or special environments (containers, GPUs, integration harnesses) when that is the only way to confirm it. Respect this project's documented environment constraints and teardown rules: destroy what you rent, commit no secrets. If you genuinely cannot run something, say so and mark everything that depends on it UNVERIFIED.

**Watch a check fail before believing it passed.** A suite that matched zero files exits 0 and prints `ok`; a gate whose environment cannot reach the defect is green and proves nothing. Say what depth each check actually reached (`sota-devsecops` rules/09 §2a, §2b).

**Report faithfully.** Failures, skips and uncertainty are stated plainly with the evidence. No confident summary papering over a gap.

Route before you fan out

Recon first — languages, entry points, data stores, CI, IaC, LLM surfaces, anything an agent loads as instructions — then map what you found onto the domain skills with the `sota` router's routing table. Those skills' AUDIT sections and per-rules-file Audit checklists are the **what** of lenses 2 and 3; the lenses are the **how**. Load lean: only the rules files with real surface area here.

**Record which domains you skipped and why.** A domain with no matching surface is a legitimate skip. A domain nobody opened is a hole in the audit and is reported as one.

Reconstruct the threat model first — its output prioritises everything below

This comes **before** the lenses, not inside lens 3, because a finding rated without trust boundaries is rated in a vacuum (router AUDIT step 2). Timebox each phase and say which you cut short (`sota-threat-modeling` rules/06 §1).

1. **Collect, and record what you were not given.** Repos, lockfiles, IaC, CI configs, container and cluster manifests, any existing architecture or threat-model docs, `.env.example`, OpenAPI/proto specs. **Surface you could not audit goes in the report as un-auditable** — never silently dropped. 2. **Extract the system model from the code, not from the docs** — entry points by mechanism, stores and assets, the actor and privilege table, and the trust boundaries the system *actually* has rather than the ones it claims (`sota-threat-modeling` rules/02 §5, §7, §8). **Output the reconstructed DFD.** It is deliverable one even if nothing else is found: most teams have never seen their real attack surface drawn. 3. **Write down the implied assumptions**, from auth middleware, IaC structure, old ADRs, comments. *Services trust the gateway's headers. That bucket is private. Only the worker reaches the queue.* Each one becomes a test target. 4. **Run the component catalogs** against e