What migration loses: a per-field account of the metadata

When to use

The conversations came over and they read and search fine, but questions like which workspace and which parent session a run belonged to are no longer answerable.

Preparation

Host version

To fill (record the exact rc version when testing)

Model

To fill

Mode / permissions

Standard mode + modify-within-workspace is enough to start

Plugins required

None (add name & version after testing if used)

Input materials

Keep in a separate workspace; back up originals first

Full instruction

I want to migrate old conversations into DSH and need to know what gets lost. First list the fields in DSH's session header, then judge each one's fate.

[Step 1: session-level fields]
From the first line of the session file and adjacent metadata events, list every field you can confirm. For each: field name | meaning | example | basis.

[Step 2: per-field fate]
Build a table: field | preserved on migration | if not, why | suggested handling. All four columns filled, none blank.

Definitions:
- 'Preserved' means written straight into the same field on the new session
- 'Needs conversion' means preserved but recomputed (different timestamp format, a path re-escaped)
- 'Inevitably lost' means the target format has no corresponding concept

[Step 3: consequences]
For each inevitably-lost field, write one sentence on which concrete capability breaks (for example 'losing the parent link means you cannot jump from a child session back to its parent'). No 'may affect some functionality'.

[Hard constraints]
1. Every field cites a basis. Mark inferences and say why you inferred them.
2. Do not write 'metadata is mostly preserved'. If the target format has no such concept, say lost.
3. Do not suggest 'write a conversion script' without stating the conversion rule. The rule is the answer.

Close with one line: whether this migration is worth doing depends on which field you care about most.

Copy full instruction

Run log

Output

After a successful run, list files and screenshots here, and note whether originals changed.

Acceptance checklist

Tap to tick each item off as you verify.

• All session-header fields listed, each with a basis
• No empty cells in the four-column table
• Preserved, conversion, and loss are judged separately
• Every loss names a concrete capability that breaks
• Closes with an actionable 'depends which field matters to you', not a vague warning

Failures & boundaries

• Measured: the session header fields are type, version, id, createdAt, cwd, parentSession, origin, delegationDepth, agentPreset. parentSession and delegationDepth encode the parent-child relation and delegation chain, origin records provenance (subagent in the sample), and agentPreset records which preset ran (standard).
• Measured: every event line carries seq and time — an in-session sequence number and a millisecond timestamp. Other tools often have no such concept, so migration means either renumbering seq or leaving it empty, and empty breaks features that address events by seq.
• The easiest losses to overlook are delegationDepth and parentSession: another tool's conversations are usually a flat message list with no notion of a child session. What you get after migrating is standalone sessions, not the original tree.
• The value here is turning 'what do I lose' from a vague worry into an itemised list. Whether the migration is worth it depends on whether you care about content or structure.
• Blocked on: Same: the DSH session header is measured (type, version, id, createdAt, cwd, parentSession, origin, delegationDepth, agentPreset, with seq and time per event line). The other side's field list is what is missing for a per-field comparison.

Claim this recipe Back to recipes