You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "liuxiaocs7 (via GitHub)" <gi...@apache.org> on 2026/08/25 09:41:11 UTC
[PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
liuxiaocs7 opened a new pull request, #3781:
URL: https://github.com/apache/maka/pull/3781
## 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 appends how many subtasks will be kept and moved to Archived when the count is non-zero.
- The completion toast reports how many subtasks were moved.
The count is a renderer estimate off the live catalog in `countArchivableSubtasks` (`app-shell-session-row-actions.ts`), matching the Host's removal plan (`session-retirement-coordinator.ts#readRemovalPlanSessionIds`): ordinary subagents count, Agent Graph operators (`subagentParent.graph`) do not, already archived children do not, and revisions of one child count once (deduped by `sessionRevisionFamilyId`). Copy lives in `shell-copy.ts` (zh + en). A restore that calls the delete off shows no subtask notice, since nothing moved.
Fixes #3780
## Verification
- `npx biome lint` on the four changed files — clean.
- `tsc -p tsconfig.main.json --noEmit` and `tsc -p tsconfig.renderer.json --noEmit` — both pass.
- Unit `app-shell-session-row-actions-revisions.test.ts` — 4/4 pass, including new cases: count excludes graph operators / archived / other parents and dedupes revisions; no notice when there are no subtasks; no notice when a concurrent restore calls the delete off.
- e2e `parent-session-deletion.spec.ts` — extended to assert the confirm names the subtask; not run in this environment (needs the Electron build + Playwright). Run with `npm --workspace @maka/desktop run e2e -- parent-session-deletion`.
## AI use
Select exactly one:
- [ ] No generative tool made a substantive contribution
- [x] Generative tooling made a substantive contribution
Tool(s) and scope: Claude Code — traced the delete/archive path, wrote the copy, the `countArchivableSubtasks` helper, the wiring in `deleteSession`, and the unit/e2e coverage. Commit carries a `Generated-by: Claude Code` trailer.
## Checklist
- [x] Tests cover the change and fail without it
- [x] Lint, format, typecheck and the affected suites pass locally
Does this PR entail a change in behavior?
- [x] Yes — described under Summary above
- [ ] No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5410573602
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.
<details><summary>简体中文</summary>
这个缺口是真的——归档列表里冒出标着「原父任务已删除」的行却毫无预告，确实让人困惑，提前告知是对的解法。关于怎么做有一条意见，不阻塞。
## [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——多一个操作，但渲染层不再猜。你定；两种我都可以，只是不希望留一个可能是错的数字。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #3781:
URL: https://github.com/apache/maka/pull/3781#discussion_r3892350289
##########
apps/desktop/src/renderer/features/session-navigation/controller/session-row-actions.ts:
##########
@@ -164,22 +180,49 @@ export function createSessionNavigationRowActions(deps: {
return runSessionRowAction(sessionId, 'delete', copy.deleteFailedTitle, async () => {
const session = sessionsRef.current.find((entry) => entry.id === sessionId);
const name = session?.name ?? copy.currentConversation;
+ // Ask the Host how many subtasks the delete would archive. It owns the
+ // removal plan; the renderer's catalog projection lacks the operator
+ // marker and copy state, so a renderer estimate would over-promise (e.g.
+ // claim archival for a parent whose only children are graph operators).
+ // A preview failure is not silence: fall back to an uncertain warning so
+ // the confirm never hides that subtasks may survive. The toast still
+ // reports the real executed count afterwards.
+ let previewSubtaskCount: number | undefined;
+ try {
+ previewSubtaskCount = await service.previewRemoval(sessionId);
Review Comment:
Thanks for making the preview Host-owned. [P2] (category ② — supported concurrent restore/create path): the preview and removal still do not bind the same plan. After this read returns 0, another client can restore or create an ordinary linked subtask before the user confirms; `remove` then recomputes a stable plan and archives it, but the confirmation showed no survival warning. The completion toast reports the fact only after the destructive choice, so it cannot replace the promised pre-delete notice. Could the preview return a plan/revision token that removal validates, or otherwise make the confirmation wording remain true when the plan changes? Please push back if an admission lease actually spans this read through the user decision.
##########
apps/desktop/src/renderer/locales/settings-tasks-copy.ts:
##########
@@ -94,8 +100,11 @@ const SETTINGS_TASKS_COPY_BY_LOCALE = {
count === 1 ? 'Delete the 1 task you searched for?' : `Delete the ${count} tasks you searched for?`,
purgeConfirmBody:
'The tasks and all of their messages are removed permanently. This cannot be undone.',
+ purgeSubtaskNote: 'Any linked subtasks are kept and moved to Archived.',
Review Comment:
Thanks for covering the bulk-cleanup path. [P2] (category ① — normal archived parent with Agent Graph children): this says every linked subtask is kept, while the Host removal family intentionally includes graph-operator Sessions in `removeSessionIds` and excludes them from `archiveSessionIds`; a graph-only parent therefore deletes those children and archives zero. The same over-certainty appears in `deleteSubtaskNoteUncertain`, which says subtasks “will be kept” even when the preview failed and the Host may later classify them as graph operators. Could the copy say that ordinary subagent subtasks may be kept/moved (or use Host previews for the actual targets) rather than promising survival for every linked child? Please push back if graph operators are deliberately not presented as linked subtasks on either surface.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #3781:
URL: https://github.com/apache/maka/pull/3781
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "liuxiaocs7 (via GitHub)" <gi...@apache.org>.
liuxiaocs7 commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5480988153
Thanks — both are fair, and the framing as suggestions is appreciated. Fixed ① on `d9b38bc0`; pushing back on ②.
**① Over-certain copy — fixed.** You're right that a graph-only parent deletes its operator children (they're in the removal family, excluded from the archive family) and archives zero, so "every linked subtask is kept" was wrong. All three kept-subtask notices — `purgeSubtaskNote`, `deleteSubtaskNoteUncertain`, and (for consistency) `deleteSubtaskNote` — now say **"ordinary subtasks"** instead of "linked subtasks", so operators aren't presented as survivors on either surface. The exact-count path is unaffected: `session.remove.preview` counts only ordinary archivable subtasks (graph operators preview 0), so a graph-only parent shows no note at all.
**② Preview↔removal plan binding — I'd still argue against it.** You're right that no admission lease spans the preview read through the user's decision — the preview is a plain read, and `remove` recomputes its own stable plan under the admission gate. So the race is real: between preview and confirm, another client could create/restore an ordinary subtask, and the confirm would have shown no warning while `remove` archives it.
Where I land differently is on proportionality:
- The action being confirmed is **non-destructive for the subtasks** — they're kept and moved to Archived, fully recoverable — so a missed *pre*-notice is a wording imperfection, not data loss.
- The completion toast reports the Host's **executed** count, so the user is still told the true outcome; the window where the pre-notice is stale is narrow (create/restore under this exact parent during the confirm dialog).
- A plan-digest token + a `plan_changed` rejection + a renderer re-preview/re-confirm loop is a fair amount of protocol and UX surface to close a narrow, recoverable, already-surfaced gap.
So I'd prefer to leave the pre-notice best-effort rather than bind a token. If you or a maintainer feel the pre-delete promise must hold exactly, I'm happy to file a follow-up for the token-bound preview rather than fold it into this PR. Your call — I won't treat this as blocking unless you'd like it to be.
<details><summary>简体中文</summary>
多谢——两条都合理,也感谢标为建议。① 已在 `d9b38bc0` 修复;② 想继续反驳。
**① 文案过度承诺——已修。** 你说得对:只有 graph 算子子任务的父任务会删掉这些算子(它们在移除族里、被排除出归档族),归档数为 0,所以「所有链接子任务都会保留」是错的。三处「保留子任务」文案——`purgeSubtaskNote`、`deleteSubtaskNoteUncertain`,以及为一致性也改了 `deleteSubtaskNote`——现在都说**「普通子任务」**而非「链接子任务」,两个界面都不再把算子当作会存活的对象。精确计数那条不受影响:`session.remove.preview` 只数普通可归档子任务(graph 算子预检为 0),graph-only 父任务根本不显示提示。
**② preview 与 remove 的 plan 绑定——我仍倾向不做。** 你说得对,没有 admission lease 覆盖「预检读 → 用户决定 → remove」这整段;预检只是普通读,remove 在 admission gate 下重算自己的稳定 plan。所以竞态是真的:预检到确认之间,别的客户端可能新建/恢复一个普通子任务,确认弹窗没警告而 remove 归档了它。
我判断不同的地方在性价比:
- 被确认的动作对子任务是**非破坏性的**——它们被保留并移入归档、完全可恢复——所以缺一个*事前*提示是措辞瑕疵,不是数据丢失。
- 完成 toast 报的是 Host **执行后**的真实数,用户仍会被告知真实结果;事前提示过期的窗口很窄(必须在确认弹窗打开期间、恰好在这个父任务下新建/恢复)。
- 为关闭这个窄、可恢复、且已事后如实告知的缺口,引入 plan 摘要 token + `plan_changed` 拒绝 + 渲染层重预检/重确认循环,协议和交互面都偏重。
所以我倾向让事前提示保持 best-effort,而不绑定 token。如果你或 maintainer 认为这个事前承诺必须严格成立,我乐意开一个 follow-up 单独做 token 绑定的预检,而不是塞进本 PR。你定——除非你希望它阻塞,否则我不当作阻塞项。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "liuxiaocs7 (via GitHub)" <gi...@apache.org>.
liuxiaocs7 commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5415137132
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.
<details><summary>简体中文</summary>
已在最新 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。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5416119374
Need rebase!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "liuxiaocs7 (via GitHub)" <gi...@apache.org>.
liuxiaocs7 commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5411332820
Thanks — took the smaller shape in 70afc159.
**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.
<details><summary>简体中文</summary>
多谢——按更小的形状改了,见 70afc159。
**toast**:`session.remove` 现在返回 `archivedSubtaskCount`(在 coordinator 里按 revision family 去重,只有归档了东西时才带上),经 `removeSession`、`sessions:remove` IPC、preload bridge 一路传到 toast。toast 报的是 Host 执行后的真实数字,天然正确,不再估算。
**confirm**:去掉了数字。现在只警告子任务会被保留并移入归档这个事实。`countArchivableSubtasks` 删掉了,剩下的是一个只决定「要不要警告」的存在性检查(`parentHasArchivableSubtasks`),新测试里大部分针对计数的用例也随之删除。
你指出的两条不一致现在都不成立了——渲染层不再重新推导计划,所以那条实现不了的 `conversationCopy` 过滤、以及 Host 忽略的 `subagent?.parentSessionId` 回退,都不会再让一个展示给用户的数字偏大。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(desktop): warn that deleting a parent keeps and archives its subtasks [maka]
Posted by "liuxiaocs7 (via GitHub)" <gi...@apache.org>.
liuxiaocs7 commented on PR #3781:
URL: https://github.com/apache/maka/pull/3781#issuecomment-5421449489
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.
<details><summary>简体中文</summary>
最新 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。你定。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org