The raw-buf milestone fieldtest (spec 0066) surfaced a spec_gap: the
kernel-extensions whitepaper teaches RawBuf surface syntax through its
§Series worked examples, but those examples were written before three
downstream surface decisions landed and never caught up — so an LLM
author who pattern-matches them writes programs that fail to parse.
Three drift classes, all verified against the HEAD parser:
- fn-type slots carried no mode. Post-#55 every value slot needs an
explicit `(own …)` / `(borrow …)` (the bare_slot_reject contract).
- `(new RawBuf lookback)` omitted the element type. Post-#51 the form
is `(new RawBuf (con T) <size>)`; the whitepaper's own spec line
(§"allocates") already documents `(new RawBuf (con T) (size: Int))`.
- parametrised kernel types were spelled bare `(Series a)` /
`(Series (con Float))`, contradicting the whitepaper's OWN prose
(`(con Series (con Float))` at the §mechanisms section). Wrapped in
`(con …)` to match the documented canonical form.
- `len` / `total_count` carried no `(type …)` at all; completed from
the obvious neighbour signatures (`borrow (con Series a) → own Int`).
Scope is deliberately surface-syntax only. The §Series listing stays a
forward-looking sketch of the still-pending library-extension milestone
(STATUS header; "not in today's AILang" at the sma_demo block). Its
full cross-module compile-verification remains assigned to the Series
milestone per spec 0059 — these edits do not claim it compiles today
(it leans on kernel-tier polymorphism that is not yet authorable), only
that its surface syntax now matches what RawBuf authors must actually
write.
Brummel
5e5b0e1484