acceptance

name	acceptance
description	Lightweight acceptance gate for completed slices, bug fixes, PRs, or implementation branches. Use when Codex needs to verify that work matches the originating issue or PRD, prove acceptance criteria and regression checks, decide pass/fail/blocked before handoff, or record acceptance evidence in GitHub, a PR, or local markdown.

Acceptance

Use this after implementation and before handoff, merge, or closing an issue. The goal is not another code review; it is a verdict on whether the slice is acceptable against the durable spec.

Workflow

1. Find The Contract

Read the originating issue, PRD, PR description, agent brief, or local markdown work item. If the source is unclear, infer from branch name and commit messages; if still unclear, ask for the spec before accepting the work.

Extract:

• The capability or behavior promised
• Acceptance criteria
• Out of scope items
• Required tests or manual checks
• Regression checks against previous slices or known behavior

If no acceptance criteria exist, derive a short checklist from the issue or PRD, mark it as derived, and treat missing clarity as a risk.

2. Inspect The Change

Compare the diff against the contract, preferably from the merge base:

git diff <base>...HEAD
git log <base>..HEAD --oneline

Use the issue tracker configuration from docs/agents/issue-tracker.md when fetching or updating GitHub issues, PRs, or local markdown work items.

Check for:

• Required behavior implemented
• Scope creep or unrelated edits
• Out of scope items accidentally included
• User-visible behavior that lacks evidence
• New or changed interfaces that the spec did not justify

3. Run Evidence Checks

Run the smallest commands that prove each acceptance criterion, then run the relevant regression checks. Prefer project-native commands and existing CI equivalents.

Evidence can include:

• Automated tests for the touched capability
• Typecheck, lint, build, or format checks
• E2E, browser, CLI, curl, or fixture-based checks
• Manual test notes from the user or from a human-in-the-loop script
• CI result links when GitHub is the source of truth

Do not accept a slice solely because the diff looks plausible. If a criterion cannot be checked, mark it Blocked or Risk, not Passed.

4. Verify Regression Coverage

Identify the closest previously delivered capability that could be broken by this change. Confirm at least one reliable regression evidence source:

• Existing automated regression tests still pass
• A new regression test was added for the affected behavior
• A manual regression checklist was run and recorded
• A baseline behavior record or user/human verification record is captured and linked

Hard rule: if there is no reliable regression evidence, the verdict must be Blocked. Do not accept a slice solely because the risk is documented.

If a regression is found, stop acceptance and route the work through bug diagnosis or implementation follow-up.

5. Record The Verdict

Use exactly one verdict:

• Accepted — all acceptance criteria are satisfied and regression evidence is adequate.
• Accepted with risks — behavior is acceptable and traceable evidence exists, but some evidence is manual, partial, slow, flaky, or environment-dependent.
• Rejected — a required criterion fails, scope is wrong, or a regression is confirmed.
• Blocked — acceptance cannot be completed because required information, environment, credentials, or artifacts are missing.

Record the result where the work is tracked: GitHub issue comment, PR comment, local markdown issue, or handoff note.

When writing cross-links between issues and PRs, use the URL returned by the tool call or query the comment/PR/issue after posting. Do not hand-type or guess comment URLs.

Use this compact format:

## Acceptance

**Verdict:** Accepted / Accepted with risks / Rejected / Blocked

**Contract checked:** issue/PRD/PR reference

**Evidence:**
- command or check — result summary
- manual check or CI link — result summary

**Criteria:**
- [x] criterion 1 — evidence
- [ ] criterion 2 — failure or blocker

**Regression checks:**
- check — result summary

**Risks / follow-up:**
- risk or "None"

Rules

• Verify behavior through public interfaces where possible.
• Do not repeat full code review findings unless they affect acceptance.
• Do not use Accepted with risks when there is no reliable regression evidence. No reliable evidence means Blocked.
• Do not close, merge, or mark an issue done if the verdict is Rejected or Blocked.
• If acceptance reveals a bug, create or update a bug issue and use the bug diagnosis workflow.
• If acceptance reveals unclear requirements, move the work back to triage or PRD clarification rather than guessing.
• Keep durable requirements in PRDs, issues, or agent briefs. Keep CONTEXT.md for domain vocabulary only, not feature requirements.