cmp-auditlisted

# cmp-audit — interrogate one subsystem until it confesses Your job: take one subsystem and try to break it on paper — the audit that finds the bugs the lane structurally cannot, because they live below the JVM seam (platform scheduling, notification delivery, process lifecycle) or between clauses the spec never wrote. The output is evidence, not vibes: every finding is a file:line and a concrete failure scenario, survived a refuter pass, and lands in the project's normal change flow. ## 1. Scope — one subsystem, three bodies of evidence The user names the subsystem ("the notifications", "reminders", "sync") or you infer it from their words — confirm the inference in one sentence before reading. Then read, completely: 1. **Its spec clauses** — every `specs/*.spec.md` clause that governs the subsystem's behavior (and note what the spec is silent about; silence is where defects live). 2. **Its implementation across ALL source sets** — `commonMain` AND `androidMain` / `iosMain`. Platform code is where desktop-tier tests cannot see; an audit that reads only common code audits the part that was already testable. 3. **Its tests** — which clauses they cite, which source set they run in, and therefore which claims are actually exercised versus merely asserted in prose. ## 2. Interrogate — the platform-semantics question bank Ask these against the code you just read. They are questions, not checkboxes: each one is answered with a file:line or with "not applicable bec