2 Commits

Author	SHA1	Message	Date
admin	1d59353df4	provider questions: arm them against the Storage Box / Storage Share conflation (operator-found) ... The operator noticed the "can I restore specific files from within a backup?" FAQ lives under storage-share, not storage-box, and asked which product it covers. It is Storage SHARE only — a managed Nextcloud — and it never mentions Storage Box. Its own text gives it away: Nextcloud's data cache, a database dump, the konsoleH web interface. The two products document OPPOSITE answers: Storage BOX (ours) "You can download individual files or entire directories as usual" Storage SHARE (not) "we only support restores for the full backup ZFS snapshot" That matters because a web search for the obvious phrasing surfaces the SHARE page and it reads like a definitive NO — so a support agent could answer Question 1 from the wrong page and push R-95 to the top of the register for no reason. Question 1 now names the product, quotes the Storage Box line, and states up front that we know what the Share FAQ says. A warning block at the head of the file tells the reader to check which product any full-snapshot-only answer is about before acting on it. Verified by grep: nothing in this repository ever leaned on the Share claim. The only vendor line cited anywhere is the Storage Box one. R-436 strengthened from the same source the operator supplied: the rclone-over-SSH restic backend is OFFICIALLY DOCUMENTED, not merely advertised in a shell banner -- "we support the restic backend, which is provided by Rclone over SSH". And the same page settles that the docs cannot answer the caveat: neither its Rclone nor its Restic section mentions append-only at all, so nobody need re-read the documentation hoping for it. Unlooked-for corroboration: that page's port-23 command table matches, item for item, the help output measured live on our own sub-account. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LB8FmJaGd2cyjvy6dbEjpM	2026-09-01 18:59:37 +02:00
admin	db38f4c800	hub v0.111.1: the alarm stops promising a rescue that does not exist, and the arc is closed for beta ... R-434 CLOSED — and the row's own "blocked on R-433" verdict was wrong, which is the point. The fix is a DELETION, not a replacement: withdraw the promise instead of swapping it for a new one, and the sentence is true under every possible answer to the provider questions, so it never needs a second rewrite. A replacement would have been blocked; a withdrawal is not. was: "...still hold the older copy, so this is recoverable file-by-file; it is NOT confirmed data loss. Check whether a deletion ran on the box before restoring." now: "...still hold the older copy. The route back out of them is not yet established, so treat this as neither confirmed data loss nor confirmed recovery. Get in touch before restoring anything, and check whether a deletion ran on the box." It must not swing the other way either: "your backups are gone" is still usually false. Clause (a) — the box cannot WRITE into the snapshot area — stands and is re-confirmed. Tests: offsite_r434_test.go, three, all driving the production path so they assert the sentence an operator RECEIVES. ASCII-only fragments, positive and negative controls. RED-PROOF: restoring the v0.111.0 sentence failed all three, on every fragment, with the offending sentence printed. TestR431_FiresOnAMassDeletion asserted "NOT confirmed data loss" and caught this fix correctly; its wording fragment is REMOVED rather than updated, so the wording keeps ONE home. R-435 written into the detector's own documentation, no threshold changed: it sees a mass deletion, not one app being wiped (69 across 9 apps -> ~35 needed, one tag is ~9, and forget --prune groups by host,tags). Says explicitly not to lower the numbers. THE STOPPING LINE, in all three places — register, 07 section 8 head, STATUS.md. Deferred set ENUMERATED, not described: 07 section 8 rows 4, 8, 9, 10, 11 (+11b), 12, each tagged [BETA-DEFERRED]. A number in the brief was wrong and is corrected in place: six rows are DEFERRED, ELEVEN carry a blank RTO (4,5,8,9,10,11,11b,12,13,14,15); the other five are blank for reasons that are not deferred work, and row 15 is an open DEFECT (R-104) that the stopping line does NOT cover. NO STATUS MOVED — nothing was proven today. Two provider questions drafted, not sent, no API called (11-D stands): documentation/runbooks/provider-questions-2026-09-01.md, linked from R-95 and R-433, and tracked by a dated DUE-CHECKS row (2026-09-15) — the 2026-07-27 check that sat unconfirmed for 36 days is the scar that block exists for. R-95, R-433 BLOCKED-ON-PROVIDER. R-95's one-day demotion on a clause that did not hold is recorded; the proposal to rank it back near the top is stated and NOT acted on. R-430 marked LATENT with its trigger: it becomes live the moment delete is withdrawn, so it is a precondition on the R-95 build, not a follow-up. The stale ranking paragraph ("armed", "zero snapshots") is corrected in place, order unchanged. Register 621 -> 688 lines; 181 rows throughout; open-state 170 -> 169. No controller or agent change. No golden owed, no floor change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LB8FmJaGd2cyjvy6dbEjpM	2026-09-01 18:34:52 +02:00