Known limitations and compatibility boundaries
This reference describes the current repository build for evaluators, operators, and reviewers using Basic, Structured, or Governed workflows. The historical release matrix below records 0.1.24 evidence from 2026-08-04; it does not certify later GUI builds. Current source requires Node.js >=24.0.0. Check your installed version and exact release manifest before applying that release’s compatibility claims. “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 language
Section titled “Status language”| 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. |
Tested runtime and distribution
Section titled “Tested runtime and distribution”The following platform observations are historical release evidence. Archive-layout verification does not prove native GUI execution. This documentation audit does not recertify operating systems, providers, or released packages.
| 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. |
Agent and integration boundaries
Section titled “Agent and integration boundaries”| 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. |
Validation execution and evidence
Section titled “Validation execution and evidence”| 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. |
Runs, paths, and attribution
Section titled “Runs, paths, and attribution”| 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. |
Concurrency, transactions, and recovery
Section titled “Concurrency, transactions, and recovery”| 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. |
Migration and legacy compatibility
Section titled “Migration and legacy compatibility”| 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. |
Workspace doctor coverage
Section titled “Workspace doctor coverage”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.
Product and adoption limits
Section titled “Product and adoption limits”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.
Current GUI and provider boundaries
Section titled “Current GUI and provider boundaries”The current GUI includes Project Brief, Specs, Planning, Policy packs, Prompts, Feedback, Delivery, Academy, and Settings. See Choose the GUI or CLI for coverage and terminal alternatives. Older releases may lack these surfaces. The source tree and deterministic fixtures establish implemented paths; live-provider quality and native-platform behavior require their own qualification.
| Area | Current boundary |
|---|---|
| Planning and lifecycle | The GUI exposes selected planning reviews, creation, attempt transitions, recovery, run inspection, trace dispositions, and maintenance operations. Availability depends on selection, current evidence, permissions, and concrete runtime support. A catalog entry alone does not prove executability. |
| Document chat | Ask answers without saving; Update prepares changes to selected targets for review and Apply changes. A draft is not a saved document. Saved and verified confirms the runtime write. |
| Read context | Chat defaults to Whole project for eligible reads. Context can narrow it to selected files and folders. Sending grants the displayed read scope to the selected provider; ignore rules, exclusions, authorization, and retrieval budgets still apply. Whole-project access does not send every file or prove exhaustive coverage. Read context and edit targets are separate. |
| Source implementation | You operate the external coding agent or editor. The planning GUI does not launch arbitrary implementation agents or edit source code on their behalf. |
| Validation | The GUI runs exact declared node --check, node --test, and supported pnpm run validation scripts after preview and confirmation. Native Windows package-script execution remains unavailable. Active-attempt runs record required evidence; completed-task follow-up checks remain separate. Input/output/time limits and unsupported commands can require the CLI. Imported results remain unverified. See validation contracts. |
| Delivery | Compiling a handoff or recording an external observation does not run Git delivery, CI, publication, deployment, migrations, or rollback. |
| Capacity and diagnostics | Environment presets tune local CPU/memory budgets; they are not hardware benchmarks or GPU acceleration. The 1.5 MiB default evidence-file limit is separate from preview display length and validation limits. Diagnostics retain up to 10 MB locally; missing or rotated records cannot establish that no failure occurred. |
| Connectivity | Document browsing and manual edits do not need a provider response. Chat requires a configured, available provider. Remote inference sends authorized context to that provider; offline CLI operation does not imply offline remote chat. |
Conflicts, retention, and recovery
Section titled “Conflicts, retention, and recovery”Unsaved text, prepared updates, saved documents, and accepted lifecycle evidence are distinct states. Application and undo check current revisions; intervening edits require a fresh review. Multi-document operations can report partial or uncertain outcomes. Preserve transaction evidence and reconcile the original operation before retrying an uncertain save.
Navigation can preserve a conversation and its unsent draft. A page reload does not promise restoration of unsaved editor or chat text. A restarted runtime has a new identity; reopen the current project and reestablish read scope. Retention is bounded, so expired history is not proof that an operation never occurred. See Project chat and planning updates for the complete context, save, undo, and reconnect procedures.
Qualification evidence
Section titled “Qualification evidence”Deterministic runtime, Chromium, and installed-archive fixtures use simulated provider transport. They verify application behavior, not live model quality, real authentication, or independent third-party certification. Provider connection testing establishes connectivity for that configured endpoint; it does not certify every model or workflow.
Maintainers can run the opt-in document-chat smoke with an explicitly selected model:
DAY_SHIFT_DOCUMENT_CHAT_CODEX_SMOKE=1 DAY_SHIFT_DOCUMENT_CHAT_CODEX_MODEL=your-model node --test tests_v2/acceptance/document-chat-codex-smoke.test.jsIt uses the configured executable and sign-in and edits a temporary specification. A skipped smoke is not live-provider certification. For whole-project qualification and optional calibration, see the project-chat guide.