#2026: Decide intent + migration for legacy fork classification (session_source="fork")

Context

Follow-up from Release M (v0.51.37, PR #2020 — Opus advisor pre-release review).

PR #2014 added a session_source="fork" marker on session objects so downstream features can exclude forked sessions from certain views/counts/exports. Sessions created before #2014 shipped do not carry this marker, so they're indistinguishable from non-forks at query time.

The question

Was the intent of #2014 to exclude all forks (including legacy ones), or only forks created after the marker existed?

• If "all forks": we need a one-shot migration that walks every session JSON, detects fork lineage from existing fields (presumably forked_from_id or similar), and writes session_source="fork" retroactively.
• If "only post-#2014 forks": close this issue, document the cutoff in CHANGELOG.

Suggested fix (if migration is wanted)

One-time script in scripts/migrate_legacy_fork_marker.py:

# pseudocode
for session_json in glob(state_dir / "sessions/*.json"):
    s = load(session_json)
    if s.get("session_source"):
        continue  # already marked
    if s.get("forked_from_id") or s.get("fork_origin"):
        s["session_source"] = "fork"
        save(session_json, s)

Run idempotently. Add a regression test that:

1. Creates a legacy-shape session JSON without session_source but with forked_from_id
2. Runs the migration
3. Asserts session_source == "fork" after

Wire into start.sh as a one-shot guarded by a sentinel file (so it runs once per install, not every boot).

Risk

Medium if migration writes session JSONs in place — needs backup-then-rewrite pattern, atomic rename, and a recovery path. Low if we just add the marker on-read in a hot path instead (compute-on-read, never persist).

Refs

• PR #2014 (introduced session_source="fork")
• PR #2020 / v0.51.37 (Release M stage where Opus flagged it)