Current Runtime Snapshot
This page separates verified current-source findings from target design. The
snapshot covers the checked-out hexis-mod. No trusted production Lua source,
including Galatea, was present in the current checkout, so script-level claims
come only from clearly labeled historical evidence. This audit does not prove
behavior in a distributed release or live Minecraft session.
Source baseline and registration count
This snapshot audited hexis-mod commit
0d3ac3771790f3366c7eccdd8461ab70afc17de6. The checkout's uncommitted files
were repository instruction files, not scripting runtime source.
LuaSandbox.injectHexisApi() registers 26 top-level hexis entries. A
static scan of the production sandbox and script/lua/api package found 326
function-valued registration or bound-command sites: literal function
registrations, registration-helper calls, command-binding declarations, and the
direct wait/notify entries, excluding the metadata sandbox's duplicate
surface.
The second number is an implementation-size signal, not a guaranteed count of distinct runnable API paths. Some commands bind only when their registry entry exists, and some function values live in nested tables. Hexis should publish a leaf callable count only after the runtime capability registry can enumerate it deterministically.
Current flow
Confirmed in current source
| Finding | Evidence in the current implementation |
|---|---|
| Lua engine | LuaJ, created from JsePlatform.standardGlobals() and reduced by LuaSandbox |
| Entry point | The runtime executes top-level Lua, then requires hexis.main() |
| Execution | Each running script starts a named daemon thread |
| Waiting | hexis.wait sleeps that script thread in short chunks and processes queued events |
| Binding style | Handwritten Java libraries populate the global hexis table |
| Concurrency | Events and several mining, combat, navigation, GUI, camera, and input mechanisms use separate schedulers or daemon threads |
| Cleanup | Runtime stop flips flags, aborts a token, stops mining/combat, releases controllers, and runs callbacks; libraries also carry their own cleanup |
| Configuration | Lua metadata/config is stored in the runtime and transformed into generated module UI |
| Script locations | Current loader uses config/hexis/scripts, including official and user sources |
Current top-level entries include log, chat, player, inventory,
wait, script, config, navigate, combat, gui, mining, world,
movement, conditions, events, timer, hud, var, routes, input,
http, client, format, tablist, sidebar, and notify.
That list describes registration, not a stability guarantee. Callable counts are reported above with their methodology and must not be treated as a v4 surface.
Galatea evidence
The recovered prior audit analyzed an 817-line Galatea production script that directly coordinated inventory selection, connected-block inspection, target filtering, navigation start/poll/stop, camera locks, mining fallbacks, competition policy, debug highlights, and cleanup. The user identifies Galatea as the most trusted production behavior.
That source is not checked into the current workspace, so its exact contents, line count, and parity with the running script are not current-source findings. It remains strong historical evidence of the boundary problem and a required reference workload. The Galatea reference workload defines how to capture it again and extract reusable mechanisms without sacrificing trusted behavior.
Refuted or downgraded historical claims
| Historical claim | Current status |
|---|---|
| A previous API function count is authoritative | Refuted. The surface changed; future counts must be generated from current source. |
The current source exposes luajava directly | Not found in the current scripting source audit. The sandbox still needs adversarial tests; absence of that symbol is not a proof of safety. |
| Current cleanup is universally automatic | Unverified. Cleanup exists, but ownership is distributed across runtime, callbacks, controllers, and individual libraries. |
| Current docs define the correct redesign | Refuted. They describe historical bindings and mechanism-heavy patterns. |
Architectural gaps
- no single versioned capability registry generates bindings, docs, schemas, and AI tools;
- no uniform action handle/result/progress contract spans every domain;
- background-thread and polling behavior is distributed across implementations;
- resource ownership is not expressed as one enforceable lease model;
- current pages and bindings can drift independently;
- server semantics and generic engine behavior need a systematic leakage audit;
- live world lifecycle, cleanup, and tick-cost guarantees remain to be proven.
Evidence still required
Before promoting any current behavior to Implemented, verify it against a named clean commit and distributed build, run focused lifecycle tests, and perform a gated live Minecraft/server acceptance task. This snapshot should be updated whenever a vertical slice replaces part of the legacy runtime.