You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[feat] Add a Workflow Runs page to the dashboard #1088
Show active local workflow state and team run records in the existing dashboard, with safe responses to eligible human gates.
Scope
Add a Workflow Runs page using the existing bundled dashboard structure.
Add read APIs for active local runs and reported run records visible to the selected workspace.
Show workflow, driver, status, current step, named end, duration, tokens, team revision, PR URL, scorer labels when present, and pending-record state.
Clearly distinguish local live state from team-reported history.
Add run and gate detail views.
Allow approve/choose responses through a same-origin protected POST endpoint.
Reuse the engine’s respond operation and audit fields.
Add CSRF or equivalent origin protection; do not expose a wildcard-CORS mutation endpoint.
Never return or render prompts, outputs, diffs, secrets, or private paths.
Add English and Chinese dashboard strings.
Out of scope
Published state snapshots, cross-machine ownership, starting runs from dashboard, editing workflows, provider approvals, remote hosting, triggers, and event waits.
Live runs and reported history have clear source labels.
Gate responses reject stale revisions.
Required gates use the non-agent dashboard channel.
External web pages cannot submit localhost responses.
No sensitive workflow content reaches API or HTML.
Existing dashboard pages and SSE remain intact.
Verification
Focused server/client scoping, record, gate, origin-protection, redaction, and UI-state tests; build/typecheck/lint; one real-CLI dashboard E2E displaying and responding to a gate. Update dashboard and workflow guides in both languages.
Notes from #1078 (#1129) for reading live run state:
Step statuses are pending | leased | running | succeeded | failed | skipped. running is a workflow step whose child steps are in progress; the step a driver works on is the leased one.
Steps inside sub-workflows are paths (ship.check.classify), and they exist in the run only once reached. Totals and "current step" cannot be computed from the top-level definition alone.
A run can carry end, the named end it reached; the run's outcome is that end's declared outcome.
Sensitive fields in the run file:inputs (the run's, and a workflow step's own inputs for its child) and snapshots of every child definition with their prompts and env templates. A lease's rendered env is not stored but is rebuilt from inputs. None of these should reach the API or HTML.
More sensitive fields in the run file. Besides inputs and the definitions, a run now keeps each for_each instance's item, each for_each step's results (every item with its outputs), and the outputs of earlier passes in passes and run.archive. An item often comes from inputs or from another step's outputs. None of these should reach the API or HTML.
A run can have several current steps. A driver that sends running holds several leases at once, and --driver local runs up to workflows.max_parallel commands. "Current step" is the list of leased steps. There is also a new status, cancelled, for steps an end or a break stopped.
Entries and counts differ. The end record has an entry per pass, while stepCounts counts each instance the run ended with once. In one run whose loop ran three passes over two items, stepCounts.total was 8 and steps had 16 entries. Take counts from stepCounts.
Activity
SaulMoro commentedon Oct 14, 2026
Notes from #1078 (#1129) for reading live run state:
pending | leased | running | succeeded | failed | skipped.runningis aworkflowstep whose child steps are in progress; the step a driver works on is theleasedone.ship.check.classify), and they exist in the run only once reached. Totals and "current step" cannot be computed from the top-level definition alone.end, the named end it reached; the run's outcome is that end's declared outcome.inputs(the run's, and aworkflowstep's owninputsfor its child) and snapshots of every child definition with their prompts andenvtemplates. A lease's renderedenvis not stored but is rebuilt frominputs. None of these should reach the API or HTML.The engine rules that span files are in
docs/dev/workflow-engine.md, added by #1129.SaulMoro commentedon Oct 15, 2026
Where the page's fields come from:
teamRevisionin the run record ([feat] Define the team revision once for run records, labels and snapshots #1163). It is absent when no pushed commit holds the definitions, so render it as optional.sourceHashis always present.prslist in the end record ([feat] Deliver workflow branches as pull requests #1090). Afor_eachrun can have several, so render the list.Acceptance criteria to add:
teamRevisionrenders without a broken link, and still showssourceHash.prsrenders three links.SaulMoro commentedon Oct 16, 2026
Three things from #1148 for reading runs:
inputsand the definitions, a run now keeps eachfor_eachinstance'sitem, eachfor_eachstep'sresults(every item with its outputs), and the outputs of earlier passes inpassesandrun.archive. An item often comes frominputsor from another step's outputs. None of these should reach the API or HTML.runningholds several leases at once, and--driver localruns up toworkflows.max_parallelcommands. "Current step" is the list ofleasedsteps. There is also a new status,cancelled, for steps an end or a break stopped.stepCountscounts each instance the run ended with once. In one run whose loop ran three passes over two items,stepCounts.totalwas 8 andstepshad 16 entries. Take counts fromstepCounts.Mobile screenshots for the Tencent#1088 Workflow Runs PR
fix(dashboard): keep gate buttons when only a run's duration changes (T…
feat(dashboard): add a Workflow Runs page with HITL answers (#1088) (#…