[Migration] v0→v1 拒收两种由 0.1.1-rc.2 写出的合法形态（descriptor v2 / plugin source summary）—— 升级后 255/256 条会话打不开

[hshskou]

摘要 / Summary

真实环境从 0.1.1-rc.2（当时 npm latest）升到 0.1.5-rc.2（next） 后，256 条旧会话里 255 条打不开，GUI 里逐条报 历史加载失败: failed to observe session …。原因不是数据损坏，而是 v0→v1 迁移器拒收两种由 0.1.1-rc.2 自己写出的、已发布的 v0 形态——迁移器接受的形态清单没覆盖它们：

1. subagent/descriptor 的 data.version: 2（迁移器只认 3；231 / 256 条会话命中）；
2. 插件注入消息的 source.summary 搭配非 notice 的 form（写方是 dsh-mnemon 0.3.5；223 / 256 命中）；199 条两者都有。

fail-fast 本身没问题——source v0 artifact remains unchanged，原件一个字节没动（76,081 个 zstd 帧、0 撕裂）。但对正常升级路径代价很大：一次版本升级就让近 90% 的历史不可读。我已用未修改的迁移链验证：只把这两处形态本地规范化，256 / 256 全部通过（241,872 个事件、0 失败） ⇒ 缺口在"迁移器接受的形态清单"，不在数据。

这两条形态此前未被上报（与 #5694 的 replayState.kind、#5909 都不是同一个）；另外我核对了 0.1.6-alpha.1 的同一段代码逐字节相同 ⇒ 目前所有已发布版本都尚未修复。

---

Upgrading one real installation from 0.1.1-rc.2 (then npm latest) to 0.1.5-rc.2 (next) left 255 of 256 legacy sessions unreadable (failed to observe session …). Two released-v0 shapes are refused, and both were written by 0.1.1-rc.2 itself — the accepted-variant inventory is simply missing them: subagent/descriptor with data.version: 2 (231/256 sessions; the migrator accepts only 3, behind two gates), and a plugin source carrying summary with a non-notice form (223/256; writer was dsh-mnemon 0.3.5). Fail-fast is the right default (source v0 artifact remains unchanged; 76,081 zstd frames, 0 torn), but on the ordinary upgrade path it costs ~90% of a user's history. With those two shapes normalized locally, the unmodified chain migrates 256/256 sessions, 241,872 events, 0 failures — the gap is the inventory, not the data. Neither shape appears in the previously reported threads, and 0.1.6-alpha.1 ships byte-identical code, so no published version fixes it yet.

Environment

• dsh 0.1.5-rc.2 (npm next); previously 0.1.1-rc.2 (npm latest) for ~2.5 weeks
• macOS 14 (Darwin 23.6.0, arm64), node v24.20.0, launchd-managed dsh web --no-open (127.0.0.1:3080)
• Plugins present: dsh-mnemon 0.3.5 (upgraded to 0.5.9 in the same window), dsh-context, dshmarket, @linxin666/dsh-web-all, and a few local plugins
• Sessions are all header version: 0 (session.jsonl.zstd), i.e. they never got rewritten; the v0→v1→v2→v3 migration runs lazily on read, which is why the breakage only appears when a conversation is opened

Shape 1 — subagent/descriptor with data.version === 2

Verbatim record from session.jsonl.zstd (real, label is the delegating plugin's own text):

{"type":"subagent/descriptor","seq":152547,"time":1788023939929,"data":{"version":2,"mode":"one-shot","provider":"fork","label":"Mnemon idle checkpoint review"}}

Observed error:

@deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session:
subagent/descriptor 152547 uses unsupported descriptor version 2
source v0 artifact remains unchanged

Refusal site — dsh-session-format-v0-to-v1/lib/index.js:1584-1588:

if (event.type === "subagent/descriptor" && data["version"] !== 3) {
  const descriptorVersion = sessionFormatCount(data["version"], `${event.type} ${event.seq} version`);
  if (version === 0) throw new SessionFormatUnsupportedMigrationError(`${event.type} ${event.seq} uses unsupported descriptor version ${descriptorVersion}`);
  return;
}

There is a second gate behind it. Relaxing only the if above moves the failure to the generic literal validator (lib/index.js:591):

subagent/descriptor 152547 version must be one of 3

So a fix has to widen the accepted version inventory (disposition/payload validation), not just the early check.

Scale: 231 / 256 sessions, 1–N occurrences each, all version: 2 (no other historical values observed).

Shape 2 — plugin source carrying summary with a non-notice form

Verbatim record (message text elided, 275 chars):

{"type":"user/message","seq":9,"time":1788877342296,"data":{"id":"7104423c-d1b6-4885-8cc6-bc0a1ca09529","role":"user","content":[{"type":"text","text":"[MNEMON] <instructions, elided>"}],"source":{"kind":"plugin","plugin":"dsh-mnemon","form":"instructions","summary":"Optional memory recall and remember reminder"}},"surfaceOp":"append"}

Observed error:

@deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session:
user/message 9 source summary requires notice form
source v0 artifact remains unchanged

Refusal site — lib/index.js:948-949, with the form allowlist at 934-941:

if (form === "notice") stringValue(source["summary"], `${label} summary`);
else if (source["summary"] !== void 0) throw new SessionFormatError(`${label} summary requires notice form`);

Note that released v0 declared summary as an optional member of any plugin source (assertReleasedV0Keys(source, ["kind","plugin"], ["form","sections","summary"], label) at lib/index.js:919-926), so the cross-field rule ("summary ⇒ notice") is the newer, stricter constraint. The historical writer is dsh-mnemon 0.3.5, whose createPluginMessage(text, form) emits {kind:"plugin", plugin, form} plus a UI summary; mnemon 0.5.9 no longer emits summary (verified in its source), so this shape stops being produced — but it stays in every log written before the plugin upgrade.

Scale: 223 / 256 sessions, exactly 1 occurrence each. 199 sessions carry both shapes.

Impact

• 255 / 256 sessions refused; the GUI reports 历史加载失败: failed to observe session … (gateway/internal) per session.
• Nothing is lost: the migration leaves the source artifact untouched, and the persistence publishes a validated current successor once a read succeeds (verified: after local normalization, session.jsonl.zstd and session.v3.jsonl.zstd coexist in the same session directory).

Repro (no private data required)

import { sessionFormatCatalog } from '@deepseek-ai/dsh-session-format-catalog';

const rows = [headerRow, ...physicalEventRows]; // decoded JSONL rows of a v0 artifact
const restore = sessionFormatCatalog.createRestore(rows[0], { recovery: 'strict', validation: 'current' });
for (const r of rows.slice(1)) restore.decodeRow(r);
restore.finish(); // throws with the messages above

A minimal artifact consisting of the session header plus either record above is sufficient.

Verified local normalization (what a fix would need to do)

Applied in-memory per file, then run through the unmodified chain above:

1. subagent/descriptor.data.version: 2 → 3 (231 records);
2. delete source.summary where form !== "notice" (223 records).

Result: 256 / 256 sessions migrate, 241,872 events, 0 failures. Every touched payload also passes the v3-side validation — i.e. these version: 2 descriptor payloads satisfy the version: 3 key/type/semantic checks as-

[xiaoyuyu6420]

你这两条形态其实已经有现成的、维护中的工具能处理——dsh-session-surgeon（#6151 里 xiaoshenming 贴过处理清单）：subagent/descriptor v2→3（两个版本字段一致，直接改版本号）和插件 source 的 summary/form 不匹配都在它的覆盖范围（commit 519ea4d 起）。你已经自己写了对版规范化脚本的话，可以拿它核对一下两类形态的边界情况；不想长期维护脚本就直接用 surgeon——记得它流程里的三件事：先停写者、先 dry-run、留 .bak。

另外这份数据对推动修复很有价值：255/256 的真实命中率、「0.1.6-alpha.1 同段代码逐字节相同」的结论、还有 256/256 通过的规范化验证——这三样合起来基本堵死了「孤例/未复现」的回应空间。建议把这篇挂进两个汇总线：#6520（社区核实的未修复清单）和 #4910（格式治理的架构层讨论）——「修迁移器而非让每个用户改文件」的共识正在这两个帖子里聚。

[yamingmou]

@hshskou — two notes from our side on the two shapes, one of which may be relevant to the counts you measured.

1. Shape 1: we have seen this before, in #6045

subagent/descriptor being refused on the version number alone is what we reported as #6045 on 2026-09-12. Three other threads reported the same thing in the same window — #5978 / #6010 / #6048 — and @PerryLink checked the mechanism against source on 2026-09-12:

• the first gate rejects data.version !== 3 before the v0 key inventory is consulted (validation.ts:198-206) — so the payload is never examined;
• a second gate hardcodes the same literal (payload-validation.ts:955-956, subagentDescriptorValue starts from literalValue(data["version"], [3]));
• the field added by the version bump (由插件重复安装引起的桌面端崩溃 #2663 / f76a225a7d, 2026-08-24) is optional (dispositions.ts:92-95), so a v2 payload would pass the v3 key checks — the rejection is purely the number.

(Those four line references are @PerryLink's verification on #6045, not ours; we did not re-read that source ourselves.)

We mention it only in case it is useful: a reader who lands on either thread has no way to know the other exists.

2. A split our store happened to give us

In our own store we ran a read-only pass and split the sessions by origin. As of 2026-09-12 (our store is live and keeps growing, so this is a snapshot, not a constant):

origin	logs	refused as-is	pass after version 2 → 3
subagent	200	200 (100%)	200 (100%)
not subagent (root / fork)	55	21	21 (unchanged)

The shape we saw: the rewrite is selective — normalizing version 2 → 3 fixed every subagent session in our store and no non-subagent session. We report it as an observation about our store, not as a rule; another installation may look different.

3. Shape 2: we have no data

For the second shape — a plugin source carrying summary with a non-notice form, written by dsh-mnemon 0.3.5 — we cannot add anything: that writer is not in our installation, so we have no sample. We would rather say that plainly than extrapolate from shape 1.

4. One thing our own store also shows

Our own dry run shows the same shape you describe: the source artifact is untouched and the chain passes those sessions once the two shapes are normalized. For shape 1 we are pointing at an existing report rather than adding one — so what we can contribute in this thread is limited to the origin split in §2.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

@hshskou —— 我方这边有两条与你那两种形态有关的观察，其中一条可能与你测到的数字有关。

1. 形态 1：我们在 #6045 里见过

「subagent/descriptor 仅因版本号被拒」是我们 2026-09-12 在 #6045 报的。同期另有三个线程报了同一件事 —— #5978 / #6010 / #6048 —— 且 @PerryLink 在 2026-09-12 对该机制做过源码核实：

• 第一道门在查询 v0 键清单之前就先拒 data.version !== 3（validation.ts:198-206）⇒ payload 根本没被检查；
• 第二道门硬编码同一字面量（payload-validation.ts:955-956，subagentDescriptorValue 起手 literalValue(data["version"], [3])）；
• 版本号那次变更（由插件重复安装引起的桌面端崩溃 #2663 / f76a225a7d，2026-08-24）新增的字段是可选的（dispositions.ts:92-95）⇒ v2 的 payload 本可通过 v3 的键检查 ⇒ 拒绝纯粹因为那个数字。

（上述四处行号来自 @PerryLink 在 #6045 的核实，不是我们读的；我方未自行重读那段源码。）

提这个只是以防有用：读者若只落在其中一帖上，本来无从知道另一帖存在。

2. 我方 store 恰好给出了一个拆分

在我方自有 store 上做了一次只读遍历，按来源把会话拆开。截至 2026-09-12（我方库是活库、仍在增长，这是时点快照、不是常量）：

origin	日志	原样被拒	把 version 2→3 后通过
subagent	200	200（100%）	200（100%）
非 subagent（root / fork）	55	21	21（不变）

我们看到的样子是：改写是选择性的 —— 把 version 2→3 规范化后，我方 store 里所有 subagent 会话被修好、而没有任何非 subagent 会话被修好。这作为对我方 store 的观察报告，不当规则；别的安装可能不一样。

3. 形态 2：我方没有数据

第二种形态 —— 插件 source 带 summary 搭配非 notice 的 form，写方 dsh-mnemon 0.3.5 —— 我方补不了任何东西：那个写方不在我方安装里，我们没有样本。我们宁愿直说，而不是拿形态 1 去外推。

4. 我方 store 也呈现同样的样子

我方的只读遍历也显示：源件一个字节未动，两种形态规范化之后那条链就能放行。形态 1 我方是指向一份已有的报告而非新增一份，所以在你这帖里我们能贡献的只有第 2 节那个来源拆分。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[xiaoshenming]

这两类形状（subagent/descriptor 的 version、插件 source 的 summary/form）dsh-session-surgeon 从 519ea4d 起就会归一：

• v0-descriptor-version：只改 data.version 字段，其余成员原样保留（两种版本的键集相同）。
• v0-plugin-source-form：只把展示用的 form 对齐（summary→notice，sections→snapshot），成员都留下；仅 summary+sections 并存冲突才删其一。

同样用官方 0.1.7-rc.1 的 sessionFormatV0ToV1 stage 对照过：改前拒、改后过。流程：先停写者 → dry-run → apply 前写 .bak.<utc>，不删事件、不改正文。

边界：这是逐形状归一，不做行级降级；未知类型（session/imported、插件消息）连 ignorable 都不盖，只报告。255/256 → 256/256 这类整体收益还得靠 #4910 / #6520 那条「迁移器该不该 fail-closed」的线。

[yamingmou]

We are the account that reported the descriptor shape as #6045 (09-12) and that runs the #4910 side of this discussion. Two things we can add to the shapes you describe, one of which is new as of today.

1. A window you can use to scope shape 1

For the subagent/descriptor version shape, we can now put a date range on it. Reading the constant out of every published version of dsh-subagent — twenty-seven versions, 08-10 → 09-23 — the value is 2 in every published version from 0.0.1-rc.1 (2026-08-10) through 0.1.1-rc.2 (2026-08-21), and 3 from 0.1.2-alpha.2 (08-30) onward. So a session can only carry a v2 descriptor if it was written by one of those eleven releases.

That may be useful for scoping rather than counting: a store's exposure to shape 1 is bounded by its own history in that window, and nothing outside it can produce the shape.

We should be explicit about the limit of that: it covers shape 1 only. We have not run the same reading for the plugin-source form shape, so we cannot put a window on shape 2 — and we would rather say so than imply symmetry.

2. Both gates, or the normalization does not land

One detail from the source reading that matches your per-shape approach: the refusal is enforced at two places — the version literal at the v0→v1 edge, and a second hardcoded literal in the payload validation for subagentDescriptorValue. Normalizing only one of the two still refuses; both must move together. @kenz1117 stated the same from the patch side in #7576: "our patch widens both, and only both … A diff touching only one of the two would indeed still refuse."

Your description already normalizes both shapes, so this is only a note about what a narrower tool would miss.

3. On the aggregate numbers

We read your closing point — that 255/256 → 256/256 style totals depend on the #4910 / #6520 thread about whether the migrator should fail closed — as the right place to put it. That thread is the one where we would expect a policy answer rather than a tooling one, and we would not ask an offline normalizer to carry it.

We are plugin authors, not maintainers; nothing here asks you to change what your tool does.

Authorship note: this reading is mine, against published package contents; root-cause reading and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the published packages and correct. We are plugin authors, not maintainers, and nothing here states official policy.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

我们是把 descriptor 这一形态作为 #6045（09-12）报出来的那个账号，也是这个讨论里 #4910 一侧的参与者。对你描述的两种形态，我们能补两条 —— 其中一条是今天才有的事实。

1. 一个可以用来界定形态 1 范围的窗口

对 subagent/descriptor 的版本形态，我们现在可以给它加上日期范围。把常量从 dsh-subagent 的每一个已发布版本里读出来 —— 共 27 个版本，08-10 → 09-23 —— 结果是：从 0.0.1-rc.1（2026-08-10）到 0.1.1-rc.2（2026-08-21）的每一个已发布版本，该常量都是 2；从 0.1.2-alpha.2（08-30）起才是 3。也就是说，一条会话只有由这十一个版本中的某一个写出，才可能带 v2 descriptor。

这更可能用于界定范围而不是计数：一个库对形态 1 的暴露面，由它自己在那段窗口里的历史决定，窗口之外产生不出这个形态。

我们想把这条的边界说清：它只覆盖形态 1。 插件 source 的 form 那一形态，我们没有做同样的读数，因此无法给形态 2 一个窗口 —— 我们宁愿直说，而不是暗示两者对称。

2. 两处都要归一，否则不生效

从源码读数里有一个细节，与你的逐形态做法吻合：这个拒收是在两处落实的 —— v0→v1 边上的版本字面量，以及 payload 校验里 subagentDescriptorValue 的第二个硬编码字面量。只归一其中一处，仍然会被拒；两处必须一起动。@kenz1117 在 #7576 从补丁一侧也说了同样的话："our patch widens both, and only both … A diff touching only one of the two would indeed still refuse."

你的描述里两种形态都已经归一，所以这只是一条"范围更窄的工具会漏掉什么"的注记。

3. 关于整体数字

你收尾那句 —— 255/256 → 256/256 这类总数，取决于 #4910 / #6520 那条"迁移器该不该 fail-closed"的线 —— 我们认为放在那里是对的。那条线该出的是政策答案，而不是工具答案，我们也不会要求一个离线归一器去承担它。

我们是插件作者、不是维护者；本文不要求你改工具的任何行为。

声明：本次通读与核对由我本人完成（对象为已发布包内容）；文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照已发布包重新核实并更正。我们是插件作者、不是维护者，本文不陈述任何官方政策。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[xiaoshenming]

Two useful additions from your side — the version window especially. One measurement back on the "both gates" point.

Both refusals read the same field, so one rewrite satisfies both. On 0.1.7-rc.1:

• the v0→v1 edge throws at dsh-session-format-v0-to-v1/lib/index.js:1586 (uses unsupported descriptor version 2);
• subagentDescriptorValue independently requires literalValue(data["version"], [3]) (:1287).

Since both compare data.version, rewriting that single member is enough — no second literal has to move in the log. Measured with a released shape ({mode:"continuable", version:2, provider:"p", label:"sub"}) through the real sessionFormatV0ToV1 stage:

before repair: refused: subagent/descriptor 2 uses unsupported descriptor version 2
after  repair: accepted   (version 3, mode continuable, label kept)

A narrower tool that only edits, say, a header or a cached copy would indeed still refuse; ours touches the event payload only, and nothing else in the descriptor.

One honest limit. The repair rewrites the version and nothing else. If the same descriptor is also outside the released shape in another way (an unreleased mode, a missing label), the session stays refused after our write — our probe hit mode must be one of continuable|one-shot before we fixed the fixture. We report those rather than guessing further; that is the same boundary you drew for shape 2.

Thanks for the 27-version reading — it bounds exposure to shape 1 by the writer window (0.0.1-rc.1 → 0.1.1-rc.2), which is more useful than a count. Noted that shape 2 has no such window yet.

[yamingmou]

Three additions, all of them about the shape of the window rather than about the repair.

The window closes at the far end too

At the near end you have it: the rewrite satisfies both gates because both compare data.version, and in dsh-session-format-v0-to-v1@0.1.7-rc.1 the check is at :1584 (data["version"] !== 3) with the throw at :1586 — both as cited.

At the far end: dsh-subagent@0.1.7-rc.1 defines SUBAGENT_DESCRIPTOR_VERSION = 3 (:1309). No published writer emits 2 any more. That makes shape 1 a closed set — the sessions already written inside the writer window, and nothing after it. Reading has moved on, writing has moved on; for those sessions a rewrite of the single member is the only route left. It can be a repair for a finished set; it cannot become the fix, because the writer is no longer where the problem is.

One line number to reconcile

In the same tarball we measure subagentDescriptorValue declared at :1289 and the literalValue(data["version"], [3]) call at :1290. The other message reads :1287. We are reporting our own reading of the tarball rather than settling the difference — it may simply be a different build, and we have only this one.

What we still cannot bound

Shape 2 — the plugin-source form — has no writer window from us. Our 27-version reading covers the descriptor constant and nothing else, so we claim a bound for shape 1 only and leave shape 2 open.

Authorship note: the code locations above were re-read by me against the published tarballs of the versions named; drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

补三条，都是关于这个窗口的形状，不是关于那个改写本身。

窗口在远端也关上了

近端你已经拿到了：改写能同时满足两处门，因为两处比的是同一个 data.version；在 dsh-session-format-v0-to-v1@0.1.7-rc.1 里，判据在 :1584（data["version"] !== 3），抛在 :1586 —— 与你引的相同。

远端是这样的：dsh-subagent@0.1.7-rc.1 定义 SUBAGENT_DESCRIPTOR_VERSION = 3（:1309）。已经没有还在写 2 的已发布写入者了。 这就让形态 1 成了一个封闭集合 —— 写入窗口内已经写下的那些会话，之后不会再有新的。读侧走过去了，写侧也走过去了；对那些会话，改这一个成员是剩下的唯一路子。它可以是一个针对已完成集合的修复，但它不会成为那个"修好的版本"，因为问题已经不在写者那一侧。

一处需要对上的行号

在我们拉的这个 tarball 里，subagentDescriptorValue 定义在 :1289，literalValue(data["version"], [3]) 的调用在 :1290；另一条消息里读到的数是 :1287。我们只报自己在这个 tarball 上读到的结果，不去判这个差；它可能只是另一个构建，而我们手上只有这一个。

我方还界定不了的

形态 2（插件 source 的 form）我这边没有窗口。那份 27 版本的读数只覆盖 descriptor 常量，所以界限只对形态 1 成立，形态 2 留着。

声明：上列代码位点由我本人对照上述版本的已发布产物重新通读；文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。我们是插件作者、不是维护者，本文不陈述任何官方政策。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[xiaoshenming]

行号对上了：两处读数一致，我上一条的 :1287 是错的。

我重新在 rc.1 的已发布 tarball 和本机安装副本上各读了一遍（两份文件字节相同，104,888 字节）：subagentDescriptorValue 声明在 :1289，literalValue(data["version"], [3], …) 在 :1290；v0→v1 那条边是 data["version"] !== 3 在 :1584、抛在 :1586。上一版写的 :1287 偏了两行，按你们读到的更正。

远端封闭这条也同意，而且它影响我们怎么写这条修复：既然已经没有还在写 2 的写入者，形态 1 就是一个封闭集合 —— 我们把它当成「对已完成集合的一次性归一」，不扩形状、不加启发式：只改 data.version 的数字，其余成员原样保留（两版键集相同）；成员越界的一律只报告。

形态 2（插件 source 的 form）我们这边同样没有写入者普查，只能给形状界而不是版本界：form 必须与 summary/sections 相配（summary→notice，sections→snapshot）；两者并存且冲突时我们不选边、只报告。按原帖，写出该形态的是社区插件（dsh-mnemon 0.3.5），窗口只能由那类插件的发布史去界，不是内核的发布史 —— 这一点同意把它留空。

[yamingmou]

The writer you name is on the public registry, and the honest result of looking is a boundary rather than a window.

We said in this thread that we had not run that reading, and that we would rather say so than imply symmetry with shape 1. We have now looked at the one end of it that can be looked at.

The part that is enumerable

dsh-mnemon is public, and 0.3.5 — the writer named in the report — was published 2026-08-28T06:21:21Z. So the single instance of shape 2 that has a name also has a timestamp, and that much can be read off the registry without touching code.

The part that is not

What cannot be read off is the set. That plugin's own line runs from 0.1.0 on 2026-08-13 to 0.5.16 on 2026-09-26 — more than sixty published versions in six weeks — and a release list says which versions exist, not which of them write this shape. There is no field anywhere in a package that declares "this release emits a summary source with a non-notice form".

Why this is structural rather than a gap waiting to be closed

Shape 1's window closes because the value that decides it lives in the kernel, and the kernel's published artifacts are an enumerable set: read the constant out of each one and the range falls out, which is what we did for the twenty-seven subagent releases. Nothing in that method depends on anyone's cooperation — the produced value is in the artifact and the artifacts are all published.

Shape 2 turns on the opposite question. It is not "which kernel releases can produce it" but "which plugin releases write it", and the artefact route does not transfer: the writing site is third-party code, and what a plugin writes is only visible by reading that plugin's own releases one at a time, in each plugin line. The set of lines is not ours to enumerate — ours is one of them.

So the form shape ends up with a different kind of boundary than the descriptor shape. Descriptor: a closed interval, eleven kernel releases, derivable from the artifacts. Form: a known writer with a date, and an open set of writers behind it, derivable only from each writer's own history. What you can state for it is the shape constraint — a summary source must pair with notice, a sections source with snapshot, and a source satisfying neither is the one the migration meets — and that is a boundary in kind rather than in time.

We do not think leaving that one open costs anything today; we mention the difference so that it is not read later as an omission that simply was not gotten to.

Authorship note: the registry readings above are mine, against published package metadata; root-cause reading and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the published packages and correct. We are plugin authors, not maintainers, and nothing here states official policy.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

你点名的那个写者在公开 registry 上，而认真看一遍的结果是一条边界，不是一个窗口。

我们在这条线程里说过：那个读数我们没做，并且宁愿直说、也不暗示它与形态 1 对称。现在我们把唯一能看的那一端看了。

可以枚举的那一半

dsh-mnemon 是公开的，而报告里点名的那个写者 0.3.5 的发布时间是 2026-08-28T06:21:21Z。也就是说，形态 2 那个有名字的唯一实例，同时也有一个时间戳 —— 这一部分不用碰代码就能从 registry 读出来。

读不出来的那一半

读不出来的是集合。这条插件线从 2026-08-13 的 0.1.0 一直排到 2026-09-26 的 0.5.16 —— 六周里六十多个已发布版本 —— 而一份发布列表只告诉你哪些版本存在，不告诉你其中哪些会写出这个形态。包里没有任何字段声明"本版本会产出带非 notice 的 form 的 summary 源"。

为什么这是结构性的，而不是一个将来会补上的空

形态 1 的窗口之所以能合上，是因为决定它的那个值住在内核里，而内核的已发布产物是一个可枚举集合：把常量从每一份里读出来，区间就掉出来了 —— 我们对那 27 个 subagent 版本做的正是这件事。这套方法不依赖任何人的配合：被产出的值在产物里，而产物全都已发布。

形态 2 问的是相反方向的问题。它不是"哪些内核版本能产出它"，而是"哪些插件版本写出了它"，而"读产物"这条路不可移植：写出点是第三方代码，而一个插件写了什么，只能在每一条插件线里、一个一个版本去读它自己的发布。有哪些线，不是由我们来枚举的 —— 我们自己就是其中一条。

于是 form 这一形态拿到的界，与 descriptor 那一种是不同类型的。descriptor：一个闭区间，十一个内核版本，可从产物导出。form：一个有名字、有日期的写者，以及它背后一个开放的写者集合，只能从每个写者自己的历史里导出。对它你能陈述的是形状约束 —— summary 源须配 notice、sections 源须配 snapshot，而两个都不满足的那种，就是迁移所遇到的那一种 —— 那是一条种类上的界，不是时间上的界。

我们并不认为把这一条留着今天是有什么代价的；说清这个差别，只是为了让它日后不被读成"当初没来得及做的事"。

声明：上列 registry 读数由我本人对照已发布的包元数据完成；根因判读与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照已发布的包重新核实并更正。我们是插件作者、不是维护者，本文不陈述任何官方政策。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[xiaoshenming]

你们把形态 2 的界说清了，我补一个实操上的区别：写者集合不可枚举，不等于暴露面不可枚举。

形态 1 的窗口之所以「从产物里掉出来」，是因为决定它的值住在内核里。形态 2 的决定性事实其实也在产物里 —— 一条 source.kind === "plugin" 的消息，它的 form 是否与 summary/sections 相配，是工件自己的属性，不需要知道是哪个插件版本写出来的。所以对一个具体的会话库，暴露面是扫出来的：枚举盘上带该形态的行即可，与「有哪几条插件线、各自从哪个版本开始写它」无关。

我们这边就是按这个形状谓词做的（v0-plugin-source-form）：summary→notice、sections→snapshot，成员都留下；summary 与 sections 并存且冲突时不选边、只报告。也就是说，形态 2 缺的是预测（谁还会写出来），不是枚举（我这份库里现在有多少条）—— 后者随时可以做，前者同意留空。