https://gitlab.synchro.net/main/sbbs/-/commit/ad12bd0878c9c79494e92217
Modified Files:
.claude/skills/jsexec/SKILL.md
Log Message:
jsexec skill: document how the exit status is actually set

The skill had one line on the subject - that exit(N) sets the process
exit status - which left the two things people actually get wrong
undocumented: that a script's return value is ignored entirely, and that
an uncaught exception yields status 1.

That gap has real cost. A hatchit.js bug reported this week was
diagnosed on IRC as "the result of hatch_file() will be the return
value, which is true (1) upon success" - a reasonable-sounding theory
that is not how jsexec works, and that would have sent anyone acting on
it to the wrong line of code. The actual cause was an uncaught
TypeError thrown after the work had already succeeded.

Adds an Exit status section covering both real sources, a measured table showing modules that return true / 7 still exit 0, and the behavior
around them: exit(N) unwinds from anywhere in the call stack, on_exit
handlers run on both the exit() and exception paths, and the exception
message goes to stderr. Closes with the consequences worth internalizing
- chiefly that status 1 does not mean the work didn't happen, since a
crash after the side effects leaves them in place, and that a module
must call exit(N) to report failure at all.

Every claim verified against a live jsexec rather than read off the
source.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)