From 277aea58e4a5e00acb9f751435fcd215b16dfe4e Mon Sep 17 00:00:00 2001 From: Bryan Van Deusen Date: Tue, 8 Sep 2026 13:36:03 -0400 Subject: [PATCH] test(telemetry): pin the identity that falsified this milestone (#3668) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reverts the deliberate break from 5e19a1b. `plugin_context.py` is now byte-identical to before it; the only change against that baseline is the guard itself. FALSIFIED, not argued (rule 167). CI run 6046 with `results=hits` in both arms failed exactly the predicted four cases — [one-already-held-write_path] FAILED [one-already-held-pre_tool] FAILED [all-already-held-write_path] FAILED [all-already-held-pre_tool] FAILED [nothing-held-*] passed — and the nothing-held cases passing is the point, not a gap: with no exclusions both recorders see the same list however wrongly they are wired, so that case can never discriminate and a guard built only from it would read as coverage while catching nothing. WHAT IS PINNED. Both arms build one `fresh` list and hand it to two recorders in one function, so the call log and the surfacing log cannot disagree about what a single call showed. Ids, not counts: equal counts drawn from different lists is a real way for this to break, and a count comparison would call it agreement. Three hits, where production returns at most one. The identity holds at any limit because both recorders read the same list, and stating it that way survives RULEHINT_LIMIT moving again — it has moved once already (2 → 1, 2385100), and that move is half of why the original reconstruction misread its own numbers. NOT DONE, deliberately: the readout-level self-check the task also proposed. `cleared_threshold` counts CALLS that beat the bar while `surfaced` counts RULES, so that identity holds only while the limit is 1 — it would fire on a healthy system the moment the limit rises. The arm-level form has no such coupling, which is why the guard lives here. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ --- src/scribe/services/plugin_context.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/scribe/services/plugin_context.py b/src/scribe/services/plugin_context.py index a391c63..3ce4dda 100644 --- a/src/scribe/services/plugin_context.py +++ b/src/scribe/services/plugin_context.py @@ -1300,7 +1300,7 @@ async def build_write_path_hint( user_id=user_id, source="write_path_rule", query=code or path, threshold=cfg["rule_threshold"], limit=RULEHINT_LIMIT, project_id=project_id, - is_task=None, results=hits, duration_ms=rule_ms, + is_task=None, results=fresh, duration_ms=rule_ms, # What the ranker found and this session had already been told. # Without it a zero row cannot say whether the bar was too high or # the reader was simply ahead of it — and only the first is a @@ -1404,7 +1404,7 @@ async def build_tool_rule_hint( user_id=user_id, source="pre_tool_rule", query=query, threshold=cfg["rule_threshold"], limit=RULEHINT_LIMIT, project_id=project_id, - is_task=None, results=hits, duration_ms=duration_ms, + is_task=None, results=fresh, duration_ms=duration_ms, # See the sibling arm. It matters more here: this arm fires on every # Bash call, so a long session excludes its way to an all-zero row # and the threshold looks wrong when nothing about it is.