Register a local debug runtime

The local debug runtime sees only state, actions, and events that you register. Read-only state is the default, and production telemetry remains independent.

Register state explicitly

Create the runtime with named snapshot functions. Start it before reading state and stop it during application teardown.

import { createDebugRuntime } from "@faultatlas/dev-core";

const runtime = createDebugRuntime({
  state: {
    cart: () => ({ itemCount: 2 }),
  },
});

runtime.start();
const cart = runtime.getSnapshot("cart");
const itemCount =
  typeof cart === "object" &&
  cart !== null &&
  "itemCount" in cart &&
  typeof cart.itemCount === "number"
    ? cart.itemCount
    : 0;
console.info("Cart snapshot received", { itemCount });
runtime.stop();

Actions require development mode and an explicit actionAllowlist. Use createDebugHost to compose the runtime with the local loopback transport consumed by the CLI.

Security boundary

The host binds to loopback and requires a short-lived session token. State names and action names are exact allowlists: prefixes and wildcards are not permissions. Register only snapshots that are already redacted and safe for a local operator.

Lifecycle and failures

Start one host for the local application process and always dispose it during framework teardown. A failed handshake, expired token, missing state key, denied action, or transport timeout is an explicit error; none of these should fall back to a remote connection.

The CLI operator loop composes the existing authenticated snapshots, bounded event buffer and explicit client registry. Unscoped capture remains read-only and redacted; targeted capture preserves explicit client routing. No automatic store discovery, remote listener, DOM/session capture, event-bus emit, or production live-debug surface is added.