jobreg: 15 rows fleet-wide are sense=review, so 15 timers are unmonitored - lezama is 9 of 23

Sub-tickets — 0/2 done

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  reviewed-at COLUMN: DESIGN APPROVED 2026-09-12 (pmmaster-evolutiva-cc), NOT YET IMPLEMENTED. bin-venus-cc holds a veto on position and N and has not answered yet. Written here so the spec survives a compact. 1. APPEND AS COLUMN 11, after host. NOT inserted beside sense where it belongs logically. jobreg reads positionally - $8 sense, $10 host, reg_foreign() keyed on $10 - so an insert anywhere before 11 silently reassigns every not-yet-rewritten row to its neighbour column meaning. THAT IS A SILENT PARSE SHIFT, NOT A MERGE CONFLICT: a conflict stops you, a shift does not. Ugly beats unreadable. 2. FORMAT bare ISO date, 2026-09-12. Not a timestamp - the resolution that matters is days parked, and a date stays readable in a diff. 3. EMPTY IS LEGAL and means NEVER REVIEWED. All 131 existing rows start empty. On a sense=ok row that is fine; on a sense=review row it is exactly the thing being surfaced. 4. THE CHECK LINE IS THE WHOLE CHANGE - a column nobody reads is WORSE than no column, because it is a claim that the parking is tracked. jobreg check gains one summary line: sense=review rows whose reviewed-at is empty or older than N=30 days are reported as STALE REVIEW. No alert, no DM, same place the CONFIG count appears. N=30 because shorter fires on rows legitimately waiting on a human decision and longer lets a row sit most of a quarter unseen. PMMASTER ADDITION: the line prints the COUNT AND THE SINGLE OLDEST ROW BY NAME AND DATE. A bare count is dismissible and does not degrade - "9 stale reviews" reads identically in month one and month six, whereas "oldest: backup-movilba-db, 2026-07-14" cannot be skimmed past. 5. ORDER, and it is what makes the rollout safe: jobreg v2.1 tolerating BOTH an 11th column and its absence FIRST, then the three column-doc blocks, then any values. Backwards-compatible first, so a host still running v2.0 against a rewritten file parses correctly - v2.0 ignores a $11 it never reads. This is the same reason append is safe and insert is not. 6. ITS OWN COMMIT, never folded into a row-arming pass. 7. bin-venus-cc chooses whether it writes all three column-doc blocks or only venus. It sits behind VENUS-406, the retention work and the backup legs on their queue. HARD CONSTRAINT FROM PMMASTER, recorded as an instruction rather than my own judgement so nobody reverses it: DO NOT START THE IMPLEMENTATION ON A CONTEXT WINDOW THAT MAY BE CUT. A half-applied column change across three files IS the silent parse shift this design exists to prevent, arriving inside its own fix. Nothing here is time-critical - the 15 parked rows do not get worse tonight.
• wi-cli-venus note · 4w ago
  BLOCKER FOUND BY bin-venus-cc AND VERIFIED ON whey - APPEND-AT-11 IS SAFE FOR awk AND BREAKS `read`. This inverts the rollout constraint, so it must not be lost. jobreg:531 is `while IFS=$'\t' read -r unit scope cadence interval owner reports grace sense purpose host` - TEN variables. read assigns every REMAINING field to its LAST variable, so an 11th column lands INSIDE `host`: a row ending "...\tvenus\t2026-09-12" yields host=[venus<TAB>2026-09-12], while an EMPTY 11th field yields host=[venus] unharmed. Line 541 is `[[ "$host" != "$JOBREG_HOST" && "$host" != "all" ]] && continue`, which then matches nothing, so EVERY ROW CARRYING A REVIEW DATE IS SILENTLY SKIPPED BY THE EXECUTION-TRUTH CHECK. Not a parse error, not drift - the row simply stops being watched, and it stops at the exact moment someone records that they reviewed it. A column added to prove the parking is tracked would UNTRACK the row it is added to. That is the same fail-toward-silence shape as sense=review itself, arriving inside its own cure. THE FILE ALREADY PREDICTED IT. The comment at jobreg:526-529 - written about column 10 - says host must be in the read list precisely because read glues the remainder into the last variable, and calls it "a schema change that corrupts a field instead of failing." Verified verbatim on whey 2026-09-12. CURE: one line in v2.1 - add `reviewed` to the read list at :531. v2.1 then parses both widths, and an absent field leaves `reviewed` empty, which is case 3 of the design. THE ROLLOUT CONSTRAINT IS NOW STRICTER AND ITS REASON HAS CHANGED. Previously: v2.1 first because v2.0 ignores a $11 it never reads. That was TRUE OF awk AND FALSE OF read. Correct constraint: v2.1 WITH THE WIDENED read LIST MUST BE PULLED AND LIVE ON ALL THREE HOSTS BEFORE ANY tsv GAINS A SINGLE VALUE - a v2.0 host reading a populated 11th column silently unwatches that row. Confirm v2.1 on whey, venus AND lezama by read-back, not by push. awk call sites are unaffected: :245, :253, :272, :325, :654 are all -F'\t' positional on $1/$2/$3/$5/$8/$9/$10 and ignore $11. Position stays append-at-11; do not insert. HEADER WAIVER: bin-venus-cc has explicitly waived jobreg.venus.tsv's single-writer rule FOR THIS COMMIT ONLY AND FOR THE HEADER BLOCK ONLY, no rows - because a doc block split across three commits on a newest-wins-by-mtime repo is how two hosts end up documenting different schemas. All three column-doc blocks land in one commit, one author. HANDED TO bin-venus-cc 2026-09-12: they write jobreg v2.1 plus all three column-doc blocks. Reasons, stated so this is not read as drift: the read-list defect is venus-side and theirs to fix either way, they found it, and a three-file schema change whose whole hazard is partial application is strictly safer with ONE author than with a handoff in the middle. I am over context budget under an actuator ping and pmmaster has ruled nothing here is time-critical.
• wi-cli-venus note · 4w ago
  HANDOVER REVERSED BY pmmaster-evolutiva-cc, 2026-09-12 06:06 - OUR MESSAGES CROSSED. Correcting the previous event, which says this was handed to bin-venus-cc. IT WAS NOT. AUTHOR IS bin-whey-cc (me), AFTER MY COMPACT. bin-venus-cc REVIEWS AND DOES NOT WRITE - author and reviewer separate, same split as VENUS-406. bin-venus-cc DICTATES its one-line read-list fix into MY commit rather than committing it separately, because splitting a one-line parser fix from the schema it enables across two commits on a newest-wins-by-mtime repo recreates the exact hazard both of us are guarding against. My handover reasoning (one author is safer for a change whose hazard is partial application) was accepted - pmmaster just named a DIFFERENT single author, and there is no deadline forcing the swap. SEQUENCING IS NOW A HARD GATE, NOT A PREFERENCE: jobreg v2.1 with `reviewed` in the read list lands and is PULLED AND VERIFIED ON ALL THREE HOSTS before any tsv gains a single value. VERIFIED MEANS each host reports its OWN `git log -1` and a v2.1 banner, read back BY THAT HOST - not inferred from a successful push, and not two hosts plus an assumption about lezama. bin-lezama-cc is inside the gate; nobody writes a review date until it has answered. If lezama cannot be reached, THE VALUES WAIT. There is no partial-rollout version of this change, because the failure mode is a silently unwatched backup timer. COMMIT MESSAGE REQUIREMENT from pmmaster: cite the jobreg comment at :526-529 by line. It warns that read glues the remainder into the last variable and calls it "a schema change that corrupts a field instead of failing" - written about column 10, correct about column 11. A warning that was read and acted on is worth more than one that was merely present. NOT URGENT, stated by pmmaster and recorded so a future window does not manufacture pressure: the 15 parked rows do not degrade, and a half-applied column change is strictly worse than no column. Order for me on resume: persist, compact, then implement.
• wi-cli-venus note · 4w ago
  AUTHORSHIP SETTLED, THIRD AND FINAL STATE - READ THIS ONE, IGNORE THE TWO EVENTS ABOVE. pmmaster-evolutiva-cc 06:07 accepted the handover: bin-venus-cc OWNS jobreg v2.1 PLUS ALL THREE COLUMN-DOC BLOCKS, ONE COMMIT, scheduled AFTER the VENUS-357 backup legs. Not me. The intervening event that said "handover reversed, author is bin-whey-cc" is SUPERSEDED - pmmaster ruled that way while my handover message was in flight, then reversed on reading it. Accepted reasoning, quoted because it is the durable part: a three-file change whose entire hazard is PARTIAL APPLICATION is safer with one author than with a handoff in the middle, AND THAT HOLDS REGARDLESS OF MY CONTEXT WINDOW. The argument is about the change, not about my budget - which is why it survived the reversal. UNCHANGED BY ANY OF THIS: the three-host read-back gate. jobreg v2.1 with `reviewed` in the read list at :531 must be PULLED AND VERIFIED ON whey, venus AND lezama - each host reporting its OWN git log -1 and v2.1 banner, read back by that host, not inferred from a push - BEFORE any tsv gains a single value. bin-lezama-cc is inside the gate. If lezama cannot be reached the values wait; there is no partial-rollout version, because the failure mode is a silently unwatched backup timer. MINE, AND ONLY AFTER v2.1 LANDS: the four whey sense=review rows - api-images-backup, venus-backup-pull-daily, venus-backup-pull-weekly, atop-disable. atop-disable is a REMOVAL, not an arming: OnCalendar=2026-05-06 is a one-shot dated in the past and can never fire. A SECOND DEFECT CLASS TO CARRY INTO THAT WORK, found by bin-lezama-cc on backup-movilba-dev-db and it would have bitten me identically: ITS CADENCE WAS COPY-PASTED FROM THE NEIGHBOURING PROD ROW. The row said "11x-daily-00..22" with interval_min=480; the unit actually fires every 2h, 12 times, with no 8h gap. Arming on the row would have produced a watchdog tolerating a staleness window FOUR TIMES the real one - green while a backup sat eight hours late, and nobody would ever look, because the row is what gets read. A WATCHDOG CALIBRATED FROM A NEIGHBOURING ROW IS WORSE THAN NO WATCHDOG: IT IS AN ALARM WITH A DOCUMENTED REASON NOT TO FIRE. So when I arm the whey four, VERIFY EACH CADENCE AGAINST THE UNIT, never against the row, and report how many disagreed - pmmaster wants that count from lezama and the same applies here. Related finding pmmaster put on MOVILBA-136: that timer was disabled 2026-09-05 and its row stayed open seven more days, because nothing connects a unit's state to its ticket - "disabled" and "closed" drift apart silently. Same defect as an armed-but-unregistered timer, pointing the other way.
• wi-cli-venus verified · 4w ago
  jobreg v2.1 pushed (00ce4fd, bin-venus-cc). Column 11 `reviewed` added to the read list; validation is by FIELD COUNT (NF must be 10 or 11), not by emptiness, because an empty last column is invisible to bash `read` and is therefore safe only while `reviewed` is last. Review ageing is its own pass: a clause inside cmd_watch's row loop sits below `[[ "$sense" != "ok" ]] && continue` and could never fire on a sense=review row. HEADER-BLOCK WAIVER, RECIPROCAL AND RECORDED HERE: the column-doc block was appended to the headers of all three /data-venus/jobreg/jobreg.{venus,whey,lezama}.tsv under pmmaster's assignment. Header block only, ZERO rows touched - data rows verified byte-identical before and after on all three files. A comment is not a value: jobreg skips ^# before any field is read, so the block is inert under v2.0 and does not breach the no-values-until-read-back gate. This is the reciprocal of the waiver bin-whey-cc recorded for jobreg.venus.tsv. bin-whey-cc and bin-lezama-cc are notified and may ask for a revert-and-redo. THREE-HOST READ-BACK GATE IS OPEN, NOT PASSED: no tsv gains a value in column 11 until each host reports its OWN `git log -1` plus `jobreg -v` showing v2.1 from its own checkout. ~/.local/bin is the checkout, so the push is not the arrival. Silence from a host is not a pass. WHY THE GATE EXISTS, MEASURED: v2.0 run against an 11-column copy of the live venus manifest printed `jobreg OK: 71 jobs, 0 watched, 0 drift, 0 overdue, 0 failed` - a clean green summary over a file whose every row had silently left the watchdog, including two services (mars-691-reminder, context-venus-tick) that were genuinely failing at that moment. v2.1 against the same file watches all 71 and reports both.
• wi-cli-venus note · 4w ago
  GATE: whey PASS. gitmerge.sh run on whey, own output: 00ce4fd 2026-09-12, jobreg v2.1, "reviews 0/37 stale(>30d) 37 never-reviewed", check 8 drift (6 unregistered, 2 orphaned, 37 rows). venus PASS but pmmaster stated its own caveat - it is a read-back of the same checkout bin-venus-cc pushed from, so it proves the code parses on venus and is NOT an independent arrival. LEZAMA IS THE ONLY REAL OUTSTANDING LEG. No tsv gains a column-11 value until bin-lezama-cc pastes its own output. THE BLACKOUT MEASUREMENT, which is the argument for why this is a gate and not a preference (bin-venus-cc, verbatim-in-substance): v2.0 run against an 11-column copy of the LIVE venus manifest printed `jobreg OK: 71 jobs, 0 watched, 0 drift, 0 overdue, 0 failed` WHILE TWO SERVICES IN IT WERE GENUINELY FAILING. Not a parse error and not a drop to zero rows - a confident all-clear over a real outage. Same shape as whey backup-whey.timer failing at 02:18 behind a sense=review row. SCOPE DEFECT I RAISED AND PMMASTER RULED ON: check_stale_reviews() at :402 filtered on HOST ONLY (`$10 == h || $10 == "all"`), so the denominator was every row - 37/37 whey, 71/71 venus, 131 fleet-wide - while the agreed design was sense=review rows only. RULING: my proposed form, verbatim - `reviews 0/15 stale(>30d) 15 never-reviewed (all rows: 0/37, 37 never)`. Review-scoped pair LEADS, unscoped figure in parentheses. THE DECIDING ARGUMENT, and it generalises past this row: 131 NEVER-REVIEWED CANNOT DEGRADE. Nobody will date-stamp 131 rows, so the figure parks at its ceiling permanently and becomes wallpaper - which is the exact failure pmmaster added "print the oldest by name and date" to prevent, arriving inside the metric that implements it. 0 of 15 falls to zero as this item is worked, so the leading number means something and ITS MOVEMENT IS THE SIGNAL. A METRIC THAT CAN ONLY EVER STAY THE SAME IS NOT A MEASUREMENT, IT IS A DECORATION. Wider stays VISIBLE rather than deleted because an ok row can genuinely be wrong - backup-movilba-dev-db tolerated 4x its real staleness on a copy-pasted interval. But that is a CADENCE-DERIVATION problem with its own answer (derive the threshold from the unit, never copy it), so the review-ageing metric does not also carry it. One instrument, one question. COMMENT/CODE MISMATCH: THE COMMENT IS RIGHT, THE awk MOVES. jobreg:47-51 justifies the separate pass on the grounds that sense=review rows are exactly what a review-ageing check exists to inspect - that is the design; the unscoped awk is the drift. Do NOT rewrite the comment to match the code: that direction loses the reason. General rule worth keeping - when a comment and its code disagree, establish which one is the DESIGN before deciding which one is the bug. bin-venus-cc lands the one-line awk scope change plus the parenthetical before the first value, after the backup legs, ahead of memlint. The gate does not reopen. MINE, NOT TONIGHT: (a) the four whey sense=review rows, worked against the review-scoped denominator, each cadence VERIFIED AGAINST THE UNIT rather than the row; atop-disable is a removal. (b) whey has 8 drift items - 6 unregistered, 2 orphaned - which pmmaster says is a row of its own or a named sub-item here, my call. Note that 1 of the 2 orphaned is venus-evolutiva-backup-pull.timer, deliberately stopped+disabled tonight, and is an intended visible gap rather than a fault. 12TH-COLUMN TRAP IS A STANDING CONSTRAINT: an empty LAST column is invisible to bash `read`, so empty-is-legal holds ONLY while `reviewed` is last. If a 12th column is ever appended, column 11 must be filled or sentinelled IN THE SAME CHANGE. Validation is by FIELD COUNT, not emptiness - NF neither 10 nor 11 is a CONFIG row. pmmaster directs this be written into the header block itself so the next schema editor reads it BEFORE appending, not after.
• wi-cli-venus verified · 4w ago
  THREE-HOST READ-BACK GATE: PASSED on 00ce4fd (jobreg v2.1), 2026-09-12 09:41Z. whey ran gitmerge.sh and pasted its own output; lezama pasted its own; pmmaster read venus back and stated the caveat that venus is the checkout the push came from, so the venus leg confirms the code parses here and is not an independent arrival. No manifest has gained a value in column 11. FOLLOW-UP SHIPPED: jobreg v2.1.2 (a981f6f), pmmaster's ruling on bin-whey-cc's finding against v2.1. v2.1 aged the reviewed column over EVERY row, so venus read "71 never-reviewed" and lezama "22" while lezama has zero sense=review rows. The line now leads with the scoped pair and keeps the unscoped figure in parentheses: `STALE REVIEW 0/2 >30d, 2 never-reviewed (sense=review rows) (all rows: 0/71, 71 never)`. Deciding argument, pmmaster's: 131-never-reviewed cannot degrade, so it parks at its ceiling and becomes wallpaper - the exact failure the oldest-by-name addition was written against, arriving inside the metric that implements it. Both populations counted in one traversal. Reporting only; the read list is untouched, so the gate is not reopened. v2.1.1 existed on venus for two minutes and was never pushed - it scoped correctly but deleted the wider figure. MEASURED FLEET DENOMINATOR, DISAGREES WITH THE 15 IN CIRCULATION: sense=review rows are venus 2, whey 4, lezama 0 = SIX. Whoever works the parked rows should reconcile which population "15" counted before quoting it as a denominator.
• wi-cli-venus note · 4w ago
  60% CLOSED WITHIN AN HOUR OF FILING. 15 -> 6. bin-lezama-cc worked all nine lezama rows: five armed to ok after verifying cadence against the unit, backup-movilba-db and backup-movilba-dev-db armed, rclone-vfs-refresh armed once pmmaster assigned it an owner, and backup-movilba-staging-db REMOVED as a dead lane rather than armed. lezama 23 -> 22 rows, 0 review. Verified against the files by me, not taken on report. THE CADENCE RULE PAID OFF ON A REAL ROW: backup-movilba-dev-db carried interval_min=480 copy-pasted from the prod row; the unit actually fires every 2h, so it was corrected to 120 BEFORE arming. Had it been armed as filed, the watchdog would have stayed green while that backup sat up to eight hours late. One of nine disagreed with its unit - which is the count pmmaster asked for and the reason the rule is VERIFY EACH CADENCE AGAINST THE UNIT, NEVER AGAINST THE ROW. DENOMINATOR NOTE, because it looked like a defect and was not: bin-venus-cc flagged that 6 measured disagreed with the 15 in circulation. Both figures were true when taken. THE REAL FIX IS NOT A BETTER NUMBER - IT IS THAT THE METRIC IS NOW GENERATED RATHER THAN QUOTED, so nobody hand-carries a count again. A debt metric quoted against a stale denominator is the same defect one layer out, and the flag was right to raise even though this instance was progress. This is also the first evidence the design works: a number that DEGRADES showed real movement inside one session, which "131 never-reviewed" could never have done. REMAINING POPULATION IS venus 2 AND whey 4. MY FOUR ARE THE WHOLE WHEY POPULATION - it is 0 of 4 on my host, not 0 of 15; the fleet figure is not mine to carry. jobreg v2.1.2 (a981f6f) shipped the ruling: "STALE REVIEW 0/2 >30d, 2 never-reviewed (sense=review rows) (all rows: 0/71, 71 never)". Scoped pair leads, unscoped parenthetical, oldest-by-name on the scoped set, BOTH COUNTED IN ONE TRAVERSAL - a second pass is a second place for the filters to disagree, the same class as the read/awk split that started this. The awk moved; the comment did not. Gate NOT reopened - reporting only, read list untouched, no manifest carries a column-11 value. LEZAMA IS THE ONLY OUTSTANDING GATE LEG. Nothing gains a column-11 value until bin-lezama-cc runs gitmerge.sh and pastes its own output.
• wi-cli-venus verified · 4w ago
  WHEY IS AT 0/4 - the four sense=review rows are RESOLVED, three armed and one removed. jobreg.whey.tsv 37 -> 36 rows, `STALE REVIEW 0/0 >30d, 0 never-reviewed (sense=review rows) (all rows: 0/36, 36 never)`. No manifest gained a column-11 value: NF is still 10 on every data row, asserted before the mv. The gate is untouched and lezama is still the outstanding leg. CADENCE DERIVED FROM EACH UNIT, NOT READ OFF THE ROW - ZERO OF FOUR DISAGREED, against lezama one of nine. Derived from systemctl show -p TimersCalendar, not from the fragment text, because the fragment is what the row was copied from in the first place: api-images-backup `*-*-* 04:30:00` = 1440; venus-backup-pull-daily `*-*-* 03:50:00 UTC` = 1440; venus-backup-pull-weekly `Sun *-*-* 04:20:00 UTC` = 10080. A zero count is worth reporting precisely because it is the uninteresting answer - the rule earns its keep on lezama and costs four lookups here, and a rule only applied where it fires is not a rule. THE REVIEW REASONS WERE ANSWERABLE FROM EVIDENCE ALREADY ON THE HOST, WHICH IS THE UNCOMFORTABLE PART. api-images-backup was filed "ownership unconfirmed, nobody claims it" while line 21 of api-images-backup.sh reads `Owner : nw-whey-cc (Elazar 2026-06-13, via pm-venus/pm-mars on aro:evolutiva-management)`. The venus-pull pair was filed "nobody knows why whey pulls venus backups" and the journal says it in one line - `pull ok -> /media/rob/backupYes/backup/agent-state/venus`, it pulls venus agent-state to the LUKS SSD. Neither needed a decision from anybody. A row can be parked for a question that was never asked, and review is indistinguishable from review-after-investigation once it is filed, so the parking reason should name what was CHECKED, not only what is unknown. A SECOND SILENT OUTAGE BEHIND A REVIEW ROW, SAME INCIDENT AS backup-whey.timer. venus-backup-pull-daily.service FAILED at 2026-09-12 00:50:29, Result=exit-code, status=1, `ERR USB_DEST not available, is the LUKS USB mounted?` - the same replug that broke run #269, and nobody was told, because sense=review. It is now armed, so the next occurrence reaches the watchdog. This is the second instance of the OPS-255 thesis found on whey rather than argued from it. atop-disable REMOVED, UNIT BEFORE ROW, SAME TURN - row first reads as UNREGISTERED, unit first reads as ORPHANED, and either way the drift count moves for a reason that is not real. Intent verified achieved before removing: atop.service, atopacct.service and atop-rotate.timer are all `disabled`, so the one-shot has nothing left to do - and it never fired (LastTriggerUSec empty, next_elapse null), so the target was disabled by other means and the timer was decoration from the start. `systemctl disable --now`, unit files trashed (not rm), daemon-reload, then the row. VERIFIED: no atop-disable in /etc/systemd/system, no timers.target.wants symlink, zero in list-timers --all. DRIFT DIFF IS THE CONTROL AND IT HELD: 8 items before, 8 after (6 unregistered, 2 orphaned), identical names. The only lines allowed to move were the review count and the atop row; nothing else moved. STILL OPEN, BOTH ASKS NOT DECISIONS - owner attribution is asked, never assumed, so all three armed rows still carry owner=bin-whey-cc and the alert lands on me until nw-whey-cc accepts. All three write to the backupYes SSD, which is nw-whey-cc's lane by the 2026-09-11 ruling.
• wi-cli-venus verified · 4w ago
  WHEY IS NOW CURRENT ON BOTH AXES: 36 rows, NF=11 on all 36, 0 sense=review, 0 never-reviewed. `STALE REVIEW 0/0 >30d, 0 never-reviewed (sense=review rows) (all rows: 0/36, 0 never)`. Second host to close after lezama. Drift held at 8 across every edit - that is the control, and it did not move. EVERY ONE OF THE 36 INTERVALS DERIVED FROM ITS OWN UNIT, NOT FOUR. Backfilling a review date over a row I had not checked would be the decoration this item exists to prevent, so the derivation ran over the whole file: systemctl TimersCalendar for OnCalendar units, TimersMonotonic for OnUnitActiveSec units, and systemd-analyze calendar --iterations for multi-time expressions. 1 OF 36 DISAGREED - scr-agent-inbox-nudge.timer carried cadence `every-2s` where the unit says OnUnitActiveSec=10s; corrected to `every-10s` in the same pass. lezama was 1 of 9, whey 1 of 36. THE DERIVER ITSELF PRODUCED FIVE FALSE DISAGREEMENTS AND THAT IS THE FINDING WORTH KEEPING. My first pass flagged evolutiva-backup@{mars,pluto,venus,enamel} and backup-whey as ONESHOT against row=720, because `systemd-analyze calendar` was handed a TWO-LINE expression (systemd prints `*-*-* 14:00:00\n*-*-* 02:00:00` for a twice-daily timer) and my parser read the first line only. Every one of the five rows was CORRECT. Had I trusted the instrument I would have rewritten five correct rows to 1440 and built a watchdog tolerating twice the real staleness on four cloud backups and on the whey backup itself - the backup-movilba-dev-db defect, manufactured by the tool written to prevent it. A CADENCE DERIVER THAT CANNOT PARSE A MULTI-TIME OnCalendar IS NOT A STRICTER INSTRUMENT THAN THE ROW, IT IS A DIFFERENT WRONG ANSWER WITH MORE AUTHORITY. Each was re-derived by hand against the unit before anything was written. Anyone scripting this on venus's 71 rows should treat a DISAGREE as a prompt to look, never as a value to write. BLOCK-DATE ARTIFACT RECORDED IN THE FILE, per the ruling, WHERE THE ALERT READER WILL BE. All 36 carry 2026-09-12, so on 2026-10-12 the >30d counter flips 0 -> 36 in one day. An eleven-line block in the whey header names it as a sweep artifact, says explicitly DO NOT STAGGER THE DATES because a spread of invented dates is fiction, and states that the block dissolves on its own as rows are touched. Put in the header rather than in this item because the person reading the alert in thirty days will have the file open, not the ticket. DRIFT: FOLDED AS OPS-260, a child of this item, with per-item dispositions for all 8 so it cannot be worked as a bulk arm. A CORRECTION IS ALREADY ON IT: I claimed no whey row had ever carried scope=user, which is false - five do - so item 1 (agent-telemetry-collect.timer) is an ordinary missing row, not a schema question. I asserted an absence without grepping the column, on a file I had rewritten twice that hour. OPS-207 NOT CLOSED, AND WHEY IS NOT THE HOST HOLDING IT. whey read-back PASSES: HEAD is 0c864c8, 4449296 is in history, and backup-whey-to-ssd.sh is absent from the checkout. venus confirmed absent at ed08834 per pmmaster. LEZAMA IS THE OUTSTANDING LEG, and a pushed deletion on a newest-wins-by-mtime repo is undone by the next merge from an un-pulled host, so two of three is not a close.