Skip to content
Motir
Start free

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-1495Done

Planned-sprint committed-points badge goes stale after moving an item out — useSprintPoints never re-fetches

Verified against shipped motir-core — my first-draft diagnosis was WRONG in two ways; corrected here (rung-2 check).

Reality — two different "committed" computations

  • Planned / backlog sprint (the real bug): committed points is computed ON-READ (no stored counter) — estimationService.rollupForSprint → workItemRepository.sumPointsForSprint (lib/services/estimationService.ts:162-173), served by GET /api/sprints/[id]/points. The UI hook useSprintPoints (app/(authed)/backlog/_components/useSprintPoints.ts:20-34) fetches ONCE (deps [sprintId, enabled]) and never re-fetches on issue changes. The move-out path (moveItemsToBacklog/moveItemsToSprint → executeBulk, BacklogDndProvider.tsx:434-447) only updates the issue-count badge (adjustSprintCount, BacklogContainer.tsx:127-131); nothing re-runs useSprintPoints. → the committed-points badge (SprintPointsBadge, SprintContainer.tsx:160) stays STALE until a full page reload. This is client-side cache staleness, NOT a stored-counter / concurrency bug — there is no counter to decrement, so the earlier "lock the row, decrement" framing was fabricated and is removed.
  • Active sprint (NOT a bug): sprint.committedPoints IS a stored Decimal, but it is stamped once at activation as an immutable scope-lock baseline (sprintsService.ts:371-382, documented immutable at :619) — Jira-style scope lock. Removing an item intentionally does NOT change it. Do not "fix" this.

Fix (motir-core, UI only)

Make the planned-sprint committed-points badge re-fetch when its membership changes: thread the existing issuesRefreshKey / reloadKey into useSprintPoints' deps (or invalidate it from the move path), so the badge recomputes after a move / add / point-edit. Leave the active-sprint committedPoints snapshot untouched.

Acceptance criteria

  • Moving/removing an item out of a PLANNED sprint updates its committed-points badge without a page reload; adding + in-sprint point-edit likewise.
  • The ACTIVE sprint's scope-lock committed baseline is unchanged (a test asserting it stays fixed).
  • Reproduce first (reproduce-before-diagnosing): a failing test that moves an item out of a planned sprint and asserts the badge dropped.

Context refs

  • On-read compute lib/services/estimationService.ts:162; hook useSprintPoints.ts:20; consumer SprintContainer.tsx:102,160; move path BacklogDndProvider.tsx:434 + BacklogContainer.tsx:127; immutable active snapshot sprintsService.ts:371,619.