git:20260923.6a7e92d to git:20260924.33c3ff5

---

name: dough-story-wrap-up

description: >-

Closes one completed feature story, bounded retrospective correction, or

context-only planless execution using available execution context. Assimilates

lasting product knowledge, handles existing follow-ups and authorized product

decisions, removes that work's spent plan and history so Git can recover it,

and reports truthfully when required inputs are missing or unfinished. Use to

wrap up a story, correction, or completed contextual instruction, close

completed work, or delete spent plan and execution history.

---

# Story wrap-up

Close one selected feature story, bounded retrospective correction, or contextual

instruction when the coordinator invokes wrap-up. Use available execution context

and optional retrospective advice. Leave this project with maintained product knowledge

and no spent source or plan history in the current snapshot. Do not invent findings,

records, or a requirement for another conversation.

## Resolve this project's context

Require one selected work identity. Use a canonical feature story only when it

is explicitly supplied as that work's active home. Otherwise use the bounded

correction plan itself when it satisfies the correction-input contract defined by

[planning scope and lifecycle](../dough-story-refinement/references/planning.md#choose-the-planning-level).

Do not require or create a seed for that correction. When the source is neither

a story nor a correction plan, use a contextual instruction with retained

execution identity, changes, and proof; do not require or create a story, plan,

or queue entry. Name any missing required field, leave the affected work intact,

and stop before closure. Do not invent conventions, artifacts, another review, or

claim closure.

Resolve from this project, not this skill's location:

- repository root and Git working tree;

- canonical seed location, story identity, heading or stable-anchor conventions

for a selected feature story;

- for planned work: executable-plan location, status vocabulary, and the

selected work's plan identity;

- for planless work: the supplied story or instruction, its changes, available

execution results, and retained execution identity;

- optional retrospective advice when present, including an empty result;

- Git commit conventions used to preserve a recoverable revision;

- selected mode and available originating checkout, execution checkout and

branch, and integration-target identity;

- the product backlog path when a **Taken** or **Backlog list** entry points

at the selected work; and

- shared records that name the selected work: its seed when applicable, process

log (`DearDough.md` unless this project sets another canonical location),

incoming links, and assessment records.

Before deleting a plan that carries planned-execution identity, retain the

resolved mode and checkout, branch, and target values in the coordinator's

available execution context for the remaining wrap-up actions and report. Do not

create a parallel registry. Missing identity needed by a later action stops that

action instead of reconstructing or guessing it after plan deletion.

## Establish execution completion

Judge completion from the selected work and available execution evidence.

- Planned work is complete when every slice is done.

- Planless work is complete when the supplied story or instruction, changes, and

execution results show the promised outcome, including evidenced no-change.

- Incomplete implementation leaves the affected active work intact. Report the

unfinished implementation and stop. Do not delete an unfinished correction

plan to manufacture a wrap-up.

Apply available retrospective advice under existing authority. Absent/empty advice

still permits ordinary closure from work context, implementation results,

maintained knowledge, existing follow-ups, and coordinator instructions.

## Assimilate lasting knowledge

Move lasting behavior and design into this project's maintained code, tests,

documentation, or current Accepted decisions. Describe the current product

without execution narration, impact chronology, story or plan identity, or

retrospective judgments. Preserve existing product tests and documents that

already state current behavior. Do not invent product knowledge. When a current

product fact is written only in spent execution context or review and is not

already stated in maintained documentation, write it into maintained documentation

before deleting that spent copy. Tests that exercise related behavior do not

replace that documentation step.

For North Star topics cited, added, or revised by the completed work, apply the

shared [topic-retirement instructions](../dough-slice-planning/references/architectural-thinking.md#retire-temporary-direction-during-ordinary-wrap-up)

as part of ordinary closure.

## Queue an existing follow-up plan first

When an existing follow-up plan is present, validate it against the

correction-input contract above, then put its one canonical active home first in

the queue. Do not refine, replan, or execute it. Preserve the plan contents

needed for later execution. Handle that follow-up by its presence, including when

retrospective advice is absent.

Resolve one canonical active home under [dough-product-backlog](../dough-product-backlog/SKILL.md#canonical-active-homes):

- If a canonical follow-up story is supplied, keep that story in its seed and

link the plan there. Queue the story; do not duplicate it as a plan entry.

- Otherwise queue the existing correction plan directly. The plan is its

canonical active home; do not create or recover a seed solely for queueing.

- If required correction input is missing, name the missing field and do not

guess or queue the addition. Keep the follow-up plan and any other needed

active-work context, report the gap, and stop before deleting the completed

predecessor's history.

Preserve unrelated queue order after that first item, near-future direction,

and human text. Repeating wrap-up must recognize either canonical home and must

not duplicate the follow-up or queue entry.

## Apply product-review decisions

When retrospective product advice or additional human input is present, apply

only authorized compatible backlog and canonical-home changes. Follow

[dough-product-backlog](../dough-product-backlog/SKILL.md) for queue and

active-home conventions. Explicit human input wins over advice.

Supported changes: relevant reorder, queue membership, understood new-story

addition, understood bounded-correction plan addition, and canonical-detail

edits. Apply the backlog skill's canonical-home admission rules to every new

entry. Keep existing follow-up work first unless a later explicit human

instruction changes that priority. Preserve unrelated content, still-needed

acceptance work, and near-future direction.

A skipped, empty, or absent product review, or absent extra human input,

introduces no mandatory question. Ordinary closure continues using the other

available inputs. Leave unresolved necessary context with active work and report

the choice; do not invent scope, launch discovery, or start another review.

## Commit closure inputs and preserve Git recovery

After supported follow-up queue changes and before deleting anything, make the

current revision recoverable with this project's ordinary Git conventions.

Commit all owned review and closure-input changes in that revision, including

applicable retrospective edits to the process log, an uncommitted active

follow-up plan and its queue edit, assimilated product knowledge, and the spent

material. Preserve unrelated changes and include only files or portions whose

ownership is unambiguous. Resolve ownership of the intended cleanup targets at

this boundary too, before deleting any of them. Then record that revision as the

before-cleanup commit, even when the current revision was already suitable. If

commit conventions, ownership, or recovery cannot be resolved, leave the material

intact, report the gap, and do not claim closure. When the selected mode is Trunk

Mode, publish that commit through [wrap-up closure publication](../dough-execute-plan/references/trunk-publication.md#publish-wrap-up-closure)

## Delete spent history, including shared records

After completion and Git recovery are established — including any required Trunk

Mode before-cleanup publication — delete the selected work's spent history under

[wrap-up cleanup](../dough-product-backlog/references/record-preparation.md#wrap-up-cleanup):

- its executable plan and owned proof, evidence, and assessment records, even

when the plan was retained at execution completion;

- its canonical story section when one exists, and its seed only when every

remaining section is spent;

- links whose sole purpose is preserving that history.

Remove empty directories belonging to the spent work, including untracked ones.

The current snapshot must be free of that history, both tracked and untracked,

with recovery available from the recorded before-cleanup commit.

Preserve unrelated human text, sibling stories and log entries, product and

version identity, maintained tests and documents, still-needed acceptance work,

the completed work; leave uncertain portions intact and report the ambiguity.

Keep an active follow-up's queue link, correction input, and provenance. If its

source locator points into deleted predecessor history, replace the locator

with the before-cleanup commit and repository-relative path. Repair Markdown

links broken by cleanup without recreating spent history. Repeating wrap-up

must recognize already-completed cleanup without duplicating edits. Missing

artifacts alone do not establish completion of another work item.

## Commit final closure

Review and commit the owned closure changes using this project's Git conventions,

preserving unrelated changes. Both the before-cleanup revision and the final

closure must be committed in either execution mode; uncommitted cleanup is not

completion. Report unresolved ownership or commit failures without claiming

closure.

Direct-current-branch mode stays in the recorded checkout and creates no

worktree. Local-only closure commits there and reports that revision as

committed and pending publication; it does not push. Publish-authorized

closure uses [wrap-up closure publication](../dough-execute-plan/references/trunk-publication.md#publish-wrap-up-closure)

from that checkout. The receipt is the accepted SHA and the authorized target.

Trunk Mode publishes the final-closure commit through that same publication,

then continues with resource cleanup below. Story Branch Mode continues with

integration and resource cleanup below.

## Integrate committed Story Branch Mode closure

Save the final-closure tip already published on the remote execution branch.

Follow [Story Branch integration observation](../dough-execute-plan/references/trunk-publication.md#observe-story-branch-integration)

for the target transition, publication, and shared completion on the accepted

integrated SHA. Its publication uses [Preserve published history](../dough-execute-plan/references/publish-the-candidate.md#preserve-published-history)

from the owned execution workspace, excluding the integration checkout's

unrelated commits and pending human edit.

When the merge touches the product backlog, use the owned workspace's installed

merge adapter as that procedure requires. A stopped result stays as Git left it.

Resolve it through

[a real conflict](../dough-product-backlog/references/merge-conflicts.md#a-real-conflict-resolve-by-hand-then-continue-through-the-same-adapter).

If the adapter and that reference are unavailable, report the gap and leave the

conflict. Stop when no coherent resolution is justified. Selected-work cleanup

alone does not prove a sibling backlog change survived.

Require that procedure's accepted receipt before resource cleanup. The receipt

is the accepted candidate SHA and the remote trunk ref. A superseded candidate

is not the receipt. Unresolved integration preserves the execution resources

and blocks completion. Do not force-push.

## Remove execution resources safely

After Story Branch Mode's verified integration and required target push, or after

Trunk Mode's final accepted closure has a completion receipt whose shutdown is

confirmed, remove this execution's clean local worktree and local execution

branch. Use retained identity and non-force operations. Preserve unrelated

resources, unique or unpublished work, a dirty checkout, unconfirmed shutdown,

and a worktree that still hosts an active checkout-bound observer under

[preserve pending local work](../dough-execute-plan/references/maintain-default-checkout.md#preserve-pending-local-work).

Trunk Mode never deletes a remote execution branch. Story Branch Mode deletes

the remote branch only when its tip is integrated in the remote target. Verify

removal, accept already-absent resources on retry, report blocked or partial

cleanup without repeating already-completed closure, and skip cleanup in

direct-current-branch mode.

## Report

Report selected work and identity, completion judgment, mode and retained

checkout/branch/target, before-cleanup and final-closure commits when deletion

happened, Trunk Mode published closure SHAs, the completion receipt (CI verdict

or exact unresolved reason with shutdown evidence), remaining CI coverage,

assimilated knowledge, deleted paths, Story Branch saved tip and

integration/push results when the target is `main`, worktree and branch cleanup

results (remote deletion only when verified absent), preserved material and

resources, and any gap. Distinguish a new merge from an already-integrated tip,

integration from refused cleanup, an accepted trunk receipt from a superseded

candidate, committed pending publication from an accepted receipt, and completed

wrap-up from a refusal that left files intact. End successful closure with

`## STORY WRAP-UP COMPLETE`. Missing context, unfinished work, unresolved

recovery/integration, required push, unpublished Trunk Mode closure, retained

or unconfirmed observation, or resource cleanup blocks that marker. Local-only

current-branch pending publication is not a required push.