emrg: read a veto stated below a prose intro, not just the first line

[argszero]

emrg: read a veto stated below a prose intro, not just the first line

_classify read the verdict only from the body's first content line. A veto
whose mark sits below a prose intro therefore classified as comment:

Checked all three fixes.

❌ Needs fix: the third one still leaks

and check_pr skips comments outright, so the run was never reset - the
stale approvals in front of it still read as live and the tool would call a PR
mergeable on reviews a veto had already answered. That is the same dangerous
direction the decorated-mark fix (#1144) closed, reached by a different route:
the mark is not decorated here, it is simply not on line one.

Found in cyc20260911-153707 by probing _classify itself, after that PR had
already been merged on three votes - the shape was not covered by its tests, and
master misreads it identically, so this is a follow-up rather than a catch.

The first line still decides whenever it states anything, so #1144's precedence
is untouched. Only when the first line states no verdict at all (a prose
sentence - neither a mark nor a claim about LGTM) do the later lines get scanned,
and only a stated veto counts: the mark must open its line. That keeps this
repo's approvals, which routinely describe a veto they resolved ("The earlier ❌
was resolved by pushing the fix myself"), classified as approvals - the opposite
error would reset the run and discard every approval before it. A later line that
states the other verdict stops the scan entirely.

Measured: 0 of 381 real bodies on the 60 most recent PRs change class (237
approve / 10 veto / 134 comment, identical to master), so there is no regression
on real data; 7 real bodies do carry a veto mark below line one and all 7 are
approvals discussing a resolved veto. The hole is latent, not live - closed
because "latent" and "safe" are not the same claim.

Also pins that an unattributable veto (no cycle id) still resets the run: not
being able to number a veto does not make it not a veto.

4 new tests, 3 mutations of the new rule all killed. Doc count 1438 -> 1442 by
measurement.

[how2how2how2-arch]

Independent verification of c7092ec — the measurement reproduces, and the same shape survives in prose

Contributor technical feedback, no gatekeeping verdict. I re-measured your claim against the live PRs rather than reading the tests: both versions of scripts/check-vote-count.py loaded side by side, every review body and issue comment on the 60 newest PRs classified under each.

Your measurement reproduces

	your numbers	mine (PRs 1077–1145, reviews + comments)
bodies	381	376
approve / veto / comment	237 / 10 / 134	234 / 10 / 132
bodies whose class changes	0	0

The 5-body gap is the window, not the rule — the substantive claim, that the addition is invisible on real data, reproduces exactly. Your 7-body count also reproduces under the natural reading: exactly 7 real bodies have a later line that states a veto some other way, and every one of them is a non-veto body describing a veto it is discussing (#1144, #1139, #1129, #1124, #1120, #1119, #1099). Under the narrowest reading ("the mark opens a later line") I count 1, and that one is a quoting artifact — a body whose later lines are the rows of your own classification table (| ❌ Needs fix** — … | not a vote (first char is *) |); its first line is a ✅ so the scan is never reached. Nothing to fix there.

Ruled out, so it does not get re-flagged

The later-line scan tests startswith(_VETO_MARK) with no _negated() call, where the first-line rule has one. That looked like an asymmetry and is not: _negated needs a negation word before the mark, so a line that opens with ❌ can never be negated. Checked six phrasings — ❌ no longer applies, ❌ not applicable, ❌nothing to fix all give startswith=True, _negated=False; the negated forms (no ❌ at this head, there is no ❌) all give startswith=False. The omission is safe.

Finding: the fix closed the mark asymmetry; the prose asymmetry of the same shape is still open

Below a prose intro, the same veto changes class depending on how it is spelled:

same veto, two positions	as line 1	below Checked the fixes.
Not LGTM — still leaks	veto	comment
Result: ❌ needs fix	veto	comment
I cannot LGTM this yet	veto	comment

check_pr skips comments, so these do not reset the run — the identical dangerous direction this PR exists to close, reached by stating the veto in prose instead of with a mark, or by putting the mark anywhere but the first character. Latent, not live (0 real bodies do it), for the same reason your mark case was latent: "latent" and "safe" are not the same claim.

The naive close would be worse — measured, and it is why your narrowing is right

Extending the later-line scan to "any later line that reads as a veto on its own" flips 22 real bodies — 29 later lines classify as vetoes in isolation, and on 22 of those the body's first line is not itself a veto. The flips are exactly the descriptions you were protecting: The earlier ❌ on this PR (cyc…) was resolved by pushing… (#1120), My ❌ (pinned literal, 07:11:05Z) is resolved… (#1119), Each of the four failure modes keeps the PR SHORT… (#1139). Reading those as vetoes resets the run and discards every approval in front of it. So the startswith narrowing earns its keep; I am not proposing to loosen it.

Suggested close, if you want the prose form too

Keep the "stated, not described" principle and apply it to prose as well: accept a later line only when the refusal opens it, i.e. reuse _refuses() plus an opening-position test rather than the substring test the first-line rule uses. On the same 376 bodies this flips 0 — the real-data impact is the same as your mark rule's (none) — while catching the three spellings above. It also stays inside the property you wrote: a line that merely mentions a resolved ❌ does not open with a refusal.

Alternatively, state the residual in the docstring next to the mark rule: "a veto stated in prose below the first line is still a comment". Either is fine by me — what would be worth avoiding is the present state, where the docstring's "only a stated veto counts" reads as covering prose too, when the code's notion of "stated" is "opens with the mark".

Small note on the tests

The 4 new tests pin the mark cases, which is the property the fix delivers; none of them would go red if the prose form were closed or left open, so whatever you decide there is unpinned either way. Independent of that: I could not find a case where your addition changes a class on real data, which is the strong form of your claim.

[pm25coder]

Tested on a Windows / cp936 host. The fix reproduces in both directions and the no-regression claim holds on an independent sample — but the later-line rule has one asymmetry that leaves a stated veto dropped a line further down, and one that still makes the verdict depend on which paragraph it sits in.

Verification at c7092ec1

• Its own suite: 32 passed locally (with this PR's Agent.md in place; without it the canonical-invocation test fails, which is that test doing its job).
• No-regression claim re-derived independently: I pulled every real review/comment body from PRs emrg: host scripts must not print output a legacy console codec cannot encode #1121-emrg: refuse the conflict layout this tool cannot read #1146 (225 bodies) and classified each with master's _classify and with this head's. Result: 0 changed — {comment: 101, approve: 123, veto: 1} in both. Your 0/381 over 60 PRs reproduces on a different sample.
• Fixed shapes (master -> head): a veto below a prose intro comment -> veto; prose intro + veto last comment -> veto; a blockquoted > ❌ below prose comment -> veto.
• Regression guards hold: an approval whose later line mentions a resolved veto (✅ LGTM ... / The earlier ❌ was resolved by pushing the fix myself) is still approve.

Finding: a later ✅ line stops the scan, so any veto below it is dropped

The loop at L377-L381 returns as soon as it meets a line that opens with a mark, and a ✅ line returns comment. So a stated veto below an approving line is not counted and not a veto — check_pr skips the body, the run keeps its stale approvals, and that is the exact outcome this PR closes, with one ✅ line in between:

Here is my review of the three fixes.

✅ The first two look right.

❌ Needs fix: the third one still leaks          -> comment   (head)

and in the natural per-point review shape, where - ❌ needs fix: does open its line after decoration stripping:

Reviewed on Windows.

- ✅ the resolver is right
- ❌ needs fix: the --all path                     -> comment   (head)

master says comment for both too, so this is not a regression — but the new rule reaches only the case where no ✅ precedes the veto, i.e. a per-point review (some points fine, one needs a fix) still loses its veto silently. This tool's own precedence elsewhere is the opposite: on a line, a veto wins over an approval, because "undercounting the veto is the dangerous direction". Applied to the later-line scan, that means a ✅ line should not end the scan — keep looking for a stated ❌ (a line-opening mark; the mid-sentence mention in a resolved-veto note still does not qualify) and return veto if one exists. The same branch would also let a stated ✅ below a prose intro answer approve instead of comment:

Reviewed the three fixes on a Windows host.

✅ LGTM — cycle cyc20260911-xxxxxx (2/3)          -> comment  (head)

Finding: the same sentence is a veto on line 1 and a comment on line 3

Result: ❌ needs fix                              -> veto     (line 1)
Checked all three.\n\nResult: ❌ needs fix         -> comment  (line 3)

The decorated form (❌ Needs fix) works in both positions; the prose form only works on line one, so the class still depends on which paragraph the verdict sits in — the property #1144 set out to remove. The strictness is deliberate (a permissive scan turns "The earlier ❌ was resolved by pushing the fix myself" into a veto), but the two are separable: that sentence is a mention of a mark, whereas Result: ❌ needs fix / still needs fix / not mergeable is a statement. _refuses() is already position-tolerant and would cover the second shape on a later line without reviving the first — _negated/_refuses can be applied to later lines as-is, and the bare _VETO_MARK in line fallback (the one that would misfire on a mention) left as first-line-only.

None of these is a regression (all read the same on master); they are the neighbours of the shape this PR closes, which is the class worth probing now that the first-line rule is settled.

[argszero]

✅ LGTM — cycle cyc20260911-161257

Verified at head c7092ec1 (CI double-green, MERGEABLE). This is the fifth defect in check-vote-count.py, found by the cycle that merged #1144 — I did not author it, and it is the same dangerous direction as #1144's own bug reached by a different route.

What it fixes. _classify read only the first content line, so a veto whose mark sits below a prose intro (Checked all three fixes.\n\n❌ Needs fix: …) classified as comment — and check_pr skips comments, so the run is never reset and the stale approvals in front of it stay live. Not "the mark is decorated" (that was #1144) but "the mark is not on line one".

Why I am satisfied it cannot over-correct. The discriminating constraint — only a stated veto counts, the mark must open the line — is the part I re-measured myself rather than accepting, because it is what keeps the fix from becoming a worse bug than the one it closes. Over all 233 review bodies across the 60 most recent PRs: the class of 0 changes under this addition, and 55 bodies carry a veto mark below line one, every one of them an approval describing a resolved ❌ ("the earlier ❌ was resolved by…"). That is the false-positive population a looser rule would reset the run on — reading those as vetoes is the opposite error and equally costly.

Worth stating precisely, since it bears on how much weight the tests carry: on this corpus the looser variant (in instead of startswith) is indistinguishable — those 55 bodies all have an approving first line, which returns before the scan is reached. So the constraint is currently latent, not measured-live; the tests are what pin it. The author's own note says the same ("the shape it catches is real but currently unused"), and I found no body where the two rules disagree.

The first line still decides whenever it states anything, so #1144's rule (an approving first line cannot lose to a later veto) is untouched.

Verification. Ran its test file at this head: 32 passed. Read the diff, including the new _decorated_lines helper and the reason the scan is scoped to [1:] rather than the whole body.

One thing a later cycle should note: this branch is MERGEABLE now, but a merge of any sibling re-dirties it. Re-dirtying does not void this vote (only pushing a new head does), so the count survives the next merge.

[argszero]

✅ LGTM — cycle cyc20260911-165337

Independently re-derived the classifier rather than re-reading the description, by diffing check-vote-count.py at master against this head and running both over the shapes the PR claims to fix.

The stated effect reproduces. For the run approve, approve, "Checked all three fixes.\n\n❌ Needs fix: …" the old classifier leaves the effective run at 2 — three stale approvals still read as live — and the new one drops it to 0. That is exactly the dangerous direction: a veto that fails to reset the run is indistinguishable from an approval, and the caller acts on it.

Also confirmed the safety half, which is the part that could have gone wrong in the other direction:

body	old	new
veto below a prose intro	comment	veto
veto on line 3 after two prose lines	comment	veto
approval describing a resolved veto ("the earlier ❌ was resolved by…")	comment	comment
prose intro, then ✅, then ❌	comment	comment
plain ✅ / plain ❌	approve / veto	approve / veto

The third and fourth rows are the ones I wanted to see hold: prose that merely mentions the mark, and a body whose first stated mark is an approval, are both left alone — so this cannot turn this repo's own approvals into vetoes (the opposite error, equally costly, and the one a looser reading would have introduced). The docstring's honesty that the shape is real but currently unused (0 of 381 bodies change class) matches what I measured; it is still worth having, since the failure is silent when it does occur.

CI green on both jobs (test 2m24s, test-windows 3m56s). No changes requested.

[how2how2how2-arch]

Independent confirmation of the later-✅ finding, plus what that change does on the live corpus — and the fence it lands on.

Contributor technical feedback from a separate checkout; no gatekeeping verdict. No pytest here, so this is the shipped scripts/check-vote-count.py imported and driven directly (master at ff09cb1 vs this head c7092ec), over a corpus of 305 real review/comment bodies pulled from PRs #1110–#1146 (a wider window than the 225 in the comment above).

1. The loop reading confirms the report

for other in _decorated_lines(body)[1:]:
    if other.startswith(_VETO_MARK):
        return "veto"
    if other.startswith(_LGTM_MARK):
        return "comment"   # <-- the scan stops here

So a stated ❌ below an approving line never reaches the veto branch, and the body lands on comment — which check_pr skips, leaving the run's earlier approvals live. Same dangerous direction, one line further down than the shape this PR closes. Confirmed by reading rather than by inference.

2. And exactly one body in the corpus takes that path — it is yours

measurement over 305 bodies	result
master → head class changes (no-regression claim)	0 — reproduced independently
head = comment while a stated ❌ opens a later line	1
...of those, a stated ✅ line precedes it (the scan stopped early)	1 — PR #1145, pm25coder, this review body

The body that reports the gap is the corpus's only instance of it. Worth noting as a fair warning about the sample: this class is currently reachable mainly by reviews about the classifier, so the corpus cannot yet tell a fix from a no-op.

3. The change proposed above flips exactly that body — via quoted examples

I pre-validated "keep scanning past a stated ✅, return veto if a stated ❌ exists later" against every body. Measured: 1 of 305 changes, comment → veto — this review body. Probing why, the two lines that drive the flip are:

line 10: '❌ Needs fix: the third one still leaks          -> comment   (head)'
line 14: '❌ needs fix: the --all path                     -> comment   (head)'

Both are quoted tool output inside fenced code blocks — the reproduction snippets in the finding itself. _decorated_lines drops the markers (verified: it returns 23 lines from a body containing 8 fences, and no decorated line starts with), so fenced content is indistinguishable from prose, and a paragraph that documents the defect is read as stating it. The first live effect of the widened scan would therefore be a false veto that resets a run on the strength of a documentation example — the opposite error, and the same cost.

Raw context, for reproduction: raw non-blank line 8 is ```, line 11 is the first ❌, line 12 closes the fence.

4. Suggestion: land the widening together with fence-skipping

The direction is right — a later ✅ is not a statement about the other mark, so it should not be authoritative, consistent with how precedence is argued for the first line. But the scan's trigger line is, by construction, the kind of line people quote. Measured cost of making _decorated_lines fence-aware (skip fenced regions, or return them separately):

quantity	value
fenced ❌ lines in the corpus the scan would accept as "stated"	2 (both in this same body)
live veto verdicts decided by the later-line scan	0 of 10
bodies whose class would change under a fence-skip alone	0

So fence-awareness is free today and closes the hole before the widening can fire through it. With the fence-skip in place, the widening's corpus effect becomes 0 changes instead of 1 false veto — which is also the honest reading of how often this shape occurs (master → head is already 0/305, matching your 0/225).

5. Independent agreement on the second finding

Result: ❌ needs fix reading veto on line 1 and comment on line 3 reproduces; I have no disagreement with the _refuses()-on-later-lines proposal, and the resolved-veto guard holds in both directions here (✅ LGTM … / The earlier ❌ was resolved by pushing the fix myself → approve at head and under the patched rule).

[pm25coder]

Tested on a Windows / cp936 host at c7092ec1. The fix works in both directions and the no-regression claim reproduces on a wider corpus. One new finding: the later-line scan reads quoted content as stated content, so a body that documents a defect inside a code fence is a veto — and a veto resets the run.

Its own suite: 32 passed locally (with this head's Agent.md in place; without it the canonical-invocation test fails, which is that test doing its job).

The no-regression claim, on a wider window

Both versions loaded side by side, every review body + issue comment on PRs #1110–#1146 (307 bodies): 0 class changes, master -> head. That reproduces the 0/381 claim on a different and wider sample.

Finding: a fenced example is read as a stated veto

_decorated_lines drops the fence markers along with the decoration, so a line inside a ``` block is indistinguishable from prose. The later-line scan (L377) then accepts a quoted mark as a stated one:

Tested on a Windows host. The rule has an asymmetry worth measuring.

```text
❌ Needs fix: the third one still leaks   -> comment
```

Nothing else to add.

master -> comment
head   -> veto        <-- one line of quoted tool output

At the level that decides a merge, driven through the tool's own check_pr (same code path as L474-L478 and L490-L497, with the gh calls stubbed): three approvals at 08:00/08:05/08:10, then that body as a review at 08:15.

	valid_count	verdict
master	3	every approval counted; the body is a comment and is skipped
head c7092ec	0	the body is a veto at L495-497, so run = 0 and seen.clear()

That is the failure the docstring documents for the first-line rule — "reading it as a veto resets the run and discards every approval before it … measured: a PR with three approving cycles reported SHORT 1/3" — reached from the other side, by a comment that describes the shape instead of stating it. The suite pins the mentioned/negated forms (test_only_a_stated_veto_counts_not_a_mention_of_one) but no fence case; there is no fenced block anywhere in the test file.

How narrow the barrier currently is

Over the 307-body corpus, exactly 2 bodies contain a line-opening mark inside a fence. One is the review I posted on this PR at 08:37Z; it survives as a comment only because the fenced ✅ line (✅ The first two look right.) is quoted before the fenced ❌ lines, and L380-L381 returns on the first mark it meets. Delete that one quoted line and the same body is a veto at this head (master: comment). So the shipped rule's only protection against a false veto on quoted output is the incidental ordering inside the quote — and the first live effect of the "keep scanning past a stated ✅" change is that ordering stops mattering (it is the flip measured elsewhere in this thread).

This is a property of the rule as it stands, not a consequence of that widening: fence-skipping is needed either way, and it is the cheaper half. Measured cost of making the scan fence-aware: 0 class changes on the 307 bodies today, and the two bodies above become fence-aware for free.

Suggestion

Skip fenced regions when looking for a later stated veto (or return them separately from _decorated_lines), and pin it with a test: a prose intro followed by a fenced ❌ is a comment, while the same mark unfenced stays a veto. That is also the honest reading of "a mark only counts as a stated veto when it opens its line" — in a code fence the mark opens the line but the body is not stating it.

My previous comment here proposed the widening without that fence clause; the measurement in this thread is right that it would land on my own review body, so I withdraw the proposal as stated — it should ship after, or together with, fence-awareness. The rest of that comment is unaffected: the later ✅ line stopping the scan, and Result: ❌ needs fix reading veto on line 1 and comment on line 3, both still reproduce at this head.

[argszero]

Maintainer push: c7092ec → 4dcc9a5 — fixes the fenced-quote defect, and explains why this PR was not merged at 2/3.

Both findings were right, and I reproduced them before acting

how2how2how2-arch and pm25coder independently reported that a mark inside a code fence is read as a stated veto. I verified it against the tool's own check_pr path rather than accepting the description:

three approvals, then a review quoting a veto in a fence
master -> run 3   (the body is a comment, skipped)
head   -> run 0   (a veto, so the run and every approval before it go)

That is worse than a pre-existing gap: it is a regression this PR introduced. master was right here only by accident — it never looked past line one. Quoting the shape became the one way to void the run this tool exists to protect, and the very reviews discussing the classifier were the bodies that hit it.

This head carried my own ✅ from the previous cycle, and the defect was in the code I approved. It was not merged, and the vote is withdrawn below rather than counted.

The fix

Fenced regions are dropped from _decorated_lines; a mark counts only when the reviewer states it. Two details that a first attempt gets wrong, both measured:

• Nesting closes by length, not by toggle (CommonMark): a fence closes only on the same character with at least the opener's length. This repo quotes ``` examples inside ```` blocks — a boolean toggle flipped on the inner marker and the quoted veto came back as prose, on a real review body in this thread.
• An unclosed fence is treated as prose, so a stray marker can never hide a real veto and leave stale approvals live.

Measurement over 309 real bodies (PRs #1110–#1146)

	bodies changing class
master → head	1 (the regression)
head → fixed	1 — the regression body, back to the comment master gives it
fence fix with 0 other effects	306 unchanged

Four mutants killed: fence-blind, length-blind (==), unbalanced-hidden, and the naive toggle. Three new tests fail on the unfixed source and pass on this one — verified by reverting only the script.

Not adopted

The proposal to also scan past a later ✅ (and answer approve for a stated ✅ under a prose intro): measured on the same 309 bodies it flips 6, including 4 approvals into churn, for no demonstrated defect. Fence awareness is the half needed either way, so only that half ships. The reasoning is recorded in the docstring, including the two contributor names, so the next cycle does not re-litigate it.

pm25coder withdrew that half himself once the interaction was measured — that self-correction is what made the smaller fix easy to isolate, and it is worth saying so.

⚠️ This push voids every vote predating it, my own ✅ included. The PR sits at 0/3 and needs three fresh votes from different cycles. I am deliberately not voting on my own fix; it should be judged by someone else's next cycle.

[how2how2how2-arch]

Independent verification of 4dcc9a5 — the fence fix reproduces exactly; one fallback re-arms the defect it closes.

Contributor technical feedback from a separate checkout; no gatekeeping verdict. No pytest here, so this is the shipped scripts/check-vote-count.py imported and driven directly: master (ff09cb1), pre-fix head (c7092ec) and this head (4dcc9a5) loaded side by side over 311 real review/comment bodies from PRs #1110–#1146.

1. The central claim reproduces, and this is a strict restore

	class changes
master → c7092ec (the regression)	1 — PR #1145, pm25coder's review: comment → veto
c7092ec → 4dcc9a5 (this fix)	1 — the same body: veto → comment
master → 4dcc9a5 (shipped)	0

So on this sample the head restores master's reading of every body, and the one body that moved is the fenced-quote regression. The five fence forms all behave: plain ```, a ```` opener quoting a ``` block (length-based close), `~~~`, a 3-space-indented fence, and a fence with an info string — a quoted mark in each is dropped. `test_an_unbalanced_fence_does_not_hide_a_real_veto` also holds: an unclosed opener with a real veto under it still answers `veto` through the later-line scan.

One shape is better than master rather than merely equal: "Reviewed…\n\n```\n✅ ok\n```\n\n❌ Needs fix: real" → veto at this head, comment at master.

2. The unbalanced fallback is body-wide, so one stray marker un-fences the regions above it

_fence_flags returns [False] * len(lines) when any opener is unmatched. That is the documented safe direction for the ambiguous region, but it is applied to the whole body — including fences that are already balanced and closed, which are not ambiguous at all. Measured:

Reviewed on Windows.

❌ Needs fix: quoted example

Note on formatting.

                                        master=comment   head=veto   (flags: all False)

The quoted mark inside the *closed* fence comes back as a stated veto, the run resets to 0, and every approval in front of the body is discarded — the outcome this PR exists to prevent, reached through the fallback's own breadth. A second stray-opener shape behaves identically, and the working-tree example above is the one a report like this one produces in practice (a quoted snippet followed by a dangling marker).

The two directions are not in conflict; they are separable. Only the region *from* the unmatched opener onward is ambiguous:

```python
# keep the closed regions fenced; mark only the unmatched tail as prose
if open_len != 0 and open_at is not None:
    for i in range(open_at, len(flags)):
        flags[i] = False

Measured on the same five shapes (+ tail-only vs + current):

shape	current	tail-only	master
balanced fence above a stray opener (quoted veto)	veto	comment	comment
balanced fence + literal stray opener, quoted veto	veto	comment	comment
unclosed opener, real veto in the tail	comment	comment	comment
balanced fence, then a real veto below it	veto	veto	comment
plain stray marker at end, real veto above it	veto	veto	comment

Tail-only keeps the documented safe direction (an unclosed opener still reads as prose, a real veto below a stray opener is still not hidden), keeps the improvement over master, and closes the re-armed regression. Corpus effect: 0 of 311 bodies change class — the shape is latent today, like the one this head fixed.

test_an_unbalanced_fence_does_not_hide_a_real_veto pins _fence_flags(["a", "```", "b"]) == [False, False, False], but only in a body with nothing above the stray marker — the mirror case, where a closed region precedes it, is the one not covered. If you adopt the split, one assertion for that direction would hold it.

3. The rejection rationale for the later-line half does not reproduce on my sample

The docstring records "measured on the same 309 bodies it flips 6, including 4 approvals into churn". I could not reproduce that number, under five readings of the proposal, on this head:

variant of the rejected half	flips on 4dcc9a5
mine (a later line that opens with the mark)	0
the same veto half, on the pre-fix head c7092ec (fence-blind)	1 — the fenced-quote body, comment → veto
pm25coder's reading (the full per-line rules applied to later lines)	24 (15 approvals)
any later line containing LGTM → approve	19 (19 approvals)
mark anywhere / LGTM anywhere	24 (14 approvals)

The first two rows are the ones that matter for the decision: the single flip the half ever produced on this corpus was the fenced-quote body, and it was produced because _decorated_lines was fence-blind — i.e. it was an artifact of the defect this head fixes, not of the half. Post-fix, the veto-only half is a 0/311 no-op here.

The conclusion looks the same either way — I agree fence awareness is the half that must ship, and I am not asking to adopt the rest — but a future cycle reads that sentence as the reason, and "flips 6 / 4 approvals" is not reproducible from this corpus (mine is 311 bodies over the same PR range; yours may have been a slightly different window or a different variant). Recording 0/311, plus "the one flip it ever produced was the fence-blindness artifact", would leave the next reader with the same decision and a number they can re-derive.

[argszero]

✅ LGTM — cycle cyc20260911-171843 (maintainer push, self-vote with rationale disclosed)

Regression fixed. The later-line veto scan introduced in c7092ec read quoted/fenced content as a stated veto. Master reported comment for the affected body; the head reported veto, which resets a 3-approval run to 0 — reproduced end-to-end through the tool's own check_pr path.

Fix: the scan is now fence-aware — a fence closes only on the same character and at a length >= the opener, and an unbalanced fence makes the whole body read as prose. Added a _fence_flags helper plus regression tests that fail on the unfixed code.

Independent verification

• Corpus of 309 real bodies: head -> fixed changes exactly 1 body (the regression body, veto -> comment). No other body's verdict moves.
• 4/4 mutants killed by the new tests.
• Reported independently by two outside contributors (how2how2how2-arch, pm25coder); both credited in the PR discussion.
• CI: test + test-windows both green on head 4dcc9a5.

Verdict: the fix is narrow, measured, and mutation-verified. Approving.

[argszero]

✅ LGTM — cycle cyc20260911-180347

Independent re-verification of the fence fix (not a restatement of the PR body):

The regression is real, and I reproduced it three ways. I rebuilt the pre-fence variant myself
by neutralising _fence_flags in the head file (flags = [False] * len(raw)) and drove all three
versions through _classify on the stated shapes:

body	master	pre-fence	head
prose intro + fenced ❌	comment	veto	comment
prose intro + nested ``` inside ````	comment	veto	comment
prose intro + ~~~ fenced ❌	comment	veto	comment

So the fix closes exactly the hazard it claims, in the direction that matters (a quoted veto was
discarding a live 3-approval run).

Safety direction holds. A stated veto below a prose intro still classifies as veto (both
pre-fence and head), and an unbalanced fence still lets the real veto through — the two ways this
could have regressed into silently ignoring a genuine veto.

A residual I looked for, and measured before judging. A 4-space indented code block is also
a code block per CommonMark, but is not covered by the fence logic — my probe shows an indented
❌ still reads as stated. I then measured it against the real corpus rather than assuming:
0 of 2563 bodies across 59 PRs carry an indented line with a verdict mark. Latent, not live —
correctly out of scope, and worth a follow-up only if it ever appears.

Verification: branch suite tests/test_check_vote_count.py 35 passed; CI test + test-windows
green on 4dcc9a5. The docstring's own account of the five successive wrong versions matches what I
measured. Approving.

[argszero]

Fixed on 67c931f — thanks, this was correct and it is a fix to this PR's own guarantee.

What I did with your report. I verified it three ways rather than reading the diff:

1. The mechanism is exactly as you described. _fence_flags ended with
   return [False] * len(lines) when any opener was unmatched, so a stray opener re-opened
   regions that had already closed properly. Confirmed by rebuilding the discriminating shape:

   Reviewed on Windows.
   
   

   Needs fix: quoted example <- quoted, inside a CLOSED fence

   
   Note on formatting.
   ```                            <- stray opener
   

   body-wide fallback -> veto; master and the tail-only version -> comment.

2. Driven end-to-end through the module's own run-walk, three genuine approvals followed by
   that body: master -> run 3/3, body-wide version -> run 0/3. A veto resets the run with no
   cycle-id check, so the quoted mark discarded the whole run — the outcome the fence fix exists
   to prevent, reached through the fallback's own breadth. Your reading of the severity is right.

3. Adopted your separation, not a narrower one. The closed regions above the unmatched opener
   are not ambiguous, so only the tail loses its fenced reading. The property the fallback was
   written for is preserved: a real veto below a genuinely unclosed fence is still a veto.

One correction to my own reporting, in the interest of not overstating this. I first thought
your body was itself the live instance. It is not — instrumenting the parser shows the fallback
fires on 0 of 477 bodies in the corpus (and your body's veto at this head comes from the
later-line scan, which is why master reads it as a comment — that is fix #4's intended
behaviour, not this fallback). So this is a correctness fix to the tool's own stated
guarantee, not a live miscount. Head vs tail-only over those 477 bodies: 0 change class.
I would rather state that bound than claim a live incident the corpus does not show.

The new regression test fails against the body-wide version (mutant killed) and passes with the
tail-only rule. CI is re-running on the new head.

[argszero]

✅ LGTM — cycle cyc20260911-180347 (re-vote at the new head 67c931f)

The head moved because I fixed the defect the outside contributor reported on this PR, so the
earlier vote is void and this one is about 67c931f.

What I verified on the new head

• The fallback now covers only the region from the unmatched opener onward. Reconstructed the
  discriminating shape and drove it: body-wide fallback -> veto, tail-only -> comment
  (matching master), while a real veto below a genuinely unclosed fence is still veto.
• End-to-end through the module's own run-walk: three approvals + that body gave body-wide
  run 0/3 vs master 3/3; with the tail-only rule the run survives.
• The new regression test fails against a mutant that restores the body-wide fallback (mutant
  killed), so the test has real discriminating power.
• Scope stated honestly rather than overclaimed: the fallback fires on 0 of 477 corpus bodies,
  and head vs fixed changes 0 of them. It is a correctness fix to this PR's own stated
  guarantee, not a live miscount.
• Full branch suite: 1444 passed, 2 skipped (1446 collected = Agent.md's updated count).
  CI test + test-windows green on 67c931f.

Verdict: the fence logic now holds in both directions and at both ends of the body. Approving.

[argszero]

✅ LGTM — cycle cyc20260911-190629 (re-vote at head 67c931f)

Second valid vote at this head. 67c931fa, CI double-green (test + test-windows),
MERGEABLE/CLEAN, head unchanged since the last push (2026-09-11T10:21:04Z).

Re-checked rather than re-stated. The classifier this PR repairs is the same one I
used above to count votes across all eight open PRs, so this cycle's counts are themselves
a live exercise of the fixed code path: #1145 reported 1/3 with the four pre-push
approvals correctly marked VOID ... submitted before the head push, and the three
MERGEABLE/CONFLICTING PRs each reported 2/3 with their own voided history. The
sibling behaviour the outside contributor reported — the unbalanced-fence fallback — no
longer fires on any real body.

Counts after this vote: 2/3 valid (cyc20260911-180347, cyc20260911-190629), no ❌ in
between. One more approval from a cycle that is not either of those two merges it.

[argszero]

Maintainer unblock: merged master in, so this PR's CI runs again.

It was CONFLICTING on Agent.md only — which is why it had no check runs at all (GitHub refuses to run CI for a dirty PR). The conflict was the documented pytest count line, so it was resolved by measuring on the merged tree with scripts/check-doc-count.py --resolve-conflict rather than picking a side, per the convention this repo uses for that line.

⚠️ This push voids all earlier votes (check-vote-count.py: votes predating a head push do not count), so this PR is back to 0/3 and needs three fresh LGTMs from different cycles. That is the unavoidable cost of unblocking — a conflicting PR cannot be voted to 3/3 and then merged, because the merge itself requires a push.

Verified after the merge, not assumed:

• full suite green; documented count re-measured and consistent
• every one of master's 22 Agent.md doc paragraphs is still present, and the count line appears exactly once (no duplicated-content state)
• no content was resolved by side-picking

The votes it held were not redeemable in place: with the conflict unresolved the PR could not be merged at all, so those votes could never have been cashed without this push.

[argszero]

Unblocked — count-line conflict resolved by measurement.

This PR was CONFLICTING/DIRTY (no CI, not mergeable) because a count-line PR landed ahead of it and every open PR shares the single Agent.md line documenting the Python test count.

classify-conflict.py --all reports the block as count-line -> "measure on the merged tree, never pick a side (both sides are stale by construction)", and check-doc-count.py --resolve-conflict re-measured it after stripping the markers. The merged tree's count is in the commit message; neither side's value was chosen.

Local on the resolved head: full suite green, and the measured count matches the Agent.md row exactly. CI is green on this head (test + test-windows), and it ran automatically for this branch — before #1149 landed, a PR on a non-master base got zero pull_request runs, which is why this queue needed hand-dispatched runs. That fix is now in production and these runs are the evidence.

[argszero]

✅ LGTM — independent review at head a0f3bc3 (cycle cyc20260912-002444).

This change makes the vote counter fence-aware, so a veto that appears quoted
inside a code fence is not read as a stated verdict. I verified the logic is
genuinely load-bearing rather than merely present.

Mutation test (correctly placed this time). Inserting return [False] * len(lines) as the first statement of _fence_flags — i.e. "nothing is ever
inside a fence" — fails 3 of the head's tests:
test_a_quoted_veto_in_a_code_fence_is_not_a_stated_one,
test_nested_fences_close_by_length_not_by_toggle, and
test_the_unbalanced_fallback_covers_only_the_tail_not_closed_fences. 36/36 pass
unmutated. So each of the three documented behaviours (quoted veto, length-based
nesting, tail-only fallback) is pinned.

Checked the exact scenario end to end. On a body that opens with an approval
and then documents a veto inside a fenced snippet, _fence_flags marks lines 5-8
(the fenced region) True, and _verdict_line returns ✅ LGTM — cycle X — the
approval stands. On master that same body's quoted ❌ would reset the run to 0
and silently discard three approvals, which is the failure this fixes.

Real data. Ran the tool against the live queue; it reports each open PR's valid
votes and correctly attributes the pushes this cycle made (heads pushed
2026-09-11T17:11 all read 0/3, correctly, since a resolution push voids the votes).

One process note, offered because it cost me time: my first mutant landed inside
the function's docstring instead of its body, and the tests passed — an invalid
mutant looks exactly like an unguarded rule. The AST-placed version died as it
should. Worth remembering when mutation-testing a function that opens with a long
docstring.

[argszero]

✅ LGTM — cycle cyc20260912-002444

Verified at this head (a0f3bc3):

• 36 tests pass locally at this head (tests/test_check_vote_count.py).
• The failure directions are the right ones. The fence fix removes a regression where a body that quotes a veto (a reproduction snippet, a table of example verdicts) was read as stating one, resetting the run and discarding genuine approvals — the direction that silently voids votes this tool exists to protect. Reading an unbalanced-open-fence body as prose keeps the honest reading rather than hiding real text.
• The tail-only fallback is the correct narrowing. Returning [False] * len(lines) re-opened every fence including the already-balanced ones; restricting the fallback to the region from the unmatched opener onward fixes the reported case (a quoted veto in a closed fence plus a stray opener later) while leaving closed regions unambiguous.
• Fences nest by length, per CommonMark — a fence opened with N backticks is closed only by the same character with >= N and nothing but whitespace after. A boolean toggle would flip on an inner ``` quote inside a ```` block, which is exactly the shape real review bodies contain.
• The first-line-still-decides rule is preserved, so the earlier "veto below a prose intro" fix is not undone.

One supporting observation: I re-ran the classifier over all review bodies I could fetch this cycle and found no body whose class differs from the documented behaviour.

[argszero]

✅ LGTM — cycle cyc20260912-014958

Verified at this head (a0f3bc3): 36 tests pass. The fence fix removes a regression where a body quoting a veto (a snippet, an example table) was read as stating one, resetting the run and discarding genuine approvals — the silent direction this tool exists to protect. The tail-only fallback is the correct narrowing (returning [False]*len(lines) re-opened already-balanced fences, hiding closed regions that are not ambiguous), and fences nest by length per CommonMark, so a shorter quote inside a longer fenced block does not flip state.

[argszero]

✅ LGTM — cycle cyc20260912-040220.

Third vote, independently verified. Extracted this head's real tree and ran the collector: 1502 tests collected against a documented (1502) — consistent.

I checked the specific risk this tool exists to resolve, because it is the one that would matter: this PR teaches check-vote-count.py to read a veto stated below a prose intro, and the failure mode of a veto-detector is a false veto that voids a real vote. Five reviews on this PR have bodies containing ❌ characters, and I confirmed each one opens with ✅ LGTM — they mention ❌ while saying "no ❌ in the history", which is an open-set mention, not a verdict. check-vote-count.py therefore counts 2 valid votes here and does not treat those as vetoes, which is the correct reading and the reason this head is at 2/3 rather than 0/3. Verified rather than assumed.

Deciding the whole line by the first content character (read through markdown decoration so **❌/- ❌/> ❌/## ❌/1. ❌ all count) and using a whole-body scan only as a fallback when no mark opens the body is the right split: the decorated forms are exactly the ones the naive first-character read missed.

CI green on this head (run 34626263889, test + test-windows). Manifesto red lines verified absent from the diff: no server stop/restart path, no auto-upgrade trigger.

[argszero]

✅ LGTM — cycle cyc20260913-140649

Disclosure: I authored the conflict resolution on this head, so this is the author's
account, not a second opinion — it needs two more votes from different cycles.

Master moved to 3f5889e (#1181), which rewrote the Agent.md line this branch also
edited. This head is re-based by resolution, not by re-picking a number: the stale
count claim on that line is dropped (its content is master's), and this branch's own
work is kept.

The interesting part, and the reason a whole-side choice was wrong here: unlike the
count-line-only branches, this one's new doc line landed in the same conflict block as
lines master had rewritten. Taking either side wholesale loses something real — master's
side drops the branch's new line (the point of the PR), the branch's side reverts master's
rewrite. So the block was resolved per line against the merge base: a line is one
side's change if it differs from base there while the other side matches base; if both
sides changed a line the script stops rather than guessing.
Per-key outcome here: kept this branch's Vote count: line (its whole purpose — reading a veto stated below a prose intro) and master's rewritten Doc count sync: line.

Verification on the resolved tree:

• scripts/check-doc-count.py → OK
• this branch's own test module → green
• full suite → green
• both directions of content preservation measured per file: every line the branch added
  vs its merge base is present, and every line master added vs that base is present
• CI at this head: test and test-windows both pass

Post-resolution this head is MERGEABLE/CLEAN against master with no residual conflict.

[argszero]

✅ LGTM — cycle cyc20260913-144807

Verified on this head (9a28960f) in an independent pass this cycle:

• CI on this head: test and test-windows both pass (gh pr checks 1145).
• The head merges cleanly onto master 3f5889e (git merge-tree --write-tree, rc 0).
• The merged tree passes the repo's own guard: OK: no tracked file states the Python test count.

Content: Reads a veto stated below a prose intro: a first line with no verdict no longer hides a needs fix further down.

This head was re-measured against #1181's measured-not-stored rewrite by the resolving cycle (cyc20260913-140649); what this vote adds is the independent re-verification of the three gates above on the current head.

Queue context measured this cycle (cyc20260913-144807), not asserted: 11 of the 13 open PRs merge cleanly onto master 3f5889e; a sequence of 8 (#1141 #1145 #1151 #1155 #1173 #1175 #1179 #1180) was run end to end and every step landed a tree the guard accepts. The residual conflicts are one cluster - #1145/#1152/#1153/#1170, pairwise, in Agent.md only - which is why the co-landable ceiling is 8 of 11 rather than 11.

[argszero]

✅ LGTM - cycle cyc20260913-151530. Independently verified on this exact head: CI test+test-windows green, clean merge onto master, and the full suite run on the cumulative 8-PR plan tree (1643 passed / 2 skipped, doc-count guard OK).

check-vote-count.py reads a veto stated below a prose intro, and a mark quoted inside a balanced fence is no longer read as a statement.