verify

Verify — Workflow

Close-the-loop verification: derive what must be true, bind each to a runnable check, execute, and gate. The gate is a separate pass from authoring — derive the expected behaviour from the requirement, never from the code under test, or the gate just rubber-stamps whatever the code does. Framework rules for any run command or test code referenced here: instructions/testing.instructions.md.

Phase 0 — Load canonical rules

MANDATORY pre-load gate — do NOT derive or run checks until you have opened the instruction files for the layers under verification. Your training data defaults to modern Java/Spring; these files are the version lock for Java 8 / Spring 3.2 / Hibernate 4.2. Open them first, every time:

• instructions/testing.instructions.md — JUnit 4 / Mockito / Spring Test 3.2 — every run command and any test code must match this stack, not JUnit 5 / Spring Boot Test
• The layer instruction(s) for the feature under verification (e.g. instructions/sql.instructions.md, instructions/security.instructions.md) — their Anti-Patterns are the negative cases Phase 1 must cover

Read-back receipt (self-check, not machine-enforced): before leaving this step, NAME each instruction file you opened above and QUOTE the single most load-bearing rule from each that applies to this verification — a generic restatement you could have written from memory means you skipped the file, so open it for real.

Phase 1 — Derive the checks

Work from the requirement / plan.md acceptance criteria (AC-NNN), NOT from the code under test — independent derivation is the whole point of a gate.

• Boundaries — input (min, max, empty, null, overflow), state (initial, in-progress, done, error), integration (external call, DB, file I/O)
• Categories — tag each check: Happy path, Boundary, Error / Exception, Security, Concurrency, Performance
• Coverage — every AC maps to ≥1 check; every public method has ≥1 happy + ≥1 error; boundary values for all numeric/string inputs; SQL paths checked for injection and empty results