final walk: the soak, and the window correction stated as mine

Window 1 (22:44-01:54Z, untouched): every periodic job fired at its declared cadence — agent-channel-health 185x/1m, stack-scan 108x/2m, the 5-minute trio 44x each, hub-report 14x/15m. offsite-credential-retry ran 44 times and did no work and said nothing, which is R-218's asserted healthy-box behaviour on a box that never saw the defect. No alert, notification or digest fired; nothing on the must-not list fired. The off-site state never moved during that window — and that is NOT a finding. The daily jobs run on the controller's clock and the guest is UTC while the appliance is CEST, so the nightly local (~02:30) and off-site (~04:15) fall at 02:30Z and 04:15Z. I sized the window against CEST and it closed at 01:54Z, before either. Reporting 'the nightly did not fire' would have been a false finding produced by a badly-chosen window. Window 2 (corrective, 01:56-02:35Z) covers the 02:30Z local backup. The 04:15Z off-site nightly is deliberately NOT covered and is recorded as not run with the reason: leaving the machine at the claim screen before 07:00 is the primary deliverable, and waiting would have put the destruction at ~06:35 CEST with no margin. The off-site tier was exercised four times manually instead, including a full listing by name.
2026-08-07 03:57:18 +02:00
parent 2d2d8d3ddc
commit f873c557ca
1 changed files with 37 additions and 0 deletions
@@ -110,3 +110,40 @@ separate folder and left live data untouched).

 **T2 and T3 are the same finding as the headline**, seen from the customer's side: the fixes are
 written and pushed but not delivered, so tonight's box still exhibits both defects.
+
+---
+
+## Phase B.1 — the soak
+
+**Window 1: 22:44:05Z → 01:54:03Z (3 h 10 m), untouched.**
+
+Every periodic job fired at exactly its declared cadence, which is the positive control that the
+scheduler was running at all:
+
+| job | cadence | fired | expected in 190 min |
+|---|---|---|---|
+| `agent-channel-health` | 1 m | 185 | ~190 |
+| `stack-scan` | 2 m | 108 | ~95 |
+| `system-health` · `backup-cache` · **`offsite-credential-retry`** | 5 m | 44 each | ~38 |
+| `hub-report` | 15 m | 14 | ~13 |
+| `tier` · `fill-watch` · `db-dump` | — | 1 each | — |
+
+**`offsite-credential-retry` ran 44 times and did no work and said nothing.** That is R-218's asserted
+healthy-box behaviour — the job exists, ticks, completes in 0 s, and stays silent because the
+declaration it keys on is false. A box that had never seen the defect behaves exactly as designed.
+
+**No alert, notification or digest fired. Nothing on the must-not list fired.** The off-site state was
+unchanged throughout (`last_run` fixed at `22:38:54Z`, `snaps=1`, `12.0 MB`).
+
+> **AND THAT LAST LINE IS NOT A FINDING — IT IS MY PLANNING ERROR, STATED AS SUCH.** The daily jobs run
+> on the CONTROLLER's clock, and **the guest is UTC while the appliance is CEST** (`date +%Z`:
+> guest `UTC`, appliance `CEST`). The nightly local backup (~02:30) and off-site (~04:15) therefore
+> fall at **02:30Z and 04:15Z**, and I sized the window against CEST — so it closed at 01:54Z, before
+> either. Reporting "the nightly did not fire" as a defect would have been a false finding produced by
+> a badly-chosen window, which is precisely the shape §6.1 warns about in the other direction.
+>
+> **Window 2 (corrective): 01:56Z → ~02:35Z**, to cover the 02:30Z local backup. The 04:15Z off-site
+> nightly is deliberately **NOT** covered: finishing the walk and leaving the machine at the claim
+> screen before 07:00 is the primary deliverable (§11.1), and waiting for it would have put the
+> destruction at ~06:35 CEST with no margin. **Recorded as not run, with the reason** — the off-site
+> tier was exercised four times manually tonight instead, including a full listing by name.