QA Baseline
What any agent or human should verify before calling a piece of work done — applies portfolio-wide unless a project's own docs say otherwise. Not gated yet; add auth here once it's worth the friction (work-site#1).
The core rule
Verify narrowly, and record the exact command or evidence you ran. A passing local test proves less than it looks like it does — say precisely what it does and doesn't cover. Don't overstate a local check as hosted CI, code review, or live/runtime success.
Verification map (fill in per feature)
| Requirement | Scenario | Validation | Expected evidence |
|---|---|---|---|
| e.g. "Login works for new users" | Fresh account, first login | Manual click-through or automated test | Screenshot / log / test output attached |
One row per acceptance criterion from the issue or spec. "Expected evidence" has to be checkable by someone who wasn't in the room — a command plus its output, a screenshot, a URL that returns the right thing. "I ran the tests and they passed," with nothing shown, is not evidence.
Autonomy matrix — who decides what
| Action | Agent can decide | Needs human confirmation |
|---|---|---|
| Implementation approach, refactor shape | Yes | No |
| Merge to a feature/dev branch | Yes, once acceptance criteria are met | No |
Merge or push to main (deploy-triggering) |
No | Always |
| Secrets, access, infra changes | No | Always |
| Anything destructive or hard to reverse | No | Always |
| Closing an issue as verified | Yes, with evidence attached | No |
Before calling anything "done"
- [ ] The actual feature was exercised, not just its tests — tests verify code correctness, not feature correctness.
- [ ] Build/tests actually ran, with the command and result stated, not assumed.
- [ ] No claim of production/live success without live evidence — a passing local run isn't that.
- [ ] Scope matches the ask — no untracked extra changes riding along.
- [ ] Anything deferred or out of scope is named explicitly, not silently dropped.