chaos night: a defect NOT filed, a worthless probe named, and the catalog verified clean

The defect I almost filed: I suspected the household is never told the off-site repository is orphaned, because 'elarvult' appears zero times in 60 KB of HTML and my search was sound (negative control 0, two positive controls finding real Hungarian text). Wrong measurement. The page's script fetches /backup/offbox/status and the page carries offbox-orphan-card, orphan-reveal, orphan-confirm and a triangle-alert icon. The household IS told, in a card rendered client-side. Nothing filed - caught BEFORE the row existed, unlike R-550. The worthless probe: my attempt to read a verify state out of the ep0 manifest returned nothing, and so did its negative control. With a compressed blob, 'no match' and 'unreadable' are indistinguishable, and I had no positive control. So the verify state is UNKNOWN, not absent, and the only claim that stands is that the copies are present and well-formed. The catalog: verified reverted rather than remembered - clean tree, level with origin, original redis pin and catalog_since intact, newest commit 2026-09-15. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-17 02:30:29 +02:00
parent 7c8a299cd1
commit 62f6b7b0b0
3 changed files with 40 additions and 0 deletions
@@ -39,3 +39,14 @@ repository on the Storage Box, which is orphaned and holds zero readable snapsho
 had a working off-site path for the WHOLE GUEST and a broken one for PER-APP restores, at the same
 time. Any sentence that says "off-site backup works" or "off-site backup is broken" without naming
 which of the two is meant would be wrong in one direction or the other.
+
+## MY MANIFEST PROBE WAS WORTHLESS, AND ITS SILENCE MUST NOT BE READ AS AN ANSWER
+I tried to read a verify state out of index.json.blob and the client log with grep and strings.
+Both returned NOTHING - and so did my negative control. That is the whole problem: with a
+compressed blob, "no match" and "unreadable" look identical, and I had no POSITIVE control that
+would have to appear if the probe worked at all. A probe that cannot fail visibly is not a
+measurement, which is the same lesson as the empty-needle grep, the wrong-directory listing and the
+invented hostname earlier tonight.
+So the verify state of these snapshots is UNKNOWN, not absent. The only claim that stands is the one
+already written above: the copies are PRESENT and well-formed, and their restorability was not
+tested this session.
@@ -40,3 +40,20 @@ The zero was the exit status of `head` at the end of my pipeline, not restic's.
 printed directly beneath a fatal error. restic 0.14.0 has `sftp.command`, not `sftp.args` -
 confirmed by asking `restic options` rather than assuming. The re-run writes restic's output to a
 file and reads `$?` immediately, so the status belongs to the command it is printed next to.
+
+## A DEFECT I ALMOST FILED, AND DID NOT - because the page does warn, in a card my probe could not see
+I suspected the household was never told the repository was orphaned: `/backups/remote` is 60 KB of
+HTML and the word "elarvult" appears ZERO times in it. My search was sound - negative control
+"zzzznope" = 0, and two positive controls proved it finds Hungarian text ("ment" 121, "voli" 29).
+It was still the wrong measurement. The page's own JavaScript does this:
+    fetch('/backup/offbox/status',{headers:{'Accept':'application/json'}})
+and the page carries the elements it fills in:
+    id="offbox-orphan-card"   id="orphan-reveal"   id="orphan-confirm"
+    id="offbox-status-value"  id="i-triangle-alert"
+with the word "orphan" appearing 4 times in the script. There is a dedicated ORPHAN CARD, revealed
+from the very status object that says orphaned:true. It is absent from the static HTML because it is
+rendered client-side - the exact case this repo's own rule warns about, and the reason there is a
+standing note that endpoint-level checking cannot prove what a browser renders.
+NOTHING IS FILED. The household IS told. This is the second time tonight I nearly filed a defect
+that was a property of my instrument; the difference from R-550 is that this one was caught BEFORE
+the row existed, by asking what the page's script does instead of trusting a grep over its HTML.
@@ -27,3 +27,15 @@ the output before the real lines were ever reached. It returned an empty marker
 like "9202 has no containers". The fix was LC_ALL=C on the remote plus filtering the warning lines,
 and not truncating before the marker. Same class as every other instrument fault tonight: a probe
 that can drop its own result silently is not a measurement.
+
+## THE CATALOG BUMP: VERIFIED REVERTED, not asserted (2026-09-17T00:29Z)
+The brief allowed one drill bump of one small app, reverted the same night.
+  working tree            clean (git status --porcelain empty)
+  local vs origin/main    94bc5fe == 94bc5fe, 0 ahead / 0 behind
+  nextcloud template      image: redis:7-alpine        <- the ORIGINAL pin, bump gone
+  .felhom.yml             catalog_since: "2026-07-18"  <- the ORIGINAL date, bump gone
+  newest commit           94bc5fe, 2026-09-15 - nothing from tonight exists in this repo
+The bump was prepared, refused by the catalog's own gates (image-resolvable INCONCLUSIVE and
+volume-persistence INCONCLUSIVE - its own canary failed, so the verdict was UNDETERMINED, never a
+pass), and reverted with `git checkout --` before any push. So there is nothing to revert now, and
+that is checked rather than remembered.