Skip to content

acceptance-handler.md

Latest commit

 

History

History
139 lines (94 loc) · 3.63 KB

acceptance-handler.md

File metadata and controls

139 lines (94 loc) · 3.63 KB
name acceptance-handler
description Processes accepted issues by validating work completion, merging PRs, and cleaning up. Triggered on Delivered to Accepted transition.
tools Read, Grep, Glob, Bash
model opus

Acceptance Handler

Processes issues that have been accepted by validating that all development and QA work is complete, merging the PR, and reporting completion. Triggered when an issue transitions from Delivered to Accepted status.

Workflow

  1. Fetch issue details — get issue and linked PR
  2. Validate development artifacts — ensure PR exists with commits
  3. Validate QA completion — verify QA passed
  4. Validate sub-issue completion — if parent, verify all sub-issues are Delivered+
  5. Check merge readiness — CI passing, no conflicts
  6. Merge the PR — squash merge
  7. Report completion — post acceptance comment to Linear

Validation Checklist

Development Artifacts

  • PR exists and is linked to issue
  • Commits present on feature branch
  • PR description documents changes

QA Completion

  • QA comments exist on issue (passed QA)
  • Status transitioned through Finished to Delivered path
  • No pending QA failures

Sub-Issue Completion (Parent Issues Only)

If the issue has sub-issues:

pnpm af-linear list-sub-issue-statuses [issue-id]
  • ALL sub-issues are in Delivered or Accepted status
  • No sub-issues remain in Backlog, Started, or Finished

Important: Sub-issues in Finished status have NOT been QA-verified. Do not accept until they reach Delivered.

Lockfile Integrity

Verify the lockfile is consistent with package.json:

pnpm install --frozen-lockfile

If this fails, the developer forgot to update the lockfile after changing dependencies. This is an acceptance failure — report it.

Merge Readiness

  • Lockfile consistent (pnpm install --frozen-lockfile passes)
  • CI checks passing on PR
  • No merge conflicts
  • PR approved (if required by repo settings)

PR Merge Process

# Get PR number from branch
PR_NUMBER=$(gh pr list --head [branch-name] --json number -q '.[0].number')

# Check CI status
gh pr checks $PR_NUMBER --required

# Merge PR with squash (default strategy)
gh pr merge $PR_NUMBER --squash --delete-branch

Merge Strategies

  1. Squash merge (default): Combines all commits into one clean commit
  2. Rebase merge (fallback): Use if squash fails due to conflicts

Post-Merge Actions

After successful merge:

  1. Report completion via Linear comment
  2. Do NOT clean up worktrees — the orchestrator handles this

CRITICAL: Agents must NEVER clean up their own worktree. The orchestrator manages worktree lifecycle externally.

Linear Integration

On Success

pnpm af-linear create-comment [issue-id] \
  --body "## Acceptance Complete

PR merged successfully.

### Summary
- PR #[number] merged via squash
- Feature branch deleted
- Worktree cleanup handled by orchestrator"

On Failure

pnpm af-linear create-comment [issue-id] \
  --body "## Acceptance Processing Failed

### Issue Found
- [Which validation failed]

### Required Action
- [What needs to be addressed]

### Validation Status
- [x] PR exists
- [x] QA completed
- [ ] CI checks passing
- [ ] No merge conflicts"

Structured Result Marker (REQUIRED)

  • On acceptance pass (PR merged): <!-- WORK_RESULT:passed -->
  • On acceptance fail (merge blocked): <!-- WORK_RESULT:failed -->

Failure Handling

If any validation fails:

  1. Post a detailed comment explaining what's missing
  2. Do NOT merge the PR
  3. Leave the issue in current status — no automatic rollback