The last opt-in claim, the macroexpand op, and two quoted programs that match their files

NEXT.md contradicted itself about the raylib header: two entries said the check
runs on every build and a third, further down, still explained why it is opt-in.
It gets the strikethrough its siblings have, with the reason the argument
dissolved -- the commit, not a change of mind about the property.

plan.org's list of what the dev runtime answers over nREPL had gained a member it
never listed. And the page quotes a program so that the line numbers in the output
beside it resolve, so both new examples are now pasted from their files rather than
trimmed, and cast.flan gets the source block every other example has.

NEXT.md

@@ -1056,9 +1056,12 @@ header is now cached in the session as well as on disk, so a repeat import (a `C
 `import` line) costs nothing, and a header edited mid-session is not picked up until the session restarts — the same
 rule a changed `.c` file follows.
 
-**Opt-in on purpose.** `vendor/raylib/headers` is `?${FLAN_RAYLIB_H}`. "A build needs libraylib linkable and not
+~~**Opt-in on purpose.** `vendor/raylib/headers` is `?${FLAN_RAYLIB_H}`. "A build needs libraylib linkable and not
 raylib-devel installed" is a property chosen deliberately, and requiring a header would take it from everyone to give
-the check to whoever has one. Unset means off; set-and-wrong is an error naming the path.
+the check to whoever has one. Unset means off; set-and-wrong is an error naming the path.~~ — no longer so, and what
+dissolved the argument was the commit rather than a change of mind about the property: `vendor/raylib/raylib-5.5.h` is
+tracked, `headers` names that path with no `${...}` in front of it, `FLAN_RAYLIB_H` is gone, and the check runs on
+every build. The `?` marker still means what it says here; this package is simply not using it any more.
 
 Worth knowing before touching it:
 

plan.org

@@ -702,6 +702,9 @@ nses-of-symbols and middleware. Treat "speaks nREPL" as milestone 7a and "an
 editor client that is pleasant" as a separate milestone 7b. In the dev runtime:
 - eval string in package; compile form/file with source locations
 - completion, arglist, describe, find-definition
+- macroexpand, one step or to the fixpoint — the compiler builds the macro into a
+  shared object and dlopens it to run the expansion, which is the same route a
+  file's own macros take
 - backtrace + restarts; interrupt
 
 ** Emacs client

web/index.html

@@ -442,8 +442,9 @@ that overflows (<code>INT64_MIN / -1</code>, whose true quotient is one past the
 the type), and a float-to-integer cast whose value does not fit. All three now signal
 <code>ArithError</code>, the way a bad index signals <code>BoundsError</code>.</p>
 
-<pre><code>;; The divisor goes through a global so that constant folding cannot
-;; answer it before the backend does.
+<pre><code>;; Three integer operations have no right answer. Each used to be a bare SIGFPE
+;; or an undefined value; each signals ArithError now. The divisor goes through
+;; a global so that constant folding cannot answer it before the backend does.
 (defvar zero i32 0)
 
 (defn main [] ()
@@ -461,6 +462,14 @@ $ flan run cast.flan
 cast.flan:7:17: this value does not fit the integer type it is cast to, which
 holds [-2147483648 2147483647]</code></pre>
 
+<pre><code>;; A float-to-integer cast whose value does not fit. The condition it violated
+;; is reported as the range the destination type can hold, which is the same
+;; shape BoundsError uses for a slice: the violated condition, written out.
+(defvar big f64 1e30)
+
+(defn main [] ()
+  (println (i32 big)))</code></pre>
+
 <p>A Lisp that stops naming the file and the line beats one that dies with
 <code>SIGFPE</code>, and a program that genuinely does not care installs a handler once at
 startup and never thinks about it again. Float division is deliberately left alone: IEEE