Intent and spec conformance
Compares the change to what was asked for: the ticket, the plan or spec, the design, the review comments it was meant to address.
When: When a change implements a ticket, a plan or a design, and before merging, to confirm the thing built is the thing requested.
VA08 tactic
7 techniques
14 sub-techniques
not detectable from CI configuration; no usage counts
| ID | Technique | Description | Sub |
|---|---|---|---|
V1052 |
Ticket intent alignment | Checks a finding or a change against the linked ticket: behaviour the ticket declares intentional is not a bug, and requirements it lists must be present. | 2 |
V1053 |
Plan and spec traceability | Checks each requirement in a plan or specification against the implementation: done in this change, done elsewhere, or not started, with gaps graded by severity. | 2 |
V1054 |
Functional spec verification | Runs the application and checks each functional requirement in a browser, returning met, partially met, not met or unverifiable with screenshot evidence. | 2 |
V1055 |
Design conformance | Compares the rendered UI with the design it implements and reports layout, spacing, colour and copy differences. | 2 |
V1056 |
Review comment resolution | Checks whether a new commit actually addresses each open review comment before the thread is resolved. | 2 |
V1057 |
Merge readiness | Combines checks, reviews, open threads and findings into one verdict on whether a change can merge. | 2 |
V1058 |
Output guardrails | Validates what an automated reviewer or fixer produces before it is posted or committed: schema, policy and safety checks. | 2 |