docs(v4.0.0): the ROM is shared code, GA144-style -- an entry table, a permanent state area

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/v4.0.0/MACHINE.md

@@ -60,6 +60,29 @@ width (32 and 64 bits).
 
 **Read-only.** A store into the ROM is an address fault. Seal and `COLD` never go below it.
 
+### 2.1 The ROM is shared code, GA144-style (ruled 2026-10-15)
+
+The ROM is both the tractor's engine and part of the payload's engine. Payload code calls ROM
+routines at run time, as GA144 applications call their node ROMs. The routines are:
+- the tokenizer;
+- number conversion;
+- the slot packer, branch placement and resolution, which is the code generator for any
+  language built on top;
+- a generic table from names to values.
+
+What this asks of the ROM:
+- **An entry table at the ROM's base**, one jump per routine. Payloads call through it, never
+  to an address inside the ROM, so a rebuilt ROM breaks no payload. Each entry's stack effect
+  and the registers it uses (A, B) are listed in `DATASHEET-F18.md`.
+- **A reserved, permanent RAM area** for the routines' state (token buffer, packer state),
+  fixed in the memory map. Tables needed only while the system assembles may still use
+  dictionary space and be cleared afterwards.
+- **Nothing language-specific.** This is the rule of 7.1, which matters more now that every
+  payload depends on the ROM.
+
+Direction (Captain Bob, 2026-10-15): much more GA144-ish. Take what serves from colorForth's
+wiring, drop its odd concepts, add our own. That is what v4 becomes, on the way to v5 and later.
+
 ## 3. The boot
 
 1. **The machine.** The engine is reset and runs the ROM.