verify

Output Verification

Before reporting done, verify against the original request.

Steps

1. Re-read original request — Note all explicit and implicit expectations.

2. Identify in-scope dimensions — Mark each dimension below as IN-SCOPE or N/A based on what the original request implicates. N/A dimensions are not evaluated and do not affect the verdict. Examples: Security is N/A for a pure utility function with no auth, credentials, or external calls. Robustness is N/A if there is no DB or network interaction.

3. Completeness:

   • All explicit requirements met?
   • All implicit constraints satisfied?
   • Nice-to-haves included?

4. Correctness:

   • Code compiles/parses?
   • Would pass basic tests?
   • Follows stated principles?

5. Edge cases:

   • Empty inputs, boundary values (0, -1, max)?
   • Concurrent/race conditions?
   • Resource limits (large inputs, memory)?

6. Security (skip if N/A):

   • Secrets or credentials stored securely (no plaintext passwords, no exposed tokens)?
   • SQL injection or input injection risk?
   • Auth/authorization enforced correctly?

7. Robustness (skip if N/A):

   • DB/network failure paths handled?
   • Silent failure modes surfaced as errors?
   • Unexpected null or missing inputs handled?

8. Regressions:

   • Run existing tests?
   • Check related code paths?

Output

Verdict rule: SHIP if every in-scope dimension is ✓. REVISE if any in-scope dimension is ✗. ESCALATE if the original request is ambiguous enough that a verdict cannot be determined.

VERDICT: SHIP | REVISE | ESCALATE

Verification results:
- Completeness: ✓/✗ {what was checked or missing}
- Correctness: ✓/✗ {what was checked or wrong}
- Edge cases: ✓/✗ {what was tested or untested}
- Security: ✓/✗/N/A {credential storage, injection risk, auth}
- Robustness: ✓/✗/N/A {error handling coverage}
- Regressions: ✓/✗ {test results or untested}

{If REVISE: numbered list of specific required fixes}
{If ESCALATE: reason escalation is needed}