harness-audit

1# Audit the four rings
2 
3Theory: [The four rings](https://secondbrainos.dev/#/read/course-4-harness/the-four-rings)
4and [Harness practice](https://secondbrainos.dev/#/read/course-4-harness/harness-practice).
5Build from the outside in: containment, guides, sensors, permissions. The
6order matters because each ring must hold when every ring inside it fails —
7a guide can be ignored, a sensor can miss, an approval can be misclicked;
8a wall does not care.
9 
10## Core rule
11 
12Report and rank; never harden anything yourself. The audit's one organising
13question is the blast radius: describe the worst session possible under the
14current setup and what it costs. If the user asks you to apply fixes
15afterwards, that is a normal edit session, not this skill.
16 
17## Workflow
18 
191. **Ring one — containment: what can it physically reach?** Where does the
20   agent run: the user's checkout or a worktree/container? Which credentials
21   are in its environment — a read-only database user or the application's?
22   Open internet or an allowlist? Real API keys or test keys? The finding is
23   one sentence: "the worst session deletes X and spends Y."
242. **Ring two — guides: what does it read before acting?** Find CLAUDE.md /
25   AGENTS.md and tool descriptions. Every line should be a rule the agent
26   can act on — flag philosophy, history, and anything over roughly a page.
27   Flag missing rules for the repo's real landmines (migrations, generated
28   files, deploy scripts).
29…