Skip to content

Keep Build waiting while a reopened decision needs an answer - #741

Open
MaggieAppleton wants to merge 1 commit into
mainfrom
maggieappleton-reopened-build-readiness-repair
Open

MaggieAppleton wants to merge 1 commit into
mainfrom
maggieappleton-reopened-build-readiness-repair

Conversation

@MaggieAppleton

Copy link
Copy Markdown
Collaborator

Symptom

Reopening a decided card shows it as needing an answer again in the Decisions tab and the sidebar, but Build readiness only blocked on decisions still in their first open state. A document with a reopened decision showed it waiting while Build plan, Build and Retry went ahead as if everything was settled.

Fix

implementationReadiness (apps/server/src/tasks/plan-graphs.ts) now uses the existing isOpenStatus helper, so a reopened decision blocks with "unanswered questionnaires" just like an open one.

Tests

  • New test in apps/server/src/tasks/plan-graphs.test.ts, run once per decision status. The status table is a Record<DecisionRecord["status"], boolean>, so adding a status fails to compile until someone decides whether it blocks Build. The test also checks that the server's stored-record unanswered count (unansweredDecisions) classifies the same statuses as waiting. Without the fix, only the reopened case fails.
  • bun test apps/server/src/tasks/plan-graphs.test.ts: 27 pass
  • bun test apps/server/src/tasks apps/server/src/questions apps/server/src/plan apps/server/src/agent/tools: 824 pass
  • bun run types: pass
  • bun run ci: pass

Review

Two adversarial reviews ran before this PR: one approved and one approved with nits. In response, the status table became exhaustive, the test is named after the rule it checks, and the unanswered-count assertion is explicitly limited to classifying statuses rather than claiming full parity between client and server.

Possible follow-up (out of scope): pastReadiness in apps/server/src/main.ts also checks only status === "open" when deciding whether a LIVE_BUILD document needs another readiness turn. As a result, a document whose only waiting decision is reopened may get an extra Planner turn. It affects scheduling, not Build readiness, so it is left alone here.

Reopening a decided card shows it as needing an answer again in the
Decisions tab and the sidebar, but Build readiness only blocked on
decisions still in their first "open" state. A document with a reopened
decision showed it waiting while Build plan, Build and Retry went ahead
as if everything was settled.

implementationReadiness now uses isOpenStatus, so a reopened decision
blocks with "unanswered questionnaires" like an open one. The test covers
every decision status through an exhaustive table, so a new status fails
to compile until someone decides whether it blocks Build. It also checks
that the server's stored-record unanswered count classifies the same
statuses as waiting.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant