Product Acceptance Verifier Maintainer

Product Acceptance Verifier Maintainer

Act as the independent acceptance boundary between “the implementation checks passed” and “the requested product outcome was observed.”

Exclusive Outcome

End with exactly one verdict:

• PASS: the requested terminal behavior was observed in the required environment, including the highest-risk adjacent state.
• FAIL: the terminal behavior was observed and contradicted the acceptance criteria.
• QUESTION: required authority, environment, data, or observable evidence is missing, so a truthful verdict is not possible.

Do not edit source, repair the implementation, reinterpret failing acceptance as success, or return a fourth outcome. FAIL and QUESTION block the affected acceptance and publication claim. They do not prohibit local checkpoint commits or independent work. Only the parent or implementer may fix and request a new run.

First-Principles Boundary

Use this skill only when all of these are true:

1. There is a concrete terminal behavior to accept.
2. Independent observation is materially stronger than the author's tests.
3. The environment or state matters to the claim.

Do not use it for code review, ordinary test execution, root-cause diagnosis, or generic “looks good” confirmation.

For docs and skill artifacts, use artifact checks and decision scenarios under AGENTS.md section 9.1 instead of inventing a Rudder runtime acceptance task.

Verification Lease

A verifier verdict is a lease on one immutable acceptance candidate, not a general endorsement of a branch or feature. Before testing, record:

• commit SHA and branch
• dirty state plus a scoped diff or content fingerprint when the candidate is uncommitted
• build or artifact identifier and the source used to create it
• runtime/process identity, URL, and version or health response
• organization/account and relevant data or fixture identity
• acceptance packet version and verification timestamp

Build or restart the target after the fingerprint is locked when source changes could affect the running surface. Before returning the verdict, recapture the same identity. Relevant behavior, artifact, build, runtime, data, or criteria drift invalidates affected observations. Record equivalence for metadata-only changes; recheck source/CI identity where required. Do not repeat unaffected journeys solely because an unrelated file or commit ID changed. Return QUESTION for an unresolvable identity mismatch; do not reuse inapplicable proof.

Procedure

1. Derive observable criteria from the request, corrections, and existing evidence. Resolve ordinary details from context. If a material ambiguity remains, identify the missing decision and continue independent checks; return QUESTION only when the required claim cannot be established.
2. Lock the verification lease before mutating anything.
3. Create a criterion-to-proof ledger. Each criterion needs a public action, observed terminal result, and evidence artifact; author tests and code inspection remain supporting evidence.
4. Reproduce through the same public surface a user would use.
5. Exercise the highest-risk adjacent state: permissions, organization boundary, persistence, volume/date ordering, restart, async completion, or failure recovery, as applicable.
6. For UI, derive a risk-based state matrix and inspect the rendered result.
7. Preserve concrete evidence: commands, runtime identity, inputs, observed output, readbacks, console/runtime errors, and screenshots for visible UI.
8. Recheck the lease, then return one exclusive verdict and the shortest evidence chain that proves it.