shoney.arickathil
1fe808b7a4
- `readiness: ready | refine` is a SECOND axis, orthogonal to status.
`ready` = the brainstorm is complete and the decisions are LOCKED (a spec
approved, or the forks explicitly confirmed). `refine` = open forks remain
and it cannot be planned yet
- `status: refine` RETIRED because it carried both meanings at once, so a held
iteration with an approved spec (language 18, 26) was indistinguishable from
one nobody had thought about. status is now purely where the WORK is:
done | in-progress | pending | hold — `pending` was already the board's own
rendering word, so nothing new was invented
- all 47 iterations classified from EVIDENCE in their own text, not by guess:
"the four forks are SETTLED" / "spec + plan approved" / "Approved spec:" for
ready; "Forks the spec must settle" / "no spec exists yet" for refine. Every
shipped iteration is ready by definition. 19 done, 5 in-progress, 15
pending, 8 hold; 27 ready, 20 refine
- two iterations moved refine -> in-progress rather than -> pending: language
31 and 34 are absorbed into 24 and work on them is literally happening, which
the board already showed as 🔄 while their frontmatter said otherwise. That
disagreement is now gone
- board legend, board-views' frontmatter contract, and two new Dataview
queries updated — the useful one being `readiness: ready AND status:
pending`, the startable set
WHAT THE NEW AXIS IMMEDIATELY SURFACED: of 15 pending iterations, exactly ONE
is startable — databasev2 4, io_uring group-commit, whose forks were confirmed
settled 2026-08-20. Everything else pending needs a brainstorm first. That was
invisible while one key carried both meanings, and it is now on the board.
Also caught by the sweep, unrelated to readiness but found by cross-checking
frontmatter against the board: SIX duplicate rows. Every iteration moved into
databasev2 was still listed in the LANGUAGE pending table under its retired id
(23, 32, 33, 20, 21, 27) as well as its new one. Stale copies removed. And two
databasev2 rows made claims the sweep contradicts — iteration 1 was billed
"startable today" while its forks are open, and 6 still called itself the
ceiling-raiser after 2 took that role.
Docs only. linkcheck 0 broken / 0 anchors.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
74 lines
3 KiB
Markdown
74 lines
3 KiB
Markdown
---
|
||
iteration: "26"
|
||
status: hold
|
||
readiness: ready
|
||
---
|
||
|
||
# Iteration 26 — blue-green in-runtime deployment
|
||
|
||
> Format: `product/story-iteration-template`. Part of
|
||
> [Story — one language, one runtime, one database, one binary](00-story.md).
|
||
|
||
## 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 / status` over 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 rollback` runs,
|
||
- **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 remote` verbs, crash battery).
|