From 0bc0bc5da0b463c9d1f524aef49f106b9e26e783 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Mon, 19 Oct 2026 05:41:34 +0200 Subject: [PATCH] CONTEXT + REPORT: v0.160.0 released, on the three test hosts, not vouched --- CONTEXT.md | 6 ++++++ REPORT.md | 51 ++++++++++++++------------------------------------- 2 files changed, 20 insertions(+), 37 deletions(-) diff --git a/CONTEXT.md b/CONTEXT.md index b895892..2da38f0 100644 --- a/CONTEXT.md +++ b/CONTEXT.md @@ -1,5 +1,11 @@ # CONTEXT — felhom-agent working state +> **2026-10-19 — v0.160.0 RELEASED (operator yes), NOT VOUCHED; on demo-hp, Tester 1, demo-felhom.** R-1093, R-978, +> R-973 (below) plus R-1149 (the local tier prunes `keep-daily=N`, `BackupTier.PruneSpec`) and R-1151 (a claim with +> `{"defer_upload": true}` keeps the package until `POST /escrow/ceremony/confirm` brings the two words at the drawn +> positions; only those two words are held, 30-min window; a claim without it keeps the R-978 order). Vouch: version +> 0.160.0, sha256 `7ebb547f…dfca1`, bundle `6b060901…e202f`. After it, unreleased: `4545819` (two texts). felhom.eu +> `REPORT-day-2026-10-19.md`. > **2026-10-18 (night) — UNRELEASED on main: R-1093, R-978, R-973** (release + vouch: the operator's). R-1093 an empty > partition is blank (lsblk's PTTYPE on a partition is the parent's; set aside only on a clean blkid exit 0 with a > matching `PART_ENTRY_SCHEME`; an unparsable lsblk is unprobed). R-978 the escrow package reaches the hub only at the diff --git a/REPORT.md b/REPORT.md index 11c38b5..336c894 100644 --- a/REPORT.md +++ b/REPORT.md @@ -1,40 +1,17 @@ -# REPORT — three agent fixes, committed and NOT released (2026-10-18 evening) +# REPORT — agent v0.160.0 (2026-10-19, day brief) -Task: the evening brief of 2026-10-18, Part 4 (felhom.eu `REPORT-evening-2026-10-18.md`). Baseline: `27bbdaa` (v0.159.2 -released). Commits: `f7b7308` + `0963bae` (R-1093), `8561dc8` (R-978), `f17e197` (R-973). CHANGELOG under „Unreleased"; -the release and its vouch are the operator's. Gates green per commit (`go build/vet/test ./...`, `agent_gates.py --fast`); -CI job 2062 success for `f17e197`. +**Released on the operator's yes and running on demo-hp, Tester 1 and demo-felhom; NOT vouched** (the operator's act): +version 0.160.0, sha256 `7ebb547f2b1ab93544ba828d3040351b60c4126327a5b85bbcb33f8f2b3dfca1`, config bundle +`6b06090190ff609af1fe9842447ebf385fd52da4be382bc7ca708b558c8e202f`. -## R-1093 — an empty partition is blank +- R-978 (an abandoned second ceremony keeps the first code), R-973 (the whole-guest cadence cap), R-1093 (an empty + partition is blank), **R-1149** (the local tier keeps one copy per day: `keep-daily=N`, operator D17), **R-1151** (the new + package reaches the hub only at `POST /escrow/ceremony/confirm` with two typed words; an old controller keeps the claim + order). +- Proven on demo-hp: a normal whole-guest backup green and counted by the cap; the escrow confirm and abandon cases through + the wizard's own calls (code 1 opens the hub's package; an abandoned code 2 opens nothing); an empty partition formatted + through the real route with no confirmation (a RAM disk), and the confirmation asked once it held ext4 (the control). +- After the release, unreleased: `4545819` — two stale texts (no behaviour change). -lsblk reports the PARENT disk's PTTYPE for a partition. `InspectDevice` now ignores that PTTYPE only when `blkid -p` on the -partition exited 0, printed `PART_ENTRY_NUMBER`, and its `PART_ENTRY_SCHEME` equals lsblk's PTTYPE. Every error path -stays data-bearing: blkid exit 2 / I/O error / missing binary keep „device has a partition table"; an lsblk answer that -exits 0 but does not parse or names no device is „could not be reliably inspected" (an older fail-open, closed here after -a background security review flagged the probe). No new sudo command, no config bundle. -Test `TestInspect_R1093_PartitionVerdicts` (14 rows); three red-proofs. **Live on demo-hp** (a 1 GB loop file in `/root`, -removed after; felhom.eu `audits/agent-fixes-2026-10-18/r1093-loop-check.txt`): the empty GPT partition → lsblk -`pttype "gpt"` (the bug's input), blkid rc 0 with only `PART_ENTRY_*` (the fix's condition holds); ext4 → `TYPE=ext4`; a -dos table inside the partition → `PTTYPE=dos`. Not walked: the whole `/api/storage/init` call (the agent refuses loop -devices; it needs a VM with a spare disk running a build of this commit). - -## R-978 — the new escrow package reaches the hub only at the claim - -A ceremony started again no longer replaces the hub's package at create time. The package travels with the pending -ceremony and is uploaded when the code is claimed, before the code is handed out; an upload failure is 502 and the code -stays claimable; a ceremony abandoned by TTL, a new start or a restart leaves the first code opening the hub's package. -Ceremony output is version 2 (`PendingUpload`); the sudo argv is unchanged. Tests `TestEscrowCeremony_R978_*` and three -`cmd` tests; four red-proofs. **Residual (filed):** the typed-back check is the browser's, so a household that opens the -new code and closes the page without writing it down has still replaced the package. - -## R-973 — a cadence cap on `POST /backup` - -Per guest and tier, successful runs only: the daily (local) tier at most **3 per rolling 24 h** (the night run, one -„Mentés most", the next night — `07` §6; since R-899 a press never costs the night); the longer tier at most one per -max(cadence − 24 h, cadence / 2) = **6 days** for the weekly off-site tier. A refusal is 429 with the next allowed time, -WARN-logged, kept in `backup-success-state.json` (survives a restart), and for 24 h the host report carries the CRITICAL -degraded status `localapi:backup-cadence-cap` (the hub's operator-only `agent_capability_degraded`). Tests `TestBackupCap_*` -and others; three red-proofs. **Limits (filed):** keep-last 3 lets three local points be replaced within one day; the -off-site namespace's keep-last 2 is a count — a time-bucketed prune on ep0 is the operator's. - -*Decided by CC unattended — operator may reverse:* the numbers 3 / 24 h and 6 days, and counting successes only. +Tests and red-proofs: `CHANGELOG.md` v0.160.0. Evidence: felhom.eu `documentation/audits/day-2026-10-19/P1/`. Full report: +felhom.eu `REPORT-day-2026-10-19.md`.