; Fieldtest raw-buf.4 (Axis 3, param-in element-type restriction).
; Task: an LLM author models a small "tick" record and reaches for a
; RawBuf to hold a batch of them — the obvious move for batch storage.
; RawBuf's element type is restricted to {Int, Float, Bool} via param-in,
; so a user TypeDef element must be rejected at `ail check` with a
; diagnostic that tells the author *why* and *what is allowed*.
;
; This probes the user-TypeDef path (distinct from the Str path the
; shipped raw_buf_reject_str.ail covers): does param-in fire for a type
; the author defined themselves, and does the message name the allowed
; set so the author can self-correct (e.g. switch to a Float field)?
;
; Expected: `ail check` exits non-zero with param-not-in-restricted-set
; naming `Tick` and the allowed set {Int, Float, Bool}.
;
; OUTCOME: rejects as expected (exit 1). Verbatim:
;   [param-not-in-restricted-set] first_price: type-arg `Tick` is not in
;   the restricted set for type-variable `a` of `raw_buf.RawBuf`
; The reject fires (good) and names the offending type, the type-var, and
; the home type. BUT it does NOT name the allowed set {Int, Float, Bool},
; which design/models/0007 §4 explicitly promises ("ParamNotInRestrictedSet
; names the offending type AND the allowed set"). A downstream author who
; reaches for RawBuf<Tick> is told `Tick` is wrong but not what would be
; right; they cannot self-correct without reading the kernel source.

(module rawbuf_4_paramin_reject

  (data Tick
    (ctor MkTick (con Float) (con Int)))

  (fn first_price
    (doc "Read the first Tick out of a batch buffer. Should never check: RawBuf cannot hold a user ADT.")
    (type (fn-type (params (borrow (con RawBuf (con Tick)))) (ret (own (con Tick)))))
    (params batch)
    (body (app RawBuf.get batch 0))))