Bug: ready-to-deliver goals missing from Kanban Queue/Ready/Blocked columns under Owner:Mine filter

[interactor-product-manager]

Integration PR for this goal — its tasks commit onto this branch (one PR per goal). Opened automatically by the engine on first push; left as a draft until the goal completes.

Delivery summary

What was built for this goal, assembled for review at delivery time.

Bug: ready-to-deliver goals missing from Kanban Queue/Ready/Blocked columns under Owner:Mine filter

BUG: on the Goals Kanban board (goals-kanban-view.tsx), with the "Owner: My goals" + "Hiding unassigned" filters active, goal G#592 ("Goals page: consolidate mobile toolbar...", id 7cda1426-78ba-4aeb-a687-8ff292b181cf) does not appear in ANY column -- Queue, Blocked, and Ready all render "0 / No goals matching filters", and Ready auto-collapses to its thin strip. Screenshots: ~/s/iScreen Shoter - 20260711172943593.jpg (Kanban board) and ~/s/iScreen Shoter - 20260711172948939.jpg (Approvals page, for contrast). Verified via the goal-detail API (GET /api/v1/me/engine/goals/7cda1426-...) that G#592 satisfies EVERY condition for the "ready to deliver" gate: status=open, prBoundary=true, prState=ready, deployGateState=passed, unresolvedMustFix=null, lastReviewedSha===prHeadSha (reviewed at head), mergeBlockedReasonKind=null, completion.complete=true, not paused. ownerId and createdById both match Peter's user (confirmed via createdByName="Peter Jung" in the API response), and ownerId is non-null, so it should pass both "Owner: My goals" and "Hiding unassigned". Yet other surfaces correctly recognize it as ready-and-Peter's: - Approvals "Needs Attention" page shows it as a "Ready to deliver" card with an Accept button, attributed to Peter Jung. - The Goals page's own right-sidebar "Awaiting acceptance" widget lists it correctly. - npm run engine:attention --all lists it as [ready] Goal #592 ... -- ready to deliver. So the bug is isolated to the Kanban board's filtered bucket/column computation specifically -- NOT the underlying goal state, and not every UI surface. Investigation starting points (goals-kanban-view.tsx): - hasActiveFilters(filters) (goals-view.ts ~line 721) correctly returns true here (owner!=="all" and !includeUnassigned both true), so the column count SHOULD fall back to the client-computed byColumn[col.key].length (from the loaded "active" goals array) rather than the possibly-stale DB aggregate (counts[col.key]) -- confirm this is actually happening. - Ready's "autoCollapse" derives its collapsed/expanded state purely from its OWN computed visible count (comment at ~line 796-853: "collapse when 0 ... filter-aware"). If that count is wrong (0 when it should be 1+), the column collapses and hides the "Load more" affordance (~line 1011-1027) that could otherwise reveal the goal -- a chicken-and-egg trap worth checking regardless of the root cause. - Queue and Blocked were NOT showing a "Load more" button in the screenshot (meaning hasMoreActive was false -- the client believes the full "active" goals set is already loaded), yet G#592 (status=open, i.e. part of the active/non-terminal set) is still missing from byColumn. That suggests the underlying "active goals" fetch/query itself may be excluding G#592 -- check whatever server query or hook populates the Kanban's active-bucket goals array (pagination page size, sort order, any owner/assignee predicate baked into the SERVER query that might not agree with the client-side "Owner: My goals" resolution), not just the client-side filter/column logic. - Consider whether this specifically affects VERY RECENTLY created/admitted goals (G#592 was created + queued today) -- e.g. a cache/rollup that hasn't been invalidated since creation (see the related, unmerged PR #1785 "Goals page server cost: scope per-page aggregates, bound goalComputeRollups" for a related caching angle, though that PR is about TTFB not correctness -- may or may not be connected). Quick repro for the investigating agent: log in as Peter, go to the Build project's Goals page (Kanban view), apply "Owner: My goals" (clear "Hiding unassigned" too if needed), and check whether G#592 (or G#593/594/595, its siblings, also created today) appear in Queue/Ready/Blocked. Also worth checking: does REMOVING the filters (Clear all) make it appear? That single experiment cleanly separates "client-side filter-matching bug" from "server-side active-goals fetch bug". Priority: high -- this misleads the goal owner about what needs their action on the primary work-tracking surface.

Branch: goal/bug-ready-to-deliver-goals-missing-from-kanban-queue-ready-b · PR: #1983

What shipped

• Plan: Bug: ready-to-deliver goals missing from Kanban Queue/Ready/Blocked columns under Owner:Mine filter (Planning)

Plan of record

Ready-to-deliver goal G#592 is missing from the Kanban Queue/Ready/Blocked columns under 'Owner: My goals' + 'Hiding unassigned'. Root cause is isolated to the Kanban's loaded active-goal set (not the goal state, which every other surface reads correctly). Decomposed into an implementation task that reproduces to pin the exact cause, fixes it, and adds a regression test.

Acceptance criteria

• eager-load-under-filter: When any facet filter is active (hasActiveFilters true) OR filters.search is set, useGoalsStore automatically keeps calling loadMore("active") until active.nextCursor === null, so the entire non-terminal active set is loaded client-side without manual 'Load more'.
• filtered-goal-beyond-page1-visible: A filter-matching active goal that sorts beyond the initially-loaded page (e.g. a freshly-created ready-to-deliver goal owned by the filtered user) becomes visible in its Kanban column, and that column's count is non-zero, once the eager-load completes under an active filter.
• eager-load-terminates-and-guards: The eager-load effect terminates when the active cursor is exhausted and never issues concurrent/duplicate loads for the same page (guarded by the existing loading flag / cursor state) — no infinite fetch loop.
• unfiltered-path-unchanged: With no facet filter and no search, the store does NOT eagerly fetch extra active pages: the initial paginated load, DB-accurate project-wide bucket counts, and manual 'Load more' behavior are unchanged (no extra fetch fires).
• ready-not-collapsed-mid-load: On the Kanban board, the Ready column does not auto-collapse to a thin strip while the filtered active set is still being fetched under an active filter (0 visible count during in-flight active pagination keeps Ready expanded); once loading settles it collapses/expands based on true visible count.
• desktop-unfiltered-byte-identical: With no active filter, the Kanban board's Ready auto-collapse and all column rendering at lg+ (desktop) remain byte-identical to the previous behavior.
• mobile-lane-counts-correct: Below-lg lane count chips reflect the corrected filtered membership (they use byColumn length under an active filter, which is now the full active set).
• typecheck-and-tests-pass: npm run typecheck passes and the goals test suites (goals-kanban-view.test.tsx and use-goals-view.test.ts) pass, including new coverage for the filtered eager-load, the unfiltered no-extra-fetch path, and Ready-not-collapsing-mid-load.

Review

0 of 1 review finding(s) resolved.

Commits

5338acfe82e23bd795994e7c05c5ef7b19238824…158bef6dfc3e347b8f0b207d6ff8442f1f8207c5 in InteractorOSS/product-manager