https://gitlab.synchro.net/main/sbbs/-/commit/35892c00ce4292ea1c9c4c11
Modified Files:
.claude/skills/javascript/SKILL.md .claude/skills/jsexec/SKILL.md
Log Message:
skills: correct two wrong claims about running in both contexts

I wrote, one commit ago, that a script runnable from both jsexec and the BBS "must use only the intersection", and that "print() is the safe way to talk
to whoever is running it". Both are wrong, and the tree says so.

A SCRIPT CAN DETECT ITS CONTEXT, and the stock code does -- with js.global.<name>, not a bare identifier. That is the whole point of the
idiom: a bare `console` under jsexec throws ReferenceError, while js.global.console is an ordinary property lookup that simply reads
undefined. exec/logonlist.js gates on js.global.bbs, exec/load/gettext.js on js.global.console, and install-xtrn.js itself does
`js.global.console && console.aborted`. The rule is not "avoid", it is
"probe, then branch".

AND print() IS NOT THE ONLY SAFE OUTPUT. Verified against the running binary: print, write, writeln, printf, alert, log, read, readln, prompt, confirm and deny are ALL present -- eleven functions, in a BBS session and on a command line alike. Only console.* / bbs / user are terminal-bound; uifc, env and
conio are jsexec-only. So an installer's child script has a real vocabulary: confirm() to ask, alert() to warn, prompt() to collect, print() to narrate.

Both skills now carry the table (from https://wiki.synchro.net/custom:javascript#output, checked against the
binary) and the js.global probe, with the stock scripts cited so the next reader can see it done rather than take my word for it.

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