b1a4f0619269b4c813036fc592c97471de310515
braney
  Sun Sep 20 17:53:28 2026 -0700
registry: hold every v504 ticket, including the ones a unit test is wrong for

The table held only the tickets that want a unit test, 37 of the release's 66.
That cannot answer "how much of v504 is tested", because the 29 it left out are
indistinguishable from tickets nobody has looked at: both are absent.

So all 66 are here now, and the 29 carry a new why, "page" -- what changed is
what a page says or does, so the docent suite is the right test and no unit test
is wanted.  Each says what changed and where the fix is, so the claim is
checkable rather than asserted; "this one does not need a unit test" was a
judgement living in one head, and now it is a row somebody can argue with.

A page row may not name a unit test, which check enforces.  `needed` leaves them
out, since they are not waiting for anything.  `unwatched` does not: a ticket
with no test of any kind is worth seeing whichever kind it should have had, and
that list is 19 now rather than 4 -- the four blocked ones plus fifteen that
nothing watches and nobody had recorded.

refs #38391

diff --git src/utils/testRegistry/README src/utils/testRegistry/README
index e9c6b6013b4..961c881fdd2 100644
--- src/utils/testRegistry/README
+++ src/utils/testRegistry/README
@@ -29,32 +29,41 @@
               array, freeing memory through the wrong handler, a session path
               that stops being accepted: the page looks the same either way, so
               a browser test cannot tell whether the bug is back.  A unit test is
               the only test there can be.
 
   perf        the fix is about speed or memory, and the danger is backsliding:
               the slow path comes back in a later edit and nothing goes red.
               Measure work done -- queries, passes over the data, allocations,
               bytes of cache -- and never wall-clock seconds, because a test that
               times a loop goes red on a busy machine and then gets deleted.
 
   library     the fix is in library code that a browser reaches only through a
               page, where a dozen other things can go wrong first and produce the
               same red.
 
-A ticket whose fix only changes what a page says is not in the table at all.
-That is the docent suite's job, refs #38252.
+  page        the opposite claim: what changed is what a page says or does, so a
+              docent script is the right test and no unit test is wanted.  The
+              row still exists, because "this one does not need a unit test" is a
+              judgement somebody should be able to read and argue with.  It names
+              what changed and where the fix is, so the claim is checkable.
+
+A ticket whose fix only changes what a page says IS in the table, with why=page
+and no unit test.  It was not, at first, and that was a mistake: a table holding
+only the tickets that want a unit test cannot answer "how much of the release is
+tested", because the tickets it leaves out are indistinguishable from the ones
+nobody has looked at.  All 66 v504 tickets are here.
 
 The docent column names that suite's script for the same ticket, or "-".  Many
 tickets have both, and should: a docent script watches the page and a unit test
 watches the thing the page cannot show.  What the column is really for is
 `unwatched`, the tickets with neither, where nothing anywhere would go red if the
 bug came back.
 
 `check` verifies both values, which matters more than it sounds.  A named script
 has to exist and has to belong to that ticket.  A "-" has to still be true: if
 somebody writes rm<ticket>.docent.yaml later, the check fails and asks for the
 row to be updated.  Without that second half the "-" rows would be the one thing
 in this file nothing verified, and `unwatched` is built entirely out of them, so
 a ticket could sit on that queue long after it had left it.
 
 The rule is about the change, not about where the file lives.  A wording fix that