Repository navigation
fix(search): refuse only when no identifier occurs (E73) - merge paused by review - #113
Merged
Merged
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
added 3 commits
November 11, 2026 01:27
`_abstains` decided "the subject does not occur" from the FIRST extracted
identifier. On commit prose that token is a dotted annotation or a type name, so
the answer was emptied while a later name occurred hundreds of times:
_orm.registry=0 Declarative=785
Databricks=0 TypeError=290
_orm.relationship.primaryjoin=0 omit_join=47
On the 40 solvable sqlalchemy commits 13 answered nothing this way (32.5%), and
with the rows shown the gold was in the top-5 for 8 of them.
The fix abstains only when NO identifier occurs. The policy is untouched: an
answer whose tokens are all absent is still withheld (2 of the 13 stay refused).
sqlalchemy, 40 commits hit@5 11 -> 17 (bar >= 15)
B1 dev, 71 commits 19/71 unchanged (bar 19)
44 negative tasks 44/44 silent (bar 0 leaks)
13 formerly-empty 6/13 recovered (bar 8 - FAILED)
P4 was miscalibrated in the frozen spec: the bar came from an
include_neighbours=true run, which bypasses the refusal, while the change keeps
it; the two remaining refusals are the all-zero case, so the maximum is 11/13.
The gate is recorded as failed and not edited afterwards; the frozen decision
rule ("P4 < 8 -> revert") and the measurement (P1 +6, no leak) disagree, so the
ship decision is with the owner.
Frozen spec and full numbers: experiments/false_abstain_2026_11/.
…fect Two follow-ups demanded by the ship procedure: 1. The E73 frozen spec gets a dated postscriptum: the P4 bar (>= 8/13) was derived from an include_neighbours=true run, which bypasses the refusal the change keeps; two of the thirteen commits have every identifier at zero and must stay refused, so the reachable maximum is 11/13. P4 stays FAIL in the run log; the bar is not re-edited and the number is not re-derived. 2. A regression test for the case the policy exists for: when every identifier is absent, the answer has no rows, says abstain, and hands back the exact `next: investigate(...)` call. The stub fails `has_symbol`, so the fail-open rule does not apply. Red on sabotage: with `_abstains` forced to return False, 3 of 8 tests fail, including this one.
ManSio
force-pushed
the
fix/false-abstain
branch
from
November 10, 2026 22:28
5556b2e to
4937732
Compare
Owner
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(search): refuse only when no identifier occurs (E73) - merge paused by review
_abstainsdecided "the subject does not occur" from the FIRST extractedidentifier. On commit prose that token is a dotted annotation or a type name, so
the answer was emptied while a later name occurred hundreds of times:
On the 40 solvable sqlalchemy commits 13 answered nothing this way (32.5%).
Gates (frozen spec in experiments/false_abstain_2026_11/frozen/PLAN.md):
Independent review: PASS with remarks, two major findings.
is now false on the recovered answers - but a test
(
test_no_exact_hits_says_the_results_are_neighbours) pins that wording, sofixing it changes a test contract: owner decision.
percounts only the first two identifiers while four are extracted, so"no identifier occurs" is stronger than the code; fixing it changes the grep
channel's coverage and needs a re-measure of P1/P5.
Conversion rule applied -> merge paused, recorded in AGENT_DIARY.md, owner
decides in the morning. Nits from the review that were safe (None/negative
counters fail-open, dead branch removed) are fixed in the same pass.