harden

# harden — dedicated security review Look at the system the way an attacker would, then report what a defender must fix. This is the focused security pass; `inspect` covers general quality with a security *axis*, but a real hardening review deserves its own depth. Read [references/disciplines/security.md](../../references/disciplines/security.md) — the shared security reference (STRIDE, OWASP Top 10 + LLM Top 10, secrets, abuse cases). Read [CONVENTIONS.md](../../CONVENTIONS.md) for the workspace (§1), the ledger (§2), the resume sweep (§5), git isolation (§11), multi-agent rules (§8), grounding (§14), and freshness (§17 — check current CVEs/advisories against today's date), and workspace integrity (§20). ## Step 1 — Scope & threat model **The iron rule: no finding without a reachable path from an attacker to an asset.** A checklist item that fails in the abstract is not a finding until you can name who reaches it and what they get. Build the model before auditing, in this order: 1. **Assets** — what is actually worth stealing or breaking here? Credentials, personal data, money movement, the ability to act as another user, availability. Rank them; the audit's attention follows this list, not the checklist's order. 2. **Entry points** — every place untrusted input enters: routes and handlers, webhooks, queue consumers, file/image uploads, third-party callbacks, admin surfaces, CLI flags, environment and config. **The API is the surface, not the UI** — enumerat...