demock

Find candidates for a test double, a swallowed failure or a placeholder on the real code path with the bundled script, read each one, and propose the real dependency or an honest failure before anything is fixed.

Goal

A real code path runs what it claims to run: a success means the work happened, and a failure surfaces with its cause. The scope is what the human named: files, directories, a diff, or the change just made. The run never picks its own target.

The run reports each finding with its location, the evidence that it is reached from the real path, its class and its proposal; then, for each item the human approved, the test that failed first and the fix. A run whose scope holds no finding changes nothing and says so.

Workflow

1. Split real paths from test paths first. Read the repository's test convention from its test directories, file naming rules and test configuration. A real path is code reached from an entry point (build output, an export, a handler, a CLI): trace it through imports and calls, including what dependency injection or a registry wires in. Code nothing reaches is dead, not a finding here; report it for a cleanup pass.
2. List candidates. From this skill's folder run node scripts/scan.mjs <paths...> [--test-glob <glob>]... [--json] over the scope, adding a --test-glob for each test path the repository's convention names beyond the defaults. It prints each candidate outside the test paths with its file, line, kind and evidence text; --json prints one JSON object. Exit codes: 0 no candidate, 3 candidates, 2 a usage error. An exit of 2 is a broken run: fix the command and run again. A name match is a lead, never a verdict.
3. Add the repository's own linter rules. When the repository already uses a linter carrying swallowed-failure rules (ruff BLE, S110 and S112, ESLint no-empty, Go errcheck), run those rules through the repository's own scripts or locally installed binaries at the version it declares, and add their hits to the candidates. Install no new tool.
4. Read and classify each candidate. Class (a) is a test double on the real path. Class (b) is a false success: a catch that turns a failure into a success, logged or not, a fallback whose caller cannot tell it from the real result, or a gate on access, spending, deletion or a counted signal that lets the request through when the secret, dependency or input it checks is missing. Class (c) is a placeholder: an unfinished implementation the real path reaches. Class (d) is intended: a seam where the real implementation is chosen at runtime, a degradation the caller can see (a typed empty result, a flag, a documented status) and is designed to handle, an offline mode documented and off by default on the real path, or code a production build excludes. Keep (d) with its evidence. When reaching the real path cannot be confirmed, give the candidate its class and proposal and mark it unverified.
5. Propose a fix for each (a), (b) and (c): the real dependency that should run, or an honest failure that surfaces the cause; for a gate that lets requests through, the honest failure is a denial. Never propose swapping one fake for another.
6. Stop and report. Report the findings and their proposals, including any pattern the script missed, and end the run. The human approves by naming the items to fix; nothing else changes.
7. Fix one approved item at a time. First write a test that fails on the fake, proving the real path runs or the failure surfaces; then fix the item and rerun the repository's checks.

Rules