implementation-verification

name	implementation-verification
description	Verify generated or modified application code with reproducible build, test, runtime, browser, API, console, and network checks. Use after code generation or bug fixes, especially for web UI login flows, forms, dashboards, frontend/backend integration, local dev servers, and claims that implementation is complete or tested.

Implementation Verification

Purpose

Use this skill after code generation or code modification to verify that the implementation actually works. Do not accept visual inspection, static reasoning, or "should work" statements as proof.

Before code verification, check that upstream implementation-driving artifacts were approved by the user. If API/database/design artifacts are still drafts, report that implementation should not have started and ask whether to review the drafts first.

Verification Standard

The agent may say "verified" only after it has recorded reproducible evidence:

• Exact commands executed.
• Build/test/lint results.
• Unit test files created or updated for new/changed logic.
• Unit test command results.
• Runtime startup result and URL.
• Browser or API smoke test result for critical flows.
• Console errors checked.
• Network/API failures checked.
• Screenshots or trace artifacts when available.
• Remaining gaps or skipped checks.

If any check is not run, say not verified for that check and explain why.

Required Workflow

1. Inspect project structure and package/build files.
2. Identify how to start backend and frontend.
3. Identify new or changed implementation logic.
4. Ensure corresponding unit test code exists or is updated.
5. Run compile/build/typecheck/lint/unit tests where available.
6. Start required services or dev servers.
7. For web UI, open the app with a browser automation tool.
8. Exercise the critical user journey, not only the homepage.
9. Check browser console errors.
10. Check failed network requests and API response status.
11. Fix blocking issues and repeat failed checks.
12. Report evidence and unresolved risks.
13. Store raw verification output under the approved reports path, defaulting to reports/verification/, not under scripts/ or the repository root.

Unit Test Requirements

For generated or modified code, require unit tests for:

• Backend service/business logic.
• Validation and error handling logic.
• Permission/security decision logic.
• Data mapping or conversion logic.
• Frontend composables/hooks/state utilities.
• Non-trivial frontend form validation or data transformation.
• Reusable utility functions.

Default test choices:

• Java/Spring: JUnit 5, AssertJ, Mockito, Spring Boot Test only when Spring context is actually needed.
• Frontend: Vitest/Jest plus Testing Library where applicable.

Do not require unit tests for pure configuration, generated DTOs without logic, trivial constants, or visual-only markup unless behavior is involved.

If unit tests cannot be added or run, mark the unit test gate as not verified and explain the blocker. Do not mark implementation complete.

Web UI Smoke Checks

For any web page or frontend feature, verify:

• Page loads without blank screen.
• Main route renders expected content.
• Login or primary form can be completed with known test credentials or seed data.
• Backend API calls return expected status.
• No blocking console errors exist.
• Navigation after the action works.
• Auth/session state is persisted as expected.
• Refresh does not break the route.

If login is involved, do not mark the feature complete until login succeeds in the browser or the exact blocker is documented.

Browser Tool Policy

Use the best available browser verification tool:

• In Codex, prefer the Browser plugin or available browser automation tool for localhost/file targets.
• In Claude Code, prefer Playwright MCP, Chrome DevTools MCP, or the browser automation tool configured in that environment.
• If no browser tool exists, generate a Playwright smoke test and instruct the user to run it; mark browser verification as not verified.

API Verification

For backend/API work, verify:

• Application starts with the selected profile.
• Health endpoint or base API route responds.
• Auth endpoints work with test credentials or seeded users.
• CRUD happy path works for at least one core entity.
• Validation failure returns the expected error shape.
• Unauthorized access is rejected.

Evidence Report

Always end with:

• Verified: checks that passed with command/tool evidence.
• Failed: checks that failed and the exact error.
• Not verified: checks that could not be run.
• Unit tests: files added/updated and command results.
• Fixes applied: changes made after failures.
• Next action: the smallest remaining action.

Record the report in docs/06-verification/implementation-verification.md or the approved equivalent path.

Store screenshots, browser traces, console/network exports, server logs, and other raw evidence under reports/verification/ or the approved equivalent path. Do not leave transient logs in the repository root.

Do not hide failures behind optimistic wording.

After producing the implementation verification report, stop and request explicit user review. Do not proceed to integration testing, performance testing, or release readiness until the user approves the verification artifact or asks for fixes.

References

Use references/web-verification-checklist.md for the default browser and API smoke checklist.