Adversarial Audit

Run a deep, adversarial audit of the current codebase. This is not the mechanical verify/drift check — those confirm paths exist. This hunts for defects those checks categorically cannot catch: places where the code's actual behavior no longer matches what the code, comments, or docs say it does, or where a change elsewhere in the repo silently broke an assumption made here.

Read-only. Do not edit any file other than the report this command writes. Full-repo scope every run — do not sample or skip areas because they seem stable; staleness hides exactly where nobody looked recently.

What to hunt for

1. Stale cross-references — comments, docstrings, or user-facing strings describing behavior a later change invalidated. Search for "never", "always", "not yet available", "no writes unless X", "once available", TODO, and version/feature gates — then verify the referenced behavior against the current code, not what was true when the comment was written.
2. Unquoted/unescaped interpolation — any generated shell command, CLI suggestion, file path, or subprocess argument built by string concatenation or a template literal without quoting/escaping. Check every subprocess spawn/exec call and every "here's the command to run" string for inputs that could contain spaces or shell metacharacters.
3. Platform-specific gaps — subprocess calls or path handling that assume POSIX (missing a shell flag for .cmd-shimmed binaries on Windows, hardcoded path separators, case-sensitivity assumptions). Flag anything that has never actually been exercised cross-platform.
4. Ownership conflicts on generated files — any file written by more than one code path (scaffolded once, then continuously regenerated by a live process). Check whether "protect user edits" / backup / diffing logic correctly distinguishes "changed because it's supposed to" from "changed because a human edited it."
5. Mechanical vs. semantic validation gaps — places where an automated check only confirms a path or reference exists, not that the prose describing it is still accurate. List every place documentation makes a factual claim about code behavior and check it against the current implementation.
6. Cross-module consistency after incremental changes — for every function or module that references another component's state, existence, or capabilities, confirm that reference is re-validated, not assumed from when it was first written.

Method

• Locate code via ai/guide/MODULE_MAP.md first; don't crawl the whole tree blind.
• For any suspicious claim, reproduce it — run the command, exercise the code path, or trace the call — rather than reasoning from the source alone. Findings that were actually reproduced should say so explicitly.
• Prefer depth over coverage: a handful of concrete, reproducible defects beats a long list of speculative ones.
• Before opening a finding, check ai/analysis/audit-reports/DEFECT_TRACEABILITY.md for a prior audit row at the same location — don't re-report something already FIXED or tracked OPEN.

Output

Append a new dated audit section to ai/analysis/audit-reports/DEFECT_TRACEABILITY.md (create it, following its existing row format, if this is the first audit) with one row per finding — ID, severity, status (OPEN until fixed), location, defect, root cause, trace — and write the full evidence/repro for each finding to ai/analysis/audit-reports/ADVERSARIAL_AUDIT_<YYYY-MM-DD>.md, tagged [inferred] until a human reviews them. One line per finding in the summary:

path:line — issue — concrete failure scenario — suggested fix

Order most-severe first. No architecture summary, no restating what the code does — only defects and risks with evidence.

Then report the finding count and the top 3 by severity directly to the user.

What this does NOT do

• Does not fix anything — that is a separate, explicit follow-up task the user asks for after reviewing the report (typically via /fix-bug).
• Does not replace verify/drift (mechanical path checks) or review-agent-config (CLAUDE.md/AGENTS.md structure) — this is deliberately the one check in the kit that requires judgement instead of a deterministic script.
• Not a CI gate: it is non-deterministic and costly. Run it periodically (before a release, after a large refactor), not on every push.