From 56f9981cc98b45c973a56a3003b31d8220c9a44e Mon Sep 17 00:00:00 2001 From: Julian lechner Date: Thu, 8 Oct 2026 10:34:02 +0200 Subject: [PATCH] docs(rules): merge repeated completion checks in definition of done Co-Authored-By: Claude Opus 5.5 --- shared/rules/definition-of-done.md | 51 +++++++++--------------------- 1 file changed, 15 insertions(+), 36 deletions(-) diff --git a/shared/rules/definition-of-done.md b/shared/rules/definition-of-done.md index 6082a00..b4044f5 100644 --- a/shared/rules/definition-of-done.md +++ b/shared/rules/definition-of-done.md @@ -2,49 +2,28 @@ A task is only considered done when all applicable requirements below are fulfilled. -## Coding +## Requirements + +* Every requirement in the work item description and every acceptance criterion is implemented or otherwise resolved; none is left partially implemented. +* Requirements are checked against the actual implementation and the relevant code paths, not assumed to be complete. +* Any deviation from the description or acceptance criteria has been explicitly approved by the user. +* No known unresolved blocker, defect, or regression introduced by the change remains. + +## Verification -* The implementation fully satisfies the requested behavior. -* All relevant acceptance criteria are implemented. -* The work item description is fully addressed. * Verification is sufficient for the change's risk and scope, following `general.md`'s Verification rules. A build, test run, new test, or independent review is not required for every change. * Checks selected on that basis, and checks explicitly required by the user or project, have passed. Material gaps and pre-existing failures are reported without claiming unverified success. -* No known unresolved defects or regressions introduced by the change remain. -* The implementation follows the project's coding, architecture, security, and performance guidelines. -* No unrelated changes are included. -* No temporary code, debug output, commented-out code, placeholders, or TODOs remain unless explicitly intended. -* Error handling and edge cases are handled appropriately. -* The implementation is readable, maintainable, and production-ready. -* Directly affected documentation and comments are updated; other documentation or comments are added only for a concrete need. * Any delegated research, review, or verification is complete and its relevant findings are resolved or reported. -## Work Items +## Code -A work item is only considered complete when: +* The implementation follows the project's coding, architecture, security, and performance guidelines and handles errors and edge cases appropriately. +* No unrelated changes are included. +* No temporary code, debug output, commented-out code, placeholders, or TODOs remain unless explicitly intended. +* Directly affected documentation and comments are updated; other documentation or comments are added only for a concrete need. -* Every acceptance criterion is fulfilled. -* Every requirement in the description is implemented or otherwise resolved. -* Acceptance criteria and description are checked against the actual implementation, not assumed to be complete. -* No known requirement is left partially implemented. -* No unresolved blocker or relevant defect remains. -* Required tests or validations have been completed successfully. -* Any deviation from the description or acceptance criteria has been explicitly approved by the user. +## Work item state -## Completion Check - -Before declaring a task complete: - -* Re-read the work item description. -* Re-read all acceptance criteria. -* Compare each requirement against the implemented result. -* Verify the relevant code paths. -* Choose and complete the smallest sufficient verification; expand only when evidence or risk warrants it. -* Check for incomplete or unrelated changes. -* Confirm that the final state matches the requested outcome. - -## Important Rule - -* Do not mark, close, resolve, or otherwise change the state of a work item automatically. -* A task may be technically complete without changing its remote work item state. +* Do not mark, close, resolve, or otherwise change the state of a work item automatically. A task may be technically complete without changing its remote work item state. * Perform an Azure DevOps write only when the user explicitly requests or approves that specific action. A direct request in the current task is sufficient; do not ask for the same approval again. * If completion is unclear, requirements conflict, or something is missing, ask the user instead of deciding autonomously.