docs(rules): merge repeated completion checks in definition of done

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

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.