The linear replay carried old-lineage content over parent-owned files;
this checkpoint restores them and adapts the branch to the parent's
post-rebase seam:
- restore all pty/lsp/subprocess/code-runtime surfaces to the parent's
exact content (this branch claims none of them) and drop the net-zero
code-runtime-e2b/pty-e2b/lsp-e2b residue and its registrations
- widen serializeRemoteEnvironment to the seam's NodeJS.ProcessEnv
tombstone contract: an explicit undefined removes an ambient entry
- migrate the two E2B fixture Agent stubs to the Inbox-model interface
and Session.create
- re-apply the branch's gen-doc-graphs roles, THIRD_PARTY_NOTICES e2b
row, and packages/README group row (trimmed to the doc budget);
regenerate catalogs and re-record bilingual pairings
The load-time range check rejects a maxWallMs above Node's maximum
setTimeout delay, but the constraint appeared only in the README design
section. Deployments reading the Config field JSDoc, the generated config
catalog, or the README config summary saw maxWallMs described as a
positive finite wall-clock ceiling, so an out-of-range value looked valid
until plugin load failed.
`config.maxWallMs` is only checked for positivity, and it is handed to
`setTimeout`, which clamps any delay above 2^31-1 ms to 1 ms. A deployment
configuring a 25-day wall ceiling therefore gets the opposite of what it asked
for: every run times out on the first tick. The runtime now range-checks the
field at load against MAX_TIMER_DELAY_MS from dsh-timeout and throws, so the
misconfiguration fails loud where it is self-contained instead of silently
inverting the budget.
`computeMs` needs no matching bound: it is compared against measured event-loop
utilization rather than fed to a timer.
The test asserts both the rejection and that the boundary value itself loads.
Tianyi Cui
Turtle
xjt
j-xiang
Chinesezjc