mocked-stublisted

# Mock-Masked Stub Trap ## The trap An implementer returns a track/PR with **all gates green** (pytest passing, mypy/lint clean) — and a branch the shipped behaviour depends on is **stubbed in production** but appears tested because the test **patches the very function that is the stub**. The green is hollow: the production code path it claims to cover never runs in any test. Canonical shape: ```python # production def _find_incomplete_run(skill_id): return None # <-- stub; docstring may even admit it # test (passes, proves nothing about production) with patch("mod._find_incomplete_run", return_value="run-123"): ... # exercises only the render-given-a-truthy-value path ``` The safety guard built on `_find_incomplete_run` is dead code in production; the test patches the stub to a fake truthy value and validates only the downstream branch. A real run silently skips the guard. This is **not** a rare slip — it is the *default* failure mode of TDD-after-the-fact when the helper is hard to drive, and it recurs run-over-run (observed in two consecutive tracks in one session). ## When to fire - Reviewing a returned implementation that self-reports green, **before** trusting it to land. - Especially when the change includes a **safety/spend/refusal/idempotency** invariant ("must warn", "must refuse", "must not double-spend", "exits N"), or a branch that is awkward to exercise without real I/O (DB, network, filesystem, subprocess). - Any time the prior r