(CODUX-107) QA follow-up for T03

docs-web/content/docs/developer-http-api.mdx

@@ -156,10 +156,7 @@ This page lists every endpoint, grouped by domain. Path parameters use `:name` n
 | `PATCH` | `/api/agent-presets/:agentPresetId` | Update. |
 | `DELETE` | `/api/agent-presets/:agentPresetId` | Delete. |
 | `POST` | `/api/agent-presets/:agentPresetId/import-markdown` | Import from a single file. |
-| `POST` | `/api/agent-presets/:agentPresetId/export-markdown` | Export one sqlite preset to the project `.code-ux/agents/` directory. |
-| `POST` | `/api/projects/:projectId/agent-presets/sync-markdown` | Backward-compatible bulk pull from `.code-ux/agents/`. |
-| `POST` | `/api/projects/:projectId/agent-presets/pull-markdown` | Explicitly discover/import project markdown into sqlite. |
-| `POST` | `/api/projects/:projectId/agent-presets/push-markdown` | Export sqlite presets to project markdown when mirroring is enabled. |
+| `POST` | `/api/projects/:projectId/agent-presets/sync-markdown` | Bulk-sync from `.code-ux/agents/`. |
 
 ---
 

docs-web/content/docs/registry.ts

@@ -178,7 +178,7 @@ export const docsRegistry: Record<DocsSlug, DocsRegistryEntry> = {
     path: '/docs/user-dashboard-chat',
     section: 'User Guide',
     title: "Chat",
-    description: "The Chat page (/chat) is a conversation surface that lets you talk to agents for project-backed Q&A, inspect MCP tool invocations, and get local onboarding help before any project exists.",
+    description: "The Chat page (/chat) is a thread-based conversation surface that lets you talk to agents for project-backed Q&A, inspect execution invocation transcripts and MCP tool invocations, and get local onboarding help before...",
   },
   'user-dashboard-agents': {
     id: 'user-dashboard-agents',

docs-web/content/docs/user-dashboard-agents.mdx

@@ -8,10 +8,11 @@ An *agent preset* is a reusable persona consisting of:
 - A markdown **system instruction** that prepends every session this agent runs.
 - An optional **memory template** — controls how project / sprint memory is injected into prompts.
 - Optional persistent skill storage attachments, stored as shared project skill storage IDs for future retrieval.
-- Optional runtime metadata such as provider/model preferences, a nullable Docker root-mode override for local CLI task runs, and optional MCP access including default-off Code UX built-in tools and custom MCP server links.
+- Optional MCP access, including default-off Code UX built-in tools and custom MCP server links.
+- Optional runtime metadata such as provider/model preferences and a nullable Docker root-mode override for local CLI task runs.
 - A set of **labels** for tagging and filtering.
 
-Agent presets show up wherever a chat thread or planning request needs to choose an agent.
+Agent presets show up wherever a chat thread or planning request needs to choose an agent. SQLite is the live authority for these presets; markdown files are the project-local import/export copy used for review and sharing.
 
 ## Project name privacy
 
@@ -55,11 +56,15 @@ Agent presets can be defined as markdown files inside `<repo>/.code-ux/agents/<p
 You are a planner agent. Decompose user requests into ...
 ```
 
-To import a single file: open the agent detail panel and click **Import markdown**.
+To import a single linked file into sqlite: open the agent detail panel and click **Import**.
 
-To explicitly pull project markdown into sqlite, use **Sync from markdown** in the page header. The backend discovers `.code-ux/agents/*.md`, applies the existing project/default/home precedence rules, imports new files, and refreshes out-of-sync linked agents.
+To explicitly pull project markdown into sqlite, use **Pull from files** in the page header. The backend discovers `.code-ux/agents/*.md`, applies the existing project/default/home precedence rules, imports new files, and refreshes out-of-sync linked agents.
 
-To explicitly push sqlite presets back to project files, use the markdown push action. Push writes only under the selected project’s `.code-ux/agents/` directory, exports manual, missing-source, out-of-sync, home-backed, and default-backed presets as project markdown overrides, and refuses to overwrite a file already linked to a different agent. Project markdown mirroring (`agents.saveToProjectDirectory`) must be enabled.
+To explicitly push sqlite presets back to project files, use **Push to files** in the page header. Push writes only under the selected project’s `.code-ux/agents/` directory, exports manual, missing-source, out-of-sync, home-backed, and default-backed presets as project markdown overrides, and refuses to overwrite a file already linked to a different agent. Project markdown mirroring (`agents.saveToProjectDirectory`) must be enabled.
+
+To push one sqlite preset to its project file, open the detail panel and click **Push to file**. This is useful when a single database-backed agent should become or refresh a repository-reviewed markdown file without exporting the whole roster.
+
+Older API clients may still call the legacy `sync-markdown` endpoint as a backward-compatible alias for pull, but the current dashboard action is **Pull from files**.
 
 This makes agent presets first-class repository content — you can check them in, code-review them, and share them across teammates.
 

docs-web/content/docs/user-dashboard-chat.mdx

@@ -89,7 +89,7 @@ The **Invocations** tab is a structured log of server-created execution invocati
 
 Use this for debugging provider runs and MCP client integrations, for example to inspect agent transcripts or see exactly what arguments your LLM is passing to tools like `manage_memory` or `manage_settings`.
 
-Invocation transcripts use the same live sprint status card as thread messages when planning metadata links them to a sprint. Completed sprint-planning invocations append a final assistant summary with `metadata.widget_metadata.type = "planning_request"`, `status = "completed"`, and `metadata.executionPlan` for that exact sprint, including the sprint id, created task ids, and planned task titles. This means a planning invocation and its related chat message should show consistent task progress without a separate refresh control. Parsed provider conversation turns stream into running invocation transcripts for provider-backed planning, QA review, dashboard/chat replies, CI repair, merge-conflict repair, memory remediation, setup, and task coding; text-only provider output is appended when the run completes.
+Invocation transcripts use the same live sprint status card as thread messages when planning metadata links them to a sprint. Completed sprint-planning invocations append a final assistant summary with `metadata.widget_metadata.type = "planning_request"`, `status = "completed"`, and `metadata.executionPlan` for that invocation's linked sprint, including the sprint id, created task ids, and planned task titles. The plan shown in the transcript is replayed from persisted invocation message metadata, not from the currently selected sprint or the latest planning run for the project, so historical planning transcripts remain sprint-specific and stable. Parsed provider conversation turns stream into running invocation transcripts for provider-backed planning, QA review, dashboard/chat replies, CI repair, merge-conflict repair, memory remediation, setup, and task coding; text-only provider output is appended when the run completes.
 
 Invocation transcripts use the same external-reference cards as thread messages for recognized Jira, GitHub, and GitLab payloads, including JSON payloads that would otherwise appear as raw punctuation-heavy output. This keeps linked work readable while preserving the original backend metadata and message content.
 

docs-web/content/docs/user-dashboard-live-session.mdx

@@ -44,7 +44,9 @@ When the engine cannot proceed without input, an attention item is created. It a
 
 A virtual worker can claim an attention item too. If you have configured `virtualWorkerProvider` in settings, the engine will offer eligible items to a worker before showing them to you.
 
-When a sprint is selected in the dashboard, the attention ledger shows active `open` and `claimed` items for that sprint, including items tied only to one of its sprint runs. With no selected sprint, the ledger keeps the project-wide active queue.
+When a sprint is selected in the dashboard top bar, the attention ledger follows that selected sprint scope and shows active `open` and `claimed` items for that sprint, including items tied only to one of its sprint runs. With no selected sprint, the ledger keeps the project-wide active queue.
+
+The Overview telemetry panel uses the same selected-project live snapshot for its compact read-only attention queue, so Overview and Live agree on which sprint's blockers are visible.
 
 ## Pause / Cancel from the live view
 

docs-web/content/docs/user-dashboard-overview.mdx

@@ -45,6 +45,16 @@ The background is an animated Three.js scene ("Deep Ocean") that lazy-loads afte
 | `/stats` | [Stats](/docs/user-dashboard-stats) | Execution analytics, time-window filtering, trends |
 | `/config` | [Settings](/docs/user-dashboard-settings) | System / project / sprint settings hierarchy |
 
+## Overview telemetry
+
+The Overview telemetry rail combines cross-project runtime health with selected-project detail:
+
+- Cross-project intervention cards still show active projects that need human attention.
+- Active sprint cards and the runtime timeline continue to summarize work across active projects.
+- When the top bar has a project selected and that project's live snapshot contains active attention items, Overview shows a compact **Selected Sprint Attention Queue** inside the telemetry panel.
+
+The Overview queue follows the same selected sprint scope as the Live page. If a sprint is selected in the top navigation, the queue shows only the active attention items returned by the selected-sprint live snapshot; unrelated sprint blockers are not reconstructed in the browser. Overview renders the queue read-only, so claim, resolve, and dismiss actions remain on the Live page.
+
 ## Real-time data
 
 The dashboard maintains a live connection to the server using a custom WebSocket protocol via `GET /api/realtime` (e.g., `ws://localhost:4444/api/realtime` for local HTTP dashboards, and `wss://<host>/api/realtime` for HTTPS deployments). On the server side, `DashboardRealtimeService` in `src/services/dashboard-realtime-service.ts` coordinates events, and the websocket upgrade/transport is handled in `src/server/dashboard-realtime-websocket-server.ts`. The connection:

docs-web/content/docs/user-dashboard-settings.mdx

@@ -269,7 +269,7 @@ Related docs:
 
 Customizes the dashboard background image, animation mode, static color, and pattern overlay.
 
-**What it controls:** Image upload, animated/static mode, animation style, color picker, and overlay pattern shape the visual layer behind panels. Onboarding previews Theme, Navigation Mode, Reduced Motion, Background Mode, Static Color, and supported Zoom Level while it is open, while Animation Style, Pattern Overlay, and custom background image remain available here after onboarding.
+**What it controls:** Background Image, Background Mode, Animation Style, Static Color, and Pattern Overlay shape the visual layer behind panels. Onboarding previews Theme, Navigation Mode, Reduced Motion, Background Mode, Static Color, and supported Zoom Level while it is open, while Animation Style, Pattern Overlay, and custom background image remain available here after onboarding.
 
 **Recommended defaults:** Prefer lightweight images and readable contrast; use static mode if motion is distracting.