Where the next session starts, and what to read first

DISCUSS.md

@@ -386,6 +386,29 @@ object cache separately at `Build.cachedir ()`, stable across builds. Nothing sw
 `dlclose`d, so a long session accumulates both files and mappings. Sweeping at session end is cheap and unrelated to
 any of the above.
 
+## NEXT SESSION STARTS HERE
+
+**The agreed plan: investigate putting the compiler inside the running program.**
+
+Today there are two programs. The *daemon* is the compiler. The *game* is a separate program it launches. They talk
+over a socket, so everything the editor shows — locals, globals, the stack, evaluation results — has to be packed up
+in one program, sent across, and unpacked in the other. A large share of what `BUILT.md` documents exists only to move
+data between those two address spaces.
+
+Putting the compiler inside the game removes all of that. There is nothing to send, because the compiler can read the
+program's memory directly. It is what SBCL does, and it is why interactive work in SBCL is instant.
+
+**Read, in this order:** item 13 (what is actually being decided, and why the order matters), then item 11 (the shape,
+the two objections and how the author answered them), then item 12 (the specific questions a spike must answer).
+
+**First task, and it is research not building:** the spike in item 12 — what it costs to link the OCaml compiler into
+a dev build. OCaml 5.2's multicore runtime has already removed the objection that would have been fatal. If it embeds
+acceptably, everything else is reachable.
+
+**Do not start with the backend question.** Merge first, measure, then choose. Item 13 says why.
+
+---
+
 ## 11. One process, not two — the biggest open question
 
 Raised at the very end of the session and **not resolved**. It subsumes items 9 and 10, and possibly several decisions

NEXT.md

@@ -480,6 +480,16 @@ acquisitions against releases at that boundary and report what is still held at
 annotation, nothing running at a distance — it does not change how code is written, it reports when something was
 forgotten.
 
+## Before the batch below: read `DISCUSS.md`'s "NEXT SESSION STARTS HERE"
+
+An architectural question was raised at the end of 2026-09-12 and agreed as the next thing to investigate: **putting
+the compiler inside the running program's process, instead of the two separate processes there are today.** It may
+reopen several things recorded here as settled — the watch design, the 4K result cap and its seqlock, the snapshot
+machinery, the render-thunk-per-inspection design for locals and globals, and whether an in-process JIT or a
+hand-written backend is needed at all.
+
+It is research first, not building. The batch below stays valid and none of it is blocked by the question.
+
 ## The next batch, in order
 
 Agreed at the end of 2026-09-12. Ordered by priority, not by size. Items 1-3 and 5-6 want the compiler core and should