runbook: publish train PARTIAL — agent 0.79.0 published (Phase B done); Phase C blocked on drill-VM launch cmd

Agent 0.79.0 published from live felhom-pve bytes (sha 35a1625476…), all
GL-1 gates green (404→201→anon-200, live-bytes sha, token-leak 0). Golden
bake (Phase C) blocked: the canonical qemu drill-VM launch command was
never saved and reconstructing it would improvise the bake (runbook-
forbidden). No publish-time signing needed (integrity root = sha; operator
signature is a runtime agent_update concern). Needs operator input to resume.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6
This commit is contained in:
2026-07-10 09:57:17 +02:00
parent c8d36b07e4
commit a848bd6a83
@@ -0,0 +1,62 @@
# RUNBOOK — publish train agent 0.79.0 + golden 0.110.0 + floor (2026-07-10) — PARTIAL (B done, C blocked)
**Class:** publish/signing runbook (GL-1 pattern). **Status:** Phase A shipped; **Phase B COMPLETE**;
**Phase C BLOCKED** on the un-captured drill-VM launch command; Phases D/E pending C + operator saves.
No credential/signature-key material in this record.
## The operator values so far (for the hub Day-0 manifest, GL-1 style)
```
AGENT_VERSION=0.79.0
AGENT_SHA256=35a162547646737ebef265f5ad69d042e897914f6ca799c007872d1c3cd27561
GOLDEN_VERSION=0.110.0 (pending Phase C bake)
GOLDEN_SHA256=<pending>
FLOOR=0.110.0 (pending Phase D)
```
## Gate outcomes
| Gate | Result | Evidence |
|---|---|---|
| A — C2 code shipped | **PASS (prior task)** | controller v0.110.0 on main + live on 9201 (`Up (healthy)`); lock self-heal + C1 unit-tested + red-proofed |
| B-0a published-state pre | **PASS** | agent 0.79.0 GET = 404, golden 0.110.0 GET = 404 (the GL-1 pre-gate) |
| B-1a live bytes | **PASS** | felhom-pve running binary = `/usr/local/bin/felhom-agent` v0.79.0, sha `35a1625476…`; selfupdate state dir empty (no pending A/B marker); sha IDENTICAL across felhom-pve→CC→180 hops |
| B-1b agent publish | **PASS** | `publish-agent.sh 0.79.0 <live-bytes>` on 180 from main@`a6e8bcb`: pre-delete 404, PUT **201**, round-trip GET sha match |
| B-3a anon fetch | **PASS** | **anonymous** GET → 200, sha256 == AGENT_SHA256 (off-LAN CC machine); hop copies removed (180 + local); token-leak grep of transcript: 0 hits |
| C-0b drill VM | **PASS** | `~/drill/drill.qcow2` on 180, internal snapshot `virgin` (2026-07-03) intact |
| C-0c controller image | **PASS** | `docker manifest inspect …/felhom-controller:0.110.0` OK on 180 |
| C-0d headroom | **PASS** | 196 G free on 180 (golden ≈ 0.6 G); virgin snapshot 0 B |
| **C-2a boot drill VM** | **BLOCKED** | the canonical `qemu-system` launch command is NOT captured anywhere (not in ~/drill, no launcher/unit/history; audits give only parameters — 4 vCPU/8 GiB/150 G qcow2, /dev/kvm, slirp `dhcpstart=10.0.2.30`, hostfwd 2222→10.0.2.15:22). Reconstructing it = improvising the bake (runbook-forbidden) + risks the virgin snapshot. **Needs the operator's launch one-liner OR explicit go-ahead to reconstruct as a recorded deviation.** |
| D — manifest + floor | **PENDING** | 🛑 two hub UI saves (needs C's golden sha) |
| E — demo self-update proof | **PENDING** | downstream of D |
## Signing note (correcting the runbook's Phase-B assumption)
`publish-agent.sh` does **NOT** sign anything — it PUTs the sha-addressed binary and prints the sha; that
matches the GL-1 precedent (its Phase B was 404→201→sha, no signing). The **operator signature is a RUNTIME
concern**, not a publish-time one: the agent self-update integrity root is the SHA256 (`selfupdate/executor.go`
— "the signed sha is the ONLY integrity root"), and the operator-signed `agent_update` job is what the hub
pushes when an operator TRIGGERS a managed agent update (GL-6 proved that round-trip against the pinned key).
So Phase B correctly required **no operator signature** — integrity for day-0 fetch comes from the
hub-manifest sha (Phase D) + anonymous fetchability (proven above). Nothing for Viktor to sign in this train
unless/until a managed agent_update is triggered.
## Blocker → what's needed to resume (Phase C onward)
To bake + publish golden 0.110.0 the drill VM must be booted, and the exact launch invocation was a manual
one-liner never saved. **Two ways forward (operator picks):**
1. Provide the `qemu-system-x86_64 …` launch command used for `~/drill/drill.qcow2` (revert-to-`virgin` +
boot with the slirp/hostfwd netdev), and CC resumes C→E autonomously.
2. Authorize CC to reconstruct it from the documented parameters (recorded as a deviation) — CC will
snapshot-revert to `virgin` first (non-destructive: `qemu-img snapshot -a virgin`), boot read-safe, and
abort if the guest doesn't come up cleanly.
Then Phases D (🛑 two UI saves) + E (demo floor self-update proof) follow, and the READY-FOR-PETI checklist
is completed.
## Follow-ups already known for the checklist (Phase E)
- Two install-form items for the Peti window (NOT this train): cores 8 vs 12/16 (confirm with Peti);
`--acl-storages` for his storage layout.
- Send Peti the retrieval passphrase out-of-band; recommend `--preflight-only` first.
- Peti hub-side provisioning is already armed (sub-account 269130, descriptor+fingerprint served, one-time
secret unconsumed) — waiting on his box to enroll + report (DIAG 2026-07-10).