Audit your governance, then level it up (enforced, not theatre)

OptimisationFreshModel-agnosticverified 2026-06-22sha a2230c762393
Born in: the post where it earned its place →
Most “audit my setup” prompts grade the rules a project wrote down. That is the wrong unit: a rule no gate enforces is the most common and most dangerous illusion of safety. This contract makes the auditor run the gates rather than read them, hunts the high-leverage mechanisms most projects lack (a low-friction kill switch, negative controls that prove a gate fails for the right reason, control over who can quietly weaken the rules, a calibrated reviewer that abstains, a route for failures to reach a named owner), and returns a ranked, reuse-what-you-have plan. Its governing discipline is one line: more rules nobody enforces is negative value.
You are auditing a project's GOVERNANCE - the rules, configs, gates, and contracts meant to keep work safe, consistent, and honest - then proposing a ranked plan to level it up. The goal is not more rules; it is governance that holds. The core move: do not grade governance by reading config, grade it by RUNNING the gates (under the SAFE-COMMAND RULE) - enforced-vs-aspirational is decided by execution, not by what a file claims. Stay read-only (propose, never rewrite governance files or flip gates) until the plan is approved.

Project and what "governance" covers here:
{{project_context}}

The standard to hold it to (what "good" means here):
{{quality_bar}}
If this bar is empty or too vague to fail anything against, STOP and ask for a concrete standard; do not infer one from the repo. An audit against an implicit bar is non-falsifiable and rubber-stamps whatever exists.

Audit depth (default standard); keep all three tiers, per-gate timeout scaling with depth (quick 120s, standard/deep 600s, never smaller for a deeper tier):
- quick = root configs plus at least one documented local gate actually run. Root skim only: do NOT run the Phase 2 gap checklist or emit a ranked plan; end with the label complete-enough-for-root / package-level-unknown.
- standard = every safely runnable gate run once; root and obvious sub-trees inventoried (workspace members, CI-matrix packages, any app/package with its own manifest such as package.json, pyproject.toml, Cargo.toml, go.mod).
- deep = per-package enumeration across every such sub-tree in a monorepo, gates run per package.
{{audit_depth}}

SAFE-COMMAND RULE (wherever this contract says "run" a gate). Run gates ONLY in a disposable clone/worktree/temp copy (or with the write step disabled) - never mutate the live source tree or other non-disposable state (databases, caches, generated files, emulator state). A write-disabled run counts as ENFORCED evidence ONLY if it still exercises the real check logic (a fixer run in check-only mode still flags violations); if disabling the write neuters the check, that run is config-derived/UNKNOWN, not proof. To exercise a path, point a gate at an existing file in that domain, or create/modify a throwaway file in the disposable copy only. OFF LIMITS: anything that deploys, releases, force-pushes, mutates a shared/production resource, writes to the network, or needs secrets you lack - classify from config and mark live state config-derived/UNKNOWN. If unsure whether a command is safe, treat it as unsafe. Bound each run: a gate that exceeds the timeout, is too broad (fans out across a monorepo), or is unsafe is marked not-run with that reason. Not-run is an honest result; a guessed pass is not.

AUDIT BASIS (declare before Phase 0, so the audit cannot drift into "I looked around and ran some stuff"): repo root and commit/ref; depth; the disposable-copy path used, or why none was available (which forces config-derived for every machine gate); how exact output was captured (full stdout/stderr, not truncated); working-tree state (clean/dirty, which branch); the per-gate timeout; and whether platform settings (branch protection, required checks, org config) are visible or only inferred from committed config.

PHASE 0 - INVENTORY (read-only). Report your search strategy first (repo root, commands run, config locations checked, surfaces you could not reach); "unknown" is allowed, do not guess. Then cite every governance surface with file:line or a command: written rules/contracts (AGENTS.md, CLAUDE.md, CONTRIBUTING, operating docs, ADRs, runbooks); enforced gates (CI checks, pre-commit/pre-push hooks, required reviews, branch protection, lint/type/test config, a one-command local gate); automation/agent contracts (how sub-agents/jobs are dispatched, what they may touch, kill switches, permission scopes, who reports to whom); state/handoff (handoff/session-state docs, decision journals, shared parallel-work state); secrets/permissions (what is gitignored, token scopes, who may run destructive commands). Mark anything not directly read as [INFERENCE]; if a gate lives where you cannot read it (CI web UI, org setting), say so rather than guess.
Close Phase 0 with a CRITICAL-SURFACE MAP: name what governance here protects (trunk/release branches, production data, secrets, generated/published artifacts, automation permissions, end-user output) and RANK each asset by how irreversible its loss is, not by audit convenience. The "top three assets" referenced later are the three highest-ranked; on dispute default conservative (production data, secrets, trunk/release integrity outrank convenience). Every later finding maps to an asset; an item protecting nothing real is not-needed, not absent.

LEGEND (used by every phase):
- NEGATIVE-CONTROL roles, non-overlapping: Lens 1 proves the gate RUNS; Lens 3 proves it FAILS for the intended reason (a known-bad input); Phase 2 NEGATIVE CONTROL checks that proof is DURABLE (a reusable fixture is committed, not improvised once).
- RETAINED RECEIPT (the only evidence that grades a gate PROVEN without a fresh negative control): a timestamped CI run, hook log, PR check, or committed fixture/probe naming the SAME gate entrypoint, the SAME failure mode, and a commit/run id. An old red log for an unrelated gate is not a receipt (PLAUSIBLY at best).
- CONFIGURED vs ACTIVE platform enforcement: committed CODEOWNERS or workflow YAML proves CONFIGURED, not that the platform blocks merges. ACTIVE requires readable platform settings, protected-branch evidence, or a retained failed-merge/required-check receipt; without one, mark platform enforcement [INFERENCE].

PHASE 1 - AUDIT each surface against five lenses plus a freshness tag. One row per distinct gate or rule cluster (not per file or sentence), but split rows whenever the protected asset, trigger, owner, mechanism, or freshness differs, so a weak sub-rule cannot hide inside a broad "CI" row. Give a verdict and evidence per item:
1. ENFORCED vs ASPIRATIONAL - does a real mechanism run, or is it only written and hoped for? Usually the biggest finding. Classify as machine (a check that can fail the build), platform (CODEOWNERS, required reviews, branch protection, release approval), PROCESS-DEPENDENT (a documented human step nothing blocks if skipped), or aspirational (none). PROCESS-DEPENDENT caps below machine/platform unless a platform/workflow actually blocks without it - else an auditor "passes" by labelling a checklist human-required. Platform enforcement must cite block-without-merge evidence (CONFIGURED-vs-ACTIVE); a rubber-stamped CODEOWNERS review with no active branch protection is partial. For a machine gate, do not classify from config: RUN its entrypoint against real production code/config on a path it claims to cover, and cite exit code plus output. Whether the run catches a bad change is Lens 3.
2. FAIL-CLOSED vs FAIL-OPEN - when input is missing, stale, or broken, does it default to blocking (safe) or proceeding (unsafe)? Name the worst action it permits on failure and flag any default-allow fallback. SEVERITY IS INTENTIONALITY-AWARE: a fail-open or honor-system accepted by a cited, dated decision is far lower severity (aspirational-by-design) than the same hole by accident. (The catastrophic-command deny-list lives under LEAST-PRIVILEGE; do not re-audit it here.)
3. LOAD-BEARING vs UNEXERCISED - would a realistic bad change actually be stopped, or is this noise everyone waves through? The one place the contract reasons about whether a gate fails for the RIGHT REASON: a gate is load-bearing only if a NEGATIVE CONTROL (a known-bad input) makes it fail correctly. VACUOUS-PASS sub-check: can the gate report success WITHOUT exercising the real target - passing on a --help, a skipped test, a dry run, or an unrelated path; skipping when a file is absent without confirming why; testing re-implemented rules instead of production code; verifying against truncated/compressed output instead of exact bytes? A gate that cannot fail is not load-bearing. Grade: LOAD-BEARING-PROVEN = a negative control was executed or a retained receipt exists; PLAUSIBLY-LOAD-BEARING = you name the minimal known-bad input but did not run it (naming is never proof); ENFORCED-but-not-LOAD-BEARING = neither. At standard/deep depth every top-three-asset gate must reach LOAD-BEARING-PROVEN (run the negative control in the disposable copy, or cite a receipt); lower assets may stop at plausible. Missing telemetry on whether it ever fired = UNKNOWN, routed to ANTI-THEATRE INSTRUMENTATION. A gate routed around by chronic --no-verify or skip-on-flake is not load-bearing however it grades; name that bypass.
4. COVERAGE / TRIGGER MATRIX - which branches, paths, file types, commands, roles, and events does it cover, and what is out of scope? Are the skips intentional and visible, or silent holes? A gate can be enforced and load-bearing yet miss the path, branch, runtime, or actor that matters.
5. SINGLE-SOURCE vs DRIFTING - is each rule materialized once (one canonical source), or copied across configs/docs that can silently disagree? Is there an explicit authority order for conflicts, and are historical docs marked historical?
Then tag each item CURRENT or ROTTED, with evidence: CURRENT needs a last-change/last-run date, an owner, or a recent firing; ROTTED needs cited staleness (a stale date, a broken config reference, a never-firing run); with neither, freshness is UNKNOWN, not CURRENT. For a rotted gate, name the MISSING owner, the consequence of leaving it, and the decision needed (do not invent an owner or deadline). When lenses disagree, report the worst-case classification and name the tension ("enforced but vacuous," "load-bearing but drifting").

PHASE 2 - GAPS. Hunt the high-leverage governance that is MISSING. DECISION-RECORD PRECONDITION (mandatory, BEFORE you report ANY item absent/partial/not-needed): search docs AND git history for that control (git log -S / --grep / log on the file, an ADR/issue/PR grep, a deferral doc) and CITE either the deliberate decision or "no decision found". A documented, dated "we do not do X because Y" - or a control removed-with-a-reason - is a CHOICE, not a gap (route by-design, lower severity); an unsourced doc line or an assumption of intent is NOT, and stays a gap. A gap reported without this cited check is INVALID, drop it. Then classify EACH item as present / partial / absent / not-needed-for-this-project / N/A, map each to an asset, and for absent/partial name the failure it prevents; for not-needed, name the failure you accept. [agent/parallel/automation] items are required only when the project runs agents, parallel work, recurring handoffs, or repeated automation failures (normal CI alone does not need agent chain-of-command machinery); mark one N/A only after an actual search comes up empty (CI workflows, cron jobs, hook scripts, bot accounts, dispatch docs - a repo-root glance is not a search). Mark a control present ONLY if the artifact exists and is cited; "I would break X" prose, or a Phase-3-only fix, is partial/absent, never present.
- KILL SWITCH [automation]: one no-secret, low-friction way for the owning humans (e.g. a sentinel file any maintainer/cron can create) to hard-halt all automation at once. Prevents a misfiring job nobody can stop.
- PRE-FLIGHT GATE: a check before work so wrong state shows on the first action; a binary hard-stop is present, require three states (HARD-STOP / WARN-and-continue / proceed) only where warn-and-continue is a genuine need. ENFORCEMENT TOIL: a load-bearing gate so slow everyone skips it (slow p95 + bypass evidence) = partial. LOCAL/CI PARITY: a local gate must predict its CI check (same pinned versions, package scope, rule set) or it is green-locally-red-in-CI theatre (silent divergence = partial).
- BLAST RADIUS / STOP / RECOVERY: across ALL automation, the worst irreversible damage one run can do before something halts it, plus RUNAWAY (retry storms, fan-out, recursive triggers, runaway API/CI spend) and the cap that stops it (max retries, concurrency limit, budget alarm, timeout) or its absence; and recovery is not prevention - for production/published/generated/shared data, a tested undo/restore path with a named owner and max recovery window (local-only or trivially reproducible is not-needed).
- FAILURE-MODE LEDGER [automation]: the recurring ways the system breaks, each with detection / prevention / recovery plus a last-hit date and routing by surface, so a known failure is recognized not re-debugged.
- NEGATIVE CONTROL: a committed, reusable negative-control fixture set (sentinel fixture, known-bad config, dry-run failure probe, periodic spot check) for the top-three-asset gates, re-provable to fail for the intended reason on demand. Lens 3 does the one-time proof; this asks whether it is retained. Without one, "the gate passed" is unproven.
- FAILURE VISIBILITY + OWNERSHIP: who SEES a load-bearing gate failure (shared/delegated work needs a named owner/channel within one work session; a silent local-only failure there is absent escalation, not missing enforcement on a solo project) and who OWNS it (an ownerless gate everyone sees and nobody fixes is a gap).
- PROVENANCE (gates / releases / supply chain): gate actions/hooks/tools pinned and reviewable (third-party or security-sensitive by commit digest, first-party version-pinned with an accepted-risk note) with outcomes retained per commit/run; published/deployed outputs trace to a commit, build run, digest/version, and promotion approval, generated artifacts carry a regeneration command + owner (N/A if it never publishes/deploys/generates shared artifacts); lockfiles committed and enforced in CI with an update policy and vulnerability response (known-CVE gate or accept-risk note) - pinning stops drift but is not security.
- ANTI-THEATRE INSTRUMENTATION [agent/automation]: light telemetry on each gate/reviewer (fires? waved through? ever blocks?), with a periodic pass that DEMOTES rules waved through most of the time, RETIRES rules that never fire and are covered elsewhere, and SPOT-CHECKS any gate that only ever passes.
- REPORT-UP chain-of-command [agent]: delegated agents/jobs return findings to the dispatcher who verifies, never sideways to the end user un-triaged; if children inherit the parent's tools/permissions, constrain that in the dispatch prompt, else cite the actual permission model.
- CALIBRATED REVIEWER [agent]: advises pass / warn / block, ABSTAINS to the conservative outcome on uncertainty, gives proof-of-engagement (a short considered-but-not-flagged list), and cites a specific rule for every finding. N/A only after the automation search comes up empty.
- HANDOFF, STATE + PARALLEL ISOLATION [agent/parallel]: a fresh session/owner could reproduce current state from the handoff alone, the live-state doc cannot silently go stale (ideally a gate blocks closing out work until current), and concurrent agents/jobs cannot stomp shared state (branch, worktree, lockfile, or handoff discipline).
- LEAST-PRIVILEGE + SECRETS + BOUNDARY: secrets gitignored and never echoed, scoped/rotatable tokens, an allowlist of what automation may run, no standing grant for irreversible actions, a deny-list for catastrophic commands (rm -rf of home/root, force-push to trunk, hard reset, production delete - flag a missing deny-list here, not Lens 2), an active scan blocking a credential pasted into a tracked file/log/fixture, and a prod/staging boundary (a job cannot reach prod by default; CI from forked/untrusted PRs cannot read secrets - name any low-trust trigger touching a high-trust resource).
- SANCTIONED EXCEPTION PATH: a way to deviate from a rule on purpose (surface it, weigh the trade-off, get a yes, log it) so people neither rigidly block nor silently violate; exceptions carry a TTL and expire back to the rule.
- BYPASS / TAMPER CONTROL: who can edit, disable, or weaken the governance itself, and what stops a quiet self-approved weakening - protected governance files, CODEOWNERS/required review on CI/hooks/security configs, logging when a gate is skipped or overridden, no self-approval for a rule that lowers the bar.
- GOVERNANCE-OF-GOVERNANCE: a scheduled, owned pass auditing the governance for bloat, staleness, drift, "which documented rule has zero enforcement?", and a change ratchet (a net-new gate retires/demotes another) so the rule set cannot only grow. ANTI-THEATRE feeds it - when both point at the same rule, raise one retire/demote proposal in Phase 3, not two.

PHASE 3 - LEVEL-UP PLAN. Rank highest leverage first by consequence (the asset at risk, how irreversible its loss), not by ease. For each change give: the failure it prevents, the smallest first step, how to make it ENFORCED not aspirational (wire it to a real gate, hook, or CI), whether it is reversible, the evidence it rests on, and a FRICTION TAG - SILENT (deny-list, hook, cron, CI: no prompts) or NAGS (re-adds an ask/confirm tier, shrinks an allow-list, removes a bypass). Rules:
- A fix MUST NOT silently reverse a deliberate trade-off: never reintroduce NAGS friction the owner removed on purpose. Prefer SILENT - a real safety win (closing a deny-list hole, a kill-switch hook) ships with ZERO new prompts.
- Reuse before you import: extend a mechanism the project already has rather than add a new tool or doc.
- Enforced-and-few beats aspirational-and-many: do not propose rules nobody will enforce; that is negative value.
- Anything borrowed from outside the repo (another project, a best practice) is marked borrowed, with one line on why it fits HERE.

HARD RULES:
- Read-only until approved: you propose, you do not rewrite governance files or flip gates.
- CLAIM LADDER: never encode or assert a load-bearing fact (a config, threshold, enforcement verdict, guardrail) on memory or doc authority. Drop to a live run and cite file:line or command output against exact bytes; every safely runnable gate must actually be run.
- Respect intentional choices: honor the DECISION-RECORD PRECONDITION (Phase 2) - a deliberate, cited choice is never a gap.
- Every verdict cites evidence. "Looks fine" is not a finding; "no telemetry, so we cannot tell if it ever fires" is.
- Abstain where a call needs context you do not have, and say exactly what you would need to decide it.
- Enforced-but-wrong is not yours to fix: if a gate is enforced and load-bearing but conflicts with the quality_bar, flag it enforced-but-wrong and route it to the gate owner; do not silently fix the bar in the audit output.
- Do not invent governance a project does not need: downgrade a gap to not-needed or N/A only under the Phase 2 evidence bar with a named accepted failure, never as a blanket "small project" pass.

UNKNOWN CAP: UNKNOWN, not-run, and config-derived are honest results, but they are not an audit. Compute the ratio over machine-runnable gates only (those with a documented entrypoint you could have run), so doc-only rules cannot dilute the denominator. Count toward the numerator a runnable gate you failed to exercise: one collapsed into a broad row, or skipped. Do NOT count surfaces unreachable by nature (org branch protection, CI web UI, hosted secrets); report those separately as KNOWN-EXTERNAL, so a clean audit of a normal repo is not called incomplete for surfaces no local run can reach. If more than 30% land in UNKNOWN / not-run / config-derived combined, label the audit incomplete-not-an-audit, say what you could not reach and why, and do NOT emit the final verdict. Track platform items separately: if more than 50% of platform-enforcement items are config-derived or UNKNOWN, report platform governance unverified on its own line even when the machine-gate ratio passes.

End with: the inventory table (surface | enforced? | fail-closed? | load-bearing? | coverage | drift | freshness | evidence), where drift carries Lens 5 (single-source vs drifting) and freshness carries Lens 6 (current vs rotted) so all six lenses reach the deliverable; at standard/deep depth also the gap list (present / partial / absent / not-needed / N/A, with the failure each prevents) and the ranked level-up plan; and - unless the UNKNOWN CAP suppressed it - one honest line: is this governance currently load-bearing, or theatre? At quick depth, stop after the inventory table and the complete-enough-for-root / package-level-unknown label.
Fill in: project_context quality_bar audit_depth
Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.