GUI planning workflows

Use the local GUI to prepare work for the implementation agent you choose and operate. Follow GUI setup, start the project runtime with day-shift serve --open, and select Project Brief, Specs, or Planning. Your selected document and its current revision determine which actions can run.

Clarify an idea

Use Ask to understand the current project, explore improvements, or compare alternatives. Ask leaves documents unchanged. Describe the intended users, observable outcome, constraints and unresolved decisions. Add design details when relevant: data ownership, API behavior, security, keyboard access, performance budgets, migration and recovery. Record alternatives and the decision you actually made; a model suggestion does not settle an open question.

Choose Update to prepare changes to the selected planning documents. Inspect Review changes, then choose Apply changes or Discard. Nothing is saved during preparation; Saved and verified confirms a successful application. Undo update restores the previous saved content if its revision is still current. Source references and imported text provide context; they do not grant more write authority. A failure, partial result or displayed draft is not evidence that the document was saved. See Project chat and planning updates for coordinated edits, history and undo.

Create a registered specification through the specification action, then refine its goals, constraints and measurable success criteria. Review it and inspect the findings. Planning disposition is a separate action with a current preview and explicit confirmation. A successful review alone does not authorize work creation or mark a task ready.

Choose the planning level

Select the registered specification in Specs, then choose Planning workflow. The GUI explains the level and previews the destination and source revision.

Level	First result	Next step
Basic	One draft task and its paired implementation summary	Complete the task contract and review readiness.
Structured	One draft work overview	Declare the direct tasks in order, then create those task pairs.
Governed	One draft slice	Refine each layer and create its declared phases, milestones and tasks.

Confirm only the displayed next layer. Creation preserves existing documents and does not recursively finish the hierarchy. A draft scaffold may contain missing details; creation does not prove readiness. Complete the objective, target paths, acceptance criteria, validation commands, dependencies and recovery instructions before implementation. Use Operating model and artifacts for workflow fit.

Cancel a preview to return to the document without creating anything. After creation, use Open in chat to refine a resulting document. Reopening an existing destination preserves its authored content. If the source, selected revision, registry or destination changes, obtain a new preview before trying again.

Organize the planning directory

Open Ordering preferences in Planning to choose First to last or Last to first for the applicable navigation layers, including top-level Structured work. Basic, Structured and Governed use the same ordering controls where their hierarchy applies. Ordering follows numbered natural names, not modification time, and saves as a browser preference without renaming files.

All three lanes show directory status indicators where status evidence is available. Open the item to inspect the underlying task or overview and its next steps. An icon is a navigation aid; missing or unknown status is not readiness authorization, and Basic or Structured do not acquire Governed phases or milestones.

Resolve readiness findings

In the selected item, open Actions beside Next steps and review and run Task Readiness Review. Review is read-only. Findings identify the owning artifact and distinguish missing task detail, a dependency handoff and a decision the user must make.

Use Refine this item in chat, then Prepare planning refinement, to put the selected item’s feedback into your existing conversation draft. Inspect and send that request yourself. Resolve the named issue, save the change, and review the current revision again. If the bounded automatic repair allowance is exhausted, decide or edit explicitly before another review; repeatedly requesting the same review does not repair the contract.

Readiness authorization requires its own preview and confirmation. Likewise, recording acceptance and closing completed work require current implementation and validation evidence through their lifecycle actions. A recommendation, generated command, imported log or another agent’s progress report cannot replace that evidence. Unsupported actions remain unavailable; a registered command description alone does not mean this runtime implements it. Use the CLI for a supported operation that the current GUI does not expose, following its own preview and evidence requirements.

Select current work and inspect next steps

In Planning, open Work queue and current work. Choose a selection session, inspect actionable or blocked candidates, and use Make … current with its confirmation to store your selection. The CLI shares this selection when it uses the same session. Browsing a candidate or returning to a document does not change lifecycle state.

Next steps and review reports the selected artifact’s recommended action and gaps. Open the document that owns a finding, save the correction, then refresh guidance or review again. Missing or incomplete evidence remains visible; an empty page is not proof that all work is finished. Terminal users have work current, work candidates, planning next-action, and planning gap-report.

Guidance uses the selected saved document’s revision and refreshes when relevant evidence changes or you explicitly refresh it. During refresh, the panel keeps its layout and previous guidance with a refreshing status. That retained view is not a new readiness decision. Unsaved editing does not authorize actions against the draft.

For completed or cancelled tasks, guidance explains that state in plain language. Review the summary, inspect historical evidence or choose subsequent work. A new implementation handoff is unavailable for a terminal task. A completed task can still run separate current-workspace follow-up checks.

If guidance reports stale required validation or inconsistent paired lifecycle evidence, open the named summary and inspect Validation evidence and Task recovery. Refresh or recover the required evidence using the applicable lifecycle action. doctor can help diagnose structural problems; it does not execute validation or grant readiness. If guidance could not read all evidence, follow limit recovery before interpreting its recommendation.

Operate a task attempt

After readiness authorization, use Task attempt lifecycle to preview and confirm Open attempt and Capture baseline. Inspect dirty declared targets and record ownership rationale for any adopted changes before implementation. Contract-only work must follow its applicable evidence requirements rather than inventing a runtime baseline. The panel also supports Record blocker, Cancel task, and Complete implementation when their preconditions are satisfied. Implementation completion is followed by separate review acceptance and closure.

Open Task recovery and choose Inspect recovery before acting on a failed or interrupted attempt. Supply the actor, reason, and original evidence run when required. Eligible actions include authorizing a retry, aborting an empty attempt, superseding a baseline-only attempt, recovering attempt chronology, and recovering validation lineage. Inspect the exact preview before Confirm recovery. Source fixes, validation execution, waivers, and arbitrary scope or contract revisions remain separate operations.

Use External-agent handoff and return for implementation and Lifecycle records for the terminal sequence and recovery commands.

Inspect run history and trace references

Run history reads saved lifecycle evidence for the selected work. Inspect status, entries, and the current continuation guidance. Metrics and comparison can load friction metrics and compare two verified runs. Missing measurements are unavailable, not zero; different scopes or evidence profiles may make runs non-comparable. Viewing history neither replays commands nor resumes implementation. The CLI equivalents are under resume run.

Trace-link controls inspect lineage and stored dispositions, preview supported migration repairs, and offer separate confirmed disposition writes. A migrated disposition can repair eligible canonical trace fields. Retired or deleted targets remain historical evidence; arbitrary Markdown references are not rewritten. Resolve conflicts and refresh stale previews before applying. See resume and trace recovery for command inputs and recovery boundaries.

Preserve drafts and recover from change

Planning remembers your last document, directory and visible pane separately for Basic, Structured and Governed. Specs, Policy packs and Prompts remember their own positions. Returning from another page restores your place automatically; explicit artifact links still open their requested target. The browser stores only navigation hints for this project, and the current runtime reads the document again.

These positions survive reloads and runtime restarts at the same browser origin (scheme, host and port). Another browser or local address has separate storage. With browser storage blocked, navigation can still be retained in memory until the page reloads. An unavailable document offers Try opening again or Choose another document; directory failures offer retry and a route back to the root. Restoring a position does not save an unsaved draft, accept evidence or replay an action.

Save a dirty document before running a planning action. Planning creation and lifecycle controls stay blocked while unsaved source edits are present. Switching planning views preserves the current conversation; use the selected-item and chat controls on narrow screens. Dialogs support keyboard focus, Escape to cancel, and focus return to the opener.

When another tab saves the selected document, compare the saved version with your local draft. Download the draft before deliberately replacing it if needed. Reconnect with the current runtime identity after a runtime restart. Retained operation history can report an earlier result without dispatching the same operation again; a stale preview still requires a new review. History pages and cursors can expire as bounded retention removes old terminal records. Reload the current history instead of replaying an expired identity. Active operations and unsaved edits are not permission to overwrite a newer canonical revision.

Large repository searches are bounded. A limited result means narrow the directory or query; it does not prove no other matches exist. Selected file previews use their own read permission and current ignore rules. Denied or ignored content is not returned as an empty successful document. See Troubleshooting for the corresponding recovery paths.

Hand ready work to your agent

Once the task has current readiness authorization, give its task definition and workflow to your chosen implementation agent. Day Shift’s planning runtime does not launch that agent or edit repository source. Exact validation execution is a separate authority contract. Git delivery, publication, deployment, production migrations and production recovery remain external operations. Task acceptance, project review and work closure are separate decisions; completing planning does not perform them.