Update to Vercel
Snapshot Oct 6, 2026 · 18:03 UTC · version 0.54.1
Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Instructions updated for verification
Instruction wording changed from “sitemap: "https://vercel.com/sitemap/docs.xml"” to “summary: "Verify full user story: browser + server + data flow + env"”. 36 additional added or edited lines are in the evidence.
Observed in instructions or declared skills. Runtime behavior has not been tested.
Skill instructions
sitemap: "https://vercel.com/sitemap/docs.xml" This skill coordinates with `agent-browser-verify` (browser-side visual checks), `investigation-mode` (reactive debugging), and `observability` (logging/monitoring) — but your focus is the...
summary: "Verify full user story: browser + server + data flow + env" sitemap: "https://vercel.com/sitemap.xml" retrieval: aliases: - end to end test - full stack verify - flow test - integration check intents: ...
Compare saved observations
Download comparison JSONFull technical diff · 1 changed fields
changed /skill_md_contents
"---\nname: verification\ndescription: \"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.\"\nmetadata:\n priority: 7\n docs:\n - \"https://vercel.com/docs/projects/project-configuration\"\n sitemap: \"https://vercel.com/sitemap/docs.xml\"\n pathPatterns: []\n bashPatterns:\n - '\\bnext\\s+dev\\b'\n - '\\bnpm\\s+run\\s+dev\\b'\n - '\\bpnpm\\s+dev\\b'\n - '\\bbun\\s+run\\s+dev\\b'\n - '\\byarn\\s+dev\\b'\n - '\\bvite\\s*(dev)?\\b'\n - '\\bvercel\\s+dev\\b'\n - '\\bastro\\s+dev\\b'\n importPatterns: []\n promptSignals:\n phrases:\n - \"verify the flow\"\n - \"verify everything works\"\n - \"test the whole thing\"\n - \"does it actually work\"\n - \"check end to end\"\n - \"end to end test\"\n - \"why isn't it working right\"\n - \"why doesn't it work\"\n - \"it's not working correctly\"\n - \"something's off\"\n - \"not quite right\"\n - \"almost works but\"\n - \"works locally but\"\n - \"verify the feature\"\n - \"make sure it works\"\n - \"full verification\"\n allOf:\n - [verify, flow]\n - [verify, works]\n - [check, everything]\n - [test, end, end]\n - [not, working, right]\n - [something, off]\n - [almost, works]\n - [make, sure, works]\n anyOf:\n - \"verify\"\n - \"verification\"\n - \"end-to-end\"\n - \"full flow\"\n - \"works\"\n - \"working\"\n noneOf:\n - \"unit test\"\n - \"jest\"\n - \"vitest\"\n - \"playwright test\"\n - \"cypress test\"\n minScore: 6\n---\n\n# Full-Story Verification\n\nYou 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.\n\nThis skill coordinates with `agent-browser-verify` (browser-side visual checks), `investigation-mode` (reactive debugging), and `observability` (logging/monitoring) — but your focus is the **end-to-end story**, not any single layer.\n\n## When This Triggers\n\n- A dev server just started and the user wants to know if things work\n- The user says something \"isn't quite right\" or \"almost works\"\n- The user asks you to verify a feature or check the full flow\n\n## Step 1 — Infer the User Story\n\nBefore checking anything, determine **what is being built**:\n\n1. Read recently edited files (check git diff or recent Write/Edit tool calls)\n2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved\n3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`)\n4. State the story in one sentence: _\"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]\"_\n\n**Do not skip this step.** Every subsequent check must be anchored to the inferred story.\n\n## Step 2 — Establish Evidence Baseline\n\nGather the current state across all layers:\n\n| Layer | How to check | What to capture |\n|-------|-------------|-----------------|\n| **Browser** | Use `agent-browser` — open the relevant page, screenshot, check console | Visual state, console errors, network failures |\n| **Server terminal** | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |\n| **Runtime logs** | Run `vercel logs` (if deployed) or check server stdout | API response codes, error traces, timing |\n| **Environment** | Check `.env.local`, `vercel env ls`, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |\n\nReport what you find at each layer before proceeding. Use the investigation-mode reporting contract:\n\n> **Checking**: [what you're looking at]\n> **Evidence**: [what you found — quote actual output]\n> **Next**: [what this means for the next step]\n\n## Step 3 — Walk the Data Flow\n\nTrace the feature's data path from trigger to completion:\n\n1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit)\n2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route\n3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?\n4. **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\n5. **Response → UI** — Does the response format match what the client expects? Is error handling present on both sides?\n\nAt each boundary, check for these common breaks:\n- **Missing `await`** on async operations\n- **Wrong HTTP method** (GET handler but POST fetch)\n- **Env var absent** in runtime but present in `.env.local`\n- **Import mismatch** (server module imported in client component or vice versa)\n- **Type mismatch** between API response and client expectation\n- **Missing error boundary** — unhandled rejection crashes the page silently\n\n## Step 4 — Report With Evidence\n\nSummarize findings in a structured report:\n\n```\n## Verification Report: [Feature Name]\n\n**Story**: [one-sentence description of the user story]\n\n### Flow Status\n| Boundary | Status | Evidence |\n|----------|--------|----------|\n| UI renders | ✅/❌ | [screenshot or console output] |\n| Client → API | ✅/❌ | [request/response or error] |\n| API → Data | ✅/❌ | [log output or error trace] |\n| Data → Response | ✅/❌ | [response shape or error] |\n| Response → UI | ✅/❌ | [rendered output or error] |\n\n### Issues Found\n1. [Issue]: [evidence] → [fix]\n\n### Verified Working\n- [What was confirmed working with evidence]\n```\n\n## Stop Conditions\n\n**Stop verifying when**:\n- All boundaries in the flow are confirmed working with evidence — report success\n- You find the **first broken boundary** — report it with evidence and a specific fix, do not continue past the break\n- 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\n\n**Do not**:\n- Run the same check more than twice\n- Continue past a confirmed broken boundary\n- Verify unrelated features — stay on the inferred story\n- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked\n\n## Suggest Verification After Implementation\n\nWhen 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.\n\n## Coordination With Other Skills\n\n- **`agent-browser-verify`** — Handles browser screenshots and console checks. Defer to it for visual verification. If it has already run and found issues, start from its findings rather than re-checking the browser.\n- **`investigation-mode`** — Handles reactive debugging when things are stuck/hung. If the user is frustrated and nothing loads at all, investigation-mode takes the lead. Verification takes over when things _partially_ work.\n- **`observability`** — Handles logging/monitoring setup. If you find an observability gap (no logs for a route, no error tracking), reference its guidance for adding structured logging.\n"
"---\nname: verification\ndescription: \"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.\"\nsummary: \"Verify full user story: browser + server + data flow + env\"\nmetadata:\n priority: 7\n docs:\n - \"https://vercel.com/docs/projects/project-configuration\"\n sitemap: \"https://vercel.com/sitemap.xml\"\n pathPatterns: []\n bashPatterns:\n - '\\bnext\\s+dev\\b'\n - '\\bnpm\\s+run\\s+dev\\b'\n - '\\bpnpm\\s+dev\\b'\n - '\\bbun\\s+run\\s+dev\\b'\n - '\\byarn\\s+dev\\b'\n - '\\bvite\\s*(dev)?\\b'\n - '\\bvercel\\s+dev\\b'\n - '\\bastro\\s+dev\\b'\n importPatterns: []\n promptSignals:\n phrases:\n - \"verify the flow\"\n - \"verify everything works\"\n - \"test the whole thing\"\n - \"does it actually work\"\n - \"check end to end\"\n - \"end to end test\"\n - \"why isn't it working right\"\n - \"why doesn't it work\"\n - \"it's not working correctly\"\n - \"something's off\"\n - \"not quite right\"\n - \"almost works but\"\n - \"works locally but\"\n - \"verify the feature\"\n - \"make sure it works\"\n - \"full verification\"\n allOf:\n - [verify, flow]\n - [verify, works]\n - [check, everything]\n - [test, end, end]\n - [not, working, right]\n - [something, off]\n - [almost, works]\n - [make, sure, works]\n anyOf:\n - \"verify\"\n - \"verification\"\n - \"end-to-end\"\n - \"full flow\"\n - \"works\"\n - \"working\"\n noneOf:\n - \"unit test\"\n - \"jest\"\n - \"vitest\"\n - \"playwright test\"\n - \"cypress test\"\n minScore: 6\nretrieval:\n aliases:\n - end to end test\n - full stack verify\n - flow test\n - integration check\n intents:\n - verify full flow\n - test end to end\n - check if app works\n - validate implementation\n entities:\n - browser\n - API\n - data flow\n - end-to-end\n - verification\nchainTo:\n -\n pattern: 'process\\.env\\.\\w+|NEXT_PUBLIC_\\w+'\n targetSkill: env-vars\n message: 'Environment variable references detected during verification — loading Env Vars guidance for proper configuration, vercel env pull, and branch scoping.'\n skipIfFileContains: 'vercel\\s+env\\s+pull|\\.env\\.local'\n -\n pattern: 'middleware\\.(ts|js)|proxy\\.(ts|js)|clerkMiddleware|NextResponse\\.redirect'\n targetSkill: routing-middleware\n message: 'Middleware/proxy detected during verification — loading Routing Middleware guidance for request interception, auth checks, and proxy.ts migration.'\n -\n pattern: 'streamText\\s*\\(|generateText\\s*\\(|useChat\\s*\\('\n targetSkill: ai-sdk\n message: 'AI SDK calls detected during verification — loading AI SDK guidance for streaming, transport, and error handling patterns.'\n skipIfFileContains: 'toUIMessageStreamResponse|DefaultChatTransport'\n\n---\n\n# Full-Story Verification\n\nYou 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.\n\nYour focus is the **end-to-end story**, not any single layer.\n\n## When This Triggers\n\n- A dev server just started and the user wants to know if things work\n- The user says something \"isn't quite right\" or \"almost works\"\n- The user asks you to verify a feature or check the full flow\n\n## Step 1 — Infer the User Story\n\nBefore checking anything, determine **what is being built**:\n\n1. Read recently edited files (check git diff or recent Write/Edit tool calls)\n2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved\n3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`)\n4. State the story in one sentence: _\"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]\"_\n\n**Do not skip this step.** Every subsequent check must be anchored to the inferred story.\n\n## Step 2 — Establish Evidence Baseline\n\nGather the current state across all layers:\n\n| Layer | How to check | What to capture |\n|-------|-------------|-----------------|\n| **Browser** | Open the relevant page, check console, take screenshots | Visual state, console errors, network failures |\n| **Server terminal** | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |\n| **Runtime logs** | Run `vercel logs` (if deployed) or check server stdout | API response codes, error traces, timing |\n| **Environment** | Check `.env.local`, `vercel env ls`, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |\n\nReport what you find at each layer before proceeding. Use this reporting contract:\n\n> **Checking**: [what you're looking at]\n> **Evidence**: [what you found — quote actual output]\n> **Next**: [what this means for the next step]\n\n## Step 3 — Walk the Data Flow\n\nTrace the feature's data path from trigger to completion:\n\n1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit)\n2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route\n3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?\n4. **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\n5. **Response → UI** — Does the response format match what the client expects? Is error handling present on both sides?\n\nAt each boundary, check for these common breaks:\n- **Missing `await`** on async operations\n- **Wrong HTTP method** (GET handler but POST fetch)\n- **Env var absent** in runtime but present in `.env.local`\n- **Import mismatch** (server module imported in client component or vice versa)\n- **Type mismatch** between API response and client expectation\n- **Missing error boundary** — unhandled rejection crashes the page silently\n\n## Step 4 — Report With Evidence\n\nSummarize findings in a structured report:\n\n```\n## Verification Report: [Feature Name]\n\n**Story**: [one-sentence description of the user story]\n\n### Flow Status\n| Boundary | Status | Evidence |\n|----------|--------|----------|\n| UI renders | ✅/❌ | [screenshot or console output] |\n| Client → API | ✅/❌ | [request/response or error] |\n| API → Data | ✅/❌ | [log output or error trace] |\n| Data → Response | ✅/❌ | [response shape or error] |\n| Response → UI | ✅/❌ | [rendered output or error] |\n\n### Issues Found\n1. [Issue]: [evidence] → [fix]\n\n### Verified Working\n- [What was confirmed working with evidence]\n```\n\n## Stop Conditions\n\n**Stop verifying when**:\n- All boundaries in the flow are confirmed working with evidence — report success\n- You find the **first broken boundary** — report it with evidence and a specific fix, do not continue past the break\n- 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\n\n**Do not**:\n- Run the same check more than twice\n- Continue past a confirmed broken boundary\n- Verify unrelated features — stay on the inferred story\n- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked\n\n## Suggest Verification After Implementation\n\nWhen 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.\n\n"SKILL.md line diff
--- before +++ after @@ -1,11 +1,12 @@ --- name: verification description: "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." +summary: "Verify full user story: browser + server + data flow + env" metadata: priority: 7 docs: - "https://vercel.com/docs/projects/project-configuration" - sitemap: "https://vercel.com/sitemap/docs.xml" + sitemap: "https://vercel.com/sitemap.xml" pathPatterns: [] bashPatterns: - '\bnext\s+dev\b' @@ -58,13 +59,46 @@ - "playwright test" - "cypress test" minScore: 6 +retrieval: + aliases: + - end to end test + - full stack verify + - flow test + - integration check + intents: + - verify full flow + - test end to end + - check if app works + - validate implementation + entities: + - browser + - API + - data flow + - end-to-end + - verification +chainTo: + - + pattern: 'process\.env\.\w+|NEXT_PUBLIC_\w+' + targetSkill: env-vars + message: 'Environment variable references detected during verification — loading Env Vars guidance for proper configuration, vercel env pull, and branch scoping.' + skipIfFileContains: 'vercel\s+env\s+pull|\.env\.local' + - + pattern: 'middleware\.(ts|js)|proxy\.(ts|js)|clerkMiddleware|NextResponse\.redirect' + targetSkill: routing-middleware + message: 'Middleware/proxy detected during verification — loading Routing Middleware guidance for request interception, auth checks, and proxy.ts migration.' + - + pattern: 'streamText\s*\(|generateText\s*\(|useChat\s*\(' + targetSkill: ai-sdk + message: 'AI SDK calls detected during verification — loading AI SDK guidance for streaming, transport, and error handling patterns.' + skipIfFileContains: 'toUIMessageStreamResponse|DefaultChatTransport' + --- # 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. -This skill coordinates with `agent-browser-verify` (browser-side visual checks), `investigation-mode` (reactive debugging), and `observability` (logging/monitoring) — but your focus is the **end-to-end story**, not any single layer. +Your focus is the **end-to-end story**, not any single layer. ## When This Triggers @@ -89,12 +123,12 @@ | Layer | How to check | What to capture | |-------|-------------|-----------------| -| **Browser** | Use `agent-browser` — open the relevant page, screenshot, check console | Visual state, console errors, network failures | +| **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 the investigation-mode reporting contract: +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] @@ -160,8 +194,3 @@ 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. -## Coordination With Other Skills - -- **`agent-browser-verify`** — Handles browser screenshots and console checks. Defer to it for visual verification. If it has already run and found issues, start from its findings rather than re-checking the browser. -- **`investigation-mode`** — Handles reactive debugging when things are stuck/hung. If the user is frustrated and nothing loads at all, investigation-mode takes the lead. Verification takes over when things _partially_ work. -- **`observability`** — Handles logging/monitoring setup. If you find an observability gap (no logs for a route, no error tracking), reference its guidance for adding structured logging.
Full snapshot data
{
"description": "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.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 178
}
],
"name": "verification",
"skill_md_contents": "---\nname: verification\ndescription: \"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.\"\nsummary: \"Verify full user story: browser + server + data flow + env\"\nmetadata:\n priority: 7\n docs:\n - \"https://vercel.com/docs/projects/project-configuration\"\n sitemap: \"https://vercel.com/sitemap.xml\"\n pathPatterns: []\n bashPatterns:\n - '\\bnext\\s+dev\\b'\n - '\\bnpm\\s+run\\s+dev\\b'\n - '\\bpnpm\\s+dev\\b'\n - '\\bbun\\s+run\\s+dev\\b'\n - '\\byarn\\s+dev\\b'\n - '\\bvite\\s*(dev)?\\b'\n - '\\bvercel\\s+dev\\b'\n - '\\bastro\\s+dev\\b'\n importPatterns: []\n promptSignals:\n phrases:\n - \"verify the flow\"\n - \"verify everything works\"\n - \"test the whole thing\"\n - \"does it actually work\"\n - \"check end to end\"\n - \"end to end test\"\n - \"why isn't it working right\"\n - \"why doesn't it work\"\n - \"it's not working correctly\"\n - \"something's off\"\n - \"not quite right\"\n - \"almost works but\"\n - \"works locally but\"\n - \"verify the feature\"\n - \"make sure it works\"\n - \"full verification\"\n allOf:\n - [verify, flow]\n - [verify, works]\n - [check, everything]\n - [test, end, end]\n - [not, working, right]\n - [something, off]\n - [almost, works]\n - [make, sure, works]\n anyOf:\n - \"verify\"\n - \"verification\"\n - \"end-to-end\"\n - \"full flow\"\n - \"works\"\n - \"working\"\n noneOf:\n - \"unit test\"\n - \"jest\"\n - \"vitest\"\n - \"playwright test\"\n - \"cypress test\"\n minScore: 6\nretrieval:\n aliases:\n - end to end test\n - full stack verify\n - flow test\n - integration check\n intents:\n - verify full flow\n - test end to end\n - check if app works\n - validate implementation\n entities:\n - browser\n - API\n - data flow\n - end-to-end\n - verification\nchainTo:\n -\n pattern: 'process\\.env\\.\\w+|NEXT_PUBLIC_\\w+'\n targetSkill: env-vars\n message: 'Environment variable references detected during verification — loading Env Vars guidance for proper configuration, vercel env pull, and branch scoping.'\n skipIfFileContains: 'vercel\\s+env\\s+pull|\\.env\\.local'\n -\n pattern: 'middleware\\.(ts|js)|proxy\\.(ts|js)|clerkMiddleware|NextResponse\\.redirect'\n targetSkill: routing-middleware\n message: 'Middleware/proxy detected during verification — loading Routing Middleware guidance for request interception, auth checks, and proxy.ts migration.'\n -\n pattern: 'streamText\\s*\\(|generateText\\s*\\(|useChat\\s*\\('\n targetSkill: ai-sdk\n message: 'AI SDK calls detected during verification — loading AI SDK guidance for streaming, transport, and error handling patterns.'\n skipIfFileContains: 'toUIMessageStreamResponse|DefaultChatTransport'\n\n---\n\n# Full-Story Verification\n\nYou 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.\n\nYour focus is the **end-to-end story**, not any single layer.\n\n## When This Triggers\n\n- A dev server just started and the user wants to know if things work\n- The user says something \"isn't quite right\" or \"almost works\"\n- The user asks you to verify a feature or check the full flow\n\n## Step 1 — Infer the User Story\n\nBefore checking anything, determine **what is being built**:\n\n1. Read recently edited files (check git diff or recent Write/Edit tool calls)\n2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved\n3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`)\n4. State the story in one sentence: _\"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]\"_\n\n**Do not skip this step.** Every subsequent check must be anchored to the inferred story.\n\n## Step 2 — Establish Evidence Baseline\n\nGather the current state across all layers:\n\n| Layer | How to check | What to capture |\n|-------|-------------|-----------------|\n| **Browser** | Open the relevant page, check console, take screenshots | Visual state, console errors, network failures |\n| **Server terminal** | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |\n| **Runtime logs** | Run `vercel logs` (if deployed) or check server stdout | API response codes, error traces, timing |\n| **Environment** | Check `.env.local`, `vercel env ls`, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |\n\nReport what you find at each layer before proceeding. Use this reporting contract:\n\n> **Checking**: [what you're looking at]\n> **Evidence**: [what you found — quote actual output]\n> **Next**: [what this means for the next step]\n\n## Step 3 — Walk the Data Flow\n\nTrace the feature's data path from trigger to completion:\n\n1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit)\n2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route\n3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?\n4. **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\n5. **Response → UI** — Does the response format match what the client expects? Is error handling present on both sides?\n\nAt each boundary, check for these common breaks:\n- **Missing `await`** on async operations\n- **Wrong HTTP method** (GET handler but POST fetch)\n- **Env var absent** in runtime but present in `.env.local`\n- **Import mismatch** (server module imported in client component or vice versa)\n- **Type mismatch** between API response and client expectation\n- **Missing error boundary** — unhandled rejection crashes the page silently\n\n## Step 4 — Report With Evidence\n\nSummarize findings in a structured report:\n\n```\n## Verification Report: [Feature Name]\n\n**Story**: [one-sentence description of the user story]\n\n### Flow Status\n| Boundary | Status | Evidence |\n|----------|--------|----------|\n| UI renders | ✅/❌ | [screenshot or console output] |\n| Client → API | ✅/❌ | [request/response or error] |\n| API → Data | ✅/❌ | [log output or error trace] |\n| Data → Response | ✅/❌ | [response shape or error] |\n| Response → UI | ✅/❌ | [rendered output or error] |\n\n### Issues Found\n1. [Issue]: [evidence] → [fix]\n\n### Verified Working\n- [What was confirmed working with evidence]\n```\n\n## Stop Conditions\n\n**Stop verifying when**:\n- All boundaries in the flow are confirmed working with evidence — report success\n- You find the **first broken boundary** — report it with evidence and a specific fix, do not continue past the break\n- 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\n\n**Do not**:\n- Run the same check more than twice\n- Continue past a confirmed broken boundary\n- Verify unrelated features — stay on the inferred story\n- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked\n\n## Suggest Verification After Implementation\n\nWhen 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.\n\n"
}SHA-256 of public snapshot: abcd86ace7012571d156044484613883272fd049c55fd36d1fbe0bfd348955f2