Verification Gates and Gap Recovery

Verification gates and gap recovery work as a team to catch problems early and fix them before Vex moves on. Without these gates, a broken task could cascade into a chain of failures. With them, problems are isolated, fixed, and documented automatically.

What is a verification gate?

After implementing a task, Vex must verify it actually worked before proceeding. This mandatory checkpoint prevents cascading failures — where a broken Task 1 leads to broken Tasks 2 and 3, and suddenly you have three tasks to debug instead of one.

How verification works:

1. Vex finishes a task and calls complete_task
2. Task status changes to Pending Verification
3. Vex tests the result — enters play mode, checks the console, inspects objects with object.info, or reads files
4. Vex calls verify_task passed=true or passed=false
5. If passed: task moves to Completed, Vex advances
6. If failed: a gap record is created and the task is Blocked

Gap records:

When verification fails, Vex creates a gap: add_gap description="Player falls through floor" severity="high". Each gap gets a unique ID and includes a description plus severity (low, medium, or high).

Resolving gaps:

1. Vex identifies the root cause
2. Implements a fix (adds a BoxCollider, corrects a script, etc.)
3. Re-tests to confirm the fix works
4. Calls resolve_gap with a resolution description
5. The gap closes, the task unblocks, and work continues

This system catches problems at the individual task level and fixes them immediately, so you never end up shipping a completed plan that is secretly full of hidden bugs waiting to surface later.

Why verification matters so much:

Without verification gates, AI assistants tend to report success optimistically without actually checking. “Created PlayerController.cs” might mean the file was created but has a syntax error that Unity will reject during compilation. “Added Rigidbody to Player” might mean the component was added but with default settings that do not match your needs. Verification forces Vex to actually test the result — enter play mode, check the console, inspect the object — and confirm it really works before moving on to the next task. This extra step takes seconds but saves hours of debugging later.