shoney.arickathil
5521d21a84
- developer directive: pending iteration IDs now ARE the priority order; LANDED iterations keep historical numbers (code comments and commit history cite them — records, not a queue); 8/11 (the half-landed arc), 17 (parked, artifacts on a branch), 18 (next, artifacts named) also frozen - mapping (recorded in 00-story): 19<-20 Float+Bytes, 20<-9c attach, 21<-9d keypair, 22<-9e benchmarks, 23<-9f io_uring WAL, 24<-19 chat, 25<-10 services, 26<-12 blue-green, 27<-9g query corpus, 28<-14 skillhost, 29<-13 metaprogramming - 11 story files renamed; every doc reference re-numbered (word-boundary sweep for the lettered 9x ids, phrase-level for numeric ones); the iterations table rewritten with Seq == priority and "(was N)" notes; story-scoped link check: zero broken - merge-recovery folded in: the partial master merge had dropped the chat story, the fibers exploration note, the arc spec+plan, the framework-v2 plan, and the iteration-17 spec+plan — all restored from their branches and renumbered consistently Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3 KiB
3 KiB
Iteration 26 — blue-green in-runtime deployment
Format:
product/story-iteration-template. Part of Story — one language, one runtime, one database, one binary.
Goals
- The story's closing promise: the running binary updates its own code. Two fixed VM slots (activity alternating); a proposal pipeline — propose → approve → in-runtime compile → additive schema migration → load → health → atomic switch — with the previous version staying resident as the instant rollback target.
- The developer drives it remotely:
wo remote pull / propose / diff / approve / rollback / statusover a loopback management transport, every stage streaming live and WAL-audited.
Acceptance Criteria
- What to achieve?
- Given a running fixture app and an additive code+schema change,
- when the developer proposes and approves it,
- then the deploy completes with zero dropped requests (in-flight work — including parked fibers — drains on the old slot through iteration 11's unwind path), and the binary's embedded source trailer matches the new active version afterward.
- What to achieve?
- Given a failure at any pipeline stage (compile diagnostic, destructive-change rejection, load failure, health failure, drain timeout),
- when it occurs,
- then the active slot keeps serving untouched, the failure is visible in the SSE stream and the WAL trail, and a destructive change was rejected at propose time naming the offending declaration.
- What to achieve?
- Given a completed deploy,
- when
wo remote rollbackruns, - then the previous version serves again in under one second with no compile and no data change — additive-only migration guarantees old code runs correctly against the migrated schema.
- What to achieve?
- Given kill -9 during COMPILING / MIGRATING / SWITCHING / trailer-rewrite,
- when the unit restarts,
- then it serves one consistent version and the WAL shows whole migrations only.
Out Of Scope
- Script-based/destructive migrations, in-runtime editing workspace, MCP/agent wrapper over the management plane — all recorded follow-ups.
- New scheduler work — fibers landed in iteration 11; this iteration's drain unwinds parked fibers through 11's shutdown path, it does not extend it.
Info
- Approved spec:
docs/superpowers/specs/2026-08-03-blue-green-vm-design.md; its implementation plan is deliberately authored only after iterations 9–10 ship (prerequisites: a catalog to diff, HTTP machinery to build on). - VMs own code; the engine owns data — the separation that makes the switch cheap and rollback unconditional.
Proposed Solution
- Author the implementation plan from the approved spec once iterations
9–10 land, then execute it (slots, deploy state machine, additive
differ, management surface + SSE,
wo remoteverbs, crash battery).