Five open issues say a workflow is red; that workflow is green on master today

[gHashTag]

An open issue is a claim with a date on it. This repository holds 477 of them and
268 carry a number in the title -- a stated measurement of the tree, taken once.
Nothing re-reads them.

One subset can be re-measured exactly, because its truth is defined outside the
repository: an issue whose title says a named workflow is red. GitHub records what that
workflow last concluded on master.

New tri issues stale does that walk:

  open issues read        477
  workflow files          49
  titles claiming red     9
  of those, every named workflow is green today   5
  attributed from the body, not the title         4

issue	title (truncated)	named workflow, on master today
#2851	Seal Coverage has been red on master since #2841	seal-coverage success
#2754	secret-scan and cli-tri are red on master	cli-tri success, secret-scan success
#2729	cli-tri has been red on master for three days	cli-tri success
#2278	emit-bitexact is red on master and nothing was watching	emit-bitexact-gate success
#2263	master's tri test suite is red, and two gates cannot see it	cli-tri success, emit-bitexact-gate success

Still correctly red, and left alone: #2915 (brain-seal-refresh failure),
#2914 (coq-proofs failure), #2783, #2292.

What this does NOT say

It does not say any of the five is resolved, and the command never suggests closing
one. #2729 is the example that makes the distinction concrete. Its title is stale --
cli-tri is green. Its deeper argument is not: the workflow still carries

    paths:
      - 'cli/**'
      - 'Cargo.toml'
      - 'Cargo.lock'
      - '.github/workflows/cli-tri.yml'

so a change outside those paths that breaks tri still would not trigger it -- which is
the sentence the issue was actually about, and is the same shape as #2903.

What a green reading says is narrower and still worth having: the sentence at the top
of that issue is no longer true, so a reader who stops at the title is misled about
the state of the tree. With 477 open issues, most readers stop at the title.

The recall bug this was built around

Issues name a workflow the way GitHub displays it, not by file. seal-coverage.yml
displays as Seal Coverage, and a reader keyed on the file stem cannot see #2851 at all.
Measured on this tree: 22 of 49 workflows display under a name that differs from
their stem, and adding that key moved the population from 8 to 9 -- the one it added
being #2851, which is also the one I already knew about and would otherwise have reported
as absent.

The command matches on all three keys (file, stem, display name) with a boundary that
treats - and _ as word characters, so cli-tri does not match inside cli-tri-mcp.
Both properties are tests.

Not measured

The other 259 open issues carrying a number in their title. Their claims are about
counts in the tree rather than workflow conclusions, and extracting the measurement from
free text is the precision problem that killed a superlative-claim detector last pass
(2 real hits in 6). This command deliberately covers only the subset whose truth GitHub
already stores.

[gHashTag]

Correction to this issue's own population, one pass later

This issue opens with "477 open issues and 268 with a number in the title". The 268
is wrong, and wrong in both directions at once. Re-measured with tri issues numbers
(PR #2986):

  open issues read              478
  count in digits only          128
  count in words only            98
  both                           57
  POPULATION                    283
  quantifier only, excluded      20
  no figure                     175

145 of the 329 loose hits were ADDRESSES. #2841, Wave Loop 369, Prop. 65,
w699, CI-01 identify a thing and measure nothing — 44% of what a two-digit-run
matcher calls the population, every one with nothing to re-read.

98 issues state their figure only in WORDS. "Twelve quantified clauses call a
function with the wrong number of arguments" is re-measurable and invisible to a digit
matcher.

The two errors partly cancel, 268 against 283, which is the worst case: a number that is
nearly right survives review.

What does NOT change: everything below the first paragraph. The nine titles claiming a
workflow is red, the five naming one that is green today, and the display-name recall bug
were measured separately and are unaffected — tri issues stale reads titles for a
redness claim, not for a number.

A second correction worth recording: my first Rust reader gave 295 where an
independent Python reader gave 283 on the same backlog. Twelve in Rust, zero in
Python — a strict superset, which is the signature of a missing boundary rather than a
missing case. The digit scan had no word boundary and fired inside identifiers (t27,
GF16, dlc10, SRL16E, 0o777, 2'b11). With the boundary both agree at 283.