From Intake to Implementation

Day Shift turns intent into implementation through explicit artifacts and separately authorized lifecycle writes. Evidence commands report current state; they do not silently create planning, authorize work, repair evidence, accept findings, or close anything.

Choose the workflow level

• Basic is the smallest path for one independent task pair.
• Structured is the normal path for specification-backed feature work with one overview and ordered direct tasks.
• Governed is the staged path for work that needs slice, phase, milestone, task, and reconciliation boundaries.

Workflow level controls organization, not evidence profile, agent mode, action authority, or safety. A production interruption is emergent intake, not permission to bypass planning. Capture durable intent through spec create, inspect it with the read-only spec review, and record the separate revision-bound planning decision with spec disposition before creating specification-backed work.

Canonical new planning roots are .day-shift/planning/basic/, .day-shift/planning/structured/, and .day-shift/planning/governed/. Preview work create --level basic|structured|governed --dry-run, inspect the resolved destination and preconditions, then apply the separately authorized write. planning next-action, inventory, gap reports, link checks, and review commands remain evidence surfaces; they never select or mutate work on their own.

Scaffold only declared work

Structured work uses work task create --overview <overview.md> to create the overview’s declared direct task pairs in dependency order. Governed work proceeds one declared layer at a time with slice new, phase new, milestone new, and task new --full-set. Full-set expansion remains layer-local: it creates only a selected declared immediate set and never invents descendants or implements them.

After scaffolding or changing an artifact body, run link materialize --dry-run. Apply materialization only when every proposed path is resolvable and the preview stays inside the selected artifact. Complete each task contract with concrete targets, desired behavior, dependencies, acceptance criteria, validation commands, and rollback guidance before asking for readiness evidence.

Authorize and open one task

Run task readiness-review --task-definition <path> against the selected declared task. It is read-only. Errors block implementation; warnings require deliberate review and do not grant authority. Record a clean, current review through the separate task readiness-authorize write, open one stable identity with task attempt-open, and, for Runtime or Hybrid evidence, capture task baseline before the first implementation write.

The baseline binds the attempt to the readiness checkpoint and classifies every declared target. Pre-existing target work requires explicit path-specific adoption. Unrelated dirty paths remain visible but cannot be attributed to the task. Stop on an incomplete predecessor, stale revision, scope disagreement, unresolved target ownership, or a material change to the task contract.

Implement, validate, and close explicitly

Change only the task’s declared target paths unless an authorized contract revision expands them. Use task validation-set for the complete declared set and task validation-record for one explicitly selected or imported result. Declared-set execution rejects arbitrary extra argv. Preserve current-cycle changed paths plus exact acceptance evidence in the paired summary. implementation-summary build refreshes command-owned evidence; complete its judgment-bearing body before task implementation-complete freezes the current implementation attempt.

implementation-summary review is read-only and does not repair or complete the summary. A current blocker-free result may authorize the separate task disposition write. Review the accepted pair again, then use task close for the terminal receipt-bound task write. Discovered work stays separate from the active task unless its contract is explicitly revised and recertified.

For Governed work, complete every declared task in a milestone before reconciliation build. The build writes a draft rollup, not a verdict. Complete the milestone evidence, run the read-only reconciliation review, repair and re-review any blocker, and use reconciliation accept only with current blocker-free evidence. Structured work instead proceeds to read-only work review and separately authorized project-review and work-close writes.

Structured walkthrough

Structured is the normal path for planned feature work. Use it when one reviewed specification should guide one or more direct implementation tasks without adding a formal hierarchy.

This walkthrough uses the repository’s qualified structured-evaluation fixture. The example is synthetic release evidence, not a customer adoption story. It proves current command arguments, numbered paths, dependency ordering, review posture, project-review persistence, and separate closeout against the shipped CLI.

What you will create

The completed example has one canonical specification, one Structured overview, and two direct task pairs:

.day-shift/specs/31-structured-evaluation-source/structured-evaluation-source.md
.day-shift/planning/structured/31-structured-evaluation/overview.md
.day-shift/planning/structured/31-structured-evaluation/tasks/01-implement-api/
├── task-definition.md
└── implementation-summary.md
.day-shift/planning/structured/31-structured-evaluation/tasks/02-implement-client/
├── task-definition.md
└── implementation-summary.md

The 31 work prefix comes from implementation_order. The 01 and 02 task prefixes come from each task’s parent-local sequence. Those directory prefixes provide order; the stable semantic identities remain structured-evaluation, implement-api, and implement-client.

Before continuing, initialize and check the workspace. Keep transient command output in one run directory such as .day-shift/runs/run-structured-feature/.

1. Create the canonical specification

Create or import the authoritative requirement document under .day-shift/specs/. The qualified example creates it explicitly:

CLI=day-shift

$CLI spec create \
  --implementation-order 31 \
  --spec-id structured-evaluation-source \
  --title "Structured Evaluation Source" \
  --purpose "Exercise the complete specification-backed Structured lifecycle." \
  --problem-statement "Public examples need one reproducible Structured release gate." \
  --desired-outcome "Complete two ordered dependent direct tasks" \
  --non-goal "Create Governed hierarchy" \
  --scope "The canonical specification and two direct Structured tasks" \
  --constraint "Use only current public lifecycle commands" \
  --constraint "Keep executable evidence aligned with the documented lifecycle" \
  --success-criterion "The Structured project closes from current accepted evidence" \
  --source request://phase-04-structured-evaluation

The resulting body has exactly these H2 sections in order: Purpose, Problem Statement, Desired Outcome, Non-Goals, Scope, Constraints, Success Criteria, and Open Questions. Repeat --open-question when the draft has unresolved questions; otherwise creation emits the parser-safe - None currently. state. Structured JSON or YAML accepts the matching canonical camel-case or snake-case fields. The former --summary, --problem, --goal, and --risk inputs remain deprecated Day Shift 0.2.0 compatibility aliases; they preserve content under canonical headings and do not create legacy sections.

Specification creation writes the specification and its registration. It does not create or relocate planning work. It also does not review readiness or record a readiness disposition. The specification remains under .day-shift/specs/ for the whole lifecycle; later planning records its repository-relative path and revision instead of copying its requirements.

2. Review the specification and record planning readiness

Review is read-only. Save the complete result, inspect it, and then make planning readiness a separate explicit write:

$CLI spec review \
  --spec .day-shift/specs/31-structured-evaluation-source/structured-evaluation-source.md \
  --reviewed-by feature-owner \
  --reviewed-at 2026-08-01T01:00:00Z \
  --format json \
  > .day-shift/runs/run-structured-feature/spec-review.json

$CLI spec disposition \
  --spec .day-shift/specs/31-structured-evaluation-source/structured-evaluation-source.md \
  --planning-readiness ready \
  --review-result .day-shift/runs/run-structured-feature/spec-review.json \
  --recorded-by feature-owner \
  --recorded-at 2026-08-01T01:01:00Z

The first command reports evidence and changes nothing. The second records the selected readiness disposition against the reviewed revision. If the specification changes later, stop and recertify it before creating fresh revision-bound planning; see scope and specification drift recovery.

3. Let the default select Structured

Supply the valid specification without --level:

$CLI work create \
  --spec .day-shift/specs/31-structured-evaluation-source/structured-evaluation-source.md \
  --work-id structured-evaluation \
  --implementation-order 31 \
  --agent-mode guided \
  --evidence-profile runtime

With no explicit level or overriding parent/configuration context, this resolves to structured. The result is .day-shift/planning/structured/31-structured-evaluation/overview.md, with stable work_id: structured-evaluation, default agent mode guided, and default evidence profile runtime.

Open the overview and confirm that it references the canonical specification path and recorded revision. The overview is shared planning context; it never becomes a second specification.

4. Create numbered direct tasks

Create the complete direct-task contracts in declared dependency order:

$CLI work task create \
  --overview .day-shift/planning/structured/31-structured-evaluation/overview.md \
  --task '{"taskId":"implement-api","objective":"Implement the specification-backed API result through the public Structured lifecycle.","targetPaths":["src/structured-api.mjs"],"currentBehavior":"The repository has no Structured API result.","desiredBehavior":"The repository exposes a syntax-valid Structured API result.","acceptanceCriteria":["The API task uses the first sequence-derived numbered direct-task root.","The API runtime result has command-owned validation evidence."],"validationCommands":["node --check src/structured-api.mjs"],"rollbackRecovery":"Remove the API result and its numbered Structured task pair.","dependencies":[],"constraints":["Preserve the Structured overview and source-specification revision binding."]}' \
  --task '{"taskId":"implement-client","objective":"Implement the dependent client result through the public Structured lifecycle.","targetPaths":["src/structured-client.mjs"],"currentBehavior":"The repository has no Structured client result.","desiredBehavior":"The repository exposes a syntax-valid client result after the API task closes.","acceptanceCriteria":["The client task uses the second sequence-derived numbered direct-task root and retains the API dependency.","The client runtime result has command-owned validation evidence after its predecessor closes."],"validationCommands":["node --check src/structured-client.mjs"],"rollbackRecovery":"Remove the client result and its numbered Structured task pair after removing dependent evidence.","dependencies":["implement-api"],"constraints":["Do not bypass predecessor acceptance or add Governed hierarchy."]}'

The CLI derives 01-implement-api and 02-implement-client from sequence. The dependency remains the stable task identity implement-api, not the numbered directory name. Each task inherits guided and runtime unless its contract intentionally overrides those defaults.

Each task-definition.md is the work agreement. Each paired implementation-summary.md is the canonical implementation evidence. A later follow-up task receives a later sequence without renaming earlier identities; if coordination outgrows direct tasks, use an explicit promotion path instead of inserting hierarchy by hand.

5. Implement and close each task separately

Start with 01-implement-api. Readiness review is no-write; authorization, attempt opening, baseline capture, implementation completion, disposition, and close are distinct writes.

TASK=.day-shift/planning/structured/31-structured-evaluation/tasks/01-implement-api/task-definition.md
ATTEMPT=structured-evaluation-implement-api-attempt-001

$CLI task readiness-review \
  --task-definition "$TASK" \
  --reviewed-by feature-agent \
  --reviewed-at 2026-08-01T01:02:00Z \
  --format json \
  > .day-shift/runs/run-structured-feature/implement-api-readiness.json

$CLI task readiness-authorize \
  --task-definition "$TASK" \
  --review-result .day-shift/runs/run-structured-feature/implement-api-readiness.json

$CLI task attempt-open \
  --task-definition "$TASK" \
  --attempt-id "$ATTEMPT" \
  --opened-at 2026-08-01T01:03:00Z

$CLI task baseline \
  --task-definition "$TASK" \
  --task-cycle-id "$ATTEMPT" \
  --checkpoint-id <readiness-review-id> \
  --captured-by feature-agent \
  --captured-at 2026-08-01T01:04:00Z

Your coding assistant—or you—now changes only the task’s declared target paths. Day Shift coordinates and records the work; it is not the implementation actor unless a selected CLI command explicitly runs a child process.

After implementation, preview and execute the current task revision’s complete declared validation set, then build and complete the canonical summary:

$CLI task validation-set \
  --task-definition "$TASK" \
  --attempt-id "$ATTEMPT" \
  --task-revision <current-task-revision> \
  --dry-run

$CLI task validation-set \
  --task-definition "$TASK" \
  --attempt-id "$ATTEMPT" \
  --task-revision <current-task-revision>

# When only one explicitly selected command is needed, keep its evidence independent.
$CLI task validation-record \
  --task-definition "$TASK" \
  --validation-id <validation-id> \
  --attempt-id "$ATTEMPT" \
  --name <validation-name> \
  --required true \
  --summary <validation-summary> \
  --dependency-mode declared \
  --scope-path <declared-target> \
  -- <exact-command-argv>

$CLI implementation-summary build --task-definition "$TASK"
# Complete the summary body with changed paths, acceptance results, and deviations.

$CLI task implementation-complete \
  --task-definition "$TASK" \
  --attempt-id "$ATTEMPT" \
  --task-revision <current-task-revision> \
  --completed-by feature-agent \
  --completed-at 2026-08-01T01:06:00Z

$CLI implementation-summary review \
  --task-definition "$TASK" \
  --format json \
  > .day-shift/runs/run-structured-feature/implement-api-review.json

$CLI task disposition \
  --task-definition "$TASK" \
  --disposition accepted \
  --review-result .day-shift/runs/run-structured-feature/implement-api-review.json \
  --recorded-by feature-reviewer \
  --recorded-at 2026-08-01T01:07:00Z

$CLI implementation-summary review \
  --task-definition "$TASK" \
  --format json \
  > .day-shift/runs/run-structured-feature/implement-api-accepted-review.json

$CLI task close \
  --task-definition "$TASK" \
  --review-result .day-shift/runs/run-structured-feature/implement-api-accepted-review.json

The validation-set command owns the declared child-process sequence and each revision-bound append. It stops before later commands when a required result fails, times out, cannot spawn, becomes stale, or cannot be recorded. Retry only through its exact returned failed-identity selector. Use validation-record when one selected command needs semantic JSON assertions or when evidence is recorded or imported separately; see evidence review and reconciliation.

Only after the API task is accepted and closed should you repeat this cycle for 02-implement-client. Its task definition keeps the implement-api dependency, so readiness fails closed if the predecessor is incomplete.

6. Review the feature without changing it

When every direct task is complete, review project coverage:

$CLI work review \
  --overview .day-shift/planning/structured/31-structured-evaluation/overview.md \
  --format json \
  > .day-shift/runs/run-structured-feature/work-review.json

work review is visibly read-only. It evaluates the overview and task evidence but does not write project-review.md, accept findings, or close the feature.

7. Persist project review, then close

Persist the reviewing actor’s accepted decision through the explicit canonical evidence write:

$CLI work project-review create \
  --overview .day-shift/planning/structured/31-structured-evaluation/overview.md \
  --disposition accepted \
  --reviewer feature-reviewer \
  --summary "The specification-bound ordered Structured lifecycle is accepted."

This creates .day-shift/planning/structured/31-structured-evaluation/project-review.md. It still does not close the work. Close only from current accepted project-review evidence:

$CLI work close \
  --overview .day-shift/planning/structured/31-structured-evaluation/overview.md \
  --project-review .day-shift/planning/structured/31-structured-evaluation/project-review.md

The separate close preserves child task artifacts and their implementation evidence. If review requests changes, return to the affected direct task instead of persisting accepted evidence or forcing closeout.

Continue from the repository record

The feature now has a canonical specification, revision-bound overview, ordered task agreements, implementation summaries, explicit project review, and terminal closeout. Another contributor can derive the next action from those records without reconstructing the work from chat.

Use the command reference for exact option lookup, Operating model and artifacts for deeper identity and evidence mechanics, and resume and drift recovery when the specification or repository changes before the next handoff.