Repository navigation
fix(orchestrator): SDLC Frame hands a TBD-laden spec to Deliver unchecked #625
Description
Activity
- added a commit that references this issue
on Aug 14, 2026 - added a commit that references this issue
on Aug 14, 2026 - added a commit that references this issue
on Aug 14, 2026 Closing as covered, not as delivered: the behaviour this asks for already holds, and the gate was measured to change nothing. No code ships.
The issue's own acceptance criterion is spent. It asks that the spec validate with "no residual
TBD:in a required section". #626 made a marker in a required section invalid by construction, and settled the other half: an open question leaves a spec valid, because a drafter lists two or three the contract does not depend on (the CSV column set, when a retention window starts) and refusing those refused complete work. So a gate here cannot read "the spec is invalid". It can only read "a decision is open".That gate was written, and then measured as a no-op. One sentence was added to
01-frame.md:A contract carrying a decision nobody has taken is one this zone cannot proceed from.
A/B against the same tree with and without it, 6 runs per arm, the zone read from a build produced by
aidd translate:Contract with the sentence without it declares two open decisions stop 3/3 stop 3/3 declares Nonedeliver 3/3 deliver 3/3 Identical. The reasons given in the arm without the sentence say why: "not planning-ready", "Contract is planning-ready: names artifact, observable outcome, no open questions". Two rules already cover it, and a reader applies them to the contract unprompted:
01-frame.md— "A source is planning-ready when it names the artifact to change, states the observable outcome, and leaves open no decision that changes what is built." Written about$source; readers apply it to$contract.SKILL.md— "A zone that cannot proceed stops the run and says what it would take to resume."references/mode.md— ask before "making a decision that requires user authority", and "An exception stops the action it guards, not the rest of the request."
Writing the gate explicitly therefore adds a fourth statement of the same rule, which is the duplication this skill has just spent a pass removing. It was reverted.
What is not proved. Two contract shapes, one model, 6 runs per arm. A contract declaring
Nonewhile genuinely hiding an undecided requirement would be the case where the sentence could earn its place; the second shape above did not reproduce one, because a spec that answers everything inside its own frame is legitimately ready. Reopen with such a contract and the gate becomes worth writing.The observed behaviour in the report — "
01-frame.md's mermaid goes straight fromSpectoContracttoDeliver, unconditionally" — stays true of the diagram, and deliberately: no zone in this skill models a stop, neither Deliver nor Check, so drawing one here would read as this zone inventing its own control flow.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Projects
- StatusShow more project fieldsDone
Description
aidd-orchestrator:01-sdlc's Frame stage produces$contractvia/aidd-pm:04-specand hands it straight to Deliver, with no check that the spec it just wrote actually validates. A spec with residualTBD:markers in a required section (hard constraints, non-goals, done-when) is already invalid perspec-validator.yml's own definition (any_required_unfulfilled: invalid, constraints must be "concrete and testable, not vague") — but nothing in01-frame.md's flow consults that validator before treating the spec as a finished$contract.Found while dogfooding
04-spec(post-#564 router migration) on a real project:buildcorrectly marked 3 genuine open questions (platform, sharing model, ingredient source) asTBD:, lifted straight from the source PRD's own Dependencies/Open Questions. That's04-specworking as designed. But SDLC runs autonomously ("decide and act without confirmation, asking only before... a decision that requires user authority") — platform/sharing-model choices are exactly that kind of decision, yet nothing wires the TBD count to SDLC's own pause condition. A TBD-laden spec can silently flow into02-deliver's Plan → Implement, building against undecided requirements.Affected file(s)
plugins/aidd-orchestrator/skills/01-sdlc/references/01-frame.mdExpected behaviour
Before
Spec --> Contractin01-frame.md's flow, the spec must validate againstspec-validator.yml(no residualTBD:in a required section). A spec that doesn't validate should route back to clarification (matching the "decision that requires user authority" pause SDLC already claims to honor) rather than continuing to Deliver.Observed behaviour
01-frame.md's mermaid goes straight fromSpectoContracttoDeliver, unconditionally. No validation gate, no reference tospec-validator.ymlanywhere in the SDLC skill.AI tool
Claude Code
OS
macOS
Additional context
Surfaced during
#564's04-specrouter-contract migration (out of scope there — different plugin, no behaviour change allowed in that issue).spec-validator.ymlitself is sound; the gap is purely that nothing in the orchestration layer consults it.