Delivery guidance and evidence
Open Delivery to collect planning reports into a Markdown document for leadership, technical documentation, and a pull or merge request. Saved handoffs live in .day-shift/state/delivery/. The Markdown file contains the handoff and its source references; it can also be edited in an external editor.
Compile a planning directory
Section titled “Compile a planning directory”Browse the planning directories and choose Compile delivery document. The title uses the selected directory’s lowercase, hyphenated slug, including its ordering prefix (for example, 02-document-handoff). New filenames use that slug with a unique suffix, so compiling the same directory again creates a separate document. Compilation reads the selected directory recursively, including nested implementation summaries, reconciliations, and project reviews. A task directory, milestone, phase, work root, or wider planning directory can be selected. Files outside the selected subtree are excluded.
The compiler prepares a draft with two main sections:
- Executive Handoff collects the reports’ accomplishment summaries, recorded review outcomes, risks, and follow-up for leadership.
- Technical Handoff includes the report bodies, validation details, exact source references and revisions, and captured external delivery flows.
Compilation uses the recorded report content. Missing summaries and unfinished statuses remain visible; compiling a report does not accept the work or certify a deployment. Use Collected reports to inspect exactly what was included. Current limits are 256 reports, 10,000 traversed entries, 32 MiB of planning input and 384 KiB of handoff Markdown. An oversized collection asks for a narrower directory instead of silently omitting reports.
Edit, preview and copy the handoff
Section titled “Edit, preview and copy the handoff”Use Source, Preview, or Split to edit the document and check its Markdown formatting. Choose Save delivery to write it to .day-shift/state/delivery/. Copy Markdown copies the handoff body, without the file’s storage metadata, for a pull request, merge request or documentation page. If clipboard access is unavailable, a dialog provides selectable Markdown.
After saving, Discuss handoff prepares the document as project-chat context. Add delivery context to message attaches it to the existing question after checking its saved revision. Preparing or attaching context does not send the message. On smaller screens, use the Delivery documents and Chat pane buttons.
Discard or delete a handoff
Section titled “Discard or delete a handoff”Discard draft removes an unsaved compilation or discards local changes to a saved document. Delete delivery opens a confirmation for permanently removing the saved Markdown file and any local draft. Deletion checks the reviewed file revision; refresh and review a file that changed before deleting it. Source planning reports and external delivery records remain available.
Record external delivery flows in the document
Section titled “Record external delivery flows in the document”Document an external delivery flow adds a named flow, PR or run reference, environment, observed outcome, and steps, verification or recovery notes under Technical Handoff. These additions are operator-reported document content; save the document to retain them.
Compilation also includes existing external delivery records whose linked work belongs to the selected planning subtree, together with their retained observations and provenance. Use External delivery records to inspect those records or capture more detailed evidence using the supporting workflow below. Existing record history remains available.
Refresh reports without replacing authored text
Section titled “Refresh reports without replacing authored text”Saved documents retain their compilation scope and report revisions. A source check identifies when reports were added, changed or removed, or captured external evidence changed. Recompile as new document creates a separate draft from the current reports and preserves the existing document, including local edits. Copy any authored additions you want to carry into the new handoff.
Drafts are kept separately for each project, with up to eight pending document drafts. Saving checks the file’s current revision. If another tab or external editor changed it, preserve your edits with Copy Markdown, then use Use current file before editing further. A save interrupted by a connection failure offers Retry save using the same operation identity. Credential-like drafts remain only in the open tab.
Supporting external delivery records
Section titled “Supporting external delivery records”The remaining sections describe External delivery records. These records support the Markdown handoff with exact revision and environment evidence. Day Shift does not commit, merge, publish, deploy, promote environments, migrate production data, provision secrets, probe production or run rollback. Generating or recording a step performs no external action.
Bind a delivery to current work
Section titled “Bind a delivery to current work”Create a delivery record with its title, work artifact path, exact source revision and environment. Use a full commit identity or a SHA-256 revision, not a branch name that can move. Saving reads the selected planning artifact and records its current hash separately from the source revision. Describe known risks, the operator decision and operator notes. Review the source and environment before saving or importing evidence.
Records are project-local. A saved record has a version; each update or imported observation advances it. Shared project events refresh other tabs. If another tab updates your record, your draft keeps its original version. Review the displayed latest notes, then choose Keep my edits on the latest version only when you intend to save your draft over that version. Refresh alone does not resolve the conflict.
Read gaps without inferring production readiness
Section titled “Read gaps without inferring production readiness”The assessment distinguishes missing, stale, failed, waived, unsupported and unknown evidence. Local task closure and test evidence do not prove CI completion, configuration correctness, migration safety, deployment readiness or production success. A waiver remains a waiver and requires operator reasoning. Resolve external prerequisites through your own review and delivery tools.
Assessment and brief generation use the currently displayed evidence page. Review additional pages separately. A successful report does not erase an earlier failure or a later regression. Compare each observation’s source, work revision, environment, time and provenance before deciding what it supports.
Prepare and export instructions
Section titled “Prepare and export instructions”Choose Generate delivery brief to prepare review, release, rollout, migration, verification and rollback instructions from the selected record and current local evidence. The brief identifies its exact work/source/environment and evidence digest. Project templates are bounded plain text; they cannot execute expressions, commands or network requests. The current template generator is local and deterministic.
Edit Operator-authored instructions, then choose Prepare brief export and copy the exported text. Regeneration preserves operator text. Changed or unavailable context disables export until you regenerate against current evidence. Generated instructions are proposals for an external operator; they are not evidence that a command ran.
Prepare delivery context in chat prepares context alongside the persistent project conversation. Add delivery context to message checks the work revision and appends to your existing question. You still choose whether to send it. The chat action does not execute delivery instructions.
Record external observations
Section titled “Record external observations”Expand Record an external outcome, select unknown, failed, partial or succeeded, and describe the actual observation. You may supply evidence text or a text file of at most 8 KiB, an external identifier and an origin. The API limits an entire evidence import to 16 KiB. HTTP(S) references must omit credentials, queries and fragments; URLs are retained as references and are never fetched.
| Provenance | What it establishes |
|---|---|
| Reported | An operator supplied a description; no evidence body authenticated it. |
| Evidence-supplied | Text was supplied, but its authenticity has not been verified. |
| Externally-verified | A configured Ed25519 public key verified an attestation for the exact project, evidence identity, content digest, source/work revision and environment. |
The observed outcome and verification result remain separate. A verified partial or failed result is still partial or failed. Invalid, expired, unconfigured or mismatched attestations never upgrade supplied evidence. A later environment/source change makes old observations stale while retaining their original provenance. Retention and refresh do not promote reported evidence to verified evidence.
Configure optional attestation verification
Section titled “Configure optional attestation verification”An operator configures public trust keys locally in .day-shift/state/private/delivery/trust.json. No private signing key or ambient credential belongs here. The settings object has schemaVersion: 1, the exact projectUri, and keys: up to 16 entries containing an id, an Ed25519 SPKI PEM publicKey, and an environments array. Settings are limited to 32 KiB. Missing or invalid settings leave observations unverified.
An external signer supplies attestation with keyId, expiresAt and the base64 Ed25519 signature. Sign the UTF-8 bytes of compact JSON with fields in this order: schemaVersion, projectUri, id, sourceRevision, artifactRevision, environment, externalId, origin, outcome, digest, observedAt, expiresAt. The schema version is 1. The digest is sha256: followed by the lowercase SHA-256 of the supplied content, or the description when content is absent. Use the exact strings submitted with the observation; changing signed fields invalidates verification. Signing takes place in your external tool.
The GUI’s optional attestation field accepts the attestation object, not trust configuration or private keys. A valid signature establishes the configured signer’s statement; it does not independently prove production health. Historical verification records retain the key digest, attestation digest and verification time. Removing a key prevents new verification under it but does not rewrite historical results.
Retention, recovery and feedback
Section titled “Retention, recovery and feedback”The local store allows 256 active records. Retired records retain immutable identity and history, so the lifetime record count can exceed 256. Only the latest 16 evidence bodies per active record remain available; older entries retain their digest, outcome and provenance with expired content. Retirement removes retained bodies. Compaction preserves identities and replay protection. Use a new observation to describe a correction or regression; do not treat unavailable historical content as a fresh verification.
The GUI loads 25 records or observations per page; the API allows at most 50. A changed cursor requires a current first page. Event gaps and reconnects refetch current state without replaying writes. Brief proposals are bounded to eight entries and 2 MiB in the existing proposal service; replaced GUI proposals are released. Expired brief context requires regeneration.
One record draft per project may survive reload in session storage, limited to 32 KiB and eight project slots. Full or unavailable storage and credential-like drafts remain in memory with a visible message: keep that tab open until saved. Review all input for secrets; pattern checks cannot recognize every sensitive value. Project changes preserve separate drafts, not shared authority.
For subsequent feedback, retain the delivery identity, source/work revisions, environment, observation identity and digest, and the actual failed or partial outcome. These references support your next planning decision without changing the earlier history. See external-agent handoff and return for implementation corrections and troubleshooting for recovery.