# PHASE 2: the off-site restore CANNOT be performed on this box - and two independent
# instruments agree on why. 2026-09-17T00:26Z

## What the brief asked for
"restore one DB-backed app from off-site onto scratch 9202."

## Instrument 1 - restic itself, using the box's own credentials, READ ONLY
  repository  sftp:u629488-sub4@u629488-sub4.your-storagebox.de:/home/felhom-repo  (port 23)
  credentials the box's own ssh_key, known_hosts and repo_password, exactly as the product uses them
  result      Fatal: wrong password or no key found
  exit status 1   (restic's OWN status, captured to a file first - see the slip below)

## Instrument 2 - the product's own status surface, which is what a customer would see
  GET /backup/offbox/status ->
    {"last_duration":"1m45s","last_error":"","last_run":"2026-09-16T21:09:00Z",
     "orphaned":true, ... ,"repo_size_human":"","snapshots":0,"status":"error"}

The two agree: the repository is ORPHANED and holds ZERO snapshots this box can read.
There is nothing to restore from, so the step cannot be performed. This is a fact about the
fixture, not a failure of the product.

## WHY the repository is orphaned, and why that is CORRECT behaviour
This box is a REBUILD for an existing customer. On a rebuild the restic repository password is
minted fresh, so the snapshots already sitting in the remote store were written under a password
that no longer exists. The product did not hide this: `offbox_repo_orphaned` fired as a true alarm
in round 1 at 21:09 and was counted as true in the truth table. It is a known and documented shape.

## THE ONE THING IN THAT JSON WORTH A SECOND LOOK
`"status":"error"` sits beside `"last_error":""`, with `last_run` set and a 1m45s duration.
That is this project's "a timestamp records an ATTEMPT, not a RESULT" shape. A run that produced
ZERO snapshots still recorded a last_run and an empty error string. Whether that misleads anyone
depends entirely on whether a customer-facing surface renders last_run without consulting status -
which is being checked separately. It is NOT filed as a defect on the JSON alone.

## MY TENTH INSTRUMENT SLIP, and it is the oldest trap in this project
My first probe printed:
    Fatal: option sftp.args is not known
    --- exit status above: 0 ---
The zero was the exit status of `head` at the end of my pipeline, not restic's. A reassuring 0
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.
