Verify Plan

Workflow

1. Resolve the current plan and implemented changes from the request, task context, and repository. Require exactly one ## Acceptance Criteria, ## MECE Review, and ## Verification Plan. Apart from blank lines, the Acceptance Criteria section must contain only one or more unique exact - [ ] AC-NNN: rows with non-whitespace criterion text after the colon. The MECE Review must contain exactly one - AC IDs: row and exactly one - Gate: row; the ID value lists the current IDs in ascending order joined by , and the complete gate value is - Gate: ready. The Verification Plan must contain exactly one - AC IDs: row with the identical value. Apart from blank lines and its AC-ID row, the Verification Plan must contain only exactly one ### AC-NNN entry per current AC and no other entry; apart from blank lines, each entry must contain only exactly one nonempty - Oracle:, - Evidence anchors:, - Prerequisites:, and - Required effects: row. Inspect every listed structural condition before deciding whether verification may start. If any condition fails, stop without reconstructing requirements after implementation and report every detected stale or malformed condition.
2. Treat prior verification reports as method hints only, never as current results. Before checks, capture one deterministic fingerprint of the exact current plan, current HEAD, and sorted file-level repository records. Enumerate untracked directories to files. For each staged path record its index status, mode, and blob digest or deletion marker; for each unstaged or untracked path record its working-tree status, file type, mode, and content digest or deletion marker; retain both records for a partially staged path. Do not report sensitive contents. Repeat the same fingerprint after all checks. Use each complete verification entry as the contract for its AC. Execute a required effect only when the live request authorizes it; otherwise leave the criterion unverified and state the missing authorization.
3. Inspect repository scripts, tests, documentation, fixtures, APIs, database queries, logs, and rendered interfaces to resolve the strongest permitted direct observation for each criterion. Prefer existing mechanisms; create a minimal local probe only when authorized and necessary.
4. Execute every feasible check. For stateful behavior, compare the relevant state before and after the action. For rendered UI behavior, set the required display conditions and interact with the actual page; source inspection, an HTTP success, or an action submission is not visual evidence.
5. Mark a criterion PASS only when the observed result matches its oracle, FAIL when it contradicts the oracle, and unverified when permitted evidence establishes neither. Preserve each result when another criterion fails.
6. Diagnose every FAIL from its evidence. When the root cause is in the implementation and its correction remains within the original authorization, make the smallest failure-scoped correction and rerun the failed criterion plus any previously passed checks the correction can affect. Continue only while new evidence identifies another authorized correction; stop before repeating an ineffective attempt, changing the requirement, expanding scope, or performing an unapproved action.
7. For an unavailable environment or transient dependency, try an available documented and safe recovery. If the required observation still cannot be made, leave the criterion unverified and state the exact access, service, credential, data, or interaction needed to complete it.
8. Remove temporary probes and restore verification-created data when possible. Report any residue or external-state change.
9. When the plan or live request includes code review or finding application, resolve a finding ledger from the latest supplied in-scope outputs. When both are supplied, use the latest review output as the finding set and its corresponding application output as disposition and evidence updates to matching items; use either output alone when the other activity is outside scope. Preserve item results but refuse complete verification while any critical or major finding is unresolved, deferred, or applied without a fresh direct check covering its affected use. When an in-scope output is unavailable, report that prerequisite unverified. Do not require or report a finding ledger when both activities are outside scope.
10. Compare the start and end fingerprints. A mismatch makes the run stale: preserve every criterion result but refuse complete verification and report the changed plan or repository inputs. Report both fingerprints, the method, observation, and result for every criterion, all corrections and reruns, every remaining failure or unverified prerequisite, and the finding-ledger gate only when step 9 applies. Claim complete verification only when every criterion passes, the fingerprints match, and any applicable finding gate has no blocker. Verification does not authorize commits, pushes, pull requests, or external mutations that the request did not authorize.