External-agent handoff and return
Open External agent and use the External-agent workflow section in a task or its paired implementation summary to take approved work to any coding agent you operate. Day Shift prepares context and observes returned changes. You choose the agent, its workspace and its permissions, and operate it yourself.
Prepare a portable handoff
Section titled “Prepare a portable handoff”Select the current task, complete its readiness review and authorization, and open an implementation attempt with a baseline through the supported task lifecycle. Choose Prepare implementation handoff, then copy or export the readable brief or structured contract. The handoff includes task scope, targets, acceptance criteria, declared validation guidance, current references, attempt identity and continuation instructions. Refresh the handoff before resuming work after a contract or source change.
No provider account or proprietary agent integration is required. Give the brief to your preferred agent and arrange workspace isolation yourself when needed. The handoff does not authorize additional paths, execute its commands, create a branch, commit changes or deploy anything.
The readable brief appears in a code block with a copy button. A toast confirms a successful copy. Completed or cancelled tasks cannot prepare a new implementation handoff. For a completed task, inspect its returned work and historical evidence; use a follow-up check to test the current workspace. New implementation needs the appropriate lifecycle recovery or new task.
Return to current evidence
Section titled “Return to current evidence”Return to the task after the external agent has worked. Shared project events refresh observed source and return evidence; Refresh returned work requests a fresh view explicitly. Source observation is read-only. Git status and differences can identify staged, unstaged, untracked, renamed and deleted paths, but cannot establish who authored them. Non-Git workspaces use bounded declared-file observations with explicit attribution limits. Nested workspaces retain project-relative scope.
| Evidence | What it establishes |
|---|---|
| Reported external activity | What a user or agent says happened; remains unverified. |
| Observed source changes | Current file differences and scope observations; not authorship or acceptance. |
| Imported report | Supplied command, revision, outcome and output with imported/reported provenance. |
| Executed validation | A command the runtime actually ran, with exit status, timing, output digest and input freshness. |
| Accepted lifecycle evidence | An explicit canonical review/disposition decision made against current task and summary evidence. |
Dirty editor buffers and conversation drafts remain local drafts while evidence refreshes. When a revision changes, refresh the proposed action before using it. A reconnect or restart does not replay validation, report imports or lifecycle writes automatically.
Validate or import a report
Section titled “Validate or import a report”Open Validation evidence and choose Refresh validation evidence to inspect recorded runs without executing anything. For a supported declared command, choose Preview validation, review the exact arguments, working directory, input revisions and effects, then choose Confirm and run validation. Results are recorded and refreshed automatically; no external report import is needed.
| Declared command | GUI execution | Timeout |
|---|---|---|
node --check <file> |
Syntax check of one local .js, .mjs or .cjs file |
10 seconds |
node --test <file> |
Run one local .js, .mjs or .cjs test file |
15 minutes |
pnpm run <script> |
Run an existing package validation script; currently unavailable in the native Windows GUI runtime | 1 hour |
These are exact three-argument forms, without extra flags, globs or shell operators. Supported package-script names are test, check, lint, validate, validation, or compatibility, optionally followed by colon-separated names such as test:unit or compatibility:local. The script must exist in the project’s package.json; pnpm must be available to the runtime. Tests and scripts run with the runtime user’s permissions. They can write files, start services or access the network; package scripts can invoke lifecycle hooks. In this repository, compatibility:local installs frozen-lockfile dependencies and runs the full quality procedure.
For an authorized open attempt, GUI execution records required validation through the task’s canonical validation lineage. Failed or stale required checks may need the displayed retry/recovery action before another execution. Unsupported commands remain visible with a reason; the CLI’s explicit task validation-set / task validation-record contracts remain available for their supported commands. A supported command shape alone does not make an ineligible task executable.
An executed result records the interpreter’s actual exit status. It does not independently verify the interpreter. Certification with Node 24.20.0 observed a zero exit status for invalid export syntax in a .js file. Require additional appropriate validation when this affects your task; a syntax-check pass alone does not establish implementation acceptance. This interpreter limitation requires separate runtime-tooling follow-up.
The GUI bounds time, output and readable inputs independently of planning-guidance settings. Validation inputs are limited to 2 MiB per file, 32 MiB total and 100 declared target/dependency paths. Directory scopes or oversized inputs can require the CLI path. Output exceeding 16 MiB stops execution; saved stdout and stderr excerpts are capped at 32 KiB each, with digests and truncation indicators. A changed preview input requires a new preview. After cancellation or an interrupted connection, refresh evidence to determine what was recorded; closing a request does not undo a saved result. A failed evidence refresh keeps the execution receipt available and does not rerun the check.
Check a completed task’s current workspace
Section titled “Check a completed task’s current workspace”Choose Preview follow-up check, inspect the proposed execution, then Confirm and run validation. New observations appear under Current workspace follow-up checks, separately from Historical validation runs. They do not reopen the task, replace accepted evidence or satisfy a closed attempt’s requirements. Changed inputs can make a follow-up stale, including when they change during execution.
Historical runs marked stale refer to an earlier input revision; that label does not change their original outcome or undo completion. If new results reveal work to do, use a new task or the authorized task review-repair successor workflow. Report imports are unavailable for the completed attempt.
Import an external result for an open attempt
Section titled “Import an external result for an open attempt”For an eligible open attempt, start the JSON report template, preserve the actual command, revision, outcome and criterion identifiers, and preview the import before confirming it. Imports are limited to 64 KiB. Review the content for secrets yourself. Supplied text is displayed as data and cannot add execution authority. An imported “passed” result remains unverified, carries canonical not_run status, and cannot satisfy required executed validation. Source changes make relevant prior results stale without deleting their history.
Correct, review and accept
Section titled “Correct, review and accept”A failed check or an out-of-scope observation produces correction guidance. Copy a fresh correction brief and have your external agent make the source correction. Preserve unrelated user changes. If necessary scope was omitted, follow the task lifecycle’s task scope-recover path in the existing run. A material contract revision requires its explicit authorization and current recovery gates; a correction brief grants neither.
Expand the evidence groups you need; current workspace observations and historical records answer different questions. Use summary refinement to prepare a conversation suggestion from current return evidence. Expand Report external progress in chat to enter an unverified activity report. Both preserve existing conversation text and require you to send explicitly. Draft evidence notes and authored acceptance claims are not accepted review receipts.
Complete the required validation and implementation-summary evidence, then use the existing explicit lifecycle previews and confirmations for implementation completion, accepted disposition and task close. Each gate checks current revisions. If the task agreement changed, obtain current readiness review and follow the supported recertification or contract-revision recovery before proceeding. Historical accepted attempts remain history; they do not certify later changes.
Delivery stays external. Git delivery mutations, publication, deployment, production migration and rollback are not implementation-return actions. Continue with GUI planning workflows for planning actions and evidence review for the wider closeout process.