---
requiresProjectContext: true
---

# Plan Verification: {{item_name}}

> Agent: {{agent_name}} ({{agent_role}}) | Team root: {{team_root}}

## Context

Project: {{project_name}}
Repo: {{repo_name}} | Org: {{ado_org}} | ADO Project: {{ado_project}}

## Plan Details

{{task_description}}

## Mission

Verify the completed plan as a whole: build and test the relevant project worktrees, identify how to run the user-facing app if there is one, create or update aggregate E2E PRs when needed, and write a transparent testing guide.

## Long-Running Commands

Builds, dependency installs, tests, and app startup can be silent for several minutes. Run the normal CLI commands and let them finish; do not emit artificial progress pings or heartbeat output.

## Approach

Use the setup information in the plan details to create or enter the aggregate worktrees and merge the relevant PR branches. Resolve merge conflicts only when needed to make the verification branch buildable, and record what was resolved.

For each relevant worktree, follow the repo's own instructions (`CLAUDE.md`, README, package files, Makefiles, project scripts), install/restore dependencies as needed, build, and run tests where they exist. If a project fails, report the error and continue verifying the rest; do not turn this into an implementation/fix task.

If there is a user-facing app, identify the normal command and URL. If the app needs to keep running after the agent exits, follow the shared detached-process handoff rules: start it detached in the worktree with stdio redirected to durable logs, save the PID/process identifier and log path, verify the URL responds, and include restart/stop commands with absolute paths.

## Testing Guide

Be transparent: clearly state what passed, what failed, what was not run, and why.

Always create the permanent guide linked from the dashboard:

`{{team_root}}/prd/guides/verify-{{plan_slug}}.md`

Create the inbox copy only after a successful verification run:

`{{team_root}}/notes/inbox/verify-{{plan_slug}}.md`

A successful verification run means every required project build/test passed or was legitimately not applicable, each runnable app was started and smoke-checked when required, and the required E2E PRs were created or updated. If verification is failed, blocked, or partial, do not create the inbox copy; record the details in the permanent guide and final response instead.

Use the template at `{{team_root}}/playbooks/templates/verify-guide.md` and clearly separate what was verified from what still needs human review.

## E2E PRs

For each project with aggregate verification changes, create or update one draft/review PR that combines the plan branches into a single reviewable diff. Reuse an existing `e2e/{{plan_slug}}` branch/PR when present. Include the plan summary, merged PRs, testing guide, and build/test status. Do not auto-complete or merge these PRs.

Track each E2E PR in the project's `.minions/pull-requests.json` if it is not already tracked.

## Cross-PR Compatibility Audit

Before declaring verification complete, audit the plan's PRs against each other — not just against master. A clean E2E build is necessary but not sufficient: two PRs can both compile and pass tests in isolation, both look fine in the merged E2E branch, and still represent contradictory or duplicate intent that will silently regress one of them once merged into master in the wrong order.

For each pair of plan PRs, check and record a verdict:

1. **Line-level overlap** — run `git diff --name-only <prA-base>..<prA-head>` and `<prB-base>..<prB-head>`; for any shared file, run `git diff <prA-head> <prB-head> -- <file>` and inspect. If both PRs touch the same line/symbol with different values, name the conflict explicitly (don't trust the auto-merge).
2. **Semantic supersession** — does PR-A do everything PR-B does, plus more? If yes, PR-B is superseded; recommend closing it. The classic trap: PR-B adds field X to a list, PR-A adds field X *and* removes dead field Y. Merging B after A reintroduces Y.
3. **Contradictory acceptance criteria** — do two plan items prescribe different shapes for the same contract (CLI flag, JSON field, prompt section)? If yes, one must lose; flag for human decision.
4. **Order dependency** — does PR-A's diff make sense only after PR-B lands (e.g., PR-A's tests reference a symbol PR-B introduces)? Record the required merge order.

For each PR pair, a one-line verdict in the form: `PR-A vs PR-B: independent | A supersedes B | B supersedes A | conflict <description> | order: B before A`. Cite the file:line for any conflict claim. "No conflicts" without per-pair audit evidence is not acceptable.

## Semantic Regression Audit

A green E2E build proves the code compiles and the existing tests still pass. It does NOT prove the new behavior is correct or that it doesn't silently break a code path the test suite never exercised. For every plan PR that touches engine code (anything under `engine/`, `engine.js`, `dashboard.js`, `bin/`, `dashboard/**`), do a behavioral audit before approving the merge:

1. **Trace the changed function's call graph one hop out.** For each modified function/exported symbol, run `git grep -n '<symbol>'` across the repo (not just within the PR's diff). For each caller, ask: does the new behavior still satisfy what this caller expects? Cite the caller as `path:line — assumption — still holds? yes/no/unsure`.
2. **Identify the silent failure modes.** A change that adds a guard, demotes a fallback, or removes a field has a *what-used-to-happen-here* shadow. Name it. For removals: which call sites read the removed field, and what do they fall back to now? For added guards: what input previously passed and now gets rejected — is that input ever produced legitimately? For demoted fallbacks: which production path relied on the fallback, and is the new primary path actually populated there?
3. **Check the test additions cover the new branch, not just the happy path.** A test that only asserts the new behavior on a freshly constructed input is half a test. The other half is: does an *existing* fixture that exercised the old behavior still pass, and does it pass for the right reason (not because the assertion got loosened)? Cite the test by file:line and the fixture it uses.
4. **Read the comments in the diff with suspicion.** Comments like "this also handles X" or "the gate at Y skips this path" are claims the agent made. Verify each one by opening Y and confirming the gate actually does what the comment says. If the claim is wrong, the change has a hole.
5. **Schema/contract changes deserve a grep across language boundaries.** A field added to a JSON contract in `engine/shared.js` may also be referenced in `dashboard/js/*.js`, `playbooks/*.md`, `test/**`, and any external consumer. Run a literal grep for the field name across the whole tree, not just the PR's touched files.

Record one verdict per engine-touching PR in the form: `PR-####: <safe | risk: <description with path:line citation> | needs human review: <question>>`. "Looks fine" without per-call-site evidence is not acceptable. If you cannot complete the audit in the time available, say so explicitly and list the unaudited PRs in the Merge Decisions section under "PRs requiring human decision".

## Merge Decision Note

The inbox copy at `{{team_root}}/notes/inbox/verify-{{plan_slug}}.md` MUST include a **Merge Decisions** section with three required subsections, written for a human deciding what to merge in what order:

1. **Recommended merge order** — numbered list of PRs that should land, in the order they should land, with a one-line reason for each ordering constraint (or `independent` if order doesn't matter).
2. **PRs to close as superseded** — bullet list of PRs that should be closed without merging, with the superseding PR cited and the regression that would occur if both lands.
3. **PRs requiring human decision** — bullet list of PRs blocked on a contradiction the agent could not resolve (cite the contradicting PR and the field/line in dispute), or on missing CI runs that need re-triggering.

If the audit finds nothing to decide ΓÇö all PRs are independent, none superseded, none contradictory ΓÇö the section MUST take this exact form instead:

```
Merge Decisions: clean ΓÇö all <N> PRs are pairwise independent and may merge in any order
```

A bare "no conflicts found" or an empty Merge Decisions section is not acceptable. The point of this section is to spare the human a second audit; if you skip it, the human has to redo the work you were dispatched to do.

## Constraints

- Do not assume any specific platform, language, framework, shell, build system, mobile app, web app, Android, or iOS target.
- Read project docs first; use `CLAUDE.md`, `README.md`, and nearby project configuration as the source of truth.
- Base manual testing steps on the plan acceptance criteria.
- If a project does not build, still document what should be testable once fixed.
- Do not fix product code except for merge-conflict resolutions needed to create the verification branch.
- Leave verification worktrees in place for user inspection.
- Use absolute paths in commands the user may copy.

## When to Stop

Your task is complete once dependency branches are merged, build/test verification has run, the cross-PR compatibility audit has produced a per-pair verdict, the semantic regression audit has produced a per-PR verdict for every engine-touching PR, the permanent guide is written with a Merge Decisions section, the inbox copy is written only if verification succeeded, and E2E PR URLs are included in your final response.

Include each E2E PR URL and the testing guide path in your final message, for example: `E2E PR created: <url>` and `Testing guide: {{team_root}}/prd/guides/verify-{{plan_slug}}.md`.
