The v0 migration refuses subagent/descriptor version 2 on the number alone, so sessions written before 2026-08-24 will not open

[nokkies]

session-format-v0-to-v1 refuses any v0 subagent/descriptor whose version
is not 3. SUBAGENT_DESCRIPTOR_VERSION was 2 until #2663 (merged 2026-08-24),
so every release before that date wrote version 2 — 0.1.0-rc.7,
0.1.0-rc.8, 0.1.1-rc.1, 0.1.1-rc.2. Anyone who used subagents on those
releases has sessions that cannot be opened on 0.1.5-alpha.1.

SessionFormatUnsupportedError: subagent/descriptor 0 uses unsupported
descriptor version 2; source v0 artifact remains unchanged

The shape of it is worse than the error suggests

It fails closed and leaves the artifact untouched, so nothing is lost. But a
listing reads only the header line, so the affected sessions still appear in
the session list with their titles, and refuse to open when clicked. Sessions
look present and are not.

Measured on one real store of 321 session logs:

measure	count
logs carrying a subagent/descriptor	291
logs whose descriptor is version 2	282
logs whose descriptor is version 3	9
logs the migration would refuse	282 of 321

The refusal is the number, not the payload

#2663 bumped 2 to 3 and added exactly one field, agentReasoningEffort. The
released-v0 disposition for this event requires mode, version, provider
and permits label, agentProvider, agentModel, agentReasoningEffort,
persona, toolFilter — so agentReasoningEffort is optional there, and a
version-2 payload is a valid version-3 payload by that same rule.

The code never gets that far. In assertReleasedEventPayload the version
comparison throws before assertReleasedV0Keys runs, so the payload is never
checked against the disposition that would accept it.

Every descriptor in that store, in five distinct key shapes:

shape	count
v2 agentModel,agentProvider,label,mode,provider,version	190
v2 label,mode,provider,version	40
v2 mode,provider,version	52
v3 agentModel,agentProvider,label,mode,provider,version	8
v3 label,mode,provider,version	1
violating the v3 disposition	0 of 291

Suggestion

Accept version 2 alongside 3 for a v0 source and let assertReleasedV0Keys do
the work it already does. On this evidence that costs no strictness: every
real payload passes the same key check a version-3 descriptor gets, and the
one field the bump introduced is optional in the disposition either way.

If the intent is that version 2 carries some semantic the migration cannot
reconstruct, then the error should say which one, because from the payloads
the two generations are indistinguishable apart from an optional field.

A branch carrying that, based on 5dda764ed3, so it applies with git am -3:

https://github.com/nokkies/dsh-upstream-patches/tree/fix/subagent-descriptor-generation-2

Generation 2 falls through to the key and value checks instead of being
refused, in both the disposition gate and subagentDescriptorValue. Every
other generation is still unknown and still refused, and the payload rules are
unchanged for both: an unlisted member, or an unpaired agentProvider, is
still rejected at generation 2. Measured over those 291 descriptors: 9
accepted before, 291 after. The package suite passes at 112.

[argszero]

@nokkies This report belongs to the same family as #5978 (over-strict v0 reads) — and yours adds the 291-descriptor quantitative evidence that #5978 lacked. I walked the rejection path line by line on the same baseline (5dda764); every claim checks out.

Source confirmation

1. The pre-gate fires before key validation: session-format-v0-to-v1/src/validation.ts:198-206 — in assertReleasedEventPayload, the event.type === 'subagent/descriptor' && data['version'] !== 3 branch throws SessionFormatUnsupportedMigrationError for version === 0 before assertReleasedV0Keys or payload semantics ever run. Exactly your "the code never gets that far".
2. "Accepting v2 costs no strictness" holds: dispositions.ts:92-96 — the descriptor disposition requires ['mode','version','provider'] and permits ['label','agentProvider','agentModel','agentReasoningEffort','persona','toolFilter']. agentReasoningEffort is in the optional list, so a v2 payload (which omits it) is a valid v3 payload under the same rule.
3. The second gate is equally hard-coded to 3: payload-validation.ts:955-956 — subagentDescriptorValue starts with literalValue(data['version'], [3], ...); the one-shot branch (:961) re-validates with assertReleasedV0Keys(data, ['mode','version','provider'], ['label']), which a v2 payload also passes. So the fix must touch both places (the validation gate and subagentDescriptorValue) — your branch already covers both, correct shape.

Family map (4 reports, one root cause)

Report	Face	Root cause
#5978	v0 read over-strict	origin member without optional (8/19-8/21 writer window) + descriptor-v2 hard throw — both root causes source-confirmed on 5dda764 by me (reply DC_kwDOT3T1g84BGBuO), archived upstream-fix candidate
#6045 (this one)	v0 read over-strict	descriptor-v2 hard throw, quantified: 282/291 refused, 0/291 violate the v3 disposition
#6010	V2→V3 over-strict (mirror face)	RELEASED_V2_RELATIONSHIP_EXTENSIONS missing the legacyInterruptedTurnRestart switch (one-line fix, source-confirmed, reply DC_kwDOT3T1g84BGDGk)
#6048	V2→V3 (#6010, third author re-report)	same

The shared root cause: the set of payloads released writers actually produced ≠ the set the reader-side dispositions/switches accept. Descriptor v2 was the normal value every pre-#2663 (2026-08-24) release wrote, yet the reader only accepts 3 — while the field #2663 introduced is optional in the disposition, which shows the bump updated the writer and constants but never added reader-side compatibility. That is the same pattern as #6010/#6048 (legacyInterruptedTurnRestart: the v2 writer leaves an unclosed turn on next-turn interruption; the reader-side switch was never enabled) — two faces of one failure mode: strictness gaps that appear when released-writer output is not aligned with the reader validator at release time.

On the fix shape + one systemic suggestion

Your fall-through (v2 and v3 run the same key/value checks; every other generation stays refused) is exactly the "widen the acceptance surface only" move adjacent-migration permits. Fail-closed guarantees zero data loss, but the "visible in the list, refuses to open" UX harm is real — all four reports in this family share it.

This is the 4th alignment crack between released writers and the validator (#5978/#6010/#6045/#6048). Worth adding a release-gate step that replays each released writer's fixtures through the reader-side validator and refuses any new crack — a "released-writer inventory ↔ validator disposition" diff check. That lives in core (release scripts), not on a plugin-mountable seam; my session-audit plugin (@argszero/cordis-plugin-session-audit) flags log corruption (seq-gap/index-reuse), which is an adjacent but different layer from migration refusal. Hoping upstream picks up your branch; otherwise it is a strong archived upstream-fix candidate.

[nokkies]

Still present at 0.1.5-rc.2, and I have a second store to add.

The gates are untouched since this was filed

This was reported against 0.1.5-alpha.1. Diffing the package between
dsh-v0.1.5-alpha.1 and dsh-v0.1.5-rc.2:

git diff --stat dsh-v0.1.5-alpha.1 dsh-v0.1.5-rc.2 -- packages/session/session-format-v0-to-v1/
 packages/session/session-format-v0-to-v1/package.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

One line, a version bump. validation.ts and payload-validation.ts are
byte-identical, so both gates @argszero identified are unchanged through two
further releases.

Second store, independent of the 321 above

A Windows deployment, 124 session logs, 884,317 event rows, every log at format
version: 0. Restored through sessionFormatCatalog.createRestore() on
@deepseek-ai/dsh@0.1.5-rc.2 from npm:

outcome	logs
restored to V3	35
refused	89
other failures	0

Every refusal is subagent/descriptor N uses unsupported descriptor version 2.
The split is the generation number and nothing else:

descriptor generation in log	logs	outcome
2	89	all refused
3	5	all restored
none present	30	all restored

The refused logs were all written between 2026-08-22 and 2026-08-30, which is
the pre-#2663 writer window. Restored logs span 2026-08-18 to 2026-09-08.

No caller can relax it

createRestore takes recovery and validation. All four combinations refuse
identically:

recovery / validation	result
strict / transformed	refused
strict / current	refused
recoverable / transformed	refused
recoverable / current	refused

readHeader succeeds on the same log and returns its cwd, which is why these
sessions list normally and fail only on open.

The branch clears it, and does not relax the payload

Applying the two widenings from
fix/subagent-descriptor-generation-2 to the published 0.1.5-rc.2 build and
re-running the same 124 logs: 124 restored, 0 refused, up from 35.

Strictness is unchanged. Against a real v0 header, varying only the descriptor:

descriptor	result
generation 2, well formed	accepted
generation 3, well formed	accepted
generation 1	refused, unsupported descriptor version 1
generation 4	refused, unsupported descriptor version 4
generation 2 + unknown member	refused
generation 3 + unknown member	refused

An unlisted member is refused at generation 2 exactly as at generation 3, so
the widening buys the old sessions and nothing else.

One thing that is not a second casualty

Worth recording, since it was the other upgrade risk: the projection cache
survives. session-projection-cache at rc.2 declares version: 7 with
compatibleVersions: [3, 4, 5, 6] and invalidRecords: 'backup-and-skip', and
this store's cache is version 3. Listing titles and stats are intact. The
descriptor refusal is the only thing standing between these sessions and the
upgrade.

[moonquake2004]

Thanks — the analysis holds on the installed build, and we can add a second, much smaller store.

Independent measurement. Different store, this machine, not the 321 or 124 above. 52 session.jsonl.zstd logs under ~/.dsh/sessions, every one at format version: 0. Scan: for each log, zstd -dc <file>, JSON-parse every line, track the header generation and each subagent/descriptor's data.version. Result: 3 logs carry a version-2 descriptor and none has a v3 companion.

We then ran the actual installed chain instead of pattern-matching. Feeding each log through sessionFormatCatalog.createRestore (session-format packages 0.1.5-rc.2, harness @deepseek-ai/dsh 0.1.5-rc.1) with validation: "current" and recovery: "strict" gives 39 restored, 13 refused, 0 other — and exactly those 3 fail with subagent/descriptor 0 uses unsupported descriptor version 2. The static scan and the real restore agree.

Two additions.

The refusal is genuinely side-effect-free. After the in-memory run, all three artifacts still carry their original bytes and mtimes, and no .v3 or temp file appeared. readHeader returns migration-required with a cwd, which is why they list and then fail on open.

The v2→v3 source-kind whitelist is not what stops them, and it does not cover session/title. assertSource is called at only three sites: user/message (line 98), assistant/message/tool/result (line 99), and the message arrays of agent/inbox/spliced/session/title-llm-request (line 107). A session/title event's own source never reaches it. Our store has 49 logs with session/title source kind fallback and 22 with provider — neither is among the 15 SOURCE_KINDS — and 36 of those logs restore cleanly. So title sources are not refused; that seems worth stating before #6311 gets read into #6045.

One caution for anyone scanning their own store: on ours the descriptor gate was not the only refusal. 10 of the 13 are permission/preset 0 data has unexpected member "origin" (the #5978 shape) — a separate fail-closed rule in the same chain.

This class is offline-detectable before anything is opened, which is why we're landing S12 in dsh-doctor: it reads the refusal rules out of the installed migration packages and reports affected logs up front — dsh-doctor --session <path> for one log, a full run for the store.

[marylyn326]

Title suggestion: 21 of 32 sessions in one profile refuse migration: subagent/descriptor version 2

Reproducing on a normal user profile — this is not an edge case, it is the
majority of a profile's history.

**Environment**
- dsh 0.1.5-rc.2 (npm installed side-by-side with the still-installed 0.1.2-rc.1)
- Linux, Node v22.22.1
- Profile: 32 session artifacts, all header `version: 0` on disk

**Result — driving the production chain, not the UI**
For each artifact: decompress the zstd frames to JSONL rows, then
`sessionFormatCatalog.createRestore(header, { recovery: 'strict', validation: 'current' })`,
`restore.decodeRow(...)` per row, `restore.finish()`.

    10 pass  → migrate to v3 cleanly
    22 fail
      21 of them: SessionFormatUnsupportedMigrationError:
                  subagent/descriptor 0 uses unsupported descriptor version 2
       1 of them: turn/start 444 does not close the prior turn   (separate defect, #6228)

**The offending row (one of the 21)**
Session created 2026-08-17, header `version: 0`. First event:

    {"type":"subagent/descriptor","seq":0,"time":1786915229877,
     "data":{"version":2,"mode":"continuable","provider":"spawn",
             "label":"D2 复盘总结存档","agentProvider":"..."}}

The v0→v1 edge refuses on the version number alone, so every session that ever
spawned a *continuable* subagent is unreadable after upgrading — while 0.1.2
reads all of them fine.

**Impact**
Upgrading makes 21 of 32 sessions (roughly two thirds of this profile's history)
impossible to open. The artifacts are preserved (fail-closed, "source v0 artifact
remains unchanged"), so nothing is lost — but there is no partial load, no skip
path and no repair path.

**Question**
Is `subagent/descriptor` version 2 a v0 value the migration is supposed to accept
(the number check being too strict), or is this genuinely out of vocabulary?
If it is a write-side regression, which release started writing version 2 —
so we know whether a session needs to predate it to be affected?

Raw excerpt of the offending row available on request.

[yamingmou]

Replying to your Question — my store answers the second half of it empirically.

Which release: all 258 of my sessions were written by 0.1.1-rc.2, and every one of the 202 subagent/descriptor events in them is version: 2 — so 0.1.1-rc.2 writes 2. It is the last release in the range @nokkies lists, so the upper bound holds at the boundary. (The switch to 3 is #2663, merged 2026-08-24 — that part is from the opening post, not my finding.)

One correction to your wording: it is not only continuable. In my store 201 descriptors are mode: "continuable" and one is mode: "one-shot" — also version: 2, and also refused:

ROW#7: subagent/descriptor 6 uses unsupported descriptor version 2

and it passes once the number is rewritten to 3. So the accurate phrasing is "every session that ever spawned a subagent"; continuable is just what dominates in practice (201 of 202 here).

Full numbers are in my comment below: 258 sessions (263 log files — two sessions had an extra file), 24 pass as-is, 201 refused on this gate, 224 after rewriting 2 → 3 in a copy.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming)

---

中文版 / ZH

回复你的 Question —— 我的样本从实证上回答了后半问。

哪个 release：我的 258 个会话全部由 0.1.1-rc.2 写入，其中 202 个 subagent/descriptor 事件全部是 version: 2 ⇒ 0.1.1-rc.2 写的就是 2。它是 @nokkies 所列受影响版本里的最后一个，因此上界在边界处成立。（2→3 的切换是 #2663，2026-08-24 合入——这一条出自主帖，不是我的发现。）

你的措辞要修正一处：不是只有 continuable。我的样本里 201 个是 mode: "continuable"，另有 1 个是 mode: "one-shot" —— 同样是 version: 2，同样被拒：

ROW#7: subagent/descriptor 6 uses unsupported descriptor version 2

把数字改成 3 之后它照样通过。所以准确说法是"spawn 过任意 subagent 的会话"；continuable 只是实践中的绝对多数（我这里 202 个里 201 个）。

完整数字见我下面的跟帖：258 个会话（263 个日志文件——其中两个会话各多一个文件）、原样 24 通过、201 因此门被拒、副本改 2→3 后 224。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）

[yamingmou]

Fifth store here, and a split that the previous four did not report.

Store: 258 sessions (from 263 log files — see the edit note at the end), all written by 0.1.1-rc.2. Read-only dry run — sessionFormatCatalog.createRestore with validation: 'current', recovery: 'strict', then decodeRow per row and finish(). Nothing on disk was modified.

measure	count
sessions (distinct)	258
passed the v0 → v3 chain as-is	24 (9.3%)
refused with subagent/descriptor … unsupported descriptor version 2	201 (77.9%)
after rewriting data.version 2 → 3 in a copy	224 pass (86.8%)

The split by session origin — the part the earlier stores did not report:

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

(255 of the 258 could be classified by header origin; the remaining 3 are counted in the totals above but not in the split.)

Two things follow from that split:

1. The blast radius is bounded and total at the same time. Every subagent session fails, and no non-subagent session is touched by this gate — their 21 failures are unchanged by the descriptor rewrite (turn structure, a different cause). So "who is affected" is not "everyone with old sessions", it is "everyone who ever ran a subagent on 0.1.0-rc.7 … 0.1.1-rc.2", and for them it is not a partial loss, it is all of it.
2. Rewriting the number is sufficient for the entire subagent class — 200 of 200. That is independent agreement with @nokkies' payload finding (0 of 291 descriptors violate the v3 disposition): nothing behind the number needs reconstruction.

My store was written by 0.1.1-rc.2, the last release in the affected range listed in the opening post, so the upper bound holds at the boundary.

Environment: session-format packages 0.1.5-rc.2, Node 22. Still present at 0.1.5-rc.2.

Edited: the count below was 263 log files — 258 of them are distinct sessions (two session directories had an extra session.v3.jsonl.zstd next to the v0 one, and my first scan counted files, not sessions). The pass counts are unchanged; only the denominators and the percentages move.

Authorship note: measured and documented 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

---

中文版 / ZH

这里是第五份独立样本，另外补一个此前四份都没报的维度。

样本：258 个会话（来自 263 个日志文件，见文末更正说明），全部由 0.1.1-rc.2 写入。只读干跑——sessionFormatCatalog.createRestore（validation: 'current'、recovery: 'strict'），逐行 decodeRow 后 finish()。磁盘上的数据一个字节都没改。

指标	数量
会话数（去重后）	258
原样通过 v0 → v3 链	24（9.3%）
因 subagent/descriptor … unsupported descriptor version 2 被拒	201（77.9%）
在副本上把 data.version 由 2 改写为 3 之后	224 通过（86.8%）

按会话 origin 拆分——此前四份样本都没有报的那一维：

origin	日志数	原样被拒	改 2→3 后通过
subagent	200	200（100%）	200（100%）
非 subagent（root / fork）	55	21	21（无变化）

（258 个中有 255 个能按 header origin 归类；余下 3 个计入上面总数，但不参与拆分。）

由此得到两点：

1. 影响面同时是"有边界的"和"彻底的"。 每一个 subagent 会话都失败，而非 subagent 会话一个都没被这道门碰到——它们的 21 个失败在改写 descriptor 前后毫无变化（那是 turn 结构问题，另一个原因）。所以"谁受影响"不是"所有有老会话的人"，而是"在 0.1.0-rc.7 … 0.1.1-rc.2 上用过 subagent 的人"；对他们而言也不是部分损失，是全部。
2. 对 subagent 这一类，改掉那个数字就够了——200 / 200。这也独立印证了 @nokkies 对载荷的判断（291 个 descriptor 中 0 个违反 v3 disposition）：数字背后不需要重建任何东西。

我这批样本由 0.1.1-rc.2 写入，是主帖所列受影响版本里的最后一个，因此上界在边界处成立。

环境：session-format 包 0.1.5-rc.2，Node 22。0.1.5-rc.2 上问题仍在。

署名说明：样本由我在自己的会话库上实测并整理；根因追溯与起草借助 AI；复核与发布由我完成。我没有工程背景——如任何技术表述有误，请直接指出，我会对照工具链重新核验并更正。

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

已更正：下面的数字原为 263 个日志文件，其中 258 个是唯一会话（两个会话目录下除 v0 的 session.jsonl.zstd 外还有一个 session.v3.jsonl.zstd，我第一次扫描按文件计数而非按会话）。通过数全部不变，只有分母与百分比变动。

[moonquake2004]

Answering @marylyn326's question, plus one note on @yamingmou's origin split.

Version 2 is a value the harness itself wrote — the gate is what is too strict. On the installed 0.1.5-rc.1 tree, SUBAGENT_DESCRIPTOR_VERSION is now 3 (dsh-subagent/lib/index.js:1300) and the v0→v1 edge pins the literal: if (event.type === "subagent/descriptor" && data["version"] !== 3) throws (dsh-session-format-v0-to-v1/lib/index.js:1584-1586). #2663 (merged 2026-08-24) is the change that bumped 2 → 3 and, per the opening post, added exactly one field (agentReasoningEffort) — so sessions written before that date are refused on the number alone while their payload is already v3-shaped. On the release window the opening post lists 0.1.0-rc.7 … 0.1.1-rc.2; I can confirm the upper bound from the merge date and the current constant, but I have not verified which release first introduced the field, so I would not state a lower bound beyond that list.

On the origin split (@yamingmou): that is the sharpest statement of blast radius in this thread. We see the same mechanism from the other side — running the real chain over a 74-log store refuses 13, and the split is 3 by this descriptor gate, 10 by a different fail-closed rule (permission/preset 0 data has unexpected member "origin", the #5978 shape). So on a store that never ran subagents the descriptor gate is invisible, exactly as your split predicts, and a "how many sessions will I lose" estimate should count both rules.

This class is detectable before anything is opened. dsh-doctor 0.4.7 runs the installed migration chain in memory and lists the affected logs up front (npx @moonquake2004/dsh-doctor; --session <path> for one log, a full run for the store). It reports both rules, and since refusal is fail-closed and side-effect-free the list is safe to produce on a live store.

[yamingmou]

EN / English

Taking your note — and the table it asks for. @moonquake2004, you called the origin split the sharpest statement of blast radius in this thread and then added the half we did not have: on your 74-log store, 13 refused split as 3 by the descriptor gate + 10 by a different fail-closed rule. You closed with "a 'how many sessions will I lose' estimate should count both rules." We kept the per-session dry-run rows from the same store our split came from, so we can now count both on one install.

Table 1 — one store, every refusal, by rule. 262 log files, one install, all at format version: 0, read-only dry run through sessionFormatCatalog.createRestore (validation: 'current', recovery: 'strict'). Counts sum to 262:

rule that refused it	logs
subagent/descriptor … unsupported descriptor version 2 — the descriptor gate	200
(passed as-is)	24
turn/start … does not close the prior turn	14
turn/start N does not open expected turn 1 (transformed-artifact stage)	7
… data has unexpected member … — the #5978 shape	3
HEADER: Unexpected token … is not valid JSON — damaged files, not a migration rule	3
assistant/attempt does not match an open turn and step	2
assistant/message … chunk provenance is not one complete ordered attempt	2
format v0 contains an unknown historical event type	2
Session inheritedEventCount exceeds its event count	2
inherited Session cut … splits one Assistant attempt	1
turn/end … reason abort kind must be one of …	1
session/title … messageSeqs must cite earlier human user/message events	1
total	262

Table 2 — the part that decides whether the two rules overlap. 255 sessions in the same store that carry a classifiable header origin:

header origin	passed	descriptor gate	all other rules
subagent	0	200	1
root / fork ((none))	21	0	33

⇒ On this store the two victim sets are disjoint, and that is stronger than "count both": the descriptor gate hit only subagent sessions (200 of 200), while none of the 33 non-subagent failures was the descriptor gate. So the two rules can simply be added — there is nothing to de-duplicate, and an estimate does not need a joint distribution.

The control that isolates the gate. Rewriting data.version 2 → 3 in a copy and re-running the same chain: 200 of 200 subagent sessions flip to pass, while the 54 non-subagent ones are unchanged (21 pass stay pass, 21 fail stay fail). The rewrite touches exactly one rule and nothing else — which is also why your second rule is invisible to it.

One narrowing on terminology, since we are now counting rules. Your ten are permission/preset … unexpected member "origin"; our three are assistant/message … data has unexpected member. Those are the same shape over different fields, so as a rule they are best counted as one family — data has unexpected member — rather than as the field that happened to trip it. ⚠️ And the ratio does not travel: 10 of 74 on your install (13.5%) versus 3 of 262 on ours (1.1%). That gap is exactly why "count both rules" is the right advice and "scale one store's percentage" is not.

On line numbers. dsh-session-format-v0-to-v1/lib/index.js:1584 (data["version"] !== 3) is character-identical on our build (0.1.6-alpha.2) — your 1584 matches. But SUBAGENT_DESCRIPTOR_VERSION = 3 sits at :1300 on your 0.1.5-rc.1 tree and :1343 on ours, which is the same published-artifact-versus-upstream-source offset you raised on 09-12. We agree with the conclusion you drew there: quote the identifier plus the artifact, and treat the number as decoration.

Honest boundaries. Read-only dry run — nothing on disk was modified. One install; the 262 log files are ours, and 255 of them carry a classifiable origin. The three HEADER rows are damaged files rather than a migration rule, and are marked as such above even though they are included in the total. We did not reproduce your permission/preset case, so our 3 are the same family, not the same field.

Authorship note: reproduced and documented by me in real-world usage; 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

---

中文版 / ZH

接受你的注 —— 以及它要的那张表。 @moonquake2004，你把 origin split 称为这条线程里对影响面最锋利的那句，然后补上了我们缺的那一半：你那台 74 条日志的 store 上，13 条被拒拆成 3 条走 descriptor 门 + 10 条走另一条 fail-closed 规则。你收尾那句是*"「我会丢多少会话」的估算必须同时算两条规则"*。我们当初算出那个 split 的那次逐会话干跑结果还在，所以现在可以在同一台机器上把两条都算出来。

表 1 —— 同一个 store，逐条拒因，按规则归类。 262 个日志文件、一台机器、全部 format version: 0，只读干跑 sessionFormatCatalog.createRestore（validation: 'current'、recovery: 'strict'）。各计数合计 = 262：

拒绝它的规则	日志数
subagent/descriptor … unsupported descriptor version 2 —— descriptor 门	200
（原样通过）	24
turn/start … does not close the prior turn	14
turn/start N does not open expected turn 1（transformed-artifact 阶段）	7
… data has unexpected member … —— #5978 那一形状	3
HEADER: Unexpected token … is not valid JSON —— 文件损坏，不是迁移规则	3
assistant/attempt does not match an open turn and step	2
assistant/message … chunk provenance is not one complete ordered attempt	2
format v0 contains an unknown historical event type	2
Session inheritedEventCount exceeds its event count	2
inherited Session cut … splits one Assistant attempt	1
turn/end … reason abort kind must be one of …	1
session/title … messageSeqs must cite earlier human user/message events	1
合计	262

表 2 —— 决定"两条规则是否重叠"的那张。 同一 store 里 255 条带可分类 header origin 的会话：

header origin	通过	descriptor 门	其余全部规则
subagent	0	200	1
root / fork（(none)）	21	0	33

⇒ 在这个 store 上，两个"受害者集合"是不重叠的**。** 这比"要算两条"更有力：descriptor 门命中的 200 条全部是 subagent 会话，而非 subagent 的 33 条失败里没有一条是 descriptor 门。
⇒ 所以两条规则可以直接相加 —— 没有需要去重的部分，估算也不需要联合分布。

把这条门单独隔离出来的对照。 在副本里把 data.version 由 2 改写成 3、再跑同一条链：200 条 subagent 会话全部翻为通过，而 54 条非 subagent 完全不变（21 条通过仍是通过、21 条失败仍是失败）。这次改写只碰到一条规则、别的不碰 —— 这也正是你那条第二规则对它完全不可见的原因。

一处术语收窄（既然我们现在是按"规则"计数）。 你那十条是 permission/preset … unexpected member "origin"；我们这三条是 assistant/message … data has unexpected member。它们是同一形状、不同字段，所以按规则计数时，最好归为一族 —— data has unexpected member —— 而不是按"恰好触发的那个字段"分。⚠️ 而且这个比例不能外推：你那台 10/74（13.5%） vs 我们 3/262（1.1%）。这个落差恰恰说明"两条都要算"是对的建议，而"拿一个 store 的百分比去缩放"不是。

关于行号。 dsh-session-format-v0-to-v1/lib/index.js:1584（data["version"] !== 3）在我们这个构建（0.1.6-alpha.2）上逐字一致 —— 你引的 1584 对得上。但 SUBAGENT_DESCRIPTOR_VERSION = 3 在你那棵 0.1.5-rc.1 树上位于 :1300，在我们这儿是 :1343 —— 这就是你 9/12 自己提出的那处"已发布产物 vs 上游源码"的偏移。我们同意你当时的结论：引用应以标识名 + 具体产物为准，行号只作辅助。

诚实边界。 以上是只读干跑 —— 磁盘上任何文件都没改。单机样本：262 个日志文件是我们的，其中 255 条带可分类的 origin。那 3 条 HEADER 是文件损坏而非迁移规则，虽然计入 262 合计，但已在上表标明。我们没有复现你那个 permission/preset 用例 —— 所以我们的 3 条是同一族、不是同一字段。

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

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

[PerryLink]

核实结论：完全属实，而且是四个同族报告（#5978/#6010/#6045/#6048）里量化证据最充分的一个。

1. 第一道门：validation.ts:198-206 对 data.version !== 3 直接抛 SessionFormatUnsupportedMigrationError，且在 assertReleasedV0Keys 之前 —— 「payload 根本没被检查」成立。
2. 第二道门同样硬编码 [3]：payload-validation.ts:955-956 的 subagentDescriptorValue 起手 literalValue(data['version'], [3])。
3. 而 dispositions.ts:92-95 表明 由插件重复安装引起的桌面端崩溃 #2663 新增的 agentReasoningEffort 本就是可选字段 —— v2 payload 按同一规则可以通过 v3 的 key 检查，拒绝纯因版本数字。
4. 版本史经 git 证实：PR 由插件重复安装引起的桌面端崩溃 #2663（f76a225a7d，2026-08-24）把 SUBAGENT_DESCRIPTOR_VERSION 从 2 升到 3，且只新增了一个可选字段；首个含该提交的 tag 是 0.1.2-alpha.1 ⇒ 0.1.0-rc.7 至 0.1.1-rc.2 写的都是 version 2；alpha.1→rc.2 之间 session-format-v0-to-v1 仅 package.json 一行变化，问题至今未修。
5. 报错文案与 fail-closed 行为（拒绝时不发布 successor、原始日志保持不动）与源码逐字一致（session-persistence-jsonl/src/index.ts:673-677）。

你的修复方向（同时放宽 validation 门与 subagentDescriptorValue，其他代际仍拒绝、payload 规则不变）正确。（各 store 统计数字与「112 测试通过」未独立复测；moonquake2004 的 assertSource 行号比实际约差 17 行，实质结论无误。）

[moonquake2004]

Thanks for checking this against the source — two things you added that the opening post did not establish: the second gate hardcodes [3] as well (payload-validation.ts:955-956), and the field #2663 added is optional (dispositions.ts:92-95), so a v2 payload would pass the v3 key checks and the rejection really is the number alone. Your git-verified tag boundary (first tag containing f76a225a7d is 0.1.2-alpha.1) also closes the release-window question @marylyn326 asked — I could only confirm the upper bound, so that is the half I deliberately left open, now answered.

One line-number note: on the installed @deepseek-ai/dsh-session-format-v2-to-v3@0.1.5-rc.2, the assertSource call sites are at lib/index.js:98, :99 and :107, with the definition at :123 — just re-checked. The ~17-line offset you saw is likely a different artifact (published lib/index.js versus upstream src/*.ts); worth pinning which one each of us quotes, since both of us use line numbers as evidence.

Agreed on the fix direction: relax both gates, keep other generations refused, and leave the payload rules untouched.

[ERICLI228]

Status check + impact data (2026-09-15)

• Unchanged in dsh-v0.1.6-alpha.1 and current master: packages/session/session-format-v0-to-v1/src/validation.ts (L198) still rejects any subagent/descriptor whose version !== 3.
• Impact on one install upgraded from 0.1.1-rc.2, measured read-only with the 0.1.5-rc.2 sessionFormatCatalog (source files untouched): 72 of 393 sessions fail at this gate.
• Content-free repro: a single subagent/descriptor row with version: 2 through createRestore(header, { recovery: "strict", validation: "transformed" }) is rejected; the same row with version: 3 passes.

We are staying on 0.1.1-rc.2 instead of rewriting session files until released v2 descriptors are accepted.