R-225/R-227/R-228 Parts 2-4: unknown is not zero, the gateway speaks Hungarian, the set-aside is visible
R-225 — an unread store said '0 pillanatkép / 0 / 50 GB' above a card stating it held backups under another key. An SFTP listing found snapshot f3d9cd67 and 12 535 KB really there; snapshot_count and repo_size_bytes were simply ABSENT and the zero value spoke for them. StatsKnown is now NAMED, for the same reason OffsiteInventory.Empty is: zero is what an unread store and an empty one both look like, and on the wire 'absent' and '0' are the same bytes. The fill bar renders only when the fill is known — a 0%-wide bar is a picture of emptiness, and a picture is a claim. A measured zero still says zero. R-227 — WHICH LAYER ANSWERS: traefik, and this repo generates its config. But traefik v3 serves no static files, so a branded proxy page needs a new always-up container for every 502 on the box — out of proportion, and scoped in the report rather than built. Shipped instead: the unlock posts via fetch and answers a gateway failure in Hungarian without leaving the page. Progressive enhancement — with no JS the plain POST is unchanged and still shows the proxy's error, which the report says plainly rather than implying otherwise. R-228 — the set-aside history was recorded in orphaned_renamed_to and read by nobody: a census found zero references in any template or handler, while 12 535 KB sat at that path. It is surfaced as two facts and stops. It does NOT promise the history can be reopened, because it cannot be by anyone today (R-199's inventory is unbuilt) — and the set-aside CONFIRMATION copy was corrected for the same reason: 'a helyreállítási kód nélkül többé nem lesznek megnyithatók' implied that WITH the code they could be. The field's own comment called it 'recovery-code-recoverable', which was the same over-promise in the code. Tests: scenarios F, G, H as render tests per branch of each gate. Red-proofs, each demonstrated failing then restored: remove the StatsKnown guards (F, 'R-225 RETURNED: an unread store reports a snapshot COUNT of zero'), delete the set-aside block (H). The F assertion on the fill bar is scoped to the bar's own container — a bare width:0% search matched unrelated elements and would have passed for the wrong reason. 28 packages ok, vet clean, all controller gates OK (the emoji gate caught a warning sign in a template comment).
This commit is contained in:
@@ -225,6 +225,22 @@ type OffboxTarget struct {
|
||||
// gate's input (last-known value; a failed stats call keeps the previous one — stale-but-safe).
|
||||
RepoSizeBytes int64 `json:"repo_size_bytes,omitempty"`
|
||||
SnapshotCount int `json:"snapshot_count,omitempty"`
|
||||
// StatsKnown — R-225. Whether SnapshotCount / RepoSizeBytes above were ever actually READ from the
|
||||
// repository, as opposed to never having been measured.
|
||||
//
|
||||
// ⚠ IT IS NAMED RATHER THAN INFERRED FROM THE COUNTS, for the same reason `OffsiteInventory.Empty`
|
||||
// is: **zero is what an unread store and a genuinely empty one both look like**, and the two are
|
||||
// opposite news. Both fields are `omitempty` ints, so on the wire and on disk "absent" and "0" are
|
||||
// the same bytes — the distinction cannot be recovered downstream and has to be carried.
|
||||
//
|
||||
// Measured live on 2026-08-05 (CAMPAIGN-11, R-225): after a rebuild the box rendered
|
||||
// „Tároló méret · 0 pillanatkép" and „Tárhelykeret: 0 / 50 GB (0%)" — directly above a card saying
|
||||
// the store held backups made under another key. An SFTP listing found snapshot `f3d9cd67` and
|
||||
// 12 535 KB really there. The keys were simply ABSENT from settings.json and the zero value spoke
|
||||
// for them.
|
||||
//
|
||||
// Set true by the run that reads the stats, whatever it reads — a true zero is knowledge too.
|
||||
StatsKnown bool `json:"stats_known,omitempty"`
|
||||
// LastWarning is a customer-visible notice set on an otherwise-OK run when SOME toggled apps had
|
||||
// no discoverable recovery unit (partial run). Empty on a fully-successful or failed run.
|
||||
LastWarning string `json:"last_warning,omitempty"`
|
||||
@@ -262,7 +278,19 @@ type OffboxTarget struct {
|
||||
// OrphanedAt is the RFC3339 stamp of the orphan detection (drives the card copy).
|
||||
OrphanedAt string `json:"orphaned_at,omitempty"`
|
||||
// OrphanedRenamedTo records the move-aside path of the last reset (e.g. <repo>.orphaned-20260717),
|
||||
// so the card/log can name where the old (recovery-code-recoverable) history was set aside.
|
||||
// so the card/log can name where the old history was set aside.
|
||||
//
|
||||
// ⚠ R-228 (2026-08-06) — THIS WAS WRITTEN AND READ BY NOBODY, and this comment used to call the
|
||||
// set-aside history "recovery-code-recoverable", which is **not true today**: serving a superseded
|
||||
// blob is an unbuilt link (R-199's inventory), so the old store cannot be opened by the customer,
|
||||
// the operator, or anyone else. Measured on 2026-08-05 (CAMPAIGN-11 F7): after a customer chose to
|
||||
// set their old backups aside, 12 535 KB sat at this exact path and `/backups/remote` mentioned it
|
||||
// nowhere — a census found zero references to this field in any template or handler. The screen
|
||||
// promised the data was kept and then showed nothing.
|
||||
//
|
||||
// It is surfaced now, as a plain statement that an earlier history is KEPT and NOT DELETED. It must
|
||||
// NOT promise the history can be reopened — that is the R-202 lesson, and a conditional promise
|
||||
// that turns out false is worse on this surface than saying less.
|
||||
OrphanedRenamedTo string `json:"orphaned_renamed_to,omitempty"`
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user