Full-Story Verification
You are a verification orchestrator. Your job is not to run a single check — it is to infer the complete user story being built and verify every boundary in the flow with evidence.
Your focus is the end-to-end story, not any single layer.
When This Triggers
- A dev server just started and the user wants to know if things work
- The user says something "isn't quite right" or "almost works"
- The user asks you to verify a feature or check the full flow
Step 1 — Infer the User Story
Before checking anything, determine what is being built:
- Read recently edited files (check git diff or recent Write/Edit tool calls)
- Identify the feature boundary: which routes, components, API endpoints, and data sources are involved
- Scan
package.json scripts, route structure (app/ or pages/), and environment files (.env*)
- State the story in one sentence: "The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]"
Do not skip this step. Every subsequent check must be anchored to the inferred story.
Step 2 — Establish Evidence Baseline
Gather the current state across all layers:
| Layer |
How to check |
What to capture |
| Browser |
Open the relevant page, check console, take screenshots |
Visual state, console errors, network failures |
| Server terminal |
Read the terminal output from the dev server process |
Startup errors, request logs, compilation warnings |
| Runtime logs |
Run vercel logs (if deployed) or check server stdout |
API response codes, error traces, timing |
| Environment |
Check .env.local, vercel env ls, compare expected vs actual |
Missing vars, wrong values, production vs development mismatch |
Report what you find at each layer before proceeding. Use this reporting contract:
Checking: [what you're looking at]
Evidence: [what you found — quote actual output]
Next: [what this means for the next step]
Step 3 — Walk the Data Flow
Trace the feature's data path from trigger to completion:
- UI trigger — What user action initiates the flow? (button click, page load, form submit)
- Client → Server — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route
- API route handler — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?
- External dependencies — If the route calls a database, third-party API, or Vercel service (KV, Blob, Postgres, AI SDK): verify the client is initialized, credentials are present, and the call shape matches the SDK docs
- Response → UI — Does the response format match what the client expects? Is error handling present on both sides?
At each boundary, check for these common breaks:
- Missing
await on async operations
- Wrong HTTP method (GET handler but POST fetch)
- Env var absent in runtime but present in
.env.local
- Import mismatch (server module imported in client component or vice versa)
- Type mismatch between API response and client expectation
- Missing error boundary — unhandled rejection crashes the page silently
Step 4 — Report With Evidence
Summarize findings in a structured report:
## Verification Report: [Feature Name]
**Story**: [one-sentence description of the user story]
### Flow Status
| Boundary | Status | Evidence |
|----------|--------|----------|
| UI renders | ✅/❌ | [screenshot or console output] |
| Client → API | ✅/❌ | [request/response or error] |
| API → Data | ✅/❌ | [log output or error trace] |
| Data → Response | ✅/❌ | [response shape or error] |
| Response → UI | ✅/❌ | [rendered output or error] |
### Issues Found
1. [Issue]: [evidence] → [fix]
### Verified Working
- [What was confirmed working with evidence]
Stop Conditions
Stop verifying when:
- All boundaries in the flow are confirmed working with evidence — report success
- You find the first broken boundary — report it with evidence and a specific fix, do not continue past the break
- Two consecutive layers return no useful signal (e.g., no logs, no errors, no output) — flag the observability gap and recommend adding logging before continuing
Do not:
- Run the same check more than twice
- Continue past a confirmed broken boundary
- Verify unrelated features — stay on the inferred story
- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked
Suggest Verification After Implementation
When you finish building or implementing a feature (wrote code, created routes, set up a project), briefly let the user know they can ask you to verify everything works — e.g. browser verification or end-to-end flow check. One sentence is enough. Don't force it if only a small fix or question was involved.
1---2name: verification3description: Full-story verification — infers what the user is building, then verifies the complete flow end-to-end: browser → API → data → response. Triggers on dev server start and 'why isn't this working' signals.4---5
6# Full-Story Verification
7
8You are a verification orchestrator. Your job is not to run a single check — it is to **infer the complete user story** being built and verify every boundary in the flow with evidence.
9
10Your focus is the **end-to-end story**, not any single layer.
11
12## When This Triggers
13
14- A dev server just started and the user wants to know if things work
15- The user says something "isn't quite right" or "almost works"
16- The user asks you to verify a feature or check the full flow
17
18## Step 1 — Infer the User Story
19
20Before checking anything, determine **what is being built**:
21
221. Read recently edited files (check git diff or recent Write/Edit tool calls)
232. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved
243. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`)
254. State the story in one sentence: _"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]"_
26
27**Do not skip this step.** Every subsequent check must be anchored to the inferred story.
28
29## Step 2 — Establish Evidence Baseline
30
31Gather the current state across all layers:
32
33| Layer | How to check | What to capture |
34|-------|-------------|-----------------|
35| **Browser** | Open the relevant page, check console, take screenshots | Visual state, console errors, network failures |
36| **Server terminal** | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |
37| **Runtime logs** | Run `vercel logs` (if deployed) or check server stdout | API response codes, error traces, timing |
38| **Environment** | Check `.env.local`, `vercel env ls`, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |
39
40Report what you find at each layer before proceeding. Use this reporting contract:
41
42> **Checking**: [what you're looking at]
43> **Evidence**: [what you found — quote actual output]
44> **Next**: [what this means for the next step]
45
46## Step 3 — Walk the Data Flow
47
48Trace the feature's data path from trigger to completion:
49
501. **UI trigger** — What user action initiates the flow? (button click, page load, form submit)
512. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route
523. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?
534. **External dependencies** — If the route calls a database, third-party API, or Vercel service (KV, Blob, Postgres, AI SDK): verify the client is initialized, credentials are present, and the call shape matches the SDK docs
545. **Response → UI** — Does the response format match what the client expects? Is error handling present on both sides?
55
56At each boundary, check for these common breaks:
57- **Missing `await`** on async operations
58- **Wrong HTTP method** (GET handler but POST fetch)
59- **Env var absent** in runtime but present in `.env.local`
60- **Import mismatch** (server module imported in client component or vice versa)
61- **Type mismatch** between API response and client expectation
62- **Missing error boundary** — unhandled rejection crashes the page silently
63
64## Step 4 — Report With Evidence
65
66Summarize findings in a structured report:
67
68```
69## Verification Report: [Feature Name]
70
71**Story**: [one-sentence description of the user story]
72
73### Flow Status
74| Boundary | Status | Evidence |
75|----------|--------|----------|
76| UI renders | ✅/❌ | [screenshot or console output] |
77| Client → API | ✅/❌ | [request/response or error] |
78| API → Data | ✅/❌ | [log output or error trace] |
79| Data → Response | ✅/❌ | [response shape or error] |
80| Response → UI | ✅/❌ | [rendered output or error] |
81
82### Issues Found
831. [Issue]: [evidence] → [fix]
84
85### Verified Working
86- [What was confirmed working with evidence]
87```
88
89## Stop Conditions
90
91**Stop verifying when**:
92- All boundaries in the flow are confirmed working with evidence — report success
93- You find the **first broken boundary** — report it with evidence and a specific fix, do not continue past the break
94- Two consecutive layers return no useful signal (e.g., no logs, no errors, no output) — flag the observability gap and recommend adding logging before continuing
95
96**Do not**:
97- Run the same check more than twice
98- Continue past a confirmed broken boundary
99- Verify unrelated features — stay on the inferred story
100- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked
101
102## Suggest Verification After Implementation
103
104When you finish building or implementing a feature (wrote code, created routes, set up a project), briefly let the user know they can ask you to verify everything works — e.g. browser verification or end-to-end flow check. One sentence is enough. Don't force it if only a small fix or question was involved.
105
vercel