Test Plan Run View

The Run View is the live picture of a Test Plan run. It opens when you
trigger a plan from the plan page, click into a run from the history list,
or follow a deep link shared by a teammate. It is the same view whether
the run finished a second ago or two weeks ago — the difference is
whether it keeps updating in front of you.

The Run View shows every kind of plan item — TCM cases, functional
collections, load runs, fuzz campaigns, chaos experiments, contract
checks, and nested plans — with their native runtime UIs, recursively,
inline on one page. You never have to leave the page to see what
happened deep inside a child plan or a fuzz finding.

About URLs in examples: all examples use localhost:5770 as the
default Mockarty address. If your instance runs on a remote server,
replace localhost:5770 with its actual address.

Related pages: Test Plans ·
Override Surfaces ·
Plan Run Report ·
Runtime Flow View (test case) ·
Test Case Steps

What you see

A vertical tree of cards — one card per plan item — with the plan run
header at the top and a context panel in the right rail.

  Plan: nightly-smoke                       RUNNING  · started 14:22:08

  ├── 1  TCM         Login regression               PASS     4m 12s   ▸ expand
  ├── 2  LOAD        Stress checkout                PASS     5m 00s   ▸ expand
  ├── 3  FUZZ        Auth endpoint                  PASS     2m 37s   ▸ expand
  ├── 4  PLAN        Smoke after deploy             RUNNING  …        ▸ expand
  ├── 5  CONTRACT    OpenAPI diff                   PASS     0.9s     ▸ expand
  └── 6  TCM         Logout regression              MANUAL   awaiting you

Click any card to expand it. The body fills with the native UI for that
item type — charts for a load run, findings for fuzz, a step-by-step
flow tree for a TCM case, the same tree one level deeper for a nested
plan.

[Run View — full plan run — screenshot pending]

Reading the flow tree

Status chips

The colour and word on each item card is its live status:

Item-type icons

Every card carries a small icon for its item type so a long list stays
scannable:

The card body — what each type shows

When you expand a card the body shows the native runtime UI for that
item type, not a generic “details” panel. So:

• TCM case — the full step flow tree. Click a step to see its
  request, response, environment snapshot, harvested values, and
  manual-verdict drawer. Sequential debug controls (Continue / Stop)
  appear when the case was triggered in debug mode. See
  Runtime Flow View for the full
  reading guide.
• Functional — a summary card: total requests / passed / failed /
  duration. Below, a request list — each row has the method, path,
  response code, duration. Click a row → drawer with the full HAR
  exchange.
• Load — three live charts plus KPI chips. Charts stop animating
  when the run terminates and freeze on the final shape.
• Fuzz — findings list grouped by severity (critical / high /
  medium / low). Each finding card shows the payload, the request that
  triggered it, and the trace. The header has counters: total findings,
  unique findings, coverage %, total executions.
• Chaos — a timeline of fault events: when the fault was injected,
  what it injected, when it cleared, and the observed metric delta in
  the window around each event.
• Contract — the diff tree: added paths in green, removed in red,
  changed in amber. Click a changed path → monaco side-by-side overlay
  showing the old vs new schema.
• Nested plan — the child plan’s Run View, recursive. Every adapter
  in this list is active at the deeper level too. Cycle protection
  kicks in if the child references an ancestor: the card flips to a
  CYCLE chip with a “cycle skipped” placeholder instead of looping
  forever. Every child run remembers the run that started it, so a script
  or an agent can list a run’s nested runs directly:
  GET /api/v1/test-plans/runs/{runId}/children (MCP:
  list_test_plan_child_runs) returns each child’s id, plan, status and
  item counts.

Sticky manual-action banner

When one or more TCM items are awaiting a manual verdict, a yellow strip
appears at the top of the page:

2 items awaiting your action — Step 2 of TC-25 · Step 3 of TC-31

Click a row → the page scrolls to the relevant item, expands it, and
opens the resolve drawer over the step in question. The drawer is the
same one you use on the standalone case page; no navigation away.

Live updates — what each event means

The Run View subscribes to a live stream from the server. You’ll see
events flow through naturally; you do not need to refresh.

If the connection drops, the view tries to reconnect silently. The
reconnected view re-syncs from the server snapshot, so you never lose
state — at most you miss the animation of an intermediate transition.

Sequential debug for TCM cases inside a plan

When a TCM case item was started in step debug mode, the embedded TCM
flow tree shows a sticky bar at the bottom after every step — same
controls as the standalone case page:

• Continue — release the pause and run the next step.
• Continue & edit — open an editor that lets you tweak the harvested
  plan-context values, the next step’s overrides, or the next step’s
  request body before resuming.
• Stop — cancel the run.

The full debug-mode reference, including how the case-level
plan_context_snap flows into the next step, lives in the
Runtime Flow View
guide.

The context override drawer

The header has an Override context button. Clicking it opens a
drawer where you can write {{plan.X}} key/value pairs into the live
run.

The pairs land on the run’s plan-context bag and propagate down into
every TCM case item that starts AFTER the merge — exactly the same
mechanism as a step’s harvested extract, except the source is you, not
a step’s response.

When to reach for this:

• Mid-run you realise a downstream item needs a token you can paste
  in from another system (an admin console, a wallet export).
• A flaky upstream step didn’t harvest the value you expected, and you
  want to unblock the rest of the run without restarting.
• You’re driving a long manual test and want every subsequent step to
  see a base URL you picked on the fly.

Precedence rules for {{plan.X}} are documented on the
Override Surfaces page; the case-step view
is in Test Case Steps §3.

Item-level parameter override

A pending item — not yet running — can have its parameters patched
before it starts. Use this when you want to:

• Change a load item’s virtual-user count just for this run.
• Hand a fuzz item a different seed corpus.
• Force a TCM case to run in manual execution mode for this trigger
  only.

Click the Edit parameters action on a pending item card. The drawer
shows the current parameters; edit, save, and the orchestrator picks
the new values up when it dispatches the item.

The override is wiped on item rerun (so a second-attempt parameter
change is always a deliberate user act). The plan template itself is
not modified — future runs of the same plan start from the saved
parameters.

Accepting a run item’s result

If an item’s recorded failure is acceptable, use Accept as passed on
that item and enter a reason. The decision is saved for this run and is
visible to other operators; it does not run the item again or change the
original execution record. You can also mark an item skipped. Only items
that belong to the live run can be changed. A deleted run cannot accept a
new decision. Deleting the plan closes its saved decisions; restoring the
plan restores them, and permanently deleting the plan removes them.

Item rerun vs plan rerun

Every terminal item card has a Rerun item action; the plan header
has a Rerun plan menu. They are not the same:

For TCM items, Rerun item cascades into the embedded case run — it
calls the case’s own rerun internally. Nested plans cascade the same
way: the parent reset triggers the child’s reset recursively, with the
orchestrator’s cycle guard kicking in if the graph self-references.

Reading the comprehensive report

Every terminal run produces a report you can browse
inside the Run View or download as Allure JSON, Allure ZIP, JUnit XML,
Markdown, HTML, or Mockarty JSON. The Export button on the run
header opens the format menu. Format details — what each one contains
and when to use it — live on the
Plan Run Report page.

Sharing a run

Every run has a permanent URL of the shape:

https://mockarty.example.com/ui/<namespace>/test-plans/runs/<run-id>

Send the URL to anyone with read access on the namespace; they see the
same view, fully reconstructed from server data. If you share a still-
running run, the recipient gets the live updates from the moment they
open it.

Common pitfalls

• Cycle detected on a nested plan — the parent’s flow tree shows a
  CYCLE chip on the nested-plan card instead of recursing. The
  orchestrator refused to descend because the child references an
  ancestor (directly or transitively). Open the source plans and break
  the loop; the run completes the remaining items normally.
• Item override won’t save — overrides only apply on a pending
  item. Once it starts running you can no longer change its
  parameters; rerun the item to reset it to pending first.
• Context drawer rejects a key — keys must match
  [A-Za-z_][A-Za-z0-9_.]{0,127} and values are bounded in size. The
  drawer shows the rule it rejected.
• Drawer says “rate limited” — the per-user budget for overrides
  is shared with /run-extract from the standalone case view. Wait
  a minute and retry; if you’re driving an agent loop, batch updates
  into a single drawer save instead of one-per-key.
• A nested plan item rerun says “would form a cycle” — defence in
  depth: the rerun path refuses to walk an ancestry it has already
  visited. Same cause as the CYCLE chip above; fix the plan
  references.
• “Plan run is terminal” when you try to override context or rerun
  an item — the run already finished (passed / failed / cancelled).
  Use Rerun plan to start a fresh run; mid-run overrides only
  apply while the run is still in flight.

Permissions and namespace isolation

• Reading the Run View (snapshot + live updates) requires
  test_plan:read on the namespace that owns the plan.
• Overriding context, editing item parameters, rerunning an item, and
  resolving a manual step all require test_plan:write.
• Cross-namespace access is not allowed — a user who can read namespace
  acme cannot see runs from namespace globex, even if they have the
  permanent URL.
• Secrets in step requests show as *** and are never written to the
  run history, the export, or the audit trail. The audit trail records
  only the alias name and the storage the secret was read from.

Next: the Override Surfaces page is
the focused reference for plan / item / step overrides and their
precedence. The Plan Run Report page covers
exports.