Two public surfaces answer "how big is the backlog" differently

• Type: bug (reporting consistency) — Track T (owns the report format and the dashboard generator). Routed by the coordinator, 2026-08-30.
• Found: by frankD while resolving task-d-verify-the-published-status-urls-..., and correctly reported rather than fixed — it is not Track D's call and not a defect in the docs.

The divergence

Both are defensible. factsheet.sh folds backlog_new/ into the backlog; the dashboard appears to break those out, alongside a separate "20 experimental". Neither is wrong on its own terms.

Why it is worth fixing rather than explaining

The two numbers are published, side by side in the reader's experience, with no statement of which population each counts. A reader who notices has no way to tell whether they are seeing a counting convention or a stale generator, and those have opposite implications. A reader who does not notice quotes whichever they saw.

Pick one convention, state it beside the number on both surfaces. The choice matters less than the statement.

The related finding, which is NOT this ticket

frankD's audit of the same figures found that two of ten published re-measure commands were themselves wrong, both undercounting — ls devdocs/progress/backlog/*.md misses backlog_new/ (338 against 351), and ls devdocs/progress/decided/*.md misses a resolved decision sitting in done/ (116 against 117). Both are corrected in docs/** already. Note that the same backlog_new/ blind spot produced both the wrong command and this divergence — so whoever fixes this should check for a third consumer before closing, per the double-case rule.

See face 184 in [[feature-a-a-refusal-is-a-claim-with-a-date-on-it]]: a stale number is wrong once and looks it; a wrong command is wrong on every run, agrees with itself every time, and therefore reads as verification.

Deprioritised 2026-09-02 — the Track T tooling backlog was cut as a pile

This ticket is not being called wrong. It was moved as part of a pile, not judged individually, and nothing here disputes its finding.

Owner decision. 73 of the 74 open track: T tickets were filed between 2026-08-31 and 2026-09-02, 58 on one day. The pile was too large to work through and returned almost nothing, and a ticket nobody will fix does not sit neutrally — it stays in the ranker forever at zero value, which is the argument CLAUDE.md already makes for a terminal folder over a low prio.

Four were kept in the ranker on a purely structural test — an active umbrella or a hard blocked-by: edge from live work: umbrella-one-full-tier-run-with-no-red-tier, feature-t-freebsd-image-and-runner, and the two regression-test-core-* reds that block the umbrella.

Kept, not deleted, for two reasons: so the finding is not rediscovered and refiled from scratch by the next agent who trips over it, and so it can be pulled back if what it touches becomes load-bearing.

To revive it: move it to the owning lane's backlog, set status: backlog, and say in the ticket WHAT CHANGED to make it matter now. Restoring it because it reads well is how the pile comes back.