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.