[knihit]

Description

Part 2 of 3 of the Execution tab, after #115, which holds the run core (wc/06a-run-core); #93 is part 3. This part puts the run on the page: the Execution tab draws the same graph as the Designer, read-only, with a goal box and a Run button. Run starts a run on the API, then reads it once a second, and each node shows its live state until the run ends. The page calls the relative /api, so it works the same against the stub (npm run dev:stub) or a server named by WC_API_TARGET.

Execution tab (src/execution/):

• Execution.tsx: the graph, a Goal box and Run. The goal starts as the outcome of the intent. The text of the box is kept in App, so it survives a switch of tab. From the click until the run ends Run is off and the box is read-only (not disabled, so it keeps focus) and shows the goal of that run. Enter in the box starts a run, except the Enter that ends an input method composition. A line break in the outcome becomes a space in the goal.
• Each node shows a badge with a word and a colour from the theme: Queued (dashed outline), Running, Done, Failed. The end shows Passed or Halted, and after a halt the stages behind the failed one say Not run. The word carries the state; only Queued also differs in shape.
• A line under the button says where the run is. A screen reader hears it from a polite live region (role="status") that App keeps outside the tabs, so it is announced while the Designer tab is open too. Each node's name for a screen reader ends with its state.
• An error from the API shows in one alert under the Run button. A screen reader hears it from a role="alert" region that App keeps outside the tabs (a test checks that it is empty before the error and holds the sentence after, with the Designer tab open too); the status line on the tab says only "See the error below.", which the live status region leaves out When a read of a started run fails, the alert adds that the run, with its id, may still be going on the server. A failed stage is a result, not an error.
• timerScheduler is the browser adapter for the core's Scheduler port. useExecution and useGoal keep the state and the goal in App, so a run goes on and the goal stays while the Designer tab is open.

Shared pieces: WorkflowGraphCard (the card with the graph) and WorkflowGate (loading, error and empty states) are used by both tabs; designer/states.tsx moved to workflow/states.tsx. State colours are CSS variables in canvas.css, and a test checks that they match the theme module and reach WCAG 2 AA in both modes.

Docs: workflow-canvas/README.md has an Execution tab section.

How to run

cd workflow-canvas
npm ci
npm run dev:stub

Open the address it prints, open the Execution tab and press Run. The stub fakes a run: draft runs for 3 seconds, then review, then the end shows Passed.

Type of Change

• Other: the Execution tab of the workflow canvas, in workflow-canvas/

Testing

• Root npm test (tests/scripts/**/*.test.js): not run; this PR changes only workflow-canvas/.
• If cli/ changed: not applicable
• Smoke tested affected agent(s): not applicable, no agent changed
• If an agent's or skill's behavior changed: not applicable
• New or changed code files carry the required SPDX header (see AGENTS.md's License headers rule)

Checked in workflow-canvas/ at f527b97: npm run lint, npm run typecheck, npm test (55 files, 949 tests) and npm run test:e2e (63 tests, against the stub) pass. By hand against npm run dev:stub in a browser: a real run followed from the Designer tab (the status was announced there from the live region), a failed read while the Designer tab was open (the alert region held the sentence and the run id), and the alert under the Run button at 700 px wide.

Tests added: the tab through App with a fake server and scheduler (idle, Run disabled in flight, each node going queued -> running -> done, a failed run, one alert for a refused start, the run continuing on the Designer tab, loading and failed-load states); the timer adapter with fake timers; state colour contrast and match with the theme module; e2e execution.spec.ts (a real run on the stub: draft Running -> Done, review Running -> Done, end Passed, with Run off in between; live region and node names; a failed stage; a refused run; a run that can no longer be followed; a run followed while the Designer tab is open; the goal kept across a switch of tab and read-only in flight, checked to fail on the earlier code; Enter in the goal box; a failure announced while the Designer tab is open) and axe checks of the Execution tab in accessibility.spec.ts, including the error of the API and a goal that cannot be run.

Screenshots

First-version Execution tab, full page, 1280x800 (generated by npm run screenshots; the runs in them answer with fixed replies, so they do not depend on timing), pinned to eb076d9757169e3d10551b81d49e1af15bc349dc:

Idle	Mid-run (first stage running)

Finished (passed)	Mid-run, dark theme

Checklist

• My code follows the style guidelines of this project (see AGENTS.md's Code Style & Conventions)
• I have performed a self-review of my own changes
• I have commented my code where necessary
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added or updated tests that prove my change works (see Testing above for the exact commands)

Notes for Reviewers

• Stacked on part 1, Read runs through the typed client and add the run core #115 (wc/06a-run-core). Eight commits (the first two are the original change; the others answer reviews). Following an active run, read retries and timeouts are in Read runs through the typed client and add the run core #115. Run the workflow from the Execution tab with live node states #93 is stacked on this PR and adds resume after reload.
• What to review: Execution.tsx and use-execution.ts wiring to the core, the node badges in nodes.tsx and canvas.css, and the move of the shared graph card and gate.
• The README text in this PR describes the tab as of this part; Run the workflow from the Execution tab with live node states #93 updates it for the later behaviour.

Fixes from the second adversarial review

• A warning above the graph names the stages of a run that are not in the graph and the graph stages that are not in the run (a workflow can be saved while a run goes on, and node states attach by name). Unit tests and an e2e test.
• Enter during an input method composition starts no run (unit test), also the Enter that Safari reports after the composition has ended (key code 229).
• The full-text list under the graph moved to the shared graph card, so the Execution tab shows it too.

Fixes from the third adversarial review

• The live status region stays empty on an error, as the alert says it all; "See the error below." showed nothing below on the Designer tab.
• An Enter with key code 229 starts no run (Safari). The stage notice says the file changed after the page loaded or after the run started, and tells the person to reload the page (see the last section).
• A start with no clear answer says "The run may not have started" and that Run joins it.
• A new workflow redraws the canvas on both tabs, so it is fitted again. The README says "Queued and Not run" differ in shape.
• Rebased onto the new wc/06a-run-core.

Fixes from the second hands-on QA run

• Opening another workflow during a run lets go of the run: the tab stops following it and clears its status, so the old run no longer sits over the new graph with Run off and a stage note that blames the file. The run itself goes on at its server. Chosen over blocking the paste because a run can take long and the launch code of a blocked paste is lost, as it works once.
• The stage note says to reload the page to draw the changed file. A reload keeps the session now (see Draw the workflow on the Designer tab with React Flow #83), so it works on a server whose launch code works once. Before, the note told the person to paste a fresh launch address.
• Tests: three for the change of workflow mid-run, and the note test checks that it says to reload.

Round 6

Rebased on #115 (the session guard and the page policy). No change of its own.

Round 9: rebased on #115. No change of its own. npm test (1043 tests), lint and typecheck pass.