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-1328Done

Readiness calc counts ARCHIVED items as open blockers — archived node phantom-gates its dependents out of the ready set

Bug: The ready-set / readiness computation counts archived work items as open blockers. An archived item is a soft-removed (superseded) node and must be excluded from openBlockers, but it currently still gates its dependents — holding them out of the ready set indefinitely.

Surfaced: during Sprint 32 composition (7.20/7.6/7.4). After the 7.19→7.20 re-plan archived MOTIR-1012 (7.19.4, archivedAt set), it remained a blocked_by edge on MOTIR-1013 (7.20.6) and MOTIR-1015 (7.20.8). Both showed readiness.ready=false with MOTIR-1012 present in openBlockers despite being archived — which would have held the 7.20 progress-cluster + E2E (the story's exit) out of the ready set forever.

Workaround already applied: the two stale edges were manually unlinked so Sprint 32 is internally executable. This bug tracks the ROOT cause so the next re-plan that archives a blocker doesn't silently mis-gate again.

Root-cause hypothesis: the readiness query that collects an item's blockers (feeding get_work_item.readiness.openBlockers, list_ready, next_ready, and the board's ready column) joins blocked_by links without an archivedAt IS NULL filter on the blocker item.

Fix: in the ready-set computation (Repository layer), exclude blockers whose archivedAt is non-null — an archived blocker no longer holds an item out of the ready set. Apply uniformly to every consumer of the computation: get_work_item readiness, list_ready, next_ready, and the board ready column, so they agree.

Acceptance criteria:

  • An item blocked_by an archived item (no other open blockers) computes readiness.ready=true and does NOT list the archived item in openBlockers.
  • A non-archived blocker still gates exactly as today (no regression).
  • list_ready / next_ready / get_work_item.readiness / the board ready column all agree on the archived-blocker case.
  • Regression test: create A blocked_by B, archive B, assert A is ready and B is absent from A's openBlockers.