Acceptance criteria, one by one

A pull request that lists what should be true after it merges now gets an answer for each item, not just one verdict for the whole change.

• Read from the description. List items under a heading such as Acceptance criteria, Test plan or How to test count as criteria. Without such a heading, a task list (- [ ]) at the top or under Summary or Changes does. A template's own checklist, under a heading such as Checklist or Before merging, never does. Up to 10 criteria, 200 characters each.
• Answered by number. The criteria are numbered in the test, and the agent marks each one met, not met or not checked, with a one-line note. A criterion it did not get to stays not checked rather than counting as met.
• A criterion not met fails the run. A run that otherwise passed is marked failed when any criterion is not met, so the check fails and blocks the merge when merge blocking is on.
• On the run page and the pull request. The run page shows the list with a count such as "2 of 3 criteria met". The pull request comment carries the same table under the verdict, and the check summary carries the count.
• Same rules as the description. The criteria are the author's words, quoted as data. Pull requests from forks and bots add none.

Turn on a repository in Connections, GitHub, and write your next pull request's test plan under a Test plan heading.