fix(dock): auto-close after short-lived processes (<125ms)

[378-kaiabot]

Note

Automated pull request by Pi, model `radius/glm-5.2`. Implemented and validated empirically against aliou/pi-processes on branch main (published @aliou/pi-processes@0.10.9 == cited commit 550b2e9 for the hasSeenRunningProcess logic), using real Pi 0.84.2, an instrumented event-logger extension, and Herdr. See the local run log for the full investigation.

Problem

The process dock does not auto-close after a very short-lived process (one that exits within the 125ms scheduleRefresh throttle window) on a fresh session.

hasSeenRunningProcess — the session-lifetime flag that gates the auto-close condition in hardRefresh — was set only inside hardRefresh, which runs ~125ms after CHANNELS.STARTED due to the scheduleRefresh throttle, and only when a process is still running at that moment. If the process exits before that first hardRefresh runs, the flag is never set, so the close condition (hasSeenRunningProcess && processes.every(!LIVE_STATUSES)) is always false and state.actions.close() never fires. The registry does not prune finished records, so the processes.length === 0 branch doesn't help either — the dock stays open showing the finished process.

Scenario	Before	After
Short-lived true (9–110ms), fresh session	dock stuck visible	dock auto-closes hidden
Long-lived sleep 3 (3014ms), fresh session	dock opens → auto-closes	dock opens → auto-closes (unchanged)

A subtlety confirmed during validation: the bug only manifests on a fresh session with a sub-125ms first process. Once any process lives ≥125ms, the flag is set for the session and later short processes auto-close fine — which is why this is easy to miss in casual testing.

Fix

extensions/processes-dock/widget/setup.ts — set hasSeenRunningProcess = true synchronously in handleStarted (the CHANNELS.STARTED handler), before any throttle delay, in addition to the existing set-site in hardRefresh. handleStarted fires synchronously when a process starts, so the flag is set before the process can exit, letting the auto-close condition fire on the subsequent END refresh even for sub-125ms processes.

Why not only set it in handleStarted: keeping the hardRefresh set-site is harmless and defensive — hardRefresh also runs from refresh() and the initial setup call, and there is no guarantee a STARTED event is the only path to a running process appearing in the list.

Verification

• pnpm typecheck ✅
• pnpm lint ✅ (202 files, no fixes)
• pnpm test ✅ (640 passed, 62 files — includes the new setup.test.ts regression tests)
• pnpm check:changesets ✅ (5 changesets)
• pnpm check:schema ✅ (schema.json up to date)
• pnpm check:lockfile ✅

End-to-end (real Pi 0.84.2 + published @aliou/pi-processes@0.10.9 patched in-place + instrumented event-logger extension, dockDefaultState: "collapsed"):

• Fresh session, single true (STARTED→ENDED = 9.2ms): dock auto-closed (stayed hidden; close() fired at the 125ms hardRefresh). Before the fix, a 110.3ms true left the dock stuck visible with 0 hidden transitions.
• Fresh session, sleep 3 && echo done (3014ms): dock hidden → visible (collapsed) → hidden — opens during the run, auto-closes after. No regression.

Closes #86

---

Run host: `jovial-vis-telimus` · Session: `01a02935-00f6-7976-962a-1662ddf87923` · Model: `radius/glm-5.2`