mece-plan-review

Workflow

1. Resolve exactly one readable current plan from supplied task content or an authorized read interface. Ordinary whole-file or whole-resource reads are complete unless the response or tool marks them truncated or paginated; ranges, snippets, and unfinished pagination are partial. When inline content and a read response identify the same exact resource, treat them as one candidate only if their complete strings match; without the same resource identity they are separate candidates. A missing, partial, unreadable, or ambiguous plan is an upstream defect. Set update requested to true if and only if the request asks to write or save the review into the current plan; returning the review in the response is not an update request. Set update authorized to true if and only if update was requested, that same current plan is the exact authorized destination, and a write interface is available; otherwise set it to false.
2. A ## section begins at its heading and ends immediately before the next ## heading or end of document. Inspect every existing ## Acceptance Criteria section. Valid input is exactly one such section that, apart from blank lines, contains only one or more rows matching - [ ] AC-[0-9]{3}: <non-whitespace criterion text>, with unique AC IDs. If an update was requested, also count existing ## MECE Review sections and record missing exact-destination authorization, missing interface, or multiple sections as update-destination defects. If the plan or Acceptance Criteria input is invalid, report all detected upstream and update-destination defects, skip evidence comparison and review generation, and continue only to the completion rules.
3. Exclude every exact ## MECE Review section and every artifact explicitly labeled as a prior MECE Review from evidence. Create one manifest slot for every specification- or implementation-code-category source occurrence explicitly supplied or referenced by the request, current plan, or criteria; deduplicate only occurrences resolving to the same canonical resource. A source is one exact artifact, Markdown link target, file path, code span, or symbol; an unlabeled document, ordinary domain term, directory, or scalar value is not a source. Require at least one slot in each category. Within the current repository, recursively add definitions reached by direct calls from criterion-relevant branches. For every repository-local definition in the manifest whose behavior is shared across consumers, whether initially manifested or closure-added, also add every repository-local direct call or reference site resolved to that exact definition, including sites not named by the plan or criteria. Use a visited set to stop at cycles and repository boundaries. An absent, external, or ambiguous definition or reference resolution is an inaccessible required comparison. Freeze the manifest after this finite repository closure and perform evidence reads only against it. Current-plan resolution, structural preflight, authorized update, and exact-destination readback follow steps 1, 2, 6, and 7 and are not evidence-manifest reads.
4. A manifested source is usable only when supplied completely or returned by an ordinary whole-resource read not marked truncated or paginated; ranges, snippets, and unfinished pagination leave dependent comparisons unverified. For each current criterion behavior or branch, compare every manifested specification source, code source, and plan item, recording presence, absence, contradiction, or inaccessible status. Also compare manifested obligations back to exact criteria: enumerate reachable async lifecycle outcomes, direct consumers of shared behavior, boundary ownership and exhaustiveness, and evidence based on absence, time, count, concurrency, or non-impact. Treat an uncovered obligation, or negative evidence without both a positive witness that the relevant path and observation boundary completed and a deterministic failure signal or controlled seam, as an omission when supported and otherwise as unverified. Group reverse-check gaps by those four obligation families, emit at most one gap per affected family, and name every concrete omission within its family. Do not emit an entry for a covered family or an all-clear checklist. Do not mark a source non-applicable unless that source explicitly says the criterion is outside its scope. Finish every comparison that does not depend on inaccessible evidence.
5. Set one gate from evidence-comparison results only: blocked when supported omissions, duplication, or contradictions remain; otherwise unverified when any required comparison lacks evidence; otherwise ready. Update-destination defects do not affect this gate. Build one response review containing item-level correspondence, supported findings, required upstream corrections, and scoped unverified comparisons. When embedded in the plan, this review fragment may use only ### or deeper headings and must not contain lines beginning - AC IDs: or - Gate:.
6. If no update was requested, make no mutation and omit update-status fields. If an update was requested but is not authorized or multiple MECE Review sections exist, make no mutation and retain the response review when the input was otherwise valid. If an update is authorized and zero or one section exists, remove the entire sole prior section when present, then insert a new ## MECE Review section immediately after the complete Acceptance Criteria section and before the next ## section. The new section contains exactly one - AC IDs: <ascending IDs joined by ", "> row, exactly one - Gate: ready|blocked|unverified row, and the response review content; all non-target plan content is preserved.
7. In the authorized zero-or-one-section branch, invoke the update interface exactly once. Set review-update submitted: yes when the call is issued to the interface, including when it later times out, throws, returns a transport error, or returns no response. First classify any timeout, thrown/transport error, conflicting signal, missing response, non-final response, partial response, or ambiguous documented status as operation unverified; only a final unambiguous success without failure is succeeded, and only a final unambiguous failure without success is failed. A readback is permitted only through a separately available authorized read of the exact current-plan destination; a write-response echo is not readback. Perform exactly one permitted readback and none when unavailable. First classify a wrong-resource response, missing, non-final, partial, failed, truncated, or ambiguous readback as content unverified; only a successful final complete readback of the exact destination can be verified when its plan string equals the submitted string or mismatch when it differs. Do not repeat invocation or readback within the same skill execution.

Completion

• When the plan or Acceptance Criteria input is invalid, return detected defects but no gate or review.
• Otherwise return the gate and response review from step 5.
• Whenever an update was requested, also return exactly review-update submitted: yes|no, review-update operation: succeeded|failed|unverified|not-submitted, and review-update content: verified|mismatch|unverified|not-submitted. When no dispatch occurred, use no, not-submitted, and not-submitted.
• Leave product code and external state unchanged except for the exact authorized current-plan update.