Context
Docs across asobi_site, the asobi_lua sandbox guide, and an asobi_lua_loader comment all directed users to an "asobi-side game.log API" for logging from Lua. No such binding exists — print/eprint are stripped by the sandbox and asobi_lua_api.erl registers no log path. The docs have been corrected (#57, widgrensit/asobi_site#67) to state there is currently no in-script logging facility.
Decision needed
Should we add a real game.log binding, or commit to "no in-script logging"?
A real binding is attractive (game authors currently have zero observability), but it touches the sandbox's threat model on purpose — print/eprint were removed precisely because unstructured stdout logging breaks the JSON log stream and lets a tight loop flood the logging driver. A game.log would need:
- structured output routed through the host logger (
?LOG_*), not stdout
- rate limiting / per-tick budget to prevent log flooding
- bounded payload size and JSON-safe value coercion
- a fixed level set (no arbitrary atoms from script data)
This is a sandbox-surface API addition and should go through the architecture-guardian + the normal human gate before implementation.
Acceptance
Either a game.log(level, message, meta?) binding with the safeguards above, or a short ADR recording the decision to keep no in-script logging and the rationale.
Context
Docs across asobi_site, the asobi_lua sandbox guide, and an
asobi_lua_loadercomment all directed users to an "asobi-sidegame.logAPI" for logging from Lua. No such binding exists —print/eprintare stripped by the sandbox andasobi_lua_api.erlregisters nologpath. The docs have been corrected (#57, widgrensit/asobi_site#67) to state there is currently no in-script logging facility.Decision needed
Should we add a real
game.logbinding, or commit to "no in-script logging"?A real binding is attractive (game authors currently have zero observability), but it touches the sandbox's threat model on purpose —
print/eprintwere removed precisely because unstructured stdout logging breaks the JSON log stream and lets a tight loop flood the logging driver. Agame.logwould need:?LOG_*), not stdoutThis is a sandbox-surface API addition and should go through the architecture-guardian + the normal human gate before implementation.
Acceptance
Either a
game.log(level, message, meta?)binding with the safeguards above, or a short ADR recording the decision to keep no in-script logging and the rationale.