Advance the FSM by one transition.

        Args:
            action: Name of the action to run. Must be in the
                current valid-next set; otherwise the call returns
                an ``invalid_transition`` error with the list of
                actions actually allowed right now.
            inputs: Keyword inputs to the action. Each action
                declares its own required + optional inputs;
                consult ``theodosia://next`` and the action's docstring
                to see what's expected. Object is the canonical
                form. A JSON-encoded string is also accepted (some
                clients serialize nested object arguments that way)
                and is parsed into an object before dispatch.

Actions (entry: select_mode):

• select_mode: Start a run. Pass intent for natural-language mode, or just repo_path/ref for diff mode. repo_path is also where openapi.json is read from; splunk_index is the index holding the target's server-side telemetry.

• read_diff: Read git diff <ref>..HEAD from the repo.

• extract_endpoints: Pull changed routes from the diff and load the sibling openapi.json.

• parse_intent: Score OpenAPI operations against the natural-language intent and pick the top matches.

• doc_lookup: Consult the k6 MCP documentation for the constructs kassi emits (HTTP requests, thresholds, checks, scenarios) and record version-grounded citations. Non-blocking: degrades to no references when the docs are unavailable.

• scaffold: Compose a deterministic, self-contained k6 scaffold from the OpenAPI spec (no model): per-endpoint requests with sample bodies, the baked base URL, and load options. This is the runnable baseline the next step builds on.

• generate_script: Author the final k6 script on top of the scaffold, using k6's own generate_script MCP prompt and best-practices to guide the model. Falls back to the scaffold when the model or guidance is unavailable; validation failures are repaired by the fix_script phase.

• validate_script: Validate the script via the k6 MCP validate_script tool (1 VU, 1 iteration).

• fix_script: Repair the k6 script using the error the k6 MCP validate_script tool returned (real stderr + issues + suggestions), then loop back to validation. The correction loop is an explicit edge in the state machine; on a model failure it falls back to the scaffold.

• run_test: Execute the load test via the k6 MCP run_script tool (passing VUs + duration, which the tool needs since it ignores the script's own options) and parse the metrics from the summary. Bounded by a timeout: if the authored script wedges k6 so the call never returns, fall back to running the deterministic scaffold once, so the pipeline never hangs.

• splunk_preflight: Before correlating, verify the target Splunk index exists and capture its event count, sourcetypes, and the Splunk version via the Splunk MCP splunk_get_info / splunk_get_index_info / splunk_get_metadata tools. Non-blocking: correlate still runs if a probe fails.

• correlate: Read the target's server-side telemetry over the exact test window via the Splunk MCP splunk_run_query tool: an overview rollup, a per-second timeline (when it degraded), a by-endpoint breakdown (which route degraded), and the dominant server-side error (why). Synthesize the actionable findings. Pass splunk_spl to override the rollup query.

• detect_anomalies: Run Splunk's own ML over the test window via the Splunk MCP splunk_run_query tool: the AI Toolkit's StateSpaceForecast projects the latency band (falling back to the core predict command when the toolkit is unavailable), and anomalydetection flags statistically outlying buckets. This is the saturation onset found statistically, independent of the fixed error thresholds. Non-blocking: degrades to no anomalies when Splunk is unavailable.

• analyze: The writer phase (Granite 4.1): turn the correlated facts into a cited analysis (cause,

• screen: The auditor phase (Granite Guardian): an independent model judges whether the analysis is

• report: Assemble the final report from the analyzed and screened state and have the model narrate

Transitions:

• select_mode -> read_diff (when: stage == 'selected' and mode == 'diff')

• select_mode -> parse_intent (when: stage == 'selected' and mode == 'intent')

• read_diff -> analyze (when: stage == 'failed')

• read_diff -> extract_endpoints (when: stage == 'diffed')

• extract_endpoints -> doc_lookup (when: stage == 'scoped')

• parse_intent -> analyze (when: stage == 'failed')

• parse_intent -> doc_lookup (when: stage == 'scoped')

• doc_lookup -> scaffold (when: stage == 'documented')

• scaffold -> analyze (when: stage == 'failed')

• scaffold -> generate_script (when: stage == 'scaffolded')

• generate_script -> validate_script (when: stage == 'generated')

• validate_script -> fix_script (when: stage == 'needs_fix')

• fix_script -> validate_script (when: stage == 'generated')

• validate_script -> run_test (when: stage == 'validated')

• validate_script -> analyze (when: stage == 'failed_validation')

• run_test -> splunk_preflight (when: stage == 'ran' and splunk_enabled)

• run_test -> analyze (when: stage == 'ran' and not splunk_enabled)

• run_test -> analyze (when: stage == 'failed')

• splunk_preflight -> correlate (when: stage == 'preflighted')

• correlate -> detect_anomalies (when: stage == 'correlated')

• detect_anomalies -> analyze (when: stage == 'detected')

• analyze -> screen (when: stage == 'analyzed')

• screen -> report (when: stage == 'screened')

Reset this session's FSM to its entrypoint.

    Rebuilds the session's Application via the factory, clears any
    sub-runs the session spawned, and appends a ``reset_session``
    marker entry to ``theodosia://history``. Prior history entries are
    preserved, so the audit trail records the reset rather than
    wiping it: ``ran A -> ran B -> reset -> ran A again``.

    Refuses in shared-app mode (servers mounted with an
    ``Application`` instance rather than a factory) because
    resetting would affect every connected client at once. Use
    per-session isolation (factory mode) for servers where reset
    matters.
    

Rewind the session to the state captured after history[seq=N].

    ``sequence_id`` is the ``seq`` field on a ``theodosia://history`` entry.
    ``seq`` is accepted as an alias so a client can copy the value straight
    from history under either name (``sequence_id`` wins if both are given).
    The session's Application is rebuilt via the factory, then its
    state is overwritten with the snapshot captured at that point,
    and its ``__PRIOR_STEP`` is set to the action name from that
    entry so ``valid_next_actions`` computes correctly. Sub-runs
    recorded after that point are cleared. A ``fork_at`` marker is
    appended to history with the target sequence_id under
    ``inputs``.

    Refuses when:
      - shared-app mode (would affect every connected client);
      - sequence_id is out of range;
      - the target entry was a refusal (state_after is None);
      - the target entry is itself a fork or reset marker (avoid
        walking a hall of mirrors).
    

Resume a past Burr run by loading persisted state.

    Three-tier source resolution:

    1. If ``mount(state_loader=...)`` was passed an explicit Burr
       ``BaseStateLoader``, use it. Any persister works:
       ``SQLitePersister``, custom S3/postgres loaders, etc.
    2. Else if the session's current Application has a
       ``LocalTrackingClient`` attached, read its on-disk log.
    3. Else refuse.

    ``partition_key`` defaults to empty string, matching Burr's
    default; pass it explicitly when your persister uses
    partitioned storage.

    Use this for:
      - resuming a session across server restarts (track
        ``app_id`` on the client, restore here after reconnect);
      - forking from any persisted past run, not just the current
        session's in-memory history.

    Refuses when:
      - shared-app mode (no factory to rebuild from);
      - no state_loader configured and no LocalTrackingClient on
        the Application;
      - the requested app_id/sequence_id doesn't exist.
    

List all available resources and resource templates.

Returns JSON with resource metadata. Static resources have a 'uri' field, while templates have a 'uri_template' field with placeholders like {name}.

Read a resource by its URI.

For static resources, provide the exact URI. For templated resources, provide the URI with template parameters filled in.

Returns the resource content as a string. Binary content is base64-encoded.