feat(desktop): warn that deleting a parent keeps and archives its subtasks

[liuxiaocs7]

Summary

Deleting a parent task permanently removes it, but its ordinary linked subagent subtasks are intentionally kept and moved to the archive rather than cascade-deleted (#1467 / #3151 — each subtask owns its own transcript, artifacts, and outputs). The delete confirm never said so and the completion gave no feedback, so the archived rows that appeared next — labelled 原父任务已删除 on Settings › 活动 › 已归档任务 — read as tasks from nowhere.

This adds two notices, without touching deletion semantics:

• The delete confirm now warns, when the task has linked subtasks, that they are kept and moved to Archived — the fact that they survive. It names no count: nobody decides differently between "3 subtasks" and "5", and a renderer-side estimate could disagree with what the Host actually archives.
• The completion toast reports how many subtasks moved, using the Host's executed count rather than an estimate.

The confirm's decision to warn is a renderer presence check off the live catalog (parentHasArchivableSubtasks in app-shell-session-row-actions.ts): ordinary subagents count, Agent Graph operators (subagentParent.graph) do not, and already-archived children do not. The exact number is owned by the Host: session.remove now returns archivedSubtaskCount (present only when it archived something, deduplicated by revision family in session-retirement-coordinator.ts), threaded through removeSession, the sessions:remove IPC, and the preload bridge to the toast. A restore that calls the delete off shows no subtask notice, since nothing moved. Copy lives in shell-copy.ts (zh + en).

Fixes #3780

Review follow-up (superseding an earlier revision of this PR)

The first version computed the count in the renderer (countArchivableSubtasks) as a second implementation of the Host's removal plan. As raised in review, that estimate diverged from the Host — the conversationCopy?.state !== 'preparing' filter is not implementable off SessionSummary, and the parent-link fallback read a field the Host ignores — so it could name a wrong number. The count now comes from the Host, and the confirm names no number at all.

Verification

• biome lint on the 14 changed files — clean.
• tsc -p tsconfig.main.json, tsconfig.renderer.json, tsconfig.preload.json (--noEmit) — all pass; @maka/runtime-host build — clean.
• Unit suites pass:
  • session-retirement-protocol.test.ts — archivedSubtaskCount round-trips on a removed result, is absent when nothing was archived, and a negative value is rejected.
  • session-retirement-coordinator.test.ts — a parent with 32 distinct subagent children reports archivedSubtaskCount: 32; graph-operator and already-archived cases stay countless.
  • runtime-host-client-operations.test.ts / runtime-host-client-uds.test.ts — removeSession / the sessions:remove IPC surface the count verbatim ({ disposition, archivedSubtaskCount }).
  • app-shell-session-row-actions-revisions.test.ts — the confirm warns without a number when the family has archivable subtasks; the toast reports the Host's count; graph operators / archived children / other parents raise no notice; a concurrent restore leaves the toast silent.
• e2e parent-session-deletion.spec.ts — asserts the confirm warns about the subtask (no count); not run in this environment (needs the Electron build + Playwright). Run with npm --workspace @maka/desktop run e2e -- parent-session-deletion.

Screenshots

Delete confirm — warns the linked subtasks are kept and archived (the current copy names no count; the image below predates the review follow-up and still shows one):

Completion toast — reports how many subtasks moved to Archived (now the Host's executed count):

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — traced the delete/archive path, wrote the copy, the parentHasArchivableSubtasks presence check, the archivedSubtaskCount wiring from the Host coordinator through the protocol, client, IPC, and preload to the toast, and the unit/e2e coverage. Commits carry a Generated-by: Claude Code trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

The gap is real — archived rows labelled 原父任务已删除 appearing with no warning is confusing, and telling people beforehand is the right fix. One note on how, non-blocking.

[P2] The count is a second implementation of the Host's plan, and already disagrees

countArchivableSubtasks re-derives what #readRemovalPlanSessionIds decides, and two rules differ:

One of them can't be implemented here. The Host filters conversationCopy?.state !== 'preparing' in two places (session-retirement-coordinator.ts:516,521). SessionSummary has no conversationCopy field — I grepped the whole interface. A subtask mid-copy counts in the confirm and isn't archived by the Host.

Parent resolution differs. linkedSubagentParentSessionId falls back to session.subagent?.parentSessionId (session.ts:641); the Host reads only header.subagentParent.parentSessionId (:518). A session with subagent but no subagentParent counts here and not there.

Both skew high. Normal user path, display-only, recoverable — hence P2.

The smaller shape

The toast doesn't need an estimate at all. By then the Host has executed its plan and knows the real number; having deleteSession return it costs nothing and is correct by construction.

For the confirm, I'd drop the number. Nobody decides differently between "3 subtasks will be kept and archived" and "5" — what matters is the fact that they survive. Without the number, countArchivableSubtasks disappears along with most of the new test file, and the toast reports something true.

If you'd rather keep an exact count in the confirm, that needs a removal-plan preview from the Host — a new operation, but then the renderer stops guessing. Your call; I'm fine either way, just not with a number that can be wrong.

简体中文

这个缺口是真的——归档列表里冒出标着「原父任务已删除」的行却毫无预告，确实让人困惑，提前告知是对的解法。关于怎么做有一条意见，不阻塞。

[P2] 这个数字是 Host 计划的第二次实现，而且已经不一致

countArchivableSubtasks 重新推导了 #readRemovalPlanSessionIds 的判定，有两条规则不同：

其中一条在这里实现不了。 Host 在两处过滤 conversationCopy?.state !== 'preparing'（session-retirement-coordinator.ts:516,521），而 SessionSummary 没有 conversationCopy 字段——我把整个 interface grep 过了。正在被复制的子任务会计入 confirm，但 Host 不会归档它。

父级判定不同。 linkedSubagentParentSessionId 会回退到 session.subagent?.parentSessionId（session.ts:641），而 Host 只读 header.subagentParent.parentSessionId（:518）。只有 subagent 没有 subagentParent 的会话，这里算、Host 不算。

两条都让数字偏大。正常用户路径，纯显示，可恢复——所以是 P2。

更小的形状

toast 那半边根本不需要估算。到那时 Host 已经执行完计划，知道真实数字；让 deleteSession 把它返回来没有任何代价，而且天然正确。

confirm 那半边，我会把数字去掉。没有人会因为「3 个子任务会被保留并归档」和「5 个」而做出不同决定——重要的是它们会存活这个事实。不带数字的话，countArchivableSubtasks 连同新测试文件的大部分一起消失，而 toast 报的数是真的。

如果你更希望 confirm 里保留精确数字，那需要 Host 提供一次 removal-plan preview——多一个操作，但渲染层不再猜。你定；两种我都可以，只是不希望留一个可能是错的数字。

[Astro-Han]

I reviewed this head and found no blocking issues.

Deleting a parent now correctly warns that ordinary subtasks are retained and archived (count via live catalog, deduplicated, excluding graph operators), matching Host readRemovalPlan. No new state or protocol; notifications now match the post-delete visible row.

No P0-P3.

简体中文

该头未发现阻断。

[liuxiaocs7]

Thanks — took the smaller shape (see the latest revision on the branch).

Toast: session.remove now returns archivedSubtaskCount (deduplicated by revision family in the coordinator, present only when it archived something), threaded through removeSession, the sessions:remove IPC, and the preload bridge. The toast reports the Host's executed number, so it's correct by construction — no estimate.

Confirm: dropped the number. It now warns only that linked subtasks are kept and moved to Archived — the fact that they survive. countArchivableSubtasks is gone; what's left is a presence check (parentHasArchivableSubtasks) that decides whether to warn, and most of the count-specific test file went with it.

Both divergences you flagged are moot now — the renderer no longer re-derives the plan, so the conversationCopy filter it couldn't implement and the subagent?.parentSessionId fallback the Host ignores no longer skew a number that's shown to anyone.

Also rebased onto current main and moved RUNTIME_HOST_COMPATIBILITY_EPOCH past main's value (now 51): the new optional field on the removed result is rejected by an older peer's strict (requireExactRecord) decoder, so this is an incompatible change and must move the epoch.

简体中文

多谢——按更小的形状改了(见分支上的最新一版)。

toast:session.remove 现在返回 archivedSubtaskCount(在 coordinator 里按 revision family 去重,只有归档了东西时才带上),经 removeSession、sessions:remove IPC、preload bridge 一路传到 toast。toast 报的是 Host 执行后的真实数字,天然正确,不再估算。

confirm:去掉了数字。现在只警告子任务会被保留并移入归档这个事实。countArchivableSubtasks 删掉了,剩下的是一个只决定「要不要警告」的存在性检查(parentHasArchivableSubtasks),新测试里大部分针对计数的用例也随之删除。

你指出的两条不一致现在都不成立了——渲染层不再重新推导计划,所以那条实现不了的 conversationCopy 过滤、以及 Host 忽略的 subagent?.parentSessionId 回退,都不会再让一个展示给用户的数字偏大。

另外已 rebase 到最新 main,并把 RUNTIME_HOST_COMPATIBILITY_EPOCH 提到 main 之上(现在是 51):removed 结果新增的可选字段会被旧 peer 的严格解码器(requireExactRecord)拒收,属不兼容变更,必须推进 epoch。

[Astro-Han]

Update on a3432eba7e:

[P2] Deletion warning uses missing graph marker — false archive promise

parentHasArchivableSubtasks() checks session.subagentParent.graph, but catalog projection strips it to {parentSessionId} only; renderer always takes fallback and claims subtasks will be archived, while Host actually retires graph children with count 0 — dialog contradicts execution.

Fix: carry graph/operator marker through catalog authority to renderer (bump epoch) or make this a Host-owned preflight with real projection test.

Checks on a3432eba7e930ebbea11c2b4681f2ea41bf6584d are test: SUCCESS (32876519613) — code is NO-GO.

简体中文

删除提示与实际执行不一致。

[Astro-Han]

Update on 15dd64a11f:

[P2] Preview is fail-open and not bound to remove plan

app-shell-session-row-actions.ts:170-185 swallows preview errors and proceeds with 0 count; protocol carries only sessionId without revision/digest. Race: preview says no archivable children, but by confirm time a subtask was unarchived or preview transiently failed — delete silently archives without warning, contradicting the confirmation purpose.

Fix: fail-closed on preview error or show uncertainty, and bind revision/plan digest to remove with re-confirm on change.

Prior graph-only P2 is now closed (Host preview returns 0). Hosted test: IN_PROGRESS — not green.

简体中文

确认预览与执行脱节。

[liuxiaocs7]

Fixed on the latest head (15dd64a1) — you were right, and it was a real contradiction.

Confirmed: the catalog projection carries a linked child as subagent: { parentSessionId } with no operator marker (and no copy state), so parentHasArchivableSubtasks's subagentParent.graph guard was dead in the renderer. A parent whose only children are graph operators — retired with the parent, archived count 0 — was warned as if subtasks would survive.

Fix: the renderer stops re-deriving the plan entirely. A read-only session.remove.preview Host query returns how many subtasks a delete would archive (deduplicated by revision family, via the same #readRemovalPlanSessionIds the mutation uses). Graph operators, already-archived children, copies mid-preparation, and absent targets all preview 0. The confirm warns off that count; the toast still reports the executed count; a preview failure just drops the note without blocking the delete. This also closes the conversationCopy: 'preparing' gap from your first review, since the renderer no longer inspects the projection at all.

Epoch 51 covers this round (the removed-result field plus the new query). Checks are green on 15dd64a1 (test: SUCCESS, run 32883398966), including the e2e where the real Host preview drives the confirm.

简体中文

已在最新 head(15dd64a1)修复——你说得对,确实是真矛盾。

已核实:catalog 投影把链接子任务表示为 subagent: { parentSessionId },没有算子标记(也没有复制状态),所以 parentHasArchivableSubtasks 里的 subagentParent.graph 判断在渲染层是死代码。只有 graph 算子子任务的父任务(随父任务退休、归档数 0)会被误报为“子任务会保留”。

修法:渲染层彻底不再推导计划。新增只读的 session.remove.preview Host 查询,返回删除会归档几个子任务(按 revision family 去重,复用与执行同一套 #readRemovalPlanSessionIds)。graph 算子、已归档子任务、复制中(preparing)、以及不存在的目标,预检都返回 0。confirm 按这个数提示;toast 仍报执行后的真实数;预检失败只是不显示提示,不阻塞删除。这同时把你首轮提的 conversationCopy: 'preparing' 缺口也一并关掉了,因为渲染层不再读投影。

epoch 51 覆盖本轮(removed 结果新字段 + 新查询)。15dd64a1 上 CI 全绿(test: SUCCESS,run 32883398966),包括由真实 Host 预检驱动 confirm 的 e2e。

[Astro-Han]

Need rebase!

[Astro-Han]

Update on be094cb043:

[P2] Preview fail-open plus batch purge bypass

• Rows: session-row-actions.ts:177-188 swallows preview errors as 0 and shows delete confirm without archive warning, while remove may still archive linked subtasks; no revision binding.
• Batch: tasks-settings-page purgePaths omit Host archivedSubtaskCount preview and toast, silently archiving active subtasks.

Fix: fail-closed or warn on preview error, bind plan token, and gate bulk purges via Host preview.

Checks on be094cb043dcebbdeda1a7357b663950a681952f are test: IN_PROGRESS — not green.

简体中文

批量删除绕过归档预览。

[liuxiaocs7]

Addressed the two concrete gaps on the latest head (142794df); pushing back on the plan-token binding.

① Preview fail-open → fail-safe. The confirm no longer swallows a preview error as "0 subtasks". On preview failure it falls back to an uncertain note — "Its linked subtasks, if any, will be kept and moved to Archived." — so it never silently hides that subtasks may survive. The delete still proceeds (a transient preview hiccup shouldn't block deletion), and the toast reports the Host's executed count afterwards.

③ Bulk purge. purgeSessions now sums the Host's executed archivedSubtaskCount across the sweep into SessionPurgeOutcome.archivedSubtasks; the archived-tasks purge confirm warns that linked subtasks are kept and moved to Archived, and the result toast reports how many moved. No more silent archival on bulk delete.

② Plan-token binding / re-confirm — I'd argue against it here. The confirm is a best-effort heads-up before an action that, for the subtasks, is non-destructive — they're kept and archived, not deleted. The authoritative account is the post-delete toast, which reports the Host's executed count and is correct by construction. So even in the race you describe (a child unarchived between preview and remove), the user is still told the true number immediately after — the outcome isn't hidden, only the pre-confirm estimate is momentarily stale. With ① in place, the "preview unavailable" sub-case is also covered. A plan-digest token + a new plan_changed rejection + a renderer re-confirm loop is a lot of protocol and UX surface for a narrow window that already has a post-hoc safety net, on a notice about tasks that survive. I'd prefer not to block on it — happy to file a follow-up if you still want hard binding. Your call.

简体中文

最新 head(142794df)修了两个实打实的缺口,plan-token 绑定那条想提出异议。

① 预检 fail-open → fail-safe。 确认弹窗不再把预检错误吞成「0 个子任务」。预检失败时改为显示不确定提示——「其链接的子任务(如有)不会被删除,将保留并移入归档。」——绝不静默隐藏子任务可能存活这件事。删除照常进行(一次瞬时预检抖动不该阻塞删除),事后 toast 仍报 Host 执行后的真实数。

③ 批量 purge。 purgeSessions 现在把 Host 执行后的 archivedSubtaskCount 在整个 sweep 里累加进 SessionPurgeOutcome.archivedSubtasks;归档任务的 purge 确认体会提示子任务将被保留并移入归档,结果 toast 报出移动了多少。批量删除不再静默归档。

② plan-token 绑定 / 重确认——这里我倾向不做。 确认弹窗本质是事前提醒,而对子任务来说这个动作是非破坏性的——它们被保留归档、不是删除。权威账目是删除后的 toast,报的是 Host 执行后的真实数、天然正确。所以即便发生你说的竞态(预检到执行之间某个子任务被 unarchive),用户事后仍会立刻看到真实数字——结果没被隐藏,只是确认前的估算短暂过期。加上 ① 之后,「预检不可用」这个子情况也覆盖了。为一个已有事后安全网的窄窗口、而且是关于「会存活的任务」的提示,引入 plan 摘要 token + 新的 plan_changed 拒绝 + 渲染层重确认循环,协议和交互面都偏重。我倾向不因此阻塞——如果你仍想要硬绑定,我可以开个 follow-up。你定。