Project chat and planning updates

Project conversations work without a planning or specification document. Every chat surface—Feedback, Delivery, standalone Chat, Project Brief, specifications and planning—starts with Whole project as its read context. Open the Context button beside Ask and Update to choose a narrower scope in a side sheet. Expand the project explorer and select folders recursively or individual documents across directories. Choices stay with the conversation while you fill out feedback, navigate or reload the page.

Choose Selected files and folders to start a specific selection. Selecting a folder includes its descendants, including new files; deselect individual descendants to exclude them. Whole-project selection can also have exclusions. A partially selected folder is marked with a mixed checkbox. Excluded folders own all descendants; include the parent again or start a specific selection to choose within it. Use arrow keys to move through the tree and Space to select. Escape or Done closes the sheet and returns focus to its trigger.

Sending a question allows the selected provider to retrieve relevant content within the displayed scope. Narrowed project conversations also exclude unrelated planning artifacts. The explorer lists filenames locally; it does not load every selected file into the message. Ignored/private files, provider policy and retrieval budgets still apply. Up to 4,096 independent included paths and exclusions can be represented; recursive folders and Whole project avoid a document-count limit on their descendants. Incomplete directory listings are labelled, and selecting the directory includes eligible descendants beyond the displayed list.

Context selection does not authorize edits. To update a planning document, use its separate Update target action in the explorer, then choose Update in chat. In planning and specification editors, the open document supplies the update target and remains included in the request. The same Context picker controls additional project access.

On Feedback, Prepare report context in chat stages a report, and Add feedback context to message adds its supplied text to your draft. Attached context shows the report title and version and can be removed. Report freshness is checked again before sending; stale context leaves the draft available for review. Adding report or delivery context does not select an update target. Creating follow-up work uses its separate preview and creation controls.

Ask or update

Choose Ask for questions, suggestions and design discussions. It leaves documents unchanged. Update from this answer copies an answer into an Update request for you to review and send.

Choose Update to prepare changes to the selected documents. Review the changed text and full updated documents in chat. Apply changes saves the reviewed content after checking the current revisions; Discard leaves the documents unchanged. Pending reviews survive reloads. If a document or your editor draft changes, prepare a new update from the current version.

A successful application shows Saved and verified and offers Undo update. A selected document group is reviewed and applied together. Older Ask/Suggest/Edit history and proposal review links remain readable.

Specification decisions and accepted deferrals

Specification review distinguishes unresolved decisions from resolved decisions and explicitly approved deferrals. Track them in the existing Open Questions section using the decision table below. A deferred value remains unanswered; its approved selection approach, owner, timing or dependency, rationale, and approval source explain why planning this scope can proceed before the value is selected.

## Open Questions

| ID | Status | Decision or question | Owner | Timing or dependency | Rationale | Approval source |
| --- | --- | --- | --- | --- | --- | --- |
| OQ-5 | deferred | Select and pin an exact supported stable framework release after compatibility checks; avoid prereleases and commit the lockfile. | Specification 2 | Implementation kickoff | Game rules do not depend on the exact version; version-specific work waits for selection. | Root specification, OQ-5: user approved selection at kickoff |
| OQ-8 | unresolved | Which hosting selection approach should apply? | Product owner | Before deployment planning | - | - |

Use stable, unique IDs and one of three statuses: unresolved, resolved, or deferred. Resolved rows need the adopted answer and its approval source. Deferred rows need all seven fields, including the full adopted selection approach and the rationale for planning before selection. An approval source identifies the actual user decision or source document and section; do not copy the example’s approval claim unless it describes your evidence. Unknown fields on unresolved rows may use -. A question without an approved answer or deferral remains unresolved.

The reviewer reports the decision ID and line requiring attention. Chat receives the same check for the current document or unsaved editor buffer when preparing an update. Existing prose and older tables remain readable, but ambiguous decision status continues to warn until an authorized refinement records the decisions in this format. Converting an existing approved deferral preserves its original approval; it does not require approving the same approach again. Keep supporting detail under the existing Scope or Constraints headings and preserve every unresolved choice in the register. Use None. only when there are no decisions left to track.

Saved and verified confirms a document update, not specification readiness. Draft feedback now reports remaining decision issues, and Review again checks the saved revision. A passing decision check does not authorize a planning-readiness disposition, create downstream work, or establish implementation or test completion. The checker validates recorded decision fields; it does not independently verify that an asserted approval source is truthful.

Ask about the actual parent

Select a phase and ask “Tell me about the parent overview.” The runtime resolves the registered parent identity and reads that document. Inspect Project context to see source paths, revisions and any exclusions. A source that is unavailable, stale or truncated cannot establish the missing requirements. Check the cited document before relying on an answer about those requirements.

Repository tools support directory listing, filename and text search, and file, section or line-range reads. Reads remain subject to the project workspace, ignore rules, disclosure policy and retrieval budgets. Source text is untrusted input; instructions embedded in a file cannot authorize new writes. The runtime rechecks disclosure and revisions during a turn. It does not automatically send the entire repository to a provider.

Use Context beside Ask and Update throughout the GUI to manage project read access. Choose Selected files and folders to browse the actual project locally, or Whole project to allow eligible content throughout the project. Browsing lists names without reading file bodies or sending them to the provider. The folder filter searches the current listing; incomplete listings are identified explicitly.

Folder selections are recursive and include new files. Exclusions take precedence within additional access. Review Selected paths and exclusions to remove a path or include an excluded path again. Exclusions do not revoke the open document or existing planning context in document chats. Ignore rules, private-path restrictions and the filesystem broker still apply.

Sending provides read-disclosure consent for the displayed scope to the selected provider for one hour. Changing context revokes the previous grant before applying the selection. Revoke analysis access withdraws the grant and clears the selection; choose context before sending again. Switching project, provider, model or runtime clears the active grant; another browser tab does not inherit it. The next message uses the displayed scope to create a fresh grant.

Local provider trust does not grant unrestricted access. Read access permits bounded evidence retrieval only: it does not authorize source edits, shell execution, validation, lifecycle acceptance, deployment or delivery actions.

Read coverage and citations

For an overview with many phases, the runtime can query the declared children and their recorded metadata without loading every body or unrelated history. A phase document larger than a read page remains accessible through bounded byte, section or line selections. Recorded status is not accepted completion: acceptance needs the corresponding reviewed evidence.

Open Project context beside the model picker for analysis progress, sources and follow-up actions. It distinguishes paths discovered from content selections actually supplied. A finished provider response does not imply exhaustive project coverage. Excluded, denied, stale and uninspected evidence remain visible. Inspect a citation to see its source and selection. A matching bounded preview proves only matching preview text; an unseen range or changed source has unknown freshness until revalidated.

A turn has finite provider-call, read, elapsed-time, context and retained-state budgets. The standard document agent permits 16 provider calls; the broader analysis loop also enforces its own ceilings. Useful additional reads can continue beyond the earlier eight-call boundary, but a budget stop remains partial evidence. Continue remaining analysis prepares a message for review; it does not send or expand permission automatically. Narrow the remaining question and submit it explicitly.

Both supported provider protocols use application-managed context compaction. Codex uses declared Day Shift tools and an ephemeral thread within each operation; the thread is never reused across separate chat requests. OpenAI-compatible providers request evidence through brokered JSON completions. Compacted notes preserve bounded source identities and excerpts, not proof that omitted material was read. Current authorization and revisions are checked again before retained evidence is supplied.

Consistent behavior across providers

Day Shift supplies the same versioned conversational contract for project chat, document chat and ordinary inference operations. It tells the model to answer the current question directly, retain supplied decisions and approvals, distinguish deferred choices from unresolved decisions, cite available evidence and respect the current request’s scope. Previous answers and source documents cannot grant new write authority. Document updates add rules for adopting recommendations, recording suggestions, preserving unrelated content and describing proposed changes.

Tool invocation and response encoding are separate from these behavioral rules. Codex receives Day Shift instructions at developer level while retaining its native base instructions; OpenAI-compatible providers receive them as a system message. Codex receives a response schema; compatible-provider JSON is requested in the prompt and checked by Day Shift. A shared contract standardizes Day Shift’s instructions, but does not guarantee identical answers from different models. Runtime scope checks, candidate validation and save controls remain authoritative.

Keep conversation and focus distinct

Use Chat mode to choose where a conversation belongs:

Page is the default on Project Brief, Specs, Planning, Feedback and Delivery. Each workspace keeps its own conversation. Navigating away backgrounds that chat and opens the destination workspace’s previous conversation or a fresh composer, without needing New conversation. Selecting another artifact within the same workspace keeps its page chat.
Global keeps the same conversation visible as you move between workspaces. Switching between Page and Global restores that mode’s conversation; it does not move or merge existing conversations.

Both modes keep requests running in the background. Returning to a workspace restores its chat and unsent draft during navigation. Use New conversation to run another chat on the same page. The header’s Chats list identifies each conversation’s owning workspace or Global mode; Open chat returns to that owner, and Stop cancels only the chosen request. Reloading the tab reconnects submitted requests and retains their ownership, but does not preserve unsent drafts.

Conversation history belongs to one project. History entries use the first message as their title, so conversations about feedback or general project questions remain identifiable without a planning artifact. Its operations retain their original target and revision identities when focus changes. Reconnecting to a restarted runtime requires its current identity; another project cannot inherit the prior project’s session authority.

Retired operation identities remain reserved to prevent redispatch. Deleting visible history is not permission to reuse an old operation ID. Preserve private conversation storage and transaction journals when diagnosing interrupted work; deleting those files can remove the evidence needed to reconcile a save.

Request a coordinated planning update

Choose Update and state the intended planning documents explicitly. For example, request alignment of a phase and its direct milestones, or a Structured overview and its direct tasks. Reading related files is separate from authorizing edits. Ambiguous scope needs clarification; creation of new children and lifecycle changes require their own explicit commands and authority.

The runtime freezes the resolved target set, prepares every candidate, validates artifact shape and cross-document consistency, and waits for you to review the complete group. Apply changes checks current revisions before saving the group together. Drafts show proposed text. A successful save requires confirmed runtime results, not an assistant sentence claiming it saved something.

Handle conflicts and incomplete operations

Keep unsaved editor text when a file changes on disk. Compare the current canonical version with the draft before selecting a replacement. A stale runtime identity or document revision must be refreshed before a new operation.

A verified rollback means the transaction restored its original contents. An incomplete transaction means recovery could not establish that result. Preserve its journal and inspect the affected files; do not retry blindly or describe the group as saved. Grouped undo checks every member against the saved versions and refuses intervening edits. It creates a compensating operation with its own identity.

Already-open editor and chat drafts remain mounted through disconnect and runtime restart. Connection warnings identify retained, potentially stale project data, and saving stays unavailable while verification is incomplete. Preserve or copy unsaved work before deliberately reloading the page: reconnect retention does not promise disk-persisted draft restoration.

Events tell connected clients to refresh canonical state. After a cursor gap or runtime restart, reconnect and reload snapshots instead of treating cached events as authoritative. An external rename or deletion can invalidate focus and draft targets.

Developer qualification

The project-chat acceptance fixture exercises the serving HTTP runtime and the Codex app-server transport with a deterministic provider. It records tool kinds, target identities and result statuses without logging credentials or source contents. The optional configured provider smoke uses DAY_SHIFT_PROJECT_CHAT_CODEX_SMOKE=1 and requires an explicit DAY_SHIFT_PROJECT_CHAT_CODEX_MODEL; normal tests require no credentials.

The maintained evidence matrix is in Structured work 41’s task 09 implementation summary. Deterministic provider transport tests do not establish real-model quality. Browser fixtures, installed delivery, platform coverage and performance bounds require their own recorded results. A skipped browser or configured-provider lane remains unqualified; do not infer a pass from component or service tests.

Whole-project qualification and optional calibration

The deterministic whole-project fixture exercises the built and extracted installed runtime and native browser with eight declared phases, a phase body above 100 KiB, at least 16 MB of unrelated history, and twelve useful content reads. It covers phase status, test coverage, architecture impact, contradictions and follow-up questions. Measurements distinguish physical analysis reads and directory traversal from unrelated GUI catalog work, and record provider inputs, retained state, memory and latency. Scripted transport results are integration evidence, not live-model reliability.

Run the credential-free calibration contract check from the repository root:

node tests_v2/acceptance/project-analysis-calibration.cjs --check

Live calibration is opt-in and may send the generated fixture to the configured provider:

DAY_SHIFT_PROJECT_ANALYSIS_CALIBRATE=1 node tests_v2/acceptance/project-analysis-calibration.cjs --protocol codex-app-server --model YOUR_MODEL --seeds 46,47 --repetitions 1

The JSON report records the exact model, protocol, settings, fixture seeds, repetitions, answer/citation/coverage scores, failures and untested models. Seeds control fixture data; provider sampling seeds are unsupported. This entrypoint does not calibrate OpenAI-compatible providers. An offline check, a scripted answer or a report for another model cannot establish the selected live model’s reliability. Keep failed and incomplete results visible.