subsystem-map

## The Rule **Read `docs/architecture/CURRENT.md` FIRST** — before any grep, agent dispatch, or claim about what Genesis has or lacks. It is the canonical judgment-layer map: what each subsystem is FOR, its easy-to-forget mechanisms, maturity (live / shadow / dark), and do-not-touch edges. A claim of absence ("Genesis lacks X", "Genesis should add X") made without consulting the map first is a protocol violation — the 2026-06-30 audit produced 6/7 wrong infrastructure claims exactly this way. ## Workflow 1. **Locate the entry.** Find the subsystem entry (or entries) covering the capability in question. Entries claim modules in fenced `yaml subsystem-map` blocks — the union covers every top-level package in `src/genesis`, so "no entry mentions it" means you're using the wrong concept name, not that it doesn't exist. 2. **Trust but verify.** The map is judgment-layer, not ground truth. Check each entry's `verified: <sha> <date>` stamp; if its modules have moved since, re-verify the specific claim against the live tree before relying on it. 3. **Then enumerate.** For absence/existence conclusions, follow the audit protocol (procedure `codebase_audit` / dev-skill "Auditing Existing Capabilities"): enumerate the subsystem's module inventory, trace the call graph both directions, grep by concept with synonyms, and verify against RUNTIME state (env gates, logs) — the map tells you where to look, not what to conclude. ## Write-Back Duty After...