/sota-audit

description: Audit this codebase against the library — agree the scope first, route from the surfaces rather than from whatever happened to get loaded, walk each skill's Audit checklist item by item, ask the questions that need a decision, then fix what you agree to. Run it when a piece of work is finished, or on arriving in a codebase you did not write.

Audit this codebase against the library's rules — how far they were applied, not how good the code feels.

It is the third position in a session: `/sota-resume` opens one, `/sota-close` shuts one down, this one checks the work in between against the standard it was supposed to meet. It is also the first useful thing to run in a codebase you did not write.

**What separates it from a defect hunt.** A generic review asks *is this code wrong?* This asks *which of the library's rules own this surface, and does the code satisfy them?* So the dominant finding is not a bug. It is a rule that owns real surface area and was never applied — and behind it, a control that is present and enforces nothing.

0. The work is the subject. Your memory of it is not

If this session wrote the code, you are auditing yourself, and re-reading your own summary re-runs the reasoning that produced it — the weakest check available. Every claim below is made against an artifact: `git diff`, the file on disk, the command run a second time. **A file quoted verbatim into context earlier is not primary either** — it may predate an edit made since. Re-read the path.

Self-audit fails in one direction: **false negatives**. You will agree with yourself, because the reasoning that produced the code is still loaded. The only counter that works is to walk the checklists rather than to recall the work — an item you cannot remember deciding is an item you did not decide.

1. Agree the scope before reading anything

Scope decides the answer, and the wrong scope does not error — it returns **clean**. Enumerate the candidates that actually exist here, size each one, and stop:

git status --porcelain | wc -l                  # uncommitted work
git ls-files | wc -l                            # the whole repo

# Resolve the base into a variable and GUARD IT before using it. Keep stderr:
# git says why it failed, and that reason is the thing you report.
BASE="$(git merge-base HEAD origin/HEAD)"
if [ -n "$BASE" ]; then
  git diff --name-only "$BASE" | wc -l          # this branch vs its base
else
  printf 'base did not resolve — ask which branch to compare against\n' >&2
fi

**That guard is the whole lesson of this step, so it is written out rather than assumed.** Unguarded, `git diff --name-only "$BASE"` with `$BASE` unset and stderr dropped prints **`0`, exit `0`** — a clean denominator for a branch carrying five commits, offered to me as a scope I might pick. An empty comparand does not fail, it silently answers a different question (`sota-shell-scripting` rules/06 §2b).

Offer only what you could size, plus any subtree this session actually touched. If a command failed, name it and say why rather than dropping the option silently — an absent scope and an unsizeable one look identical in a list. **Print the denominator beside every candidate.** `0 findings over 0 files` and `0 findings over 900 files` are the same sentence and different answers (`sota-code-security` rules/11 §2.2).

Then say what the chosen scope *excludes*, and do not quietly widen it later. A scope that grew mid-pass makes every count in the report unreconcilable.

**If what I pick is larger than you can hold at once, partition it and say how** — by subsystem, by entry point, by directory — and finish each partition before opening the next. Skimming a large scope returns a clean result for the same reason the wrong scope does, and nothing in the output distinguishes the two (`sota` router `rules/01` §1a).

2. Route from the surfaces, not from what happened to be loaded

**This is the step that decides whether the audit can find anything at all.** A session that never routed will look perfectly compliant, because nothing was being compared against.

So rebuild the list from the tree, not from context: languages, entry points (HTTP routes, queues, cron, webhooks), data stores, CI config, Dockerfiles, IaC, shell scripts, anything an agent loads as instructions. Map each onto its owning skill with the `sota` router's routing table, then print a coverage table before reading a single rules file:

| surface found | owning skill | loaded? | if not, why |

**An unexamined domain is not a clean one.** A domain with no matching surface is a legitimate skip and says so in the table; a domain nobody opened is a hole in the audit and must be reported as one, not omitted.

<!-- count-check: ^- \*\* --> Three things join the standard beside the skills:

• **The stack profile.** `~/.claude/profiles/*.md`, if one exists, is the expected baseline

in AUDIT mode (router principle 4) — a deviation from it is a finding even when the generic rule is satisfied.

• **The project's own written conventions.** `CLAUDE.md`/`AGENTS.md`, `CONTRIBUTING`, ADRs,

the invariants a repo enforces on itself. Inside its own tree a project's stated convention outranks a general default. Where the two genuinely conflict, **say which you followed and why** — do not pick silently, and report the collision.

• **Day zero.** No secret scan in any hook or CI job, no licence file, no agent file, and a

short history together mean nothing enforces any of this, and that is the first finding — above whatever the code does. Offer `scripts/init-gates.sh`; never run it unasked.

3. Walk the checklists — silence is not a verdict

For every rules file you loaded, take its `## Audit checklist` item by item and mark each **met · not met · not applicable, with the reason**. Not "reviewed". An item you skip because it obviously holds is exactly the item that goes missing: the cross-cutting ones — abuse control, transport enforcemen