T: a user hold enforced by a number does not survive a process that rewrites numbers

The event

ab584382e (2026-08-25), "tickets: apply the approved re-triage — prio now spans 3-88":

One commit, two user rulings, neither named in its message. Nothing about the re-triage was a decision to lift either hold. Discovered independently by frankB and the coordinator on the same night, from opposite ends — [[decide-is-the-2026-07-12-esp-park-still-in-force]].

The tell worth keeping

The ESP park survived in both done/ tickets that carried it and was deleted from the one live ticket, because a re-triage re-prices open tickets and does not touch done/. Enforcement was destroyed exactly where it was load-bearing and preserved exactly where it was inert — which is why it read, six weeks later, as a fossil that had never had a mechanism, when in fact it had one and the mechanism was overwritten.

Generalised: if a rule appears to survive only in places where it cannot act, it has probably already been erased where it mattered. That is a cheap check and it is the one nobody ran.

Why this is filed anyway, with both instances closed

The ESP park expired on its own terms (owner, 2026-08-30: "ESP is not parked - that was temporary") and the NilPy hold was repaired with a NOT DISPATCHABLE marker. So nothing is currently broken and this is deliberately not urgent.

It is filed because the recording form is unchanged. The next time the owner holds something, the natural thing to write is still a prio: comment, and the next bulk re-triage will still erase it. Two instances in seven weeks is not a coincidence; it is the rate.

What would fix it

The two forms that survive a re-price already exist in the tree, because they are not prices:

• NOT DISPATCHABLE in the ticket body (what repaired the NilPy hold);
• a blocked-by: edge on a decide- ticket (what feature-dns-esp-wire-nameservers-from-lwip used, correctly, without presuming the answer).

So the work is not inventing a mechanism. It is:

1. Make the tooling refuse to silently drop one. A re-price that changes a prio: line carrying a # comment should either preserve the comment or fail loudly. Cheapest possible version, and it alone would have prevented both instances.
2. Give the ranker something to report. progress.sh check (or ready) should be able to answer "what is currently held, and by whom" — today there is no way to ask, which is why a park could be invisible for six weeks while sitting intact in a live ticket's frontmatter.
3. Say so in the docs. devdocs/progress/README.md should state that a hold goes in the body or an edge, never in a prio: comment, and why.

Item 1 is the whole value; 2 and 3 are what stop it recurring in a different shape.

Gate

Track T's own tooling gate. Plus the functional check that settles item 1: re-price a ticket whose prio: line carries a comment and confirm the tool either keeps the comment or refuses. Re-running the two historic cases against the changed tool is the honest regression test — both are in git log.

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.