Post-audit fieldtest for the kernel-extension-mechanics milestone.
Fieldtester wrote 6 .ail consumer programs against the public
interface only (design ledger + spec + ail CLI; no source crate
reads), one per axis with two for the param-in pair (accept +
reject). All artefacts in examples/fieldtest/ + the spec.
**Working (4):** F5 NewTypeNotConstructible diagnostic is precise
(names the home module + missing def in one sentence). F6 Term::New
codegen-deferral diagnostic explicitly names the raw-buf milestone
where support lands. F7 param-in accept-path is end-to-end (check +
build + run prints 17). F8 ParamNotInRestrictedSet names type-arg
+ var + TypeDef.
**Bugs (3, action: debug):**
- F1 (axis 1) — Same-module type-scoped call `(app Type.member …)`
rejected with phantom-qualified `expected <this>.T, got T`.
Bare `(app member …)` from inside Type's home module works.
Spec's "Canonical form decision" promises type-scoped works
uniformly; the resolver appears to disagree with the workspace
pre-pass on whether `<this-module>.T` equals bare `T`. Repro:
examples/fieldtest/kem_2b_min_repro.ail.
- F3 (axis 3) — Kernel-tier auto-import scopes the name but does
not register the module as a resolvable qualifier prefix. Per
the pre-pass, a bare `StubT` in a type slot is qualified to
`kernel_stub.StubT`; the resolver then rejects `kernel_stub`
as unknown. Asymmetric: prelude's free fns work (per
prelude_free_fns.rs), but the stub's TypeDef is effectively
unreachable from any consumer. Repro:
examples/fieldtest/kem_3_stub_consumer.ail.
- F4 (axis 3, spec/ship coherence) — The spec's prep.3 worked-
consumer relies on `(new StubT 42)`, but the shipped STUB_AIL
has only a TypeDef + ctor — the `(fn new ...)` the spec
designed is missing from the implementation. The diagnostic
the resolver does emit on the consumer (F5) is precise; the
bug is the absent def itself. Resolution: re-add the `new` to
STUB_AIL (the spec's design), refresh the drift pin.
**Friction (1, action: plan-or-defer):**
- F2 — Loader's sibling-only module resolution forces symlinks
for any cross-module fixture sitting outside the canonical
`examples/` directory. The kem_1 example required local
symlinks for std_list.ail + std_maybe.ail. Secondary: the
diagnostic message names only the .ail.json path even though
.ail also resolves — actively misleading. Recommended: small
tidy iter for loader workspace-search-path + diagnostic clarity.
**Spec-gap (1, action: ratify):**
- F9 — `design/models/0007-kernel-extensions.md:80` uses `unit`
as a value literal of type Unit; the checker treats it as a
Term::Var lookup and emits [unbound-var]. Either ratify `unit`
as the canonical Unit-value literal in the language, or tighten
the design model to use the existing idiom. The current model/
surface disagreement is a small but real LLM-author trap.
**Symlinks committed** as evidence of the F2 workaround:
examples/fieldtest/std_list.ail and std_maybe.ail are symlinks
into ../. They are the fingerprint of the friction — removing
them silently would erase the evidence.
Per Iron Law, fieldtester did not work around bugs — they were
all surfaced and recorded. The kem_2b_min_repro.ail fixture
exists specifically because F1 surfaced mid-drafting and got
minimised; kem_3_stub_consumer.ail also stays as the F3 RED-side
fixture.
Triage (next-step routing for /boss):
F4 → small inline fix (add (fn new ...) to STUB_AIL + drift refresh)
F9 → small inline ratify (whitepaper edit)
F2 → backlog issue, deferred (single tidy iter someday)
F1, F3 → debug skill dispatches, then implement mini-mode
F5-F8 → carry-on, recorded as wins
