How GSD's Verification Workflow Catches Bugs Before You Ship: Automated Checks + Manual UAT

Apr 21, 2026

When I first started using GSD, I wondered how it ensures quality. Does it just write code and hope for the best? After running dozens of projects through GSD, I found it uses three distinct verification layers that catch issues at different stages. Let me walk you through how each layer works.

The Three Verification Layers

GSD verification isn’t a single check at the end. It’s a defense-in-depth approach with checks before, during, and after code execution:

Plan checking - Verifies plans achieve phase goals before any code is written
Automated verification - Checks code exists and tests pass after execution
Manual UAT - You test deliverables one at a time with /gsd-verify-work

Each layer catches different types of issues, and together they form a safety net.

Layer 1: Plan Checking (Before Execution)

Before GSD writes any code, it verifies the plan itself. The plan-checker agent examines each plan to confirm it meets the phase goals. This prevents wasted effort on incorrect approaches.

Here’s what plan checking validates:

Plans achieve the phase goals defined in requirements
Tasks cover all must-have requirements
Verification commands exist for each task
No scope reduction has happened

If the plan fails validation, GSD can try up to three revision loops. If it still fails after revisions, the plan gets rejected entirely.

I’ve seen this catch issues early. For example, when I planned a user authentication feature, the plan-checker flagged that I’d missed the “remember me” functionality that was marked as a must-have requirement. GSD revised the plan to include it before writing any code.

Layer 2: Automated Post-Execution Verification

After execution finishes, the verifier agent runs automated checks. This layer focuses on what can be verified without human judgment:

Code existence checks:

Files exist where expected
Expected functions and classes are present
No missing imports or broken references

Test execution:

Automated tests pass
No test failures or errors
Coverage meets minimum thresholds

Deliverable validation:

Output matches requirements
Expected artifacts are created
No missing pieces

When verification fails, the issue gets flagged for escalation to the UAT layer. GSD doesn’t just report failure - it identifies what specifically failed and why.

Here’s what a verification output might look like:

✓ Code files exist at expected locations
✓ All required functions implemented
✗ Test suite failed: 2 tests failing
  - test_user_login: AssertionError on line 45
  - test_password_reset: Timeout exceeded
⚠ Coverage at 72%, below 80% threshold

Layer 3: Manual UAT with /gsd-verify-work

The final layer requires human judgment. Run /gsd-verify-work (or /gsd-verify-work N for a specific phase), and GSD presents deliverables one at a time for you to test.

The key difference from automated verification: UAT confirms the feature works as expected from a user perspective, not just that code exists.

Here’s how a UAT session flows:

Phase 3: User Authentication

Deliverable 1: Email login
Question: Can users log in with their email address?
[You test manually]
Your answer: yes

Deliverable 2: Password reset
Question: Can users reset their password via email?
[You test manually]
Your answer: no - email never arrives

Deliverable 3: Remember me checkbox
Question: Does the remember me option persist sessions?
[You test manually]
Your answer: yes

When something breaks during UAT, GSD doesn’t just record the failure. It spawns debug agents to diagnose the issue, then creates fix plans automatically. In the example above, GSD would investigate why password reset emails aren’t being sent.

The Nyquist Validation Layer

GSD includes a Nyquist validation layer that maps test coverage to each requirement before code is written. This ensures every requirement has a corresponding test that can verify it.

Think of Nyquist as a requirements-to-tests mapping that gets created early in the process. When you commit code, the feedback mechanism verifies coverage within seconds.

For projects that existed before Nyquist was added, GSD provides retroactive validation:

/gsd-validate-phase 2

This fills coverage gaps for phases that were executed before the Nyquist layer existed. It’s useful for bringing older projects up to current verification standards.

How the Layers Work Together

The three layers catch different types of issues at different points:

Plan checking catches:

Missing requirements
Incorrect approaches
Scope creep or reduction
Unverifiable tasks

Automated verification catches:

Missing files or functions
Test failures
Integration issues
Syntax errors

UAT catches:

User experience problems
Integration issues with external systems
Edge cases automated tests miss
Requirements misunderstood during planning

By the time code reaches production, it’s been checked at three distinct gates. Issues get caught early when they’re cheapest to fix.

When Verification Fails

Verification failures trigger specific recovery actions:

Plan check failure: GSD revises the plan up to three times, then rejects if still failing.

Automated verification failure: GSD flags the issue and escalates to UAT for human review.

UAT failure: GSD spawns debug agents to investigate, then creates fix plans for identified issues.

You don’t have to manually diagnose problems. GSD handles the investigation and planning for fixes.

Practical Tips for Using GSD Verification

I’ve learned a few things about making verification work effectively:

Run UAT promptly: Don’t wait days between execution and UAT. Test while context is fresh.

Be specific in UAT answers: Instead of just “no”, explain what’s wrong. “No - email never arrives” gives GSD more to work with than “no”.

Trust the plan checker: When it rejects a plan, review why. It’s usually catching something you missed.

Use retroactive validation: If you’re bringing an existing project into GSD, run /gsd-validate-phase for each completed phase.

Summary

In this post, I explained GSD’s three-layer verification workflow. Plan checking validates plans before execution, automated verification checks code and tests after execution, and manual UAT with /gsd-verify-work confirms features work as expected. The Nyquist validation layer maps test coverage to requirements before implementation. When verification fails, GSD automatically diagnoses issues and creates fix plans.

This multi-layer approach catches issues at the earliest possible stage, when fixes are cheapest. It’s not just about finding bugs - it’s about preventing wasted effort and ensuring deliverables match requirements.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!