This reference is for evaluators, operators, and reviewers using Basic, Structured, or Governed workflows with Day Shift 0.1.24. Evidence was rechecked on 2026-08-04. “Supported” applies only to the named scope; publication, prompt portability, or a repository example does not prove an untested environment or integration.
Use the website compatibility matrix for per-platform evidence sources and dates, and verified proof records for executor, benefit, cost, and unresolved-boundary disclosures.
| Status |
Meaning |
| Supported |
Repository evidence covers the named scope. |
| Supported with constraints |
Evidence applies only inside a stated version, platform, or operating boundary. |
| Experimental |
Evidence exists, but the behavior is not a stable compatibility promise. |
| Untested |
No repository evidence supports the combination. |
| Unsupported |
The current product does not provide the behavior. |
| Planned but unavailable |
Future work may be discussed, but the behavior is not callable. |
| Area |
Status |
Current boundary |
| Linux runtime |
Supported with constraints |
Repository execution evidence covers Linux x64 with Node.js 20 and a POSIX shell for release 0.1.24; it is not a guarantee for every distribution, shell policy, repository layout, project size, or newer Node.js release. |
| macOS x64 and arm64 archives |
Supported with constraints |
Release-manifest and archive layouts are verified. This task did not exercise native macOS CLI execution. |
| Windows x64 and arm64 archives |
Supported with constraints |
Archive and PowerShell installer layouts are verified. Native execution requires a Windows command shell and was not exercised by this task. |
| Bash, Zsh, and Fish completion generation |
Supported with constraints |
Generation is tested. Interactive startup behavior and third-party shell/plugin configuration remain environment-owned. |
| Other operating systems, architecture combinations, and native package managers |
Untested |
No compatibility claim follows from a similarly named archive or portable JavaScript runtime. Public npm discovery, Homebrew, winget, .pkg, and .msi are not current public install paths. |
| Area |
Status |
Current boundary |
| Codex internal dogfooding |
Experimental |
This repository contains internal Governed workflow evidence. It is not a direct integration, independent certification, endorsement, customer adoption story, or proof that Codex always complies. |
| Claude Code and other prompt-capable assistants |
Untested |
Markdown portability does not prove model compatibility, reliability, or integration support. |
| External-agent enforcement |
Unsupported |
Day Shift exposes repository contracts and commands. The integration and accountable human determine whether an external agent reads and follows them. |
| Multi-agent orchestration |
Planned but unavailable |
Shared artifacts can coordinate human-reviewed work, but hosted orchestration and automatic coordination among arbitrary agents are not current capabilities. |
| Area |
Status |
Current boundary |
| Declared validation-set execution |
Supported with constraints |
task validation-set derives commands only from the exact current task revision, rejects caller-supplied argv and shell evaluation, records each command independently in order, and stops on the first required failed, timed-out, spawn-restricted, stale, or unrecordable result. Retries require the returned exact failed identity. |
| Explicit selected-command execution |
Supported with constraints |
task validation-record can preview exact argv and execute one selected command once on apply, including explicit semantic JSON assertions. It remains the single-command and imported-evidence surface. |
| Manual, CI, or imported evidence |
Supported with constraints |
Results produced elsewhere retain source, scope, status, and bounded references. Recording them does not mean Day Shift executed the command or proved more than the source. |
| Scoped validation |
Supported with constraints |
Declared paths and dependencies bind the evidence scope. Unknown dependency impact remains conservative rather than being silently treated as covered. |
| Read-only review |
Supported |
Review reports evidence and findings without accepting, closing, repairing, migrating, or creating follow-up work. Each mutation needs its separately named, receipt-bound command. |
| Area |
Status |
Current boundary |
| Resumable lifecycle runs |
Supported with constraints |
Routine status and resume are compact-first and byte-bounded. Their context-loss capsule names current scope, completed evidence that must not be repeated, one next action, and targeted paging; explicit full audit remains available. A run manifest is continuation evidence, not the canonical task pair, and cannot recover an incomplete operational transaction by itself. |
| Declared path scope |
Supported with constraints |
Target paths make intended scope inspectable and closeout classifies attributed changes. A declaration is not an operating-system sandbox around arbitrary tools. |
| Changed-path attribution |
Supported with constraints |
Attribution is baseline-relative. Pre-existing dirty targets require explicit adoption; concurrent or external changes can remain uncertain rather than being assigned to an agent. |
| Monorepos and nested repositories |
Supported with constraints |
A nearer workspace configuration can select a nested workspace. Ambiguous nested Git roots, case collisions, and repository escapes fail closed; not every topology or project size is tested. |
| Symlinks |
Supported with constraints |
Supported path inputs are normalized and repository escapes are rejected. Symlinks and security policies can still make a layout ineligible. |
| Area |
Status |
Current boundary |
| Concurrent Day Shift writes |
Supported with constraints |
Participating mutations use one exclusive repository lock and revalidate preconditions. This does not serialize unrelated editors, scripts, or external tools. |
| Transaction-backed mutation |
Supported with constraints |
Supported multi-path writes stage content and verify replacements. An incomplete state requires inspection; lock or transaction files must not be deleted as a guessed repair. |
| Exact-fingerprint recovery |
Supported with constraints |
An owning command may offer roll-forward or restore when retained evidence proves the action safe. Missing, stale, or diverged evidence blocks recovery. |
| Performance |
Untested |
No broad maximum repository size, throughput, or latency guarantee is published. Evaluate representative work locally. |
| Area |
Status |
Current boundary |
| Documented workspace migration |
Supported with constraints |
Only documented source layouts and exact preview-bound transactions are supported. |
| Legacy readiness and evidence formats |
Supported with constraints |
Documented legacy layouts remain readable inputs. They are not canonical new-write destinations, and every historical customization is not guaranteed to migrate. |
| Partial-field migration, ambiguous mapping, implicit migration, or demotion |
Unsupported |
Reads and reviews do not move artifacts. Unsupported source shapes remain blockers rather than being guessed into a destination. |
| Experimental commands |
Experimental |
An example or callable surface marked experimental is not a stable workflow contract and may change. |
doctor is supported with constraints. It reports repository and runtime health, reads the specification registry, and checks selected workspace contracts. It does not semantically approve every file beneath .day-shift/specs/, execute task validations, or replace specification, readiness, evidence, and review gates.
Day Shift adds repository artifacts and review work. That overhead can be useful when work crosses sessions or hands, scope matters, and evidence must persist. It may be excessive ceremony for tiny disposable work with no review or handoff; use the fit assessment before adopting a larger workflow.
Day Shift structures intent and evidence; it does not guarantee code correctness, model-output quality, regulatory compliance, project success, or reviewer acceptance. Release hosting, purchase, entitlement, signed-license delivery, recovery, legal terms, warranty limits, and response policies remain website-owned. Normal CLI operation is local-first and offline-capable after installation, but this does not imply universal environment compatibility.