Session unloadable: v1→v2 migration rejects assistant/message 4060703 — declared 874 source refs vs 873 reconstructed (range starts on a session/end-seed)

[xiaowei2025cqu23phy]

Summary

A long-running session (461 turns, 170,416 records) can no longer be observed/loaded. The v1→v2 session-format migration refuses it because exactly one assistant/message cites a source-event range that starts one event earlier than the first chunk event the migration reconstructs for that attempt.

• assistant/message seq=4060703 (turn 450, step 24) declares sourceEventSeqs: [[4059829, 4060702]] → 874 references.
• The migration reconstructs 873 chunk events for that attempt: 4059830 … 4060702.
• The single extra reference, seq 4059829, is not a chunk event in this file — it is a session/end-seed record ({"type":"session/end-seed","seq":4059829,"time":1788954489814,"data":{}}).

The session data itself looks intact (no records lost; see measurements). I would like to recover this session, and I would like to know whether this is a writer bug, a migration-strictness bug, or both. Full diagnosis below; I am happy to send the file or a redacted extract.

Error

Surfaced by the desktop client when opening the session:

历史加载失败：failed to observe session "session-ec57579b-8cb9-4b35-aa37-fe36c235e5eb":
assistant/message 4060703 chunk references are not one complete ordered attempt;
source v0 artifact remains unchanged
(raw log: C:\Users\34745\.dsh\sessions\--D-Users-34745-Desktop-github-deepseek-aideepseek-harness--\session-ec57579b-8cb9-4b35-aa37-fe36c235e5eb\session.jsonl.zstd)
(gateway/internal)

Where the refusal is thrown

In the installed desktop build (bundled runtime, see Environment):

• Module: dsh/node_modules/@deepseek-ai/dsh-session-format-v1-to-v2/lib/index.js inside app.asar
  (asar-relative file offset 49,821,697, size 33,614; the migration bundle is also present in dsh/node_modules/@deepseek-ai/dsh-session-persistence-jsonl/lib/worker.cjs)
• function transformMessage at asar byte 53,212,045 (≈ line 518 of the module)
• the refusal template chunk references are not one complete ordered attempt at asar byte 53,213,008 (≈ line 539)
• function matchesChunkSources at asar byte 53,217,517 (≈ line 672)

if (pending === void 0 || !matchesChunkSources(pending.group, sources))
  throw refusal(`assistant/message ${event.seq} chunk references are not one complete ordered attempt`);
...
function matchesChunkSources(group, sources) {
  if (sources.length !== group.chunkCount) return false;
  let index = 0;
  for (const span of group.spans)
    for (let offset = 0; offset < span.eventCount; offset += 1) {
      if (sources[index] !== span.firstSeq + offset) return false;
      index += 1;
    }
  return true;
}

Span accounting is built by transformChunk (one assistant/chunk event → recordChunkSpan(group, event.seq, 1, …)), by transformReleasedRun (a released compacted run → recordChunkSpan(group, run.firstSeq, run.eventCount, …)), and merged in recordChunkSpan; finishAttempt / flushAccumulator / appendStreamRecord are the adjacent paths. So chunkCount/spans describe the chunk events of the attempt, and matchesChunkSources requires the declared sourceEventSeqs to equal that list exactly — same length, same order, no extra member.

Because the throw is immediate and messages are processed in order, the error naming seq=4060703 also means every earlier assistant/message in this 170k-record file passed the same check.

Environment

item	value
DSH desktop	installed build 0.1.7-rc.2 (from resources/runtime/primary-runtime/runtime.json → desktopVersion, and app.asar → dsh/package.json → @deepseek-ai/dsh-desktop-runtime@0.1.7-rc.2)
session-format package	@deepseek-ai/dsh-session-format-v1-to-v2@0.1.7-rc.2 (declared in the same dsh/package.json)
update channel	nightly, https://download.deepseek.com/dsh-desk/feeds/win-x64/ (resources/app-update.yml)
bundled runtime	Node 24.21.0, pnpm 11.7.0, Python 3.12.14, win32 x64
OS	Windows x64

Unverified / caveat: the installed application files are dated 2026-09-24, while the session was written on 2026-09-09/10, so I cannot confirm which build produced the file or threw the original error. The refusal text and the code above match the installed 0.1.7-rc.2 bundle verbatim, but I could not find any build/version stamp for the writing run (the session projection cache only carries its own "version": 5). If you need the exact writing build I will dig further — tell me what identifier to look for.

Happy to provide anything else you need (dsh version output, full log lines, the decoded JSONL, app.asar extraction).

Session

• File: …\session-ec57579b-8cb9-4b35-aa37-fe36c235e5eb\session.jsonl.zstd
• Compressed 27,245,912 B, mtime 2026-09-10 17:41:51 (+08:00); decodes cleanly with zstd -d (exit 0, no truncation warning) to 165,369,254 B / 170,416 JSONL records.
• Header record: {"type":"session","version":0,"id":"session-ec57579b-…","createdAt":1786824256927,"cwd":"D:\\Users\\34745\\Desktop\\github\\deepseek-aideepseek-harness","delegationDepth":0,"agentPreset":"standard"} → source format v0.
• Events span 2026-08-15T20:04:16.975Z → 2026-09-10T09:41:51.990Z; 461 turns, 9,042 step/start events, 43 session/end-seed boundaries, 119 compactions.

Measurements

metric	value
records	170,416
records with top-level seq	109,804 distinct, range 0 … 4,125,203
records without top-level seq	60,612 — of which 60,611 carry seq0 (the other is the session header)
seq numbers absent from [0, 4,125,203]	4,015,400, all inside ranges covered by the seq0 compact records (18,192 gap runs)
assistant/message records	8,970
… that satisfy the check	8,969
… that fail the check	1 — seq=4060703, turn 450 step 24
declared refs for 4060703	874 ([[4059829, 4060702]])
reconstructed refs (spans / chunkCount)	873 (4059830 … 4060702)
extra declared ref	4059829 = session/end-seed, data: {}

The 873 decomposes as 12 explicit assistant/chunk events plus 861 seq numbers inside 18 compact records (reasoning-chunks / text-chunks / tool-call-chunks) for that step, which transformReleasedRun folds into the attempt.

How I obtained the 8,969 / 1 split (so you can judge it): I decoded the JSONL and re-implemented the span accounting and matchesChunkSources in a script, treating each compact *-chunks record as one released run spanning [seq0, seq0 + payloadCount). Merging adjacent spans in recordChunkSpan makes any grouping of adjacent records equivalent, but I did not inspect the v0→v1 stage, so the exact run boundaries it produces are unverified. I could not execute the shipped migration directly. The conclusion that all earlier messages pass does not depend on that emulation: the migration throws on the first offending message and reports 4060703.

Avoidable red herring

Counting only materialised assistant/chunk events understates every attempt in this file, because most deltas live in the compact seq0 records. For the failing step that count is 12 against 874 declared; for a passing step such as turn 1 step 2 it is 8 against 128 declared. Those large ratios are expected and are not the defect.

What is actually different in this file

Immediately around the failing attempt (records in file order):

assistant/chunk     seq=4059823  turn 450 step 23  block-end
assistant/message   seq=4059824  turn 450 step 23  sourceEventSeqs=[[4059746, 4059823]]   ← passes
tool/call           seq=4059825
tool/result         seq=4059826
step/end            seq=4059827
turn/end            seq=4059828
session/end-seed    seq=4059829  data {}
assistant/chunk     seq=4059830  turn 450 step 24  reasoning-delta  ("结果")
reasoning-chunks    seq0=4059831 … (18 compact records through 4060697)
assistant/chunk     seq=4060698..4060702  block-end ×3, usage, finish
assistant/message   seq=4060703  turn 450 step 24  sourceEventSeqs=[[4059829, 4060702]]     ← refused

Observations for this attempt, all measured:

• there is no step/start record for turn 450 step 24 anywhere in the file;
• there is no block-start chunk for the reasoning block — the attempt opens with reasoning-delta at 4059830;
• seq 4059829 is occupied by the session/end-seed;
• the declared range nonetheless starts at 4059829.

session/end-seed is the only record type in this file that any assistant/message cites as a source event: across all 8,970 messages, exactly one declared reference (this one) is not part of a chunk event.

The declared range is identical in the pre-existing sibling snapshot (below), which is consistent with the range having been written while 4059829 was still the attempt's block-start and not rewritten when that position became the seed. I have not verified the write order — flagging it as an inference, not a measurement.

Control: the older sibling snapshot does not fail

Sibling session.jsonl.zstd.orig53.bak (53,117,939 B, mtime 2026-09-09 22:12:18) decodes to 164,062,629 B / 168,477 records. Same encoding shape (60,611 compact seq0 records, 17,990 gap runs, first run 24..386, 8,932 assistant/message). It contains the same assistant/message at seq=4060703 with the same sourceEventSeqs=[[4059829, 4060702]], and under the same re-implementation 0 messages fail.

The difference at the boundary (both files order records identically before it):

	backup	current
seq 4059828	step/start turn 450 step 24	absent
seq 4059829	session/end-seed and assistant/chunk (block-start, turn 450 step 24)	session/end-seed only
re-used top-level seq values	4	0
result of the check on 4060703	passes	refused

So in the backup the replay after the seed re-establishes the attempt's block-start at 4059829 and the declared range is exactly satisfied; in the current file the attempt opens at 4059830 while the declaration still starts at 4059829.

Minimal reproduction

I do not have a minimal repro file yet. What I can offer instead, on request:

• a redacted extract around seq 4059740…4060710 (the seed boundary plus the whole failing attempt), which I expect is enough to reproduce the refusal;
• the failing assistant/message / session/end-seed / assistant/chunk lines verbatim;
• the decoded JSONL (165 MB) or a filtered slice;
• the full session file (session.jsonl.zstd, 27 MB) if you would rather have the original.

I have not uploaded anything: this is a private long-running session, so I hesitated to publish it. Tell me which artefact you want, and the smallest one that would let you reproduce this, and I will send it.

Ask

The session data looks intact — nothing else in the file is inconsistent, and the mismatch is a single one-event offset — and I would like to get this session loadable again. Questions, in priority order:

1. Recovery. Is there a supported way to recover a session that is already unloadable: a repair/dsh-side command, a re-migration flag, a documented procedure to fix one sourceEventSeqs value inside the .zstd JSONL — or should I hand this file to you? I would rather not hand-edit a session store without guidance.
2. Intended contract. Is sourceEventSeqs meant to list only chunk events of the attempt, or may it also include non-chunk neighbours such as the session/end-seed boundary? If the latter is allowed, should matchesChunkSources compare against the chunk subset instead of requiring exact list equality?
3. Writer. Is the current file's state — seed at the attempt's first-chunk seq, no step/start and no reasoning block-start for that step, no replayed tail — an expected outcome of a seeded/resumed generation that continues the previous generation's seq numbering, or a sign that the attempt head was lost? Related: could sourceEventSeqs have been computed from a pre-seed / pre-compaction chunk layout that the file no longer matches? I have not verified which component wrote 4059829, so I am phrasing this as a question.
4. Blast radius. This file has one occurrence in 8,970 messages. Is the "declared range starts on the boundary event" pattern known to occur elsewhere, or would a targeted guard in the migration plus a writer-side assertion be the right shape of fix?

[kittimzhe]

Your numbers reproduce exactly against the migration source: matchesChunkSources (packages/session/session-format-v1-to-v2/src/migration.ts:473-483) requires the declared sourceEventSeqs to equal the reconstructed attempt — element count and every seq — and 874 ≠ 873 refuses at line 294.

To answer your question — both sides have a defect, but only one is still live:

• Writer (historical): under the frozen v1 contract ("a successful v1 assistant/message must cite its complete ordered attempt" — the package README), citing the session/end-seed marker violates the contract. The plausible mechanism: the end-seed landed between the previous surface event and this attempt's first chunk, and the writer's source window swept it in. That's why exactly one message in 170k records — it only bites when seeding completes inside a message window. The current writer no longer emits sourceEventSeqs on assistant messages at all (they embed the stream), so this side is historical v1-only.
• Migration (live): the transform stage has no recovery mode — every refusal is an unconditional SessionFormatUnsupportedMigrationError (only the v1 decoder has a strict/recovery seam, for seq gaps). A 1/874 prefix overshoot on verified-intact data bricks a 461-turn session at every load. The migration already reasons carefully about cut-vs-attempt boundaries elsewhere (lines 373/379 refuse cuts that split attempts); tolerating a declared range that prefix-extends the attempt with non-chunk structural markers — clamping it and recording an issue — would fit that same spirit.

Immediate recovery for your file: back it up, then rewrite that one record's sourceEventSeqs from [[4059829,4060702]] to [[4059830,4060702]]. The migration then matches exactly and the session loads. Worth scanning the file for other messages whose range starts on a non-chunk event (happy to send a jq/python one-liner if useful, or verify on a redacted extract).

[xiaoyuyu6420]

kittimzhe 确认了门位，补一条立即可用的修复路径——你这个案例的形态恰好是三种悬挂/溯源损伤里最好修的一种：坏的只是一行声明，不需要重编号。

原理：v2 格式每行一个事件、sourceEventSeqs 按范围编码在信封里；迁移器要求「声明的引用 == 从 chunk 重建的 attempt」。你的差异是那一条 assistant/message 的声明范围多含了起点 4059829（一个 session/end-seed 继承接点）。把它改成与重建结果一致即可：

"sourceEventSeqs": [[4059830, 4060702]]

即把范围起点从 4059829 挪到 4059830，引用数 874 → 873，与迁移器重建的 attempt 逐元素相等。seed 事件本身（4059829 那行）不受影响——你只是不再把它声明为该消息的 chunk 来源，它的继承切点语义仍由它自己承载。

操作步骤（动字节前老三样：停 dsh、整目录留副本、改完全量校验）：

1. 定位那行：解压日志后按 assistant/message + "seq":4060703 找到所在行；
2. 该行落在哪个 zstd 帧就只重编那个帧——容器是逐帧独立的，其余帧字节不动；
3. 重编后用与 kittimzhe 相同的门自校验：全量 walk 帧 + 逐行 matchesChunkSources 语义过一遍，0 缺陷再放回。

两点附带价值：

• 这是溯源家族的新形态：此前记录过 descriptor v2、permission/preset origin、插件 source summary/form、悬空 tool-call，你这是「范围起点锚在 end-seed 上」的 off-by-one——建议把本帖并进 DSH master (0.1.6-alpha.2 / ddefc45fbc) 仍未修复的问题清单（社区核实版） #6520 的清单，上游修复方向是让 v1→v2 边容忍「以继承切点为起点的 attempt 范围」（seed 本来就是那段历史的合法起点）；
• 461 轮 / 17 万条记录的会话值得修完之后立刻做份离线备份——这么大的会话再出一次容器级损伤，手工修复成本会高一个量级。

[xiaoshenming]

补一条工具侧的实测，和 @xiaoyuyu6420 给的手改配方落在同一处归一上。

形状本身我按真实链路复现了（不含你的文件）：一个 v0 工件里，assistant/message 声明的范围把非分块事件（你这里就是 seq 4059829 的 session/end-seed）也圈了进去 → v0→v1 那道 stage 原样放过，v1→v2 才拒，报错与你贴的一字不差：assistant/message <seq> chunk references are not one complete ordered attempt。在 0.1.7-rc.2 上：修前拒；把声明改成重建出来的那一段（你的例子 874 → 873，起点 4059830）之后官方链路通过。

dsh-session-surgeon 的 v0-chunk-provenance 判据就是这个：声明是否等于同一 (turn, step) 自上次尝试边界（turn/end / step/end / llm/retry / llm/retry-started，同官方 closesAttempt）以来的完整有序一段。命中后只做一件事 —— 把 sourceEventSeqs 改写成磁盘上已经存在的那段分块序号：不新增 seq、不删事件、不动 session/end-seed 本身（它的继承切点语义仍由它自己承载）。[[4059829, 4060702]] 会被写成语义相同的密集整数 run。

流程：先停写者 → inspect（会报 v0-chunk-provenance 与命中的 seq）→ repair（默认 dry-run，不写文件）→ --apply（先写 .bak.<utc>）。

边界：只在「声明与磁盘分块 run 不一致」时才改；如果分块本身缺号/乱序（问题不在声明上），我们只报告、不猜；surfaceOp: replace 的消息（/rewind 撤回标记）绝不动 —— 它的引用是 applySurface 要求的 shadowed 节点。你这是最干净的一类：坏的只有一行声明。

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

170,416 条记录建议先复制一份在旁边跑 dry-run。我测的是同形状的构造样本、不是你的文件 —— 如果 dry-run 出来的动作不是恰好一条、或者没落在 seq 4060703 上，把输出贴回来我看。

[xiaowei2025cqu23phy]

Session unloadable: turn/end emitted while a step is still open — two interrupted-resume boundaries in one turn

TL;DR — A v0 session (461 turns / 170k records) fails migration with
assistant/message does not match an open turn and step. Root cause is not chunk
provenance: one turn/end (and the session/end-seed that follows it) was emitted
mid-turn, so steps 24–59 of turn 450 live after their own turn was closed. Two
secondary imbalances (a step/start and a step/end lost on the resume boundary) come
from the same two interruptions.

I am not uploading the session. Happy to provide a redacted structural extract
(carries no message text) or to run any probe you suggest against it.

Relationship to the earlier chunk-provenance defect

Same session, two independent defects. The chunk-provenance one was real and I fixed
it locally by rewriting one record's declared range:

- "sourceEventSeqs":[[4059829,4060702]]
+ "sourceEventSeqs":[[4059830,4060702]]

That fix is confirmed effective — the migration now proceeds past it and fails later, on a
different check:

before: assistant/message 4060703 chunk references are not one complete ordered attempt
after:  Session migration from v0 to v4 refuses the transformed artifact:
        assistant/message does not match an open turn and step

Notably 4059829 — the seq the first defect revolved around — is one of the two
misplaced events in the second defect (see below). I suspect both are symptoms of the
same writer-side disturbance: see "Hypothesis".

Defect A — turn/end emitted while a step is open

@deepseek-ai/dsh-session/lib/invariant.js requires:

case "turn/end":
  if (trace.openTurn !== event.data.turn) fail(...)
  if (trace.openStep !== null) fail(`turn/end ${event.data.turn} while step ${trace.openStep} is still open`)
  openTurn = null

The raw log around turn 450:

167571  tool/call        seq=4059825  turn=450 step=23
167572  tool/result      seq=4059826  turn=450 step=23
167573  step/end         seq=4059827  turn=450 step=23     ← step 23 closes cleanly
167574  turn/end         seq=4059828  turn=450             ← ★ turn closed here…
167575  session/end-seed seq=4059829
167576  assistant/chunk  seq=4059830  turn=450 step=24     ← …but steps 24–59 continue
   …                                                        898 records later
168472  step/end         seq=4080255  turn=450 step=58
168473  step/start       seq=4080256  turn=450 step=59
168474  session/end-seed seq=4080257
168475  agent/inbox/spliced seq=4080258
168476  turn/start       seq=4080259  turn=451

So turn 450 has one turn/start (line 166874) and one turn/end (line 167574), but
its content spans 59 steps across two resume boundaries. turn/end therefore always lands
while a step is open.

File-wide this is the only such turn: I checked every turn for
max(step/end line) > turn/end line and exactly 1 of 461 fails.

Defect B — two lost step boundaries on the two resume points

Per step, step/start/step/end pair up for all steps of turn 450 except two:

step  1: start 行166876  end 行166913
…
step 24: start ✗missing  end 行167609     ← resumed in the middle of the step
…
step 58: start 行168450  end 行168472
step 59: start 行168473  end ✗missing     ← interrupted again before closing

Both missing boundaries sit exactly at the two session/end-seed records, i.e. at the two
interruption points.

What the canonical resume boundary looks like

Every other resume in this file follows the same shape (43 session/end-seed records,
all of them turn-boundary):

step/end → turn/end → session/end-seed → agent/inbox/spliced → turn/start(N+1)

Turn 450's first resume is the only one that does not emit the following
turn/start; instead it continues the same turn number with step=24.

Hypothesis

Both defects look like writer-side races around session/end-seed:

• Defect 1 (chunk provenance): the writer's source window for one assistant/message
  swept in the session/end-seed marker as if it were a chunk.
• Defect 2: the pre-interruption teardown emitted turn/end + session/end-seed, then the
  post-interruption resume continued emitting into the same turn without re-opening it,
  and the step boundaries straddling the cut were dropped.

In all three cases the anomaly is anchored on a seed boundary, which is why only this
session (and only these two spots in 170k records) is affected.

Question

Is a mid-turn session/end-seed + turn/end → same-turn continuation a known writer
state, or does it indicate something else (e.g. a resume path that replays the tail of the
previous turn)? Knowing which lets me decide whether the local repair should merge
turn 450 into one turn (move the premature turn/end/seed after step 59) or split it
(treat steps 24–59 as a new turn and renumber the remaining 11 turns). Both are local
rewrites; the second also has to renumber ~65k record seqs, so I'd rather pick the one
that matches writer intent.

Also glad to hear if there is a supported "repair" entry point I should be using instead of
hand-editing the container.

[xiaoshenming]

补一组发布包上的实测，回答你两个问题；其中一处和你的描述不同。

1) 是哪一道在拒、哪条规则

• v0→v1 的 stage 自己不校验关系：我把你这段形状（turn/end 之后同回合继续）喂给 createSessionFormatV0ToV1(...).createStage(...)，通过。
• 拒读发生在 v1→v2：它对转换后的工件重跑 v0→v1 的 assertReleasedArtifactRelationships（mode === "current"）。这也解释了报错为什么落在 assistant/message：RELEASED_V2_EVENT_TYPES 里没有 assistant/chunk（v0 有，51 条里是 assistant/attempt + assistant/message），v1→v2 把分块折进消息/attempt，所以转换后第一个被 requireOpenStep 检查的 step 事件就是那条消息。
• 外层 Session migration from v0 to v4 refuses the transformed artifact 由 @deepseek-ai/dsh-session-format 的 orchestrator 包出，和你日志一致。
• 0.1.7-rc.2 上的最小对照：健康序列通过；turn/end 之后再来一条 assistant/message → restoreReleasedV2Artifact 报 assistant/message does not match an open turn and step（你的原话）。

2) 一处修正：你的 Defect A 并不是「turn/end 落在 step 未关时」

你自己贴的日志里 step 23 是先干净关闭的（4059827 step/end → 4059828 turn/end），所以 turn/end 450 crosses an open step（写者侧 dsh-session/lib/invariant.js:37 是同一条规则）没有触发；真正拒读的是后面那些 step 事件没有 open turn/step。这个区别有实际意义 —— 两种形状官方报的是不同的话、修法也不同，我把它们做成了两个独立健康码。

3) 算不算「已知的 writer 状态」

从工件本身推不出写者意图，我不编这个结论。可以说的是：43 条 session/end-seed 里只有 turn 450 这次没有跟 turn/start(451)，而是用 step=24 继续同一个回合号 —— 形态与「中断前 teardown 已落盘、恢复方仍在内存里继续写同一回合」的竞态一致（#1586 家族）。我们已有的 live-writer-tail 规则处理的是同一 seq 重叠那种；你这里是更高 seq 继续（无重叠），所以它不触发 —— 这也正是它没有唯一答案的原因。

4) 合并还是拆分

两边都不选。合并 / 拆成两个回合都是局部改写，工件里没有唯一答案；拆分还要重编号后面约 65k 条 seq 与所有声明范围，跨过我们「绝不发明」的线。所以只报告这个形状（含命中 seq），repair 对它是 no-op。你手改是另一回事；动 17 万条的容器前整目录留一份副本，这个直觉是对的。

第一处缺陷我们已经能修：v0-chunk-provenance 的判据是「声明 == 同一尝试边界以来磁盘上完整有序的一段」，只把声明改写成磁盘上已经存在的 seq，不新增、不删除。

刚推了 2ef75ff：inspect 现在会报 step-after-turn-end（带命中 seq），只报不修。

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

停写者 → inspect（默认只读）→ repair（默认 dry-run）→ --apply（先写 .bak.<utc>）。以上结论全部跑在同形状的构造样本上，不是你的文件。

[kittimzhe]

Verified all three of your corrections against the installed 0.1.7-rc.2 packages — right on each, and the correction sharpens the family picture:

1. The v0→v1 stage does not validate relationships. sessionFormatV0ToV1 never calls assertReleasedArtifactRelationships — it is a payload gate only. My earlier "turn/end crosses an open step" framing was the writer-side invariant (dsh-session/lib/invariant.js:37), not the rejection site; as you showed, step 23 closed cleanly at 4059827/4059828 and the actual refusal is the later steps finding no open turn/step. Two shapes, two messages, two repairs — the two health codes are the right decomposition, and I've stopped conflating them.
2. The rejection is v1→v2 re-running the relationship gate on the transformed artifact. dsh-session-format-v1-to-v2 imports assertReleasedArtifactRelationships from v0-to-v1 and calls it at mode === "current" with RELEASED_V2_RELATIONSHIP_EXTENSIONS — which is why the orchestrator's "v0 to v4 refuses the transformed artifact" wrapper matches the log.
3. The error landing on assistant/message follows from the fold. The v2 retained map filters out assistant/chunk and assistant/message (chunks embed into attempt events), so the first step-scoped event the relationship gate can trip on is the message — consistent with the minimal repro on 0.1.7-rc.2.

On "report, don't repair": agreed, for the same reason you give — the artifact carries no unique answer (merge and split are both local rewrites; renumbering ~65k seqs plus every declared range crosses the invent-nothing line). The only defensible output for this shape is a report: the offending seqs, the rule that refused, and the boundary that produced it.

One more data point for the maintainers, from the same per-stage-gate family: #7995 (filed yesterday) is the descriptor-version arm of the same pattern — the v0→v1 payload gate rejects subagent/descriptor version 2, the only version the writer has ever emitted on this machine (27/27 sessions, including ones written the same day by 0.1.5-rc.3), and one failing artifact currently fails every session-search query rather than being quarantined. Both arms point at the same direction: a per-artifact report mode — name the offending shape, continue with the rest of the store — would turn both of these from hard bricks into diagnostics.

[xiaoshenming]

收到，三点都对得上我们这边的实测：v2 保留映射里没有 assistant/chunk（RELEASED_V2_EVENT_TYPES 51 条里是 assistant/attempt + assistant/message），所以关系闸门能碰到的第一个 step 事件就是那条消息 —— 你这句补充我们量到的是同一个结论。

关于「per-artifact report mode」：上游怎么改不是我们能决定的，但离线版今天就能用 —— 对整库跑一遍 index（只读）会逐条列出每个会话的健康码，等于在 observer 撞上之前先把「哪些工件会被哪条规则拒」列出来；inspect <id> 给出具体 seq 与规则名。这也是我们给 #7995 那个 descriptor 分支的同一套答复。

顺带把 #7995 接上：那个分支（subagent/descriptor version 2）我们已经能修，不是只报告。同一条 v0→v1 payload 闸门，构造样本实测：

before: SessionFormatUnsupportedMigrationError: subagent/descriptor 0 uses unsupported descriptor version 2
after : accepted        # 只把 data.version 2→3，其余成员不动

并且这条闸门在 0.1.5-rc.3 与 0.1.7-rc.2 的发布包里逐行一致（lib/index.js:1290 的 literalValue(data["version"], [3])、:1584 的 !== 3、:1586 抛错），所以它确实不是 0.1.5 才出现的回归。