Take one FSM transition

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')