Review an execution

Review implementation and product learning by default, and process when enabled. Return evidence and needed correction plans; do not implement, commit, push, or change the backlog. Leave closure to dough-story-wrap-up.

An execution retrospective may start once implementation is delivered while its applicable CI result remains pending. Treat the retained observer, publication target, accepted revision, and pending state as input, not as a missing completion prerequisite. Review the delivered implementation while observation continues and state which conclusions remain conditional on unresolved CI. Do not invoke the CI wait, stop or replace its observer, acknowledge its events, or claim final execution/review handoff; the invoking execution owns those actions through its completion operation.

Select reviews

Select reviews before focus-specific actions or context, including log-location resolution. Independent, combinable --skip-process and --skip-product omit their analysis, suggestions, and destination access/writes. Unresolved process selection excludes that focus too. Other reviews retain their authority, implementation planning, and direction consideration.

Read this project's optional <established-planning-directory>/open-dough.json (default: <project-root>/.planning/open-dough.json), not a skill-local or other project's file. Expect a JSON object with optional boolean skipProcessRetrospective: false enables process; missing file/key or true skips it like --skip-process. Ignore unknown keys; never create, rewrite, or repair it.

Explicit process selection overrides storage, including errors: --skip-process skips; an include-process request enables without a new flag. Clarify contradictory instructions. Otherwise unreadable/malformed/non-object JSON or non-boolean recognized values leave selection unresolved: report error, omit process analysis/log access, and continue independent reviews.

Resolve this project's context

Start from a capability/story phrase, correction plan, commit, or current/supplied conversation. Resolve project navigation, focused tests, cleanup lifecycle, relevant plan/story locations and statuses, and direction; backlog conventions only for dependent product recommendations. Missing decision-relevant context stops that path with a named gap, not invented conventions. Preserve worktree changes. Separate report artifacts require a request; allowed writes are correction plans, a new correction's minimal story, and process recording below. Quick inputs follow the recovery rules below.

Write only in an owned checkout

Make every allowed write in one owned checkout. When an invoking execution supplies its execution checkout as the write location, write there; that execution commits those records in its completion commit. A landing or wrap-up running the process review of its run supplies its own checkout as that execution checkout and commits the records itself. Otherwise, immediately before the first write, select or reuse an owned workspace under prepare records in an owned workspace, write there, and report the written result's pending disposition. Do not write in the checkout the review started from unless it is that supplied execution checkout. A review that writes nothing creates no workspace. Resolve the process-log path and correction story and plan locations in the chosen checkout.

Before residue assessment, read refactoring and its checks; use the smell definitions on the aggregate result without editing. For needed correction planning, load slice planning and follow its bounded-input, proof, sizing, and destination gates. Load backlog guidance only for dependent enabled recommendations.

Recover one execution

Search conversation, supplied history, current planning, then Git history. Establish whether work was planned, explicitly planless, quick-to-planned, or planned with normal cleanup. File absence establishes none of these. Recover original intent before judging implementation:

• Planned: recover the earliest execution-ready plan, story/correction input and outcome, then later changes supported by approval or new evidence. Partial references and removed plans suffice when history identifies them; removed plans remain planned executions.
• Quick: require conversational evidence of explicit planless selection. Recover canonical goal, boundaries, examples, promised proof, approved changes, related changes/commits, and available proof. Use current chat when sufficient, otherwise supplied transcript; invent no historical plan or substitute execution record.
• Quick-to-planned: recover conversational quick selection/attempt and the ordinary same-source remaining-work plan. Preserve compatible attributable quick work/proof as such, not earlier planned slices; recover later slices/changes normally. Both parts form one execution.

Completion requires every planned slice done (history proves deleted plans), or quick conversation/repository proof of delivered outcome. Quick-to-planned needs a completed remaining plan plus quick/planned proof covering the original outcome without gaps or assumed repeated work. Missing kind, continuity, contract, completion, or proof limits dependent conclusions only. Two equally plausible executions need user selection; continue independently supported review. Pending CI alone does not make delivered implementation incomplete. Preserve its explicit pending state and do not convert it into passing validation.

Manifest each related SHA with a reason from story/plan, retained published revisions, message, diff, or transcript. When those published revisions exist, they are the related set; do not attribute a whole-trunk range, interleaved sibling work, or a rewritten unpublished SHA (use its published replacement). Inspect nearby/intervening commits and exclude unrelated work with reasons. Ambiguous attribution limits claims; planning-only commits are provenance. Use a net diff only for an uncontaminated range, otherwise selected patches together and files at the last related implementation commit. Review history read-only, excluding later work.

Consider near-future direction

Read direction once, prioritizing alignment/digression questions and explaining exceptions (e.g. urgent fixes). If absent, report unassessed alignment and continue; never invent, propose, or edit it. Route defects to corrections, process learning to findings, and product learning/priorities to advice. Users own constraint/outcome changes. Historical contracts stand; later direction governs future work.

Review the outcome

Compare original intent, boundaries, approved changes, and promised proof to aggregate code, tests, docs, and proof. Assess only completed slices of unfinished plans; unexecuted work is not missing behavior, nor its temporary predecessor obsolete. Findings need evidence and plausible impact: bugs, regressions, drift/disputes, refactoring residue, architecture, or test coverage/cost.

Assess whole-product domain responsibilities, dependencies, and representations, including relevant untouched code. Check coherent rules versus successive-example cases and explain impact, such as divergent rules or coordinated edits. Delivery sequence cannot justify boundaries; helpers alone cannot prove cohesion. Apply ADR awareness with human-owned conflicts. Older weaknesses may need correction; only provenance establishes an execution regression.

Identify whether E2E tests drove development, then assess the whole suite, including older tests and executions adding no E2E tests, under behavioral test guidance. Ground retention, detail downgrades, and consolidation in coverage/cost; preserve journey information and integration proof. Use project testing guidance or the shared black-box fallback. Whole-suite assessment needs no full run; use focused read-only checks to confirm/dismiss findings.

Inspect worked-around/replaced branches, flags, callers, fixtures, compatibility paths, overlapping/ obsolete-internal tests, and historical documentation. Removed temporary behavior warrants negative proof/docs only when absence remains required. Exclude cosmetic/speculative/unsupported findings, duplicate symptoms, and approved decisions mislabelled as drift. Before planning removal of a disputed restriction, use plan-conflict handoff. Preserve genuine constraints; await human resolution of disputed corrections while independent review continues. Plan compliance alone does not settle justification.

Reconcile findings with current truth

Recheck findings against current revision/worktree; report later fixes and deduplicate by root cause. Current evidence bounds corrections, including beyond the old footprint, while preserving scope and promises. No findings means unchanged plans; broader review grants no new feature promises.

Give suite cleanup explicit correction ownership, including older redundant tests. For consolidation, name surviving meaningful coverage/integration proof (retained E2E may suffice). For detail downgrades, require replacement unit coverage before narrowing/removing E2E tests. Plan cleanup; do not perform it.

• Unfinished plan: amend in place; retain completed evidence/resume history and numbering. Put corrections before remaining work, revise overlapping slices instead of duplicating them, and record findings/manifest as concise learning when the project format supports it.
• Planless, completion unresolved: return evidence and exact completion/proof/attribution gaps. Original unfinished work is not yet a completed-execution correction; reconstruct no plan or create a correction destination until the completed execution boundary is established.
• Completed execution: create one follow-up through slice planning in the established location: its minimal story in a suitable seed, linked to the plan under the correction input; original contract/manifest as provenance; current findings as scope/evidence; bounded outcome, concepts, impact, preserved behavior, and focused proof. Keep historical promises/attribution intact. Changing promises/constraints or findings that cannot form one bounded correction need user decision.

Only the designated writer changes the plan when two authorized reviews cover one execution; the other returns evidence. Continue enabled reviews; writing the follow-up neither queues nor authorizes it; a separate request executes the correction, and dough-execute-plan publishes it through increment and repair publication. This review does not publish.

Review process only from a real record

Review the coordinator's existing conversation and tool results. Inspect relevant sub-agent history through available host access when needed. If required history is unavailable, report the affected process review unavailable and continue independently supported reviews. Persist supported findings under the recording rules below; execution state follows the project's plan and Git conventions.

Use that history and the user's direction to identify waste, rule-induced churn, missing stops, disproved sizing/decomposition, digression, and useful practices. Assess instruction and context usability, including this review's avoidable rereading, duplication, and reconstruction. Separate necessary investigation, observation, and inferred cost/cause. Cite recorded token counts or repeated work with qualified cost; brevity/skipped investigation alone proves no gain. Insufficient records limit conclusions: invent no events, edit no guidance, require no measurements or recursive review. Process proposals stay outside correction plans.

Record supported process findings

When enabled process review produces supported findings, read and follow process-finding recording. No findings or an identified identical rereview means no log change or reference load; skipped or unresolved process review does not access the log or its recording references.

Review product learning

Inspect direction and relevant queue entries/stories; unrelated urgent fixes need no queue survey. Preserve priorities; connect supported learning to recommendations or reasoned no-change. Unread entries stay unvalidated; inspirations are hypotheses. Unknown beneficiaries/outcomes warrant an exploration proposal, not discovery/decomposition. Missing conventions leave conclusions provisional: report gaps, invent no files/learning, and continue independent reviews.

Send recommendations, proposals, and unresolved choices to story wrap-up; backlog/story edits require that workflow or separately requested maintenance. Leave disputed goals/scope, conflicting priorities, and unknown beneficiaries/outcomes unresolved.

Report

Report work identity/completion, provenance, manifest/boundary, impact-ordered findings or none, and evidence limits. Classify planning as amended, new, read-only, unchanged, or unavailable pending execution-boundary evidence, with a new follow-up's story and plan links. Report enabled process proposals and product advice/reasoned no-change; unresolved process selection reports its error only. Distinguish evidence from hypotheses and recommendations from proposals/unresolved choices. When CI is pending, report its retained target and revision as pending and make no success claim. End with ## EXECUTION RETROSPECTIVE COMPLETE; this marker completes review, not the execution's final CI handoff. When this review was invoked automatically by an active dough-execute-plan execution, do not end the turn at this marker: return immediately to that execution's completion operation, without asking for confirmation. If an authorized CI repair later changes reviewed code, resume only the affected conclusions using the retained review state.

Only with the evidenced attention need above, append this at the absolute end of a standalone retrospective report. For an automatic execute-plan review, return the attention need to the invoking execution for its final handoff:

!!!!!!!!!! DEVELOPER ATTENTION REQUIRED !!!!!!!!!!
<the overlooked item, its impact, and the response needed>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!