Decisions-settled gate ignores the blocking flag — revisit the contract #19

New issue

Open

opened 2026-08-11 14:57:24 +00:00 by jbr870 · 1 comment

jbr870 commented

2026-08-11 14:57:24 +00:00

Owner

Observed failure

The decisions-settled gate blocks on every open Pending Decision regardless of its blocking flag.
On verity #112 that meant 12 self-answered dispositions plus a needless human round-trip before work
could continue.

Why it is not an obvious fix

The gate was made strict deliberately: tests and fixes must run against a settled in-scope set, and
"what are we fixing this round" has no answer while dispositions are open. Honouring blocking: false
would let a round start with its scope still moving — which is the failure the strictness prevents.

So loosening it means re-arguing the QA-loop ordering, not just reading the flag. Questions to settle:

Is blocking: false meaningful at all for a scope-disposition, or only for other decision types?
If a non-blocking disposition is unresolved when the tests stage starts, what is the in-scope set — and
what happens to the finding when it later resolves fix-now?
Does the answer differ by phase boundary (/develop entry vs the QA round's tests stage)?

Pairs with the /resolve batch-mode issue — 13 mechanical dispositions being a blocker is what makes
clearing them one-by-one painful. Fixing either reduces the pain; fixing both is the real answer. Worth
designing together.

Source: dogfood retrospective 2026-08-07, deferred backlog.

## Observed failure The decisions-settled gate blocks on **every** open Pending Decision regardless of its `blocking` flag. On verity #112 that meant 12 self-answered dispositions plus a needless human round-trip before work could continue. ## Why it is not an obvious fix The gate was made strict **deliberately**: tests and fixes must run against a *settled* in-scope set, and "what are we fixing this round" has no answer while dispositions are open. Honouring `blocking: false` would let a round start with its scope still moving — which is the failure the strictness prevents. So loosening it means re-arguing the QA-loop ordering, not just reading the flag. Questions to settle: - Is `blocking: false` meaningful *at all* for a `scope-disposition`, or only for other decision types? - If a non-blocking disposition is unresolved when the tests stage starts, what is the in-scope set — and what happens to the finding when it later resolves `fix-now`? - Does the answer differ by phase boundary (`/develop` entry vs the QA round's tests stage)? ## Related Pairs with the `/resolve` batch-mode issue — 13 mechanical dispositions being a *blocker* is what makes clearing them one-by-one painful. Fixing either reduces the pain; fixing both is the real answer. Worth designing together. *Source: dogfood retrospective 2026-08-07, deferred backlog.*

jbr870 referenced this issue

2026-08-11 14:57:37 +00:00

/resolve: batch mode for N decisions, without weakening per-decision rationale #14

jbr870 commented

2026-08-11 14:57:37 +00:00

Author

Owner

Pairs with #14 — see the note there.

jbr870 referenced this issue

2026-08-13 13:05:29 +00:00

decisions: no withdraw/supersede path — mooted blocking decisions stay open until something trips over them #36