Target contractVerified 2026-07-23Not yet executable

Normative promotion sequence for the v4 API.

Delivery Roadmap

Hexis will not redesign hundreds of bindings at once. It will prove the architecture through complete vertical slices and revise the contract before expanding.

Phase 0 — Freeze the evidence

• Inventory current Java/Lua bindings and properties from source.
• Trace runtime, thread, cleanup, GUI/config, and world lifecycle behavior.
• Capture production Galatea behavior and other representative scripts.
• Catalog every Hypixel leak and unsafe Java bridge path.
• Define task fixtures and telemetry before changing contracts.

Exit: a reproducible baseline, not merely a function count.

Phase 1 — Action kernel

• Create typed action, result, progress, cancellation, and resource-lease contracts.
• Establish one Lua scheduling lane and a client-thread gateway.
• Enforce world-scoped cancellation and cleanup.
• Introduce the allowlist capability registry.
• Keep the first surface internal until lifecycle tests pass.

Exit: a synthetic action survives success, failure, timeout, stop, disconnect, and world unload without leaked resources.

Phase 2 — Navigation vertical slice

Acceptance tasks:

1. navigate to a reachable coordinate;
2. report no-path with useful diagnostics;
3. cancel during movement;
4. recover from a changing obstacle;
5. traverse a pack-provided teleport/topology edge;
6. run the same core contract in a local-world fixture.

Then expose one Lua action, write one realistic script, and run the AI generation suite. Revise naming and semantics before marking navigation implemented.

Phase 3 — Galatea mining reference slice

Move reusable scan, vantage, navigation, camera, mining, retry, and cleanup mechanisms from Lua into engine actions. Preserve Galatea’s trusted behavior through side-by-side replay and live acceptance. Keep zone selection, competition policy, sell policy, and stop rules in Lua.

Exit: substantially smaller Lua, no behavior regression, explainable failures, and no Hypixel semantics embedded in core.

Phase 4 — Inventory, GUI, and transactions

Introduce synchronized inventory observations and transaction actions. Place menu meaning in packs. Test screen changes, lag, rejected clicks, cancellation, and full-inventory recovery before building sell workflows.

Phase 5 — Combat, camera, observations, and events

Apply the same action/resource model to targeting, pursuit, camera, world queries, HUD/config, and event delivery. Prove backpressure and resource conflicts before allowing passive scripts to run alongside active control. Add chat, commands, HTTPS, notifications, and scoped storage only behind separate grants, rate limits, cancellation, redaction, and audit tests.

Phase 6 — AI authoring and long-term goals

Generate AI tools and Lua annotations from the contract registry. Add static validation, permission review, dry-run support, structured repair, provenance, and the evaluation dashboard. Only then expose user-facing “describe a script” generation broadly.

Promotion gate for every capability

A slice becomes Implemented only when:

• source and public contract agree;
• lifecycle, permission, and failure tests pass;
• a realistic Lua workflow succeeds;
• server knowledge is isolated;
• an AI produces and repairs it reliably;
• live Minecraft behavior is verified;
• rollback and telemetry are defined.

Shipping fewer proven contracts is preferable to publishing a large, unpredictable API.