dough-execution-retrospective git:20260913.706255dA

Immutable. This exact content never changes and is served at /api/v1/blob/5249c74c9f77a5ab.

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

# 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
[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.

## Work from these principles

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

## 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`.

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.

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

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.

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.

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.

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

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

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.

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.

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

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

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.

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.

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.

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

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

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.

For a new log, write this minimal Markdown shape, assigning `DD-001` upward in
the order of supported findings:

```markdown
# DearDough Process Findings

## DD-001 — <descriptive issue title>

<concise concrete description>

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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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:

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

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