Fieldtest F4 surfaced that the shipped STUB_AIL had only the
TypeDef + ctor; the spec's prep.3 § "Worked author example" wired
a `(fn new ...)` def into the stub and immediately exercised it
via the worked consumer's `(new StubT 42)`. The implementer
dropped the def during the Task 6 sweep (spec-review let it
through). Without the def, the stub's `Term::New` end-to-end
ratification story is broken — F4 demonstrated this with a
`new-type-not-constructible` diagnostic on a verbatim
worked-consumer paste.
Re-added the def per the spec's design:
(fn new
(doc "Construct StubT<Int> from an Int. Exercises Term::New end-to-end.")
(type (fn-type (params (con Int)) (ret (con StubT (con Int)))))
(params x)
(body (term-ctor StubT Stub x)))
IR snapshots refreshed because every binary now carries the `new`
function's IR (in addition to the `drop_kernel_stub_StubT` from
the original prep.3 close). All 664 workspace tests green.
This restores coherence between the spec, the design model, and
the shipped stub. The `Term::New` invocation `(new StubT 42)` is
still codegen-deferred (per spec § Architecture, raw-buf
milestone); but at least `ail check` now passes on the spec's
worked-consumer paste.
A related and more substantive bug (F3 — kernel-tier auto-import
not registering the module as a qualifier prefix, making
`kernel_stub.StubT` consumer-unreachable) is handled separately
via the debug skill.
Brummel
171a986f82