Observe execution

The structure of task detail

Task detail is not a four-column layout. The header carries task identity, status and task-level controls; below it the page holds a stable two-column relation between the agent session on the left and the evidence rail on the right.

The header itself is a three-layer hierarchy: task identity and title on the mainline, status with progress and branch on the subline, and the task actions alongside. A long goal truncates to a single line in the flexible content area and is read in full through the task context, while the lifecycle markers stay horizontal and never shrink.

The evidence rail is a single-level state machine

The right rail shows the full dependency graph by default. Selecting a node replaces the whole rail with that node's overview, from which you switch between code, artefacts, lineage and agent.

Topology and detail are never on screen at the same time, which lets the file reader use the entire height of the right rail. The detail state allows the rail to widen moderately, and the session on the left stays visible throughout.

The top of a detail view must offer an explicit way back, and returning restores the full dependency graph.

The reason for this design is that trying to hold the dependency graph and a file body side by side in one narrow column makes both of them unusable. Replacing is more honest than compressing.

Disclosure order in node detail

Node detail follows conclusion → contract → evidence → source.

Overview leads with a scannable execution conclusion, then presents the input and output contract, the task context, the frozen code and the artefact evidence.

One caveat applies: attempt counts, durations and rework facts may appear only if the task snapshot already provides them. The front end must not fill the gaps with demo constants. So when a field is absent, that usually means the data does not exist rather than that the interface dropped it.

Code shows the code revision frozen when that attempt completed, together with the full code tree, and does not read the final task branch. The distinction matters: the final branch is the merge of every node's commits, and it does not represent the state any intermediate node was in at the time.

Artefacts shows the frozen result summary, the artefact manifest and the declared handoff artefacts. It does not open arbitrary runtime files.

Lineage shows a node invocation summary and deep-links to the task's full-width observability page.

Agent shows the runtime, model and capabilities together with their versions and lock information.

Reading a result summary

The result summary is the single user-visible summary authority for each successful node. Its structure is fixed: result, files, links, verification, risks and follow-ups.

The files section enumerates the relative paths of artefacts the runner has validated, one by one. That is what makes the summary trustworthy — its file list corresponds one-to-one with the frozen artefacts, rather than being the agent's own description of what it did.

The links section records only external addresses this node actually created or discovered. It does not dress a relative artefact path up as a web address.

By default the summary shows only the short excerpt extracted from the frozen body, and the full content loads once the user expands it explicitly. The reason is to keep the list scannable.

Reading the dependency graph

Graph nodes carry order, title and status only. The attempt count is not repeated on every node as a fixed property.

Node numbering and the execution queue come from a deterministic topological sort of the frozen dependencies, not from the index of an array in configuration. The canvas hides only those transitive edges that another path already implies, and keeps the true dependency direction with arrows — independent branches must not be drawn as if they were serial.

Live connection state

Task execution state and physical connection state must be kept separate.

Only a running task shows live, reconnecting, offline and active states. A completed or failed task uses the stable terminal state, read-only semantics and a final dependency graph.

Historical backlog backfills session records only; it must not roll the current snapshot back to an older node state. Once the terminal subscription has finished replaying, reconnection stops.

It follows that seeing "reconnecting" on a completed task is a defect rather than normal behaviour. If you observe it, it is worth reporting.

The file reader

Code and artefacts share one full-width file workspace, its filters, a raw file reader and a download action.

The file tree is given a usable width. Filenames, metadata and body are set at a readable reading scale, rather than squeezed into the side rail in a microscopic font.

The reader shows the raw path, byte size, media type and either the code object identifier or the content digest. Text is read page by page while preserving encoding boundaries; binary content is offered as a raw file download only.

An older task with no frozen revision shows an explicit compatibility note, rather than exposing a runner method error or a blank panel to the user.

Observability

The resource dashboard presents in-cluster platform telemetry, observability runs and task associations. An empty state must not fabricate capacity or health data.

Observation should be entered from the original business object, and the way back to that object should be preserved. A trace is execution evidence; a span is an operation within that evidence; the runtime session identifier is shown as technical information only when it is needed for diagnosis.

Conversation, turn, task, automation run, observability run and trace identifiers must not collapse into a single identity just because their display names have been unified. A flow started from a conversation is linked to it by a persistent proposal receipt — the completion state of the background task is not the same thing as the state of the turn that started it.