---
prompt_version: 1
layer: phase
action: build
---

# Prompt: Build Phase Overview

Use the upstream slice overview and repository context to create or update a phase overview.

## 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.
- Create missing canonical artifacts only for the selected layer. When revising an existing artifact, update it in place and do not create sibling, child, paired, or alternate artifacts unless the current user request explicitly asks for that creation step.
- Document a phase-level purpose and scope.
- Describe milestone candidates without defining task execution procedures. Keep only the bounded prospective task contracts required by `## Scaffold Evidence` for phase readiness and later milestone projection.
- Use the minimum number of milestone candidates needed to fully implement the phase. Do not add milestone candidates merely to turn inferred detail into extra prose.
- Split milestone candidates only for meaningful acceptance checkpoints, dependency order, validation strategy, rollback path, ownership boundary, risk, or readiness state.
- In a generated phase overview, `## Milestones` must declare at least one ordered milestone slug with a short description. Before link materialization, use raw backticked slug bullets such as ``- `01-license-payload-contract`: define signed payload parsing and canonicalization behavior.``. After link materialization, the same declaration may be a Markdown link bullet such as `- [01-license-payload-contract](milestones/01-license-payload-contract/milestone-overview.md): define signed payload parsing and canonicalization behavior.`.
- Milestone slugs declared in phase overviews must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, be unique, and appear in ascending order.
- Do not leave prose-only milestone bullets or placeholder milestone text such as `To be planned.`, `TBD`, `TODO`, or `Pending.` in saved phase overviews.
- Record acceptance criteria for the phase-level outcome and handoff.
- Give each acceptance criterion a stable ID. Readiness accepts raw (`EW-AC-01:`), backticked (`` `EW-AC-01`: ``), or bracketed (`[EW-AC-01]`) labels and normalizes the ID independently of its Markdown decoration.
- Capture dependencies, risks, validation focus, and unresolved questions.
- Preserve the complete canonical phase H2 order from the template, including `Implementation Target Paths`, `Validation Commands`, `Rollback / Recovery`, and `Scaffold Evidence`.
- Add one `## Scaffold Evidence` block per declared milestone in phase order. Each block must contain the readiness contract consumed by phase review: milestone criterion ownership, positive target task count, a boundary-based decomposition rationale, and the matching ordered prospective task contracts with current/desired behavior, dependency, repository-native target paths, validation, rollback, and command-facing adapters when applicable.
- When revising an existing phase overview, evaluate status and upstream traceability separately from body edits. Apply deterministic metadata changes only through an explicitly authorized `phase update` or metadata command; otherwise report them as metadata-hygiene follow-ups.
- Label assumptions explicitly instead of silently inventing scope, sequence, or validation detail.
- Preserve traceability to the source spec and slice overview.
- After creating or revising the phase overview, run `<day-shift-cli> validation links-check --scope planning --artifact <phase-overview-path>` as read-only local trace-link evidence, then run `<day-shift-cli> link materialize --dry-run --artifact <phase-overview-path>` and use `<day-shift-cli> link materialize --write --artifact <phase-overview-path> --validation-evidence-id <evidence-id>` only when the dry-run reports safe selected-artifact body-reference changes, using the exact `validationEvidence.evidenceId` returned by that dry run. `<day-shift-cli> validation smoke --scope planning --artifact <phase-overview-path>` may be used to check the `declared-child-slugs` lane for milestone declaration syntax; that lane accepts both raw backticked slug bullets and materialized Markdown-link slug bullets. Treat validation findings as evidence only; treat link materialization as an explicit selected-artifact body-link write only, not as permission to mutate metadata or create downstream artifacts.
- Stop and report instead of guessing when the selected artifact and upstream evidence conflict materially.
- Preserve user-authored content when updating an existing phase.
- Use repository-relative paths throughout the artifact.
- Preserve the canonical artifact-shape contract from `.day-shift/specs/06-templates-and-prompts/templates.md`: one visible H1, the required H2 section names in order, parser-safe `Open Questions` none-state, and no leaked scaffolding prose or unresolved placeholders in the saved artifact.

## Template Reference

Use `.day-shift/templates/phase-overview.md` as the artifact shape.

## Required Output

Create or update a phase overview artifact with the configured template sections and valid front matter.
