The failure this probe hunts has a specific shape [2]. The reviewer retrieves a genuine artifact, quotes it accurately, and applies it after the team stopped honoring it. Both the old decision and its replacement are real files, and the bug is that the reviewer ranked them by the wrong key. That is why the fixture leaves the superseded module on the main branch instead of pre-deleting it [6]. metrics_service.py is 120 lines and telemetry_service.py is 140 [4], so the two sit 20 lines apart in a shared vocabulary [24], and only 43 days separate the ADR that blessed the first pipeline from the ADR that renamed it [22]. If your reviewer ranks context by similarity, the legacy file's own body gives it no reason to suspect it is dead code; that verdict exists only in the Markdown decision record sitting elsewhere in the repo [3].
One prompt line does most of the grading work: do not flag a difference from deleted code as a regression unless the deleted behavior is still enforced by a live decision file [11]. Paired with the requirement to cite an exact path for every convention claim [12], that turns "don't be stale" into something a hiring panel can diff against a filename.
The seeded bug is deliberately orthogonal to the memory question. transmit sends an empty payload with no guard [8], and the expected fix is an early raise ValueError before client.send [13], while the consistency section wants the rename accepted as correct per ADR-0012 and the deletion read as expected rather than churn [14]. A candidate can pass one section and fail the other in either direction, which is why the sections are scored separately [10]. The reference solution requires nothing under uncertain, though it credits a review that asks whether downstream callers were migrated before the module vanished [15].
The dev.to write-up's case for two phases is that a single-shot snapshot test cannot observe memory effects at all [21], and I accept that. My objection is narrower: the priority ordering is printed in the candidate's own prompt [9]. A bot scoring 90 has demonstrated that it can follow a ranking it was handed; inferring that same ranking unprompted from the repository is a separate and harder skill [16]. Withholding the list is the harder experiment, and no rubric is supplied for it.
There is also an unscored trap. pyproject.toml disables E501 for telemetry only [5], and phase one touches pyproject.toml [7], so a candidate that reads the diff learns the exemption is scoped to the new module. Line length appears nowhere in the reference solution's three sections [13][14][15], so a candidate who flags it is arguing outside the graded rubric, not failing it.
Two conditions have to hold for the score to transfer to your repo. Your conventions have to exist as files, because tier one of the priority list is docs/decisions/*.md and DEPRECATED.md [9]; if the rename lives in a chat thread, the candidate is graded on tiers two and three by default. And your reviewer needs a machine-readable review mode, since the harness takes the reviewer as a CLI argument shaped like monkeycode review --json [18]. Reporting a verdict to a hiring panel as 409 [16] is a rubric written by someone who has had to explain a blocked migration in a standup.
The 90 threshold [16] is worth treating as provisional. It rests on one fixture, two PRs, and one seeded bug [8]. That is a sample of one conflict, and the result it produces is specific to this rename: a passing score shows the candidate handled this particular case, not that it would handle renames generally.
