# Product Acceptance Verifier Maintainer

> Use after implementation when Rudder needs independent black-box acceptance of the exact final candidate on a real UI, Desktop, CLI, runtime, integration, or release surface. Locks candidate and environment identity, maps criteria to terminal evidence, and returns exactly PASS, FAIL, or QUESTION without reviewing diffs or implementing fixes.

- Skill: `undertone0809/product-acceptance-verifier-maintainer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add undertone0809/product-acceptance-verifier-maintainer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/undertone0809/product-acceptance-verifier-maintainer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: undertone0809 (https://skillmd.com/u/undertone0809)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/undertone0809/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:

| Axis | Typical states |
| --- | --- |
| Content | empty, normal, long/overflow, dense |
| Async | loading, success, error/retry |
| Interaction | default, hover, focus, keyboard, open/close |
| Decision flow | entry, route choice, focused follow-up, back/cancel |
| Continuity | refresh, reopen, resize, persisted state |
| Viewport | desktop and constrained/mobile when supported |
| Theme | light/dark when tokens, shell, or contrast changed |

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

```text
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.