• v1.6.9 b0e8368c1d

    nntrivi2001 released this 2026-09-17 09:17:53 +00:00 | 196 commits to main since this release

    A pipeline run is what you declared, and reload types two commands, not one

    A backwards DETECTION no longer opens a new pipeline run. runs is the denominator every rate on the Workflows page's pass-rate panel is read against, and until now any backwards move started one. Stage detection bounces by design — a single feature reads implement → tests → implement as the session edits, runs the suite and edits again — so one feature was recorded as five or six runs, and a lane in constant use reported a handful of passes scattered across dozens of phantom ones. A backwards move now opens a run only when it is declared (agenthub stage, or a codex lane's ingest-driven declaration); a backwards detection continues the run in flight. Reaching the pipeline's last 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 a 26-run history down to the 5 features that actually shipped through it.

    Nothing else about the panel moved: a pass is still a declaration, detections still render as the grey "reached, not declared" bar, and the GET /api/lanes/pipeline-stats payload is unchanged. If your lane's rates read low, that is the honest answer — a session that works without calling agenthub stage leaves detections, not passes.

    /reload-plugins and /reload-skills reach a pane as two commands again. They were typed back to back, and Claude Code opens its slash-command menu the moment / is typed, so the Enter that follows lands on that menu instead of submitting. The second command was appended to the line still sitting in the composer and the pane submitted the single string /reload-plugins/reload-skills — which Claude Code runs as /reload-plugins with an argument, so skills were never reloaded and a stray prompt turn was left in the scrollback. Reproduced and fixed against a live pane: the two sends are now a second apart (SETTLE_MS in server/lib/cc-reload.js), which makes reloadOpenSessions async rather than block the event loop for it, and the detached Update all worker got the same pause. POST /api/cc-config/reload therefore takes about a second longer to answer.

    Fixes #26 and #25.

    Downloads