reviewer-protocol

## Context When a team member has a **Reviewer** role (e.g., Tester, Code Reviewer, Lead), they may approve or reject work from other agents. On rejection, the coordinator enforces strict lockout rules to ensure the original author does NOT self-revise. This prevents defensive feedback loops and ensures independent review. ## Patterns ### Reviewer Rejection Protocol When a team member has a **Reviewer** role: - Reviewers may **approve** or **reject** work from other agents. - On **rejection**, the Reviewer may choose ONE of: 1. **Reassign:** Require a *different* agent to do the revision (not the original author). 2. **Escalate:** Require a *new* agent be spawned with specific expertise. - The Coordinator MUST enforce this. If the Reviewer says "someone else should fix this," the original agent does NOT get to self-revise. - If the Reviewer approves, work proceeds normally. ### Strict Lockout Semantics When an artifact is **rejected** by a Reviewer: 1. **The original author is locked out.** They may NOT produce the next version of that artifact. No exceptions. 2. **A different agent MUST own the revision.** The Coordinator selects the revision author based on the Reviewer's recommendation (reassign or escalate). 3. **The Coordinator enforces this mechanically.** Before spawning a revision agent, the Coordinator MUST verify that the selected agent is NOT the original author. If the Reviewer names the original author as the fix agent, the Coordinator MUST refuse and...