Build on the ecosystem.

The latency-compensation developer API shipped with HeroSync r1.4.0. Register rules for which actions register locally, classify packets the framework should reconcile, and provide state snapshots for consistent rollback points.

• Registration rules. Declare which player actions register locally at zero latency and which defer to the server.
• Packet classifiers. Classify outbound and inbound packets so reconciliation only touches what it should.
• Snapshot providers. Supply state snapshots — the rollback engine reverses only what needs reversing against a consistent point.
• Compatibility adapters. Adapters for common mod interactions, so other mods' actions reconcile cleanly.

// Usage pattern for HeroSyncAPI (signatures ship with the JAR's javadoc).
// 1. Register an action as locally-registered:
herosync.registerAction("my-mod:my-action", RegistrationRule.LOCAL_FIRST);

// 2. Classify a packet the framework should reconcile:
herosync.classifyPacket(direction, packet, PacketClass.RECONCILABLE);

// 3. Provide a snapshot provider for consistent rollback points:
herosync.registerSnapshotProvider(() -> captureState());

// 4. Disable per-mod when rules conflict:
herosync.disableRegistration("my-mod:my-action");

The public crosshair API shipped in v1.1.0. Other mods can read what the crosshair is currently targeting and drive their own rendering from the same context.

• CrosshairContext. The current target context — what you are aiming at, and its state.
• CrosshairColor. The colour vocabulary: hostile=red, passive=yellow, player=blue, boss=purple, container=cyan, interactable=green, redstone=orange, ore=gold.
• CrosshairStyle. The style vocabulary driving how the crosshair renders for a given context.

// Usage pattern for the CrosshairContext API (v1.1.0).
// Register a provider that renders alongside the dynamic crosshair:
CrosshairContext ctx = crosshair.currentContext();

switch (ctx.targetType()) {
  case HOSTILE   -> myOverlay.tint(CrosshairColor.HOSTILE);   // red
  case PASSIVE   -> myOverlay.tint(CrosshairColor.PASSIVE);   // yellow
  case PLAYER    -> myOverlay.tint(CrosshairColor.PLAYER);    // blue
  case BOSS      -> myOverlay.tint(CrosshairColor.BOSS);      // purple
  case CONTAINER -> myOverlay.tint(CrosshairColor.CONTAINER); // cyan
  case ORE       -> myOverlay.tint(CrosshairColor.ORE);       // gold
}

// Combat conditions surface through the same context:
if (ctx.attackCharged()) myOverlay.glow(CrosshairStyle.ATTACK_CHARGED);

The public API, EventBus and provider system shipped with README.md r1.2. Other mods can extend book rendering, subscribe to book events, and ship content through the provider system — with 15 bundled templates for common documentation layouts.

• Public API. Open and manipulate README.md works from other mods.
• EventBus. Subscribe to book lifecycle events (created, edited, saved, synced).
• Provider system. Register custom render providers and content sources that extend the Markdown pipeline.
• 15 templates. Bundled templates for common documentation layouts — start books from any of them.

// Usage pattern for the README.md public API (r1.2).
// Subscribe to book events:
readmemod.events().subscribe(BookEvent.SAVED, book -> {
    log.info("Book saved: " + book.name() + " (" + book.wordCount() + " words)");
});

// Register a custom provider that extends the Markdown pipeline:
readmemod.providers().register("my-mod:callout", new RenderProvider() {
    @Override public String render(String body) {
        return "{{callout}} " + body + " {{/callout}}";
    }
});

// Start a book from a bundled template:
readmemod.newBook("Server Rules", Template.GUIDE);

The command and export surface shipped with Redstone Debugger 1.0.0: the /rdebug suite, plain-language diagnostics (/rd explain, /rdebug diagnose <n>), world and HUD overlays, and a recording export format for sharing and re-analysis. A deeper SDK is in progress — this is what ships today.

• /rdebug suite. Recorder, timeline, clear, export and perf commands — headless control from chat.
• Diagnostics. /rd explain and /rdebug diagnose <n> — 12 analysis algorithms (signal tracing, dependency chains, root cause, SCC cycles, critical path, clock detection) over 25 event types.
• Export format. Export a recorded event timeline; the recipient can replay and re-diagnose without your world.
• AI insights (optional). Optional providers including local Ollama explain circuit behaviour — every core diagnostic runs offline.

# Command surface (shipped in 1.0.0)
/rd help                     # the full command suite
/rdebug recorder start       # begin recording a circuit (or press R)
/rdebug recorder stop        # stop and capture the timeline
/rdebug diagnose <n>         # run the 12-algorithm analysis on event n
/rd explain                  # plain-language explanation of the recording
/rdebug timeline             # step through recorded events tick by tick
/rdebug export               # export the recording for sharing
/rdebug perf                 # profiler, metrics, caching and memory monitor

The /packmerge command suite shipped with Pack Merger 1.9.1 — headless, server-side and scripted merging for pipelines and server owners. Merge strategy, conflict scanning and version-correct export all run from chat.

• Scan & conflicts. /packmerge scan and /packmerge conflicts — detect and classify every collision across packs without merging.
• Merge & export. /packmerge merge <a> <b> and /packmerge export — combine packs and write the version-correct pack_format.
• Strategy & resolution. /packmerge strategy sets the automatic resolution; /packmerge resolve overrides per asset.
• Import & clear. /packmerge import and /packmerge clear — manage the working set for scripted pipelines.

# Headless merge pipeline (shipped in 1.9.1)
/packmerge import my-pack.zip
/packmerge scan                      # classify conflicts first
/packmerge strategy priority         # list order wins by default
/packmerge merge pack-a.zip pack-b.zip
/packmerge export                    # version-correct pack_format baked in
/packmerge clear                     # reset the working set

The /j2b suite shipped with J2B MC 3.2.1 — cross-edition connectivity and mechanic control from chat. The RakNet client (ECDH + AES-256-CFB8) connects Java to Bedrock servers, and 27 flags govern the 161 sub-systems.

• /j2b connect. Connect Java → Bedrock servers via the native RakNet client. Online auth is still being verified against real servers.
• /j2b command suite. Explore and control the mod in-game; the config screen (B key / Mod Menu) exposes the 27 flags.
• Bedrock-ify flags. 161 sub-systems across 13 phases, each governed by one of 27 individually toggleable flags.
• .mcworld import. Import Bedrock .mcworld files into Java worlds.

# Cross-edition connectivity (shipped in 3.2.1)
/j2b connect <host> <port>     # Java → Bedrock via RakNet (ECDH + AES-256-CFB8)
# Config screen (B key / Mod Menu): 27 flags over 161 sub-systems
# e.g. keep Bedrock combat while leaving Java redstone alone

Shipped in v2.2: a command framework with a parser, a namespaced registry (namespace+trie), a completion engine and a middleware pipeline, plus config validators (range, enum, TTL cache, diagnostics). The developer plugin framework — where developer features plug in — is in progress; plugin APIs will be documented here as they stabilise.

• Command framework. Parser, registry with namespace+trie lookup, completion engine, middleware pipeline — wired into the mod via CoreCommandBridge.
• Config validators. Range and enum checks, TTL cache and diagnostics — invalid config is caught, not silently ignored.
• Plugin framework. Developer features are added via the plugin framework — in progress; public plugin APIs will land here.
• Feature registry. Every feature carries a real lifecycle (stable/beta/experimental) from the mod's own FeatureRegistry.

# Command framework surface (shipped in v2.2)
/hero                    # Hero Client command root
# The parser, namespaced registry (namespace+trie), completion engine
# and middleware pipeline power every /hero command.
# Plugin APIs: in progress — watch this page as they stabilise.

The shared AI backbone — internal today. The model router (BYOK across OpenAI, Anthropic, Gemini, Groq, OpenRouter and Ollama, with capability inference and rate limiting) exists as scaffolding; public API access arrives with the developer portal. CraftPilot's assistant is the first planned consumer.

• BYOK routing. User-provided keys by design; Ollama supports fully local inference.
• Capability inference. The router chooses a model suited to the task.
• Rate limiting. Per-provider rate limiting guides which model handles each request.
• Public API access. Planned with the developer portal — not yet public.

# Hero Agent — internal backbone (planned public API)
# Providers: OpenAI · Anthropic · Gemini · Groq · OpenRouter · Ollama (local)
# Status: model router + specialist agent suite exist; public API access
# arrives with the developer portal. Nothing here is assumed live.