- `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>
146 lines
4.7 KiB
Markdown
146 lines
4.7 KiB
Markdown
# Live board views (Obsidian Dataview)
|
||
|
||
Every story iteration file carries YAML frontmatter — **the frontmatter
|
||
is the source of truth**:
|
||
|
||
```yaml
|
||
---
|
||
track: porch # OMITTED on language-runtime-database stories
|
||
iteration: "8" # immutable id, LOCAL TO ITS TRACK (string: "7b", "9b" exist)
|
||
status: in-progress # done | in-progress | pending | hold — where the WORK is
|
||
readiness: ready # ready | refine — whether the DESIGN is settled
|
||
chain: 1 # concurrency-chain position, chain stories only (1–6)
|
||
---
|
||
```
|
||
|
||
**Editing `status:` IS the status change.** Story files sit flat in
|
||
`docs/stories/language-runtime-database/`; no directory encodes state, so
|
||
there is nothing to move and nothing that can disagree. This replaced the
|
||
2026-08-20/21 folder scheme on **2026-08-26** — under that scheme a status
|
||
change moved the file, which broke every relative link in and to it, and
|
||
the repo's two link audits were largely the cleanup.
|
||
|
||
**Two axes, since 2026-08-27.** They are orthogonal and conflating them is
|
||
what `refine` used to do:
|
||
|
||
- `status` — where the WORK is: `done`, `in-progress`, `pending`, `hold`.
|
||
- `readiness` — whether the DESIGN is settled: `ready` means the brainstorm is
|
||
complete and the decisions are LOCKED (a spec is approved, or the forks were
|
||
confirmed); `refine` means open forks remain and it cannot be planned yet.
|
||
|
||
`status: refine` is retired. It meant both "not started" and "design not
|
||
settled", so a held iteration with an approved spec (language 18, 26) was
|
||
indistinguishable from one nobody had thought about. Those are now
|
||
`status: hold` + `readiness: ready`, and the genuinely unthought ones are
|
||
`readiness: refine`. A value outside either closed set simply will not appear
|
||
in the lanes below, which is the cheapest possible validation.
|
||
|
||
**The useful query is `readiness: ready` + `status: pending`** — design locked,
|
||
work not started. That is the startable set. The prose board ([`00-status.md`](00-status.md)) stays the
|
||
standup narrative; these queries are the live views over the same facts.
|
||
|
||
Adjust the `FROM` path to your vault root (queries below assume the
|
||
vault opens at the repo root).
|
||
|
||
Three tracks now carry iterations, each numbered from 1:
|
||
`language-runtime-database/` (the language and runtime), `porch/` (the web
|
||
framework) and `databasev2/` (the database beyond RAM) — the latter two added
|
||
2026-08-26. Iteration ids therefore repeat across tracks, so every query below is
|
||
scoped by `FROM` path; non-language stories carry `track:`, and iterations moved
|
||
between tracks keep `was_language_iteration:` so the old number stays
|
||
searchable.
|
||
|
||
## Everything not done, chain order first
|
||
|
||
```dataview
|
||
TABLE iteration, status, chain
|
||
FROM "docs/stories/language-runtime-database"
|
||
WHERE status != "done"
|
||
SORT chain ASC, iteration ASC
|
||
```
|
||
|
||
## Grouped by status (the kanban lanes, as data)
|
||
|
||
```dataview
|
||
TABLE rows.file.link AS story, rows.iteration AS iteration
|
||
FROM "docs/stories/language-runtime-database"
|
||
WHERE status != "done"
|
||
GROUP BY status
|
||
```
|
||
|
||
## The concurrency chain, in execution order
|
||
|
||
```dataview
|
||
TABLE iteration, status
|
||
FROM "docs/stories/language-runtime-database"
|
||
WHERE chain
|
||
SORT chain ASC
|
||
```
|
||
|
||
## Active right now
|
||
|
||
```dataview
|
||
LIST
|
||
FROM "docs/stories/language-runtime-database"
|
||
WHERE status = "in-progress"
|
||
```
|
||
|
||
## Kanban caveat
|
||
|
||
The Kanban plugin stores board state in its own markdown file — a
|
||
second copy of status. To keep frontmatter the single source of truth:
|
||
**use Dataview for querying; treat any Kanban board as a VIEW, never
|
||
the place status is edited.** A status change is one edit to one
|
||
`status:` key; a Kanban card drag that only rewrites the Kanban file is a
|
||
lie the next query won't see.
|
||
|
||
## The databasev2 track
|
||
|
||
```dataview
|
||
TABLE iteration, status, was_language_iteration AS "was"
|
||
FROM "docs/stories/databasev2"
|
||
WHERE status != "done"
|
||
SORT iteration ASC
|
||
```
|
||
|
||
## The porch track
|
||
|
||
```dataview
|
||
TABLE iteration, status
|
||
FROM "docs/stories/porch"
|
||
WHERE status != "done"
|
||
SORT iteration ASC
|
||
```
|
||
|
||
## Both tracks at once, grouped
|
||
|
||
Relies on `track:` being present on porch stories and absent on language ones,
|
||
so the language track shows up under an empty group.
|
||
|
||
```dataview
|
||
TABLE rows.file.link AS story, rows.iteration AS iteration, rows.status AS status
|
||
FROM "docs/stories"
|
||
WHERE iteration AND status != "done"
|
||
GROUP BY track
|
||
```
|
||
|
||
## Startable: design locked, work not started
|
||
|
||
The set to pick from. Anything here has its decisions made and needs no
|
||
brainstorm.
|
||
|
||
```dataview
|
||
TABLE track, iteration
|
||
FROM "docs/stories"
|
||
WHERE readiness = "ready" AND status = "pending"
|
||
SORT track ASC, iteration ASC
|
||
```
|
||
|
||
## Needs a brainstorm before it can be planned
|
||
|
||
```dataview
|
||
TABLE track, iteration, status
|
||
FROM "docs/stories"
|
||
WHERE readiness = "refine"
|
||
SORT track ASC, iteration ASC
|
||
```
|