Close verified incident task and finish local workplan loose ends
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e3c3-621b-7350-9f77-50a8d3ee7657
This commit is contained in:
codex 2026-09-27 19:04:54 +02:00
parent 5781d34b3b
commit debf981097
22 changed files with 1210 additions and 62 deletions

View file

@ -61,13 +61,12 @@ CronJob status timestamps only. It fails when a newer scheduled run has not
succeeded within an hour, and it goes stale after 36h. The tokens lapse after
7 days without renewal.
The following remain missing until a native value-safe adapter and acceptance
exist: validated isolated restore receipts,
OpenBao snapshot/restore proof, and offsite upload/restore receipts. Missing
adapters are not inferred healthy from pod readiness. The local producer is
not the Q2 standard; railiance-telemetry has no implemented receiving contract
in the reviewed checkout. Integration, routing and scheduled delivery remain
T04, and no notification was sent during implementation.
Current gaps include accepted platform-pg/platform-pg-2 and OpenBao isolated
restore samples, fresh OpenBao snapshots, and dated full-archive receipts.
Missing evidence is not inferred healthy from pod readiness. RTEL-WP-0002
implements the Q2 reference contract and local delivery tests; its T04 still
owns production mapping, recipient and controlled failure/absence acceptance.
Integration, routing and scheduled delivery remain T04 here.
## Service records and evidence inventory
@ -87,7 +86,7 @@ provider invalidation/replacement recovery for the shared offsite lane.
| OpenBao snapshot | WARDEN-WP-0027 preparation receipt, 2026-08-23 | Snapshot/encrypted off-host preparation, not isolated restore |
| OpenBao restore | Existing `openbao-validate-restore-evidence.sh` and package procedure | Example receipt cannot pass as a fresh execution |
| Recovery exercise | RPF-WP-0015-T02/T03 | Separate windows, synthetic driver/quorum and abort operator required |
| Logical/Forgejo offsite | activity-core backup definitions, existing helper/runbooks | No new upload/restore performed; RPF-WP-0029 remains open |
| Logical/Forgejo offsite | activity-core backup definitions, existing helper/runbooks | WP-0029 is finished; WP-0038 retains recurring primary/secondary activation |
## Admission and disclosure drift
@ -134,8 +133,26 @@ Decryption now retains `platform.forgejo-primary-decryption.v1` and its own
operation times; older decryption receipts used the transfer schema through an
overwrite bug. The restore tool explicitly accepts both forms, with verified
hash/decryption flags. Existing historical receipts are unchanged. These producer
fixes enable future dated archive evidence; automatic archive adapters, fresh
end-to-end receipts and recurring execution are still pending.
fixes enable dated archive evidence. The full primary archive adapter is now
implemented; fresh end-to-end receipts and recurring execution remain pending.
For `offsite.upload`, add a reviewed entry with `signal`, `path` and `sha256`
to the recovery index. It must name a full-profile Scaleway archive transfer
with completed multipart upload, version-pinned GET, matching byte counts/hash,
the application-archive destination and ordered timezone-aware timestamps.
For `offsite.restore`, the entry additionally names `decryption` and `transfer`,
each with `path` and `sha256`. The restore must attest database import, application
health, repository verification, all package blobs and successful scratch cleanup.
The receipt hashes, ciphertext identity, destination, profile and operation order
must match across all three receipts. Only the distinct decryption schema is
accepted for automatic assurance. Essentials and Nextcloud-only proofs cannot
substitute for this primary full-application recovery signal. Other supported
services still need their own evidence; one Forgejo receipt does not close T03.
No historical index entry was added: the September 6 archive receipts lack
operation timestamps. They remain manual evidence. Tests use synthetic receipt
chains and prove expiry, provenance rejection and rejection of the real undated
receipt; those fixtures do not assert a new live recovery.
The OpenBao snapshot adapter also accepts the reviewed, hash-pinned receipt in
`reviews/`. It requires the expected source cluster identity, encrypted off-host