---
prompt_version: 1
layer: implementation
action: next
---

# Prompt: Implementation Summaries To Milestone Reconciliation

Use the selected milestone overview or milestone directory and completed task implementation summaries to create the milestone reconciliation artifact.

## Instructions

- Command placeholder: Expand `<day-shift-cli>` to the resolved session invocation. Use `day-shift` for installed/user mode after verification, and use `node dist/cli/index.js` in repository development mode when compiled `dist` output is current.
- Prefer command-supported implementation-summary build/review/update and reconciliation build/review/update surfaces before inference or manual artifact edits. When no suitable command owns the needed change, record `unsupported by CLI`, `CLI failed`, or `manual recovery after scaffold verification` instead of inventing command behavior.
- When reconciliation guidance depends on command availability, lifecycle role, write posture, selected-artifact requirements, callable versus registry-only state, or mixed-posture family behavior, use `<day-shift-cli> commands inventory --format json` as read-only machine-readable evidence before drafting accepted residual work or follow-up candidates.
- This prompt is the canonical `next` action for the `implementation` layer: it advances only from completed task execution evidence into milestone reconciliation. Do not reuse it as `build`, `review`, or as permission to normalize task-level reconciliation into the default downstream path.
- Support inputs that point either to the milestone overview or to the milestone directory, and infer the matching canonical `milestone-overview.md`, supported legacy `overview.md`, or sibling `reconciliation.md` path when needed.
- Use `.day-shift/templates/` as the project-local working customization surface for reconciliation handoff updates, without treating prompt references as packaged-default membership declarations.
- Treat any prompt `template_ref` or `template_refs` metadata as source-template and output-shape guidance only; do not inline template bodies automatically or reinterpret those references as destination-routing rules.
- If the milestone-level `reconciliation.md` artifact does not exist yet, create it from `.day-shift/templates/milestone-reconciliation.md` as part of this handoff rather than stopping for human intervention.
- For `<day-shift-cli> reconciliation build` contract work, keep one canonical pairing: use milestone overview plus task implementation summaries as source evidence, write only to the milestone `reconciliation.md` destination under the same hierarchy, and preserve `.day-shift/templates/milestone-reconciliation.md` front-matter and heading shape.
- Treat `<day-shift-cli> reconciliation build --milestone-overview <path>` as a required first write for eligible full-milestone closeout, not as an optional suggestion. After the command runs, re-open the written `reconciliation.md` and verify that the placeholder body was replaced with concrete completed-task summary links, acceptance-criteria review, validation review, final notes, and a stated milestone verdict before reporting the milestone complete.
- Preserve reconciliation artifact creation/scaffold provenance in front matter unless an explicit metadata update command changes it. Treat `reconciliation build` and `reconciliation review` as closeout evidence to record in body sections, not as automatic replacement values for `workflow_cli_command` when that field records the artifact's scaffold command.
- Planning artifacts may be untracked while active work is in progress. Do not call out `git status` `??` output for task, milestone, phase, or slice artifacts in closeout unless the user asked for git state, commit readiness, or PR preparation.
- Do not route ordinary implementation closeout into a task-level reconciliation artifact first. Task-level reconciliation remains an exception path only when a task-local review boundary is explicitly justified.
- Preserve task-level reconciliation as an explicit exception path rather than collapsing milestone and task review surfaces into one default destination.
- For `<day-shift-cli> reconciliation review` contract work, keep review strictly read-only and findings-oriented: report evidence sufficiency and gaps, but do not treat findings as automatic acceptance or status-transition writes.
- Use task `implementation-summary.md` files as the implementation source of truth.
- Confirm that every task summary under the milestone carries both `implementation_status: completed` and `status: completed`, with non-placeholder body evidence, before treating milestone reconciliation as eligible. Summaries with `implementation_status: pending`, draft `status`, missing files, or placeholder-heavy content mean the milestone is not ready for reconciliation.
- If the milestone is not ready for reconciliation, stop and report the next task-summary closeout step instead of refreshing or completing `reconciliation.md`.
- Set `reconciliation_status` based on review completeness: `pending` when review has not started; `partial` when review is underway but some criteria remain unreviewed or task summaries are missing or still `implementation_status: pending`; `blocked` only for review-side blockers (missing evidence, unresolved concerns, or reviewer unavailability — not implementation-side failure); `completed` only when all milestone acceptance criteria are reviewed against task summary evidence and a milestone verdict is stated without placeholder content.
- Keep `reconciliation_status` and `status` independent: advance both when the review is finished — `reconciliation_status: completed` and `status: completed` together. Use `<day-shift-cli> reconciliation update` for CLI-supported reconciliation metadata transitions when available; direct front matter edits require an explicit manual exception.
- For metadata-update utility integration work performed during reconciliation updates, keep one canonical caller-to-helper seam: identify metadata family first, pass direct intended-value updates, delegate mutation execution to shared helpers, and treat helper rejection as a blocking no-write outcome without command-local fallback rewrites.
- For unsafe-update detection/reporting work performed during reconciliation updates, treat wrong-family, ambiguous, inconsistent, under-specified, and lossy mutation requests as blocking no-write failures, disallow partial-write fallback semantics, keep reporting aligned with existing RuntimeError/finding-oriented validation surfaces, and treat surfaced failures as review evidence rather than permission to continue with narrowed or guessed writes.
- For `<day-shift-cli> implementation-summary update` contract or behavior work, keep field applicability strict: allow `status`, `implementation_status`, and applicable planning fields only when coordinate transitions are coherent and parent links are updated coordinately; reject `readiness` or `reconciliation_status` requests as wrong-family no-write failures.
- During reconciliation updates, do not mutate non-applicable status families (`readiness` or `implementation_status`) on reconciliation artifacts; treat such requests as contract violations that must be rejected instead of normalized.
- During reconciliation updates, treat planning coordinates as identity-bearing fields: update applicable `slice`, `phase`, `milestone`, and `planning_depth` values only in explicit coherent transition scenarios, coordinate applicable parent-link updates when affected, and reject partial or contradictory coordinate rewrites.
- Compare milestone intent and acceptance criteria against the combined task outcomes.
- Preserve execution-mode evidence when rolling task summaries into reconciliation. Contract summaries preserve frozen contract evidence but cannot satisfy runtime acceptance criteria that remain pending; runtime and hybrid summaries must show Runtime Delta targets, runtime changed paths, executable validation evidence, or structured validation exceptions before runtime acceptance is treated as complete.
- Roll up validation evidence, cross-task follow-up notes, and any remaining gaps.
- This prompt may record planned work, discovered work, backlog work, accepted residual work, and follow-up tasks in milestone reconciliation, but it must not create follow-up phases, milestones, task definitions, or nested scaffolds.
- Use `Accepted Residual Work` only for reviewed gaps or deferred adoption that do not block milestone acceptance; state why they are non-blocking instead of hiding them under `Review Concerns`.
- Wording such as `move downstream`, `plan next work`, `identify follow-up work`, or `suggest next step` inside implementation handoff means record candidate follow-up work and stop unless the user separately invokes the matching planning prompt or an explicit create/scaffold command.
- If reconciliation identifies broad follow-up planning that spans more than one layer, report a proposed scaffold plan as review guidance only. Nested scaffolding requires an explicit programmatic nested-scaffold request once such tooling exists.
- When rolling up metadata-validation work, preserve the selected-file versus directory evidence distinction and call out whether prompt-family Markdown, planning-artifact Markdown, unsupported-family findings, ambiguous-family findings, and no-write behavior were validated.
- When validation guidance is needed before reconciliation, use `<day-shift-cli> validation smoke --scope planning --artifact <milestone-overview-path>` as focused read-only evidence. If it recommends advancing the next task because reconciliation is premature, follow that evidence and do not edit reconciliation in this pass.
- If validation evidence includes trace-link lifecycle dispositions, record retired, deleted, migrated, malformed-storage, or applied-migration findings as validation review evidence. A recommendation to run `link disposition preview` or migrated-only `link disposition apply` is not reconciliation authority to repair links, infer replacement targets, rewrite body references, mutate disposition storage, or apply retired/deleted dispositions.
- Treat the completed task summaries as the only normal implementation-to-review handoff inputs; do not require a separate task-local reconciliation artifact before milestone review can proceed.
- Separate planned work, discovered work, backlog work, accepted residual work, and follow-up tasks.
- Do not claim final acceptance automatically.
- Leave explicit review fields for the user or reviewing agent.
- When updating an existing reconciliation artifact, refresh reconciliation status, upstream traceability, and other review-state front matter metadata so it reflects the current review state rather than the original draft state, while preserving scaffold provenance fields as described above. Apply CLI-supported metadata transitions through `<day-shift-cli> reconciliation update` instead of direct edits.
- When updating an existing reconciliation artifact, edit the existing sections in place under their current headings instead of regenerating the entire file. Preserve the heading structure and replace only the sections whose content changes.
- Do not report full milestone reconciliation as complete while `reconciliation.md` still contains placeholder lines such as `Pending.`, `Pending milestone review.`, `Pending review after task implementation summaries are available.`, or `Pending. Add completed task implementation summaries as milestone execution work finishes.`. Either replace the placeholder sections with concrete review evidence or report the reconciliation as blocked with the exact missing evidence.
- Check that front matter matches the body before finishing the artifact update.
- Stop and report instead of guessing when the selected artifact and task-summary evidence conflict materially.
- Preserve traceability to milestone, phase, slice, source spec, and the reviewed task summaries.
- Use repository-relative paths throughout the artifact.

## Template Reference

Use `.day-shift/templates/milestone-reconciliation.md` as the artifact shape.

## Required Output

Create or update a milestone reconciliation artifact with the configured template sections and valid front matter. For eligible full-milestone closeout, the final artifact must be non-placeholder, must cite every completed task implementation summary, must review acceptance criteria and validation evidence, must state a milestone verdict, and must either complete reconciliation metadata through the supported update command or report the exact blocker preventing that transition.
