Summary
While the /jobs panel is open, incoming jobs/updated notifications update the :jobs state slice but not the visible panel. New/killed/status-changed jobs are not reflected until the panel is closed and reopened. This defeats the push-driven design premise (Phase 11b plan, AC9: "UI updates on next jobs/updated").
Surfaced by /review-changes (both Standards + Spec axes) on #3, and overlaps a Copilot low-confidence comment (jobs.clj:105).
Root cause
cmd-open-jobs-panel snapshots jobs into :picker (:all / :filtered / :list) at open time. render-jobs-panel-lines renders from :picker :filtered, but handle-jobs-updated only does (assoc state :jobs by-id) — it never refreshes :picker. So the render path reads a stale snapshot.
;; jobs.clj — handle-jobs-updated
[(assoc state :jobs by-id) nil] ; :picker :filtered untouched
Related smells (same root cause)
- Vestigial
cl/item-list labels — panel-row-label builds ·-separated labels the render path ignores; only the selection index is used. The spec's · row separator (AC6) therefore never renders.
- The list component's only real job is holding the selection index.
Fix options
- Refresh
:picker in handle-jobs-updated when a :jobs panel is open, preserving the current selection index.
- Render live from
(jobs-vec state) and drop the cl/item-list snapshot entirely, tracking selection as a clamped :sel-idx in the picker. Also removes the vestigial labels and restores the · separator.
Option 2 is the cleaner end state but a larger change.
Also noted nearby (optional cleanup)
protocol/jobs-list! is dead code (push-only design; never called).commands/cmd-open-jobs-panel is a pure pass-through to jobs/cmd-open-jobs-panel; the /mcp registry row references its handler directly.
Summary
While the
/jobspanel is open, incomingjobs/updatednotifications update the:jobsstate slice but not the visible panel. New/killed/status-changed jobs are not reflected until the panel is closed and reopened. This defeats the push-driven design premise (Phase 11b plan, AC9: "UI updates on nextjobs/updated").Surfaced by
/review-changes(both Standards + Spec axes) on #3, and overlaps a Copilot low-confidence comment (jobs.clj:105).Root cause
cmd-open-jobs-panelsnapshots jobs into:picker(:all/:filtered/:list) at open time.render-jobs-panel-linesrenders from:picker :filtered, buthandle-jobs-updatedonly does(assoc state :jobs by-id)— it never refreshes:picker. So the render path reads a stale snapshot.Related smells (same root cause)
cl/item-listlabels —panel-row-labelbuilds·-separated labels the render path ignores; only the selection index is used. The spec's·row separator (AC6) therefore never renders.Fix options
:pickerinhandle-jobs-updatedwhen a:jobspanel is open, preserving the current selection index.(jobs-vec state)and drop thecl/item-listsnapshot entirely, tracking selection as a clamped:sel-idxin the picker. Also removes the vestigial labels and restores the·separator.Option 2 is the cleaner end state but a larger change.
Also noted nearby (optional cleanup)
protocol/jobs-list!is dead code (push-only design; never called).commands/cmd-open-jobs-panelis a pure pass-through tojobs/cmd-open-jobs-panel; the/mcpregistry row references its handler directly.