Readiness
Read more about SDD in Spec-Driven Development.
Maturity: Still defining
Summary
Readiness communicates how ready a work item is for agent execution. It is a lightweight quality gate before the handoff to Duo Developer. Without it, anyone can start an agent on a poorly scoped work item, which wastes tokens and produces low-quality output, and there is no signal of whether a work item is good enough to hand off.
Readiness applies to the whole work item, not only to the Workplan. It is backed by a numeric readiness score, but the user interface shows only the readiness level, not the number. The rename from confidence is implemented in merge request 259555.
Epic: WS-6: Work item readiness score
User documentation: Readiness
Scoring model
The score is a number from 0 to 100. The scoring stage evaluates the saved Workplan against the work item description and comments. Its supervisor coordinates two rounds of three evaluators:
- A rubric evaluator scores coverage, groundedness, specificity, feasibility and ordering, and completeness. A coverage evaluator maps requirements to plan steps in both directions. A falsifier looks for a wrong premise, wrong target, or success criteria that could pass without solving the problem.
- Three cross-examiners reassess those findings against each other. The supervisor combines the revised scores and caps the result when a material defect remains plausible or confirmed.
Each round is designed for parallel delegation, with sequential fallback if the execution environment does not support it. An incomplete first round does not produce a score. These scoring caps affect the assessment, not the user’s permission to implement.
The supervisor also writes Markdown recommendations, ordered by impact. It omits feedback when there are too few genuine recommendations rather than inventing issues to fill the list. The implementation is in the workplan scoring configuration. Further simplification is tracked in issue 2913.
Computation
Scoring runs inside the async workplan flow, after the planner writes the plan, rather than launching a separate workflow. The scoring stage fetches the saved work item and non-system notes, evaluates them, and writes only the score and feedback; it does not rewrite the plan (merge request 7039). A scoring fetch failure ends the scoring stage without turning a successfully written plan into a failed planning run.
The score and feedback are stored with the Workplan and exposed through readinessScore, readinessScoreFeedback, and readinessScoreFeedbackHtml. The AI Gateway work item tool persists both the score and feedback (merge request 7144). The MCP work item tools support the score; feedback support remains tracked separately in issue 627234.
Display
The Implementation widget shows the readiness indicator only after a numeric score exists, including zero.
| Score | Level | Indicator |
|---|---|---|
| 0–39 | Low | One bar, error |
| 40–79 | Medium | Two bars, warning |
| 80–100 | High | Three bars, success |
Readiness details opens an overlay drawer titled How to improve readiness?. It fetches rendered feedback on demand and keeps the readiness level in the widget. Opening the drawer does not resize the work item or change its URL. Closing it restores focus to the trigger (merge request 259135).
When no score exists, the UI does not yet distinguish evaluating, failed, canceled, and not evaluated states. A dedicated readinessScoreStatus field is proposed in merge request 262079, with the UI tracked in issue 633076.
Behavior
In this iteration, readiness is advisory. Users can start implementation regardless of the readiness level. This avoids hard approval gates while still signaling when a work item needs more refinement.
Future iterations might add:
- Approval gates for handoff below a threshold, restricted to specific roles.
- Project-level policies, such as automatic handoff above a threshold.
- Score history.
- Criteria configurable by project owners.
- A separate score for how well the merge request matches the Workplan.
Open questions
- Whether to also score before plan generation, and how to support scoring independently of a planning run.
- The empty-feedback treatment at 100% readiness (issue 633996) and showing high scores below 100% more precisely (issue 633988).
- Default thresholds for any warning before handoff.
- Whether to store score history or only the current score.
0259db05)
