oceanbase · PsiACE · Aug 27, 2026 · Aug 27, 2026 · Aug 27, 2026 · Aug 27, 2026
diff --git a/.env.example b/.env.example
@@ -18,9 +18,8 @@ POWERCONTEXT_SERVER_AUTH_ENABLED=false
 # POWERCONTEXT_SERVER_AUTH_TOKEN=replace-me
 
 # Dashboard -------------------------------------------------------------------
-# Every Coding Agent below uses this same Scope ID.
+# The Dashboard discovers Scopes from the Server. The Server creates a default Scope on first startup.
 POWERCONTEXT_SERVER_DASHBOARD_ENABLED=true
-POWERCONTEXT_SERVER_DASHBOARD_SCOPES='[{"scope_id":"project:quickstart","display_name":"Quick Start"}]'
 
 # Logging, metrics, and tracing -----------------------------------------------
 POWERCONTEXT_SERVER_LOGGING_LEVEL=INFO
@@ -108,13 +107,14 @@ POWERCONTEXT_CLIENT_TIMEOUT=10
 # POWERCONTEXT_CLIENT_API_TOKEN=replace-me
 
 # Coding Agent integrations ---------------------------------------------------
-# Keep these values equal to the Dashboard scope above. Load .env before starting the selected Agent.
-POWERCONTEXT_CODEX_SCOPE_ID=project:quickstart
-POWERCONTEXT_CLAUDE_SCOPE_ID=project:quickstart
-POWERCONTEXT_DSH_SCOPE_ID=project:quickstart
-POWERCONTEXT_OPENCODE_SCOPE_ID=project:quickstart
-POWERCONTEXT_PI_SCOPE_ID=project:quickstart
-POWERCONTEXT_LANGGRAPH_SCOPE_ID=project:quickstart
+# Load .env before starting the selected Agent. Codex binds each Session through the Scope service.
+# Set an integration's SCOPE_ID only to select an existing Scope explicitly.
+# POWERCONTEXT_CODEX_SCOPE_ID=scp_existing
+# POWERCONTEXT_CLAUDE_SCOPE_ID=scp_existing
+# POWERCONTEXT_DSH_SCOPE_ID=scp_existing
+# POWERCONTEXT_OPENCODE_SCOPE_ID=scp_existing
+# POWERCONTEXT_PI_SCOPE_ID=scp_existing
+# POWERCONTEXT_LANGGRAPH_SCOPE_ID=scp_existing
 
 # Local Server endpoints used by integrations.
 POWERCONTEXT_CLAUDE_SERVER_URL=http://127.0.0.1:8000

diff --git a/docs/en/development/server-web-ui.md b/docs/en/development/server-web-ui.md
@@ -72,20 +72,22 @@ versioned prefixes.
 
 ## Understand Dashboard data
 
-The browser authenticates against `/dashboard/scopes`, then requests `/v1/stats` with the selected `scope_id` and a
-`30d` period. The Server reads one scoped snapshot and returns inventory, model usage, and recall statistics.
+The browser authenticates against `/dashboard/scopes`, builds the shared Scope selector, then posts the selected
+`ScopeSelection` and period to `/v1/stats`. The selector exposes three observation views: `all`, one root's `subtree`,
+or one `exact` Scope. A Parent relation organizes the selector; it does not make parent data visible to a child.
 
 | Dashboard value | Source |
 | --- | --- |
-| Sources | Current scoped Source journal position |
-| Memory entries | Entries in the current Memory Artifact |
-| Artifacts | Current Artifact heads grouped by family |
-| Pending review | Current Candidate heads grouped by family and status |
+| Sources | Selected Scopes' Source journal positions |
+| Memory entries | Entries in the selected Scopes' Memory Artifacts |
+| Artifacts | Selected Scopes' Artifact heads grouped by family |
+| Pending review | Selected Scopes' Candidate heads grouped by family and status |
 | Model usage | Persisted daily generation and embedding usage |
 | Recall hits, token reduction, and savings trend | Persisted daily recall measurements for the configured estimator |
 
-The Runtime performs these reads in one database transaction and calculates totals, pending Sources, family counts,
-daily buckets, and token reduction on the Server. The browser presents `ready_preparations` as recall hits and plots the
+The Runtime resolves the selection to exact Scope IDs, aggregates totals, pending Sources, family counts, daily buckets,
+and token reduction on the Server, and returns both the selection and resolved IDs. The browser presents
+`ready_preparations` as recall hits and plots the
 signed daily `token_reduction` as the savings trend. Each heatmap cell combines those two fields for its date. Its fixed
 bands are no hit, hit without a positive reduction, 1–255, 256–1023, and 1024 or more estimated tokens reduced. The
 fixed thresholds keep sparse activity and outliers from changing the meaning of every other cell.
@@ -101,17 +103,17 @@ or rendering contract only after a second page needs the same behavior.
 
 ## Add the Handoff Report page
 
-When Handoff Report is enabled, the Server hosts the scope Handoff page at `/handoff-reports` without requiring the scoped-statistics Dashboard or its configured scope list. The optional Dashboard remains at `/` when separately enabled. The pages share only `base.html`, the header and footer, `auth.js`, theme state, and locale state; their statistics and report calculations remain independent.
+When Handoff Report is enabled, the Server hosts a read-only report page at `/handoff-reports`; the Dashboard remains
+optional. Both pages load Scopes from `/dashboard/scopes` and use `scope-selection.js` to expose the same `all`,
+`subtree`, and `exact` views.
 
-The Handoff Report page obtains exact `scope_id` values with committed Handoffs from `POST /v1/handoff-reports/scopes/list-known` and uses them in a searchable scope combobox. Selecting a scope sends its required `scope_id` to `POST /v1/handoff-reports/get`; neither the Project catalog nor `project_id` participates in report selection. The page presents the exact current Handoff snapshot at full width.
+The page posts the selected `ScopeSelection` to `/v1/handoff-reports/get`. The Server resolves it to exact Scope IDs
+and projects each Scope's descriptor and latest exact Handoff. A Scope without a committed Handoff remains visible as
+`no_handoff`. Parent does not infer Context sharing, and the report does not edit Handoff state.
 
-The current snapshot displays objective, current state, disposition, next action, and known omissions as one Handoff document. One Edit action opens all five fields, and one Save Revision action prepares and commits the complete document as a new immutable Handoff Revision. Scope switching and background refresh pause while the editor is open. Receiver-side decisions are not part of this page; existing continuity records remain available in the read-only Continuity timeline. Apart from the explicit revision write, the browser formats returned `summary`, `coverage`, Workstream state, and digests without recalculating report semantics.
-
-When known-scope discovery succeeds but no scope has a committed Handoff, the page replaces report controls with a clearly labeled, data-free template preview. Retry enumerates Handoff heads again; the first committed scope replaces the preview. The preview neither creates a Handoff nor requests fabricated report data.
-
-The page requests the current day in UTC by default and provides current-day, ISO-week, calendar-month, and custom date-range inputs. The custom end date is inclusive in the UI and is converted to the exclusive start of the next day for the API. The current scope application normalizes this input but supplies no Activity events, reports `activity_coverage=not_configured`, and returns no period comparison. Handoff status comes from the current exact selection and must not be presented as a historical period-end state.
-
-The overview request may disable evidence checks for lower latency. A Markdown download makes a separate request with `format=markdown`, `download=true`, and evidence checks enabled by default. The browser never reconstructs Markdown from rendered DOM or canonical JSON. Both background refresh and browser download currently require a stored bearer token even when Server authentication is disabled; initial and manual report loads still work without one. Disabling Handoff Report removes the `/handoff-reports` page and its API while leaving the original Dashboard route, scope selection, and statistics request unchanged.
+JSON is the browser projection. Markdown download repeats the same selection with `format=markdown` and
+`download=true`; the browser does not reconstruct Markdown from the rendered DOM. Disabling Handoff Report removes
+the page and report API without changing Dashboard selection or statistics behavior.
 
 ## Preserve the security boundary
 

diff --git a/docs/en/docs/explanation/core-concepts.md b/docs/en/docs/explanation/core-concepts.md
@@ -89,9 +89,8 @@ inspected boundary and returns a temporary Prepared Handoff. Committing a Handof
 the user wants a milestone. The receiver resolves the Handoff and records an Acknowledgement; a Task Outcome preserves
 the final status and checks as Source evidence.
 
-The [Handoff Report](../how-to/use-handoff-report.md) projects current Handoff Revisions for inspection and export. The
-current scope report does not yet include Activity events or period comparison, and it does not rewrite Memory or the
-underlying Handoff history.
+The [Handoff Report](../how-to/use-handoff-report.md) projects the latest Handoff Revision in each selected Scope for
+inspection and export. It is read-only and does not rewrite Memory or the underlying Handoff history.
 
 ## Interfaces expose different parts of the same Server
 

diff --git a/docs/en/docs/how-to/configure-claude-code.md b/docs/en/docs/how-to/configure-claude-code.md
@@ -73,16 +73,15 @@ Skill.
 Scope resolution uses this order:
 
 1. `POWERCONTEXT_CLAUDE_SCOPE_ID`, when explicitly set;
-2. the Git-private Workstream binding shared with Codex;
+2. a Git-private Scope binding;
 3. the normalized `remote.origin.url` of the Git top-level directory;
 4. a `local:sha256:<digest>` identifier derived from the resolved project directory.
 
-Claude Code and Codex therefore resolve the exact same scope in a checkout that has a Workstream binding. Without a
-binding they still share the normalized remote scope. Bind a known Workstream with the bundled resolver:
+Bind a known Scope to the checkout with the bundled resolver:
 
 ```bash
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/project_scope.py" \
-  --cwd "$PWD" --bind-workstream "WORKSTREAM_SCOPE_ID"
+python3 "${CLAUDE_PLUGIN_ROOT}/scripts/workspace_scope.py" \
+  --cwd "$PWD" --bind-scope "SCOPE_ID"
 ```
 
 The local fallback is stable for one resolved directory, but it is not intended to join unrelated checkouts. Set an

diff --git a/docs/en/docs/how-to/configure-codex.md b/docs/en/docs/how-to/configure-codex.md
@@ -36,27 +36,20 @@ handoff this work
 ```
 
 The `project-context` Skill treats that imperative as explicit authorization to create one durable Handoff milestone.
-If the catalog contains multiple Workstreams, Codex first opens a native picker; one Workstream is selected
-automatically when it is the only candidate. Codex binds the selected Workstream to the checkout, inspects the current
-conversation and repository, assembles the objective, branch and worktree state, changed files, observed checks,
-blockers, omissions, and next action, then calls `handoff_current_work` followed by `commit_handoff`. After a successful
-commit, Codex reports the selected Workstream and exact Handoff Revision; the user does not need to fill in the Handoff
-content or confirm the commit again.
+Codex inspects the current conversation and repository, assembles the objective, branch and worktree state, changed
+files, observed checks, blockers, omissions, and next action, then calls `handoff_current_work` followed by
+`commit_handoff` in the current Session Scope. After a successful commit, Codex reports the exact Handoff Revision; the
+user does not need to fill in the Handoff content or confirm the commit again.
 
 `交接`, `交接当前工作`, and `commit a handoff` use the same behavior. To inspect the proposed content without writing,
 ask to `preview the handoff without committing`; the Skill renders the proposed fields in chat and calls no write
 tool. Discussing Handoff design or asking how it works does not authorize a write.
 
-Codex resolves scope in this order: an explicit `POWERCONTEXT_CODEX_SCOPE_ID`, a Workstream scope persistently bound
-to the current Git workspace, the normalized Git remote, and finally the project path. Later Codex sessions in the
-same workspace reuse that scope.
-
-The picker returns the Workstream's human-facing `work_id` and authoritative `scope_id`. The `project-context` Skill
-passes that exact scope to the resolver's `--bind-workstream` operation and verifies the result. The binding lives in
-`powercontext/codex-workspace.json` below the Git-private directory, outside the worktree and commits. A one-line
-Handoff then continues the selected Workstream's Artifact lifecycle and creates the next Revision. If the MCP client
-does not support native elicitation, the tool returns structured choices instead; the integration must still obtain an
-explicit selection and must not choose silently.
+At Session start, Codex resolves Scope in this order: an explicit `POWERCONTEXT_CODEX_SCOPE_ID`, an existing Session
+binding, a host-managed workspace binding, and the Server's default Scope. The selected Scope is fixed to the Session.
+Repository and directory identities are lookup inputs only; they never generate a Scope ID. The prompt hook uses the
+binding for recall and capture, while `PreToolUse` injects it into data-plane tools so Agent input cannot redirect a
+read or write. The host must create or bind a different Scope when the Session changes work boundaries.
 
 The Hook calls `POST /v1/context/prepare` once before Codex analyzes the prompt. It requests an 8000-byte total budget,
 strictly validates `powercontext.prepared-context.v1`, and injects the returned content unchanged. The Runtime labels

diff --git a/docs/en/docs/how-to/configure-hermes.md b/docs/en/docs/how-to/configure-hermes.md
@@ -52,12 +52,12 @@ hermes powercontext search "Python package manager"
 ```
 
 Inside an interactive Hermes session, `/pc status` should reach the same active provider. Use `/pc ` followed by
-Tab/Down to inspect the available Memory, Handoff, Experience, Skill, review, statistics, trace, and Workstream
+Tab/Down to inspect the available Memory, Handoff, Experience, Skill, review, statistics, trace, and Scope
 commands. Hermes 0.20.4 does not provide enough invocation context to route gateway slash commands safely, so the
 companion rejects gateway invocations; use the provider's Hermes tools in gateway sessions.
 
-The provider uses `http://127.0.0.1:8000` by default. In a Git workspace, Workstream persistence first reads the
-shared `.git/powercontext/codex-workspace.json` scope binding. An explicit scope configuration takes precedence.
+The provider uses `http://127.0.0.1:8000` by default. In a Git workspace, Scope binding first reads
+`.git/powercontext/scope-binding.json`. An explicit Scope configuration takes precedence.
 Without either value, the provider derives a scope from the active Hermes profile and gateway user identifier; for a
 local CLI session without a user identifier, it derives a stable value from `HERMES_HOME`.
 
@@ -80,7 +80,7 @@ the file:
 | `POWERCONTEXT_HERMES_CAPTURE_PRE_COMPRESS` | Capture filtered new turns before compression; disabled by default |
 | `POWERCONTEXT_HERMES_EVALUATION_TRACE` | Record recalled context in sensitive local JSONL traces; disabled by default |
 | `POWERCONTEXT_HERMES_EVALUATION_TRACE_PATH` | Override the evaluation trace directory |
-| `POWERCONTEXT_HERMES_WORKSTREAM` | Read the shared Git-private Workstream binding; enabled by default |
+| `POWERCONTEXT_HERMES_SCOPE_BINDING` | Read the Git-private Scope binding; enabled by default |
 
 Let the Hermes wizard store authorization in its protected `.env` secret store; do not put the token in
 `config.json`. Use plain HTTP only for a loopback Server. See [Deploy the Server](deploy-server.md) before connecting

diff --git a/docs/en/docs/how-to/configure-workbuddy.md b/docs/en/docs/how-to/configure-workbuddy.md
@@ -69,8 +69,8 @@ cp "$PLUGIN"/hooks/workbuddy_powercontext_hook.py \
    "$PLUGIN"/hooks/workbuddy_settings.py \
    "$PLUGIN"/hooks/prepared_context.py \
    "$WORKBUDDY_HOOKS_DIR"/
-cp "$PLUGIN/scripts/project_scope.py" \
-   "$WORKBUDDY_HOOKS_DIR/powercontext_project_scope.py"
+cp "$PLUGIN/scripts/workspace_scope.py" \
+   "$WORKBUDDY_HOOKS_DIR/powercontext_scope_binding.py"
 ```
 
 ### 2. Register the hook
@@ -131,9 +131,9 @@ EOF
 
 Then replace `${POWERCONTEXT_PYTHON}` in
 `~/.workbuddy/skills/project-context/SKILL.md` with a shell-safe Python
-executable argument. Replace `${POWERCONTEXT_PROJECT_SCOPE_SCRIPT}` with a
+executable argument. Replace `${POWERCONTEXT_SCOPE_BINDING_SCRIPT}` with a
 shell-safe complete path to
-`<WORKBUDDY_HOOKS_DIR>/powercontext_project_scope.py`.
+`<WORKBUDDY_HOOKS_DIR>/powercontext_scope_binding.py`.
 
 ### 5. Start the Server, restart WorkBuddy, and verify
 
@@ -230,16 +230,14 @@ query strings, or fragments; plain HTTP is accepted only for loopback hosts.
 WorkBuddy resolves scope in this order:
 
 1. an explicit `POWERCONTEXT_WORKBUDDY_SCOPE_ID`;
-2. a Workstream scope persistently bound to the current Git workspace (stored
-   in `powercontext/codex-workspace.json` below the Git-private directory,
-   shared with the Codex and Claude Code plugins);
+2. a Scope persistently bound to the current Git workspace (stored in
+   `powercontext/scope-binding.json` below the Git-private directory);
 3. the normalized Git remote;
 4. a hash of the resolved local project directory.
 
 Later WorkBuddy sessions in the same workspace reuse that scope. The
-`project-context` Skill's `--bind-workstream` operation persists a Workstream
-binding for a selected Handoff; the binding never enters the worktree or
-commits.
+`project-context` Skill's `--bind-scope` operation persists a Scope binding;
+the binding never enters the worktree or commits.
 
 ## Connect to an authenticated local Server