fix(eval): M3 selectivity gate is exactly <= 1/3 (#209 amendment)

[leo-aa88]

This encodes the M3 protocol amendment recorded on #209 before any capture exists (amendment). The selectivity bar is now median candidate fraction ≤ 1/3. It was "≤ 0.33".

Why

• The bound means "at least as selective as M1 on otel-fresh".
• The evaluator (feat(eval): frozen M3 evaluator for the structural model (#209) #214) reproduces that reference value as exactly 1/3, and "0.33" was it rounded to two decimals.
• Read literally, 0.33 fails M1's own reference value and draws an arbitrary line: 0.331 passes and 0.334 fails.

Change

• CANDIDATE_FRACTION_MAX = Fraction(1, 3).
• The gate takes the median over Fraction(|localization|, |services|), so a result of exactly 1/3 can never fail on float rounding. For example, the median of 1/4 and 5/12 is exactly 1/3.
• The report keeps the float median and adds median_candidate_fraction_exact, e.g. "11/30". The criterion prints <= 1/3.

Nothing else in the protocol or the evaluator changes. After capture, no criterion changes.

Tests

The test that pinned "exact 1/3 fails 0.33" is replaced by four tests:

• exact 1/3 passes;
• 1/3 as an even-count median passes;
• 0.334 fails and 0.331 passes;
• the exact median is reported.

make lint ✅ · make test-unit ✅ (1587). A smoke run on trace-loc serializes and renders correctly.

Eval delta

None on the product. This touches src/eval/ only; src/core/ is unchanged. On the spent otel-fresh corpus the frozen arm's fraction is 0.139, so the gate verdict is unchanged there. The only behaviour change is a median landing in (0.33, 1/3].

Refs #209.

🤖 Generated with Claude Code

[leo-aa88]

/review

[cursor]

LGTM

  

_{Sent by Cursor Automation: Code Reviewer}

[cursor]

REQUEST CHANGES

The comparison in decide is exact, and the new unit tests actually pin the float-rounding case. The decision record those tests never look at does not contain the value that was compared. CI is green. This is not a failing-test problem.

1. The criterion record is not the comparison the gate ran

BLOCKING.

decide computes Fraction median, compares that to Fraction(1, 3), then writes a different object into generalization_criteria: float(median) and the string "1/3". render_markdown — the as-is post for #209 — runs every criterion value through _num, i.e. two decimal places, and never reads median_candidate_fraction_exact.

So the three medians this PR exists to separate all print as the same line:

• 1/3 passes, posts 0.33 (pre-registered <= 1/3)
• 331/1000 passes, posts 0.33 (pre-registered <= 1/3)
• 334/1000 (= 167/500) fails, posts 0.33 (pre-registered <= 1/3)

The table cell is the same 0.33. The exact ratio is on the arm dict inside the JSON and then dropped on the floor by the publisher. Before this patch the criteria triple was the pair of operands the branch used. It is not anymore: 0.334 <= "1/3" does not even type-check, and the Fraction that did get compared is not stored.

ಠ_ಠ You refused to gate on the float, then stored the float as the official criterion, so _num could keep rounding it back to the literal the amendment just retired.

Record the exact ratio in the criterion value and print that ratio in the verdict line and the selectivity row. The float can stay beside it. Add a render test for 1/3, 331/1000, and 334/1000 that asserts the posted lines are not identical.

VERDICT

The gate boolean matches the #209 amendment. The audit record does not. This is an abstraction failure: two representations of one threshold, and the one the protocol posts is the rounded one. Do not merge until the posted criterion is the ratio decide compared.

  

_{Sent by Cursor Automation: Code Reviewer}

[leo-aa88]

/review

[cursor]

LGTM

  

_{Sent by Cursor Automation: Code Reviewer}