Unified_Workspace_Library_Project_Proposal_R0_4.md
Current Specs/DOC26 UnifiedWorkspaceLibrary/Unified_Workspace_Library_Project_Proposal_R0_4.md
# Unified Workspace / Project Mode Control Surface Proposal R0.4
**Working title:** Unified Workspace / Library / Project Mode / Output Routing / Memory Continuity Proposal R0.4
**Recommended descriptive title:** Project Mode, Library Access, Output Routing, and Scope Control Surface Proposal R0.4
**Author:** Will Brody, ELNOR principal architect
**Drafted by:** ChatGPT, for Will's review
**Date:** 2026-05-25
**Status:** Proposal cleanup draft for review before DOC80 / Memory Control Plane flattening.
**Supersedes for discussion:** Unified Workspace / Library / Project Mode / Output Routing / Memory Continuity Proposal R0.3.
**Schema status:** **Non-final interface sketches only.** Final schemas, contracts, ledgers, and owner-doc insertions will be drafted through the DOC80 Memory Control Plane flatten-and-unify process.
---
## 0. Plain-language summary
R0.4 narrows the proposal into a **control-surface and operational-binding layer**. It does not attempt to settle the memory architecture. It makes scoped work visible, lets the user and system indicate what a surface is doing, binds useful folders/libraries/output targets, and emits safe signals to the memory and delivery systems.
The core sentence:
> **R0.4 emits intent and renders state. It does not compile model-facing context, govern memory, define canonical knowledge, or own task-run context.**
Project Mode is the human-facing way to say:
```text
This chat/tab/surface is currently working in this scope.
Use that fact as a signal for retrieval, capture aperture, folder/library handles, output routing, and user-visible state.
```
But the actual decisions about what to inject, what to learn, what to suppress, what to verify, and what becomes durable knowledge belong to the owner systems: DOC24 / KDA / DOC11 for delivery, DOC72 / DOC1 / DOC73 / DOC25 for knowledge and source handling, EC / PropA for writes and policy, and the future DOC80 Memory Control Plane for the final flattened contracts.
---
## 0.1 R0.4's main changes from R0.3
- **Reframes the document as a control-surface proposal.** R0.3 sounded like a workspace/memory architecture. R0.4 is explicitly the UI and operational signal layer over existing and future memory machinery.
- **Adds `ScopeRef` indirection.** R0.4 no longer keys itself directly to `project_entity_id` or to a not-yet-final DAMS `ScopeRoot`. It keys off an opaque EC-owned `scope_ref` that can resolve today to a DOC72 entity and later to a DOC80 / ScopeIdentityRoot-style object.
- **Makes the proposal DAMS-shaped but not DAMS-dependent.** It is compatible with the DAMS / Memory Control Plane direction, but it does not require any unfinished DAMS primitive to exist.
- **Fixes capture policy.** Project Mode raises capture aperture, candidate priority, and evidence preservation; it does not bypass significance gating, DOC1 Write Gate, policy, or write-quality controls.
- **Fixes auto-link.** Auto-link now enters `provisional_auto` first. Visual chrome can appear and retrieval can use the scope as a hint, but durable scope tagging and elevated capture wait for confirmation or undo-window expiry.
- **Fixes paused mode.** Paused mode retains visible project handles and folder/library access handles, but does not inject project state by default.
- **Splits background instructions.** User-authored **Project Instructions** are separate from system-generated **Project State Cards**. State cards are orientation-only, source-backed, validity-bounded, and rendered by DOC24 / future Context Compiler, not by this proposal.
- **Fixes Library statuses.** User vocabulary remains **Linked / Indexed / Learned**, but internal state is multi-axis: link state, index state, learning state, corpus membership, and access policy. Indexed is not a memory lane. Learned intentionally invokes DOC73/PBE-style Library/corpus extraction.
- **Fixes carryover export.** External carryover is an egress event requiring policy, redaction, review, visibility summary, and export receipt.
- **Softens `memory.consolidate_now`.** It bypasses scheduling latency only; it does not bypass significance, policy, or Write Gate.
- **Removes R0.2 leftovers.** `work_thread_id` and “active Working Set state” are removed from this proposal's command sketches.
- **Keeps DOC23 boundary.** R0.4 exposes adjacent objects and signals, but DOC23 owns task-run scope, task context assembly, task memory, task handoff format, task output governance, and Run Inspector semantics.
---
## 0.2 What R0.4 keeps from R0.3
R0.3 was directionally right about the product problem. R0.4 preserves the useful parts:
- explicit Project Mode as a deliberate, visible scoped-work state;
- no global focus mode;
- per-surface activation;
- visual chrome: project button, tab indicators, chat-input scope indicator, project menus;
- EC operational state rather than DOC72 memory ownership;
- persistent tabs / surface participation;
- user-facing Library wrapper over DOC7/DOC25/DOC73 source machinery;
- Linked / Indexed / Learned vocabulary;
- Folder Bindings;
- Source Folder Affinity;
- Work Products as output tracking;
- output routing precedence with current user instruction at the top;
- carryover generation as a useful command;
- the commitment that Project Mode is optional and memory must still work in default mode.
---
## 0.3 What R0.4 is
R0.4 is a proposal for:
- Project Mode as a user-visible control surface;
- per-surface scope activation;
- scope-state visual indicators;
- folder, library, agent, and output operational bindings;
- safe auto-link behavior;
- persistent tabs and project participation records;
- Library source preparation UI using Linked / Indexed / Learned;
- output-routing UX and policy hints;
- Work Product UI/read-model integration;
- carryover generation as a controlled export/render request;
- memory-consolidation commands as signals into owner pipelines;
- event/signal shapes that the flattened Memory Control Plane can consume later.
R0.4 is intentionally near the user. It answers:
```text
What does the user see?
What can the user click?
What state changes happen when they click?
What signals are emitted?
What owner system must consume those signals?
What should never be silently assumed?
```
---
## 0.4 What R0.4 is not
R0.4 does **not**:
- define final schemas or durable contracts;
- define the DOC80 Memory Control Plane;
- define the final canonical memory object model;
- define ScopeIdentityRoot / ScopeRoot internals;
- define WorkEpisode schema;
- define CognitiveDiff schema;
- define Context Compiler internals;
- define DAMS attenuator math;
- define DOC23 task-run scope envelope or task context;
- define DOC73 corpus extraction internals;
- define DOC25 ingestion internals;
- define DOC72 graph payload shapes;
- define DOC1 memory-governance rules;
- create a second memory store;
- create a global focus mode;
- make Projects mandatory for good memory.
If R0.4 appears to make one of those decisions, read it as an error or as an explicitly non-final sketch to be resolved in the flattening process.
---
## 0.5 Relationship to DOC80 / Memory Control Plane flattening
The DOC80 flatten-and-unify plan will draft the final schemas and contracts. R0.4 is a cleanup and positioning proposal to make the Project/Library/Output/Carryover layer ready to be consumed by that process.
The intended relationship is:
```text
R0.4
= user-facing control surface + operational bindings + signal emitter.
DOC80 Memory Control Plane
= canonical memory objects, source/evidence, policy/scope coordination,
extraction, runtime context products, delivery proof, learning, and final contracts.
```
R0.4 should be included in the DOC80 source-freeze corpus as an **accepted-directionally control-surface proposal** unless the architect later assigns a different source status. Its useful concepts should be preserved, but its schema sketches should not be treated as final normative contracts.
---
## 0.6 DAMS-shaped, not DAMS-dependent
The memory rebuild materials point toward a larger Memory Control Plane with source/evidence handling, canonical Assertion resolution, scope coordination, working-state memory, runtime context products, and delivery proof. R0.4 should align with that direction without depending on unfinished primitives.
R0.4 therefore uses this posture:
```text
- Use ScopeRef, not hard ScopeRoot columns.
- Emit scope-control events, but do not define WorkEpisode.
- Render Project State Cards, but do not define the Context Compiler.
- Emit learning signals, but do not define the Learning Engine.
- Request carryover/context products, but do not assemble the final prompt.
```
This allows R0.4 to work today with DOC72/DOC24/DOC25/DOC7/DOC73 and to remain compatible if DOC80 later adopts ScopeIdentityRoot, WorkEpisode, Context Compiler, CognitiveDiff, or related constructs.
---
## 0.7 Core memory distinctions R0.4 must preserve
R0.4 uses the following distinctions from the memory-control work:
```text
Source
= where information came from.
Route
= why/how Elnor looked for or captured it.
Canonical object
= what kind of knowledge was produced.
Organization
= how the user/system groups, browses, searches, or manages it.
Delivery
= how DOC24/KDA/DOC11 expose it to the model.
```
Project Mode, Library activation, task output, chat capture, or carryover are **routes and organizational/control signals**. They must not determine canonical knowledge identity. A truth-apt statement extracted through Project Mode must resolve through the same canonical memory pipeline as the same statement extracted through a Library, Topic, chat, task output, or manual user teaching.
---
## 0.8 Major concepts and naming
| Concept | User-facing name | Internal / owner posture | Purpose |
|---|---|---|---|
| Project Mode | Project Mode / Project | R0.4 control surface over `scope_ref` | Makes scoped work visible and operational on a surface. |
| ScopeRef | Not usually shown | EC-owned opaque handle | Avoids hard dependency on raw DOC72 entity or future ScopeIdentityRoot. |
| Library | Library | DOC7/DOC25/DOC73 source wrapper | Source access, document intelligence, optional learning. |
| Linked | Linked | link state / source binding | Elnor can access/open/read/scan on demand. |
| Indexed | Indexed | DOC25 document intelligence ready | Elnor can retrieve by content, summarize, compare, cite, version-link. Not memory. |
| Learned | Learned | DOC73/PBE extraction state | Elnor intentionally extracts governed reusable knowledge from source contents. |
| Folder Binding | Folder Binding | EC operational binding | A folder can be a source, output destination, or both. |
| Work Product | Work Product | DOC72 work_product + EC/UI read-model | Output Elnor creates/edits/tracks, with internal and external refs. |
| Project Instructions | Project Instructions | user-authored operational guidance | Stable user instructions for a Project Mode scope. |
| Project State Card | Project State / State Card | DOC24/future compiler product rendered by R0.4 | Source-backed orientation, not evidence. |
| Persistent Tab | Project Tab / persistent tab | EC surface participation read-model | Keeps relevant chats/docs/notes/surfaces findable in a project. |
| Carryover | Generate Carryover | export/render request | Produces controlled continuation/export packets. |
| Memory Consolidate Now | Consolidate Memory Now | immediate pipeline request | Runs owner pipeline now; does not bypass governance. |
---
## 0.9 Governing principles
1. **Visible beats hidden.** The user should be able to tell what scope a surface is using without inspecting a transcript.
2. **Automatic beats manual, but only when inspectable.** Elnor may infer and auto-link, but the inferred state must be visible, explainable, undoable, and initially provisional.
3. **Surface-local beats global.** Project Mode applies to a surface, not all of Elnor.
4. **User instruction wins.** The current user instruction in the active turn beats project defaults, folder affinity, saved output policy, assistant defaults, and prior inferred behavior.
5. **Source access is not memory.** Linked and Indexed sources may be opened/searched/retrieved, but indexing does not itself create durable memory.
6. **Learning remains governed.** Learned Libraries intentionally invoke DOC73/PBE extraction, but DOC72/DOC1/EC governance still controls durable knowledge.
7. **Orientation is not evidence.** Project State Cards, continuity summaries, carryovers, and recent activity cards may orient a model; they do not satisfy evidence or authority queries.
8. **No phantom controls.** Every visible button/chip/menu must map to an EC command, route, no-op/degraded receipt, telemetry event, and refreshed read-model.
9. **No duplicate truth.** R0.4 operational state is not a new memory store.
10. **Policy-before-flow.** Export, carryover, retrieval, rendering, indexing, learning, and delegation use the relevant compiled policy decision where required.
11. **Final-prompt truth remains downstream.** DOC24/KDA may assemble/render; DOC11/OpenClaw owns final runtime truth.
12. **Default mode must work.** Projects improve the UX and scoping signals but are not required for high-quality memory, routing, or document access.
---
## 1. Owner split
R0.4 should carry a clear owner split to prevent drift.
| Owner | R0.4 consumption / obligation | R0.4 must not take over |
|---|---|---|
| DOC20/Q | Visual chrome, Project Mode button, tab indicators, inspectors, menus, Library/Output views | durable truth, policy decisions, memory writes |
| EC | operational state, commands, ScopeRef resolver, command closure, receipts, effective state, policy enforcement hooks | canonical knowledge schemas, final prompt assembly |
| DOC24 | packet lifecycle, context product selection/injection, manifests, Project State Card delivery, carryover rendering path where applicable | durable knowledge shape, policy internals, KDA rendering internals |
| KDA | deterministic rendering from prepared products | selection/retrieval/memory ownership |
| DOC11/OpenClaw | final runtime truth, folder/file tool execution, agent runtime behavior | R0.4 UI state |
| DOC72 | knowledge graph shape, entities, work_product payloads, memory directives, procedures, graph hygiene | Project Mode UI/operational state |
| DOC25 | source artifacts, document intelligence, parsing/materialization, indexing status | canonical truth and Project Mode state |
| DOC7 | lightweight bucket/source refs and materialization | deep corpus learning or Project Mode UI |
| DOC73 | corpus/Library extraction, CUs/source-bound synthesis, RecentActivityRollup consumer surfaces | Project Mode state or source-index UI |
| DOC1 | memory governance and Write Gate | Project Mode operational command semantics |
| PropA / EC policy | visibility, export, redaction, egress, exposure policy | UI rendering by itself |
| DOC8 / BDSM / future Learning Engine | utility learning and signal attribution, once final | truth, policy, memory governance |
| DOC23 | task execution, task scope envelopes, task context, task memory, task output governance | R0.4 must not define task-run internals |
| DOC80 Memory Control Plane | final memory contracts, flattening, owner reconciliation | R0.4 interim sketches should not preempt final contracts |
---
## 2. ScopeRef indirection
### 2.1 Why ScopeRef exists
R0.3 keyed most operational state off `project_entity_id`. The memory rebuild materials identify the risk of multiple references to the same underlying scope: an entity, a Library/corpus, a project tag, a Topic, and recent work/episode records may all describe the same working context. If each becomes a separate scoring/membership anchor, the system can double-count, triple-count, or treat equivalent scopes as unrelated.
The future Memory Control Plane may solve this with a canonical scope root. R0.4 should not wait for that primitive or hard-code it. Instead, R0.4 introduces an opaque handle:
```text
ScopeRef = the EC-owned handle R0.4 uses for scoped operational state.
```
Today, `scope_ref` may resolve to an existing DOC72 entity. Later, the same `scope_ref` may resolve to a DOC80 `ScopeIdentityRoot` or equivalent. R0.4 tables do not need migration.
### 2.2 Interface sketch, not final contract
```ts
// Non-final sketch. DOC80/EC will draft final resolver contracts.
type ScopeRef = string;
type ScopeRefResolution = {
scope_ref: ScopeRef;
resolves_to:
| { kind: "doc72_entity"; entity_id: string }
| { kind: "memory_control_scope_root"; scope_root_id: string };
resolved_at: string;
resolution_status: "active" | "stale" | "ambiguous" | "retired";
schema_version: 1;
};
type ScopeDisplayBinding = {
scope_ref: ScopeRef;
display_entity_id?: string; // denormalized convenience only
display_label: string;
display_kind:
| "project"
| "engagement"
| "research_topic"
| "initiative"
| "client"
| "workflow"
| "other";
source: "doc72_entity" | "user_named" | "system_generated";
schema_version: 1;
};
```
### 2.3 Rules
- R0.4 operational records use `scope_ref` as the canonical R0.4 scope handle.
- R0.4 may cache `display_entity_id` and `display_label` for UI/debugging.
- R0.4 does not define the future scope-root object.
- ScopeRef resolution is EC-owned.
- If ScopeRef resolution is ambiguous, R0.4 must show ambiguity or degrade to default mode; it must not act as if uncertainty is same-scope.
- A Project Mode surface can exist with no future ScopeRoot. It only needs a valid current ScopeRef resolution.
---
## 3. Project Mode as control surface
### 3.1 What Project Mode is for
Project Mode solves a UX and control problem:
```text
The user often works across multiple scoped bodies of work.
Elnor needs to know which scope this surface is probably serving.
The user needs to see that state and override it quickly.
```
Project Mode does not make projects mandatory. It provides a deliberate, visible surface state when scoped work matters.
### 3.2 What Project Mode changes
When a surface is in confirmed Project Mode, R0.4 emits signals:
- retrieval bias hint;
- capture aperture hint;
- eligible Project State Card hint;
- Library/folder handles available for retrieval;
- output routing hints;
- persistent tab participation;
- learning/utility signals from accept/reject/undo behavior.
The owner systems decide downstream effects. For example:
- DOC24 decides whether a Project State Card is included in the packet.
- DOC72/DOC1 decide whether observed content becomes memory.
- DOC73 decides whether Library/corpus learning happens.
- DOC25 decides whether documents are indexed/materialized.
- PropA/EC decide whether access, render, export, or learning is allowed.
### 3.3 Project Mode state machine
R0.4 uses five visible/effective states:
```text
default
suggested
provisional_auto
confirmed_active
paused
exited
```
The important change from R0.3 is `provisional_auto`.
```text
DEFAULT
→ user_selected → CONFIRMED_ACTIVE
→ auto_inferred → PROVISIONAL_AUTO
→ low_confidence_inferred → SUGGESTED
SUGGESTED
→ user_accepts → CONFIRMED_ACTIVE
→ user_rejects → DEFAULT
PROVISIONAL_AUTO
→ undo_window_expires → CONFIRMED_ACTIVE
→ user_confirms_by_action → CONFIRMED_ACTIVE
→ user_undoes → DEFAULT
CONFIRMED_ACTIVE
→ pause → PAUSED
→ exit → DEFAULT/EXITED
→ switch → CONFIRMED_ACTIVE for new scope
PAUSED
→ resume → CONFIRMED_ACTIVE
→ exit → DEFAULT/EXITED
```
### 3.4 Interface sketch
```ts
// Non-final sketch. EC/DOC20/DOC80 will draft final contracts.
type ProjectModeState =
| "default"
| "suggested"
| "provisional_auto"
| "confirmed_active"
| "paused"
| "exited";
type SurfaceKind =
| "chat"
| "workspace_tab"
| "document_viewer"
| "note"
| "browser_panel"
| "split_pane"
| "floating_palette"
| "external_client";
type ScopeActivation = {
activation_id: string;
scope_ref?: ScopeRef;
surface_id: string;
surface_kind: SurfaceKind;
principal_id: string;
mode_state: ProjectModeState;
activation_source:
| "user_selected"
| "auto_link"
| "workspace_restore"
| "opened_scope_artifact"
| "explicit_resume"
| "system_suggestion";
capture_aperture_hint: "default" | "raised" | "paused";
retrieval_bias_hint: "none" | "handle_only" | "boosted";
injection_hint: "none" | "eligible_for_project_state_card";
provisional_until?: string;
undo_available_until?: string;
durable_scope_tagging_committed_at?: string;
created_at: string;
updated_at: string;
schema_version: 1;
};
```
The fields are intentionally described as hints. R0.4 does not make final injection or memory decisions.
---
## 4. Visual signal layer
### 4.1 Product goal
The user should know at a glance whether a surface is scoped to a project-like body of work. The visual layer should be clear enough to avoid ambiguity, but quiet enough not to become a project-management burden.
### 4.2 Core affordances
R0.4 keeps R0.3's visual chrome:
- a persistent Project Mode button;
- a project/scope indicator inside the chat input;
- tab indicators for project-affiliated tabs;
- right-click tab menu for add/remove/move scope affiliation;
- project menu with pause/resume/switch/exit/settings;
- one-time onboarding tooltip for auto-link behavior;
- short pulse animation for auto-link state changes.
### 4.3 Suggested button states
```text
DEFAULT:
[+ Start project]
SUGGESTED:
[? Continue Product Launch?]
PROVISIONAL_AUTO:
[● Product Launch ▶] with subtle pulse and undo menu item
CONFIRMED_ACTIVE:
[● Product Launch ▶]
PAUSED:
[● Product Launch ⏸]
```
### 4.4 Menu rules
The menu must always answer:
```text
What scope is active on this surface?
How was it activated?
Can I undo it?
Can I pause it?
Can I switch it?
Can I inspect why Elnor inferred it?
What folders/libraries/output targets are bound?
```
Auto-link explanation should be visible:
```text
Why Elnor linked this surface:
- Opened source file from Product Launch folder.
- Mentioned Product Launch twice.
- Reopened Launch_Plan_v3 work product.
- Prior chat from yesterday had same source set.
Confidence: 0.88.
```
This inspection is essential. Without it, auto-link becomes spooky.
---
## 5. Provisional auto-link
### 5.1 Why provisional auto-link exists
Automatic linking is necessary because the user will not reliably create or select a Project every time. But immediate durable effects are dangerous. R0.4 therefore separates visual/inference behavior from durable tagging and elevated capture.
### 5.2 Behavior
When auto-link confidence crosses threshold:
1. Surface enters `provisional_auto`.
2. Visual chrome appears.
3. Retrieval may use the inferred scope as a weak hint.
4. No durable project tagging occurs yet.
5. No elevated capture aperture occurs yet.
6. A prominent undo item appears for a short window.
7. If the user confirms by action or the undo window expires, state becomes `confirmed_active`.
8. If the user undoes, state returns to default and provisional evidence is handled by default-mode rules.
### 5.3 Confirmation events
Examples of confirmation:
- user sends a clearly in-scope follow-up;
- user opens a project-linked artifact;
- user clicks “yes / continue / confirm”;
- user explicitly saves output to a scope-bound output target;
- undo window expires without rejection, if the policy allows passive confirmation.
### 5.4 Rejection events
Examples of rejection:
- user clicks undo;
- user says “this is not Product Launch”;
- user switches to another scope;
- user pauses and asks unrelated questions repeatedly;
- policy/visibility indicates the inferred scope should not attach.
### 5.5 Learning signal
Accept/reject/undo events emit learning signals. The current proposal does not define the learning engine. It only requires the signal to be available.
```ts
// Non-final sketch.
type ScopeInferenceFeedbackSignal = {
signal_id: string;
scope_ref?: ScopeRef;
surface_id: string;
principal_id: string;
inference_confidence: number;
signals_used: string[];
outcome:
| "accepted_by_user"
| "confirmed_by_behavior"
| "undone_by_user"
| "rejected_by_user"
| "timed_out_to_confirmed"
| "suppressed_by_policy";
created_at: string;
schema_version: 1;
};
```
---
## 6. Paused mode
### 6.1 Product purpose
Paused mode exists for the common case:
```text
I am generally in this project, but this next question should not be captured or interpreted as project work.
```
### 6.2 Correct R0.4 behavior
Paused mode:
- keeps visual chrome visible;
- keeps Library/folder handles available;
- keeps output targets visible but not default-dominant;
- returns capture aperture to default;
- suppresses project-state card injection by default;
- allows explicit project retrieval if the user references the project;
- does not create new persistent tabs unless user reactivates or explicitly attaches.
### 6.3 What paused mode does not do
Paused mode does not:
- keep injecting project background automatically;
- tag all new turns to the project;
- keep elevated memory capture active;
- silently treat unrelated questions as project-related.
### 6.4 Policy sketch
```ts
// Non-final sketch.
type PausedModePolicy = {
retain_folder_grants: boolean; // default true
retain_library_handles: boolean; // default true
inject_project_state_by_default: false;
allow_project_retrieval_on_explicit_reference: true;
capture_aperture_hint: "default";
retrieval_bias_hint: "handle_only";
schema_version: 1;
};
```
---
## 7. Project Instructions and Project State Cards
### 7.1 Why R0.3 needed correction
R0.3 used “Elnor-maintained background instructions” as a prose block. That was risky because it mixed stable user-authored instructions with generated state summaries. A stale generated summary could be injected like truth. It could bloat context. It could become mistaken for evidence.
R0.4 splits the concept.
### 7.2 Project Instructions
Project Instructions are user-authored guidance for the scope. They may include strict instructions and softer working preferences.
Examples:
```text
- Use concise, direct style for drafts in this project.
- Prefer source-backed answers when discussing documents.
- Do not save exploratory drafts to external shared folders unless I ask.
```
Project Instructions are stable and editable by the user. They should have a token cap and a strict/soft distinction.
```ts
// Non-final sketch.
type ProjectInstructions = {
scope_ref: ScopeRef;
strict_instructions: string;
soft_guidance?: string;
max_tokens: number;
updated_by: "user" | "principal_delegate";
updated_at: string;
schema_version: 1;
};
```
### 7.3 Project State Card
A Project State Card is a generated orientation product. R0.4 does not compile it; DOC24 or the future Memory Control Plane compiler does. R0.4 renders it, requests it, and shows its inclusion/exclusion in the inspector.
A Project State Card should be:
- source-backed;
- generated from owner records;
- validity-bounded;
- orientation-only;
- small;
- inspectable;
- not evidence;
- not a durable memory by itself.
```ts
// Non-final sketch. Final card products belong to DOC24/DOC80.
type ProjectStateCard = {
card_id: string;
scope_ref: ScopeRef;
state_of_play: string;
open_loops: string[];
recent_decisions: Array<{
text: string;
source_ref: string;
decided_at: string;
}>;
generated_from_refs: string[];
generated_at: string;
stale_after: string;
warrant: "orientation_only";
evidence_status: "framing_only";
injection_policy_hint: {
inject_when: "confirmed_active" | "explicit_reference" | "resume_only";
max_tokens: number;
};
schema_version: 1;
};
```
### 7.4 Injection rule
Project State Cards are **eligible** when a surface is confirmed-active. Eligibility is not injection. DOC24 / future Context Compiler decides whether to include the card, how much to include, and how to render it.
Paused mode suppresses default injection unless the user explicitly references the project or asks to use project context.
### 7.5 Inspector rule
If a Project State Card is injected, the user must be able to inspect:
```text
- what card was included;
- why it was included;
- what sources generated it;
- when it was generated;
- when it becomes stale;
- what was available but not injected;
- what was blocked by policy or visibility.
```
---
## 8. Persistent tabs and surface participation
### 8.1 Product purpose
Persistent tabs solve a concrete problem: when scoped work spans chats, notes, documents, browser pages, and panels, the user needs to find the surfaces that mattered without manually organizing them.
R0.4 keeps persistent tabs, but frames them as **surface participation records**, not memory.
### 8.2 What gets recorded
Examples:
- chats opened during confirmed Project Mode;
- documents viewed long enough to matter;
- notes edited while confirmed-active;
- Work Products created or revised;
- relevant Library pages or document viewers;
- outputs saved under the scope;
- browser/document surfaces explicitly attached by the user.
### 8.3 What persistent tabs are not
Persistent tabs are not:
- durable memory;
- evidence of truth;
- a second transcript store;
- a task scope envelope;
- a guarantee that content should be injected.
They are a UI/read-model and a signal for owner systems.
### 8.4 Interface sketch
```ts
// Non-final sketch.
type PersistentSurfaceParticipation = {
participation_id: string;
scope_ref: ScopeRef;
principal_id: string;
surface_id: string;
surface_kind: SurfaceKind;
content_ref?: string;
title: string;
participation_basis:
| "confirmed_project_mode"
| "user_attached"
| "dwell_threshold"
| "work_product_created"
| "source_document_used"
| "output_saved";
first_seen_at: string;
last_seen_at: string;
dwell_seconds?: number;
status: "active" | "archived" | "removed" | "tombstoned";
schema_version: 1;
};
```
### 8.5 Deletion rule
Do not hard-delete persistent tabs when a Project Mode config is deleted or archived. Tombstone them. They may still be valuable audit/read-model history, and underlying content belongs to its owner store.
---
## 9. Capture aperture and memory posture
### 9.1 R0.3 problem
R0.3 said project-mode surfaces could be “captured unconditionally” and bypass default significance gating. R0.4 removes that.
### 9.2 Correct rule
Project Mode changes the **aperture**, not the governance.
```text
Confirmed Project Mode may:
- preserve source evidence more reliably;
- queue more observations for intake;
- raise candidate priority;
- attach stronger scope signals;
- create clearer provenance and participation records.
Confirmed Project Mode may not:
- bypass significance gating;
- bypass DOC1 Write Gate;
- bypass PropA/EC policy;
- auto-deep-extract everything;
- create a separate project memory store;
- silo memory to the project by default.
```
### 9.3 Intake effect as hints
```ts
// Non-final sketch.
type CaptureApertureSignal = {
signal_id: string;
scope_ref?: ScopeRef;
surface_id: string;
principal_id: string;
aperture_hint: "default" | "raised" | "paused";
priority_hint: "normal" | "elevated";
evidence_preservation_hint: "standard" | "preserve_more";
basis: "confirmed_project_mode" | "user_command" | "auto_link_provisional" | "paused";
created_at: string;
schema_version: 1;
};
```
### 9.4 Default mode remains first-class
Memory must work when no project is active. Default-mode capture still uses ordinary entity resolution, recent episodes/summaries, user directives, Libraries invoked by name, Topics, active documents, and normal graph retrieval. Project Mode is an additive signal.
---
## 10. Library access: Linked / Indexed / Learned
### 10.1 Product purpose
Library is the user-facing wrapper for source collections. It lets the user say:
```text
Look in my Product Docs library.
Use the Drafts library.
Add this source folder to the Research library.
Learn from this library.
```
The Library UI should be simple. The underlying owner machinery may be DOC7 buckets, DOC25 document intelligence, DOC73 corpus extraction, and DOC72/DOC1 governed memory.
### 10.2 User-facing statuses
R0.4 keeps the user vocabulary:
```text
Linked
Indexed
Learned
```
These are not mutually exclusive levels. They are additive states for files/folders/sources.
```text
Linked
= Elnor has a link/reference and can open, read, scan, or convert the source when asked.
Indexed
= Elnor has prepared document intelligence for reliable content retrieval and document use.
Learned
= Elnor has intentionally run or queued Library/corpus-style knowledge extraction.
```
### 10.3 Linked
Linked means:
- source binding exists;
- file/folder/provider ref is known;
- basic metadata may exist;
- Elnor can open/read/scan/convert on demand if policy and access allow;
- the source can be found by name/path/Library/source relationship;
- no proactive full indexing is guaranteed;
- no content-based retrieval is guaranteed except live scan/on-demand read.
Linked is useful for:
- fast setup;
- huge folders;
- sensitive folders;
- temporary material;
- output folders;
- uncertain material;
- sources that may only need occasional opening.
Linked does **not** mean “unusable.” It means “not proactively prepared.”
### 10.4 Indexed
Indexed means:
- DOC25-style document intelligence exists or is being prepared;
- text/OCR/conversion may exist;
- page/section/chunk maps may exist;
- summaries/source maps may exist;
- content retrieval is faster and more reliable;
- document identity/version/dedup status may be stronger;
- DOC72 intake has better source material if existing DOC72 rules decide extraction is warranted.
Indexed is useful when the user wants:
- content-based document finding;
- reliable “find the file that discussed X” behavior;
- summarization and comparison;
- citations/source spans;
- version comparisons;
- repeated use across sessions.
Indexed does **not** mean:
- all contents are memory;
- all entities/concepts are promoted;
- DOC73 deep extraction has run;
- DOC72 significance/Write Gate is bypassed;
- Learned status exists.
### 10.5 Learned
Learned means:
- a Library/corpus-scoped extraction process has intentionally run or is queued;
- source contents may produce governed reusable knowledge candidates;
- DOC73/PBE-style extraction, trust posture, review settings, and corpus membership may apply;
- outputs may include AssertionCandidates, CUs/source-bound synthesis, directives/procedure candidates, entity updates, evidence records, or other owner-approved objects once the final DOC80 taxonomy lands.
Learned is useful for:
- durable reference bodies;
- long-term project sources;
- manuals/playbooks/templates/research collections;
- sources whose internal knowledge should shape future reasoning;
- source sets worth review and re-extraction.
Learned does not create a separate brain and does not bypass governance.
### 10.6 Critical boundary sentence
R0.4 should preserve this sentence:
> **Learned is the only Library status that intentionally invokes corpus-scoped DOC73/PBE extraction. Normal DOC72 intake may still create durable knowledge from any source when DOC72's existing significance, provenance, and Write Gate rules warrant it. Indexed provides better document intelligence to those owner pipelines; it is not a separate memory lane.**
### 10.7 Internal axes
R0.3 collapsed too many things into one status. R0.4 separates the axes.
```ts
// Non-final sketch. Final contracts belong to DOC80 / DOC7 / DOC25 / DOC73 / EC.
type LibrarySourcePreparation = {
library_id: string;
source_ref: string;
link_state:
| "linked"
| "link_broken"
| "permission_missing"
| "removed";
index_state:
| "not_indexed"
| "queued"
| "indexing"
| "indexed_ready"
| "index_stale"
| "index_failed";
learning_state:
| "not_learned"
| "learning_queued"
| "learning_in_progress"
| "learned_candidates_created"
| "learned_committed"
| "learning_failed"
| "excluded_from_learning";
corpus_membership?: {
corpus_id: string;
corpus_mode: "shell" | "full" | "research_event";
membership_state: "candidate" | "active" | "archived";
};
access_policy: {
visibility_class:
| "ambient"
| "scoped"
| "explicit_only"
| "firewalled"
| "sealed";
indexing_allowed: boolean;
learning_allowed: boolean;
egress_allowed: boolean;
};
schema_version: 1;
};
```
### 10.8 Important correction: corpus mode is not learning state
A DOC73 corpus/library shell can exist without the source being Learned. Shell means identity/access-path/minimal extraction. Learned means a learning/extraction process has created or is creating governed knowledge candidates.
### 10.9 Mixed status within one Library
A single Library may have mixed source states:
```text
Product Launch Library
- Source Docs folder: Indexed
- Final Strategy references: Learned
- Drafts folder: Linked, excluded from learning
- Archive: Linked
- Large PDFs: Linked + prepare large PDF on first use
```
This should be normal, not an advanced edge case.
### 10.10 Large PDF / reliable reading option
Large-document preparation should be cross-cutting. A Linked source can still have a selected file converted for reliable reading on first use. That is not the same as indexing the whole Library or learning from its contents.
User-facing option:
```text
[ ] Prepare large PDFs for reliable reading when first used
```
### 10.11 Library UI
A simple Library inspector should show:
```text
Library: Product Docs
Sources
- Product Docs folder — Indexed, watched
- Drafts folder — Linked, excluded from learning
- Final References — Learned
Counts
- 382 linked
- 119 indexed
- 23 learned
- 8 need OCR
- 4 changed since last indexing
Settings
[ ] Keep linked folders updated
[ ] Index new files automatically
[ ] Learn from selected folders
[ ] Review learned knowledge before saving
[ ] Exclude outputs/drafts from learning
[ ] Prepare large PDFs on first use
[ ] Firewalled
```
---
## 11. Library activation and automatic use
### 11.1 Product goal
The user should not have to click ten things to make Libraries useful. Libraries should become available through several natural paths:
- user explicitly invokes by name;
- Project Mode has default Libraries;
- user opens a source/work product linked to a Library;
- auto-link infers the scope and its Libraries;
- Workspace restore reopens a surface with Library handles;
- output/source-folder affinity points to a Library source;
- a DOC24/DOC80 retrieval process asks for a Library notice/source slice.
### 11.2 Activation does not mean injection
Activating a Library usually means:
```text
The model knows the Library exists and can be searched/read on demand.
```
It does not mean:
```text
All Library contents are injected.
```
### 11.3 Handle-first behavior
Default chat packet should receive compact handles/notices, not documents:
```text
Available library: Product Docs
Status: 119 indexed docs, 23 learned items, firewalled=false.
Use source retrieval when needed. Do not assume unseen contents.
```
DOC24/DOC80 decides final context-product rendering.
### 11.4 Explicit invocation examples
```text
Look in the Dog Library.
Use the Product Docs library for this answer.
Search the Drafts library for the latest version.
Learn from this folder in the Product Docs library.
Do not use the Archive library in this chat.
```
These should map to real commands or retrieval routes, or return a no-op/degraded receipt.
---
## 12. Folder Bindings
### 12.1 Product purpose
A folder can play different roles:
```text
source folder
output destination
both source and output
watch folder
manual-only folder
```
The folder itself is not the Library. It is a source or destination binding attached to a Library, Project Mode scope, Work Product policy, or other owner object.
### 12.2 Role model
```ts
// Non-final sketch.
type FolderBinding = {
folder_binding_id: string;
folder_ref: string;
scope_ref?: ScopeRef;
library_id?: string;
roles: Array<
| "library_source"
| "output_destination"
| "source_and_output"
| "watch_folder"
| "manual_reference"
>;
read_policy: "no_read" | "read_on_demand" | "index_allowed";
write_policy: "no_write" | "ask_before_write" | "write_allowed";
overwrite_policy: "never_without_confirm" | "explicit_turn_only";
delete_policy: "never_without_confirm";
created_at: string;
updated_at: string;
schema_version: 1;
};
```
### 12.3 Role separation
Source folder and output folder are often the same physical folder, but they are distinct roles. The same folder can be bound in both roles, but the policy must be explicit.
---
## 13. Work Products and output routing
### 13.1 Product purpose
Libraries handle what Elnor reads/searches/learns from. Work Products handle what Elnor creates, edits, exports, or tracks.
Work Products are necessary because a generated output may be:
- saved internally only;
- saved next to a source file;
- saved to an external shared folder;
- exported once;
- revised multiple times;
- linked to a Project Mode scope;
- later added to a Library as source material;
- produced by a DOC23 task;
- not safe to learn from automatically.
### 13.2 Hybrid object
A Work Product is not merely a file and not merely a view. It is a durable output object with references.
It should generally have:
- internal artifact/version reference;
- optional external file refs;
- source refs;
- scope refs;
- creator/agent refs;
- output target used;
- status;
- Library contribution status.
DOC72 already has `work_product` as the durable knowledge/output node kind. R0.4 should not redefine that payload. R0.4 only defines the UI/read-model needs and output-routing signals around it.
### 13.3 Interface sketch
```ts
// Non-final sketch. Final work_product contracts belong to DOC72/DOC80.
type WorkProductReadModel = {
work_product_ref: string;
title: string;
kind:
| "draft"
| "memo"
| "report"
| "spreadsheet"
| "timeline"
| "email_draft"
| "task_output"
| "other";
scope_refs: ScopeRef[];
source_refs: string[];
current_internal_artifact_ref?: string;
external_file_refs: Array<{
file_ref: string;
output_target_ref?: string;
saved_at: string;
save_reason:
| "user_requested"
| "source_folder_affinity"
| "scope_default"
| "task_default"
| "internal_default";
}>;
status: "scratch" | "draft" | "review" | "final" | "archived";
library_contribution_status:
| "not_source"
| "candidate"
| "approved_source"
| "excluded_from_learning";
schema_version: 1;
};
```
### 13.4 Output routing principles
1. Current user instruction wins.
2. Source folder affinity is real and valuable.
3. Saving a new sibling version near a source is often useful.
4. Overwrite and delete require stricter confirmation.
5. Internal output store exists even if no external output folder is configured.
6. Work Product reference remains visible regardless of where the file is saved.
7. Output routing can be LLM-assisted, but EC validates and enforces.
### 13.5 Precedence stack
```text
1. Current user instruction in the active turn
2. Explicit task/run output target, if DOC23 owns the run
3. Source-folder affinity for direct revisions/exports
4. Active scope/project output policy
5. Workspace/session/agent default output policy
6. Internal Elnor output store
7. Ask user
```
### 13.6 Source Folder Affinity
If a user opens or uploads a source file and asks for a revision, Elnor should often infer:
```text
Save a new sibling version near the source file.
```
This is useful and should not be overrestricted. The safety issue is not sibling saves. The safety issue is destructive or inappropriate saves.
Rules:
```text
- Create new sibling version: usually allowed if write policy allows.
- Overwrite existing file: confirm unless explicit current-turn instruction says overwrite.
- Delete external file: always confirm.
- Save exploratory/scratch outputs to external source folder: ask or use internal store.
- User-named destination: use it if policy allows.
```
### 13.7 Output policy card
R0.4 can define the need for an output policy card. DOC24/DOC80 owns final packet product.
Example model-facing concept:
```text
[output_policy]
Current user instruction has highest priority.
Likely targets:
1. Same folder as source file
Use for direct revisions/exports. Save as a new version unless user explicitly requests overwrite.
2. Project output folder
Use for new deliverables and reports not tied to one source file.
3. Internal Elnor Outputs
Use for scratch work, exploratory drafts, uncertain outputs.
Do not delete or overwrite external files without confirmation.
```
The LLM may choose among candidates. EC validates:
- target exists;
- write permission exists;
- policy allows write/export;
- target is appropriate for content type;
- overwrite/delete confirmation exists where required;
- visibility/firewall rules are satisfied.
### 13.8 Output target sketch
```ts
// Non-final sketch.
type OutputTarget = {
output_target_id: string;
scope_ref?: ScopeRef;
folder_binding_id?: string;
display_label: string;
use_for: Array<
| "direct_revision"
| "external_final"
| "research_export"
| "task_output"
| "scratch_internal"
| "general_project_output"
>;
create_policy: "allowed" | "ask_first" | "blocked";
overwrite_policy: "ask_always" | "explicit_turn_only" | "blocked";
delete_policy: "ask_always" | "blocked";
default_filename_policy: "new_version" | "timestamped" | "ask";
permission_snapshot_ref?: string;
policy_snapshot_ref?: string;
schema_version: 1;
};
```
---
## 14. Carryover generation
### 14.1 Product purpose
Carryover solves the practical problem of starting a fresh model/session/agent with enough context to continue work without manually maintaining a huge prompt.
R0.4 keeps the command but reframes it:
```text
carryover.generate = request a controlled continuation/export product.
```
It is not a second continuity system and not a memory truth store.
### 14.2 Targets
R0.4 supports:
```text
self_continuation
external_llm
local_subagent
generic_markdown
```
R0.4 drops `task_handoff` as a target. DOC23 owns task handoff formats.
### 14.3 Egress policy
External LLM carryover is an egress event. It requires:
- policy check;
- redaction pass where configured;
- exclusion of firewalled/sealed content by default;
- user-visible source/visibility summary;
- user review before export;
- export receipt.
### 14.4 Interface sketch
```ts
// Non-final sketch. Final export/carryover contracts belong to DOC24/DOC80/EC/PropA.
type CarryoverGenerateCommand = {
command: "carryover.generate";
target:
| "self_continuation"
| "external_llm"
| "local_subagent"
| "generic_markdown";
scope: {
scope_refs?: ScopeRef[];
surface_ids?: string[];
conversation_thread_ids?: string[];
episode_ids?: string[]; // optional if an episode layer exists; ignored otherwise
document_refs?: string[];
work_product_refs?: string[];
};
size_hint: "compact" | "standard" | "full";
include: Array<
| "state_of_play"
| "recent_decisions"
| "open_loops"
| "key_entities"
| "documents"
| "work_products"
| "source_handles"
| "user_instructions"
| "memory_directives"
>;
egress_policy: {
target_environment: "local_elnor" | "external_llm" | "local_subagent";
include_firewalled: false;
include_sealed: false;
redact_sensitive: boolean;
require_user_review_before_export: boolean;
show_visibility_summary: boolean;
write_export_receipt: true;
policy_snapshot_ref: string;
};
schema_version: 1;
};
```
### 14.5 Carryover output rules
Carryover output should clearly mark:
- what scope(s) it covers;
- what sources/documents are referenced;
- what was excluded for policy/visibility;
- whether it is for internal continuation or external export;
- whether it is orientation-only;
- when it was generated;
- what generated it.
---
## 15. Consolidate Memory Now
### 15.1 Product purpose
The user needs a command meaning:
```text
Review what just happened and save what matters, now.
```
But that command must not become a governance bypass.
### 15.2 Correct R0.4 behavior
`memory.consolidate_now`:
- bypasses scheduling latency;
- raises priority;
- runs the appropriate owner intake/consolidation pipeline now;
- may create review candidates;
- may refresh a Project State Card;
- does not bypass significance;
- does not bypass Write Gate;
- does not bypass policy;
- does not auto-commit by default.
### 15.3 Interface sketch
```ts
// Non-final sketch. Final command belongs to DOC80/DOC72/DOC1/EC.
type MemoryConsolidateNowCommand = {
command: "memory.consolidate_now";
scope: {
scope_ref?: ScopeRef;
surface_id?: string;
conversation_thread_ids?: string[];
episode_ids?: string[];
time_window_minutes?: number;
};
purpose:
| "prepare_for_resume"
| "save_important_session_learning"
| "review_memory_candidates"
| "refresh_project_state_card"
| "prepare_carryover";
posture: {
bypass_scheduling_latency: true;
priority_boost: "user_requested";
bypass_significance_gate: false;
bypass_write_gate: false;
allow_high_confidence_auto_commit: false;
};
output: {
create_review_queue_items: boolean;
refresh_project_state_card?: boolean;
emit_learning_signal?: boolean;
};
schema_version: 1;
};
```
### 15.4 Removed R0.3/R0.2 leftovers
- Do not refer to “active Working Set state.”
- Do not auto-commit above a threshold by default.
- Do not define a new memory lane.
---
## 16. Learning signals
### 16.1 Product purpose
Project Mode and Library/Output UX produce useful data:
- auto-link accepted/rejected;
- user had to re-supply context;
- output folder chosen/changed/undone;
- Library manually invoked after the system failed to retrieve;
- carryover requested because continuity failed;
- user corrected Project State Card;
- user rejected a learned memory candidate.
R0.4 should emit signals. It should not define the final learning engine.
### 16.2 Signal sketch
```ts
// Non-final sketch.
type ScopeControlLearningSignal = {
signal_id: string;
signal_kind:
| "auto_link_feedback"
| "manual_scope_switch"
| "context_resupply"
| "library_invocation_after_miss"
| "output_target_feedback"
| "project_state_card_correction"
| "carryover_requested"
| "memory_candidate_feedback";
scope_ref?: ScopeRef;
surface_id?: string;
principal_id: string;
outcome?: string;
evidence_refs?: string[];
created_at: string;
schema_version: 1;
};
```
### 16.3 Boundary
Learning signals may tune utility, routing, UI suggestions, and future defaults only within owner rules. They do not update truth, override policy, or bypass final-prompt-proof-gated learning requirements.
---
## 17. Scope-control events
### 17.1 Why event emission belongs in R0.4
R0.4 owns the UI/control state transitions. Therefore it should define the **event kinds it emits**. It should not define the WorkEpisode schema or cognitive diff schema that may consume those events later.
### 17.2 Event sketch
```ts
// Non-final sketch. Final event ledger belongs to EC/DOC80.
type ScopeControlEvent = {
event_id: string;
event_kind:
| "project_mode_entered"
| "project_mode_paused"
| "project_mode_resumed"
| "project_mode_exited"
| "auto_link_suggested"
| "auto_link_provisional_started"
| "auto_link_confirmed"
| "auto_link_rejected"
| "work_product_created_from_scope_surface"
| "output_saved_from_scope_surface"
| "context_pressure_checkpoint"
| "model_switch_checkpoint";
scope_ref?: ScopeRef;
surface_id: string;
surface_kind: SurfaceKind;
principal_id: string;
source_command_id?: string;
evidence_refs?: string[];
created_at: string;
schema_version: 1;
};
```
### 17.3 Episode boundary relation
If the future Memory Control Plane has WorkEpisode / EpisodeSegment, these events may be consumed by that layer. If not, they remain useful EC audit and UI history. R0.4 does not define episode construction.
---
## 18. DOC23 boundary
### 18.1 Rule
R0.4 must not specify DOC23 task-run context.
R0.4 may define or expose objects/signals DOC23 can reference:
- `scope_ref`;
- Project Mode state;
- Library refs;
- Folder Bindings;
- Work Products;
- Output Targets;
- Carryover artifacts;
- scope-control events.
DOC23 owns:
- task-run scope envelopes;
- task-specific context assembly;
- task memory;
- task continuity writes;
- task output governance;
- task handoff formats;
- task UI/Run Inspector;
- task audit/export behavior.
### 18.2 R0.4 must not include
- final Task Scope Envelope schema;
- task context injection rules;
- task memory save rules;
- task workstream/episode rules;
- task output disposition rules beyond generic Work Product adjacency;
- task handoff carryover format.
### 18.3 Task adjacency sentence
Use this sentence in the spec:
> **DOC23 may consume R0.4 scope, Library, output, and Work Product signals, but DOC23 remains the sole owner of task-run context, task-specific memory behavior, task handoff, and task execution semantics.**
---
## 19. Agent / Assistant profile boundary
R0.3 retained `default_agent_id`. That is acceptable if it points to the existing runtime/AgentKnowledgeProfile concept. R0.4 should clarify that this is not the deferred “Assistant Profile” architecture.
Use this note:
```text
default_agent_id references the existing agent/runtime profile available to the system.
It does not introduce a separate Assistant Profile object and does not imply a separate agent memory store.
A future Assistant Profile spec may replace or extend this binding.
```
Project Mode may bind a preferred agent for UX/routing, but it does not own agent identity, agent memory, agent training, or OpenClaw runtime projection.
---
## 20. Effective state, desired state, and degraded receipts
R0.4 controls must distinguish desired configuration from effective runtime truth.
Example:
```text
Desired: Product Docs Library active.
Effective: Product Docs Library handle available, but 4 sources are permission-missing and 2 are index-stale.
```
Every visible activation/binding should have:
- desired state;
- effective state;
- divergence reason;
- last checked time;
- command/receipt ref;
- visible degraded/no-op result where applicable.
This follows the no-phantom-control rule.
---
## 21. Commands and command posture
R0.4 commands are EC commands or requests to owner systems. The final names and payloads will be drafted in the flattening plan.
### 21.1 Command categories
```text
scope_mode.enter
scope_mode.pause
scope_mode.resume
scope_mode.exit
scope_mode.switch
scope_mode.undo_auto_link
scope_mode.attach_surface
scope_mode.detach_surface
scope_ref.resolve
scope_ref.explain
project_instructions.update
project_state_card.refresh_request
library.attach
library.detach
library.source.set_index_policy
library.source.set_learning_policy
library.source.prepare_large_pdf
folder_binding.create
folder_binding.update
folder_binding.remove
output_target.create
output_target.update
output_target.select
work_product.save
work_product.export
carryover.generate
memory.consolidate_now
```
### 21.2 Command discipline
Every command must produce:
- command receipt;
- effective-state update or explicit no-op/degraded status;
- policy decision ref where required;
- UI read-model refresh;
- audit/telemetry event where relevant.
---
## 22. UI workflow examples
### 22.1 User opens a recent scoped project
```text
User clicks: Project button → Recent → Product Launch.
Result:
- current chat enters confirmed_active for Product Launch scope_ref;
- visual chrome updates;
- default Library handles become available;
- output routing gets Product Launch targets;
- Project State Card becomes eligible, not guaranteed;
- scope-control event emitted.
```
### 22.2 Auto-link fires
```text
User opens Launch_Plan_v3 and asks for a revision.
Elnor infers Product Launch:
- enters provisional_auto;
- project button pulses;
- retrieval may prefer Product Launch handles;
- no durable tagging yet;
- undo is visible in menu;
- after confirmation/timeout, confirmed_active begins.
```
### 22.3 User pauses project
```text
User clicks Pause.
Result:
- scope chip remains visible but dimmed;
- capture aperture returns to default;
- Project State Card not injected by default;
- user can still explicitly ask “use Product Launch context.”
```
### 22.4 User asks to revise a source document
```text
Source: /Product Launch/Drafts/Launch_Plan_v3.docx
User: Revise this and save a new version.
Output routing:
- current instruction wins;
- source-folder affinity suggests same folder;
- EC checks write policy;
- Elnor saves Launch_Plan_v4_Elnor.docx or similar;
- Work Product version links internal artifact and external file ref.
```
### 22.5 User asks for scratch analysis
```text
User: Give me three possible strategies but don't save anything to the shared folder.
Output routing:
- current instruction blocks external folder save;
- internal output store used if durable artifact needed;
- Work Product may be scratch/internal only.
```
### 22.6 User invokes a Library
```text
User: Look in the Product Docs library for the refund-policy issue.
If sources are Indexed:
- content retrieval can search prepared document intelligence.
If sources are Linked only:
- Elnor can live-open/live-scan selected candidates if policy allows;
- response may say indexing would make this faster/more reliable.
```
### 22.7 User generates carryover for external LLM
```text
User: Generate a standard carryover for this project for use in another model.
Result:
- carryover.generate target external_llm;
- policy/redaction run;
- visibility summary shown;
- user reviews before export;
- export receipt written.
```
---
## 23. Acceptance tests
### 23.1 Control-surface posture
```text
AT-R04-001
Given a surface enters Project Mode,
Then R0.4 emits control signals and visual state,
And does not directly compile model-facing context or write memory.
```
### 23.2 ScopeRef
```text
AT-R04-002
Given a Project Mode activation,
Then the activation stores scope_ref,
And raw project_entity_id is not the canonical R0.4 key.
```
### 23.3 Auto-link provisional
```text
AT-R04-003
Given auto-link threshold is reached,
Then surface enters provisional_auto,
And no durable scope tagging or elevated capture occurs until confirmation/expiry.
```
### 23.4 Auto-link undo
```text
AT-R04-004
Given provisional_auto is active,
When user clicks Undo within the window,
Then state returns to default,
And provisional evidence is scoped by default-mode rules.
```
### 23.5 Paused mode
```text
AT-R04-005
Given Project Mode is paused,
When user asks an unrelated question,
Then Project State Card is not injected by default,
And capture aperture is default.
```
### 23.6 Project State Card
```text
AT-R04-006
Given Project State Card is included,
Then inspector shows source refs, generated_at, stale_after, inclusion reason, and orientation-only status.
```
### 23.7 Library statuses
```text
AT-R04-007
Given a Linked-only source,
Then Elnor can find/open it by Library/path/name if access allows,
But content-based retrieval may require live scan/on-demand conversion.
```
```text
AT-R04-008
Given an Indexed source,
Then document intelligence is available for content retrieval,
And no durable memory is created merely because it is Indexed.
```
```text
AT-R04-009
Given a Learned source,
Then corpus-scoped extraction is intentionally invoked or queued,
And durable knowledge remains governed by owner pipelines.
```
### 23.8 Output routing
```text
AT-R04-010
Given a user names an output destination in the current turn,
Then that destination outranks project defaults and source-folder affinity if policy allows.
```
```text
AT-R04-011
Given a direct revision of a source file,
Then same-folder new-version save is allowed if write policy allows,
But overwrite requires confirmation unless explicitly requested in current turn.
```
### 23.9 Carryover egress
```text
AT-R04-012
Given carryover.generate targets external_llm,
Then policy/redaction/visibility summary/user review/export receipt are required.
```
### 23.10 Memory consolidate
```text
AT-R04-013
Given memory.consolidate_now runs,
Then scheduling latency is bypassed,
But significance gate, Write Gate, and policy are not bypassed.
```
### 23.11 DOC23 boundary
```text
AT-R04-014
Given a DOC23 task is launched from a Project Mode surface,
Then R0.4 may pass adjacent refs/signals,
But DOC23 owns task-run scope and task context semantics.
```
---
## 24. R0.3 bug-fix checklist
R0.4 should explicitly close these R0.3 bugs:
- [x] Remove `work_thread_id` from carryover scope.
- [x] Remove “active Working Set state” from `memory.consolidate_now`.
- [x] Do not bypass significance gating in Project Mode.
- [x] Do not auto-commit memory in `memory.consolidate_now` by default.
- [x] Add carryover egress policy.
- [x] Add provisional auto-link before confirmed-active.
- [x] Fix paused mode injection behavior.
- [x] Split Library status into link/index/learning/access/corpus axes.
- [x] Add surface/principal identity.
- [x] Tombstone persistent tabs instead of hard-deleting.
- [x] Add token cap / strict-soft split for user-authored instructions.
- [x] Clarify `default_agent_id` is existing agent profile, not deferred Assistant Profile.
- [x] Avoid hard dependency on unfinished DAMS/DOC80 primitives.
- [x] Do not define full WorkEpisode/CognitiveDiff schemas.
- [x] Preserve DOC23 boundary.
---
## 25. Open questions for the next revision / flattening
### Must decide before R0.4 finalization
1. Should the public title remain “Unified Workspace…” for lineage, or be retitled to “Project Mode, Library Access, Output Routing, and Scope Control Surface Proposal”?
2. What is the minimal Project Mode UI: top button only, chat-input chip only, or both?
3. What default timeout confirms `provisional_auto` if the user does not undo?
4. Should passive timeout confirmation be allowed, or should confirmation require user action?
5. What is the default Project State Card token cap?
6. Which output actions require explicit confirmation in v1: external write, overwrite, delete, final save, all of the above?
7. Should Indexed be the default for new Libraries, or should new sources start Linked and index on first use?
### Defer to DOC80 / flattening
1. Final `ScopeRef` resolver contract.
2. Final ScopeIdentityRoot / ScopeRoot model.
3. Final WorkEpisode / RecentActivity / IssueFrame contracts.
4. Final Project State Card / Recent Work Orientation product schema.
5. Final Context Compiler / MemoryContextPlan contracts.
6. Final Assertion pipeline mappings for Project/Library/Topic/chat/task routes.
7. Final learning-signal and attribution contracts.
8. Final policy-stage and egress/export contract.
### Defer to DOC23
1. Task-run scope envelope.
2. Task-specific context injection.
3. Task memory behavior.
4. Task handoff carryover format.
5. Task output disposition and Run Inspector.
### Defer to DOC73/DOC25/DOC7 owner alignment
1. Exact mapping from Library UI statuses to DOC7 bucket records.
2. Exact mapping from Indexed to DOC25 ingestion/materialization state.
3. Exact mapping from Learned to DOC73 corpus/PBE extraction state.
4. How DOC73 V1.6+ advanced Library options appear under “Advanced Library Options.”
---
## 26. Recommended R0.4 disposition
R0.4 should be treated as:
```text
source_status: accepted_directionally or draft_controlling_for_review
normative_weight: supports_target / candidate_completion_source
```
Final status will be assigned by the DOC80 flattening ledger.
The useful R0.4 material to preserve:
- Project Mode as surface-local control state;
- ScopeRef indirection;
- visual chrome and inspectors;
- provisional auto-link;
- paused-mode semantics;
- Project Instructions / Project State Card split;
- Linked / Indexed / Learned vocabulary and multi-axis internals;
- Folder Bindings;
- Work Products + output routing;
- carryover export policy;
- memory-consolidate-now governance posture;
- DOC23 boundary;
- no new memory store;
- default mode remains first-class.
The material to avoid importing as final:
- schema sketches as written;
- any assumed final Context Compiler behavior;
- any assumed WorkEpisode/CognitiveDiff behavior;
- any task-run context behavior;
- any hard-coded ScopeRoot dependency;
- any claim that Project Mode owns memory.
---
## 27. Final product framing
The simplest product explanation:
> **Project Mode tells Elnor what this surface is doing. Libraries tell Elnor what sources are available. Indexed sources make documents easy to find and use. Learned sources let Elnor extract reusable knowledge. Work Products track what Elnor makes. Output Routing decides where files should go. Carryover exports or resumes state safely. The Memory Control Plane decides what to learn, inject, verify, suppress, or preserve.**
A shorter UI framing:
```text
Project: Product Launch Libraries: 2 Outputs: Source folder / Internal State: Active
```
Everything is optional. If the user never starts a Project, Elnor should still use normal memory, entities, Libraries invoked by name, recent work, documents, and ordinary retrieval.
---
## 28. Fresh-window review prompt stub
For future red-team review, use this framing:
```text
Review R0.4 as a control-surface and operational-binding proposal, not as the final Memory Control Plane.
Ask whether it makes scoped work easier, safer, and more inspectable without becoming a second memory system.
Check that it emits signals and renders state, but does not compile model-facing context or govern durable memory.
Check that it is compatible with DOC80/DAMS direction without depending on unfinished primitives.
Check whether the UI can remain automatic-first and low-friction.
```
---
**End of R0.4 draft.**