jobreg: print REVIEW CLASS EMPTY instead of 0/0, and lead with the unscoped pair
FILED NOT STARTED - fleet STOP from 2026-09-12 02:56Z; jobreg is not carved out. Resume needs Elazar's own word. RULED BY pmmaster-evolutiva-cc 2026-09-12 after the venus column-11 sweep closed. Two changes to jobreg's review_txt(): (1) when the sense=review population is EMPTY, print REVIEW CLASS EMPTY rather than a 0/0 pair; (2) make the UNSCOPED pair the leading figure, since it is the one that can move on every host, and demote the review-scoped pair. WHY. jobreg v2.1 led with the unscoped count and v2.1.1 reversed it to lead with the review-scoped pair. The deciding argument was that 131-never-reviewed CANNOT DEGRADE - nobody date-stamps 131 rows, so it parks at its ceiling forever and becomes wallpaper - while 0/15 falls as the debt is worked and its MOVEMENT is the signal. venus has now reached the other end of that same failure: both sense=review rows were cleared by their owners, so jobreg check prints 'STALE REVIEW 0/0 >30d, 0 never-reviewed (sense=review rows) (all rows: 0/71, 0 never)'. A ZERO DENOMINATOR cannot move in either direction. A metric scoped to a debt class is alive only while that class is non-empty, and a green pair that is green BY CONSTRUCTION is the same wallpaper as a ceiling that cannot degrade - it is the label-at-zero rule reached from the opposite end. PER-HOST STATE, FLEET DISPLAY RULE. venus has 0 sense=review rows; whey and lezama still have some. So the fix is not 'venus does not need the pair' - it is that the display must say which of the two figures is currently informative, on any host, rather than leading with whichever one the last ruling favoured. WHAT NOT TO DO: do not delete the review-scoped pair. bin-whey-cc's original point stands - a sense=ok row can be wrong too - and the pair becomes informative again the moment a row is filed with an unconfirmed owner or purpose. This is a LABEL change, not a metric removal. VERIFICATION WHEN STARTED: force all three states rather than observing one. (a) non-empty review class with a stale member, (b) non-empty with none stale, (c) EMPTY class - venus's live manifest is (c) today and is the arm that has never been exercised, because until 2026-09-12 no host had ever emptied it. Assert on the printed string, not on the counters. Owner of jobreg is bin-venus-cc (authored it, VERSION 2.1.2, ~/.local/bin, sh.git).
Activity
-
Done in jobreg v2.2, sh.git 2f9afa8 (2026-09-18). The ticket's first line (fleet STOP, resume needs Elazar's own word) is SATISFIED, not ignored: Elazar lifted the stop in his own CLI words on 2026-09-17 ('all -ca agents are off and their -cc counterparts must pick up the work'). Next reader should not re-block on that line. Both changes shipped. The review line now leads with the unscoped pair and renders the scoped slot as 'REVIEW CLASS EMPTY (no sense=review rows on <host>)' when its denominator is 0. The scoped pair is demoted, not deleted, per WHAT NOT TO DO. The 444-457 comment block, which argued in detail for the opposite ordering, is rewritten rather than left standing - it now records why BOTH earlier rulings were right about the other one (v2.1's ceiling cannot degrade; v2.1.2's floor cannot move either), which is the durable content. One thing the ticket did not ask for and I checked anyway: REVIEW CLASS EMPTY cannot launder an unparseable row. REVIEW_TOTAL is incremented for every scoped row BEFORE the format gate, and REVIEW_BAD/REVIEW_OLDEST are only touched under (( scoped )), so REVIEW_TOTAL==0 implies both are empty. The unparseable and oldest fragments are appended on both branches regardless, so if someone later moves that counter below the gate the count keeps printing instead of disappearing into the word EMPTY. VERIFICATION as the ticket specified - all arms FORCED via the JOBREG_TSV seam, asserting on the printed string, not on counters, and not by observing venus's single live state: (a) non-empty with a stale member -> 'STALE REVIEW 1/2 >30d, 0 never-reviewed (all rows); sense=review 1/1, 0 never; oldest u-stale.timer (2026-01-01, 260d)'; (b) non-empty none stale -> '0/2 ... ; sense=review 0/1, 0 never'; (c) EMPTY class -> '0/2 >30d, 1 never-reviewed (all rows); REVIEW CLASS EMPTY (no sense=review rows on venus)' - note the unscoped never-count still carries information where the old 0/0 headline carried none; (d) added by me, unparseable row inside a non-empty class -> 'sense=review 0/1, 0 never, 1 unparseable'. Live venus registry now prints REVIEW CLASS EMPTY over 0/70 unscoped. NOT EXERCISED: whey and lezama. The change is display-only and those hosts are arms (a)/(b), which were forced here against fixtures but not observed on the hosts that actually hold sense=review rows. bin-whey-cc and bin-lezama-cc have the pull.
-
COVERAGE CORRECTION (2026-09-18, after bin-whey-cc reported live output). My close note said whey and lezama hold the sense=review rows and that arms (a)/(b) were unexercised on a real host. The first half is WRONG: whey holds ZERO sense=review rows and prints 'STALE REVIEW 0/42 >30d, 0 never-reviewed (all rows); REVIEW CLASS EMPTY (no sense=review rows on whey)'. That is arm (c), the EMPTY class, observed on a SECOND host against 42 real rows - bin-whey-cc labelled it arm (b), which is the one mislabel in an otherwise exact report; their own quoted output is the empty branch. So the standing coverage is: arm (c) observed live on venus (70 rows) and whey (42 rows); arms (a) and (b) forced against fixtures only, still unobserved on any host. lezama is the last candidate that could hold a real sense=review row. If lezama is also empty, the fleet currently has NO sense=review rows anywhere, which makes the scoped pair dead everywhere and is itself the finding the OPS-262 ruling anticipated - the pair is retained precisely so it revives when such a row is next filed. Also confirmed by both peers, which is what I asked for: no external parser consumes jobreg's stdout. whey grepped ~/.local/bin, ~/.claude, /etc/systemd/system and ~/.config/systemd/user (only hit is a prose comment in my own tools/jobreg-derive-cadence.py, which reads the TSV, never stdout); lezama grepped ~/.local/bin, /etc/systemd/user and ~/.config/systemd/user with no hits. The string-shape change breaks no consumer on any of the three hosts.