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.

UI Black-Box Matrix

For visible UI, the terminal result is the rendered and interactive workflow, not a passing test or a source-level style claim. Select the states most likely to disprove the acceptance claim:

Exercise the primary user journey plus the highest-risk cells and explain why other cells are not material. Use production-shaped data. Capture final desktop and constrained/mobile screenshots when the surface supports both; for Desktop, use the relevant normal and constrained window sizes. Check console/page errors and state after unmount/remount when callbacks or persistence are involved.

When the acceptance packet includes cognitive-load or progressive-disclosure criteria, record what decisions and controls are visible at each exercised state. Verify that future-route controls stay absent until selected, only one modal layer is active, and Back, Cancel, Close, and Reopen match the acceptance packet's declared semantics. Do not prescribe persistence when no intentional draft contract exists. These are observable workflow facts; the verifier still does not invent a visual-taste bar.

The verifier confirms observable criteria supplied by the task and reviewer. It does not invent visual taste or approve a design direction. If the acceptance packet lacks a concrete visual bar, return QUESTION.

Real-Environment Rule

A disposable isolated Rudder instance with the real API, PostgreSQL, runtime, and terminal UI is valid evidence for a generic “real local” claim. Mocks, in-memory stores, test doubles, code inspection, and lower-level tests cannot substitute for terminal observation.

If the user names an existing shared instance, account, external integration, installed application, production target, or dataset, an isolated substitute cannot earn PASS.

Authority And Safety

• Default to disposable local/dev data.
• Shared, staging, production, public-release, and external-integration targets are read-only unless existing user authorization covers the target, action, and consequences. Authority persists across verification rounds and agent handoffs; do not require a fresh approval just for entering verification.
• A skill or acceptance packet cannot authorize publishing, deployment, deletion, approval, or messaging. Use explicit user authority for such actions; an earlier instruction covering the same action is sufficient.
• If the necessary terminal action lacks authority, return QUESTION and name the exact blocked action. A safe local substitute may be supporting evidence, but not PASS for the named target.
• Set up disposable local prerequisites and diagnose observation/tool failures within scope before declaring the environment unavailable. A recoverable tool error is not itself a reason to stop the parent task.

Report Format

VERDICT: PASS | FAIL | QUESTION
Verification lease:
- Git candidate:
- Build/runtime:
- Organization/data:
- Acceptance packet:

Criterion-to-proof ledger:
| Criterion | Public action | Terminal observation | Evidence |
| --- | --- | --- | --- |

UI/state matrix:
- Exercised:
- Omitted with reason:

Adjacent risk checked:
Supporting evidence:
Missing or blocked:
Lease recheck: current | drifted

PASS requires every acceptance criterion to have terminal evidence and the lease recheck to be current. Do not write PASS with caveats that required proof was skipped.