Mock Scenario Editor

The Mock Scenario Editor is the browser-based surface in DVARA Flightdeck for authoring the Groovy scenarios that drive the Mock Provider. It replaces the edit-save-wait-for-watcher loop with an inline editor, a compile-check on save, and a Run test panel that dry-runs a scenario against a synthetic request without touching the live matcher list.

This page covers the Flightdeck-side of the workflow. For scenario syntax (the name, when, respond variables), the file layout, and the matcher precedence rules, see the Mock Provider page.

Prerequisites

The editor is a triple opt-in by design — bundling Groovy means scenarios execute arbitrary code inside the gateway JVM, so the editor stays off unless operators explicitly turn it on.

All three of the following must be true for the /mock-scenarios page and the underlying REST API to appear:

Requirement	Why
dvara.llm-gateway.providers.mock.enabled=true	Mock provider must be active.
dvara.llm-gateway.providers.mock.scenarios-dir=<path>	A scenarios directory must be mounted — the editor reads and writes files in this directory.
dvara.llm-gateway.providers.mock.console-authoring=true	Explicit opt-in for the REST API and UI. Defaults to false.

Without the console-authoring flag, the gateway serves mock traffic read-only from the scenarios already on disk. This is the recommended configuration for any environment where scenarios are version-controlled and deployed immutably.

On top of the property gates, every write endpoint under /v1/admin/mock/scenarios/** requires the owner role. RBAC blocks everyone else even with the flags flipped on. The gateway also logs a loud WARN at startup whenever the Mock provider is enabled on a non-dev Spring profile, so the activation is never silent.

Enabling the editor

Add the opt-in alongside the other Mock provider settings in your override config:

dvara:
  llm-gateway:
    providers:
      mock:
        enabled: true
        scenarios-dir: /app/config/mock-scenarios
        console-authoring: true   # opt in to the REST API + UI

Mount the override file and the scenarios directory in your Docker Compose or Kubernetes deployment as documented on the Mock Provider page. After restart, DVARA Flightdeck serves three new routes:

• /mock-scenarios — list page showing every .groovy file in the scenarios directory with its filename, size, and last-modified timestamp
• /mock-scenarios/new — blank editor with a starter template
• /mock-scenarios/{filename}/edit — editor pre-loaded with the on-disk source

Figure 1. Mock scenarios list — every .groovy file in the configured scenarios directory

Editing a scenario

The editor provides Groovy syntax highlighting and a single Save action.

Save writes the file via PUT /v1/admin/mock/scenarios/{filename}. Before the destination is touched, the gateway compile-checks the source on a staged temp file — a broken scenario surfaces as an inline error banner and the existing file on disk is left untouched. You can keep iterating in the editor without ever losing a working scenario to a syntax mistake.

Successful saves trigger a synchronous reload so the next request sees the new version immediately — no 200 ms debounce wait, no polling the filesystem, no stale dispatch. The reload is the same one the filesystem watcher would do (steps 3–6 of the hot-reload flow documented on the Mock Provider page), just fired directly instead of from the CREATE/MODIFY event.

The Run test panel

The right-hand pane is a sample-request builder with fields for:

• model — any mock/* string the scenario might match on
• userMessage — the text that populates the latest user message
• systemMessage (optional) — prepended as a system role message
• temperature — nullable, defaults to the provider default if left blank
• stream — checkbox that sets request.stream=true

Click Run test and the gateway loads the scenario fresh from disk, runs matches() and respond() against the synthetic request, and shows the outcome inline:

Badge	Meaning
Matched	The when predicate returned true. The editor renders the response body from respond() plus the elapsed evaluation time.
No match	The when predicate returned false. The editor shows the elapsed time so you can spot slow predicates.
Error	The predicate or the response closure threw. The editor shows the exception message so you can identify the bug without grepping logs.

The Run test endpoint (POST /v1/admin/mock/scenarios/{filename}/test) is read-only. It loads the scenario, dry-runs it, and returns the result without touching the active matcher list, emitting an audit event, or mutating any on-disk state. Run it as many times as you want while iterating.

Deleting a scenario

The list page's Delete button issues DELETE /v1/admin/mock/scenarios/{filename}, removes the file, and triggers the same synchronous reload. The deleted scenario is excluded from the next request immediately. As with saves, the action is owner-only.

Audit events

Every mutating action emits a signed audit event so scenario changes are traceable:

Event	Trigger
MOCK_SCENARIO_CREATED	A scenario file was created via the editor (PUT on a filename that didn't exist).
MOCK_SCENARIO_UPDATED	An existing scenario file was overwritten via the editor.
MOCK_SCENARIO_DELETED	A scenario file was deleted via the editor.
MOCK_SCENARIO_RELOADED	The scenarios directory was reloaded — fires on editor saves, deletes, and filesystem-watcher events equally.

The Run test endpoint does not emit an audit event — it's read-only by design.

When to use the editor vs the filesystem

Use the editor for:

• Interactive development — fast iteration on matcher logic against a running gateway, without restarts
• One-off ad-hoc scenarios — quick spikes to reproduce a tester's bug report
• Exploratory debugging — running the same scenario against a variety of synthetic requests via the Run test panel

Keep scenarios in version control and deploy them from the filesystem for:

• Production mock environments — CI pipelines, staging, shared dev instances
• Anything that must be reviewable via a pull request — compliance-sensitive test fixtures, shared fixtures across team boundaries
• Any tenant where you want to disable editing entirely — leave console-authoring=false and the editor routes return 404

The two modes coexist cleanly: the editor writes to the same directory the watcher reads, so a scenario authored in the editor is immediately available to git-commit and promote through your normal deploy pipeline.

Next steps

• Mock Provider — scenario syntax, matcher precedence, file layout, hot-reload mechanics
• SIEM & Webhooks — route the MOCK_SCENARIO_* audit events to your SIEM if you want change tracking outside the gateway