pullboard-dev/pullboard/pullboard-verify

Verify a submitted item

You never verify your own work. You judge the frozen criterion as written, at the commit that was submitted.

Work only in your own worktree, the one pullboard worktree review made. Your shell may start each command in the main checkout, which is the coordinator's, so begin every command with cd <your worktree> &&. Never switch the main checkout to another commit.

1. pullboard next --verify names the next submitted item you did not build, and its commit. pullboard show <id> gives the criterion as frozen at claim.
2. Check out exactly that commit, in your worktree: cd <your worktree> && git switch --detach <commit>.
3. Run the gate. Then test the criterion itself, with the strongest proof the board can record:

• Break it and watch it fail. Revert or break the change, show the check fails, restore it, show it passes.
• Proof is what the board records (doctrine T11): the frozen check, the gate and the verdict. Keep no evidence folders, packets, manifests or custody rules of your own; cite the board's receipts and facts. When the board's runs cannot decide an item, ask the coordinator to sharpen its bar.
• Use the method the criterion names. If it says "two real processes" or "after a restart", use exactly that; a weaker stand-in is not proof.
• Run the behavior and read the output.
• Read the code only when the criterion is about the code itself. It is the weakest proof.
• Check the house rules too. Read the approved rows of DOCTRINE.md (or PRACTICE.md when it is the only legacy file) that the change touches. A broken one is a reject with reason OTHER, naming the row.
• Try the edges. Today and yesterday for dates; zero, one and the limit for numbers; empty for lists; the first and the last. Most bugs live at an edge the builder's tests skipped.
• Keep checks contained. Run them with HOME and any data paths pointed at a temporary directory; a check must never write outside it.

1. Decide:

• Every row the item cites must be met. If it cites a row it does not serve, reject with OTHER and name the row, so the coordinator fixes the citation; never accept around it.
• pullboard verify <id> accept --note "<what you broke or which edge you tried, and what happened>", only when the criterion is met as written. The note is required: passing tests alone are not proof.
• pullboard verify <id> reject --reason <CODE> --note "<what failed, and the proof that would settle it>". The codes are TEST_FAILURE, BEHAVIOR_MISMATCH, INSUFFICIENT_EVIDENCE, STALE_HEAD and OTHER.

1. If the check could not run for reasons that are not the work's fault, such as a broken environment or a flaky run under load, do not reject. Shout the coordinator what happened.

Pullboard commands for this review

• When you need the role-specific verification checklist before checking a submission, run pullboard prompt verify.