Review tickets and merge requests for missing requirements

Resolve the linked ticket using a trusted repository convention or an explicit reviewer selection. Do not allow arbitrary URLs in a commit message to trigger authenticated fetches. Fetch acceptance criteria and approved clarifications from permitted projects, record their version, and identify the owner who can answer an ambiguity.

Break a compound criterion into observable obligations. “An operator can export filtered results” includes the operator role, the active filter, the exported content and the error path. The model can propose this decomposition, but a human must confirm it before treating the list as the release contract.

• Separate mandatory criteria from suggestions and future work.
• Identify requirements implemented outside this MR, with explicit references.
• Report missing or conflicting criteria rather than inventing an interpretation.

1. 01Record the ticket and head commit being assessed.
2. 02Collect permitted diff context, relevant unchanged code and actual CI results.
3. 03For every criterion, propose implementation references and independent verification references.
4. 04Classify it as evidenced, partially evidenced, missing or needs clarification.
5. 05Have a reviewer confirm uncertain mappings and reopen affected rows when the ticket or commit changes.

A file name alone is weak evidence. For an export requirement, point to the filter serialization and query application, then a test that compares exported rows with the filtered expectation. A green CI badge without a relevant assertion is not coverage of that requirement.

Allow “outside this change” as a separate explanation, not an automatic pass. The reviewer needs to inspect the referenced earlier work and verify it still applies. Large cross-repository changes require explicit scope limits.

This row does not assert that the code is broken. It states that verification evidence is missing. That distinction matters: a product owner might accept a documented manual check, ask for an automated regression or decide the risk requires a release hold. The bot should make that choice possible, not make it implicitly.

Use a concise summary ordered by unresolved obligation. Link to the actual ticket, commit and check record. Do not quote sensitive ticket text into a public repository comment.

Prepare tickets with independently labelled obligations and paired changes: complete implementation, missing error behaviour, absent permission check and a test that merely echoes the implementation. Include a clean change so “flag everything” cannot score well.

Measure omitted obligations detected, false omission claims and evidence-reference validity. Ask reviewers to score whether each mapping would help a release decision. Keep clarification questions separate from missing implementation; unresolved requirements cannot be scored as engineering defects.

A useful challenge is to remove one branch or one assertion from an otherwise complete change. The reviewer should identify the affected criterion, not produce an unrelated generic warning. Also alter a ticket after review and confirm that the old matrix is marked stale.

Repository access does not imply ticket-system access. Authorise both independently. A broad integration account can accidentally reveal private requirements to contributors who may view the MR but not the ticket. Filter source context and publication audience before calling the model.

Treat ticket comments, repository files and logs as untrusted content. The model must not be able to expand the project allow-list, approve a requirement or modify a release label. Provide only the fields needed for the matrix and validate every proposed reference against fetched evidence.

Missing access should produce a limited-review status. It must never be converted into “no requirements missing”. Record why a row could not be assessed without disclosing inaccessible content.

Use the same bounded event infrastructure for code risk and delivery completeness, but label outputs separately. Cache ticket context by version, deduplicate publication by commit and avoid generating a new matrix for unrelated label edits. The cost includes ticket retrieval, repository context, model usage and the time spent resolving questions.

A pilot can sit alongside AI-assisted requirements work and existing release gates. For implementation and rollout, see AI in software delivery or share the workflow for an estimate.

Event and source-handling references reviewed 11 October 2026: GitLab: merge request pipelines, GitHub: secure use of Actions and OWASP: prompt injection. No platform setting or model judgement replaces the requirement owner.