Project: frostyard/snosi — a bootc/mkosi-based immutable Debian Trixie OS image build system. Pull request: frostyard/snosi#409 — Secure native A/B deployment path (Phases 0–8), alongside bootc.
A single autonomous Claude Code run took a design plan for a secure native A/B disk-image deployment path (mkosi EROFS/dm-verity roots + systemd-sysupdate + Secure Boot + TPM-unlocked LUKS) — adding cayo-ab / snow-ab / snowfield-ab native products alongside snosi's existing bootc path — executed it across 9 phases, validated every phase in QEMU, and opened a reviewed pull request, running mostly overnight without a human driving each step.
Work was structured as subagent-driven development: a controller agent decomposed the plan into work units, dispatched a fresh implementer subagent per unit, then an adversarial reviewer subagent (spec compliance + code quality) per unit, looping fix→re-review until clean, with a final whole-branch review before the PR.
Stats below are measured from git and the run artifacts. The total-tool-calls figure is a reasoned estimate (subagent resumes double-report counts); every other number is exact.
| Metric | Value |
|---|---|
| Branch | feat/mkosi-ab-root |
Commits (branch vs main) |
41 |
| Files changed | 179 |
| Lines added / deleted | +22,837 / −256 |
| Test code added | +9,839 (≈43% of the diff — tests ≈ product code) |
| Docs added | +5,712 markdown lines |
| Shell scripts / chroots authored | 37 new |
| New mkosi config fragments | 37 |
| Systemd units authored | 8 service + 3 timer + 3 path + 1 preset |
| sysupdate transfer definitions | 9 |
| Largest single file | a 1,698-line Secure Boot QEMU test harness |
Commit types: feat 14 · fix 14 · test 5 · docs 4 · refactor 2 · merges 2.
The 14 fix commits are the review-and-validation loop working — mostly real bugs caught before
merge, not typos.
- Plan authored → PR opened: ~30 hours wall clock.
- Pure execution (first phase commit → PR): ~29 hours, commits landing across 23 distinct clock-hours including continuous overnight progress.
| Metric | Value |
|---|---|
| QEMU validation runs | ~30 (0 Incus needed — OVMF MOK varstore injection + swtpm made the full Secure Boot chain scriptable) |
| Peak proof: desktop full update window | 125/125 assertions — install, N→N+3, rollback, 3-try boot-count fallback, all under enforced Secure Boot with unattended TPM unlock |
| Installer end-to-end proof | 75/75 — ISO boot on a virgin Secure Boot varstore → signed encrypted install → MOK-enrolled unattended boot |
| Real product bugs caught by QEMU | ~12 |
| e2e debug iterations, each a named root cause | 9 |
Examples of bugs QEMU caught that static review would not have: a first-boot unit that would have created a passwordless-sudo user on every real install; kernel lockdown silently never engaging on one kernel variant despite enforced Secure Boot; a udev race in the production update stager's post-stage verification.
| Metric | Value |
|---|---|
| Phases executed | 9 |
| Discrete work units dispatched | 41 (each an isolated brief + report) |
| Adversarial review cycles | 28 |
| Subagents spawned | ~45 (implementers, reviewers, fixers, one large-model whole-branch review) |
| Est. total tool calls | ~5,000+ (heavy implementers ran 100–2,100 calls each) |
Every phase passed a two-verdict review (spec + quality), and the whole branch got a final large-model review before the PR — no Critical findings survived to the pull request. On a change where a mistake bricks a machine's boot or silently drops fleet updates, the 14 fix commits and 12 QEMU-caught bugs are the point: the review/validation overhead bought correctness a single-pass implementation wouldn't have. Tests came out roughly 1:1 with product code, and nothing was published to a container registry or blob store — the two actions that would have been hard to walk back were deliberately left as human gates.
Generated with Claude Code.