Skip to content

fix(orchestrator): SDLC Frame hands a TBD-laden spec to Deliver unchecked #625

Description

@blafourcade

Description

aidd-orchestrator:01-sdlc's Frame stage produces $contract via /aidd-pm:04-spec and hands it straight to Deliver, with no check that the spec it just wrote actually validates. A spec with residual TBD: markers in a required section (hard constraints, non-goals, done-when) is already invalid per spec-validator.yml's own definition (any_required_unfulfilled: invalid, constraints must be "concrete and testable, not vague") — but nothing in 01-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: build correctly marked 3 genuine open questions (platform, sharing model, ingredient source) as TBD:, lifted straight from the source PRD's own Dependencies/Open Questions. That's 04-spec working 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 into 02-deliver's Plan → Implement, building against undecided requirements.

Affected file(s)

plugins/aidd-orchestrator/skills/01-sdlc/references/01-frame.md

Expected behaviour

Before Spec --> Contract in 01-frame.md's flow, the spec must validate against spec-validator.yml (no residual TBD: 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 from Spec to Contract to Deliver, unconditionally. No validation gate, no reference to spec-validator.yml anywhere in the SDLC skill.

AI tool

Claude Code

OS

macOS

Additional context

Surfaced during #564's 04-spec router-contract migration (out of scope there — different plugin, no behaviour change allowed in that issue). spec-validator.yml itself is sound; the gap is purely that nothing in the orchestration layer consults it.

Activity

  1. moved this from Ideation to Todo in AIDD Roadmapon Sep 10, 2026
  2. changed the issue type fromtoon Sep 10, 2026
  3. blafourcade commented on Oct 7, 2026

    @blafourcade
    ContributorAuthor

    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 None deliver 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 None while 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 from Spec to Contract to Deliver, 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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Fields

    Priority

    High

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions