Promote develop to main: Count Carried-Over Open Findings in pr_review.py

scripts/README.md

@@ -223,7 +223,7 @@ The digest also reports the **suppressed findings** a review body collapses into
 
 The digest reports the **previously missed findings** the second body format collapses under a counted heading of its own, findings the round raises against code the pull request did not change. They are the suppressed section's structural twin, a counted heading wrapping entries that open no inline thread, so `previously_missed=N (on_head=N earlier=N)` is read, counted, split and printed exactly as `suppressed=` is and for the same reasons, and the [merge gate][governance] counts them as outstanding findings the same way. They are counted apart rather than folded into that field because the two take different answers: a suppressed finding is one the reviewer chose to withhold, and this one it raised outright, so the fact that the branch never touched the code is a reason to decline one with evidence rather than a reason to leave it unanswered. No exit code rides on the field, as none rides on `suppressed=`, and it is printed where a round raised one or the `reviews` window was cut, so a repository whose reviewer never raises one sees no permanent zero while a window that could be hiding a round still says so, as `cr_outside_diff=` does and with the same trailing `+`. Each entry's severity arrives as a theme-switched `picture` element whose only textual carrier is its `img` `alt`, the rest being icon URLs that carry a version the set has already bumped once, so the badge is reduced to that text before the block prints and nothing here keys on the markup around it.
 
-Copilot's reviews arrive in two body formats. None of the ten bodies read here in the second carried a `Suppressed comments` heading, so the reading above found nothing in it, and that format states its own finding total instead, as a count per severity that is summed across the badges the line pairs them with, since reading its first number alone reported two findings for a round stating two of one severity and three of another. The markup is masked to one sentinel before any count is read, a badge carrying digits of its own in its attributes, and a run of more than four digits is an identifier rather than a count, which is the second guard under a mask that can terminate early on a bracket a URL carries itself. Every count the mask left is then summed, rather than each being paired with markup beside it, since which side of a count that markup sits on and whether the severity carries any is presentation rather than structure: a bold split, a bare prose split, and a reference-style link each read as one severity under a paired reading. Summing overstates and never understates, which is the direction chosen deliberately, and its named cost is that a line stating a total and then its context, `12 findings across 4 files`, sums to sixteen. A shortfall overstated prints a block a reader checks against the body and blocks no merge, where one suppressed closes the gate on findings nobody answered. `overview=T/M` reports that total beside the number of review threads the round actually opened, `?` for `T` where no total is found in the overview preamble or a count-first open-findings section, since a total absent and a total of zero are different readings. A `?` covers a round stating no total, a round stating one only after its first collapsed section in anything but the open-findings section described below, and a round stating one as a bullet, that last blocking at exit 43 as an unvetted metadata label. None of them says the round withheld nothing. `M` comes from the API rather than the review's prose: that format enumerates the findings it opened threads for, and the anchor each entry links is the database id of that thread's own comment, so the threads are the same set already structured. Reading the enumeration instead took six attempts and four of them cancelled a shortfall by counting something that was not an entry, which needs a Markdown parser to tell apart rather than a line scan. A total larger than the thread count is findings raised where polling threads cannot see them, and a `FINDINGS WITH NO THREAD` block follows naming the shortfall, except where a count-first open section supplied the total, as the next paragraph says. A thread past the hundred `reviewThreads` reads would count in `M` too, so a cut page overstates the shortfall and `threads=` carries the trailing `+` that says so. The comparison holds while the round's enumeration lists what that round raised, and a format listing findings still open from earlier rounds states a total `M` undercounts, which is a shortfall to confirm against the body rather than to act on from the number. The field is present only where the round covering the head is written in that format, and it is head-scoped where `suppressed=` is not, because a total is one round's statement about one diff and the push that changes that diff raises a round stating its own, where a suppressed block carries the finding text an answer is still owed to.
+Copilot's reviews arrive in two body formats. None of the ten bodies read here in the second carried a `Suppressed comments` heading, so the reading above found nothing in it, and that format states its own finding total instead, as a count per severity that is summed across the badges the line pairs them with, since reading its first number alone reported two findings for a round stating two of one severity and three of another. The markup is masked to one sentinel before any count is read, a badge carrying digits of its own in its attributes, and a run of more than four digits is an identifier rather than a count, which is the second guard under a mask that can terminate early on a bracket a URL carries itself. Every count the mask left is then summed, rather than each being paired with markup beside it, since which side of a count that markup sits on and whether the severity carries any is presentation rather than structure: a bold split, a bare prose split, and a reference-style link each read as one severity under a paired reading. Summing overstates and never understates, which is the direction chosen deliberately, and its named cost is that a line stating a total and then its context, `12 findings across 4 files`, sums to sixteen. A shortfall overstated prints a block a reader checks against the body and blocks no merge, where one suppressed closes the gate on findings nobody answered. `overview=T/M` reports that total beside the number of review threads the round actually opened, `?` for `T` where no total is found in the overview preamble or a count-first open-findings section, since a total absent and a total of zero are different readings. A `?` covers a round stating no total, a round stating one only after its first collapsed section in anything but the open-findings section described below, and a round stating one as a bullet, that last blocking at exit 43 as an unvetted metadata label. None of them says the round withheld nothing. `M` comes from the API rather than the review's prose: that format enumerates the findings it opened threads for, and the anchor each entry links is the database id of that thread's own comment, so the threads are the same set already structured. Reading the enumeration instead took six attempts and four of them cancelled a shortfall by counting something that was not an entry, which needs a Markdown parser to tell apart rather than a line scan. A total larger than the thread count is findings raised where polling threads cannot see them, and a `FINDINGS WITH NO THREAD` block follows naming the shortfall. A count-first open section supplying the total is one exception, as the next paragraph says. Open entries standing for an earlier round's threads are the other, as stated below. A thread past the hundred `reviewThreads` reads would count in `M` too, so a cut page overstates the shortfall and `threads=` carries the trailing `+` that says so. The total counts what is still open, not only what the round raised. So a round can state findings an earlier round raised and left open. An open entry whose title links an earlier round's thread, and which links none the round opened, is counted beside `M` first. Where a block still prints, it names how many it counted that way. A carried finding no entry links still reads as a shortfall. Confirm that one against the body rather than acting on the number. The field is present only where the round covering the head is written in that format, and it is head-scoped where `suppressed=` is not, because a total is one round's statement about one diff and the push that changes that diff raises a round stating its own, where a suppressed block carries the finding text an answer is still owed to.
 
 One reader, `read_overview`, reads every section of that format's overview. Each section it added arrived as a spelling nothing read, and each stopped the loop at exit `43` in turn. The `OVERVIEW_SECTIONS` table in the script names each collapsible section that lists thread links, with its role. The open-findings section states the later revision's total, since that revision writes the bare zero line only for a zero. So where the preamble states no total, that section's count is `T`. `Open (N)` is not read as a total, since it listed an earlier round's thread in 2 of the 41 rounds measured. Each open-section entry links the database id of its thread's first comment. An entry linking no thread on the pull request is a finding named only in the body. `FINDINGS WITH NO THREAD` counts it whatever the totals say. It also counts each entry an `Open (N)` section counts beyond those it lists with a link. A linked entry is a bullet at the section's margin carrying a link this reader recognizes. A bullet inside any block collapsed within the section is not one. Any other entry counts here too. Where the open-findings section supplied `T`, the block is measured against its entries rather than against `M`. So an entry linking an earlier round's thread is no finding without one. A finding that section's count names and no entry links is still counted. A resolved section's entries link threads an earlier round raised, so they are read as information rather than findings.