https://gitlab.synchro.net/main/sbbs/-/commit/d3c494572acac3b4fa607dbc
Modified Files:
.claude/skills/javascript/SKILL.md .claude/skills/jsexec/SKILL.md exec/load/door_deploy.js
Log Message:
skills: an install-xtrn [exec:] child must use only the CONTEXT INTERSECTION

The `env` object I documented a moment ago has a sharper caveat than "jsexec-only", and it is a live trap rather than a curiosity.

install-xtrn.js runs an installer's [exec:<file>.js] steps with js.exec() --
IN THE SAME PROCESS -- and install-xtrn itself is invoked either from the command line (jsexec install-xtrn ...) or from INSIDE THE BBS (xtrn-setup.js, the sysop's Auto-install menu). So a door's getcore.js / getwads.js / getdata.js / getroms.js runs under whichever context the sysop happened to choose, and can rely on neither:

* no `env`, `uifc`, `conio` -- absent under the BBS
* no `bbs`, `console` -- absent under jsexec
* `system.*`, `js.*`, `file_*`, `print()`, `argv` -- present in both

print() is how such a script talks to whoever is running it.

Checked: none of the six [exec:] children in the door installers (download.js, fetch-assets.js, getcore.js, getdata.js, getroms.js, getwads.js) touches any
of the forbidden globals, and door_deploy.js resolves the live install from system.ctrl_dir rather than env.SBBSCTRL -- which also means a deploy step COULD be wired into an installer later without breaking. Its comment now says why, so the next reader does not "improve" it back to the environment.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net