AC verification
How acceptance criteria become verifiable code contracts.
Acceptance Criteria (ACs) are the contract a PR is supposed to fulfil. codingassist.bot treats them as first-class — every AC is bound to one or more code contracts before reasoning starts.
The mapping problem
Most AI reviewers never see the ticket; they look at the diff in isolation. codingassist.bot does the opposite: it parses the ticket, extracts each AC, and maps it to the lines of the diff that satisfy (or refute) it.
32def update_email(user, new):33 validate(new)34 if user.pending_email:35 return "verify first"3651def issue_token(user):52 token = make_token(ttl=900)5367def reject_dup(new):68 if email_exists(new):69 raise Duplicate()
Hover an AC to see the bound contract. Each AC carries a confidence score and an explanation that survives into the audit ledger.
How extraction works
ACs are extracted from your ticket source using a typed schema (no free-form prompting). For Jira and Linear, codingassist.bot parses the Acceptance Criteria field; for GitHub Issues, it parses checklist items in the body.
type Ac = {
id: string; // e.g. "AC1"
text: string; // human-readable
shape: "must" | "should" | "may";
source: { kind: "jira" | "linear" | "github"; id: string; url: string };
};Binding ACs to code
The Context stage runs a bind step that, for each AC, retrieves the diff hunks most likely to satisfy it. Binding is graph-based, not lexical — it uses the CodeGraph to find call sites, type usages, and contract changes.
A bound AC produces:
- The set of
(file, lineRange)tuples that contribute to satisfying it - A
confidencescore (0–1) - A short natural-language explanation of the binding
If an AC cannot be bound, the verdict is degraded to Reviewable at minimum — codingassist.bot will never silently pass a PR that drops an AC.
Where it surfaces
Bound ACs appear in three places:
- The reasoning trace on every verdict
- The hero card of the PR comment (compact view)
- The audit ledger with cryptographic signatures