@zhangj1164/dsh-github-issue 0.3.0 → 0.4.0

package/README.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write packages/github-issue/dsh-github-issue/README.md
-README.md: 94d588e442d78a17a570ab9d177c963df7fdcf4a
-README.zh.md: a71d9f46f33066ae18b10b86fd6ad6d1c3f689fd
+README.md: 8bea5576f968f66e8eadb75bf5d6da52c2501df0
+README.zh.md: d52ed1b3284b6c2d5e62eb3c5615c3396734b9ef

package/README.md

@@ -28,6 +28,7 @@ GitHub issue generation and optimization service for DeepSeek Harness. Builds st
 | `autopilotPreset` | empty | Agent preset the dispatched Sessions run. Empty follows the deployment default. |
 | `autopilotTimeZone` | empty | IANA zone "today" is measured in. Empty follows the host's own zone, so the user's local midnight starts a new day. |
 | `autopilotPrompt` | the built-in template | Prompt handed to every dispatched Session. Placeholders `{number}`, `{title}`, `{url}`, `{body}`, and `{labels}` are replaced; an unknown placeholder stays visible. |
+| `dispatchTaskDelaySeconds` | `1` | Seconds between registering a dispatch's automation task and its delivery, 1–3600. The Schedule service refuses a non-positive delay, so this cannot be `0`. |
 
 **Settings-editable fields.** Eight of these fields — `repoUrl`, `claimLabel`, `maxIssuesPerRun`, `autopilotEnabled`, `autopilotCwd`, `autopilotPreset`, `autopilotTimeZone`, and `autopilotPrompt` — are declared `.volatile()`, which is what lets `@zhangj1164/dsh-client-ui-memo-settings` expose them in the Settings panel: `dsh-settings` projects only volatile fields, an accepted write lands in the profile's user layer, and the service reads each value where it is used instead of copying it at construction, so the change reaches the running process without a restart. `autopilotEnabled` is read by the `Service.init` startup check, so flipping it applies from the next host start. The remaining fields stay deployment-only.
 
@@ -40,7 +41,7 @@ GitHub issue generation and optimization service for DeepSeek Harness. Builds st
 | `optimizeIssue(request)` | Rewrites a natural-language description into a structured issue following a pinned Markdown template. Returns `empty-input` for blank descriptions, `route-missing` when no route resolves, `llm-failure` when the model call failed. |
 | `createIssue(request)` | Files the report through the GitHub REST API and returns the created issue's `{ number, url }`. The body is filed without its leading `## title` heading, because GitHub takes the title as its own field. |
 | `listClaimableIssues(request)` | Lists the open issues carrying the claim label, excluding pull requests, which GitHub's issue endpoints also return. |
-| `dispatchIssue(request)` | Creates one Session through the Session controller, queues the rendered prompt on its Agent, names the Session, and returns its `sessionId`. |
+| `dispatchIssue(request)` | Creates one Session through the Session controller, names it, and registers the rendered prompt as a one-shot automation task on the Schedule service, which delivers it into that Session; returns its `sessionId`. A deployment that mounts no Schedule service admits the prompt directly instead. |
 | `runIntake(request)` | Runs one pass: lists the claimable issues, skips those an earlier pass already dispatched, dispatches the rest, and records the local day durably. |
 
 The intake methods report one stable failure code instead of a raw `fetch` error: `auth-missing`, `auth-failure`, `rate-limited`, `invalid-repo`, `invalid-request`, `http-failure`, `network-failure`, `session-unavailable`, or `dispatch-failed`. `auth-missing` is separate from `auth-failure` because no credential and a rejected credential are different deployment problems with different fixes.
@@ -79,13 +80,13 @@ Both `generateReport` and `optimizeIssue` use built-in system prompts that pin a
 
 The loop has three steps, and this plugin owns the last two. The user describes a problem in natural language, `optimizeIssue` turns it into the pinned report, and `createIssue` files it. That replaces the point where the loop used to stop: a pre-filled URL still required the user to open the form and press Submit, so nothing could pick the issue up automatically.
 
-`runIntake` then reads the issues that carry `claimLabel` and hands each one to a fresh Session. Dispatch goes through the Session controller rather than the Agent registry directly, so the dispatched Session gets the same preset and workspace policy as one the user opened in the Web; the prompt is queued with the Agent's `followup`, which wakes the driver without waiting for a turn to be open elsewhere. Naming the Session is best-effort: a deployment that mounts no title service still gets a working Session.
+`runIntake` then reads the issues that carry `claimLabel` and hands each one to a fresh Session, registered as a one-shot automation task. The Session is created through the Session controller, so it gets the same preset and workspace policy as one the user opened in the Web. The work is handed over as a task on the Schedule service — the same board the Web's **Automation tasks** page lists — and that service delivers the rendered prompt into the Session when the task comes due. A task always belongs to an existing Session, so the Session is created first; a deployment that mounts no Schedule service (a non-Web composition) admits the prompt directly with the controller's `prompt` instead, which is the same durable path the Web prompt uses: it records the message with a user source and queues it on the Session's Agent, resolving (and resuming) that Agent itself. Naming the Session is best-effort: a deployment that mounts no title service still gets a working Session.
 
 The credential is resolved once per process, in this order: `token`, then `tokenEnv`, then `tokenCommand`. The default command is `gh auth token`, so a machine already logged in to GitHub needs no extra secret; a deployment that manages secrets itself sets `token` and disables the command with an empty string. The token is never logged.
 
 ### First startup of the day
 
-`autopilotEnabled` turns on one check per local day at host startup. The local day is read from durable storage-domain state, so a restart later the same day does nothing, and an issue that was already dispatched is never dispatched again — its Session exists, and a second one would duplicate the work. The day is committed only after the listing succeeded, so a pass that could not reach GitHub is retried on the next startup instead of being remembered as done.
+`autopilotEnabled` turns on one check per local day at host startup. The local day is read from durable storage-domain state, so a restart later the same day does nothing, and an issue that was already dispatched is never dispatched again — its Session exists, and a second one would duplicate the work. The day is committed only after the listing succeeded, so a pass that could not reach GitHub is retried on the next startup instead of being remembered as done. A pass whose every dispatch failed is retried the same way: the day is committed only when an issue reached a Session or nothing needed dispatching, because remembering a broken dispatch as a finished day is what made a failing startup look like a day with nothing to do. The listing failure, the dispatch failures, and an intake state that cannot be opened are each written as a telemetry error event, so the reason a check did nothing is readable afterwards.
 
 The check needs durable state and refuses to run without one: without a memory of what it dispatched, a restart would open a second Session for the same issue. It is also off by default, because opening a Session without being asked is a deployment decision rather than something a plugin install does on its own.
 
@@ -103,7 +104,21 @@ The check needs durable state and refuses to run without one: without a memory o
         claimLabel: ready-for-agent
 ```
 
-The host must be running for the check to happen at all; a day with no startup is a day with no check. That is the intended behavior — the check is a startup hook, not a scheduler — and the Automation tasks page remains the place to inspect or manage reminders the Session itself creates.
+The host must be running for the check to happen at all; a day with no startup is a day with no check. That is the intended behavior — the check is a startup hook, not a scheduler — and the Automation tasks page now lists each dispatch as the one-shot task it registers, with the delivered ones showing as ended.
+
+A dispatched Session runs the repository workflow itself, and that workflow starts with `git fetch`. Under the default `workspace-write` sandbox a network command is blocked and raises an approval prompt that an unattended dispatch cannot answer, so a deployment that wants the loop to run on its own should pin the permission preset to `danger-full-access` in its own patch layer:
+
+```yaml
+- id: permission
+  config:
+    presets:
+      read-only: { sandbox: read-only, approval: ask }
+      workspace-write: { sandbox: workspace-write, approval: ask }
+      danger-full-access: { sandbox: danger-full-access, approval: never }
+    defaultPreset: danger-full-access
+```
+
+That is a deployment-wide choice: it applies to every new Session the host creates, not only to dispatched ones.
 
 ## Requirement mapping
 
@@ -166,5 +181,5 @@ Every subpath resolves to the flat `lib/*.js` layout tsdown emits.
 
 - **Model dependency** — `inject: ['llm']` means the service will not activate without an LLM provider.
 - **No browser UI of its own** — this package registers no model tool and ships no browser UI. Installing it on its own gives a deployment `ctx.get('githubIssue')` and nothing a user can see or click; the visible entry point is `@zhangj1164/dsh-client-ui-memo`'s issue editor, whose "File on GitHub" button and log-analysis action reach it over Remote. Treat it as a backend that a UI plugin consumes, not as a standalone feature.
-- **Dispatch needs the Web composition** — `dispatchIssue` and `runIntake` read `ctx.get('sessionController')` and `ctx.get('agents')`. A headless or SDK-only composition that mounts neither reports `session-unavailable` and files or lists issues only.
+- **Dispatch needs the Web composition** — `dispatchIssue` and `runIntake` read `ctx.get('sessionController')` and, when it exists, `ctx.get('schedule')`. A headless or SDK-only composition that mounts no Session controller reports `session-unavailable` and files or lists issues only; one that mounts a controller but no Schedule service still dispatches, admitting the prompt directly.
 - **The first-startup check is a startup hook, not a scheduler** — it runs only when the host starts. A deployment that keeps the host running across midnight gets the check on the next start, not at midnight.

package/README.zh.md

@@ -28,6 +28,7 @@ DSH 的 GitHub issue 生成与优化服务。从遥测分析构建结构化 issu
 | `autopilotPreset` | 空 | 派发会话使用的 agent preset。空值跟随部署默认。 |
 | `autopilotTimeZone` | 空 | 判定「今天」所用的 IANA 时区。空值跟随宿主自身时区，因此用户的本地午夜才是新一天的开始。 |
 | `autopilotPrompt` | 内置模板 | 交给每个派发会话的提示词模板。占位符 `{number}`、`{title}`、`{url}`、`{body}`、`{labels}` 会被替换；未知占位符保留原样可见。 |
+| `dispatchTaskDelaySeconds` | `1` | 派发时登记的自动化任务从登记到送达的秒数，1–3600。Schedule 服务拒绝非正数延迟，所以不能是 `0`。 |
 
 **可在设置页编辑的字段。** 其中八个——`repoUrl`、`claimLabel`、`maxIssuesPerRun`、`autopilotEnabled`、`autopilotCwd`、`autopilotPreset`、`autopilotTimeZone`、`autopilotPrompt`——声明了 `.volatile()`，这正是 `@zhangj1164/dsh-client-ui-memo-settings` 能把它们放进设置面板的原因：`dsh-settings` 只投影易变字段，被接受的写入落进 profile 的用户层，而服务在用到的位置读取每个值、不在构造时拷贝，因此改动无需重启就能到达运行中的进程。`autopilotEnabled` 由 `Service.init` 的启动检查读取，拨动它从下一次宿主启动生效。其余字段仍只属于部署层。
 
@@ -40,7 +41,7 @@ DSH 的 GitHub issue 生成与优化服务。从遥测分析构建结构化 issu
 | `optimizeIssue(request)` | 将自然语言描述重写为按固定 Markdown 模板组织的 issue。空描述返回 `empty-input`，无路由可解析时返回 `route-missing`，模型调用失败返回 `llm-failure`。 |
 | `createIssue(request)` | 经 GitHub REST API 直接建单，返回新 issue 的 `{ number, url }`。正文写入时会去掉首行的 `## 标题`，因为 GitHub 把标题作为独立字段。 |
 | `listClaimableIssues(request)` | 列出带接单标签的 open issue，并排除 PR——GitHub 的 issue 端点也会返回 PR。 |
-| `dispatchIssue(request)` | 经 Session 控制器新建一个会话，把渲染后的提示词排进它的 Agent，并给会话命名；返回 `sessionId`。 |
+| `dispatchIssue(request)` | 经 Session 控制器新建一个会话并命名，把渲染后的提示词登记为该会话上的一次性自动化任务，由 Schedule 服务送达；返回 `sessionId`。没有挂载 Schedule 服务的部署改为直接排入提示词。 |
 | `runIntake(request)` | 执行一次接单：列出可接单 issue，跳过此前已派发的，派发其余，并把本地日期持久化。 |
 
 接单方法只报一个稳定的失败码，而不是原始的 `fetch` 错误：`auth-missing`、`auth-failure`、`rate-limited`、`invalid-repo`、`invalid-request`、`http-failure`、`network-failure`、`session-unavailable`、`dispatch-failed`。`auth-missing` 与 `auth-failure` 分开，是因为「没有凭据」和「凭据被拒绝」是两种部署问题，修法不同。
@@ -79,13 +80,13 @@ DSH 的 GitHub issue 生成与优化服务。从遥测分析构建结构化 issu
 
 闭环有三步，本插件负责后两步。用户用自然语言描述问题，`optimizeIssue` 把它变成固定模板的报告，`createIssue` 直接建单。这一步替换掉闭环原本停住的地方：预填 URL 仍然要用户打开表单并按下提交，任何东西都无法自动接住这个 issue。
 
-`runIntake` 随后读取带 `claimLabel` 的 issue，并把每个交给一个新会话。派发走 Session 控制器而不是直接走 Agent 注册表，这样派发出来的会话与用户在 Web 里新建的会话拿到相同的 preset 与工作区策略；提示词经 Agent 的 `followup` 排入，它会唤醒驱动，而不需要别处已经有一个打开的 turn。命名是尽力而为：没有挂载标题服务的部署依然得到一个可用的会话。
+`runIntake` 随后读取带 `claimLabel` 的 issue，并把每个交给一个新会话，同时登记为一次性自动化任务。会话经 Session 控制器创建，因此与用户在 Web 里新建的会话拿到相同的 preset 与工作区策略；工作本身以任务的形式交给 Schedule 服务——也就是 Web「自动化任务」页面列出的那块面板——由它在任务到点时把渲染好的提示词送进该会话。任务永远绑定一个已存在的会话，所以会话先建；没有挂载 Schedule 服务的部署（非 Web 组合）改为用控制器的 `prompt` 直接排入提示词，那正是 Web 端发提示词走的同一条持久路径：把消息以用户来源记录下来，排进会话 Agent 的收件箱，由控制器自己解析（必要时先恢复）那个 Agent。命名是尽力而为：没有挂载标题服务的部署依然得到一个可用的会话。
 
 凭据每个进程只解析一次，顺序是 `token`、`tokenEnv`、`tokenCommand`。默认命令是 `gh auth token`，因此已经登录 GitHub 的机器不需要额外密钥；自行管理密钥的部署设置 `token` 并用空字符串停用命令。token 永远不会被记录到日志。
 
 ### 每天首次启动
 
-`autopilotEnabled` 打开后，宿主启动时每个本地日期执行一次检查。本地日期从 storage-domain 的持久状态读取，因此同一天稍后重启什么也不做，已派发的 issue 永不再次派发——它的会话已经存在，再来一个只会重复劳动。只有列取成功后才提交日期，所以连不上 GitHub 的那次会在下次启动重试，而不会被记成已完成。
+`autopilotEnabled` 打开后，宿主启动时每个本地日期执行一次检查。本地日期从 storage-domain 的持久状态读取，因此同一天稍后重启什么也不做，已派发的 issue 永不再次派发——它的会话已经存在，再来一个只会重复劳动。只有列取成功后才提交日期，所以连不上 GitHub 的那次会在下次启动重试，而不会被记成已完成。每次派发都失败的那一次同样会重试：只有在有 issue 进入会话、或本来就没有需要派发的东西时才提交日期——把一次坏掉的派发记成「今天查过了」，正是让失败的启动看起来像「当天无事可做」的原因。列取失败、派发失败，以及打不开接单状态，都会写一条 telemetry 错误事件，事后能读到这次检查为什么什么都没做。
 
 检查需要持久状态，没有就拒绝运行：没有「派发过什么」的记忆，重启会为同一个 issue 打开第二个会话。它也默认关闭，因为未经请求就打开会话是部署决定，而不是插件安装时自带的行为。
 
@@ -103,7 +104,21 @@ DSH 的 GitHub issue 生成与优化服务。从遥测分析构建结构化 issu
         claimLabel: ready-for-agent
 ```
 
-宿主必须在运行，检查才可能发生；没有启动的一天就没有检查。这是有意的行为——检查是启动钩子，不是调度器——Automation tasks 页面仍然是查看和管理会话自身创建的提醒的地方。
+宿主必须在运行，检查才可能发生；没有启动的一天就没有检查。这是有意的行为——检查是启动钩子，不是调度器——而「自动化任务」页面现在会列出每次派发登记的那条一次性任务，已送达的显示为已结束。
+
+派发出来的会话要自己跑仓库流程，第一步就是 `git fetch`。默认的 `workspace-write` 沙箱会拦住联网命令并弹出审批，而无人值守的派发无法回答它；因此想让闭环自己跑起来的部署，应在自己的 patch 层把权限预设固定为 `danger-full-access`：
+
+```yaml
+- id: permission
+  config:
+    presets:
+      read-only: { sandbox: read-only, approval: ask }
+      workspace-write: { sandbox: workspace-write, approval: ask }
+      danger-full-access: { sandbox: danger-full-access, approval: never }
+    defaultPreset: danger-full-access
+```
+
+这是部署级取舍：它对宿主新建的每个会话生效，而不只是派发的会话。
 
 ## 需求映射
 
@@ -166,5 +181,5 @@ dsh plugin --profile web add @zhangj1164/dsh-telemetry @zhangj1164/dsh-github-is
 
 - **模型依赖** — `inject: ['llm']` 意味着服务在没有 LLM 提供方时不会激活。
 - **自身没有浏览器界面** — 本包不注册模型工具，也不附带浏览器 UI。单独安装只会给部署带来 `ctx.get('githubIssue')`，用户看不到也点不到任何东西；可见的入口是 `@zhangj1164/dsh-client-ui-memo` 的 issue 编辑器（其「直接提交到 GitHub」按钮）与日志分析动作，它们经 Remote 调用本服务。请把它当作供 UI 插件消费的后端，而不是一个能独立使用的功能。
-- **派发需要 Web 组合** — `dispatchIssue` 与 `runIntake` 读取 `ctx.get('sessionController')` 与 `ctx.get('agents')`。两者都没挂载的 headless 或纯 SDK 组合会返回 `session-unavailable`，只能建单和列取。
+- **派发需要 Web 组合** — `dispatchIssue` 与 `runIntake` 读取 `ctx.get('sessionController')`，存在时再读 `ctx.get('schedule')`。没有 Session 控制器的 headless 或纯 SDK 组合会返回 `session-unavailable`，只能建单和列取；有控制器但没有 Schedule 服务的组合仍能派发，只是改为直接排入提示词。
 - **首次启动检查是启动钩子，不是调度器** — 它只在宿主启动时运行。跨过午夜仍保持运行的部署会在下一次启动时检查，而不是在午夜检查。

package/lib/index.d.ts

@@ -142,6 +142,16 @@ interface Config {
    * location and points at the repository workflow.
    */
   readonly autopilotPrompt: Volatile<string>;
+  /**
+   * Seconds between registering a dispatch's automation task and its delivery.
+   *
+   * The Schedule service refuses a non-positive delay, so this is at least one
+   * second. It stays a deployment-level value instead of a constant because a
+   * deployment may want the task to sit visibly on the board before it fires,
+   * and it stays out of the settings surface: it times a dispatch, it does not
+   * describe one.
+   */
+  readonly dispatchTaskDelaySeconds: number;
 }
 /** Schemastery configuration for the GitHub-issue service. */
 declare const Config: s<Config>;
@@ -287,13 +297,21 @@ declare class GithubIssueService extends TypertRemoteService {
    */
   runIntake(request?: GithubIssueIntakeRequest): Promise<GithubIssueIntakeResult>;
   /**
-   * Create one Session, queue the issue prompt, and name the Session.
+   * Create one Session, register its automation task, and name the Session.
+   *
+   * A dispatch is two steps. The Session is created through the controller, so
+   * the deployment's preset and workspace policy apply. The work is then handed
+   * over as a one-shot automation task on the Schedule service: the task shows
+   * up in the Web's automation board, and the service delivers its prompt into
+   * that Session when the task becomes due. A task is always bound to an
+   * existing Session — the board never opens one by itself — so the Session has
+   * to exist first, and registering the task is what makes the dispatch visible
+   * beyond the sidebar.
    *
-   * The Session is created through the Session controller rather than the Agent
-   * registry directly: the controller applies the deployment's preset and
-   * workspace policy, so the dispatched Session behaves like one the user
-   * opened from the Web. The prompt is queued with the Agent's followup, which
-   * wakes the driver without waiting for a turn to be open elsewhere.
+   * A deployment that mounts no Schedule service (a non-Web composition) falls
+   * back to admitting the prompt directly, the same durable admission the Web
+   * prompt uses. Both paths fail the dispatch when the host refuses, so a
+   * refusal never leaves the day marked as checked.
    *
    * @param request - the issue and optional Session placement.
    * @returns the created Session, or a stable failure.

package/lib/index.js

@@ -598,7 +598,8 @@ const Config = s.object({
 	autopilotCwd: s.string().default("").volatile(),
 	autopilotPreset: s.string().default("").volatile(),
 	autopilotTimeZone: s.string().default("").volatile(),
-	autopilotPrompt: s.string().default(DEFAULT_DISPATCH_PROMPT).volatile()
+	autopilotPrompt: s.string().default(DEFAULT_DISPATCH_PROMPT).volatile(),
+	dispatchTaskDelaySeconds: s.number().step(1).min(1).max(3600).default(1)
 });
 /** The built-in system prompt that structures a natural-language issue description. */
 const OPTIMIZE_SYSTEM_PROMPT = [
@@ -711,9 +712,31 @@ const SESSION_UNAVAILABLE = {
 	ok: false,
 	error: {
 		code: "session-unavailable",
-		message: "this deployment mounts no Session controller or Agent registry, so no issue can be dispatched"
+		message: "this deployment mounts no Session controller with prompt admission, so no issue can be dispatched"
 	}
 };
+/**
+* The longest title the Session and Schedule services accept.
+*
+* Both truncate or reject beyond this length, and the Schedule service rejects
+* with `invalid_prompt`, which would fail a dispatch that otherwise succeeded.
+* The number is that service's protocol limit, not a deployment knob, so it
+* lives here as a constant rather than in `Config`.
+*/
+const MAX_TITLE_LENGTH = 120;
+/**
+* Build the title a dispatch gives its Session and its automation task.
+*
+* The issue title is cut by code point rather than by UTF-16 unit: slicing a
+* string at a surrogate boundary would keep the length the service accepts but
+* leave a reader with half a character.
+* @param issue - the issue being dispatched.
+* @returns a title naming the issue, at most {@link MAX_TITLE_LENGTH} code points.
+*/
+function dispatchTitle(issue) {
+	const title = "Issue #" + issue.number + ": " + issue.title;
+	return title.length <= MAX_TITLE_LENGTH ? title : [...title].slice(0, MAX_TITLE_LENGTH).join("");
+}
 /** Promise-based `exec`, used only for the configured token command. */
 const execAsync = promisify(exec);
 /**
@@ -901,6 +924,11 @@ let GithubIssueService = (() => {
 			await this.openIntakeState();
 			if (!this.config.autopilotEnabled.get()) return;
 			if (!this.intakePersistent) {
+				this.trackError("startupIntake", {
+					code: "state-unavailable",
+					message: "autopilot is enabled but no durable intake state is available",
+					featureCodeRef: this.featureCode("startupIntake")
+				});
 				this.warn("autopilot is enabled but no durable intake state is available; skipping the startup check so it cannot dispatch the same issue twice");
 				return;
 			}
@@ -1118,7 +1146,16 @@ let GithubIssueService = (() => {
 				});
 			}
 			const checkedAt = Date.now();
-			await this.commitIntakeState(localDayKey(checkedAt, this.intakeTimeZone()), dispatched);
+			const day = localDayKey(checkedAt, this.intakeTimeZone());
+			if (dispatched.length === 0 && failures.length > 0) this.trackError("runIntake", {
+				code: "dispatch-failed",
+				message: "no issue was dispatched and " + failures.length + " failed: " + failures.map((entry) => "#" + entry.number + " " + entry.code).join(", "),
+				featureCodeRef: this.featureCode("runIntake")
+			}, {
+				claimable: listed.value.length,
+				failed: failures.map((entry) => entry.number)
+			});
+			else await this.commitIntakeState(day, dispatched);
 			return {
 				ok: true,
 				value: Object.freeze({
@@ -1132,21 +1169,28 @@ let GithubIssueService = (() => {
 			};
 		}
 		/**
-		* Create one Session, queue the issue prompt, and name the Session.
+		* Create one Session, register its automation task, and name the Session.
 		*
-		* The Session is created through the Session controller rather than the Agent
-		* registry directly: the controller applies the deployment's preset and
-		* workspace policy, so the dispatched Session behaves like one the user
-		* opened from the Web. The prompt is queued with the Agent's followup, which
-		* wakes the driver without waiting for a turn to be open elsewhere.
+		* A dispatch is two steps. The Session is created through the controller, so
+		* the deployment's preset and workspace policy apply. The work is then handed
+		* over as a one-shot automation task on the Schedule service: the task shows
+		* up in the Web's automation board, and the service delivers its prompt into
+		* that Session when the task becomes due. A task is always bound to an
+		* existing Session — the board never opens one by itself — so the Session has
+		* to exist first, and registering the task is what makes the dispatch visible
+		* beyond the sidebar.
+		*
+		* A deployment that mounts no Schedule service (a non-Web composition) falls
+		* back to admitting the prompt directly, the same durable admission the Web
+		* prompt uses. Both paths fail the dispatch when the host refuses, so a
+		* refusal never leaves the day marked as checked.
 		*
 		* @param request - the issue and optional Session placement.
 		* @returns the created Session, or a stable failure.
 		*/
 		async dispatch(request) {
 			const controller = optionalService(this.ctx, "sessionController");
-			const agents = optionalService(this.ctx, "agents");
-			if (controller === void 0 || agents === void 0) return SESSION_UNAVAILABLE;
+			if (controller === void 0 || typeof controller.prompt !== "function") return SESSION_UNAVAILABLE;
 			const cwd = firstNonBlank(request.cwd, this.config.autopilotCwd.get());
 			const agentPreset = firstNonBlank(request.agentPreset, this.config.autopilotPreset.get());
 			let sessionId;
@@ -1164,22 +1208,46 @@ let GithubIssueService = (() => {
 					}
 				};
 			}
-			const handle = agents.get(sessionId);
-			if (handle === void 0) return {
-				ok: false,
-				error: {
-					code: "dispatch-failed",
-					message: "Session \"" + sessionId + "\" was created but no live Agent was published for it"
+			const prompt = renderDispatchPrompt(this.config.autopilotPrompt.get(), request.issue);
+			const schedule = optionalService(this.ctx, "schedule");
+			if (schedule !== void 0 && typeof schedule.create === "function") {
+				let taskId;
+				try {
+					taskId = (await schedule.create(sessionId, {
+						prompt,
+						title: dispatchTitle(request.issue),
+						after_seconds: this.config.dispatchTaskDelaySeconds
+					})).id;
+				} catch (error) {
+					return {
+						ok: false,
+						error: {
+							code: "dispatch-failed",
+							message: "Session \"" + sessionId + "\" was created but its automation task was refused: " + describeError(error)
+						}
+					};
 				}
-			};
+				this.renameSession(controller, sessionId, dispatchTitle(request.issue));
+				this.track("dispatchIssue", "success", {
+					issue: request.issue.number,
+					sessionId,
+					taskId
+				});
+				return {
+					ok: true,
+					value: Object.freeze({ sessionId })
+				};
+			}
 			try {
-				handle.agent.followup({
+				await controller.prompt({
+					requestId: "github-issue:" + request.issue.number + ":" + sessionId,
+					sessionId,
+					mode: "queue",
 					content: [{
 						type: "text",
-						text: renderDispatchPrompt(this.config.autopilotPrompt.get(), request.issue)
-					}],
-					source: { kind: "github-issue" }
-				});
+						text: prompt
+					}]
+				}, new AbortController().signal);
 			} catch (error) {
 				return {
 					ok: false,
@@ -1189,7 +1257,7 @@ let GithubIssueService = (() => {
 					}
 				};
 			}
-			this.renameSession(controller, sessionId, "Issue #" + request.issue.number + ": " + request.issue.title);
+			this.renameSession(controller, sessionId, dispatchTitle(request.issue));
 			this.track("dispatchIssue", "success", {
 				issue: request.issue.number,
 				sessionId
@@ -1232,9 +1300,27 @@ let GithubIssueService = (() => {
 				if (this.intakeState.lastCheckedDay === today) return;
 				const result = await this.runIntake({});
 				if (!result.ok) {
+					this.trackError("startupIntake", {
+						code: result.error.code,
+						message: result.error.message,
+						featureCodeRef: this.featureCode("startupIntake")
+					});
 					this.warn("issue intake did not complete: " + result.error.code + ": " + result.error.message);
 					return;
 				}
+				if (result.value.failures.length > 0) {
+					const detail = result.value.failures.map((entry) => "#" + entry.number + " " + entry.code).join(", ");
+					this.trackError("startupIntake", {
+						code: "dispatch-failed",
+						message: "dispatched " + result.value.dispatched.length + " issue(s); failed: " + detail,
+						featureCodeRef: this.featureCode("startupIntake")
+					}, {
+						dispatched: result.value.dispatched.length,
+						failed: result.value.failures.map((entry) => entry.number)
+					});
+					this.warn("issue intake dispatched " + result.value.dispatched.length + " issue(s) and failed " + result.value.failures.length + ": " + detail);
+					return;
+				}
 				this.track("startupIntake", "success", { dispatched: result.value.dispatched.length });
 			} catch (error) {
 				this.warn("issue intake failed: " + describeError(error));
@@ -1260,6 +1346,11 @@ let GithubIssueService = (() => {
 				this.intakeState = table.get("intake") ?? EMPTY_INTAKE_STATE;
 				this.intakePersistent = true;
 			} catch (error) {
+				this.trackError("openIntakeState", {
+					code: "state-unavailable",
+					message: describeError(error),
+					featureCodeRef: this.featureCode("openIntakeState")
+				});
 				this.warn("intake state is unavailable: " + describeError(error));
 			}
 		}
@@ -1546,9 +1637,9 @@ function buildPrefillUrl(repoUrl, report, maxLength, note) {
 * Read one optional host service by its Cordis key.
 *
 * The intake loop works with services this package does not depend on: a
-* deployment may mount no storage, no Session controller, or no Agent registry.
-* Reading them by key keeps those features optional without turning the plugin
-* into a hard dependency of the whole Web composition.
+* deployment may mount no storage or no Session controller. Reading them by key
+* keeps those features optional without turning the plugin into a hard
+* dependency of the whole Web composition.
 *
 * @param ctx - the host context.
 * @param name - the service key.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@zhangj1164/dsh-github-issue",
   "description": "GitHub issue generation, filing, and intake service for DeepSeek Harness: structured reports from telemetry analysis, AI-optimized descriptions, direct issue creation, and first-startup dispatch of claimable issues to new Sessions",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/index.d.ts",