The header says where this stops and what picks it up next

lib/js.ml

@@ -131,7 +131,33 @@
     Output goes through [fs.writeSync(1, ...)] rather than
     [process.stdout.write], because node's stdout is asynchronous and a
     [process.exit] after a write on it truncates the output — which would
-    look exactly like a codegen bug. *)
+    look exactly like a codegen bug.
+
+    {1 Where this stops, and what the next lane picks up}
+
+    [spike/js/survey.sh] is the standing measurement: 24 MATCH, 0 DIFFER, 77
+    refused by name, 0 that node would not run, over the corpus and this
+    file's own two probes. What the refusals say about the order to work in:
+
+    - {b [Vec], and with it the type-erased container runtime.} The largest
+      single bucket after the FFI. A [Vec] reaches this file as
+      [Prim (Rt "flan_vec_push", ...)] over an [AddrOf] and an [Allocator],
+      so it needs two things that are refused on purpose today: a {e named
+      table} of [flan_vec_*] symbols answered over a JS array, and a narrow
+      hole in [AddrOf] for the arguments those take. Both refusals are
+      load-bearing and neither should be widened further than that. A [Vec] is
+      move-only and owns its storage, so a JS array aliases correctly and
+      needs none of the copying above.
+    - {b The dev loop.} docs/DISCUSS.md item 5's unexpected upside: evaluating
+      new code is the one thing JavaScript makes easy, and wasm cannot have
+      this at all. [Build.executable] refuses [--dev] here in its own words
+      and that refusal is where the lane starts.
+    - {b Interop}, which is what the whole target is for: a [declare-c]
+      binding has no meaning here, but a [declare-js] would, and 14 of the 77
+      refusals are the agent package's C.
+    - {b Conditions} are a lane and not a stub. [fdefers] is dropped below on
+      the grounds that nothing can start a transfer; the first thing that can
+      makes that note wrong, and it says so where it is. *)
 
 exception Unsupported of string