v0→v3 session migration refuses legacy plugin-injected message sources (history fails to load after host upgrade)

[SeaOf0]

Environment: dsh web 0.1.5-rc.2 (Node 22), macOS. Sessions written by older hosts (v0 artifacts, up to ~0.1.2 era) with third-party community plugins installed (at-file, mnemon, a custom attack-atlas build, a results panel plugin).

Symptom: opening history fails with

failed to observe session "...": cannot safely transform unclassified message source; source v0 artifact remains unchanged

and, for other sessions, sibling errors from the same migration chain.

Root cause: the v0→v3 migration chain in @deepseek-ai/dsh-session-persistence-jsonl refuses (correctly refusing to touch data) historical events written by plugin agent/inbox injections that older hosts accepted. Across 331 local v0 sessions I hit five distinct refusals:

1. source summary requires notice form — plugin message source {kind:"plugin", form:"instructions", summary:"..."} (summary requires form:"notice").
2. cannot safely transform unclassified message source — source kinds outside the v3 SOURCE_KINDS whitelist (e.g. at-file-mention).
3. subagent/descriptor N uses unsupported descriptor version 2 — descriptors with version:2 whose fields are otherwise v3-compatible.
4. agent/inbox/spliced ... inserted message lacks required member "role" — spliced injected messages missing role.
5. inserted message content must be an array — spliced content written as a bare string.

Ask: consider making the v0→v3 migration chain safely degrade these legacy plugin-injection shapes instead of refusing (e.g. normalize unknown source kinds to plugin, drop summary when form≠notice, accept descriptor v2 fields as v3, backfill role:"user" and wrap string content). Right now a host upgrade silently bricks history loading for any workspace that used community plugins, and the only recovery is hand-editing zstd session artifacts.

Workaround applied locally: I rewrote the offending fields in-place across all sessions (full backup kept, per-file trash, then re-verified every artifact through JsonlSessionPersistence.open()+read() — 331/331 now migrate). Happy to share the normalization script if useful.

[PerryLink]

I checked all five against the source. They hold — and there is one detail that matters for the fix: they do not live at the same stage.

your class	thrown at	edge
1 ... summary requires notice form	session-format-v0-to-v1/src/payload-validation.ts:654	v0→v1
2 cannot safely transform unclassified message source	session-format-v2-to-v3/src/payload.ts:113	v2→v3
3 ... uses unsupported descriptor version N	session-format-v0-to-v1/src/validation.ts:202	v0→v1
4 ... inserted message lacks required member "role"	label built at session-format-v0-to-v1/src/payload-validation.ts:28, thrown at .../validation-helpers.ts:32	v0→v1
5 ... must be an array (content written as a bare string)	session-format-v0-to-v1/src/payload-validation.ts:365	v0→v1

Four of the five sit on the v0→v1 edge. So the normalization you propose — unknown source kind → plugin, drop summary when form ≠ notice, accept descriptor v2, backfill role:"user", wrap string content — is mostly a v0→v1 change. Only class 2 needs the v2→v3 stage. Treating it as "the v0→v3 chain" would put most of the work in the wrong layer.

Upstream status: none of these have changed on master (c291e7961a, 2026-09-10), and the newest tag is still dsh-v0.1.5-rc.2.

One policy note that may help your Ask land: the refusal is deliberate rather than incidental. .agents/notes/implemented/architecture/2026-08-31-alpha-historical-unknown-event-refusal.md:25 states it outright:

Community feedback will determine the next policy. A later release may add an explicit external-owner migration interface, permit omission of explicitly ignorable historical events while retaining the exact source generation, or keep strict refusal. No option is implied by the alpha marker.

Your Ask is exactly the input that line is inviting. Naming which of those three options you would pick would probably carry further than the mechanism alone.

[ERICLI228]

Data point (2026-09-15): on the same install described in #6045, 104 of 393 sessions fail with user/message … source summary requires notice form. The writer is the third-party plugin dsh-mnemon 0.2.14, which calls createPluginMessage(reminder, "instructions", "…").

payload-validation.ts is byte-identical in dsh-v0.1.6-alpha.1 and master. A plugin update would only fix future writes; sessions already on disk still need the migration to accept or normalize this legacy shape.