venus-db-backup.sh: prune glob spans plaintext+encrypted lanes, sharing one KEEP budget
venus-db-backup.sh prune() glob 'venus-prod-*.sql.gz*' matches BOTH the legacy plaintext .sql.gz lane (dead lane, stopped 2026-06-16) and the current encrypted .sql.gz.gpg lane, so a single KEEP=84 budget is shared across two naming conventions. Measured 2026-08-07: dest ~/gdrive/backup/venus held exactly 84 files = 74 .gpg + 10 legacy plaintext, so effective ENCRYPTED retention is 74 (~6.2 days at 12 runs/day), not the 84/7-days the constant documents. Second, live consequence: because ls -1t is newest-first, the 10 oldest plaintext files occupied prune positions 75-84 and were being destroyed at 1 per run - all 10 gone by ~2026-08-08 04:00 UTC. Those artifacts are VENUS-350 evidence AND the last unencrypted clinical copies on a consumer cloud mount; nobody decided to delete them, a glob did. Evidence preserved 2026-08-07 08:32 UTC under pmmaster-evolutiva-cc authorization (msiorxd2q1mh) to ~/.local/state/venus-350-evidence/ (AES256, round-trip verified byte-identical, wrong-passphrase must-fail fixture passed) - that is preservation, NOT the fix. FIX: scope the glob per lane so each retention budget counts only its own artifacts, and make KEEP mean what the comment claims. Blocked while venus-db-backup.sh is evidence in the live P0; see mem:owned-scripts.
Activity
-
Blocked by live P0 VENUS-350: venus-db-backup.sh is evidence. bin-venus-cc's standing position, agreed on-channel - the script is not edited while it is under measurement. Unblock when coder-venus-cc/Elazar release the file.
-
RELEASED by pmmaster-evolutiva-cc under Elazar's delegated GO (announce aro:evolutiva-management 2026-09-11 09:22). The blocker was 'venus-db-backup.sh is evidence in the live P0 VENUS-350' and that premise expired today: db-venus-cc closed VENUS-350's attribution question by measurement (vault.secrets +242 == auth.sessions +242 == venus-db-backup.service journal 242 Finished over the identical window; residual on vault ZERO). The file is no longer under measurement, so it is no longer evidence. Fix both 358 and 359 in one push as bin-venus-cc planned. 359 outranks: it is live unrecoverable data loss.
-
FIXED in venus-db-backup.sh v1.6, sh.git 36624b6, same push as VENUS-359. prune() now calls prune_lane() three times with independent budgets instead of one glob over everything: 'venus-prod-*.sql.gz.gpg' at KEEP, 'venus-prod-*.sql.gz' at KEEP, and 'venus-prod-*.part' at 0. KEEP now means what its comment claims for the encrypted lane. THE SEPARATION NEEDS NO FILTER and that is why this is clean rather than clever: '*.sql.gz' cannot match '*.sql.gz.gpg' because '.gz' has to be terminal - the old glob only conflated them because of its own trailing '*'. Asserted directly in the fixture (test 6) rather than assumed, since the entire fix rests on it. A THIRD LANE THE TICKET DID NOT NAME: the old glob's trailing '*' also matched orphaned '.part' files, so dropping to two lanes would have silently retired that cleanup - a regression hidden inside a fix. They get their own lane at keep=0, which is safe because prune runs LAST: this run's own .part has already been renamed into place or discarded by the publish block, so anything still carrying .part is residue from an earlier crashed run. It gets the same trash-or-refuse treatment as a real artifact, because a .part is still a partial copy of clinical data, not scratch. CURRENT STATE MEASURED BEFORE THE CHANGE: the destination holds 84 .gpg and ZERO plaintext - the ten legacy files this ticket was filed to save are already gone, destroyed by the glob at one per run exactly as predicted on 2026-08-07. They survive only in the authorized evidence copy under ~/.local/state/venus-350-evidence/. So this fix prevents a recurrence and restores the documented retention; it does not recover anything, and the ticket's own prediction of the loss is now confirmed rather than averted.