--- name: dough-execution-retrospective description: >- Reviews planned, completed planless quick, or quick-to-planned execution against original intent, aggregate commits, current whole-product architecture, and tests, including after cleanup. Use for execution retrospective, product review, or backlog recommendations from current/supplied history. Supports `--skip-process`, `--skip-product`, and project `skipProcessRetrospective` preference. May plan corrections, record process findings in `DearDough.md` (500-line warning, 1,000-line ceiling, recoverable lower-priority replacement on overflow), and recommend product work; never implements findings. --- # Review an execution Review implementation, process, and product learning by default. Return evidence and needed correction plans; do not implement, commit, push, or change the backlog. Leave closure to [dough-story-wrap-up](../dough-story-wrap-up/SKILL.md). ## 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 `/open-dough.json` (default: `/.planning/open-dough.json`), not a skill-local or other project's file. Expect a JSON object with optional boolean `skipProcessRetrospective`: missing file/key or `false` enables process; `true` skips. 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 and process recording below. A complete correction plan needs no seed. Quick inputs follow the recovery rules below. Before residue assessment, read [refactoring](../dough-post-change-refactor/SKILL.md) and its checks; use the smell definitions on the aggregate result without editing. For needed correction planning, load [slice planning](../dough-slice-planning/SKILL.md#require-understood-planning-input) and follow its bounded-input, proof, sizing, and destination gates. Load [backlog guidance](../dough-product-backlog/SKILL.md) 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. 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](../dough-adr-awareness/SKILL.md) 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](../dough-post-change-refactor/references/refactor-checks.md#tests-as-behavioral-documentation). 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](../dough-execute-plan/references/execution-decisions.md#resolve-a-disputed-plan-restriction). 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](../dough-story-refinement/references/planning.md#examples-and-constraints). 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: 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; a separate request executes the correction, and [dough-execute-plan](../dough-execute-plan/SKILL.md) publishes it through [increment and repair publication](../dough-execute-plan/references/trunk-publication.md#publish-an-execution-increment-or-repair). This review does not publish. ## Review process only from a real record Use direction and a sufficient conversation/transcript 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 Use the explicit user/project `DearDough.md` location or `/DearDough.md` for enabled process findings. No findings means unchanged/no new log. Missing/conflicting root/location stops recording only: return findings and continue independent reviews without inventing/searching elsewhere. Reuse logged execution identity, else canonical plan/story plus first related implementation commit, or a stable execution-record reference if no commit exists. Later commits/reviews/dates create no identity. Missing/conflicting identity permits findings but no countable row or invented tracking. For a new log, assign `DD-001` upward in supported-finding order using: ```markdown # DearDough Process Findings ## DD-001 — ### Occurrences - Execution: - Timestamp: - Tool: - Model: - Open Dough release: - Evidence: - Observed effect: - Inference: ``` Use compact references and separate observation/inference. Rows count retained occurrences, not all-time recurrence. Record supported one-offs, practices, potential general issues, and retrospective observations with qualified generality. For each new occurrence: - **Timestamp:** actual event time, ISO 8601 with timezone, from execution evidence or live clock; otherwise `unknown`, with available dates/ranges in Evidence. Never substitute review/import/ nearby-commit times or invent date precision. Preserve timestamps; fill unknown only with event evidence. Older timestamp-free rows remain valid without replay rewrites. - **Tool/model:** identify the executing tool, not reviewer; omit Model when execution evidence supplies none, without guessing or separate lookup. Unidentified tool means no countable row. Backfill older rows only with supporting evidence. - **Release:** execution-time guidance provenance, otherwise `unknown`; not product version or today's checkout/installation `VERSION` unless tied to this work. Mark unreleased/modified guidance with available revision/base release, e.g. `modified; revision ; base `. Never mislabel it a clean release, guess, or backfill older releases; identical rereview stays unchanged. Existing headings/descriptions/rows must safely identify issues, executions, and next ID. Use only this log's IDs; preserve DD/adopted ODF codes, mint only `DD-NNN`. Keep notes, evidence, release rows, and unrelated content; make the smallest supported edit. Migration, normalization, reordering, deletion, or merging requires bounded retention below. Match the same concrete problem/practice by decisive evidence, not wording/symptoms; reuse its code. Recover history only for consequential identity/match questions, reusing established removed IDs. Missing history that prevents safe identity resolution stops allocation. Otherwise an unmatched/ uncertain finding gets the next unused `DD-NNN`, with matching uncertainty stated when relevant. Never renumber to fill gaps or restore a pruned occurrence on identical rereview. Next DD number is one above the greater of all current DD/adopted-ODF heading numbers and retention metadata's highest allocated local number. Never reuse removed IDs or collide across prefixes (`ODF-001` reserves 1). Update existing high-water metadata on every allocation, even without pruning. Uncertain historical gaps cannot be filled; report inability to allocate safely. One execution means one row: identical/pruned rereview makes no edit; decisive new evidence or corrected qualified conclusions enrich it, preserving prior notes. New executions add rows, symptoms do not. For supported writes only, build the complete ordinary candidate, then follow [bounded process-log recording](references/bounded-process-log.md) for measurement, retention, warnings, writing/refusal, and recovery. No-findings/identical rereviews load no reference; skipped/unresolved process accesses neither log nor reference. Ambiguity, malformed content, unsafe retention, or write failure leaves the log byte-identical; report limitations/findings and continue. Report path, created IDs/rows or `unchanged`/`not recorded` with reason, and required size/retention warnings or refusal. Claim no unsuccessful write as success. The final banner requires an evidenced overlooked request, decision, warning, failed verification, or Jidoka stop still needing user action. ## 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](../dough-story-wrap-up/SKILL.md); backlog/story edits require that workflow or separately requested [maintenance](../dough-product-backlog/SKILL.md). 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. 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. End with `## EXECUTION RETROSPECTIVE COMPLETE`. Only with the evidenced attention need above, append this at the absolute end: ```text !!!!!!!!!! DEVELOPER ATTENTION REQUIRED !!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ```