---
artifact_schema_version: 1
artifact_type: workflow
workflow_id: phase-agent-lifecycle-guide
---

# Phase Agent Lifecycle Guide

Use this guide when the user wants an agent to coordinate a full lifecycle at phase scope: verify the declared milestone set, create missing declared milestone artifacts, delegate each milestone through the milestone lifecycle, review phase evidence, and hand off the remaining work clearly.

Agent entrypoint route: read `.day-shift/agents.md` first, then use this guide for phase-scope coordination. Human workflow files may orient the session, but this guide owns the full agent phase lifecycle.

This guide is phase-oriented orchestration. It composes existing Day Shift workflows instead of replacing them:

- `.day-shift/workflows/02-plan-from-spec.md` owns phase-to-milestone planning and milestone scaffolding.
- `.day-shift/workflows/milestone.agent-lifecycle-guide.md` owns one milestone's full lifecycle.
- `.day-shift/workflows/04-summarize-and-reconcile.md` owns review-family boundaries and phase evidence review after milestone reconciliation exists.

The selected phase overview artifact remains the source of truth for the declared milestone set, milestone order, phase intent, acceptance criteria, upstream traceability, validation focus, and parent planning context. New phase scaffolds use `phase-overview.md`; supported legacy phases may still use `overview.md`.

## Agent Orientation Command

`<day-shift-cli> agent` is the read-only agent orientation command. Use it at the start of an automation-agent session to show the repository contract, entrypoint guidance, and command envelope before the agent chooses workflow-specific commands.

`agent orient` is the full-orientation alias, and `agent remind` is the shorter correction-focused reminder for sessions that have drifted from the repository contract.

## Purpose

Point the agent at one phase and have it drive:

- phase startup and repository-state checks
- declared milestone-set verification
- milestone directory scaffolding for every declared milestone
- milestone-by-milestone execution using the milestone lifecycle guide
- phase evidence review from completed milestone reconciliations
- deterministic metadata-update recommendations or explicit updates when authorized
- final reporting of completed, blocked, deferred, and discovered work

## Inputs

Require these inputs before starting:

- phase overview path or phase directory path
- run mode: `scaffold-only`, `readiness-only`, `implement`, or `review`
- whether the agent may create missing milestone directories and paired milestone reconciliation placeholders
- whether the agent may perform approved milestone-scope code, doc, planning, or metadata edits through delegated milestone lifecycles
- whether phase or stale milestone status metadata may be updated after evidence review

Prefer repository-relative paths in all artifact references and outputs.

When the user provides a phase directory, infer:

- phase overview: `<phase-directory>/phase-overview.md`, or `<phase-directory>/overview.md` for supported legacy artifacts
- milestone root: `<phase-directory>/milestones/`

## Canonical Surfaces

Use these surfaces intentionally rather than mixing ad hoc alternatives.

### CLI

- `<day-shift-cli> workflow explain --artifact <path>`
- `<day-shift-cli> planning next-action --artifact <path>`
- `<day-shift-cli> planning inventory --root <path>`
- `<day-shift-cli> planning gap-report --scope <path>`
- `<day-shift-cli> milestone new --phase-overview <path> --full-set`
- `<day-shift-cli> milestone review --milestone-overview <path>`
- `<day-shift-cli> phase review --phase-overview <path> --metadata-posture read-only|sync-on-clean-review`
- `<day-shift-cli> metadata sync-status-from-review --phase-overview <path> --review-result <phase-review.json> --metadata-posture sync-on-clean-review --dry-run`
- `<day-shift-cli> phase update --phase-overview <path> --run-directory <.day-shift/runs/run-id> --field status=completed` for lifecycle-managed selected-artifact writes
- `<day-shift-cli> milestone update --milestone-overview <path> --run-directory <.day-shift/runs/run-id> --field status=completed` for lifecycle-managed selected-artifact writes
- `<day-shift-cli> link materialize --dry-run --artifact <path>` for revision-bound link-gate validation and candidate preview
- `<day-shift-cli> link materialize --write --artifact <path> --validation-evidence-id <evidence-id>` for an authorized candidate write against that exact preview
- `<day-shift-cli> validation links-check --scope planning --artifact <path>` only for independent diagnostics or an exact required recheck
- `<day-shift-cli> task readiness-review --task-definition <path> --reviewed-by <actor> --reviewed-at <ISO-8601 timestamp>` inside delegated task lifecycles, only after the selected task has zero safe materialization candidates
- `<day-shift-cli> validation smoke --scope planning --artifact <path>`

Note the option boundary: `planning gap-report` selects its artifact or directory with `--scope`, while validation commands such as `validation links-check` and `validation smoke` use `--artifact` for artifact-scoped review.

Use broader validation only when the phase or delegated milestone explicitly needs repository-wide evidence. For phase navigation and readiness decisions, prefer artifact-scoped validation against the selected phase overview or selected milestone overview.

### Workflow Files

- `.day-shift/workflows/README.md`
- `.day-shift/workflows/01-start-here.md`
- `.day-shift/workflows/02-plan-from-spec.md`
- `.day-shift/workflows/milestone.agent-lifecycle-guide.md`
- `.day-shift/workflows/task.agent-lifecycle-guide.md`
- `.day-shift/workflows/04-summarize-and-reconcile.md`
- `.day-shift/workflows/workflow-guide.md`

### Prompts

- `.day-shift/prompts/user/phase.next.md`: canonical phase-to-milestone handoff prompt
- `.day-shift/prompts/user/phase.review.md`: canonical phase-layer review prompt
- `.day-shift/prompts/user/phase.recertify.md`: canonical phase-layer lifecycle hygiene prompt
- `.day-shift/prompts/user/milestone.next.md`: canonical milestone-to-task handoff prompt
- `.day-shift/prompts/user/milestone.review.md`: canonical milestone-layer review prompt
- `.day-shift/prompts/user/milestone.recertify.md`: canonical milestone-layer lifecycle hygiene prompt
- `.day-shift/prompts/user/task.next.md`: canonical task-to-implementation handoff prompt
- `.day-shift/prompts/user/implementation.next.md`: canonical implementation-to-reconciliation handoff prompt
- `.day-shift/prompts/user/reconciliation.review.md`: canonical reconciliation review prompt
- `.day-shift/prompts/user/reconciliation.recertify.md`: canonical reconciliation lifecycle hygiene prompt
- `.day-shift/prompts/user/reconciliation.next.md`: canonical reconciliation-to-follow-up prompt

The phase lifecycle should use phase-layer prompts first, milestone-layer prompts for the active milestone, and lower-layer prompts only through the delegated milestone lifecycle. Use recertify prompts when an existing artifact may be stale before advancing, reviewing, or relying on it; recertification remains read-only unless a separate explicit write request follows.

Mode-aware runtime evidence gate: preserve execution-mode evidence from task summaries through milestone reconciliation and phase review. Contract-only evidence may close contract-scope guidance or planning work, while runtime or hybrid phase acceptance requires reconciled Runtime Delta targets, runtime changed paths, executable validation evidence, or a structured validation exception for each blocked validation command. Phase review remains read-only evidence and does not authorize repairs, status mutation, or artifact creation without a separate explicit write command.

## Mode Semantics

Use the selected run mode to bound write authority before starting.

- `scaffold-only`: create missing declared milestone directories and paired milestone reconciliation placeholders, then stop. Do not complete milestone contracts, scaffold tasks, execute implementation work, reconcile milestones, run phase review, or update metadata.
- `readiness-only`: after milestone artifacts already exist or are explicitly scaffolded in the same request, check readiness without implementation writes. By default, check only the active milestone; run a phase-wide readiness sweep only when the user explicitly asks for one. Do not scaffold tasks, update implementation summaries, update reconciliations, or update metadata.
- `implement`: scaffold declared milestones when authorized, then run the active milestone as a full cycle before moving to the next milestone. Complete only the active milestone contract, scaffold only the active milestone's declared tasks, execute those tasks, complete implementation summaries, reconcile that milestone, then repeat for the next declared milestone.
- `review`: use only existing completed milestone reconciliations to run phase evidence review. Do not scaffold milestones or tasks, complete contracts, execute implementation work, reconcile milestones, or update metadata unless the user explicitly authorizes a separate metadata update after review evidence.

`Profile: full-cycle-strict` is compact invocation shorthand for `Mode: implement` plus the complete algorithm, stop conditions, delegated milestone lifecycle, safe-link gate, reconciliation re-open gate, and artifact contract in this guide. It does not add write authority. The invocation must name metadata posture as exactly `read-only` or `sync-on-clean-review` and separately state whether phase metadata writes are authorized; posture is recorded context, not permission.

If the requested mode is ambiguous, infer the narrowest mode that satisfies the user request and report the assumption before any write-capable command.

## Run-Scoped Lifecycle Evidence

Before the first command that emits transient readiness, review, reconciliation, validation, or other command evidence, resolve or create one repository-local run evidence directory at `.day-shift/runs/run-<run-id>/` and open its `.day-shift/runs/run-<run-id>/run-context.json` manifest. Under `Profile: full-cycle-strict`, this setup happens before the first delegated task readiness result is captured, even when the phase and milestone scaffolds already exist.

Reuse that exact manifest for the entire phase cycle. Include `Run evidence directory: .day-shift/runs/run-<run-id>/` in every delegated milestone invocation, and require milestone and task lifecycles to inherit it instead of creating sibling or nested run directories. The only required structured files are the manifest plus deterministic manifest-owned paths such as `.day-shift/runs/run-<run-id>/evidence/0001-task-readiness-task-readiness-review-ok.json`.

Do not write evidence files directly under `.day-shift/runs/`, and do not create unexpected sibling directories there; its direct children must remain canonical `run-<run-id>/` directories. Transient command output belongs in the selected run directory. Canonical phase, milestone, task, implementation-summary, and reconciliation artifacts remain in `.day-shift/planning/`, while separately owned durable local evidence stores remain at their declared repository-local paths. Do not move either durable artifact class into `.day-shift/runs/`.

If continuation inherits a legacy `sandbox/run-<run-id>/run-context.json`, inspect it read-only, run `<day-shift-cli> resume run migrate --run-directory sandbox/run-<run-id> --dry-run`, and apply only with that preview's exact `sourceSnapshot`. Continue from `.day-shift/runs/run-<run-id>/`; migration preserves the legacy source for explicit later cleanup. Never open a new root `sandbox/` run.

### Command Continuation And Evidence Inspection

Under strict lifecycle execution, an execution-surface response that includes a live process or continuation handle is `running`, not successful, failed, or timed out. Retain that handle and poll the same invocation until it reaches a terminal result; do not launch a duplicate command solely because the initial call yielded. A poll or caller wait budget ending while the handle remains live leaves the command in `running` state.

Use command states consistently:

- `running`: the original invocation has a live handle and no terminal result
- `timed out`: the command itself reached a terminal deadline outcome and is no longer running
- `interrupted`: the process or session ended without a command-owned terminal result; inspect possible side effects and freshness before an intentional retry
- `failed`: the invocation returned a terminal unsuccessful result
- `completed`: the invocation returned a terminal successful result with complete required output

While an invocation is `running`, poll its existing handle and provide user-visible progress at least once every 60 seconds without changing command identity. A retry is a new execution and is eligible only after the earlier invocation is known to be terminal and the lifecycle permits retrying it.

Inspect authored evidence with bounded, structure-aware reads. For Markdown, separate front matter from the authored body and select the named body section before searching; exclude serialized attempts, validation records, review receipts, and disposition payloads from body searches by default. For JSON or YAML, select exact structured fields. Bound the file set, match count, surrounding context, and output size before broadening scope, and do not begin with an unbounded repository-wide recursive text search over planning artifacts.

When serialized lifecycle metadata is the selected evidence source, parse it explicitly and inspect only the relevant attempt, validation, receipt, or disposition fields with bounded output. The default body-search exclusion keeps serialized payloads from flooding authored evidence; it does not discard them.

When a long-running phase needs a machine-readable interruption boundary, use
`<day-shift-cli> resume run open` to create
`.day-shift/runs/run-<run-id>/run-context.json`. Invoke every selected ordinary gate as
`<day-shift-cli> --format json --run-directory .day-shift/runs/run-<run-id> --run-gate <gate> --run-artifact <artifact> <ordinary command argv...>`.
`--run-artifact` may be omitted only when the manifest's current active artifact
is the correct attribution target. The global binding verifies a fresh manifest
before command execution but never authorizes the selected command or changes
its mutation contract. The shared success/error boundary writes the exact final success or error envelope once under
`evidence/` and appends its digest-bound manifest
entry; do not combine the binding with `--output-file`, shell redirection, or a
follow-up ordinary `resume run record` call.

`resume run record` remains available only for an explicit compatibility import
or partial-evidence recovery. If automatic capture cannot finish after the
underlying command reaches a final outcome, the returned envelope preserves that
command's status, identity, and exit classification and includes
`data.lifecycleRunCapture` with `writeOutcome: partial-evidence`,
`rerunUnderlyingCommand: false`, and non-callable recovery guidance. Preserve
that envelope, inspect `resume run status`, and never rerun the underlying
command merely to obtain evidence.

`resume run status` and `resume run resume` are read-only: they revalidate the selected phase, active
artifact, and recorded evidence digests before reporting current guidance.
The manifest's lifecycle profile, metadata posture, active gate, and command
history are context and evidence only. They do not execute a gate, authorize a
write, replace canonical task or review receipts, or permit advancing past a
failed or stale canonical check.

Every lifecycle-managed `phase update`, `milestone update`, or shared metadata
update must pass the inherited `--run-directory`. The writer verifies the run's
active artifact, active gate, manifest completeness, current digests, and
metadata posture before it plans a file change. Under `read-only`, lifecycle
status and readiness fields fail with a typed no-write result that routes back
to the applicable read-only phase or milestone review. Under
`sync-on-clean-review`, only `status=completed` for a target named by the exact
current indexed clean phase-review receipt is eligible; unrelated fields,
partial target selection, stale evidence, and a gate other than `phase-review`
fail closed. Omit `--run-directory` only for an independently authorized
standalone operator-selected update outside a lifecycle run; run context is a
restriction and freshness input, never independent write authority.

Under `Profile: full-cycle-strict`, bind each required gate-boundary command so
the shared output boundary captures it into the manifest as part of that one
invocation. The required entry set is:

- every milestone scaffold result under the `milestone-scaffold` gate
- every delegated task close result under the `task-closeout` gate
- every reconciliation build and review result under the
  `reconciliation-build` and `reconciliation-review` gates
- every final phase inventory, gap report, link gate, and smoke result under the
  `phase-final-validation` gate
- the final phase review result under the `phase-review` gate

An explicitly imported source result passed to compatibility `resume run record`
remains auxiliary transient evidence while its deterministic `evidence/` copy
is the indexed manifest entry. Put incidental structured diagnostics that are
not gate results under the run directory's `auxiliary/` subtree. Do not leave
other JSON results loose or unclassified: strict `resume run status` reports
deterministic indexed, auxiliary, unexpected, and `unindexedRequired`
structured-file counts. Every unexpected structured file is unindexed required
evidence and makes the manifest incomplete until it is imported or explicitly
moved into the auxiliary classification boundary.

A recorded, zero-blocker `phase review` result is terminal only when its receipt
uses `read-only` posture and its phase, milestone, and reconciliation revisions
still match canonical files. In that exact state, `resume run resume` returns
`terminalState: review_complete_read_only` and `nextPermittedGate: null`; it must
not recommend phase review again. A nonterminal review, stale receipt, changed
descendant, incomplete manifest, or `sync-on-clean-review` posture continues to
derive the exact callable next action from current canonical artifacts. Manifest
history never supplies authority for that action.

Lifecycle run open accepts only `--metadata-posture read-only` or
`--metadata-posture sync-on-clean-review`. Reject any other posture instead of
recording an open-ended synonym. A sync posture makes the later batch preview
eligible for consideration, but the explicit write command and current user
authorization are still required before apply.

Before executing a named strict profile, agents may run
`<day-shift-cli> workflow compile --profile full-cycle-strict --artifact <phase-overview> --format json`.
The compiler treats this guide, the selected canonical phase artifact, the
authoritative command descriptor registry, and any explicitly selected run
manifest as revision-bound inputs. Its compact result must identify one next
executable gate when ordering permits it. Routine compilation and generated
recovery repeat the compact invocation with no `--detail full`; explicit audit
uses `--detail full`, optionally with `--page-lane gates`. Compilation is read-only guidance: unresolved
actor, time, artifact selection, receipt, or authorization inputs remain
non-callable, unknown clauses or command drift fail closed with source
locations, and a compiled plan never performs a gate or grants write authority.

## Legacy Runtime-Acceptance Compatibility

`runtime_acceptance` is newer planning metadata. An existing phase or milestone overview that omits it is a supported legacy input, not by itself an incompatible workspace or a reason to stop `milestone new`, `task new`, or the `full-cycle-strict` lifecycle. Do not invent a `runtime_acceptance` block merely because a lifecycle profile is strict, and do not describe the missing block as a required schema migration.

When the selected parent has no executable runtime evidence, continue the normal lifecycle with the legacy artifact unchanged. When its authored acceptance criteria, Runtime Delta, or other executable evidence makes runtime behavior genuinely in scope, stop before making a classification: whether runtime acceptance is required and which stable criterion IDs apply are product/planning decisions, not values the CLI can infer safely.

The current `metadata update` and layer-specific `phase update` / `milestone update` commands do not author nested `runtime_acceptance` structures. Neither schema-mode nor structural-mode `workspace migrate` infers or authors that semantic contract: schema mode handles supported workspace-schema transitions, while structural `--check`/`--plan`/digest-bound `--apply` reorganizes existing planning artifacts. Do not recommend any of these commands as a repair for a missing runtime-acceptance block. Request explicit authorization for a reviewed planning edit when that semantic decision is needed, then rerun the selected lifecycle command.

## Starting

Start with the minimum context required to coordinate the selected phase safely:

- the selected phase overview artifact
- the phase `milestones/` directory, if present
- existing milestone overviews and milestone reconciliations beneath the phase, if present
- `.day-shift/workflows/02-plan-from-spec.md`
- `.day-shift/workflows/milestone.agent-lifecycle-guide.md`
- `.day-shift/workflows/04-summarize-and-reconcile.md`
- `.day-shift/prompts/user/phase.next.md`
- `.day-shift/prompts/user/phase.review.md`
- upstream specs, parent overviews, decisions, manifests, prompts, templates, or dependency artifacts named by the phase when they specify contract truth, validation semantics, or scope boundaries

Read broader surfaces only when phase context, trace links, or workflow choice is unclear:

- `.day-shift/agents.md`
- `.day-shift/workflows/README.md`
- `.day-shift/workflows/01-start-here.md`
- `.day-shift/workflows/workflow-guide.md`
- parent slice overview artifact
- `<day-shift-cli> workflow explain --artifact <phase-overview-path>`
- `<day-shift-cli> planning next-action --artifact <phase-overview-path>`
- `<day-shift-cli> planning inventory --root <phase-directory>`
- `<day-shift-cli> planning gap-report --scope <phase-overview-path>`
- `<day-shift-cli> validation links-check --scope planning --artifact <phase-overview-path>`
- `<day-shift-cli> validation smoke --scope planning --artifact <phase-overview-path>`

Use the selected phase overview to establish:

- phase intent
- acceptance criteria
- declared milestone slugs and milestone order
- target milestone count and decomposition rationale
- upstream traceability
- validation expectations
- phase review expectations
- parent slice context

Before creating or implementing anything, confirm the phase path is the active source of truth.

- Infer the phase directory from the selected phase overview artifact.
- Use existing milestone directories under the same phase directory only if they match declared milestone slugs or are explicitly identified as legacy/adopted milestone artifacts.
- If chat context or prior summaries disagree with the repository tree, trust the repository tree and re-resolve from the phase overview before editing anything.
- If the phase depends on a later phase, missing parent artifact, or missing producer artifact, stop and report the sequencing blocker.

## Full-Cycle Algorithm

Run this loop for the selected phase.

For normal `implement` runs, use this minimum command spine. A phase overview or active milestone overview may add stricter validation or sequencing inside the active milestone, but it does not authorize task scaffolding or execution for later milestones before the active milestone is reconciled.

1. Inspect repository state, preserve unrelated user changes, and resolve or create the one `.day-shift/runs/run-<run-id>/` evidence directory that this phase and every delegated lifecycle will reuse.
2. Confirm the phase overview has a valid ordered `## Milestones` section, then run `<day-shift-cli> phase review --phase-overview <path> --review-mode readiness --metadata-posture read-only --format json` and save the complete readiness result. Stop when it reports any `phaseAuthoringBlockingIssues` or its revision-bound `phaseAuthoringReceipt` is not handoff-ready. When `.day-shift/contract-impact.json` exists, require `contractImpactCoverage.requiredComplete: true`: the review replays each declared nested task's target, adapter, validation, posture, and transitive-impact preflight before milestone creation. Under `unknownPolicy: blocking`, it groups uncovered producers by milestone as `PHASE_CONTRACT_IMPACT_COVERAGE_REQUIRED`; route that no-write result to an explicitly authorized contract-impact coverage task rather than scaffolding first. Under `unknownPolicy: advisory`, uncovered producers remain visible in `unknownPaths` and fingerprint evidence but do not make otherwise-complete phase authoring fail. In both modes, known relationships still enforce their complete writable/generated closure, immutable posture, enforcers, and required validations. The accepted receipt must cover the current phase revision, declared milestone order, criterion ownership, nested task identities, normalized scaffold evidence, and exact task contract-impact fingerprints for every declared milestone, so any later contract revision invalidates stale authorization. Keep explicit readiness mode for partial-scaffold recovery; automatic review may select evidence mode when a pending reconciliation already exists.
3. Pass that exact result to `<day-shift-cli> milestone new --phase-overview <path> --full-set --phase-review-result <saved-phase-authoring-review.json>` to create missing declared milestone directories and reconciliation placeholders. Missing, malformed, stale, mismatched, or incomplete evidence is an atomic no-write blocker. Omit the receipt only when the command proves the full declared milestone-pair set is already materialized and therefore performs a no-op.
   Under `full-cycle-strict`, save and record both the authoring-readiness result and the complete structured milestone result at the `milestone-scaffold` gate before continuing.
4. After milestone scaffolding or any phase-overview body update, run `<day-shift-cli> link materialize --dry-run --artifact <phase-overview-path>` as the combined revision-bound link-validation and materialization preview. A clean zero-candidate result with `reusableAsLifecycleLinkGate: true` satisfies the phase link gate without a standalone links-check. Reuse it only while repository, artifact, planning scope, selected revision digest, candidate state, and finding state match exactly. When `candidateCount > 0`, `previewChangedPaths` names only the selected artifact, and the current run mode permits writes, run `<day-shift-cli> link materialize --write --artifact <phase-overview-path> --validation-evidence-id <evidence-id>` and use its current `postWriteValidationEvidence`; if that proof is absent, run only its exact `requiredRecheck`. Stale or differently scoped evidence fails closed. Also run `<day-shift-cli> validation smoke --scope planning --artifact <phase-overview-path>` when declared-child, readiness, or local gap evidence is needed.
5. Pick the first declared milestone that is not already reconciled as completed.
6. Before completing the active milestone contract, read completed reconciliations from earlier declared milestones in the same phase when any exist, and check whether implementation decisions, deviations, discovered work, or validation findings require updating the active milestone's overview.
7. Complete only that active milestone's scaffolded milestone contract when the scaffold produced placeholders or prior reconciliation evidence changed its assumptions; do not complete later milestone contracts yet.
8. Run the active milestone lifecycle from `.day-shift/workflows/milestone.agent-lifecycle-guide.md` with `.day-shift/prompts/user/milestone.next.md`; that delegated milestone lifecycle owns scaffolding only that milestone's declared tasks, completing those task contracts, executing those tasks, completing implementation summaries, and reconciling that milestone.
   Pass the selected run evidence directory through the milestone handoff. Each delegated task must complete its link-materialization dry-run and any safe authorized rewrite before the revision-bound readiness review. Every readiness invocation must include explicit `--reviewed-by` and `--reviewed-at` arguments, and every transient result must remain in the inherited run directory.
   Execute each delegated task's complete current declared validation set through `task validation-set` with its exact task revision. Require per-command manifest evidence followed by the bounded set rollup, stop on the first required unsuccessful or unrecordable result, and use only the command's exact retry and continuation selectors. Retain `task validation-record` for explicitly selected, semantic-assertion, or imported evidence cases.
   Under `full-cycle-strict`, require each delegated task readiness result to run the repository contract-impact preflight before authorization and carry its exact current posture-aware transitive fingerprint into baseline planning. Blocking-policy unknown producers, missing writable/generated obligations, immutable declared targets, and missing frozen enforcers fail closed. Advisory-policy unknown producers remain explicit warning and fingerprint evidence but do not block otherwise-complete work; they never prove coverage or weaken obligations from known relationships. Keep read-only and frozen dependencies out of writable scope, and use the explicit additive contract-revision recovery for newly exposed writable obligations instead of silently expanding scope. Record every delegated task close plus reconciliation build and review result at the required gates before returning control to the phase lifecycle.
   After milestone or task implementation starts, consume the accepted phase authoring receipt as immutable handoff evidence. Do not repair phase `## Scaffold Evidence` during implementation; stop for an explicit phase-contract revision, then rerun phase review and milestone scaffolding with a fresh receipt before resuming.
9. Before leaving the active milestone, re-open its `reconciliation.md` and verify it is populated with concrete completed-task summary links, acceptance-criteria review, validation review, final notes, and a stated milestone verdict. Do not advance to the next milestone while the active milestone reconciliation still contains scaffold placeholder text.
10. After the active milestone has a completed, non-placeholder `reconciliation.md`, return to step 5 for the next declared milestone.
11. Stop at the first blocking milestone unless the user explicitly asked for a readiness sweep or independent-milestone continuation.
12. Run final phase inventory, gap-report, link-materialization dry-run, and smoke checks before phase review. Treat the dry-run's revision-bound validation evidence as the link gate under the exact reuse rules from step 4. Apply a safe candidate write only with that preview's `evidenceId`, then rely on its post-write evidence or exact required recheck; otherwise report the dry-run output as administrative follow-up.
    Under `full-cycle-strict`, record every complete final-validation result at the `phase-final-validation` gate and confirm strict run status has no unexpected structured files before phase review.
13. After every milestone has a completed, non-placeholder `reconciliation.md`, run `<day-shift-cli> phase review --phase-overview <path> --metadata-posture <read-only|sync-on-clean-review> --format json` and save the complete result in the selected run evidence directory.
    Under `full-cycle-strict`, record that exact result at the `phase-review` gate before using resume guidance.
14. Treat phase review as read-only evidence in both postures. Under `read-only`, classify stale phase and milestone statuses backed by clean reconciliation evidence as expected administrative state; the same stale-status smoke findings are administrative evidence, not implementation or reconciliation unreadiness.
15. Under `sync-on-clean-review`, and only when the user separately authorized phase metadata writes, run `<day-shift-cli> metadata sync-status-from-review --phase-overview <path> --review-result <saved-phase-review.json> --metadata-posture sync-on-clean-review --dry-run`. Confirm the preview contains the exact declared phase-and-milestone target set, old and new statuses, and revision preconditions. Apply by repeating the same explicit command without `--dry-run`; the eligible overview updates must commit in one repository transaction. A stale review, changed reconciliation, blocker, ineligible status, partial target set, or posture mismatch stops the lifecycle without fallback serial writes.
16. Report phase status, milestone outcomes, validation evidence, discovered work, and the next handoff only after every milestone reconciliation has been populated and reviewed, or report the first reconciliation blocker.

Metadata-hygiene recommendations from phase review are advisory evidence only. Do not apply `metadata sync-status-from-review` unless the current request explicitly authorizes metadata writes and the saved clean review carries `sync-on-clean-review` posture. For a phase-scoped clean review, do not replace a rejected batch with serial `phase update` or `milestone update` calls. Do not hand-edit phase or milestone status metadata when the revision-bound batch command can apply the deterministic transition.

Do not skip from milestone scaffolding to phase completion. Phase evidence review is eligible only after every declared milestone has completed reconciliation evidence, unless the user explicitly requested a readiness-only or partial review.

Use the shared Safe Link Materialization Gate in `.day-shift/references/validation-and-review.md`; do not redefine or broaden its write boundary at the phase layer.

When phase work audits or adopts commands, use `commands search`, then `commands describe`; use `commands validate` for drift/input-coverage evidence and full inventory only for whole-surface audits. Fall back to command help when descriptor input coverage is missing.

When a phase or milestone validation command consumes compiled `dist/**` output, run the build or compile step before that validation. Do not parallelize `pnpm run build`, `pnpm run check`, or `pnpm exec tsc -p tsconfig.json` with tests or CLI commands that import `dist/**`; stale compiled output can create false failures or false passes.

Do not parallelize write-capable planning commands with evidence commands that are meant to observe the result of those writes. Run scaffold, build, update, or reconciliation writes first, then collect dependent status, inventory, validation, review, or diff evidence. This applies to commands such as `<day-shift-cli> milestone new`, `<day-shift-cli> task new`, `<day-shift-cli> implementation-summary build`, `<day-shift-cli> reconciliation build`, and explicit metadata update commands.

### Authorized Pre-Write Contract Revision Recovery

User authorization to change the phase/task contract and command eligibility to mutate lifecycle state are separate decisions. If an explicitly authorized material scope correction is required after a task baseline but before implementation evidence, stop the delegated lifecycle and preserve the one inherited `.day-shift/runs/run-<run-id>/` directory. Apply only the authorized planning body edits, rerun `phase review --phase-overview <path> --review-mode readiness --metadata-posture read-only`, and require a current handoff-ready authoring receipt with no scaffold projection drift.

Preview `resume run revise-contract --run-directory <run-directory> --review-result <current-phase-review.json> --active-artifact <task-definition> --recorded-by <actor> --recorded-at <timestamp> --reason <reason> --rollback-gate task-readiness --dry-run`. Confirm that only the selected phase and active planning artifact changed, all historical entries and evidence digests remain immutable, the checkpoint names exact old/new digests and invalidated entry identities, and no unrelated run file or canonical drift exists. Apply the same command without `--dry-run`; then require fresh `resume run status` and a callable `resume run resume` result. Do not create a sibling run directory or treat manifest history as current authority.

For the affected task, use `task attempt-supersede` with preview/apply parity only when the current attempt is baseline-only and repository comparison proves no post-baseline target delta or lifecycle evidence. The transition must preserve the predecessor baseline, archive the attempt as `superseded`, reset readiness, and clear stale authorization. Continue with fresh link materialization, task readiness review and authorization, a new attempt identity, and a new baseline containing the expanded declared target set. Validation, deviation, waiver, blocker, disposition, cancellation, review, closeout, or implementation-delta evidence makes supersession ineligible and requires an explicit stop.

### 1. Startup Preflight

Confirm the local session is safe to begin.

- inspect current repository state before editing, using scoped changed-path accounting rather than broad unrelated-dirty-state narration
- preserve unrelated user changes
- verify the phase overview exists and is readable
- verify parent traceability paths are present when they define phase scope
- verify the phase's milestone list uses ordered milestone slug declarations in ascending order; accept raw backticked slug bullets and materialized Markdown-link slug bullets
- verify declared milestone slugs match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`
- verify existing milestone directories match the declared milestone set or identify drift before proceeding
- verify the phase does not require missing planning artifacts before milestone creation or execution can proceed
- use planning inventory, gap-report, next-action, workflow explain, or artifact-scoped validation when directory shape or trace links are suspect

If startup evidence is contradictory or incomplete, stop before editing.

### Resume / Interruption Recovery

When resuming a phase after an interruption, aborted tool call, context compaction, or explicit user "proceed" request, re-establish the lifecycle boundary before continuing.

- run `<day-shift-cli> resume run status --run-directory <run-directory> --format json` first; protocol v2 selects the byte-bounded compact decision projection when `--detail` is omitted
- use its `resumeCapsule` as the context-loss boundary: confirm the active artifact and last accepted gate, treat its counted current successful entries as completed actions that must not be repeated, and follow its one authoritative next action
- recover only the needed history with the capsule's `entries`, `validations`, or `evidence` paging command; use unpaged `--detail full` only for an explicit audit, never as automatic recovery
- run `<day-shift-cli> resume run resume --run-directory <run-directory> --format json` to re-resolve current action legality from the canonical artifact; manifest history remains evidence and does not authorize a write
- run `git status --short` with a scope that includes the selected phase, active milestone artifacts, active task artifacts, and expected implementation paths when known
- identify the last completed lifecycle gate: milestone scaffold, milestone readiness, task execution, milestone reconciliation, phase review, or metadata update
- inspect partially edited files for the active milestone or task before assuming prior edits completed
- when a resumed write-capable update should verify the same active artifact selected by the lifecycle handoff, pass that repository-relative path through `--active-artifact` and stop on mismatch rather than guessing which artifact is current
- rerun the active milestone's review or readiness checks before executing tasks if no implementation edits were completed yet
- rerun the active milestone's reconciliation review before marking a partially completed milestone as done
- preserve the declared milestone order after resuming; do not skip ahead because a later milestone looks easier
- report any ambiguous resume state as blocked instead of claiming phase completion from uncertain evidence

### 2. Scaffold Declared Milestones

Use `.day-shift/workflows/02-plan-from-spec.md` and `.day-shift/prompts/user/phase.next.md` for phase-to-milestone creation.

Under `Profile: full-cycle-strict`, pass this pre-scaffold contract gate before invoking `<day-shift-cli> milestone new`. Review the selected phase's `## Scaffold Evidence` against its declared milestone order and record the result in the existing `.day-shift/runs/run-<run-id>/` directory:

- every declared milestone has exactly one child-scoped block with non-empty `criterion_ids`, concrete `ownership`, a positive `target_task_count`, and an authored `decomposition_rationale`
- milestone criterion subsets contain only phase criterion IDs, preserve their relative phase order, cover the complete phase criterion set, and do not overlap unless every owner explicitly lists the overlap in `shared_criterion_ids`
- the number of ordered nested `task` entries matches `target_task_count`
- every nested task has a canonical ordered slug plus child-specific `criterion_ids`, `current_behavior`, `desired_behavior`, repository-relative `dependency`, executable `target`, `validation`, and `rollback` evidence
- each milestone's nested task criterion union exactly covers that milestone's reviewed subset, with any overlap explicitly reviewed through `shared_criterion_ids`
- command-facing child behavior names its adapter path, implementation targets are not validation launchers, and no unresolved placeholder or generic scaffold evidence remains
- when `.day-shift/contract-impact.json` uses `unknownPolicy: blocking`, every nested task target and adapter has an exact writable or generated producer relationship before milestone creation; under `unknownPolicy: advisory`, uncovered producers remain visible and nonblocking, while every known relationship in either mode still requires complete writable/generated closure, non-immutable posture, required enforcer evidence, and declared validation coverage

If the gate fails, do not invoke milestone creation. When phase-contract repair is authorized, update only the selected phase body, rerun its links-check and safe materialization sequence, and repeat this gate in the same run evidence directory. If `milestone new` still returns refinement-required findings, treat the full-set attempt as atomic no-write evidence, return to the selected phase contract, and resume through the same public command after repair; never hand-create milestone artifacts as a workaround.

Canonical invocation:

```md
Workflow: .day-shift/workflows/02-plan-from-spec.md
Prompt: .day-shift/prompts/user/phase.next.md
Phase overview: <relative-path-to-phase-overview>

Create all milestones listed in the phase overview by iterating the standard milestone-creation contract for each listed milestone, creating that directory if needed, using ordered milestone directory names and keeping traceability back to the source specs and parent planning artifacts.
```

Milestone scaffolding rules:

- create only milestones already declared in the phase overview
- preserve the declared milestone order
- use `<day-shift-cli> milestone new --phase-overview <path> --full-set` as the first choice
- create the phase `milestones/` directory if needed
- create one milestone directory per declared milestone slug
- create both `milestone-overview.md` and `reconciliation.md` in each milestone directory for new canonical artifacts
- support legacy `overview.md` milestone artifacts when they are the selected existing artifacts
- initialize milestone reconciliations as pending placeholders
- preserve upstream traceability to source specs and parent slice and phase artifacts
- do not mark newly scaffolded milestones as completed during phase-to-milestone planning
- do not create task definitions or implementation summaries during phase-to-milestone planning
- preserve refinement-required failures as atomic no-write evidence and do not bypass the public scaffold command with manually created milestone pairs

Manual milestone creation is allowed only for the named exceptions in `02-plan-from-spec.md`: `unsupported by CLI`, `CLI failed`, or `manual recovery after scaffold verification`. Record workflow provenance when manual creation is used.

### 2a. Complete Only The Active Milestone Contract

Generated milestone artifacts may be placeholders. Treat milestone scaffolding and milestone contract completion as separate gates.

After the phase-level milestone scaffold exists, do not complete every milestone overview up front. Complete one milestone contract at a time, immediately before that milestone enters its delegated lifecycle. This preserves phase order and avoids spending context on later milestones before earlier milestone evidence is complete.

For milestone 2 and later, contract completion must first review completed reconciliations from earlier milestones in the same phase. If prior implementation decisions, accepted deviations, discovered work, validation findings, or follow-up notes change the active milestone's assumptions, update only the active milestone overview before task scaffolding. Do not proactively update later milestone overviews.

When the phase overview names an earlier phase as a dependency, read that dependency phase's completed milestone reconciliations before completing the first active milestone contract in the selected phase. Treat accepted residual work, discovered work, implementation decisions, and validation findings from dependency phases as active-milestone contract input. If dependency phase evidence is missing, contradictory, or not completed enough to establish the active phase boundary, stop and report the sequencing blocker.

Before the active milestone is considered ready for the milestone lifecycle, its milestone overview must have:

- no unresolved scaffold placeholder tokens or default incomplete-status sentences
- a concrete purpose and scope
- a valid ordered `## Tasks` section
- concrete acceptance criteria
- concrete repository-relative dependencies
- concrete validation focus
- no planning-blocking open questions

If the active scaffolded milestone overview is a placeholder, refine only that declared milestone overview from the phase overview, upstream artifacts, prior completed milestone reconciliations when present, and existing repository context. Then run focused validation or review after refinement, not before, and treat a placeholder-heavy active milestone as not ready for the milestone lifecycle.

Do not scaffold, complete, review, or execute task artifacts for later milestones while the active milestone is unreconciled.

### 3. Check Active Milestone Readiness

After milestone artifacts exist, confirm the active milestone can enter the milestone lifecycle. A phase-wide readiness sweep is optional and read-only; it does not authorize task scaffolding or task execution for later milestones.

For the active milestone:

- read the milestone overview
- read completed reconciliations from earlier declared milestones in the same phase when any exist
- verify prior reconciliation decisions do not require active milestone contract updates, or make those active milestone updates before task scaffolding
- verify the milestone's `## Tasks` section is concrete, ordered, and implementation-oriented
- verify dependencies point to concrete repository-relative artifacts
- verify validation focus is clear
- verify open questions are not planning-blocking
- verify the milestone does not depend on a later-numbered sibling or missing producer artifact
- verify the milestone no longer contains scaffold placeholders before trusting readiness status
- use `<day-shift-cli> validation links-check --scope planning --artifact <milestone-overview-path>` or `<day-shift-cli> validation smoke --scope planning --artifact <milestone-overview-path>` when local evidence is needed

If `links-check` reports hierarchy mismatches because a new canonical artifact uses `slice-overview.md`, `phase-overview.md`, or `milestone-overview.md` while the checker still expects a supported legacy `overview.md` path, do not rewrite canonical trace links by hand. Confirm the explicit links resolve locally, run focused `validation smoke --scope planning --artifact <phase-or-milestone-overview>`, record the links-check result as a validation-tool compatibility warning, and continue only when smoke/review evidence has no blocking findings.

In `readiness-only` mode, stop after the active-milestone readiness check and report:

- active milestone readiness status
- missing evidence
- first recommended next step
- whether phase review is premature

If the user explicitly requested a phase-wide readiness sweep, keep it read-only and instead report:

- ready milestones
- blocked milestones
- missing evidence
- first recommended next milestone
- whether phase review is premature

Do not update milestone reconciliations, task summaries, or phase metadata during readiness-only runs.

### 4. Execute The Active Milestone

For the active ready milestone, invoke the milestone lifecycle directly. Return here for the next milestone only after the current milestone has completed reconciliation evidence.

Canonical invocation:

```md
Prompt: .day-shift/prompts/user/milestone.next.md
Workflow: .day-shift/workflows/milestone.agent-lifecycle-guide.md
Milestone overview: <relative-path-to-milestone-overview>

Execute this milestone as a full cycle: scaffold declared tasks, complete task contracts, execute each task in order, capture implementation evidence, reconcile the milestone, and hand off clearly.
```

The milestone guide owns task scaffolding, execution, validation, task closeout metadata, touched-path accounting, and reconciliation. The phase layer adds only these orchestration constraints:

- execute declared milestones in order and complete one reconciliation before advancing
- preserve phase and milestone scope and unrelated user changes
- feed prior reconciliations into the next active milestone contract
- record discovered work rather than silently expanding scope
- return to the phase layer only after reconciliation review and re-open verification
- before phase review, investigate unexplained deletions, file-type changes, or test-coverage shrinkage across the combined milestone changes

Stop at the first milestone blocker unless one of these is true:

- the user requested `readiness-only`
- the user explicitly requested a full readiness sweep
- the blocked milestone is documented as independent and the user explicitly authorized continuing to later milestones

Do not silently reorder phase milestones to keep momentum.

### 5. Gate Phase Review

Before starting phase evidence review, confirm every declared milestone under the phase has:

- a present milestone overview
- a present `reconciliation.md`
- `reconciliation_status: completed`
- `status: completed` in the reconciliation front matter
- completed task implementation summaries for every declared task under that milestone
- non-placeholder reconciliation evidence
- validation evidence or an explicit validation exception
- acceptance-criteria review or an explicit deferral

If any milestone reconciliation is missing, pending, draft, blocked, or placeholder-heavy, stop phase review and report the next milestone or reconciliation closeout step.

Treat scaffold placeholder text inside milestone reconciliation as a phase blocker after that milestone's tasks are completed. Do not accept a phase run as complete when any milestone `reconciliation.md` still says `Pending.`, `Pending milestone review.`, `Pending review after task implementation summaries are available.`, or `Pending. Add completed task implementation summaries as milestone execution work finishes.`.

If milestone reconciliations are complete but final diff sanity evidence is missing for high-risk changes, stop before phase acceptance and close the evidence gap first.

The phase overview and completed milestone overviews may still carry stale `status` metadata at this point. Under `read-only` posture, treat deterministic drift as expected administrative state rather than a blocker or implementation-readiness defect. Under `sync-on-clean-review`, preserve it as a preview candidate until a fresh complete phase review and separate explicit write authorization permit the atomic batch.

### 6. Review The Phase

Use `.day-shift/prompts/user/phase.review.md` and the planning review command family for phase closeout evidence.

Canonical invocation:

```md
Workflow: .day-shift/workflows/04-summarize-and-reconcile.md
Prompt: .day-shift/prompts/user/phase.review.md
Phase overview: <relative-path-to-phase-overview>
Metadata posture: read-only | sync-on-clean-review

Review the phase against completed milestone overviews and milestone reconciliation evidence. Report blockers, warnings, metadata-hygiene follow-ups, administrative follow-ups, user decisions needed, and the suggested next step.
```

Phase review rules:

- use the phase overview plus completed milestone overviews and reconciliations as the review inputs
- keep milestone reconciliations as the source of truth for milestone-level acceptance, validation, discovered work, and follow-up evidence
- run `<day-shift-cli> phase review --phase-overview <path> --metadata-posture <read-only|sync-on-clean-review>` when command-supported
- keep phase review read-only by default
- separate blocking issues, missing evidence, warnings, satisfaction status, metadata-hygiene follow-ups, administrative follow-ups, user decisions needed, and suggested next steps
- classify clean-review status drift under `read-only` as expected administrative state, including equivalent stale-status smoke findings
- treat metadata-hygiene recommendations and a `sync-on-clean-review` receipt as evidence to consider, not as authorization to write
- treat advisory review warnings as evidence only; they do not authorize writes or lifecycle changes by implication
- do not create follow-up phases, milestones, or tasks unless a separate explicit planning prompt or user request invokes that layer
- do not update phase or milestone metadata unless the current request explicitly authorizes metadata updates

When the user explicitly authorizes phase-completion metadata writes and the saved phase review used `sync-on-clean-review` posture:

- preview `<day-shift-cli> metadata sync-status-from-review --phase-overview <path> --review-result <saved-phase-review.json> --metadata-posture sync-on-clean-review --dry-run`
- verify every declared phase and milestone target, old and new status, and revision precondition, then apply the same command without `--dry-run`
- require the phase and every changed selected milestone to commit in one repository transaction or write nothing
- keep selected-artifact `phase update`, `milestone update`, and milestone-only metadata sync as legacy or non-phase-scoped recovery surfaces; do not use them to bypass a rejected phase batch
- include `--active-artifact <same-repository-relative-path>` when the handoff names an active artifact and the command supports active-artifact validation
- do not rewrite traceability, provenance, or reconciliation bodies during metadata-hygiene updates unless a separate explicit command requires it
- if a direct metadata edit appears necessary where a CLI sync or update command exists, stop before editing and report the command considered, why it cannot be used, the manual exception, and the artifact fields that would change

## Stop Conditions

Stop and report instead of improvising when any of these are true:

- the phase overview is missing, unreadable, or not the active source of truth
- the phase milestone list is missing, prose-only, unordered, duplicated, or contains invalid slugs
- the phase fails the pre-scaffold contract gate for criterion ownership, task count, child-specific behavior, dependencies, targets, validation, rollback, or unresolved scaffold evidence
- milestone creation returns refinement-required findings that have not been repaired and re-reviewed in the current run evidence directory
- milestone scaffolding would require inventing undeclared milestones
- required upstream specs, parent overviews, or producer artifacts are absent
- existing milestone directories conflict materially with the declared milestone set
- a milestone depends on a later-numbered sibling without an explicit approved exception
- a milestone is not ready for the milestone lifecycle
- delegated milestone implementation would require broad opportunistic cleanup outside declared task or milestone scope
- delegated validation cannot meaningfully confirm the milestone's acceptance criteria
- final diff sanity reveals unexplained high-deletion changes, file-type changes, or test coverage shrinkage
- not all milestone reconciliations are completed and non-placeholder when phase evidence review is requested
- phase review evidence conflicts with completed milestone reconciliations
- phase review has blocking findings after completed milestone reconciliation evidence
- metadata update evidence is deterministic but the user has not authorized write-capable metadata updates

When stopping, report the exact phase or milestone, the blocking condition, and the next explicit artifact or decision needed to resume.

## Artifact Contract

This workflow may update only these artifact classes by default:

- declared milestone directories under the selected phase
- milestone overview files under the selected phase
- milestone `reconciliation.md` files under the selected phase
- declared task directories and paired task artifacts under the active delegated milestone only
- repository code or docs within active delegated task implementation target paths

Phase metadata may be updated only when the user explicitly authorizes phase-completion or metadata-hygiene writes after evidence review. Derived state files under `.day-shift/state/` may be written only by explicit state, checkpoint, or sync commands named by delegated task or reconciliation workflows or explicitly requested by the user. Do not hand-edit derived state as part of ordinary phase execution.

This workflow must not automatically:

- invent undeclared milestones
- reorder phase milestones silently
- skip blocked milestones to implement later siblings
- scaffold task artifacts for later milestones while the active milestone is unreconciled
- complete later milestone contracts before prior milestone reconciliations have been reviewed for active-milestone impact
- mark blocked milestones as completed
- update phase metadata before milestone evidence is complete
- create follow-up planning artifacts from phase review findings
- absorb unrelated cleanup outside delegated task scope
- treat advisory review or validation output as authorization to write
- create alternate milestone, task-summary, reconciliation, or phase-review destinations

When CLI, workflow, and prompt surfaces disagree, prefer them in this order:

1. the selected phase overview and its upstream contract artifacts
2. the selected milestone overview during that milestone's execution
3. the selected task definition during delegated task execution
4. the command-specific CLI contract for the exact operation being used
5. the workflow file governing the current stage
6. the matching layer/action prompt
7. prior summaries or conversational assumptions

## Output Contract

For successful full-cycle phase completion, keep the final response concise and include:

- completed status or blocked status for the phase
- milestone outcomes in phase order
- changed paths, grouped by milestone when useful
- validations run and results
- validation commands skipped, substituted, blocked, or inconclusive
- phase review status
- metadata updates performed or recommended
- discovered work
- follow-up work
- next handoff

Detailed acceptance-criteria mapping should live in task implementation summaries and milestone reconciliations. Summarize only material deviations, unmet criteria, unresolved review concerns, or phase-level blockers in the final response.

Do not include unrelated dirty worktree state as its own final-report note unless it materially affected phase scope, validation, reconciliation, or review risk.

If the run stopped early, say so explicitly and identify the first blocker.

Name the CLI commands, workflow files, and prompts actually used whenever they materially shaped the lifecycle outcome.

## Promptable Invocation

Use this compact invocation; the workflow owns the `full-cycle-strict` profile defined by its algorithm and artifact contract:

```md
Workflow: `.day-shift/workflows/phase.agent-lifecycle-guide.md`
Phase: <path-to-phase-overview-or-directory>
Mode: implement
Profile: full-cycle-strict
Metadata posture: read-only | sync-on-clean-review
Phase metadata write authorization: authorized | not-authorized
```

For milestone creation without implementation, set `Mode: scaffold-only`.

For read-only milestone readiness review, set `Mode: readiness-only` and keep the workflow read-only after milestone artifacts already exist.

For phase closeout after milestones are already reconciled, set `Mode: review`.
