fix(lanes,reload): count a pipeline run by declarations, and stop the two reload commands merging

Closes #26, #25.

`runs` is the denominator every pass rate on the Workflows page is read
against, and any backwards move opened a new one. Stage detection bounces by
design — one feature reads `implement → tests → implement` as the session
edits, runs the suite and edits again — so a single feature was recorded as
five or six runs, and a lane in constant use reported a handful of passes
spread across dozens of phantom runs. A backwards move now opens a run only
when it is DECLARED; a backwards detection continues the run in flight.
Reaching the final node still closes the run for either, since work after
`done` is new work however it was observed. Replayed over this repo's own lane
the rule takes 26 recorded runs down to the 5 features that actually shipped
through it. The panel itself is unchanged: passes are still declarations only.

`/reload-plugins` and `/reload-skills` were typed back to back. Claude Code
opens its slash-command menu the moment `/` is typed and the Enter that follows
lands on that menu, so the second command was appended to the line still in the
composer and the pane submitted `/reload-plugins/reload-skills` — which Claude
Code runs as `/reload-plugins` with an argument, never reloading skills, and
leaving a stray prompt turn in the scrollback. Reproduced and fixed against a
live pane: SETTLE_MS (1s) between the two sends, which makes
`reloadOpenSessions` async rather than block the event loop, and the same pause
in the detached update-all worker.
This commit is contained in:
2026-09-17 16:01:59 +07:00
parent 02ee46c862
commit 686b80bd99
11 changed files with 132 additions and 35 deletions
+13 -4
View File
@@ -398,9 +398,17 @@ function reservedPorts(excludeLaneId = null) {
*
* The run a row belongs to is decided here rather than stored on the lane, so
* there is one rule and no column to fall out of sync. A new run starts when
* the lane moves BACKWARDS (the next feature begins at plan) or when the last
* event sat on the pipeline's final node (the previous feature finished). Any
* other move continues the run in flight.
* the lane is DECLARED backwards (the next feature begins at plan) or when the
* last event sat on the pipeline's final node (the previous feature finished).
* Any other move continues the run in flight.
*
* Only a declaration may open a run by going backwards. Detection bounces by
* design — one feature reads `implement → tests → implement` as the session
* edits, runs the suite and edits again — so counting every backwards detection
* as a new run recorded a single feature as five or six of them, and `runs` is
* the denominator the Workflows page reads every pass rate against. A pass ends
* where the session says it ends. Reaching the final node still closes the run
* for a detection too: work after `done` is new work however it was observed.
*
* Never throws: a lane's stage must still advance if this log cannot be
* written — the dashboard losing a statistic beats an agent's pipeline dying.
@@ -415,7 +423,8 @@ function appendStageEvent(lane, nodeId, { source, result, evidence } = {}) {
if (last) {
const lastIdx = phaseIdx(pipeline, last.node_id);
const nextIdx = phaseIdx(pipeline, nodeId);
const wentBack = lastIdx > -1 && nextIdx > -1 && nextIdx < lastIdx;
const declared = source !== "detected";
const wentBack = declared && lastIdx > -1 && nextIdx > -1 && nextIdx < lastIdx;
const finished = lastIdx > -1 && lastIdx === pipeline.nodes.length - 1 && nextIdx !== lastIdx;
runSeq = last.run_seq + (wentBack || finished ? 1 : 0);
}