write_path_rule reported zero_result_calls: 0 and cleared_threshold: 133/133 — a perfect record no other surface comes near (write_path 421 zeroes of 613, reuse_slot 124/199, auto_inject 114/326). #3311 read that as a measurement, and milestone 333 was scoped on it.
It was an artifact. Both arms called record_retrieval inside a guard on having results — the write-path arm behind if fresh:, the pre-tool arm below if not fresh: return out — so a call that found nothing wrote no row. The statistic was a fact about the shape of the code, true at any threshold whatsoever.
What changed
The call log moves out of the guard in both arms. The surfacing log stays in it: nothing was shown, so no surfacing occurred.
results=fresh kept deliberately. The note arms pass exclusions into semantic_search_notes, so what they log is already post-exclusion; logging hits here would make this row mean something other than every other row in the same readout.
Six regression tests — behavioural for each arm (found nothing; found only what the session already held; searched nothing at all, which must stay silent) plus a structural guard, because this was one level of indentation that appeared independently in two places.
test_telemetry_uses_its_own_source had encoded the defect: its assert_called_once passed only because the rule arm skipped its row. Rewritten to assert the source split it was actually about.
The defect bites hardest on the pre-tool arm (#3476), which fires on every Bash call: with no rows at all, a ranker that declined is indistinguishable from a hook that never fired — the silent failure that arm exists to stop.
Why this merges now
The deployed instance is actively writing the contaminated rows that milestone 333 step 4 has to read. Every hour it runs unfixed is analysis window that has to be discarded.
#3311 and the rule_usage module docstring are corrected rather than quietly rewritten — the wrong version stays visible, since the reason to measure the arm survives the correction and is stronger for it.
CI green on dev @ 48804c4 (run 5450, all six jobs).
`write_path_rule` reported `zero_result_calls: 0` and `cleared_threshold: 133/133` — a perfect record no other surface comes near (`write_path` 421 zeroes of 613, `reuse_slot` 124/199, `auto_inject` 114/326). #3311 read that as a measurement, and milestone 333 was scoped on it.
It was an artifact. Both arms called `record_retrieval` inside a guard on having results — the write-path arm behind `if fresh:`, the pre-tool arm below `if not fresh: return out` — so a call that found nothing wrote no row. The statistic was a fact about the shape of the code, true at any threshold whatsoever.
## What changed
- The **call** log moves out of the guard in both arms. The **surfacing** log stays in it: nothing was shown, so no surfacing occurred.
- `results=fresh` kept deliberately. The note arms pass exclusions into `semantic_search_notes`, so what they log is already post-exclusion; logging `hits` here would make this row mean something other than every other row in the same readout.
- Six regression tests — behavioural for each arm (found nothing; found only what the session already held; searched nothing at all, which must stay silent) plus a structural guard, because this was one level of indentation that appeared independently in two places.
- `test_telemetry_uses_its_own_source` had encoded the defect: its `assert_called_once` passed only because the rule arm skipped its row. Rewritten to assert the source split it was actually about.
The defect bites hardest on the pre-tool arm (#3476), which fires on every Bash call: with no rows at all, a ranker that declined is indistinguishable from a hook that never fired — the silent failure that arm exists to stop.
## Why this merges now
The deployed instance is actively writing the contaminated rows that milestone 333 step 4 has to read. Every hour it runs unfixed is analysis window that has to be discarded.
#3311 and the `rule_usage` module docstring are corrected rather than quietly rewritten — the wrong version stays visible, since the reason to measure the arm survives the correction and is stronger for it.
CI green on `dev` @ `48804c4` (run 5450, all six jobs).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ
`write_path_rule` reported `zero_result_calls: 0` and `cleared_threshold:
133/133` — a perfect record no other surface comes near (`write_path` 421
zeroes of 613, `reuse_slot` 124/199, `auto_inject` 114/326). #3311 read that
as a measurement and milestone 333 was scoped on it.
It was an artifact. Both arms called `record_retrieval` inside a guard on
having results — the write-path arm behind `if fresh:`, the pre-tool arm
below `if not fresh: return out` — so a call that found nothing wrote no row.
The statistic was a fact about the shape of the code, true at any threshold
whatsoever.
The call log moves out of the guard in both arms. The surfacing log stays in
it: nothing was shown, so no surfacing occurred. `results=fresh` is kept
deliberately — the note arms pass exclusions into `semantic_search_notes`, so
what they log is already post-exclusion, and logging `hits` here would make
this row mean something other than every other row in the same readout.
The defect bites hardest on the pre-tool arm, which fires on every Bash call:
with no rows at all, a ranker that declined is indistinguishable from a hook
that never fired — the silent failure the arm exists to stop.
Tests cover both arms behaviourally (found nothing; found only what the
session already held; searched nothing at all, which must stay silent) plus a
structural guard, because this was one level of indentation and it appeared
independently in two places.
#3311 and the `rule_usage` docstring corrected rather than quietly rewritten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ
`assert_called_once` held only because the rule arm skipped its retrieval_logs
row when it found nothing. With the arm logging every call, the test now
asserts what it was always about — exactly one `write_path` row, no
`auto_inject`, and the rule arm keeping its own separate source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
write_path_rulereportedzero_result_calls: 0andcleared_threshold: 133/133— a perfect record no other surface comes near (write_path421 zeroes of 613,reuse_slot124/199,auto_inject114/326). #3311 read that as a measurement, and milestone 333 was scoped on it.It was an artifact. Both arms called
record_retrievalinside a guard on having results — the write-path arm behindif fresh:, the pre-tool arm belowif not fresh: return out— so a call that found nothing wrote no row. The statistic was a fact about the shape of the code, true at any threshold whatsoever.What changed
results=freshkept deliberately. The note arms pass exclusions intosemantic_search_notes, so what they log is already post-exclusion; logginghitshere would make this row mean something other than every other row in the same readout.test_telemetry_uses_its_own_sourcehad encoded the defect: itsassert_called_oncepassed only because the rule arm skipped its row. Rewritten to assert the source split it was actually about.The defect bites hardest on the pre-tool arm (#3476), which fires on every Bash call: with no rows at all, a ranker that declined is indistinguishable from a hook that never fired — the silent failure that arm exists to stop.
Why this merges now
The deployed instance is actively writing the contaminated rows that milestone 333 step 4 has to read. Every hour it runs unfixed is analysis window that has to be discarded.
#3311 and the
rule_usagemodule docstring are corrected rather than quietly rewritten — the wrong version stays visible, since the reason to measure the arm survives the correction and is stronger for it.CI green on
dev@48804c4(run 5450, all six jobs).🤖 Generated with Claude Code
https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ