---
prompt_version: 1
layer: reconciliation
action: review
---

# Prompt: Review Reconciliation

Review the reconciliation artifact for closure quality and traceability.

## 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.
- Determine whether the reconciliation artifact is ready to support an acceptance decision, not only whether the current metadata already says so.
- For `<day-shift-cli> implementation-summary review` and `<day-shift-cli> reconciliation review` contract work, keep both command surfaces read-only and findings-oriented: evaluate evidence quality, metadata/body alignment, and closure risks without writing files.
- Verify original intent, completed work, acceptance criteria review, validation review, discovered work, backlog work, accepted residual work, and follow-up tasks.
- Verify mode-aware runtime evidence: contract summaries may support frozen contract acceptance without runtime claims, while runtime and hybrid acceptance requires Runtime Delta targets, runtime changed paths, executable validation evidence, or structured validation exceptions for blocked validation commands.
- Flag a warning when follow-up or reviewed-scope wording uses `define` as an action verb without clearly naming a contract, boundary, schema, vocabulary, policy, rule, interface, or decision deliverable. If the intended work is initialization, implementation, documentation, evidence capture, review, or validation, recommend the more specific verb.
- Check that reconciliation status is accurate.
- Check that front matter matches the body, especially reconciliation status and upstream traceability.
- If the body supports advancing reconciliation status but the front matter has not yet been updated to reflect the available evidence, treat that as a metadata-update recommendation rather than an automatic blocker.
- Treat review findings as assistive recommendations only; do not present findings as automatic acceptance, automatic rejection, or automatic status-transition writes.
- Treat validation and reconciliation review findings as evidence-only; they do not authorize repairs, status mutation, artifact creation, or inferred runtime acceptance without a separate explicit write command.
- Treat stale metadata as a blocking issue only when it creates real ambiguity about closure state, acceptance readiness, or follow-up handling, or when the body still lacks enough evidence to justify advancing the metadata.
- For metadata-update integration or unsafe-update reporting work, verify the reviewed artifact still describes one caller-to-helper seam, blocking no-write behavior for wrong-family, ambiguous, inconsistent, under-specified, and lossy requests, and reporting as evidence of rejection rather than permission to continue with guessed writes.
- For `<day-shift-cli> reconciliation update` contract work, verify field-family boundaries remain explicit: `reconciliation_status` is applicable while `readiness` and `implementation_status` stay rejected as wrong-family requests, planning-coordinate updates remain coherent and coordinated with applicable parent-link paths, and direct update semantics remain separate from reconciliation review/acceptance automation.
- For sync-status-from-review contract work, verify that sync eligibility requirements are deterministic and bounded to the eligible artifact families and evidence states in the artifact model, that rejection rules cover ambiguous and judgment-heavy cases as blocking no-write outcomes, and that sync-status-from-review is not conflated with generic `<day-shift-cli> metadata update` semantics.
- For metadata inventory contract work, verify that inventory is described as strictly read-only with no write path, that its reporting scope is bounded to metadata state and helper coverage rather than general repository health, and that inventory output is framed as operator-visible evidence rather than automation authorization.
- Confirm that review concerns are explicit.
- Confirm that accepted residual work is explicit and justified as non-blocking when present; move unresolved acceptance risks to review concerns instead.
- Identify whether the reviewed work can be accepted, rejected, deferred, or needs more review.
- Identify missing evidence, unclear review conclusions, or follow-up gaps that would prevent a trustworthy acceptance decision.

## Required Output

Return findings grouped as:

- Blocking Issues
- Warnings
- Follow-Up Work
- Metadata Updates Needed
- Reconciliation Status Recommendation
- User Decisions Needed
