From intake to implementation

Day Shift turns intent into implementation through explicit artifacts and gates. This workflow begins after configuration and health checks and applies the ownership model in Operating model and artifacts. Each command below either gathers evidence or performs one named write; no read-only result advances the lifecycle by itself.

Choose the planning lane

Use the standard lane when work needs phased decomposition:

specification → slice overview → phase overview → milestone overview → task definition → implementation summary

Use lightweight planning only when the selected slice explicitly declares it. It skips phase and milestone artifacts, but still requires a task definition, implementation evidence, a completed implementation summary, and reconciliation. A production interruption or operator report is emergent intake, not permission to bypass planning: capture it as a registered specification, normally under 00-emergent, then choose standard or lightweight planning.

Do not infer a lane from urgency or repository size. The selected source and planning metadata carry that decision.

1. Register and recertify the specification

A human supplies intent and acceptance boundaries. Register its repository-relative source with spec add, then use spec list, spec show, or spec recertify to inspect registration, source availability, and currency. These inspection and recertification surfaces are read-only: they neither rewrite the source nor create a slice.

If the source is missing, contradictory, stale in a way that affects scope, or unregistered, stop. Correct or explicitly revise the specification before decomposition. A healthy registered source becomes the input to the first explicit planning write.

2. Create the selected slice

Run slice new --spec-id <id> only after selecting the registered specification and planning depth. The write creates a slice overview; it does not create phases, milestones, or tasks implicitly.

Review the saved overview and use artifact-scoped validation smoke, validation links-check, planning inventory, or planning gap-report for evidence. These commands report findings and next-action guidance without repairing links, changing metadata, or creating children. Apply a correction only through a separately selected update command.

3. Decompose the standard lane

For standard planning, move down one declared layer at a time:

1. The slice overview declares ordered phases; phase new scaffolds only a selected declared phase.
2. The phase overview declares ordered milestones; milestone new scaffolds only a selected declared milestone.
3. The milestone overview declares ordered tasks; task new --full-set may scaffold the complete declared immediate task set, in order.

Full-set expansion is layer-local. It must not invent undeclared children or recursively implement them. After scaffolding, replace placeholders with concrete objectives, target paths, dependencies, acceptance criteria, runtime delta, rollback, and validation commands. Materialize newly resolvable body links only after a matching link materialize --dry-run shows changes confined to the selected artifact.

For lightweight planning, the slice declares direct tasks. Create only those declared tasks and retain the same readiness and evidence gates below.

4. Prove task readiness

Run task readiness-review --task-definition <path> after the task contract is concrete. The review is read-only. Ready means the selected task has unambiguous scope, creatable repository-relative targets, dependencies, acceptance criteria, execution mode, validation, and recovery guidance with no scaffold placeholders.

Errors block implementation. Warnings require review or explicit acceptance; they are not automatic permission to proceed. Repair the task definition through an explicit edit or supported update, then rerun readiness review. Record the final readiness transition on the task artifact with the supported write-capable lifecycle operation; do not claim that review performed it.

5. Select work without guessing

Use planning next-action, inventory, and gap reports to orient, then verify the proposed task against its parent overview and declared order. Navigation output is assistive and read-only. The human or coordinating agent explicitly selects the task and authorizes its scoped implementation.

Stop when an earlier required task is incomplete, a parent artifact disagrees with the task, a dependency is missing, the effective workspace is incompatible, or target changes would escape task scope. Discovered work belongs in evidence or a later planning update; it does not silently expand the active task.

6. Implement the selected task

Read the task definition and named upstream contracts, inspect scoped repository state, then change only declared target paths unless a justified deviation is recorded. Validate in proportion to risk, preserving command output or structured exceptions as evidence. Runtime and hybrid tasks require executable runtime evidence; contract-only evidence cannot satisfy an acceptance criterion that requires runtime behavior.

Implementation is the write-capable stage. Reviews, validation, diff checks, impact analysis, and link checks remain read-only even when they identify a repair. Perform any repair as a separate authorized implementation write and rerun the evidence command.

7. Close the task and hand off evidence

Run implementation-summary build --task-definition <path> only after implementation and validation. Complete the paired summary with changed paths, acceptance results, validations, deviations, discovered and follow-up work, and review concerns. Then run implementation-summary review; it checks evidence but does not repair or complete the summary.

Mark the task and summary completed only when their evidence is concrete and non-placeholder. The next consumer is milestone reconciliation in the standard lane, or the slice-level reconciliation path declared by lightweight planning. Reconciliation is not eligible until every relevant task summary is completed. This workflow stops at that handoff; evidence review, reconciliation, archival, and release are the next lifecycle journey.

A compact operator journey

An engineer with a healthy initialized workspace registers a feature specification, inspects it, creates one standard slice, and scaffolds only the phase, milestone, and tasks declared by each selected parent. An agent completes the first task contract, passes read-only readiness review, and reports it as the next declared action. After the engineer authorizes implementation, the agent changes scoped files, runs validation, builds and completes the implementation summary, and submits it for review. At every gate, a blocking finding stops advancement; no navigation or review command is treated as a hidden write.

A lightweight maintenance journey

For a narrow documentation correction, the human selects lightweight depth on the slice. The slice declares a direct task, so no phase or milestone is created. The same readiness review, explicit selection, scoped implementation, executable validation where required, completed summary, and reconciliation evidence gates still apply.