verify-and-evidence

To verify code changes and capture durable evidence, you classify the change surface, select applicable checks like browser or CI verification, execute them, and store artifacts like logs and screenshots under the .project/logs path.

Frontend browser behavior changes require browser verification using Playwright to capture traces and screenshots, ensuring credible completion claims and providing durable evidence of the UI functionality.

You collect Playwright traces and logs for release verification by executing targeted browser checks and storing the resulting artifacts under the repository's local .project/logs/playwright directory.

Local verification is used for immediate change validation, while CI status checks ensure integration readiness; both modalities are required to distinguish local execution from pipeline readiness before merging.

Change surfaces like docs, backend, API, frontend, Docker, CI, or release are classified to map them to appropriate verification modalities such as unit tests, integration checks, or browser automation.

Yes, the verification approach supports re-running targeted checks after rebasing code to ensure the updated change surface still has sufficient evidence and valid CI status before completion.