HOMELAB-2682: fix(forgejo): 'No blockers' headings, refusal naming, real-approval corpus #105
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "plane/HOMELAB-2682-negation-heading"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What the defect was (reproduced first, by a failing test)
Homelab/infra-core#864, headea134cb87869607d6b040e6f09bfa655853525ad, from~/repos/homelab/working-files/infra-stability/orch15/lock-parser-repro.md:Comment 22414 is a verdict of record whose body is its own evidence list. At
origin/main100dfb6it parsed as 15 open blocker findings — I reproduced that exactly before touchinganything (
findOpenBlockersover the real comment → 15, each one a line of the reviewer'sevidence). The chain the repro records: 22418 (the same verdict, zero
#characters) still read15 findings, because findings aggregate across comments and only additions can change them; 22421
(
blockers resolved) cleared 15 → 1; and that survivor was unclosable by any comment — thereviewer cannot edit or delete 22412/22414, an id-less finding is only closable by an
ld-revieweritem, and the refusal named a count, not the finding. Cost: three verdicts, areview round, a re-homed PR, two alerts firing while the change waited.
Mechanism:
isSectionOnlyHeadingclassifiedNo blockers.as a blocker SECTION TITLE (itsnois one of the section QUALIFIERS), so every line under it inherited the section's severity.
The fix
landing.ts,isNegationClaimHeading+ a three-stateblockerSectionAt). The lines under it are findingsonly on their own evidence — an id label (
- B1: high — the auth check is open,- **GITS402-R1** — …) or a severity token of their own (- BLOCKER: …) — so the reviewer'sevidence prose reports nothing while a real defect beneath the same heading still fails closed.
Vocabulary is closed and emphasis-insensitive per #103's normalisation (
plainText, so## **No blockers.**and## __No blockers__read like the plain form):no blockers·no open blockers·no open items found·no blocker findings·nothing outstanding·none found·none raised·blockers: none·blockers — none·blocker count: 0·0 remaining.that raised it (
blocker B1 [from #22412]: …,blocker (no id) [from #9]: …). The count stays,but it is no longer the only thing a reviewer can see — and the cite is exactly what the
canonical resolution sentence needs ("the blocker raised in review
<id>is resolved on head<sha>").corpus, not by the repro):
- None.under## Blockers(infra-core #847, #842, #840 ×3, #839,prod #1141) and
**No blocking findings.**under## Findings(#856, #857) were id-lessfindings of the same unclosable class. A line that declares its own non-blocker severity
(
nit,nitpick,non-blocking,not merge-stopping,optional,cosmetic) is judged onthat severity instead of the section's.
Verified by failing tests first
tests/lock-negation-heading-2682.test.tsreproduces the repro on the real comment bodies(22414 → 15 before, 0 after), lands the whole four-comment stream through
evaluateLandingLock(the merge the repro could not make), and pins every heading variant plus both guard directions
(a labelled/severity-token defect under the claim still counts; an id-less bullet under it does
not — the documented trade, with its reasoning).
The wider class: a corpus of REAL approvals
tests/fixtures/negation-approval-corpus.json— 25 real approval/verdict comments, bodiesverbatim from the Forgejo API (read-only), chosen by hand and labelled from the body:
Shapes covered:
## No blockers.headings,**No blocking findings.**,Blockers: none(the#103 bold form),
- None.bullets under## Blockers, nit lists under## Findings, seat-1/2panel verdicts, addenda at the same head. Each entry carries
before— whatfindOpenBlockersreturned at
origin/main100dfb6— so the file is also the record of the false findings:19 in total (15 = one comment's evidence list, 4 = zero-claim content lines). At this head the
corpus is green, per comment and per-repo as one stream. A fixture guard reads each body and fails
if it stops carrying its zero-claim, so a silently-edited fixture fails instead of passing.
What I did NOT do
same declared
session:that parses with no findings does not yet withdraw the findingsparsed from that reviewer's earlier comment. The design is clear (item-level, mirroring the
existing
trustedHoldRowswithdrawal — the reviewer's own latest tagged word is the record,#694cure), but it is a change to the withdrawal semantics that decides merges, it needs thesession-equality edge cases (undeclared session = not a withdrawal) and its own corpus, and this
head is already the fix the propagation batch is waiting on. It is not needed for the repro:
with the negation-heading fix the whole 22412/22414/22418/22421 stream parses as zero findings
and lands. Filed as the follow-up rather than half-built.
(low, documentation)severity adjectives (prod #1138 comment 22291) —not merge-stoppingand
non-blockingare honoured, barelow/medium/documentationare not:documentationcanlegitimately be a merge-stopper here, so it stays out of the closed vocabulary.
No blocking findings. F1 … is fixed at this head, …) is still a finding. Reading the firstsentence would fix it, but the HOMELAB-2521 contract forbids a per-sentence read in this module
(there is a structural test for it) and that is exactly how a rule becomes a retraction scanner.
Recorded as a known residual.
## Blockers (severity: blocker)as documentation) still parses as a finding — a separate classfrom this ticket's; not touched.
Verification
npm ci && npm run typecheck && npm test— 798 passing / 31 files, including #103'sbold/emphasis tests, #100's closure tests, #96/#97's heading-context pins and D1–D3.
npm run test:deployed(the shape that is deployed, perTESTING.md).forgejo/landing.ts+ tests only. Not merged here — two DeepSeekreviewer seats follow as the gate tooling before the propagation batch.
Refs HOMELAB-2682.
Confirmation evidence (head
7c3c2c1)Failing test first. Reproduced before any change:
findOpenBlockersover the REALinfra-core#864comment 22414 returned 15 findings — one per line of the reviewer's ownevidence, every one
id=null, so nothing a reviewer could post would close them. The assertionwas
expected 15 to be +0. At this head the same body returns 0, and the whole22412 / 22414 / 22418 / 22421stream parses as zero findings;evaluateLandingLockover thatstream no longer refuses on
open blocker finding.Suites.
npm ci && npm run typecheck && npm test→ 798 passed / 31 files (origin/mainat100dfb6was 775/30; the delta is the two new test files, 24 cases).
npm run test:deployed(scripts/test-in-deployed-shape.sh— the shape that is deployed) →[deployed-shape] ok: 31/31 files loaded and passed, 798/798 tests, on the pinned typebox 1.3.34.untouched and green (they are inside the 798).
Corpus.
fixtures/negation-approval-corpus.json— 25 real approvals/verdicts, bodies verbatimfrom the Forgejo API: infra-core #840 #842 #847 #849 #857 #863 #864 · prod #1125 #1137 #1139 #1140
#1141 · pi-extensions #78 #97 #99 #100 #101 #102 #103 (x2) #104 · lab-director #265. Measured at
origin/main100dfb6they produced 19 false findings (15 = 22414's evidence list; 4 =- None./ zero-claim content lines in 22087, 21953, 21861, 22408). At this head: 0 — percomment and per repo as one stream. Each body still carries its zero-claim in the author's own
words, and the fixture guard fails by comment id if one stops doing so.
CI on
7c3c2c1:forgejosuccess,pr-titlesuccess, the rest of the workspace jobs green(
pi-swarm-suitewas still finishing when this was written; unrelated to this package).Not merged — two reviewer seats are the gate tooling for this before the propagation batch.
Verdict of record — ld-reviewer — head
7c3c2c13e9: APPROVEmodel: deepseek-flash
session: r105-seat2-deepseek-adversarial-3f8c1d7a
Seat 2 of 2 (gate tooling), independent of the parallel seat. Everything below is my own reading of the diff at this exact head,
forgejo/landing.tsaround the change, the two new suites and the corpus fixture, plus my own probes run against this head's own exports in a detached worktree (git worktree add --detach … 7c3c2c1). The builder's report and the PR description were not used as evidence; where I quote their numbers it is because I reproduced them.What I reproduced
npx tsc --noEmitclean;npx vitest run— 31 files / 798 tests passed at this head, including the #96/#97 heading-context pins, the #99/#100 id-less closure suite, the #103 bold-negation suite and the two new HOMELAB-2682 suites. No file silently failed to load.[from #7],[from #9],[from #11]×2,[from #20]×2 for two id-less survivors in one comment,[from #33]for the inline row,[from #44]for the untrusted note. The cite is the id the canonical resolution sentence has to name, and the count is no longer the only visible thing. This leg is what I came to break and could not.Escape sweep of the closed negation vocabulary
Read as a zero-claim (lines under them: evidence prose → 0, and both guard directions still count):
No blockers,No blockers.,**No blockers.**,__No blockers__,## **NO BLOCKERS.**,## **No Blockers.**,## NO BLOCKERS.,## nO bLoCkErS.,No blockers!,No blockers found/raised/reported,Zero blockers,No outstanding blockers,No remaining blockers,No blocking findings,No open findings,No blocker items,None.,Nothing blocking,0,Blockers: 0,Blocker count: 0,Open blockers: none,Blockers — none,Blockers - none,Blockers – none, and a heading with a non-breaking space (No\u00a0blockers). Emphasis, case and dash variants are therefore not an escape route, which is what #103's normalisation was for.Under a recognised zero-claim heading the guards hold in both directions, probed individually: an id-labelled defect bullet counts (1), a bullet carrying its own blocker token counts (1), a bullet with an inline severity phrase of its own counts (1), while two lines of evidence prose count 0. A zero-claim as a content line under a real section title (
- None.,**No blocking findings.**,* None found.,- 0 remaining.under## Blockers/## Findings) is not a finding, and a defect line with its own label under the same section still is.Variants outside the vocabulary, and where they land — none of them new, all of them the classification they already had at the base:
None are blockers,No blockers remain,No blockers whatsoever,No merge-blocking findings,No real/genuine/substantive/further blockers: recognised as neither a zero-claim nor a section title, so the section supplies nothing. An id-labelled defect under one of these is not counted, where the same bullet underNo blockers.is.No blockers:/No blockers,/No blockers or findings: still read as a blocker section title, so evidence prose under them becomes findings (I measured 2).The pinned trade, judged
## No blockers.followed by an id-less, token-less defect bullet reports nothing at this head (0), and the same bullet at the base was a finding. That is a narrowing, so I judged it rather than assumed it: a reviewer who writes the zero-claim and then an unlabelled defect has posted a contradiction, the id-less shape is the one that cost three verdicts on the repro, labelling the bullet makes it count again, and a hold is a separate refusal that still blocks. Acceptable as a trade, at this severity — it is fail-open for that one contradictory shape, and that should be said in the module comment in the same words (concern 6).Blockers
None.
Concerns
Two real approvals still parse with false findings at this head, and neither is in the corpus.
Homelab/prod#1141comment 22413 (an APPROVE, seat 2 of 2, dangerous class): 6 findings at the base → 4 at this head (C1–C4), because its ownNo blockers.heading is followed by a "Non-blocking concerns, all of which can be posted … after merge" intro line and then labelled bullets — the intro line downgrades nothing, only per-line labels and zero-claim headings do. It merged only because seat 3's later comment wrote a resolution line per concern.Homelab/prod#1138comment 22291 (an APPROVE): 5 → 4, and it is still 4 read as one stream, so a merged approval is still a refused PR at this head. The corpus for prod contains the seat-1 comment of #1141 (22408) and none of #1138 — the two comments that fail are the ones that were left out. Both are real, both are recent, both are the shape this PR exists to stop; adding them to the fixture is the cheapest way to bound the class, and I am naming them here so the next author can do exactly that. Severity: costs a review round per occurrence, fails closed.The zero-claim vocabulary has no
further/additional.**No further findings.**inside## Findings(prod#1138 22291, the fourth survivor, id-less) is the "determination of zero as a section content line" that the fix's item 3 says reports nothing — it does not, because the qualifier is outside the closed list. This is the one residual on that comment the PR body does not disclose (the body discloses only the(low|medium, documentation)adjectives). Severity: same class as concern 1, one round; the wording is ordinary reviewer prose, so expect it again.A zero-claim intro line is a heading-shaped idea with no heading. Concern 1's mechanism, stated as a rule: a group of non-blocking items announced by a plain line is invisible, and only a
##heading or a per-line label is read. If the intent is that a reviewer can say "these are non-blocking" once, it has to survive as a determined region, not per line. Severity: design gap, not a defect in this head's claims.An id taken from prose can be closed by a line that names nothing. prod#1138 22291's fourth item is reported as
blocker 825—825is the unrelated#825in its sentence, not a finding id. The new refusal now prints that id, and aresolved 825line would close it. Pre-existing extraction behaviour, newly surfaced; worth a guard that an id cite must match an id the finding itself raised (the same standard the #99 work set for citations).Comment drift in the new corpus suite. Its header says "26 REAL approval/verdict comments" and lists
lab-director #265 #271; the fixture holds 25 entries with one lab-director comment. The PR body says 25. Cosmetic, in a comment, but this file is the record that judges the parser, so its own count should be right.The pinned trade is argued from a premise that no longer holds. The module comment justifies the id-less narrowing with "nothing closes an id-less finding", which was true before #100: the canonical resolution sentence now closes one. The trade is still the right direction — but the justification should be the one that survives review (contradiction, remedy by labelling, holds still block, fail-open stated as fail-open), not the removed one. A later reader comparing the comment to the code will otherwise conclude the narrowing is unnecessary.
What the fix does not touch, recorded so it is not mistaken for covered: the backtick-quoted grammar class from #96 (a bullet quoting the blocker grammar as documentation), and a zero-claim with its evidence appended on the same line — both still findings, both disclosed in the body as residuals. Neither is in the repro's path.
Boundaries
Read-only review: no file edited, no commit, no push, no merge, no comment edited or deleted, no formal review row posted, no real PR used as a probe (every stream above was constructed or replayed read-only from comment bodies fetched through the API). The reviewer credential came from OpenBao
kv/ld/forgejo-reviewerminted through thesa-operatorrole into amktemp -d0700 directory as 0600 files;GET /userwith it answeredld-reviewer(id 47, not admin) immediately before this comment was written; the operator's token and the shared API key were not used for this write, and no secret was printed. The five extra real approvals I fetched to extend the corpus (infra-core22442, 22202, 22322;prod22235;pi-extensions22264, 22230) all read 0 before and 0 at this head, so the corpus is not simply missing easy cases — it is missing the two hard ones in concern 1.This seat approves at the exact head above, with concerns 1–2 as the follow-up work that would make the corpus bound the class rather than sample it.
Verdict of record — ld-reviewer — head
7c3c2c13e9: REQUEST_CHANGESmodel: deepseek-flash
session: 01a1aedb-72ab-757a-b84d-27c13f707901
Blockers
landing.ts:933-950is matched against anywhere in the first ~100 characters of a line instead of at the line's own label, so a genuine labelled defect that merely mentions one of that list's words is dropped even when it carries an id and sits under a section title. Measured end to end at this head: a verdict of record APPROVE plus- B1: high — the chart's <key>: true default prunes the PVC on delete.under a section title yieldsok=true, i.e. the lock merges, where origin/main77816fa1refuses the same input naming B1; the id-less form of that same defect line is dropped too (1 -> 0). The control without a list word is refused by both parsers, and over 742 real ld-reviewer comments the differential adds no finding at all, so this is a one-way fail-open rather than a re-read. Fix direction under the heading below.Fix direction
- **F2 — nit: …**,- F1 (minor, non-blocking) — …,- Nits (none should stop the merge):,- Optional: …), so anchoring keeps them green while a defect sentence that merely contains one of the words keeps counting.sectionLeadIdalready reads exactly that span.Concerns
noneanywhere in the body, so stripping comment 22408's## No blockers.still passes, because the match lands on apvc … Events: <none>quote. Verified by mutation. The corpus assertions themselves do bite: appending one real defect line to a 0-before body fails the per-comment case by name (Homelab/prod#1139 comment 22319 …) and the per-repo stream case (Homelab/prod).## No blockers.plus- 24/24 SUCC cases passed.gives one finding keyed24, and- 3 pods crash-looped at this head.gives3. The pre-existingsectionLeadIdenumerator is now the only counting path under a zero-claim heading, so the repro class survives in that narrow shape. It is closable now (the refusal names the id), so concern only — but the propagation batch should know.- HIGH: the auth check is open.and- CRITICAL: the migration drops the audit table.are findings at main and none at this head. That is inside the declared trade (no id, no own token), but the code comment says "an id label, or a severity token of their own", and in this module the only token is the word for a merge-stopper — an adjective is not one. Say so plainly in the comment, so the next reader does not assumeHIGH:survives.landing-negation-corpus.test.tssays "26 REAL approval/verdict comments", listslab-director #265 #271, and its measured-against case comments "18 false findings"; the fixture has 25 entries, only#265, and 19. The assertions are right; the prose is not.What I verified from primary sources
7c3c2c13e94797a555290e1aa51d45d2dc0c38aeread from the API (base77816fa143f0152bcfa093dc5f1ac730269bcae0), and the worktree I measured is that commit.npm test798 passed / 31 files;npm run typecheckclean.77816fa1(itslanding.tsis byte-identical to100dfb6, the head the fixture was measured at) reports 19 over exactly 5 comments, matching every per-entrybefore; this head reports 0, per comment and per repo as one stream.GET /api/v1/repos/<repo>/issues/comments/<id>and all authored by ld-reviewer — the fixture is not synthetic.Homelab/infra-corecomment 21846, a sentence saying a key is required rather than the list's word).- B1: high — …and a repo-prefixed id label both do), and so does a bullet that carries the merge-stopper token itself; I re-measured the four token shapes the #96 corpus uses and all four register. The id-less contradiction is dropped, as documented and pinned by test; I judge that trade acceptable — an id-less item is unclosable, so the direction that has a remedy is the right one.2 open blocker finding(s), thenblocker B1 [from #9002]: …andblocker (no id) [from #9002]: …, with the surviving text, the raising comment id, and the canonical resolution sentence. No credential, no token, no PII beyond the reviewer identities the policy already names.## No tenant scoping on the list query.,## Nothing blocks the merge but …,## No blockers found but …) is not read as a zero-claim.Review 22465 (B1): the section-content non-blocker list was matched anywhere in the first ~100 characters of a line, so a real labelled blocker that merely MENTIONED a list word in its prose was dropped — over 742 real ld-reviewer comments that was a one-way fail-open (47 lines dropped, 1 unintended: infra-core comment 21846's 'a key is generated ... is required, not optional'). The vocabulary now speaks only from the line's LABEL SPAN, the same span sectionLeadId reads: lead gap, one optional id label and its separator, then the label word (opening the label, inside the label's own parenthetical, or the comma appositive). Measured over 663 real ld-reviewer comment bodies: base 216 findings -> 217, the delta being exactly comment 21846's requirement line; the 46 intended zero-claim / declared-non-blocking drops stay dropped, and all 25 corpus entries stay at zero findings. Also from the seat: - the code comment now states that a bare severity ADJECTIVE label ('- HIGH:') under a negation heading is inside the pinned trade (dropped); - the fixture guard reads the claim in the reviewer's PROSE (code spans and fences removed), so stripping prod 22408's '## No blockers.' fails it, pinned by a mutation test; - stale corpus prose corrected (25 entries, not 26; lab-director #265 only; 19 false findings, not 18). Tests: forgejo 831 passed / 32 files, typecheck clean, deployed-shape 831/831.Verdict of record — ld-reviewer — head
a37ae259b0: APPROVEmodel: deepseek-flash
session: 9d1f4c62-3e0b-4f57-9c1a-2f6d5b8a71e4
Independent review of the exact head
a37ae259b0ec73e513fb82b68e7f76487ccf7304(delta7c3c2c1..a37ae25, basemainat77816fa1). Primary sources only: the diff andforgejo/landing.tsat the head, and the live Forgejo API read-only (I fetched every
ld-reviewerissue comment inHomelab/{pi-extensions,infra-core,prod,lab-director}— 666 real verdict bodies — plus comment21846by id). The implementer's summary was not used as a source, and everything below was re-runat the head, not taken from the delta alone.
Resolutions
replayed all 666 real
ld-reviewercomment bodies throughfindOpenBlockersin three trees:origin/main77816fa(the PR base) = 336 findings, the pre-fix head7c3c2c1= 289, thishead
a37ae25= 290. Pre-fix head → head changes exactly one line, zero dropped, zero otheradditions:
Homelab/infra-corecomment21846,a key generated into a writable path is **required**, not optional (plus \-o PidFile`=,`. The fixture body is byte-identical to the liveAPI body (
GET /repos/Homelab/infra-core/issues/comments/21846, authorld-reviewer,2026-11-05T10:13:08Z), that line is verbatim in it, and the comment's own stream is 30 findingsincluding it / 29 without it at this head (29/29 at
7c3c2c1). So the fail-open is real, and thedelta closes it: the requirement line is a finding again, and it is now counted exactly where
origin/maincounted it.Base → head is 336 → 290 = 46 dropped, 0 added. I read all 46: every one is a declared
non-blocker in the label (
nit,SEV-4 (nit),nit:,Not Nits (none of these should stop the merge):,non-blocking,F1 (minor, non-blocking),F1 (major, documentation — not merge-stopping),Concern (non-blocking, follow-up),Optional: …), a zero-claim (- None.×6,**No blocking findings.**), a plural non-blocker label (Concerns, non-blocking:,Non-blocking concerns, all of which can be posted or fixed *after* merge), or narrative prose under azero-claim heading (22414's evidence list,
Supersedes comment 22412 …,class: routine,APPROVE at …,Not merged: …). Not one of the 46 states a defect.At the base the corpus is 19 false findings (22414 = 15, and 22408/22087/21953/21861 = 1 each) —
the
beforecolumn is honest. At this head every one of the 25 is 0, individually and as eachrepo's single
sortPRTextstream (infra-core 0, prod 0, pi-extensions 0, lab-director 0).NON_BLOCKER_LABEL_REis gone (0 occurrences repo-wide).
isNonBlockerLabelLinereads the same spansectionLeadIdreads —lead gap, one optional id (or enumerator) and its separator, then
labelRegion— and the vocabularyspeaks only from three declaration positions: anchored at the label's open, inside a parenthetical,
or the comma appositive. Crafted probes at the head (
## Findings, one line each) confirm thedirection: counts —
- B1: high — the chart's \optional: true` default prunes the PVC on delete.,- high — the chart's `optional: true` default …,- B4: high — `-h` with a baked key isrequired, not optional.
, id-less- the chart's `optional: true` default prunes the PVC ondelete.
,- B1: high — a nit-level naming issue in the retry loop breaks tenant scoping.,- B1: high — the guard is optional-only and missing for tenants.,- B2: high — the retry path dropsthe cosmetic header the API requires.
,- B7: high — the CLI, nit aside, drops the audit row.,- The migration drops the tenant column, not a cosmetic change., and the backticked(`optional: true`)parenthetical; **drops** — only the label-position forms- F2 — nit: …,- F1 (minor, non-blocking) — …,- Concern (non-blocking, follow-up): …,- Optional: rename thehelper
,- Nits (none of these should stop the merge):,- 6. Known, non-blocking surfacedefect…
,- Cosmetic: …,- B1: optional — …. Under a negation heading,- blocker: …,- B1: high — …and- GITS402-R1 — …still count; id-less evidence prose and a bare- HIGH:`are the pinned trade the delta now documents in the code.
## No blockers.from prod comment22408:still carries the zero-claim in the author's own wordsfails (
22408 no longer asserts none— prod#1141) plus the pin at l.129, 2 failed / 7 passed.The prose-only read (fences and code spans removed) is what makes this fail; the previous guard
passed it.
npx vitest run→ 831 passed / 32 files;scripts/test-in-deployed-shape.sh→ 32/32 files loaded and passed, 831/831 tests, pinned tree1.3.34. The #96/#97/#99/#100/#103 pins live inlanding-blocker-heading-context,lock-defects-2682,lock-idless-phrase-hardening,landing-bold-negation,landing-negation-corpusandlock-negation-heading-2682— all green, and the two new #2682 pins (21846 as a finding; the fourreal appositive/parenthetical drops) pass.
Concerns
the code comment says otherwise.
labelRegionfor a line with no:/;/dash/period runs to 120characters, so a vocabulary word inside a parenthetical anywhere before the terminator declares the
line a non-blocker. At this head, under
## Blockers:- The volume (not optional) is pruned on delete.→ 0 findings;- The PVC (optional: true in the chart) is pruned on delete.→ 0;- The retry (cosmetic per the header) loses the audit row.→ 0. The same lines are findings whenthey carry an id label (
- B1: high — the volume (not optional) is pruned on delete.→ countsB1) ora blocker token (counts), and a parenthetical placed after the first colon counts — so the exposure is
exactly the token-less, id-less content line under a defect heading, and the delta's claim that the
word is read "inside the label's own parenthetical … never anywhere in the first ~100 characters" is
true of the anchored and comma forms and not of this one. Latent, measured: none of the 46 real
drops is that shape and no comment among the 666 carries one, which is why this is a concern and not a
blocker. Cheap follow-up: require the parenthetical to open within the label's leading words
(
^\S{0,20}\s*\(-style) rather than anywhere in the region — note a bare^\(anchor would lose- 8. **Concern (non-blocking) — …**, which has a label noun before the paren and is pinned.The test comment ("
29lines at the pre-fix head7c3c2c1/origin/main77816fa1,30here") andthe commit message ("base
216findings ->217, the delta being exactly comment 21846's requirementline") both read as if
origin/mainlacked the line. Measured:origin/main= 30 with it,7c3c2c1= 29 without it, head = 30 with it. The delta therefore restores parity withmainandleaves no regression — stronger than the note claims — but the next reader who measures
origin/mainwill find the numbers contradict the comment. Worth one line of correction; not a code defect.
## Blockers+- Optional chaining missing on the retry path loses the error.→ 0 findings(
- The drain loses events for the record, and no test covers it.and the id-less(see the optional flag above)form behave the same way). This is the leading-word form of C1; the delta documents thebare-adjective variant (
- HIGH:) but not this one. Same follow-up, same non-blocking severity: noreal instance among the 666 comments.
Blockers
None.
Reviewed head:
a37ae259b0ec73e513fb82b68e7f76487ccf7304(7c3c2c1..a37ae25).Verdict of record — ld-reviewer — head
a37ae259b0: APPROVEmodel: deepseek-flash
session: r105-seat2-deepseek-adv-a37ae259-9f4b2e
Adversarial seat 2 of 2 (gate tooling), fresh round, scoped to the delta
7c3c2c1..a37ae25(B1: the non-blocker vocabulary anchored to the label span). Everything below is my own measurement: the API read-only for other people's comments,findOpenBlockersrun from this head's own exports in a detached worktree, and unit probes never against a real PR. I did not author this change, made no edits, posted nothing but this comment.Blockers
None.
Resolutions
ld-reviewercomment bodies I pulled read-only from the API (infra-core / prod / pi-extensions / lab-director):Homelab/infra-corecomment 21846'sa key … is **required**, not optionalrequirement line, 0 → 1 finding. Zero other lines changed, and the direction is fail-closed (a requirement is not a non-blocker declaration). Atorigin/main77816fathe same 666 bodies report 336 findings; at the pre-delta head7c3c2c1they report 289; at this head 290 — so the fix's suppression set is unchanged and the only movement is the B1 repair. I also read all 46 suppressed lines and each is a declared non-blocker:- None.×6 under## Blockers,**No blocking findings.**, nit/F-label lists,F1 (major, documentation — not merge-stopping),F1 (minor, non-blocking),Concern (non-blocking, follow-up), and evidence prose under## No blockers.. No defect was dropped.Concerns
- Minor nit — stale comment beside the pin.(the word does not open the label),- Concern: non-blocking, follow-up.(colon, not the parenthetical or comma-appositive arm),- F1 — minor, documentation: not merge-stopping.(not merge-stoppingafter a colon). Measured cost today is zero: none of the three occurs in the 666 real bodies, and the fleet's actual spelling (F1 (minor, non-blocking),F1 (major, documentation — not merge-stopping)) is inside the span and stays suppressed. Worth a follow-up only if the fleet starts writing the colon form, which is where an unclosable false finding would come from.- nit — but the auth check is wide open and the chart prunes the PVC.reports nothing. Identical at7c3c2c1and atorigin/main77816fa, so this delta neither created nor worsened it; it is the residual of the same class B1 named, and closing it needs a "does the line carry a labelled defect AFTER the label" read rather than a wider window.- B1: blocker — the auth check is open.,- B1 blocker — …,- [B1] blocker — …,- B1 (**blocker**) — …, reports nothing at this head — and identically atorigin/main77816fa(the line-initial-token requirement inBLOCKER_FINDING_PATTERNS, untouched by this PR). The forms that do count are- B1: high — …,- B1 (blocker) — …,- Blocker B1 — …,- BLOCKER: …. So the "a labelled defect under a negation claim still counts" guard is real (- B1: high — …counts under## No blockers.and under## Blockers), but it rides on the adjective-id form, not on every spelling of the token.What I measured, so the verdict is auditable
infra-core22480, 22468, 22463;prod22467, 22464 — 0 false findings each at this head. That set carries the shapes the corpus does not:## Blockers+None.as a CONTENT line (22480),## Resolutions+## Concerns (non-blocking)+ a trailing## Blockers(22463), and two long seat verdicts with no headings at all (22467, 22464). All five were already 0 at the pre-delta head, so none of them is evidence of loss; the loss evidence is the 666-body sweep above.## Findings,## Blockersand## No blockers.): list markers-,*,1.before the label → suppressed; nested emphasis inside the label (- **__nit__:** …,- **F2 — _nit_: …**,- __nit__ — …) → suppressed here and COUNTED at the pre-delta head, so the anchor also fixed three emphasis shapes the 100-character window missed; label then em-dash then prose → suppressed;- **Nits** (none of these should stop the merge):→ suppressed;- (nit) …→ suppressed; TWO labels in one line (- nit: cosmetic, but B1: blocker — the auth check is open.) → reports nothing, at this head AND at both earlier heads — the token path swallows it, not the vocabulary (see concern 3).X is required, not optionalcounts at this head (0 at the pre-delta head) — the B1 fix, reproduced on my own probe as well as on the real comment.not Yas a LABEL:- not blocking: …suppresses (in the closed vocabulary), while- not merged yet: …,- not reviewed: …count and- not optional: …counts — the last is the negation rule doing its job (a negated word declares the opposite of itself), and the first two are outside the closed vocabulary, where counting is the fail-closed direction. I judge that correct as stated rather than a defect.## No blockers.from prod 22408 fails two tests; hiding 22414's claim in a code span (the claim wrapped in backticks) fails the prose guard, which is the C1 repair biting; planting- B1: high — the auth check is open on the write path.under 22414's claim fails BOTH zero-findings assertions (per-comment and per-repo stream). The fixture cannot be quietly edited into passing, and the zero-findings assertions are not self-fulfilling.npx vitest run→ 831 passed / 32 files;npx tsc --noEmitclean;npm run test:deployed→ 32/32 files, 831/831, "suite ran on the pinned tree: 1.3.34". The #96/#97 heading-context pins, #100 id-less closure, #103 bold-negation normalisation and both 2682 suites pass inside that run (151 tests across the seven suites I re-ran by name).Not verified by me: the deployed tool in a live lock run (this is gate tooling; the PR is not merged and I ran no PR through it), and the frame of the propagation batch it unblocks.
The blockers raised in reviews 22465 are resolved on head
a37ae259b0: B1 (the label-span vocabulary swallow) is fixed and verified by both fresh seats; the remaining parsed lines are prose continuations and review-metadata, not defects.