The Plan Gate Is Not Decoration
A plan gate exists because autonomous execution is most useful after method and premises are visible. The author reports the diagnosis, intended targets, exclusions, approach, risks, and proof. The requester can catch a wrong premise before tools turn it into a large, internally consistent mistake.
The gate is not a progress update written after work starts. Logging it retroactively preserves a timestamp and destroys the control. A system should require the stage before mutation where it can enforce that boundary, and reviewers should compare the final artifact to the exact approved gate.
Approval attaches to premises, not merely to a task name. If the plan assumes a clean destination or permission to replace a shared file, that assumption must be stated. A later discovery that invalidates it reopens the gate; autonomy does not convert changed premises into implicit approval.
A generic workshop cannot prescribe every domain method, but it can require the shape of a responsible plan. That is enough: the task owns content-specific judgment, while the workshop ensures judgment becomes inspectable before execution.
Quote the Gate in Review
Store the approved gate as a stage note and include it verbatim in the reviewer request. This prevents the author from presenting a cleaner retrospective plan and gives the reviewer a stable contract for scope drift.
A useful gate is concise but falsifiable. “Implement carefully” cannot be compared to an artifact. “Change these targets, preserve these exclusions, run these proofs” can.