6df69d8811
A pipeline template named ONE command for the whole run (`skill`), so the only way to know what actually moves a given node was to read that node's `detect` regexes. Each node now carries its own `command`: a slash command (`/superpowers:writing-plans`) or a shell one (`ccam lanes hook ci-gate`), whichever its detect rules already watch for. The values are derived from each node's own detect rules, not invented — every `ccam …` string was checked against bin/ccam.js and every `/superpowers:*` against the installed plugin. Nodes reaching which is a declaration rather than an action (`done`, `merged`, `reported`, `e2e-feature-passed`, `qc-plan`) are deliberately left empty. `pipelines.js` normalizes a missing or non-string value to "", so a custom template written before this field keeps loading rather than rendering "undefined". `nodeStates()` and GET /api/lanes/pipeline-stats pass it through. Never executed by the dashboard — display text, the same contract `skill` already had. Surfaced where each view has room for it: the Workflows pass-rate panel shows it under the node label and copies it on click; PipelineMap folds it into the node tooltip, because a 16-node pipeline has to fit across one card and there is no width for a second line. `command?: string` is optional in the client type only to spare four unrelated test fixtures — the server always sends the key, and the UI has to branch on the empty string regardless. Verified: npm run test:server (1373, +3), npm run test:client (459, +2), tsc --noEmit, prettier and check-headers clean. docs/LANES.md § Custom template format documents the field. openapi.yaml needs no change: the lane payload and pipeline-stats were never schematized there.
74 lines
3.5 KiB
TypeScript
74 lines
3.5 KiB
TypeScript
/**
|
|
* @file The lane pipeline map: a horizontal chain of stage nodes coloured by
|
|
* state. Layout is computed from the node list (flex + connectors), never from
|
|
* hardcoded coordinates, so a lane can use a longer or shorter template without
|
|
* touching this component. Every state but `current` shares one visual
|
|
* language — coloured border, coloured text, a translucent wash of the same
|
|
* colour — so status colour means the same thing everywhere in the app, not
|
|
* a different shade per component. `current` is the sole solid fill, in the
|
|
* app's own accent colour: the one state that gets to look bolder than the
|
|
* rest, because it answers "where am I right now". "passed without
|
|
* evidence" is its own colour: a stage the agent claimed but left no
|
|
* artifact for is not the same as a stage that is genuinely done. A
|
|
* `detected` node (the server's heuristic saw tool-event evidence but the
|
|
* agent never declared it) gets a FOURTH treatment — thin dashed warning,
|
|
* no fill — because it must never be mistaken for a real declaration.
|
|
* @author Nguyễn Ngọc Trí Vĩ <vinnt@smartgift.vn>
|
|
*/
|
|
|
|
import type { LaneNode } from "../../lib/types";
|
|
|
|
const STATE_CLASS: Record<LaneNode["state"], string> = {
|
|
done: "border-status-success/60 text-status-success bg-status-success/10",
|
|
current: "border-accent bg-accent text-white ring-2 ring-accent/30 shadow-sm",
|
|
"passed-no-evidence": "border-status-warning/60 text-status-warning bg-status-warning/10",
|
|
failed: "border-status-danger/60 text-status-danger bg-status-danger/10",
|
|
pending: "border-border-light text-fg-muted bg-transparent",
|
|
};
|
|
|
|
// Thin dashed border and no fill keep an inference visually lighter than
|
|
// every outlined state above — so it never reads as more certain than a claim.
|
|
const DETECTED_CLASS = "border-dashed border-status-warning/50 text-status-warning bg-transparent";
|
|
|
|
export default function PipelineMap({
|
|
nodes,
|
|
detectedSignal,
|
|
}: {
|
|
nodes: LaneNode[];
|
|
detectedSignal?: string | null;
|
|
}) {
|
|
if (!nodes.length) return <div className="text-xs text-fg-muted">no pipeline</div>;
|
|
return (
|
|
// The map spans the panel: every node takes an equal share and the
|
|
// connectors absorb the slack, so the pipeline reads as one track across
|
|
// the width rather than a short cluster hugging the left edge.
|
|
<div className="flex w-full items-center py-1">
|
|
{nodes.map((n, i) => (
|
|
<div key={n.id} className="flex min-w-0 flex-1 items-center">
|
|
<div
|
|
data-testid={`pipeline-node-${n.id}`}
|
|
data-state={n.state}
|
|
data-detected={n.detected ? "true" : undefined}
|
|
// The node's driver command rides along in the tooltip rather than
|
|
// on the pill: the map has to fit a 16-node pipeline across one
|
|
// card, so there is no width for a second line of text.
|
|
title={[
|
|
n.detected && detectedSignal
|
|
? `${n.label} ← ${detectedSignal}`
|
|
: `${n.label} — ${n.state}`,
|
|
n.command ? `→ ${n.command}` : null,
|
|
]
|
|
.filter(Boolean)
|
|
.join("\n")}
|
|
className={`flex min-w-0 flex-1 items-center justify-center gap-1.5 rounded-full border px-2 py-1.5 text-[11px] ${n.detected ? DETECTED_CLASS : STATE_CLASS[n.state]}`}
|
|
>
|
|
<span className="shrink-0 text-[13px] leading-none">{n.icon}</span>
|
|
<span className="truncate">{n.label}</span>
|
|
</div>
|
|
{i < nodes.length - 1 && <div className="h-px w-2 shrink-0 bg-surface-3 sm:w-3" />}
|
|
</div>
|
|
))}
|
|
</div>
|
|
);
|
|
}
|