QA Verification

Purpose

Manually verify that an implementation satisfies its acceptance criteria by exercising the implemented surface the way a user, client, job runner, or integration would.

Do not change implementation code or alter configuration to repair a defect while acting as the verifier. Normal verification may use documented setup, feature flags, or test controls and may mutate designated test data or trigger expected side effects when the acceptance criteria require it; record those mutations and any cleanup.

When an acceptance criterion depends on a real third-party contract or propagated state, gather evidence from that dependency. A controlled substitute is acceptable only when the criterion and requested scope explicitly concern behavior independent of the dependency; report the limitation and do not claim integration coverage. If required access, tooling, credentials, data, dependencies, or an executable surface is unavailable, return QA cannot proceed and name the blocker plus required next input. Passing tests, mocks, and source inspection cannot replace missing runtime evidence. When a caller explicitly requires CANNOT_VERIFY, use that blocker token with the same reason and required next input.

Inputs

Expect a compact QA request with:

• implemented surface area and entry point: URL, command, API, job trigger, script, or integration path
• ticket, PR, bug report, acceptance criteria, and testing instructions when available
• mode: ui, backend, mixed, or other
• environment setup, credentials, seed data, fixtures, feature flags, and known non-goals
• changed surfaces, adjacent flows, integrations, and state that may regress