Module json 

Turning derived run state into the JSON shapes the control-plane returns.

The core RunState and its parts are Rust enums with data; the wire wants stable, self-describing objects a thin SDK can read without knowing the Rust types. This module is that translation, and it is the one place that fixes those shapes, so every endpoint returns a run’s status the same way.

The status object

A status is always { "state": "<name>", ... }, where state is a stable snake_case token and any extra keys carry that state’s data:

• { "state": "running" }, { "state": "awaiting_model" }, { "state": "awaiting_tool" }, { "state": "not_started" }, { "state": "needs_reconciliation" } carry nothing more.
• { "state": "suspended", "reason": "...", "input_schema": { ... } }
• { "state": "budget_exceeded", "budget": { "kind": "...", "limit": n }, "observed": n }
• { "state": "completed", "output": <json> }
• { "state": "failed", "error": "..." }
• { "state": "abandoned" }, optionally with "reason": "..." and, when a needs-reconciliation run was abandoned, "unresolved_write": { "seq": n, "tool": "..." } — the recorded evidence that the abandonment never claimed the dangling write settled.

The pending object

A dangling call intent is null when there is none, or one of:

• { "kind": "model", "seq": n, "request_hash": "..." }
• { "kind": "tool", "seq": n, "tool": "...", "input": <json>, "effect": "read|idempotent|write", "idempotency_key": "..."|null }

Functions

pending

The pending-call object, or null when there is no dangling intent.

run_state

The full derived-state object: the dry-run replay projection a client gets from the run and replay endpoints (status, usage, next position, pending intent). Nothing here executes; it is a pure fold of the recorded log.

status

The status object for a derived status. See the module docs for the shapes.