fix: enable dashboard reply scheduler wakeups

.code-ux/agents/planning_agent.md

@@ -1,16 +1,14 @@
 ---json
 {
   "avatarConfig": {
-    "body": "male",
-    "hair": "style3",
-    "face": "style4",
-    "shirt": "style3",
-    "bottom": "style4",
-    "chassis": "capsule",
-    "eyes": "pixel",
-    "antenna": "dual",
-    "wings": "propeller",
-    "accent": "sky"
+    "chassis": "classic",
+    "eyes": "smile",
+    "antenna": "jewel",
+    "wings": "dust",
+    "accent": "jade",
+    "baseColor": "pearl",
+    "visorColor": "noir",
+    "headphones": "bumper"
   },
   "memoryTemplateOverrideEnabled": false
 }

.code-ux/agents/project_manager.md

@@ -2,19 +2,14 @@
 {
   "description": "Project manager - the main point of contact for orchestrating Code UX.",
   "avatarConfig": {
-    "body": "female",
-    "hair": "style2",
-    "face": "style3",
-    "shirt": "style4",
-    "bottom": "style1",
-    "chassis": "pebble",
-    "eyes": "pixel",
-    "antenna": "beam",
-    "wings": "orbit",
-    "headphones": "loop",
-    "accent": "coral",
-    "baseColor": "plum",
-    "visorColor": "violet"
+    "chassis": "classic",
+    "eyes": "smile",
+    "antenna": "jewel",
+    "wings": "dust",
+    "accent": "jade",
+    "baseColor": "pearl",
+    "visorColor": "noir",
+    "headphones": "bumper"
   },
   "memoryTemplateOverrideEnabled": false,
   "memoryConfig": {
@@ -83,6 +78,49 @@ Execution rules:
 4. After action, report concrete state: ids, names, status, URL, or changed setting.
 5. If only a legacy umbrella tool exists, use its domain/action/payload structure.
 
+## Programming Work Delegation
+
+When the user asks for programming work, implementation work, refactors, migrations, tests, fixes, QA follow-up, or "do these tasks", you are an orchestrator. You must delegate through Code UX sprint planning instead of manually constructing a sprint task list yourself.
+
+- Use `manage_sprints` with action `plan` as the default route for programming work delegation. If the request needs a new sprint first, create the sprint with the user's goal and immediately use the sprint planning route for task decomposition.
+- Do not invent, hand-write, or directly create a set of implementation tasks unless the user explicitly asks you to manually construct tasks or bypass planning.
+- Do not start coding yourself. Your job is to collect the minimum missing context, start planning, monitor outcomes, and report state.
+- If the user gives enough context, start planning. Ask only for missing essentials that would make the plan unsafe or impossible.
+- If the user asks to start execution after planning, use the planning route options that start the planned sprint when available; otherwise plan first, report the planned state, then start the sprint through the proper sprint lifecycle action.
+
+## Scheduler Protocol
+
+Use `scheduler_code_ux` to wake yourself for continuation work. The scheduler is for your own future dashboard reply turns, not for creating worker tasks.
+
+Use a wakeup before any operation where you need to answer first and continue after the answer is sent, including:
+
+- starting a planning run
+- retrieving project, sprint, task, telemetry, preview, settings, memory, or knowledge data through MCP
+- calling an MCP tool that may take noticeable time
+- waiting for a sprint, task, planning run, preview, or external condition to finish
+
+Immediate continuation pattern:
+
+1. Call `scheduler_code_ux` with `action: "schedule_wakeup"`, `projectId`, `wakeAfterReply: true`, and a precise `bodyMarkdown` describing the exact next action.
+2. Answer the user concisely, for example: "I’ll retrieve the current sprint data now and report back."
+3. On the scheduled wakeup, perform the promised MCP call or management action, then report the result or schedule the next wakeup if more waiting is required.
+
+Use delayed or anchored wakeups when continuation depends on time or completion state:
+
+- Use `delaySeconds`, `delayMinutes`, or `scheduledFor` for a known time delay.
+- Use `afterSprintId` with optional `offsetMinutes` when the user asks for a report or follow-up after a sprint ends.
+- Use `afterTaskId` with optional `offsetMinutes` when the user asks for a report, inspection, or follow-up after a task ends.
+
+For completion-triggered requests, include the promised action in `bodyMarkdown`, not just a reminder. Example body: "Sprint completion follow-up: inspect sprint `<id>`, summarize final status, blockers, merged work, and next recommended action for the user." For task completion: "Task completion follow-up: inspect task `<id>`, check run/PR/QA state, and send a concise report."
+
+Scheduler discipline:
+
+- Use exactly one timing mode per wakeup: `scheduledFor`, `delaySeconds`/`delayMinutes`, `wakeAfterReply`, `afterSprintId`, or `afterTaskId`.
+- Include enough context in `bodyMarkdown` for your future turn to act without guessing: ids, user request, intended tool call, and expected report.
+- Use `list` before creating a duplicate wakeup when you are unsure whether one already exists.
+- Use `cancel` for obsolete wakeups you created.
+- Do not use the scheduler for simple answers that require no tool call, no wait, and no continuation.
+
 ## Custom Dashboard Requests
 
 When the user asks to create, revise, validate, publish, or inspect a user-created dashboard, treat it as a custom dashboard management request.

.code-ux/agents/project_setup_agent.md

@@ -1,12 +1,14 @@
 ---json
 {
   "avatarConfig": {
-    "chassis": "capsule",
-    "eyes": "pixel",
-    "antenna": "dual",
-    "wings": "propeller",
-    "accent": "lime",
-    "baseColor": "slate"
+    "chassis": "classic",
+    "eyes": "smile",
+    "antenna": "jewel",
+    "wings": "dust",
+    "accent": "jade",
+    "baseColor": "pearl",
+    "visorColor": "noir",
+    "headphones": "bumper"
   },
   "memoryTemplateOverrideEnabled": false
 }

.code-ux/agents/quality_assurance_agent.md

@@ -1,16 +1,14 @@
 ---json
 {
   "avatarConfig": {
-    "body": "male",
-    "hair": "style3",
-    "face": "style2",
-    "shirt": "style3",
-    "bottom": "style2",
-    "chassis": "capsule",
-    "eyes": "pixel",
-    "antenna": "none",
-    "wings": "propeller",
-    "accent": "violet"
+    "chassis": "classic",
+    "eyes": "smile",
+    "antenna": "jewel",
+    "wings": "dust",
+    "accent": "jade",
+    "baseColor": "pearl",
+    "visorColor": "noir",
+    "headphones": "bumper"
   },
   "memoryTemplateOverrideEnabled": false
 }

.code-ux/agents/worker.md

@@ -2,16 +2,14 @@
 {
   "description": "Default coding worker template for production-grade task execution.",
   "avatarConfig": {
-    "body": "female",
-    "hair": "style4",
-    "face": "style1",
-    "shirt": "style2",
-    "bottom": "style3",
-    "chassis": "egg",
-    "eyes": "cyclops",
-    "antenna": "single",
-    "wings": "tiny",
-    "accent": "pink"
+    "chassis": "classic",
+    "eyes": "smile",
+    "antenna": "jewel",
+    "wings": "dust",
+    "accent": "jade",
+    "baseColor": "pearl",
+    "visorColor": "noir",
+    "headphones": "bumper"
   },
   "memoryTemplateOverrideEnabled": false,
   "memoryConfig": {

docs-web/architecture/mcp-server.md

@@ -125,9 +125,8 @@ Advertised agent identities fail closed when malformed, unknown, or missing an e
 policy. This prevents an unknown worker agent from inheriting broad project-manager tools.
 Agent-scoped provider runs use the same default-deny posture for built-in Code UX tools. Default
 custom MCP links such as `playwright` are stored separately and do not imply `code_ux` access.
-Dashboard chat replies are the only route-local default exception: unconfigured reply agents receive
-the restricted `scheduler_code_ux` tool only, with broad tools such as `manage_scheduler`, `manage_tasks`,
-`manage_sprints`, `manage_settings`, and `manage_code_ux` disabled.
+Dashboard chat replies are the only route-local default exception: assigned reply agents receive
+the full built-in Code UX MCP surface plus `scheduler_code_ux` by default, even when their saved preset access disables Code UX.
 
 ### `CallTool`
 

docs-web/content/docs/architecture-mcp-server.mdx

@@ -125,9 +125,8 @@ Advertised agent identities fail closed when malformed, unknown, or missing an e
 policy. This prevents an unknown worker agent from inheriting broad project-manager tools.
 Agent-scoped provider runs use the same default-deny posture for built-in Code UX tools. Default
 custom MCP links such as `playwright` are stored separately and do not imply `code_ux` access.
-Dashboard chat replies are the only route-local default exception: unconfigured reply agents receive
-the restricted `scheduler_code_ux` tool only, with broad tools such as `manage_scheduler`, `manage_tasks`,
-`manage_sprints`, `manage_settings`, and `manage_code_ux` disabled.
+Dashboard chat replies are the only route-local default exception: assigned reply agents receive
+the full built-in Code UX MCP surface plus `scheduler_code_ux` by default, even when their saved preset access disables Code UX.
 
 ### `CallTool`
 

docs-web/content/docs/developer-mcp-tools.mdx

@@ -25,9 +25,8 @@ Tools are filtered before being advertised on `ListTools`:
 Agent-scoped provider runs are also default-deny for built-in Code UX tools. Newly synced Worker,
 Project manager, and generated coding agents may link the default `playwright` custom MCP server,
 but that custom-server link does not imply `code_ux` access. The dashboard chat reply route is the
-only default exception: when the reply agent has no explicit MCP access, Code UX enables only the
-restricted `scheduler_code_ux` tool and explicitly disables the broad management tools such as
-`manage_scheduler`, `manage_tasks`, `manage_sprints`, `manage_settings`, and `manage_code_ux`.
+only default exception: when the reply agent has no explicit MCP access, Code UX enables the full
+built-in management surface plus the restricted `scheduler_code_ux` tool for that dashboard chat turn.
 
 All inputs are validated against their declared JSON Schema (AJV) before dispatch; validation
 failures return `InvalidParams` with the failing JSON path.
@@ -45,7 +44,7 @@ action-specific fields, and an optional `approval` object for destructive action
 | `manage_tasks` | orchestration | Create, edit, start, stop, pause, and inspect tasks. |
 | `manage_quicksprints` | orchestration | Manage quicksprint templates and execute them. |
 | `manage_scheduler` | orchestration | Create and run scheduled sprints, quicksprints, messages, and node flows. |
-| `scheduler_code_ux` | orchestration | Agent-owned wakeups and task reruns with restricted list/schedule/cancel actions. |
+| `scheduler_code_ux` | orchestration | Agent-owned wakeups with restricted list/schedule/cancel actions. |
 | `manage_agents` | agents & memory | Manage agent presets and sync them to project markdown. |
 | `manage_node_flows` | agents & memory | Manage reusable node workflows, run them, and attach them as agent skills. |
 | `manage_memory` | agents & memory | Inspect, search, promote, and re-embed short/long-term memory. |
@@ -69,7 +68,7 @@ Every tool requires `runtimeRoles: ["project_manager"]` and is enabled by defaul
 | `manage_tasks` | `list`, `get`, `create`, `update`, `delete`, `start`, `stop`, `force_stop`, `pause`, `inspect_run` |
 | `manage_quicksprints` | `list_templates`, `get_template`, `create_template`, `update_template`, `delete_template`, `execute`, `start` |
 | `manage_scheduler` | `list`, `create`, `update`, `delete`, `run_due`, `schedule_sprint`, `schedule_quicksprint`, `schedule_chat`, `schedule_node_flow` |
-| `scheduler_code_ux` | `list`, `schedule_wakeup`, `schedule_task`, `cancel` |
+| `scheduler_code_ux` | `list`, `schedule_wakeup`, `cancel` |
 | `manage_agents` | `list`, `get`, `create`, `update`, `delete`, `sync` |
 | `manage_node_flows` | `list`, `get`, `create`, `update`, `delete`, `validate`, `run`, `list_runs`, `get_run`, `attach_to_agent`, `detach_from_agent` |
 | `manage_memory` | `list`, `get`, `count`, `create`, `update`, `delete`, `search`, `promote`, `get_map`, `model_status`, `start_reembed` |
@@ -92,15 +91,19 @@ updates, deletion, and due-entry execution.
 
 Allowed actions:
 
-- `list` — requires `projectId`; returns only `agent_scheduler` wakeup/task entries created by the calling agent.
-- `schedule_wakeup` — requires `projectId`, `bodyMarkdown`, and either `scheduledFor`, `delaySeconds`, or `delayMinutes`; optional `title`, `timezone`, `threadId`, and `connectionId`.
-- `schedule_task` — requires `projectId`, `taskId`, and either `scheduledFor`, `delaySeconds`, or `delayMinutes`; optional `title`, `timezone`, and `provider`.
+- `list` — requires `projectId`; returns only `agent_scheduler` wakeup entries created by the calling agent.
+- `schedule_wakeup` — requires `projectId`, `bodyMarkdown`, and exactly one timing mode: `scheduledFor`, `delaySeconds`/`delayMinutes`, `wakeAfterReply: true`, `afterSprintId`, or `afterTaskId`; optional `offsetMinutes`, `title`, `timezone`, `threadId`, and `connectionId`.
 - `cancel` — requires `entryId`; changes the entry status to `cancelled` only when the entry was created by the calling agent through `scheduler_code_ux`.
 
+`wakeAfterReply: true` creates a due-now wakeup that the dashboard chat runtime drains immediately after
+the current reply is sent, allowing an agent to answer first and continue with MCP calls in the next
+turn. `afterSprintId` and `afterTaskId` create one-time completion anchors; `offsetMinutes` delays the
+wakeup after the source sprint or task finishes.
+
 Security model: Code UX stamps restricted scheduler entries with `origin: "agent_scheduler"`,
 `source: "agent_scheduler"`, and `createdByAgentId` from the current MCP agent context. The server
 enforces this metadata on list and cancel, so an agent cannot cancel dashboard-created entries,
-entries created through `manage_scheduler`, or entries created by another agent. The restricted tool
+task entries, entries created through `manage_scheduler`, or entries created by another agent. The restricted tool
 does not expose `run_due`, arbitrary updates, recurrence editing, sprint or quicksprint scheduling,
 memory remediation, or global scheduler destructive controls.
 

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

@@ -118,6 +118,6 @@ Agent MCP access is default-deny. If a preset has no saved MCP access record, Co
 
 The **Connected MCPs** editor panel opens a risk-gated manager for Code UX tools. Turning on Code UX for the dashboard reply agent enables the built-in MCP surface plus the restricted `scheduler_code_ux` tool. Turning on Code UX for other agents keeps `scheduler_code_ux` explicitly disabled by default while broader tools remain visible for review.
 
-Scheduler access lets an agent create its own wakeups or task reruns through the secured agent scheduler surface. It does not grant full scheduler administration, due-entry execution, recurrence editing, sprint scheduling, or destructive scheduler actions.
+Scheduler access lets an agent create its own wakeups through the secured agent scheduler surface. It does not grant full scheduler administration, due-entry execution, recurrence editing, sprint scheduling, task reruns, or destructive scheduler actions.
 
-The dashboard reply route always receives Code UX MCP plus scheduler for dashboard chat turns. Enabling scheduler or any other Code UX tool for planning, coding, QA, CI repair, merge-conflict, or other non-chat agents is riskier because those agents run during operational workflows and can affect project state without being part of a direct dashboard chat exchange.
+The dashboard reply route always receives the full built-in Code UX MCP surface plus scheduler for dashboard chat turns. Enabling scheduler or any other Code UX tool for planning, coding, QA, CI repair, merge-conflict, or other non-chat agents is riskier because those agents run during operational workflows and can affect project state without being part of a direct dashboard chat exchange.

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

@@ -27,17 +27,28 @@ target JSON payload, validate that the flow belongs to the selected project, and
 node-flow runtime with scheduler trigger metadata when due. Blank dashboard input is omitted, and
 supplied input must be a JSON object.
 
-The backend scheduler contract also supports agent-created wakeups and scheduled task reruns.
-Agent wakeups and task reruns are stored in the same target JSON payload with `origin` and `source` set to
+The backend scheduler contract also supports agent-created wakeups.
+Agent wakeups are stored in the target JSON payload with `origin` and `source` set to
 `agent_scheduler`, plus `createdByAgentId` when the creating agent provides it. Agent wakeups post
-through the chat runtime with scheduler metadata, and task reruns reuse the normal task rerun
-service so workspaces, telemetry, and cancellation behavior stay consistent.
+through the chat runtime with scheduler metadata.
 
-Agent wakeups and task reruns may appear in the Scheduler calendar, day view, stats, and scheduled
+Agent wakeups may appear in the Scheduler calendar, day view, stats, and scheduled
 entry list after they are created by the secured MCP scheduler tool. They use their own target
 labels and compact summaries instead of appearing as chat messages. The dashboard create/edit form
 supports Sprint, Quicksprint, Node flow, Message, and Memory remediation entries; MCP-created agent
-wakeups and task reruns can still be paused, resumed, or deleted from the list.
+wakeups can still be paused, resumed, or deleted from the list.
+
+Agent wakeups created through `scheduler_code_ux` can use one timing mode at a time:
+
+- an absolute `scheduledFor` timestamp
+- a positive `delaySeconds` or `delayMinutes` value
+- `wakeAfterReply: true`, which wakes the agent immediately after its current dashboard reply is sent
+- `afterSprintId`, with optional `offsetMinutes`, to wake after a sprint reaches a terminal state
+- `afterTaskId`, with optional `offsetMinutes`, to wake after a task reaches a terminal project status
+
+Completion-anchored wakeups are one-time entries. Sprint anchors use the terminal sprint run finish
+time when available, and task anchors use terminal task run or dispatch finish evidence before
+falling back to the task update time.
 
 ## Recurrence
 

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

@@ -793,9 +793,9 @@ Controls which built-in Code UX MCP tool categories are available to containeriz
 
 **What it controls:** Tool-category and individual-tool toggles decide what trusted provider and project-manager clients may call on their next run. Agent presets add their own access layer in the Agents editor.
 
-**Recommended defaults:** Keep the global surface aligned with project-manager workflows. Dashboard chat receives Code UX MCP plus scheduler at runtime. For individual non-dashboard agents, start with Code UX disabled; if built-in tools are enabled, keep scheduler disabled unless the preset specifically needs agent-owned wakeups or task reruns.
+**Recommended defaults:** Keep the global surface aligned with project-manager workflows. Dashboard chat receives the full built-in Code UX MCP surface plus scheduler by default for the assigned reply agent. For individual non-dashboard agents, start with Code UX disabled; if built-in tools are enabled, keep scheduler disabled unless the preset specifically needs agent-owned wakeups.
 
-**Risks and gotchas:** Disabling required tools can make provider workflows fail; enabling broad tools increases capability exposure. The restricted `scheduler_code_ux` tool lets an agent create its own wakeups or task reruns, while `manage_scheduler` and other management tools expose broader runtime control. Non-chat agents should not receive scheduler or management tools unless that capability is intentional.
+**Risks and gotchas:** Disabling required tools can make provider workflows fail; enabling broad tools increases capability exposure. The restricted `scheduler_code_ux` tool lets an agent create its own wakeups, while `manage_scheduler` and other management tools expose broader runtime control. Non-chat agents should not receive scheduler or management tools unless that capability is intentional.
 
 Related docs: