- `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>
3.8 KiB
3.8 KiB
| iteration | status | readiness |
|---|---|---|
| 7 | done | ready |
Iteration 7 — log-watcher proof workload
Format:
product/story-iteration-template. Part of Story — one language, one runtime, one database, one binary.
Goals
- The language's driving workload runs for real: the Haxe log-watcher
daemon (~1,200 lines) re-expressed file-for-file in
.woatdocs/examples/log-watcher/, compiled bywoc, detecting a silent death on a live file. - The README mapping table's "could not express" column is empty — the systems track's acceptance bar: nothing in a real daemon exceeded the language.
Status: ✅ landed 2026-08-15. Compile-and-run met 2026-08-14 (zero diagnostics, 106 KB standalone binary, all three modes work); the executable half landed 2026-08-15 — zero ASan leaks in all three modes, SIGTERM ends parked syscalls, fds flat across 200 requests, and the
LW_SOAKgate holds RSS/descriptors flat under sustained load.just log-watcher: 7 checks, 0 failures. The work is recorded inplan/compiler/2026-08-14-logwatcher-executable.mdand nothing else blocks this iteration.
Acceptance Criteria
- What to achieve?
- Given the eight-file
.woport (logtail, watcher, cron, probes, supervisor, mcp, tools, main), - when
woccompiles the sample and the ported fixture groups run, - then compilation is clean and every fixture mirrors its named Haxe test case with matching behavior.
- Given the eight-file
- What to achieve?
- Given the built sample running
watchagainst a growing tempfile, - when the feed ends with an error line and the quiet period elapses,
- then exactly one detection line appends to the JSONL sink — the original's measured behavior, reproduced.
- Given the built sample running
- What to achieve?
- Given the README mapping table,
- when the iteration closes,
- then every row names its
.hxsibling and deliberate divergences, and the could-not-express column is empty.
- What to achieve? (added 2026-08-14 — compiling is not running)
- Given any of the three modes started under a sanitizer build,
- when it is signalled to stop after a soak,
- then it exits cleanly on SIGTERM alone, reports zero leaks, and its resident size and descriptor count are flat across the soak.
Out Of Scope
- The sqlite-backed minilog tools — expressible when iteration 9's SQL lands; recorded as scoped-out, not inexpressible.
- New language or stdlib features: a gap found here is a defect report against iterations 5/6, and this iteration stops until it's resolved.
Info
- The
.wofiles may be authored docs-first ahead of this iteration (spec2026-08-07-logwatcher-sample-and-principles-design.md); this iteration is where they must actually compile and run. - The pure-core discipline (tail state machine, cron math, MCP
handlesocket-free and clock-injected) is preserved — the original's best design decision.
Proposed Solution
- The authoring plan (
docs/superpowers/plans/2026-08-01-log-watcher-sample.md) is spent: the.wofiles exist and compile. - What remains is
plan/compiler/2026-08-14-logwatcher-executable.md— six tasks, every one traced to a measurement on this sample: the ownership pass learning stdlib return types, dropping a projected temporary, the runtime's own argv container, honouring the stop signal in blocking calls, closing accepted connections, and a soak that would have caught all of it. just log-watcher(scripts/log-watcher-accept.sh) is this iteration's gate: compile, watch alert, cron schedule, and three MCP checks today; the soak joins it in the last task.