jobreg per-host split: confirm v2.0 check output on venus + lezama, then delete jobreg.tsv from sh.git with a read-back on all three

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  VENUS EQUALITY CHECK: PASS, and the verdict is equality rather than absence-of-errors. bin-venus-cc, 2026-09-12, released by pmmaster-evolutiva-cc under bin-whey-cc's relayed lift from Elazar (bin agents, jobreg only). diff of old-source vs new-source output is EMPTY, rc=0, 3 lines each, rc=1 from both runs. Both runs report the same 2 drift items on venus (api-images-log-reader.timer, evolutiva-emaildrain@terra.timer), 2 unregistered / 0 orphaned, 66 rows filed for this host - matching bin-whey-cc's published venus count exactly. Zero CONFIG lines from either source, so no foreign-host rows are misfiled into the venus file. It also exercised lezama's arm on venus deliberately, because venus is the host where /data-venus is LOCAL and the cache path can never fail naturally there: JOBREG_DIR=/nonexistent returns rc=1, the same 2 drift and the same 66 rows, an EMPTY diff against the fresh run, and a summary reading REGISTRY-SOURCE-UNREACHABLE (/nonexistent) - checking against local cache 0h old. The caveat lands on the summary line and not only on the broken path, which is the property worth having: a reader seeing a summary with no caveat has actually learned something. DELETION OF jobreg.tsv IS NOT AUTHORISED BY THIS CHECK - ruling by pmmaster-evolutiva-cc, relayed to bin-whey-cc: a lift naming a ROW is not authorisation for an irreversible fleet-wide deletion, and the file comes out only on Elazar's own word naming the file. The gate is satisfied; the deletion is not. Nothing was deleted on venus. CARRIED OUT, not actioned: jobreg-registry-reconcile.sh still defaults to jobreg.tsv as of now, so the old path survives in a consumer even after the registry source moves - already flagged for its own version bump.
• wi-cli-venus verified · 4w ago
  Equality gates PASS on both hosts. venus: diff empty, rc=1 both, 2 drift (2 unregistered, 0 orphaned), 66 rows - matches published count; zero CONFIG lines, so no foreign-host rows misfiled. lezama: diff empty, rc=1 both, 5 drift (4 unregistered, 1 orphaned), 23 rows. Cache-fallback arm run on BOTH - venus ran it although /data-venus is local there, which is the one host where it could never fail naturally: identical verdicts off cache, REGISTRY-SOURCE-UNREACHABLE named on the summary line. jobreg-registry-reconcile.sh v1.7 pushed - concatenates the per-host manifests, refuses a zero-row manifest, labels a cache fallback instead of answering silently from it. Its full run and header line are UNVERIFIED on whey (zero-byte maintainer registry, run dies at the registry gate by design); bin-venus-cc owns that one command. REMAINING: delete jobreg.tsv from sh.git. HELD - pmmaster ruling, agreed: a row-scoped lift is not authorisation for an irreversible fleet-wide deletion; it needs Elazar naming the file. Asked.
• wi-cli-venus verified · 4w ago
  v1.8 CONFIRMED on venus by bin-venus-cc: full run, canonical path, no env override, cwd=/tmp - the exact away-from-own-directory case that produced the defect. Header prints all three inputs; rulings names the real path with count 1, matching the file's 1 non-comment row. readlink -f resolves the default from an arbitrary cwd, so the arm whey cannot reach (zero-byte maintainer registry, run dies at the registry gate by design) is green on venus. Venus was 2 commits behind and has now merged v1.7+v1.8, so venus is running the code, not merely verifying it - an earlier report of mine conflated those and is corrected. OPS-220 is complete except the deletion of jobreg.tsv from sh.git, which remains HELD for Elazar naming the file.