Your first project with Day Shift

Your First Project With Day Shift

Use this walkthrough for a first-time Day Shift run in a fresh repository.

This guide keeps the flow CLI-first and avoids common first-run failures such as missing workspace schema evidence. It assumes you are starting from a repository that does not already contain a Day Shift workspace, registered spec, or planning slice.

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.

Outcome

At the end of this walkthrough, you will have:

• an initialized Day Shift workspace
• one sample specification Markdown file
• one registered spec entry in .day-shift/specs/index.json
• a generated planning slice from that spec
• a phase, milestone, task, implementation summary, and milestone reconciliation for the demo game

This walkthrough continues through the normal flow instead of sending you to another guide, so the same file can teach the full Day Shift loop.

Agent Doctor Anytime

At any point in this walkthrough, you can ask an agent to run Day Shift doctor and resolve any reported errors. This is especially useful before you start, after initialization, or whenever a command result suggests the workspace may not be healthy.

Copy this prompt:

Use `.day-shift/workflows/00-your-first-project-with-day-shift.md`.

Run `<day-shift-cli> doctor` for this repository. Report the doctor findings first. If doctor reports errors, resolve only those errors with the narrowest safe changes, preserve unrelated user content, rerun doctor, and stop when doctor passes or when a blocker needs my decision. Do not create planning artifacts until doctor is clean.

Command the prompt tells the agent to use:

<day-shift-cli> doctor

Why: doctor is the read-only baseline workspace-health check. It can be run before or during the walkthrough so missing schema evidence, malformed workspace state, or compatibility problems are found before more artifacts are created.

1. Resolve The CLI Command

Use the installed command when available:

command -v day-shift
day-shift --help

If day-shift is not found, install the Day Shift CLI first, then rerun the checks above.

In this guide, <day-shift-cli> always means day-shift.

Expected output: command -v day-shift prints the installed command path, and day-shift --help prints the top-level command list.

2. Initialize The Workspace

Run init before any planning/spec lifecycle command:

<day-shift-cli> init
<day-shift-cli> ignore install --yes
<day-shift-cli> doctor

ignore install --yes applies Day Shift’s recommended local-only ignore entries without prompting. It helps prevent local Day Shift artifacts from being accidentally committed while preserving existing ignore content and avoiding duplicate entries.

Why this matters: commands that rely on spec/planning metadata can fail when the workspace has not been initialized.

Expected output: .day-shift/ exists with workspace configuration, local guidance files, specs, templates, prompts, and workflow assets needed by later commands. The ignore installer has added Day Shift’s recommended local-only entries without removing existing ignore content, and doctor reports whether the workspace is compatible before planning starts.

3. Create A Sample Root Spec

Create root-spec.md at repository root with this content:

Title: Tic-Tac-Toe Demo Specification

## Goal

Build a simple browser-based Tic-Tac-Toe game in a fresh Next.js scaffold. The demo should be small enough to build live while showing state management, rendering, user interaction, and basic game logic.

## App Scope

The app contains one playable Tic-Tac-Toe board.

Users can:

- click a square to place X or O
- alternate turns automatically
- see whose turn it is
- see when X wins, O wins, or the game ends in a draw
- reset the board

## Acceptance Criteria

- app runs with `npm run dev`
- X starts first
- occupied squares cannot be overwritten
- wins are detected correctly
- draws are detected correctly
- board locks after win or draw
- reset starts a new game

Expected output: root-spec.md exists at repository root and contains the source intent that the Day Shift spec will reference.

4. Create A Day Shift Specification File

Use a command for this.

Workflow-guide prompt form:

Prompt: .day-shift/prompts/user/specification.build.md
Spec source: [Relative Path To Spec File]

Build or revise the specification.

Tutorial prompt to give the agent:

Use `.day-shift/prompts/user/specification.build.md`.

Spec source: .day-shift/specs/01-tic-tac-toe-demo/overview.md

Build the Day Shift specification for the Tic-Tac-Toe demo from `root-spec.md`. Preserve source traceability to `root-spec.md`, use `spec_id: tic-tac-toe-demo`, and keep the specification scoped to a small browser game with turn handling, win/draw detection, board lock, and reset.

Scaffold the specification file with the template command:

day-shift template materialize \
  --template .day-shift/templates/specification.md \
  --mode rendered \
  --destination .day-shift/specs/01-tic-tac-toe-demo/overview.md \
  --placeholder spec_id=tic-tac-toe-demo \
  --placeholder title='Tic-Tac-Toe Demo' \
  --placeholder depth=standard \
  --placeholder source_ref=root-spec.md \
  --placeholder purpose='Build a small browser demo to show Day Shift planning and execution flow against a concrete, low-risk project.' \
  --placeholder problem_statement='Teams need a simple first project to learn Day Shift workflow end-to-end.' \
  --placeholder desired_outcome='A playable Tic-Tac-Toe demo is specified and ready for planning decomposition.' \
  --placeholder non_goals='Production hardening, auth, and backend services are out of scope.' \
  --placeholder scope='Next.js Tic-Tac-Toe UI, game state, winner/draw detection, and reset flow.' \
  --placeholder constraints='Keep implementation small, browser-based, and easy to demo live.' \
  --placeholder success_criteria='The game is playable, validates turn/win/draw rules, and can be reset.' \
  --placeholder open_questions='None currently.'

If you prefer manual authoring, create .day-shift/specs/01-tic-tac-toe-demo/overview.md with:

---
artifact_schema_version: 1
artifact_type: specification
spec_id: tic-tac-toe-demo
title: Tic-Tac-Toe Demo
depth: standard
status: active
implementation_order: "01"
destination: tic-tac-toe-demo
source:
  type: markdown
  ref: root-spec.md
---

Title: Tic-Tac-Toe Demo

## Purpose

Build a small browser demo to show Day Shift planning and execution flow against a concrete, low-risk project.

## Requirements

- Use a Next.js app scaffold.
- Render a 3x3 board.
- Alternate turns between X and O.
- Detect winner and draw.
- Lock input after completion.
- Support reset.

## Acceptance Criteria

- The game is playable in the browser.
- Winner and draw states are correct.
- Reset returns the game to initial state.

Expected output: .day-shift/specs/01-tic-tac-toe-demo/overview.md exists with specification metadata, a single visible H1, and source traceability back to root-spec.md.

5. Register The Spec In The Index

Create .day-shift/specs/spec-entry.tic-tac-toe-demo.json as command input (this is not the canonical registry file):

{
  "id": "tic-tac-toe-demo",
  "title": "Tic-Tac-Toe Demo",
  "depth": "standard",
  "status": "active",
  "destination": "tic-tac-toe-demo",
  "spec_path": ".day-shift/specs/01-tic-tac-toe-demo/overview.md",
  "source": {
    "type": "markdown",
    "ref": "root-spec.md"
  },
  "implementation_order": "01"
}

Check, register, and verify:

If the spec is already registered, spec add will report a duplicate and not overwrite the existing entry.

<day-shift-cli> spec list
<day-shift-cli> spec add --entry-file .day-shift/specs/spec-entry.tic-tac-toe-demo.json
<day-shift-cli> spec list

Canonical behavior:

• spec add validates this input file and writes the real registry entry into .day-shift/specs/index.json.
• .day-shift/specs/index.json is the source of truth for registered specs.
• The spec-entry.*.json file is just a convenient payload file for onboarding and can be removed after successful registration.

Important: spec add does not take positional ids like spec add 01. Use --entry-file or --entry-json.

Expected output: .day-shift/specs/index.json contains an active tic-tac-toe-demo entry with implementation_order: "01", destination tic-tac-toe-demo, and spec_path pointing to .day-shift/specs/01-tic-tac-toe-demo/overview.md. spec list shows the registered spec.

6. Generate The First Planning Slice

Workflow-guide prompt form:

Workflow: .day-shift/workflows/02-plan-from-spec.md
Prompt: .day-shift/prompts/user/specification.next.md
Spec source: [Relative Path To Spec File Or Spec Directory]

Create the next planning layer from the specification.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/02-plan-from-spec.md`.
Also use `.day-shift/prompts/user/specification.next.md`.

Spec source: .day-shift/specs/01-tic-tac-toe-demo/overview.md

Create the next planning layer from the Tic-Tac-Toe specification. Use the registered `tic-tac-toe-demo` spec entry, preserve traceability to `root-spec.md`, and stop after the slice overview is created and validated.

Create the slice from your registered spec:

<day-shift-cli> slice new --spec-id tic-tac-toe-demo

Then ask for guidance on the next valid step:

<day-shift-cli> planning next-action --artifact .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Expected output: .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md exists as the generated slice overview. planning next-action reports the next valid planning step from that slice instead of requiring you to guess the next artifact.

7. Plan The Game Phase

Workflow-guide prompt form:

Workflow: .day-shift/workflows/02-plan-from-spec.md
Prompt: .day-shift/prompts/user/slice.next.md
Slice overview: [Relative Path To Slice Overview]
Phase overview: [Relative Path To Phase Overview]

Create the next phase from the slice overview.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/02-plan-from-spec.md`.
Also use `.day-shift/prompts/user/slice.next.md`.

Slice overview: .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Create the next phase overview for building the Tic-Tac-Toe game. Use the phase slug `01-build-game`. Stop after creating and validating the phase overview; do not create milestones or tasks yet.

Command the prompt tells the agent to use:

<day-shift-cli> phase new --slice-overview .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md --phase-slug 01-build-game

Why: .day-shift/prompts/user/slice.next.md advances only from a slice overview into phase planning. The command creates .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/phase-overview.md and records CLI provenance before the agent refines the phase body.

Expected output: the phase overview exists and declares the milestone or milestones needed to build the browser game.

8. Plan The Playable Game Milestone

Workflow-guide prompt form:

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 the next milestone from the phase overview, keep it focused on acceptance-checkpoint scope rather than task execution detail, initialize the milestone `reconciliation.md` placeholder, and preserve traceability back to the phase and upstream planning artifacts.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/02-plan-from-spec.md`.
Also use `.day-shift/prompts/user/phase.next.md`.

Phase overview: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/phase-overview.md

Create the next milestone overview for a playable Tic-Tac-Toe board. Use the milestone slug `01-playable-game`. Include implementation-sized task candidates for the game UI, game rules, validation, and closeout evidence. Stop after creating the milestone overview and its pending reconciliation artifact; do not create task directories yet.

Command the prompt tells the agent to use:

<day-shift-cli> milestone new --phase-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/phase-overview.md --milestone-slug 01-playable-game

Why: .day-shift/prompts/user/phase.next.md advances only from phase planning into milestone planning. The command creates the milestone milestone-overview.md plus a pending reconciliation.md, which will stay incomplete until task summaries are finished.

Expected output: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md exists and declares the task set for the playable game.

9. Create The Game Task

Workflow-guide prompt form:

Workflow: .day-shift/workflows/02-plan-from-spec.md
Prompt: .day-shift/prompts/user/milestone.next.md
Milestone overview: [Relative Path To Milestone Overview]

Create the next task directory from the milestone overview, keep the task implementation-sized, initialize both `task-definition.md` and `implementation-summary.md`, and preserve traceability back to the milestone and upstream planning artifacts.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/02-plan-from-spec.md`.
Also use `.day-shift/prompts/user/milestone.next.md`.

Milestone overview: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md

Create the declared task directory for implementing the playable Tic-Tac-Toe game. Use the task slug `01-implement-playable-game` if the milestone declares that slug; otherwise use the first declared task slug from the milestone overview. Create the task definition and paired implementation-summary placeholder only.

Command the prompt tells the agent to use:

<day-shift-cli> task new --milestone-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md --task-slug 01-implement-playable-game

Why: .day-shift/prompts/user/milestone.next.md advances from a milestone overview into task planning. The command creates the task directory, task definition, and paired implementation-summary placeholder without starting implementation.

Expected output: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/tasks/01-implement-playable-game/task-definition.md exists and names concrete target paths, acceptance criteria, validation commands, rollback notes, and open questions.

If the milestone declares more than one task, create only the first task unless you intentionally want the full task set. For a full set, say so explicitly and use:

<day-shift-cli> task new --milestone-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md --full-set

10. Implement The Game

Workflow-guide prompt form:

Workflow: .day-shift/workflows/03-implement-from-task.md
Prompt: .day-shift/prompts/user/task.next.md
Task definition: [Relative Path To Task Definition]

Implement the task, keep changes within scope, run the listed validation when feasible, update `implementation-summary.md` in the same task directory, and use the supported metadata sync/update command for the originating task definition so completed work no longer remains in a ready state.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/03-implement-from-task.md`.
Also use `.day-shift/prompts/user/task.next.md`.

Task definition: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/tasks/01-implement-playable-game/task-definition.md
Mode: implement

Confirm readiness, implement the playable browser Tic-Tac-Toe game within the task's target paths, run the task's validation commands, update the paired implementation summary, and close the task artifacts with changed paths, validation evidence, deviations, discovered work, and follow-up work.

Command the prompt tells the agent to use first:

<day-shift-cli> task readiness-review --task-definition .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/tasks/01-implement-playable-game/task-definition.md

Why: .day-shift/prompts/user/task.next.md requires readiness review before implementation. The command is read-only and confirms that the task has enough scope, dependencies, target paths, and validation detail to start.

Implementation work should follow the task definition. For this demo, a complete task usually creates or updates the app files needed to run a browser Tic-Tac-Toe board, including state for X/O turns, win and draw detection, board lock after completion, and reset.

Expected output: the app runs locally, the task’s validation commands pass or are recorded with explicit exceptions, and the paired implementation summary is completed.

11. Build And Review The Implementation Summary

The implementation prompt tells the agent to refresh and review the paired summary after code changes.

Command the prompt tells the agent to use:

<day-shift-cli> implementation-summary build --task-definition .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/tasks/01-implement-playable-game/task-definition.md
<day-shift-cli> implementation-summary review --task-definition .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/tasks/01-implement-playable-game/task-definition.md

Why: the build command refreshes the canonical paired summary path, and the review command checks that closeout evidence is sufficient without writing files. The agent may still need to manually complete the summary body with actual changed paths, validation evidence, acceptance results, and deviations.

Expected output: implementation-summary.md has implementation_status: completed, status: completed, non-placeholder evidence, and a successful read-only review.

12. Reconcile The Milestone

Workflow-guide prompt form:

Workflow: .day-shift/workflows/04-summarize-and-reconcile.md
Prompt: .day-shift/prompts/user/implementation.next.md
Milestone directory: [Relative Path To Milestone Directory]

Review the milestone, use the completed task `implementation-summary.md` files under that milestone as the implementation source of truth, and update milestone-level `reconciliation.md` with acceptance-criteria review, validation review, discovered work, and follow-up tasks.

Tutorial prompt to give the agent:

Use `.day-shift/workflows/04-summarize-and-reconcile.md`.
Also use `.day-shift/prompts/user/implementation.next.md`.

Milestone overview: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md

Build and complete milestone reconciliation from the completed task implementation summaries. Reconcile only after every task summary in the milestone is completed and non-placeholder. After build or repair, re-open `reconciliation.md` and verify it contains concrete completed-task summary links, acceptance-criteria review, validation review, final notes, and a stated milestone verdict.

Command the prompt tells the agent to use:

<day-shift-cli> reconciliation build --milestone-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md
<day-shift-cli> reconciliation review --milestone-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md

Why: .day-shift/prompts/user/implementation.next.md advances from completed implementation summaries into milestone review. The build command refreshes milestone reconciliation from task evidence, and the review command confirms closure evidence without writing. The artifact must still be checked for non-placeholder closeout evidence before the milestone is reported complete.

Expected output: the milestone reconciliation.md reviews the game acceptance criteria, validation evidence, discovered work, backlog work, follow-up tasks, and review concerns. When the review is complete, reconciliation metadata should be completed.

13. Review Back Up To The Specification

After milestone reconciliation, use review prompts to walk back up the planning hierarchy. These reviews are read-only by default; they tell you whether the completed game evidence satisfies each overview instead of creating more artifacts. Use the matching recertify prompt instead when the question is whether an existing artifact has become stale, should be updated, should be superseded, or should leave active planning input before you rely on it again.

Review The Milestone

Workflow-guide prompt form:

Prompt: .day-shift/prompts/user/milestone.review.md
Milestone overview: [Relative Path To Milestone Overview]

Review against downstream evidence.

Tutorial prompt to give the agent:

Use `.day-shift/prompts/user/milestone.review.md`.

Milestone overview: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md

Review the milestone against the completed task implementation summary and milestone reconciliation. Confirm whether the playable-game milestone acceptance criteria were satisfied and identify any missing task or review evidence.

Command the prompt tells the agent to use:

<day-shift-cli> milestone review --milestone-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/milestones/01-playable-game/milestone-overview.md

Why: milestone review checks the overview against completed task summaries and reconciliation evidence without writing files.

Recertify instead when the milestone may be stale before additional task planning:

Prompt: .day-shift/prompts/user/milestone.recertify.md
Milestone overview: [Relative Path To Milestone Overview]

Recertify this milestone against current task, implementation, and reconciliation evidence. Recommend whether it remains active, needs updates, is completed, is superseded, or should leave active planning input.

Review The Phase

Workflow-guide prompt form:

Prompt: .day-shift/prompts/user/phase.review.md
Phase overview: [Relative Path To Phase Overview]

Review against downstream evidence.

Tutorial prompt to give the agent:

Use `.day-shift/prompts/user/phase.review.md`.

Phase overview: .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/phase-overview.md

Review the build-game phase against the completed milestone evidence. Confirm whether the phase scope is satisfied by the playable-game milestone and report stale metadata or follow-up work separately.

Command the prompt tells the agent to use:

<day-shift-cli> phase review --phase-overview .day-shift/planning/01-tic-tac-toe-demo/phases/01-build-game/phase-overview.md

Why: phase review checks whether milestone evidence satisfies the phase without mutating the phase overview.

Recertify instead when the phase may be stale before additional milestone planning:

Prompt: .day-shift/prompts/user/phase.recertify.md
Phase overview: [Relative Path To Phase Overview]

Recertify this phase against current milestone, task, implementation, and reconciliation evidence. Recommend whether it remains active, needs updates, is completed, is superseded, or should leave active planning input.

Review The Slice

Workflow-guide prompt form:

Prompt: .day-shift/prompts/user/slice.review.md
Slice overview: [Relative Path To Slice Overview]

Review against downstream evidence.

Tutorial prompt to give the agent:

Use `.day-shift/prompts/user/slice.review.md`.

Slice overview: .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Review the Tic-Tac-Toe slice against the completed phase, milestone, task, and reconciliation evidence. Confirm whether the slice desired outcome was satisfied and identify any remaining planning or validation gaps.

Command the prompt may tell the agent to use:

<day-shift-cli> validation smoke --scope planning --artifact .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Why: slice review is a prompt-led evidence review. Artifact-scoped smoke gives a read-only planning validation signal for the slice while keeping any follow-up writes separate.

Recertify instead when the slice may be stale before additional phase planning:

Prompt: .day-shift/prompts/user/slice.recertify.md
Slice overview: [Relative Path To Slice Overview]

Recertify this slice against current upstream specs and downstream planning, implementation, and reconciliation evidence. Recommend whether it remains active, needs updates, is completed, is superseded, or should leave active planning input.

Review The Specification

Workflow-guide prompt form:

Prompt: .day-shift/prompts/user/specification.review.md
Spec source: [Relative Path To Spec File Or Spec Directory]
Slice overview: [Relative Path To Slice Overview]

Review against downstream evidence.

Tutorial prompt to give the agent:

Use `.day-shift/prompts/user/specification.review.md`.

Spec source: .day-shift/specs/01-tic-tac-toe-demo/overview.md
Slice overview: .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Review the original Tic-Tac-Toe specification against the completed downstream planning, implementation, and reconciliation evidence. Confirm whether the specification was satisfied, whether any source-spec expectations remain unmet, and whether any follow-up planning should be reported.

Recertify instead when the source spec may be stale before you plan from it again:

Prompt: .day-shift/prompts/user/specification.recertify.md
Spec source: [Relative Path To Spec File Or Spec Directory]
Spec index: .day-shift/specs/index.json

Recertify this specification against current implementation, workflow direction, and downstream planning evidence. Recommend whether it remains active, needs updates, should collapse with related specs, should defer, is superseded, or should leave the active spec registry.

Command the prompt may tell the agent to use:

<day-shift-cli> validation smoke --scope planning --artifact .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Why: specification review is the final upward check. The command provides read-only downstream planning evidence; the prompt owns the judgment about whether the spec overview was satisfied.

14. Learn The Normal Flow From The Finished Game

At this point you have used the normal Day Shift sequence:

specification -> slice overview -> phase overview -> milestone overview -> task definition -> implementation summary -> milestone reconciliation

Use read-only navigation to inspect what you created:

<day-shift-cli> planning inventory --root .day-shift/planning/01-tic-tac-toe-demo
<day-shift-cli> planning gap-report --scope .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md
<day-shift-cli> validation smoke --scope planning --artifact .day-shift/planning/01-tic-tac-toe-demo/slice-overview.md

Why: these commands show the hierarchy, missing or incomplete downstream evidence, and planning-validation state without creating or changing artifacts. This is the same read-only orientation pattern you will use on real project work.

15. Reference Links

For command-family boundaries, exact help checks, and read-only versus write-capable behavior, use .day-shift/references/commands.md. Planning-layer producers, consumers, expected outputs, and evidence handoffs live in .day-shift/references/planning-layers.md. Validation and review gates live in .day-shift/references/validation-and-review.md. Metadata field boundaries live in .day-shift/references/metadata.md. Prompt and template responsibilities live in .day-shift/references/prompts-and-templates.md; use those pages for handoff and artifact-shape context, not as embedded prompt instructions in this walkthrough.

Troubleshooting

If you see a compatibility failure mentioning missing schema evidence:

1. Re-run init and doctor:

<day-shift-cli> init
<day-shift-cli> doctor

1. If the workspace is partially upgraded or version-incompatible, use migration preview first:

<day-shift-cli> workspace migrate --dry-run --target-schema-version 1

1. Apply only after reviewing dry-run output:

<day-shift-cli> workspace migrate --target-schema-version 1 --confirm apply-workspace-migration