Mock Scenario Editor

Enterprise only

Not included in DVARA Open Source.

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 opt-in by design — bundling Groovy means scenarios execute arbitrary code inside the JVM, so the editor stays off unless operators explicitly turn it on.

The editor runs inside Flightdeck, so set these properties in Flightdeck's configuration, not only the gateway's. All four of the following must be true for the /mock-scenarios pages to appear (there is no separate REST API):

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 editor pages. Defaults to false.
Flightdeck is not running with the prod or production Spring profile	The editor and its Settings link are never served under those profiles.

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 on this page 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 editor pages

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 uses these owner-only operations: PUT /mock-scenarios/{filename} creates or replaces a scenario, DELETE /mock-scenarios/{filename} deletes it, and POST /mock-scenarios/{filename}/test runs the submitted test action. Use a basename ending in .groovy; path separators are refused.

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

Save writes the file. Before the destination is touched, Flightdeck compile-checks the source on a staged temp file — a broken scenario is refused with MOCK_SCENARIO_INVALID, shown 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.

A successful save makes Flightdeck reload its own copy of the scenarios at once, with no 200 ms debounce wait. 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). The gateway is a separate process: it sees the change only if it mounts the same scenarios directory, and then it picks the change up through its own filesystem watcher.

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 Flightdeck 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.

Run 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 removes the file, and Flightdeck reloads its own copy at once. A gateway that mounts the same directory drops the scenario when its filesystem watcher sees the delete. 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 workspace 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