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>
70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
---
|
|
iteration: "9"
|
|
status: done
|
|
readiness: ready
|
|
---
|
|
|
|
# Iteration 9 — database engine
|
|
|
|
> Format: `product/story-iteration-template`. Part of
|
|
> [Story — one language, one runtime, one database, one binary](00-story.md).
|
|
|
|
## Goals
|
|
|
|
- The language's oldest promise executes on the new runtime: every class is
|
|
a table. `insert` and `select` stop trapping (`DB_STUB` retires) and run
|
|
against class-shaped row storage inside the VM's shards.
|
|
- Data survives anything: a typed write-ahead log with ack-after-fsync,
|
|
parallel boot replay, and a crash battery proving no committed row is
|
|
ever lost and no half-applied transaction ever visible.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- What to achieve?
|
|
- **Given** a class annotated `@table` and a method inserting rows,
|
|
- **when** the method runs,
|
|
- **then** the insert is WAL-logged before acknowledgment, visible to
|
|
subsequent `select`, and the pricing fixture that previously trapped
|
|
`DB_STUB` now passes with real data.
|
|
- What to achieve?
|
|
- **Given** kill -9 at arbitrary points during committed writes,
|
|
- **when** the process reboots and replays,
|
|
- **then** every acknowledged commit is present, no unacknowledged
|
|
partial write is visible, and replay across shards completes without
|
|
manual steps.
|
|
- What to achieve?
|
|
- **Given** a `@unique` field and a duplicate insert,
|
|
- **when** it executes,
|
|
- **then** the insert traps with the unique-violation code and
|
|
secondary indexes remain consistent (maintained only through the
|
|
engine's row choke points).
|
|
|
|
## Out Of Scope
|
|
|
|
- Cypher/document query paradigms and `LIVE` subscriptions (the query
|
|
layer's later phases; `prototypes/wo-db` stays the reference).
|
|
- Cross-shard 2PC transactions; Postgres mirroring (exists on the Rust
|
|
side; ports after parity).
|
|
|
|
## Info
|
|
|
|
- Doctrine: RAM is authoritative; the WAL makes it durable; indexes drift
|
|
unless writes go through the row API — the Rust runtime learned this
|
|
lesson, the C engine enforces it.
|
|
- The wo-db overlap manifest keeps the C++ prototype and this engine
|
|
answer-compatible where features overlap.
|
|
- **Ownership/GC analysis (2026-08-15):** the engine and the VM heap are two
|
|
memory worlds crossed only by copy — rows store no VM pointers, GC-managed
|
|
values in stored fields are a compile error, and everything a query returns
|
|
is copied out — so the collector never traces rows and the engine never
|
|
counts references. The full analysis (row views as borrows without a
|
|
runtime net, cursor stability, GC-pause interaction) lives in the 9b
|
|
design's section 6:
|
|
[`2026-08-15-table-relations-query-design.md`](../../superpowers/specs/2026-08-15-table-relations-query-design.md).
|
|
|
|
## Proposed Solution
|
|
|
|
- Execute the existing plan: `docs/superpowers/plans/2026-08-01-db-engine-binding.md`
|
|
(class-shaped row slabs with a choke-point row API, typed WAL + parallel
|
|
replay + crash battery, insert execution, doctrine-enforced indexes +
|
|
`@unique` trap, select subset, db corpus).
|