forEach steps should show step name in tree view, not just model→method

[keeb]

Problem

When using forEach to expand steps in a workflow, the live tree view shows the same model → method label for every expanded step. For example, a workflow testing 13 extensions with forEach shows:

test
  ├─ tester → smokeTest    ∴ 1.9s
  ├─ tester → smokeTest    ∴ 1.9s
  ├─ tester → smokeTest    ∴ 1.9s
  ...

The step names ARE distinct (test-alpine, test-discord, etc.) and appear correctly in --json output, the workflow summary report, and data artifacts. But the tree view only renders modelName → methodName, making it impossible to tell which step is which during execution.

Current workaround

Create a separate model instance per iteration (e.g., test-alpine, test-discord, test-github, ...) instead of using forEach with a single model. This makes the tree show:

test
  ├─ test-alpine → smokeTest     ∴ 1.9s
  ├─ test-discord → smokeTest    ∴ 1.9s
  ├─ test-github → smokeTest     ∴ 1.9s
  ...

This works but requires N model definitions for N iterations, defeating the purpose of forEach.

Proposed solution

The tree view renderer should include the step name (or the resolved forEach variable) in the label. For example:

test
  ├─ test-alpine: tester → smokeTest    ∴ 1.9s
  ├─ test-discord: tester → smokeTest   ∴ 1.9s

Or use the step description if available.

Affected components

• Tree view rendering in the workflow execution display
• The step label formatter that currently uses modelName → methodName

The --json output and report system already have the correct step names — this is purely a tree view rendering issue.

[stack72]

🔍 Triage started — fetching issue context

[stack72]

📋 Classified as feature (high) — This is a tree view rendering issue. The step_started event carries the expanded stepId (e.g. 'test-alpine') but once model_resolved fires, the label switches to 'modelName → methodName' (e.g. 'tester → smokeTest'), losing the step name. The fix is to include the step name prefix in the label when the step ID differs from the modelName.

[stack72]

📝 Implementation plan generated (v1) — Include step name as a prefix in the tree view label when it differs from modelName. Change the label from 'modelName → methodName' to 'stepId: modelName → methodName' for forEach-expanded steps where the stepId (expanded step name) is distinct from the model name.

[stack72]

Approved Implementation Plan (v1)

Summary: Include step name as a prefix in the tree view label when it differs from modelName. Change the label from 'modelName → methodName' to 'stepId: modelName → methodName' for forEach-expanded steps where the stepId (expanded step name) is distinct from the model name.

DDD Analysis

This is a pure presentation-layer change. The domain already correctly propagates step names (expandedName) through events as stepId. The StepState in the tree reducer already stores step.id. The only change needed is in the label construction logic in the presentation components (step_line.tsx, job_line.tsx) and the scrollback graduation (state.ts).

Implementation Steps

1. Change the label construction in step_line.tsx and job_line.tsx to prefix the step ID when it differs from modelName. Format: 'stepId: modelName → methodName'. This preserves the step name (which is the forEach-expanded name like 'test-alpine') while still showing model and method info.
2. Update the scrollback singleStepLabel and ScrollbackOutputSection to also include the step name prefix when applicable, for consistency in graduated (completed) job display.
3. Update existing tests in state_test.ts and add a new test for forEach-expanded step label rendering to verify the step name prefix appears correctly.

Files

• src/presentation/renderers/workflow_run_tree/components/step_line.tsx
• src/presentation/renderers/workflow_run_tree/components/job_line.tsx
• src/presentation/renderers/workflow_run_tree/state.ts
• src/presentation/renderers/workflow_run_tree/state_test.ts

Testing Strategy

Update existing state_test.ts tests for label assertions. Add a focused test that simulates forEach-expanded step events where stepId differs from modelName and verifies the label includes the step name prefix.

Potential Challenges

• Need to determine the right heuristic for when to show the step name prefix — only when stepId !== modelName, to avoid redundant labels like 'create: ec2-instance → create' for non-forEach steps where the step name matches the model name

Approved via swamp @si/issue-lifecycle