chore(workflow): audit and polish step-graph and stepper family (CL-8484)

[TheGreatAxios]

Audit: workflow family vs AI Elements Task/Stepper (CL-8484)

Scope: src/ui/step-graph.tsx, step-graph-node.tsx, horizontal-stepper.tsx,
step-list.tsx, step-primitives.tsx, workflow-status-badge.tsx,
src/lib/chart-geometry.ts, src/lib/step-graph-layout.ts. Compared against
Vercel AI Elements' Task/Stepper (ai-sdk.dev/elements) and
agent-elements.21st.dev, used as inspiration only — nothing here is a port.

Branching

StepGraph accepts an arbitrary edges prop (any from/to pair, not just
a sequential chain), but computeStepGraphLayout in step-graph-layout.ts
positions nodes purely by array index along one axis. Two steps that could
run in parallel (a fan-out) are still stacked one after another in a straight
line — the connectors can point anywhere, but the geometry can't express two
nodes sharing a "rank." This is strictly less than agent-elements.21st.dev's
workflow view, which lays out branches as parallel columns.
Not fixed here — a rank-based layout is layout-engine work, not polish.
Added a Branching story to step-graph.stories.tsx to make the current
behavior (edges draw, layout doesn't fork) visible and testable.

Status vocabulary

Interchange's canonical run vocabulary, as the Workbench consumer uses it
(workflow-run.ts's RunStatus, mirrored in apps/web/src/routines-api.ts
and pages/routines-page.tsx's consumption of it):

provisioning | running | awaiting | completed | failed | stopped

The workflow family currently has four different vocabularies for the
same underlying states, none of which match RunStatus directly:

Type	Values
StepGraphNodeStatus (step-graph-node.tsx)	pending | running | completed | failed
WorkflowStepStatus (workflow-run-progress.ts, used by horizontal-stepper)	completed | current | pending | failed
StepDisplayStatus (workflow-registry.ts, used by step-list.tsx)	pending | active | done | failed
StepPhase (workflow-run-progress.ts)	pending | in-flight | awaiting-signal | awaiting-timer | completed | failed

WorkflowStatusTone (running \| awaiting \| done \| paused \| fail) is a
deliberate coarser layer per its own doc comment, which is fine. But none of
the four step-level vocabularies above model stopped (a cancelled run),
and each spells "in progress" and "done" differently for no functional
reason (running/current/active/in-flight, completed/done). A
consumer wiring a real run through more than one of these components has to
hand-roll a different mapping from RunStatus for each one, with no shared
helper.
Not fixed here — reconciling four public prop types is a breaking,
cross-cutting change.
Proposed follow-ups (I will file):

• Add small RunStatus → mapping helpers (e.g. runStatusToStepPhase,
  runStatusToWorkflowStepStatus) next to workflow-run.ts so a Workbench
  screen doesn't reinvent the mapping per component.
• Decide whether a stopped/cancelled run gets a distinct terminal step
  glyph, or is intentionally folded into a step's last-known phase.

Density

StepGraph has compact/expanded; HorizontalStepper has one density
with a hard 5-step threshold that switches to number-only pills. The naming
doesn't line up (no density prop on the stepper) but the underlying
behavior is reasonable for each component's use case. Low-value to unify;
not fixed.

Reduced motion

Verified, not a gap: theme.css's @media (prefers-reduced-motion: reduce)
block (theme.css:562) collapses every animation/transition duration to
0.01ms globally, so StatusDot's live pulse and HorizontalStepper's
rail-fill transition already still correctly for a reduced-motion viewer.
HorizontalStepper additionally guards its pulse with motion-safe:, which
is redundant given the global rule but harmless. No fix needed.

Story coverage

Fixed in this PR:

• step-graph.stories.tsx: added Branching, a fan-out/fan-in edge set
  over the existing linear step list (see Branching section above for what
  it does and doesn't demonstrate).
• workflow-status-badge.stories.tsx: new — this component had zero
  stories. Renders all five WorkflowStatusTone values.
• step-primitives.stories.tsx: new — this component had zero stories.
  Renders the compound API's horizontal and vertical orientations.

Checks

bun run typecheck, bun run lint, bun test (336 pass), bun run build
(SWC + tsc + Tailwind + contrast gate) all green.

Not merging — for review.

[TheGreatAxios]

Review

Verdict: approve. Stories/audit only. Body documents branching layout and status-vocab gaps as not fixed — honest. No CI. No prior reviews.

[TheGreatAxios]

Review (Draper + Emil)

Verdict: approve. Stories only. Copy is on-voice.

Nit: story titled Branching still lays nodes in one line. Rename to what it shows, or don’t call it Branching until layout forks. Not blocking.

[TheGreatAxios]

Stories-only chore, fine to merge — but the Branching story documents a real limitation, not just a demo: edges changes which connectors draw but not where nodes sit, so the graph can render a DAG's edges yet can't lay out a DAG. Worth filing as an issue rather than letting a story comment be the only record of the gap.

[TheGreatAxios]

Re-review

Story export Branching → LinearDagEdges. SHA 30d359e. bun test 336 pass.

[TheGreatAxios]

Closing — this PR's entire surface is gone. It only edited stories/workflow/step-graph.stories.tsx, step-primitives.stories.tsx, and workflow-status-badge.stories.tsx, and all three subjects were deleted by the consumer-usage prune (#55): no consumer imported them, so they are no longer part of the package.

The useful observation in this PR — that StepGraph drew DAG edges over a linear node layout — is moot now that the component is gone. If a graph surface comes back, layout-by-edges should be a design requirement from the start, not a polish note.