R-193: the recovery screen — unlocking, and only unlocking (v0.200.0)

A customer whose machine was rebuilt had everything needed to get their data
back and no way to find out: the only route was a command line. This is the
screen that closes that.

IT UNLOCKS, AND ONLY UNLOCKS (operator ruling). It explains, takes the recovery
code, opens the repository and shows what is in there — apps, dates, sizes. It
restores nothing: restore is already per-app and lives in the backups area, and
a screen that unlocks and then offers to overwrite is two decisions wearing one
button.

ONE CORE, TWO CALLERS. RecoverInstallCore is split out of RecoverAndInstall; the
CLI wrapper keeps its exit codes and printed lines byte-identical, and the
handler drives the same function. Two implementations of the one operation that
can permanently lose a customer's data would drift, and only one would be
tested. Asserted from source on both sides by AST.

THREE WAYS OUT, none a dismiss button: recover; 'most nem' (the full page stops
interrupting, the backups-area entry point stays PERMANENTLY, bound to the offer
and never to the postpone flag); and 'I do not want the old data' — confirmed
TWICE and reaching the SHIPPED move-aside, which sets aside and never deletes.

THE CODE IS HANDLED NO MORE LOOSELY THAN ON THE COMMAND LINE: POST body only,
never logged, never persisted, never echoed, cleared on every path, no-store,
autocomplete off. No lockout — the code is a ten-word phrase, and locking a
customer out of their own data for a typo is worse than anything it prevents.

TWO DEFECTS THE TESTS CAUGHT, both fixed: an UNCLAIMED (legacy-open) box would
have been shown the page, because RequireAuth passes such a box through; and the
inventory nil-dereferenced when no off-site target was configured, which is
exactly the pristine rebuilt shape.
This commit is contained in:
2026-08-05 12:45:48 +02:00
parent be3c5fa7f6
commit 636c51e542
14 changed files with 1347 additions and 27 deletions
+28
View File
@@ -70,6 +70,13 @@ type Settings struct {
// first ACK — which is correct, because the hub is the authority on what the hub holds.
HubEscrowIdentityPresent bool `json:"hub_escrow_identity_present,omitempty"`
// RecoveryNoticePostponed (v0.200.0, R-193) — the customer chose "most nem" on the full-page
// recovery screen. It suppresses THE FULL-PAGE INTERRUPTION ONLY. The entry point in the backups
// area stays, permanently, for as long as the situation lasts: the data is still there whether or
// not anyone clicked, and a one-shot notice a flustered person clicks past is a notice that never
// happened. It is deliberately NOT cleared by anything except the situation ending.
RecoveryNoticePostponed bool `json:"recovery_notice_postponed,omitempty"`
// Cached state
DBValidations map[string]DBValidationCache `json:"db_validations,omitempty"`
@@ -640,6 +647,27 @@ func (s *Settings) SetHubEscrowIdentityPresent(present bool) error {
return s.save()
}
// ── Recovery screen (v0.200.0, R-193) ──────────────────────────────────────────
// GetRecoveryNoticePostponed reports whether the customer chose "most nem" on the recovery page.
// Suppresses the full-page interruption ONLY — never the backups-area entry point.
func (s *Settings) GetRecoveryNoticePostponed() bool {
s.mu.RLock()
defer s.mu.RUnlock()
return s.RecoveryNoticePostponed
}
// SetRecoveryNoticePostponed records the "most nem" choice.
func (s *Settings) SetRecoveryNoticePostponed(v bool) error {
s.mu.Lock()
defer s.mu.Unlock()
if s.RecoveryNoticePostponed == v {
return nil
}
s.RecoveryNoticePostponed = v
return s.save()
}
// ── Customer-claim arc (v0.122.0) ──────────────────────────────────────────────
// GetClaimed reports whether this box has completed a claim (set-only).