[REQ-128][DECIDE][P2] 整包移除后插件正文仍在 CAS 里(52K,6 小时后才清)——「移除无残留」在用户口径上是有条件的

[jinjunnn]

大白话

用户点「移除此扩展包」,界面说「扩展包已移除」。
账本、ext-store、引擎三面逐字干净,GET /skill 当场回落 —— 这些都对。

但插件正文还在盘上:内容寻址存储里 10 个 blob(那 10 份 SKILL.md 正文,合计 52K),
要等 6 小时宽限窗的定时 GC 才清(ext-cas-gc.ts:34 CAS_GC_GRACE_MS_DEFAULT)。

这不是本期引入的缺陷

是 #194 内容寻址存储的既有设计(mark/sweep + 宽限窗),移除动作本身按设计不删 blob。
#783 的打包真机 L2 只是第一次把它在用户口径上量出来。

为什么仍要立票

用户读到的「已移除」和磁盘上的事实之间有这个差。 三种处置各有代价,需要产品裁决:

1. 不改,但把话说准 —— 移除后的呈现补一句「插件正文会在数小时内彻底清除」。
   最便宜,但把一个实现细节推给用户。
2. 移除时主动触发一次 GC(或对该包的 blob 立即 unpin/sweep)。
   用户口径最干净,但要评估与宽限窗设计的冲突(宽限窗存在是有原因的:防止事务中途的 blob 被误删)。
3. 维持现状不改也不说 —— 需要明确接受「移除无残留」这句话是有条件的。

判据(不管选哪条)

• 若选 1:呈现文案不许出现「彻底删除 / 无残留」这类绝对表述。
• 若选 2:必须证明不会误删正在被别的包/别的事务引用的 blob
  (ext-cas-gc.ts 的 mark 根包含各环境根 ext-store 的 generation 内容重哈希 + journal 有界保留)。
• 若选 3:把这个条件写进 docs/contracts/extension-package-lifecycle.md,
  不许只活在一份 verification 文档里。

出处

#783 打包真机 L2(PR #794)§4「第 8 步的『无残留』到底残了什么」。