Acceptance Tester

Acceptance Tester

Final quality gate — determines whether a project is ready to proceed.

Acceptance Criteria Source

The definition of done comes from the combined plan (section 8), which typically includes:

• All modules implemented
• All tests passing
• Linting clean
• Application starts and core flows work
• Documentation updated
• Security constraints verified

Acceptance Checklist

Run through this checklist systematically:

1. Build Verification

• [ ] Project builds without errors
• [ ] No compiler/linter warnings (or all are documented exceptions)
• [ ] All dependencies resolve correctly

2. Test Suite

• [ ] Full test suite passes (cargo test / npm test / pytest)
• [ ] Coverage meets target from combined plan (default: 80%)
• [ ] No skipped or ignored tests without documented reason

3. Core Flow Verification

For each core user flow defined in the spec:

• [ ] Happy path works end-to-end
• [ ] Primary error paths handled gracefully
• [ ] Data persists correctly across operations

4. Spec Completeness

• [ ] All P0 spec requirements verified (from spec-vs-impl checker)
• [ ] No Blocker or Critical bugs outstanding
• [ ] All Major bugs either fixed or explicitly deferred with user approval

5. Security Constraints

For each constraint from Zero's review:

• [ ] Constraint is implemented
• [ ] Constraint is tested
• [ ] No obvious bypasses found during functional testing

6. Integration Points

• [ ] Cross-module integrations work correctly
• [ ] Error propagation across module boundaries is handled
• [ ] Data format consistency across interfaces

Verdict Determination

PASS — Ready for Next Phase

All of these must be true:

• Build succeeds
• All tests pass
• Coverage target met
• Zero Blocker bugs
• Zero Critical bugs
• All P0 spec requirements verified
• All security constraints verified

CONDITIONAL PASS

• Minor or some Major bugs remain but none are blockers
• User has approved deferring specific issues to v2
• Core flows work, edge cases may have issues

FAIL — Return to Forge

Any of these triggers a fail:

• Build fails
• Tests fail
• Blocker bugs found
• Critical bugs found
• P0 spec requirement missing or broken
• Security constraint not met

Output Format

# Acceptance Test Report — 

**Date:** YYYY-MM-DD
**Verdict:** PASS / CONDITIONAL PASS / FAIL
**QA Engineer:** Watchdog

## Checklist Results

| Category | Status | Details |
|---|---|---|
| Build | PASS/FAIL | [details] |
| Test Suite | PASS/FAIL | X/Y tests passing, Z% coverage |
| Core Flows | PASS/FAIL | X/Y flows verified |
| Spec Completeness | PASS/FAIL | X% requirements verified |
| Security | PASS/FAIL | X/Y constraints verified |
| Integration | PASS/FAIL | [details] |

## Outstanding Issues

| Bug | Severity | Status | Decision |
|---|---|---|---|
| BUG-003 | Minor | OPEN | Deferred to v2 |

## Recommendation

[PASS]: Project is ready for documentation (Ink) and release.
[CONDITIONAL PASS]: Project can proceed with noted caveats.
[FAIL]: Return to Forge. Fix items: [list].

Handoff

• On PASS: Control returns to Clawpick, who invokes Ink for documentation.
• On CONDITIONAL PASS: Clawpick presents conditions to user for approval. If approved, proceeds to Ink.
• On FAIL: Clawpick routes bug reports to Forge. After fixes, Watchdog re-tests failed items only (not full re-test unless regression is suspected).

---

Watchdog skill — Acceptance testing and release readiness assessment

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Firstp1ck
• Source: Firstp1ck/pi-coding-agent-forge
• License: MIT

Install and usage instructions live in the source repository linked above.