Verify Reads the Contract
Verification is the point where recorded work meets pipeline policy. It checks that every required stage is present, the claim belongs to the landing session, review obligations are satisfied, and the landing summary exists. It should derive those requirements from canonical row data rather than from whatever the author remembers.
Order matters when stages express sequence. A plan gate logged after compose is not equivalent to one logged before mutation. The verifier needs timestamps or event order and a contract that names the allowed sequence, otherwise a complete set can still represent a broken workflow.
Verification also distinguishes structural gates from domain acceptance. It can prove the workshop trail is complete. The task's own evidence proves the deliverable. The landing decision joins them and reports failures by owner instead of reducing both to one green badge.
A current-row verifier can intentionally tighten in-flight work. If that is the product choice, output must show the effective row version and missing stages clearly. Surprising a session with “verification failed” and no policy identity makes live policy operationally hostile.
Explain Every Refusal
For each gate, return the missing or misordered stage, the policy version that required it, and the next valid action. A verifier is a product surface, not an assertion dump.
Test a complete-but-misordered trail, a stale brief under tightened live policy, a wrong-session landing, and a non-code task with no commit. Those cases prove the contract rather than the happy path.