Skip to content

Record the #495 decline, and correct a tier figure that shipped in #499 - #500

Merged
derek73 merged 1 commit into
masterfrom
claude/decisions-radar-only-rules
Sep 3, 2026
Merged

derek73 merged 1 commit into
masterfrom
claude/decisions-radar-only-rules

Conversation

@derek73

@derek73 derek73 commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Records the #495 decline, and corrects a figure that shipped in #499.

Why #495 closed as not planned

It asked whether ledger rules that only explain radar-tier names still earn
their place. Measured at baseline 1.4.0, 19 of the 72 explaining rules explain
only radar names
— 48 of the 352 intentional diffs. That is not the five the
issue named; it is a SUPERSET of them, containing all three rules #495's own
option 2 proposed deleting.

What kills the criterion is what deletion actually does. Driving classify()
over each of the 48 diffs with its own rule removed: 25 report UNCLASSIFIED
and 23 are claimed by a DIFFERENT rule
— nine of fix(cjk-comma-compound)'s
eleven land on fix(cjk-glued-honorific-peel), all seven of
fix(cjk-comma-honorific-peel)'s land on the compound rule, 'Carod i' lands on
the roman-numeral fix(suffix-routing). So for nearly half the population
deleting is not merely wasteful, it is a MISLABEL — the rule-broader-than-the-diff
absorption this file already names twice.

The criterion that does justify deleting a rule is that it explains NOTHING,
which dormant already names and the dormancy check already enforces.

The five precedes_narrower exemptions citing #495 described it as a live
question in the present tense; all five now read as decided. The #496 decline
that leaned on it still stands on its own reasoning — nothing can demand the twin
rule, which is not what #495 settled.

The corrected figure

expected_since_1.4.0.toml has said since #499 that the routing rule "explains
eight of which six are contract". At baseline 1.4.0 it is five.

Not a mis-map: six is what tiering by FILE MEMBERSHIP gives from a correct
_CORPUS_TIERS. 'John Smith, Dr.' sits in corpus_issues.jsonl (radar, no
shape) and corpus_shapes.jsonl (contract, shape 4, FAMILY_FIRST,
min_baseline 2.0.0). The dedup key is (name, order), so the shape-4 copy is a
SECOND entry rather than the dedup winner — verified at baseline 2.0.0, where the
run compares both — and at 1.4.0 it is among the seven the baseline-minimum skip
drops. The only entry a 1.4.0 run compares for that string is the radar one.

Tier, in any claim scoped to a baseline, is a property of the ENTRY that run
compared — not of the files the string appears in.
Measured: 24 of the 352
explained names sit in files of both tiers, 2 of those carry a shape tag, and
exactly 1 bites at 1.4.0. File-membership tiering gets 1 of 352 wrong;
entry["tier"] gets it right for free. The radar-only count of 19 is identical
under either tiering.

Three traps in one measurement, all recorded in the RECOMPUTE recipe

Two of them produced wrong answers during this work:

  1. Report truncation (names[:10], no "and N more" line) — harmless for this
    predicate, because contract files load first so contract names occupy the
    prefix; first-ten-only still gives 19. Recorded because it looks dangerous.
  2. Naive repr parsing — gives 20. "'Smitty' Dr. Jones" renders with double
    quotes because the name contains single ones, so strip-the-quotes drops
    fix(#410)'s only contract name. ast.literal_eval is the fix.
  3. File-membership vs compared-entry tier — the one above, and the only one of
    the three that changes an answer on this tree.

Verification

Full suite 6467 passed, 156 skipped, 5 xfailed; ruff clean; mypy clean on 111
source files. Gate at all four baselines, exit 0 each: 352 / 247 / 155 / 14
intentional, 0 unexplained, 0 radar-unclassified.

Prose only — no rule, name_regex, fields, orders or file order changed.
design-docs-reviewer ran the eleven axes over the first draft and returned seven
confirmed findings; this is the rebuild, plus the shape-tag correction found while
fixing one of them.

🤖 Generated with Claude Code

…deletion measures

The Declined bullet on #495 reached the right conclusion through
seven wrong claims. Rewritten on the measurement that actually
refuses the criterion, and the five ledger exemptions citing #495
now record its answer instead of posing it.

CORRECTS A FIGURE THAT SHIPPED IN #499: the fix(comma-family)
routing-rule exemption in expected_since_1.4.0.toml said it
explains "eight of which six are contract". It is FIVE. Six is
what tiering by file membership gives from a correct
_CORPUS_TIERS -- it counts 'John Smith, Dr.' contract because
corpus_shapes.jsonl holds a copy, but that copy carries shape 4,
whose FAMILY_FIRST order makes it a second (name, order) entry
rather than the dedup winner, and shape 4's min_baseline of 2.0.0
skips it at this baseline. The only entry a 1.4.0 run compares for
that string is the radar one. Tier in a baseline-scoped claim is a
property of the ENTRY the run compared; the general trap is now
recorded in the bullet's RECOMPUTE line, where 2 of the 24
both-tier names carry a shape tag and exactly 1 bites at 1.4.0.

Measured at baseline 1.4.0 by driving classify() over each of the
48 diffs with its own rule removed: 25 report UNCLASSIFIED and 23
are claimed by ANOTHER rule (26 and 22 with all 19 deleted at
once). So for nearly half the population deleting mislabels rather
than merely loses -- the rule-broader-than-the-diff absorption
decisions.md#H1 and the fields-only arc already name.

Also corrected in the bullet: UNEXPLAINED cannot happen on a radar
tier (both NOT WANTED names are radar; measured, removing both
rules gives unexplained 0, radar unclassified 1); the 19 is a
SUPERSET of what #495 proposed deleting, not a different set; the
wrong count of 20 came from a repr-parsing bug, not from the
report's ten-name truncation, which cannot flip the predicate;
feat(#269) and fix(#360) name families, so the rules are named;
and the WATCH quote belongs to decisions.md#cjk-comma-demotion.

The RECOMPUTE recipe is replaced by one that was run: wrap
_run_worker and classify() around an unchanged compare.main() and
read tier off entry["tier"], rather than joining names to files by
hand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@derek73 derek73 added this to the v2.3 milestone Sep 3, 2026
@derek73 derek73 added docs Documentation fixes and updates tooling labels Sep 3, 2026
@derek73 derek73 self-assigned this Sep 3, 2026
@codecov

codecov Bot commented Sep 3, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.66%. Comparing base (777c1ec) to head (f736563).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #500   +/-   ##
=======================================
  Coverage   98.66%   98.66%           
=======================================
  Files          45       45           
  Lines        3219     3219           
=======================================
  Hits         3176     3176           
  Misses         43       43           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@derek73
derek73 merged commit 514a2a1 into master Sep 3, 2026
11 checks passed
@derek73
derek73 deleted the claude/decisions-radar-only-rules branch September 5, 2026 23:39
derek73 added a commit that referenced this pull request Oct 21, 2026
Three reviewers on #795. Pointer resolution:
- words that continue no candidate's head are now a finding where
  candidates share a date and issue, so a typo (`#718 reveiw`) no
  longer falls back to the bare entry in silence;
- the longest head the words continue wins, so an entry whose head
  another's extends (`review`, `review round`) can be named;
- a head's words are matched against the whole rest of the line, so a
  period inside them (`v2.4`) no longer cuts them, and a date inside
  them is part of the pick rather than a second pointer;
- an issue is the pointer's only when no comma or parenthesis stands
  between it and the date, so prose after a date-only pointer
  (`— 2026-09-24, see #500`) is not read as its issue;
- `_clean` drops a supersession note in any case, and a parenthesis
  never closed is text.
The 68 real pointers resolve exactly as before (compared against the
previous resolver). New rows fail on the previous commit for the new
behavior; the reviewers' mutation rows (twins differing by a note,
"opens with", a trailing space, the bare-sibling pins) pass there and
kill the mutants they were written for.

Blocks: H3's #316 entry marks the `Dr Smith V` reading S10's #718
reversed, missed when the block was written; H3's numeral example shows
its title; S10's report line also points at #718's PR review; S4 says
"left as it is" as its entry does. README: the pointer sentence states
the new behavior, #776's two cases are attributed to writing and
review, and the batch's count is dated and includes H3.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
derek73 added a commit that referenced this pull request Oct 21, 2026
…795)

* Index S3, S4, S6, S10, H3 and P5 with Standing blocks (#762, gate files)

The gates phase 2 of the vocabulary model (#752) will re-read: each
file now opens with what is in force and the entry that decided it,
and leaves the exempt list (88 -> 82).

Writing them found four entries whose heads did not say a later
decision had replaced part of them, now marked under the README's edit
kind 1: S6's accepted `abdul Smith Jr Ma` (reversed by S7's #544), S4's
`Doe, Jane nee Smith MA` maiden reading (by M2's #601), P5's view
comparison (by #614), and S10's one-case `v` (by #721). The README's
Standing bullet now says to look for those first, across the folder,
naming the cases #776 and this batch found.

S6 holds two entries dated 2026-09-14 and two dated 2026-09-18 with no
issue, which a date-only pointer could not tell apart; a pointer may
now carry the words that open its entry's head (`— 2026-09-14 (Derek)`),
and a bare-date head never matches a qualified pointer. New rows pin
both; the qualified ones fail on the previous checker.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Fix the review's findings: every pointer resolves to one entry

The checker let an issue pointer name several entries of one date and
issue, and two S10 lines landed on the wrong sibling (#718's report
entry for its comma review, #721's for its PR review) with nothing
failing. A pointer now resolves to exactly one entry: where several
share its date and issue it goes on with the words the entry's head
continues with (`— 2026-10-18 #718 review`), a bare pointer names the
entry whose head ends there, and one still naming entries with
different heads is a finding. A parenthesized supersession note in a
head is not read, so marking an entry does not break its pointers.
P8's #383 lines were ambiguous among three entries and now name
`#383 + #479` or `#383/#479`. A test pins each target, since a pointer
landing on a sibling passes every finding.

S4's maiden line cited a family-comma example #601 had taken out of
the clause; it cites the comma-less one, and the head marker names
both things #601 superseded there. P5's three family-comma and
name-word clauses come from #425 (PR #426), whose paragraphs #614's
bullet was inserted into on 2026-10-07; the line points there, the
marker names the #369 application #614 also superseded, and an edit
kind 2 note says where the paragraphs belong. S10 marks its two
in-file reversals, S6 its marker issue-first and its helper's callers
without a short list.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Tell twin entries apart by how their text opens

The second review found two P8 entries with the same head words
(`2026-09-13 #383/#479`), so each Standing line pointing there landed on
both and the checker passed it, a row having blessed that. Where heads
are the same words, the pointer now goes on with the words its entry's
text opens with (`— 2026-09-13 #383/#479, AMENDS`), and a pointer still
naming more than one entry is ambiguous, twins included. The target
test pins both twins; the unqualified row fails on the previous checker.

Also: S10's #721 PR-review entry marks the mechanism #722 replaced, and
S6's helper sentence no longer says only later stages call it (segment
runs before classify).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Pass re.split's maxsplit by keyword

Python 3.13 deprecated the positional form, and CI runs with
DeprecationWarning as an error, so the three newest build jobs failed
on the pointer resolver while 3.11 and 3.12 passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Record the newer-interpreter deprecation trap in AGENTS.md's Gotchas

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Fix the PR review's findings on pointer resolution and the blocks

Three reviewers on #795. Pointer resolution:
- words that continue no candidate's head are now a finding where
  candidates share a date and issue, so a typo (`#718 reveiw`) no
  longer falls back to the bare entry in silence;
- the longest head the words continue wins, so an entry whose head
  another's extends (`review`, `review round`) can be named;
- a head's words are matched against the whole rest of the line, so a
  period inside them (`v2.4`) no longer cuts them, and a date inside
  them is part of the pick rather than a second pointer;
- an issue is the pointer's only when no comma or parenthesis stands
  between it and the date, so prose after a date-only pointer
  (`— 2026-09-24, see #500`) is not read as its issue;
- `_clean` drops a supersession note in any case, and a parenthesis
  never closed is text.
The 68 real pointers resolve exactly as before (compared against the
previous resolver). New rows fail on the previous commit for the new
behavior; the reviewers' mutation rows (twins differing by a note,
"opens with", a trailing space, the bare-sibling pins) pass there and
kill the mutants they were written for.

Blocks: H3's #316 entry marks the `Dr Smith V` reading S10's #718
reversed, missed when the block was written; H3's numeral example shows
its title; S10's report line also points at #718's PR review; S4 says
"left as it is" as its entry does. README: the pointer sentence states
the new behavior, #776's two cases are attributed to writing and
review, and the batch's count is dated and includes H3.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Restore the pointer's issue window; end words at the next pointer

The re-review found the fix commit narrowing what it widened: limiting
the date-to-issue window to 20 characters with no comma or parenthesis
stopped a pointer copied whole from its head (`2026-09-19 (Derek),
#533`) from reading its issue, and where a bare sibling shared the date
it resolved to that sibling in silence. The 40-character window is
back; an issue written in prose right after a date-only pointer is
again read as the pointer's and fails loudly, which the module comment
now says. Every head in the files with Standing blocks, copied whole,
resolves to its own entry but P8's twins, which fail as ambiguous.

The words after a pointer now end at the next pointer's date as well
as at `.` or `;`, so `— 2026-10-17 #718, 2026-10-18 #721` reads both;
a Not-standing line's unmatched words are reported as such rather than
as "no entry"; the docstring lists the unmatched-words finding, and
the README says prose after a shared-date pointer goes after a `.` or
`;`. The real pointers number 70, not the 68 the previous message
gave; all resolve as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Read a date inside an entry's head words in every case

The re-review found two shapes where a date inside the words a pointer
continues its entry's head with was still read as a second pointer:
with one candidate, where resolution returned before reading any words
(S4's head copied whole, `2026-09-14 (Derek), scope corrected
2026-09-18`, also cited S4's separate 2026-09-18 entry), and with the
words cut short at that date, new in the previous commit. The words a
resolved pointer read are now its common prefix with the named entry's
head continuation, in every branch. Two rows, whose inner dates name no
entry so that a stray second pointer fails, fail on the previous
commit. The 64 real lines resolve as before, and every head copied
whole now resolves to its own entry except the two pairs of twins.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Stop a pointer's issue window at another date

A date-only pointer joined by a comma to a pointer with an issue
(`— 2026-09-24, 2026-10-23 #741`) read that issue as its own, the
window between a date and its issue letting a second date through. The
window now stops at another date, as it stops at `—`, `.` and `;`.
The new row fails on the previous commit; the real lines resolve as
before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Count the read prefix by hand; os.path.commonprefix is deprecated in 3.15

The 3.15 build jobs failed on 2a26d17: os.path.commonprefix warns
there, and warnings are errors. The trap is the one AGENTS.md's Gotcha
added in this PR records, and 2a26d17 was not run on 3.15 before it
was pushed. The full suite now passes on 3.15 and 3.11.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation fixes and updates tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant