The node half is ClientModuleHostService (ctx.clientModuleHost): it composes
the __DSH_BOOT__ graph by scanning loader entries for dshClient packages,
serves /plugins/<id>/client.js, taps the index render, and exposes
rebuilt/onRebuilt/onGraphChanged. Scanning is incremental per package — no
full-rescan path exists: internal/plugin marks the fiber's entry name dirty,
a flush reconciles each name against live entries, package metadata
(including negative verdicts) caches forever, and re-hashing is reachable
only through rebuilt(id). The browser half moves wholesale to the standard
./client export (ClientModuleSystem, parseBootManifest with the dual-view
BootManifest, and the adoption plugin face that reads the
window.__DSH_MODULES__ slot and provides ctx.modules).
The session-title snapshot exposed a real activation race: ui-trajectory
and ui-question register into conversation-declared slots but only
injected 'slots', so nothing ordered their applies after ui-conversation's
— register() into the undeclared slot threw and the entry FAILED. Both now
inject 'conversation' as an ordering edge (documented as such; specs stub
the service where the bench declares the slot itself).
Review-bot findings, all three applied: the module loader's load sink
cross-checks the handoff id against the arriving row (a mis-stamped bundle
can no longer register under another entry's identity); the default
execute seam removes the inline script node right after its synchronous
execution (repeated HMR rebuilds no longer accumulate dead nodes); a
throwing onRebuilt subscriber is contained per-listener and routed to
onError instead of escaping the fs.watchFile callback.
