dough-execution-retrospective · diff

git:20260913.706255d to git:20260914.a3e9532

169 added, 492 removed. Audit A to A.

---

name: dough-execution-retrospective

description: >-

- Reviews one completed or unfinished planned execution, a completed quick

- execution whose plan never existed, or a quick attempt continued through an

- ordinary remaining-work plan, against its original feature story or

- bounded-correction contract, aggregate commit set, current whole-product

- architecture, and test suite. Use for an execution retrospective, product

- review, or backlog recommendation from current or supplied execution history,

- including after cleanup. `--skip-process` and `--skip-product` omit those

- reviews independently. Project `open-dough.json` may set

- `skipProcessRetrospective` to persist skipping process review. May plan

- unresolved implementation findings, record supported process findings in

- `DearDough.md` with a 500-line warning, 1,000-line ceiling, and recoverable

- replacement of lower-priority material when a write would overflow, and

- recommend product work; never implements them.

+ 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

- Recover what one execution intended, identify the commits that executed it, and

- review their combined outcome, current product architecture, and whole test suite. By default,

- cover implementation, process, and

- product learning. Leave the project with evidence and, only when needed, a

- plan for bounded corrections. Do not implement, commit, or push those

- corrections. A retrospective authorizes product recommendations; it does not grant

- backlog-write authority. Leave any completed plan and routine

- completion or backlog actions for

+ 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

- Ordinary invocation considers implementation, process, and product review.

- Choose the enabled set before loading focus-specific context or acting on that

- focus. Resolve process review before process analysis and before resolving,

- checking, reading, or writing `DearDough.md`.

- `--skip-product` omits product analysis and suggestions. It does not change

- process selection. `--skip-process` omits process analysis and all log

- inspection and writing. Both flags may be supplied together. Neither skips

- implementation review or its correction planning. Skipped or unresolved process

- review does not skip implementation or product review, and does not suppress

- their destination writes. Skipped product review does not suppress the shared

- direction consideration in implementation or enabled process review. Do not

- covertly review a skipped or unresolved focus or write its destination.

- Read this project's optional `open-dough.json` from the established planning

- directory: `<established-planning-directory>/open-dough.json`, defaulting to

- `<project-root>/.planning/open-dough.json` when no different planning directory is

- established by the user or this project's conventions. Resolve that path from

- this project, not this skill's location. Do not search other projects. Do not use

- `open-dough.json` beside this skill.

- The file is one optional JSON object. The only recognized setting is this boolean:

- ```json

- { "skipProcessRetrospective": true }

- ```

- A missing file, missing `skipProcessRetrospective` key, or boolean `false`

- leaves process review on. Boolean `true` omits process analysis and all log

- inspection and writing.

- Ignore unrecognized keys. Leave the file unchanged: do not rewrite it, create a

- missing file, or repair an invalid or unreadable file.

- Explicit invocation instructions override the stored preference without editing

- the file. `--skip-process` always skips, even when the file is missing or says

- `false`. An explicit request to include process review enables it for this

- invocation even when the file says `true`; do not add a new flag for that

- override. Contradictory explicit instructions use ordinary clarification.

- If the file is unreadable, is not a JSON object, contains malformed JSON, or sets

- a recognized key to a non-boolean, process selection is unresolved: report the

- error, omit process analysis, leave the log untouched, and continue

- independently supported reviews. An explicit process-selection instruction

- (`--skip-process` or an explicit include-process request) resolves that

- invocation without repairing the file.

+ 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.

- ## Work from these principles

+ 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`: missing file/key or

+ `false` enables process; `true` skips. Ignore unknown keys; never create, rewrite, or repair it.

- - **Original intent is the contract.** Recover the feature story or bounded

- correction input, boundaries, approved changes, and promised proof before

- judging implementation.

- - **Commit membership needs evidence.** A nearby commit is not part of the

- execution merely because it is in the same range.

- - **Judge the aggregate result and current architecture.** Review the combined

- execution outcome and the whole product's conceptual structure, including

- relevant untouched code. Delivery decomposition is not a design objective;

- coincident product boundaries need independent domain justification.

- - **Current truth decides remediation.** Report later fixes and do not plan work

- that is already resolved.

- - **Execution state decides the destination.** Amend an unfinished plan; create

- a follow-up plan only for a completed execution. A wholly planless quick

- execution with unresolved completion has neither destination yet.

- - **The user owns disputed scope and constraints.** Stop when evidence cannot

- distinguish two execution candidates or when a finding would change the source

- outcome rather than correct it. Use the shared

- [plan-conflict handoff](../dough-execute-plan/references/execution-decisions.md#resolve-a-disputed-plan-restriction)

- for apparently accidental contractual restrictions; plan compliance does not

- settle their justification.

- - **Product learning is not an implementation defect.** Keep product

- recommendations out of correction plans and process findings.

- - **Direction is a criterion, not a deliverable.** Question alignment of

- work and process with the established near-future direction; never propose

- or edit that text.

+ 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

- Require one useful clue: a capability or story phrase, correction plan, commit,

- or the current or supplied execution conversation. Resolve this project's plan

- location and status vocabulary for planned work, feature-story locations when

- applicable, cleanup lifecycle, repository navigation, and focused test commands.

- Preserve existing working-tree changes. A complete bounded correction plan is

- its source contract; do not require or create a seed for its retrospective. A

- wholly planless quick execution instead requires its canonical story and enough

- execution history to establish that slice planning was explicitly skipped. A

- quick-to-planned execution requires that initial evidence plus its ordinary

- remaining-work plan and evidence connecting both parts.

- Resolve this project's established near-future direction when present. When

- product review is enabled, resolve backlog and canonical-story conventions when

- that review needs them. Do not invent a direction, backlog, or feature-story

- seed location.

- If context needed for a review decision is missing, name it and stop that path.

- Do not invent a plan location, completion rule, or project convention.

- Return retrospective evidence in the response; do not create a separate artifact

- unless the user asks. Keep the repository read-only except for the process log

- when process review is enabled and an allowed plan update described below. Do

- not create, repair, or rewrite `open-dough.json`.

+ 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.

- Read [dough-post-change-refactor](../dough-post-change-refactor/SKILL.md) and its

- refactor checks before assessing refactoring residue; apply its smell definitions

- to the aggregate result without running its editing workflow. Read

- [dough-slice-planning](../dough-slice-planning/SKILL.md) only when unresolved

- findings need planning, then follow its

- [bounded-correction entry](../dough-slice-planning/SKILL.md#require-understood-planning-input),

- proof, sizing, and destination gates. Read [dough-product-backlog](../dough-product-backlog/SKILL.md) only when

- product review is enabled and recommendations depend on those conventions.

+ 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 the current conversation, supplied execution history, current planning

- material, and Git history in that order. First establish whether the execution

- used a plan, explicitly ran as one quick slice without creating a plan, began as

- a quick attempt and continued through an ordinary remaining-work plan, or used a

- plan that normal cleanup later removed. File absence alone does not establish

- which case applies.

- For planned execution, preserve the existing recovery path: a partial reference

- or a plan removed by normal cleanup is sufficient when history identifies it.

- Recover the earliest execution-ready plan, its feature story or

- bounded-correction input and intended outcome, and any later changes supported

- by user approval or new evidence. Do not relabel a removed-but-recoverable plan

- as quick execution.

- For quick execution, require conversation evidence that the caller explicitly

- selected planless execution. Recover the canonical story's goal, boundaries,

- examples, and promised proof; approved changes from the conversation; related

- changes and commits; and the available proof. Do not require, invent, or

- reconstruct a historical plan or substitute execution record. Current chat is

- sufficient when it contains these facts; otherwise use a supplied transcript.

- For a quick attempt continued through planning, recover the initial quick-path

- selection and attempt from current or supplied conversation evidence, then the

- ordinary plan linked to the same canonical story and that attempt's remaining

- work. Treat both parts as one execution. The plan must preserve attributable

- completed compatible work and proof and must not represent them as earlier

- planned slices. Recover its remaining slices and later plan changes through the

- ordinary planned path. Do not manufacture a second execution identity merely

- because the execution source changed from story-and-chat to plan.

+ 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:

- Determine completion from source-specific evidence, not file presence. A plan

- is complete when every slice is done; a deleted plan needs history evidence of

- completion. A quick execution is complete only when its conversation and

- repository evidence establish the delivered story outcome and its required

- proof. A quick-to-planned execution is complete when the remaining-work plan is

- complete and the preserved quick-attempt evidence plus planned proof establish

- the original story outcome without a gap or repeated-work assumption. Missing

- proof limits the completion or finding conclusion that depends on it; continue

- independently supported review rather than treating plan absence as failure. If

- execution kind, continuity, contract, or completion remains ambiguous, name the

- missing evidence and stop only the affected decision. If two candidates remain

- equally plausible, ask the user to choose and do not combine them.

+ - **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-story 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.

- Build one manifest of related commits across a quick attempt and its planned

- continuation when both occurred. Include each SHA with a reason grounded in

- the plan or story, commit message, diff, or execution transcript. Inspect

- intervening and nearby commits and exclude unrelated work. Ambiguous attribution

- limits claims about that commit and findings that depend on it; it does not

- authorize widening the manifest. Treat planning-only commits as provenance, not

- product findings.

+ 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.

- Use one net diff only when the implementation commits form an uncontaminated

- range. Otherwise review the selected patches together and inspect their files at

- the last related implementation commit. Never mutate the worktree to reconstruct

- history or mix later work into the historical boundary.

+ Manifest each related SHA with a reason from story/plan, message, diff, or transcript; inspect

+ nearby/intervening commits to exclude unrelated work. 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

- For every enabled review, treat the established near-future direction as a

- high-priority criterion. Read it once from the resolved project location. If it

- is missing, say alignment cannot be assessed against an established direction

- and continue the independently supported reviews. Otherwise question apparent

- alignment and digression. Explain justified exceptions such as urgent fixes. Do

- not merely assert that the work fits.

- Route a supported deviation through that review's existing authority:

- - Implementation: supported defects and architectural weaknesses go to bounded

- correction planning under current truth. A needed product-constraint or

- promised-outcome change is the user's decision, not a rewritten historical

- contract.

- - Process: produce a process recommendation; do not add it to an

- implementation correction plan.

- - Product: recommend work or priorities. Do not treat a direction mismatch as

- an implementation defect.

- A later change in direction does not retroactively make approved historical work

- a defect. Judge that work against its original approved contract; use today's

- direction only for remaining or proposed work.

- Never propose or apply a replacement or revision of the direction itself.

+ 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

- Apply the shared direction consideration. Then compare the feature-story or

- bounded-correction contract and approved changes with the aggregate code, tests,

- documentation, and proof at the execution boundary. For the historical

- assessment of an unfinished plan,

- judge only the completed slices;

- do not call unexecuted planned behavior missing or its explicitly temporary

- predecessor obsolete.

- Keep only findings with concrete evidence and plausible impact:

- 1. bugs or regressions;

- 2. source-outcome drift or an unresolved scope dispute;

- 3. refactoring residue in complete implicated concepts;

- 4. consequential weaknesses in the current whole-product architecture; and

- 5. test coverage or execution-cost findings under the shared behavioral test guidance.

- Assess overall responsibilities, dependencies, and representations against the

- product's domain, not the story sequence. Ask whether successive examples

- exercise a coherent model or accumulate special cases. Use the shared refactor

- checks for concrete concept examination; shared helpers alone do not establish

- cohesion. Follow architectural evidence beyond the changed files to relevant

- untouched code, and explain the concrete impact of a weakness, such as divergent

- domain rules or changes requiring repeated coordinated edits. Whole-product

- assessment is required; it does not require speculative redesign or treating

- cosmetic preferences as defects. Apply

- [dough-adr-awareness](../dough-adr-awareness/SKILL.md) to genuine architectural

- constraints and leave conflicting decisions with the human.

- Keep historical attribution separate from current assessment: only claim this

- execution introduced a defect when its provenance supports that claim. An older

- weakness can warrant current correction without becoming an execution regression.

- Identify whether E2E tests drove this execution's development, then assess the

- whole suite, including older tests outside the story, using

- [tests as behavioral documentation](../dough-post-change-refactor/references/refactor-checks.md#tests-as-behavioral-documentation).

- No newly added E2E tests does not exempt existing coverage from review. Ground

- retention, detail downgrades, and overlap consolidation in actual coverage and

- cost findings; preserve important journey documentation and integration proof.

- Use the project's testing guidance when supplied and the shared black-box

- fallback otherwise. Whole-suite assessment does not require running every test.

+ 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.

- Look explicitly for additions later worked around or replaced: dead branches,

- flags, callers, fixtures, compatibility paths, overlapping tests, tests of

- obsolete internals, and documentation that preserves implementation history

- instead of product truth. An explicit user decision is not drift. Style

- preferences, speculative redesigns, duplicate symptoms, and unsupported claims

- are not findings. Do not retain a negative test or documentation merely to prove

- that temporary behavior is gone unless its absence is an enduring requirement.

+ 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.

- Surface a disputed plan restriction through that handoff before planning its

- removal. Leave the disputed correction pending the human decision, retain genuine

- constraints, and continue independently supported reviews. Do not silently

- rewrite the historical contract or treat preservation as resolution.

+ 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.

- Use focused read-only checks when they can confirm or dismiss a finding. Do not

- run broad suites.

+ 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 every finding against the current revision and working tree. Report a

- later fix and deduplicate remaining findings by root cause. Use current evidence

- to bound needed corrections across the product, including outside the old

- story's implementation footprint. Preserve existing product promises and genuine

- constraints using the shared

- [scope distinction](../dough-story-refinement/references/planning.md#examples-and-constraints);

- review reach does not authorize new feature promises. If none remain, leave

- planning unchanged.

- Give unresolved test downgrades and consolidation, including older redundant

- tests, explicit ownership in the bounded correction plan. Name the retained

- meaningful coverage and integration proof for consolidation; existing retained

- E2E coverage may suffice. For detail downgrades, make replacement unit coverage

- a prerequisite to removing or narrowing the corresponding E2E tests. Apply the same current-truth and

- destination rules as other corrections; the retrospective plans suite cleanup

- and does not perform it.

- For an unfinished plan, update that plan in place. Preserve completed evidence

- and resume-useful history; place corrective work before remaining planned work

- and revise overlapping planned slices instead of duplicating them. Do not

- renumber completed slices. Record the finding and reviewed commit manifest as a

- concise learning when this project's plan format supports it.

+ 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.

- When a planless execution's completion is not established, return the supported

- review evidence and the exact completion, proof, or attribution gap. There is no

- plan to amend, and unresolved original story work is not yet a completed

- execution correction. Do not reconstruct a plan or create a correction plan

- until evidence establishes the completed execution boundary.

+ 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.

- For a completed execution, use `dough-slice-planning` to create one follow-up

- plan in this project's established location. Cite the original story and commit

- manifest as historical provenance, and the current findings as the correction's

- scope and evidence. State one bounded correction outcome, affected concepts,

- concrete impact, preserved behavior, and focused proof. This may reach beyond the

- original story without rewriting its promises or attributing older defects to

- it. If correction would change product constraints or promised outcomes, stop

- for the user's decision. Stop likewise when the findings cannot form one bounded

- correction.

+ - **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.

- When two authorized reviews cover the same execution, only the designated writer

- reconciles findings into the plan destination; the other reviewer returns

- read-only evidence.

- After any planning change, do not refine or execute that correction unless the

- user separately requests it. Continue every other enabled review, then

- report. That restriction applies to correction refinement and implementation, not

- to other enabled reviews.

+ Only the designated writer changes the plan when two authorized reviews cover one execution;

+ the other returns evidence. Continue enabled reviews; correction refinement/execution needs a separate request.

## Review process only from a real record

- When process review is enabled, apply the shared direction consideration, then

- when the current conversation or a sufficiently complete transcript contains the

- execution, separately identify evidence-backed process improvements: wasted

- work, rule-induced churn, a missing stop condition, a disproved sizing or

- decomposition assumption, avoidable digression from direction, or a useful

- practice to learn. Consider whether instructions were concise and context was

- organized for easy consumption, including this retrospective's own avoidable

- rereading, duplication, or reconstruction. Distinguish necessary investigation

- from avoidable waste.

- Record observations separately from inferred cost and cause. Use token counts

- only when they are available in the record; otherwise cite the repeated work and

- qualify the cost. Neither shorter text nor skipped necessary investigation proves

- improvement. If the record is insufficient for a process conclusion, state that

- limit instead of manufacturing a finding. Do not infer missing events, edit

- guidance, require token measurement, or recursively launch another retrospective.

- Do not put process proposals into the repository correction plan.

+ 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

- After process analysis, record its supported findings in the project's canonical

- `DearDough.md`. This is a narrow process-recording allowance; it does not authorize

- other project or product maintenance. Product-only findings and implementation

- corrections stay in their own destinations. Preserve every unrelated file.

- Apply the process-selection result from [Select reviews](#select-reviews)

- before resolving, checking, reading, or writing the log location. When process

- review is skipped or unresolved, do not create, read, or edit the log. When

- enabled review yields no supported process finding, do not create an empty log

- and leave an existing log unchanged. `--skip-product` does not suppress process

- recording.

- Use `<project-root>/DearDough.md` unless the user or this project's conventions

- explicitly establish another canonical location for that filename. An explicit

- location wins over the root default. Do not search other projects or invent an

- alternative. If the project root or canonical location is missing or conflicting,

- return the findings with that limitation and stop recording only; continue every

- independently supported review.

+ Use the explicit user/project `DearDough.md` location or `<project-root>/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.

- Identify the reviewed execution before writing. Reuse an execution identity

- already present in the log when available. Otherwise combine its canonical plan

- or story reference with its first related implementation commit. If it has no

- implementation commit, use an available stable execution-record reference. A

- later commit, another review, or the review date does not create another

- execution. If identity evidence is missing or conflicting, return the findings

- without a countable occurrence, report the limitation, and continue the other

- reviews. Do not make an identity from today's date or introduce a tracking

- system.

+ 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, write this minimal Markdown shape, assigning `DD-001` upward in

- the order of supported findings:

+ For a new log, assign `DD-001` upward in supported-finding order using:

```markdown

# DearDough Process Findings

## DD-001 — <descriptive issue title>

### Occurrences

- Execution: <stable execution identity>

- Timestamp: <ISO 8601 occurrence time with timezone | unknown>

- Tool: <Codex, Cursor, Claude Code, or another identified tool>

- Model: <model identifier, when available>

- Open Dough release: <version | unknown | unreleased | modified>

- Evidence: <decisive compact references or locators>

- Observed effect: <what the record shows>

- Inference: <qualified cause, cost, or uncertainty, only when needed>

```

- Keep observation separate from inference. Use compact references rather than

- transcript copies. The occurrence rows are the visible count; do not add a

- redundant total. Record one-off costs, useful practices, potentially general problems,

- and supported observations about this retrospective without claiming recurrence

- or generality the evidence does not establish.

+ 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:

- Record `Timestamp:` for every new occurrence: the time the reported event

- occurred, in ISO 8601 with a timezone (for example,

- `2026-09-13T14:30:00+08:00`). Use execution evidence, or read the current clock

- when observing the event live. If its time cannot be established, write

- `unknown`; do not substitute the retrospective or import time, a nearby commit

- time, or invent precision from a date alone. Preserve an available date or

- time range in Evidence when an exact timestamp is unknown. Preserve timestamps

- on rereview; fill an unknown only when new evidence supplies the occurrence

- time. A timestamp does not change execution identity or create another row.

- Older rows without timestamps remain interpretable; do not rewrite them merely

- on replay.

+ - **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 <rev>; base <version>`.

+ Never mislabel it a clean release, guess, or backfill older releases; identical rereview stays unchanged.

- Record the tool name for every new occurrence. Use the tool that executed the

- work, such as Codex, Cursor, or Claude Code, rather than the tool reviewing it.

- Record the model identifier when the execution evidence supplies it; otherwise

- omit the Model line instead of guessing or performing a separate lookup. If the

- executing tool cannot be identified, report the finding without adding a

- countable occurrence. Do not backfill older rows without supporting evidence.

+ 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.

- On every new occurrence, record `Open Dough release:` as a released version,

- `unknown`, `unreleased`, or `modified`. This is the Open Dough guidance used

- while the work ran — not this project's product version, and not the release

- installed when the retrospective later runs. Resolve it from execution or

- installation provenance tied to the reviewed work. Do not use a current

- checkout `VERSION`, or today's `.agents/skills/dough-update/VERSION` or

- `.claude/skills/dough-update/VERSION`, unless that installation is tied to the

- work. If the release cannot be established, write `unknown`. For unreleased or

- modified guidance, mark that state and attach an available revision and, when

- known, the base released version — for example

- `modified; revision <rev>; base <version>` — rather than a clean released

- version. Do not guess or backfill a release on older rows; an identical

- rereview still makes no edit.

+ 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.

- When the canonical log exists, maintain it only when its issue headings,

- descriptions, and occurrence rows are interpretable enough to identify the

- affected issue, execution, and next unused local ID. Existing headings may use

- `DD-NNN` or a previously adopted code such as `ODF-001`; both are local issue

- IDs in this project's log. Identify issue IDs only from this project's log. Do

- not mint `ODF-NNN`. Preserve existing IDs, human notes, prior evidence,

- unrelated entries, release-bearing occurrence rows, and all content outside the

- smallest supported edit. Do not migrate, normalize, reorder, delete, or

- automatically merge existing content except as required by bounded retention

- in [bounded process-log recording](references/bounded-process-log.md).

+ 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.

- Match an existing issue only when decisive evidence supports the same concrete

- process problem or useful practice; similar wording or symptoms do not establish

- that match. Reuse that issue's existing heading code, including a previously

- adopted code such as `ODF-001`. Consult recovered history only to resolve a

- consequential identity or match, not on every review. When decisive evidence

- identifies a removed issue, recover that identity: reuse its heading code and

- do not allocate a new ID. Do not restore a pruned occurrence, and do not

- inflate the visible count, when the current review is an identical rereview

- of a pruned execution. If missing history prevents safe identity resolution,

- report that limitation instead of inventing a new issue or count. If the

- relationship is uncertain, or the finding has no supported match, and identity

- remains safely allocatable, create a separate issue with the next unused local

- `DD-NNN` and briefly state matching uncertainty when that is the reason. Never

- change another issue's ID to fill a gap.

+ 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.

- The next unused `DD-NNN` is one greater than the highest allocated local number.

- That high-water is the greater of the highest number on any issue heading still

- in the log (`DD-NNN` and adopted `ODF-NNN`) and the highest allocated local

- number recorded in retention metadata, when present. Never reuse a removed ID.

- Removing the highest-numbered issue does not make its ID reusable. When

- retention metadata is present, update its highest allocated local number

- whenever a new ID is allocated, including ordinary writes that do not remove

- content. Do not allocate a `DD-NNN` that collides with an existing heading

- number. If `ODF-001` is present or recorded in the high-water, do not allocate

- `DD-001`. If a gap exists and high-water or recovery cannot establish whether a

- missing number was allocated, do not fill that gap; report the limitation when

- a new ID cannot be allocated safely.

+ 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.

- Within a matched issue, treat equal execution identities as one occurrence. An

- identical rereview makes no edit, including an identical rereview of an

- execution whose occurrence was pruned. Add only newly available decisive

- evidence or a corrected qualified conclusion to that existing row, without

- discarding its prior evidence or human notes. Evidence of the same concrete

- issue in a distinct execution adds one occurrence row. A second symptom in the

- same execution does not add a row. Keep retained rows as the count; they are

- not an all-time recurrence total.

+ 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.

- When those rules produce a supported edit, construct the complete ordinary

- candidate first, then measure, retain if required, warn, write, or refuse using

- [bounded process-log recording](references/bounded-process-log.md). Load that

- reference only for an enabled process write. No-findings and an identical

- rereview are not candidate writes; do not load that reference for them.

- Skipped or unresolved process review never loads the log or that reference;

- follow [Select reviews](#select-reviews).

+ ## Review product learning

- If malformed or ambiguous content prevents safe identification of entries,

- executions, or the next unused ID, leave the entire existing file byte-identical

- and report a recording limitation. Do the same when a write fails or when

- bounded retention cannot form a safe candidate. Return the supported findings

- and continue other independently supported reviews; never describe either case

- as a successful write.

+ 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.

- In the final response, give a concise recording result: the canonical path and

- created issue IDs with occurrence rows, or `unchanged`/`not recorded` and the

- reason. Include any size warning, bounded-retention report, or size-limited

- refusal required by

- [bounded process-log recording](references/bounded-process-log.md). Do not

- describe a skipped, refused, failed, or size-limited write as successful.

+ 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.

- Surface a concrete overlooked request, decision, warning, failed verification,

- or Jidoka stop only when the record clearly shows that it still needs user

- attention. Put this banner at the absolute end when that gate passes:

+ ## 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 !!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

```

- ## Review product learning

- When product review is enabled, apply the shared direction consideration, then

- inspect queue entries and canonical stories only when they are relevant to this

- execution or a supported finding. An isolated urgent fix with no connection to

- other queued work does not trigger queue investigation. Preserve existing priority

- instructions.

- Connect supported learning to a relevant priority or story recommendation, or

- state a reasoned no-change result. Do not claim to validate unread backlog

- entries. Do not invent learning. Label inspirations as hypotheses. When

- beneficiary or outcome is unresolved, return a concrete exploration proposal; do

- not launch discovery or decomposition.

- If backlog or story conventions cannot be resolved, keep product conclusions

- provisional, identify that gap, and do not invent files. Independent supported

- implementation and enabled process review still proceed.

- Do not apply backlog or canonical-story edits during retrospective. Report

- recommendations, remaining proposals, and unresolved choices for

- [dough-story-wrap-up](../dough-story-wrap-up/SKILL.md). Standalone

- [dough-product-backlog](../dough-product-backlog/SKILL.md) maintenance remains

- available when a human requests it separately. A skip option is never write

- authority.

- Leave unresolved: a disputed goal or scope, conflicting explicit priorities, and

- ideas whose beneficiary or outcome is unknown. Do not implement product or

- implementation findings.

- ## Report

- Report the resolved feature story or bounded correction and completion state,

- provenance, included commit manifest and review boundary, findings ordered by

- impact or `none`, planning

- result, and evidence limitations. Include supported process proposals only for

- enabled process review. When process selection is unresolved, report the

- configuration error and omit process analysis. Include product recommendations or

- a reasoned no-change result only for enabled product review; do not report backlog

- writes from this skill. Omit skipped-focus analysis, suggestions, and destination

- writes. Distinguish evidence from hypotheses, and recommendations from

- proposals and unresolved choices. State whether planning was updated in place,

- newly generated, read-only, unchanged, or not yet available because the

- execution boundary remains unresolved. End with:

- `## EXECUTION RETROSPECTIVE COMPLETE`

- Append the attention banner after that marker only when its evidence gate

- passes; otherwise nothing follows the marker.