Workflow Quality

Use the minimum set of validators that proves correctness. Do not stack validators that check overlapping concerns.

ValidatorSchedule

The schedule controls when each validator runs relative to pipeline progress.

Set lint_check and test_suite to per_deliverable — catching failures early reduces rework. Set code_review and regression_tests to per_stage when reviewing all changes together is more meaningful than reviewing each in isolation.

CompletionCriteria

CompletionCriteria use AND-composition. All conditions must be true for a stage or TaskGroup to advance.

completion_criteria:
  deliverable_status: complete          # All deliverables reach COMPLETE status
  validator_results:
    - lint_check: pass
    - test_suite: pass
    - code_review: approved
  approval: director                    # Human-in-the-loop gate

AND-composition rules:

• Every validator_results entry must pass.
• deliverable_status: complete requires every deliverable in scope to be in COMPLETE state.
• If approval is set, human confirmation is required before advancing regardless of validator outcomes.
• Missing approval key defaults to auto — no human gate.

Evidence Collection Principle

Validators read existing agent output. They never perform work.

# Correct pattern
lint_check reads: session_state["lint_results"]    # Written by linter agent
test_suite reads: session_state["test_results"]    # Written by tester agent

# Incorrect pattern
lint_check runs: ruff check .                       # Validator is not a worker

If the expected state key is absent, the validator returns inconclusive and the stage gate fails. This surfaces missing agent output explicitly rather than silently passing.

Three-Layer Completion Reports

Stage completion reports aggregate evidence across three layers:

1. Functional layer — deliverable status: are all deliverables COMPLETE? Any FAILED or BLOCKED?
2. Architectural layer — design conformance: do code_review results confirm the implementation matches the design?
3. Contract layer — spec coverage: do all acceptance criteria from the deliverable spec appear in test results or reviewer sign-off?

Not every workflow needs all three layers. A simple code workflow needs functional and contract layers. An architectural refactor warrants all three.

Approval Configuration

Per-stage approval controls who must sign off before the next stage begins:

Use ceo approval on stages that produce externally visible deliverables (deploys, releases, public-facing changes). Use director for internal quality gates that a human should review but not necessarily be blocked on.

Hard Gate Principle

TaskGroup and stage completion gates are deterministic. The PM cannot override a failed gate.

• A gate that has unmet validator_results conditions returns BLOCKED regardless of PM instruction.
• A gate with approval: ceo remains BLOCKED until the CEO queue item resolves.
• The only path through a hard gate is satisfying its conditions — there is no bypass mechanism.

This is intentional. Deterministic gates prevent LLM judgment from overriding objective evidence.

Checklist

• Every validator in validator_results has a corresponding agent that writes the expected state key
• deliverable_status_check is included in the final stage gate
• ValidatorSchedule matches the granularity of the check (per-deliverable vs per-stage)
• approval is set to ceo for externally visible outcomes
• Completion report covers functional + contract layers at minimum
• No validator performs work — all validators read from session state