Problem

Two bugs Pedro reported on desktop v0.3.0, both in "Continue with another agent" / "Fork from here" (spec .compozy/tasks/session-continue-fork/, shipped in #684).

Bug 1: the chosen runtime/model was not applied to the continued session.
Repro: create a session on Codex GPT-6.1-Sol and send "oi". Open the session menu → Continue with another agent. Leave Agent = general, pick Runtime → Fable 5 (Claude Code), set Open in = This window, and click Continue. The new session opens ("Continued from Saudação inicial ao Pedro", "Nothing said here yet"), but the composer model selector shows GPT-6.1-Sol. Sending a message would bind Codex, not Claude.

Bug 2: continued and forked sessions rendered nested under their source.
The sidebar showed the source row with "⌄ 1" and the new session indented under it. Product rule: sessions spawned by an agent (sub-agents, orchestration children) are children and may nest. Sessions the user creates with Continue or Fork are new top-level sessions. Their lineage ("Continued from X" / "Forked from X") is provenance metadata (pill, divider, inspector), not hierarchy.

Root cause

Bug 1: the composer never sees the chosen runtime

• The dialog sends the runtime correctly (web/src/systems/session/hooks/use-session-continue-dialog.ts runtimeRequest), and the handler passes it through (internal/api/core/session_derive.go deriveRuntimeFromPayload).
• The derive applies it only as create-time fields (Provider/Model/... in applyDeriveRuntime, internal/session/derive_prepare.go). It never sets the session's SelectedRuntime, the durable runtime intent.
• A derived child is a logical session created through CreateAccepted, so it stays unbound until the first prompt (internal/session/manager_create_accepted.go). While unbound, the API leaves out runtime.effective (runtimeHasEffectiveSelection in internal/api/core/conversions.go: Unbound with TransitionNone → no effective runtime), and runtime.selected is nil.
• The composer seeds from selected and falls back to effective, then to the agent's default runtime (promptRuntimeDefaults → resolveAgentRuntimeValue(agent) in web/src/systems/session/hooks/use-session-prompt-runtime.ts). So it showed Codex, and its first prompt sent Codex as an explicit runtime snapshot, overriding the create-time fields.
• The same class of bug hit route continues: the composer sent the agent default, which then failed pendingRouteMatchesSelection and silently dropped the pending route. It also hit forks whose source ran on a runtime other than the agent default: the child is locked to the source runtime by forkRuntimeFromMeta, but its composer showed the agent default.

Bug 2: hierarchy consumers ignored the typed lineage edge

• feat: continue and fork sessions across agents, with fallback account routes #684 already gave every lineage a typed kind ("", provenance, recovery, spawn, continue, fork). It is stored as a catalog column and in meta.json, with a lossless backfill (internal/store/session_lineage.go). The store already separates the two meanings.
• Consumers that build hierarchy still treated every parent_session_id as a parent:
  • Web tree: buildSessionTree (web/src/systems/session/lib/session-hierarchy.ts) nested any session whose lineage.parent_session_id was loaded. The spec had decided "nesting unchanged" (_uiux.md S10), and Pedro's new rule overrides that.
  • Supervision: sessionWorkSources.children (internal/daemon/session_work_sources.go) counted every row with parent=<id> as an active_child work signal, and that signal defers inactivity stops. A continued child (an accepted logical session is active) kept its source session alive.
  • Goal authorization: authorizeGoalDescendant (internal/daemon/loop_goal_command.go) walked parent_session_id, so the source session's agent could command Goals on a session the user had continued from it.

Fix

Session runtime (Go, internal/session)

• applyDeriveRuntime marks the create opts with deriveSelectsRuntime whenever an explicit runtime, a declared route, or the fork source runtime applies. A speed left unset takes the target agent's default speed, as the bind would resolve it.
• prepareCreateStart turns those (post-hook) runtime fields into the child's SelectedRuntime at revision 1 (deriveSelectedRuntime, manager_create_prepare.go). This goes through the existing start-spec → Session → meta.json / catalog path, so the existing payload mapper exposes it as runtime.selected. A runtime without a provider (a model or speed alone) still refines the agent default at bind and records no selection.
• Result: the unbound child's composer shows the chosen runtime, and a prompt without its own runtime binds it (normalizePromptRuntimeSelection already prefers SelectedRuntime). A routed child's selection matches its pending route, so the route is no longer dropped by the composer's default.

Hierarchy vs provenance (Go + web)

• store.HierarchyParentSessionID(lineage) (internal/store/session_lineage.go) is the single rule: it returns the parent for root/provenance/recovery/spawn edges and "" for continue/fork.
• internal/daemon/session_work_sources.go: a continued or forked session is not active-child work, so it never defers the source's inactivity stop.
• internal/daemon/loop_goal_command.go: Goal descendant authorization walks hierarchy parents only.
• web/src/systems/session/lib/session-hierarchy.ts: sessionTreeParentId reuses sessionOriginKind (the same predicate as the origin pill), so continue/fork rows are roots in every list built on the shared tree (window sidebar, sessions modal, agent detail, the cycle shortcut order, and thread filtering). Spawned, provenance, and recovery children keep nesting, including sub-agents a continued session spawns, which nest under it.
• Provenance is untouched: lineage.parent_session_id still names the source for the origin pill/divider, the inspector, compozy session status Origin, and the CLI PARENT column.

Reference research

• t3code (docs/orchestration-v2/core-graph-and-data-model.md, packages/client-runtime/src/state/threadRelationships.ts, apps/web/src/components/Sidebar.logic.ts): uses one lineage record { parentThreadId, relationshipToParent: "fork" | "subagent", rootThreadId } plus forkedFrom. Forks keep parentThreadId = source, and the sidebar decides by relationship kind. Forks render as ordinary top-level threads, and subagents are handled separately (isSidebarSubagentThread). Adopted: one parent pointer plus a typed relationship, with the UI and daemon deciding hierarchy by kind. Compozy already persists this shape as lineage.kind.
• synara (packages/contracts/src/orchestration.ts, apps/server/src/orchestration/decider.ts): uses separate fields, with parentThreadId for subagents, forkSourceThreadId for forks (created with parentThreadId: null), and handoff.sourceThreadId for provider handoffs. Its sidebar nests by parentThreadId only. Same product rule (forks/handoffs are top-level). I did not adopt the field split, because Compozy can express the rule with the existing typed kind without a migration or a DTO break.
• monocode (src/features/sessions/model/session.ts): handoff is an in-session harness switch (HandoffMeta), and subagents are mirrored as blocks inside the parent transcript. There is no fork-as-child nesting, so it agrees with the rule but has no data-model equivalent.

Compatibility notes (SD-013)

• User state: no SQLite or meta.json shape change, so no migration. Existing continue/fork rows already carry lineage_kind (continue/fork), written by feat: continue and fork sessions across agents, with fallback account routes #684 and backfilled for older rows, so they become top-level immediately and losslessly. Existing unbound derived children made before this fix have no selected runtime. They keep today's behavior (agent default until the user picks a model). New derives get the selection.
• Public surfaces: no wire shape change. runtime.selected / selection_revision are existing fields that are now populated for derived children. lineage.parent_session_id keeps naming the source. The parent= / root= catalog filters (CLI --parent/--root, compozy__session_list) still match stored fields as-is, so they include continued/forked sessions. The docs say to read lineage.kind to tell them apart. No OpenAPI or codegen change, and codegen-check passed locally.
• Internal: CreateOpts.deriveSelectsRuntime is unexported and set only by the derive path.

Tests added/changed

Each new Go regression fails without the production change: I checked this by temporarily reverting each fix.

Focused checks run

• go test ./internal/session/ ./internal/store/: 1651 passed. 4 failures (TestManagerSpawnHooksCarryLineageAndCannotWidenPermissions, TestSpawnGovernanceUsesOnlyContiguousSpawnedLineage) were Stop(...) context deadline exceeded while the daemon suite ran concurrently on the same machine. They pass 3/3 with -count=3 alone and don't touch the derive path.
• go test ./internal/daemon/ ./internal/api/core/: 4015 passed.
• go test ./skills/: 33 passed.
• golangci-lint run ./internal/session/ ./internal/store/ ./internal/daemon/: clean.
• vitest run src/systems/session/lib src/systems/session/components/session-list …: 36 files / 278 tests passed. use-session-prompt-runtime.test.tsx: 6 passed.
• turbo run typecheck lint --filter=compozy-web: passed (including codegen-check).

Left to CI

make gate / full Go race lanes, full Vitest, Playwright E2E (session-derive.spec.ts), and Storybook. Per the controller's instructions I did not run these locally.

QA scenarios touched

• ET-web-session-continue: new steps 10 (runtime) and 11 (top-level row), fix note, reset to untested.
• ET-web-session-fork-from-here: fix note and walk, reset to untested.
• ET-web-session-sidebar-threads, ET-web-sessions-catalog-modal: qa-impact flags (continue/fork no longer nest).
• Cross-surface impact entry: docs/_memory/change-impact.md (2026-10-06). Docs: packages/site/content/docs/sessions/lifecycle.mdx. Official skill: skills/compozy/references/runtime-operations.md.

Risks / follow-ups

• Recovery children ("Restart in a new session") are user-created too, but this PR keeps them nested, because the request named only Continue/Fork. Making them top-level is a one-line change in the predicate if wanted.
• root_session_id / spawn_depth of a derived child still point at the source's tree, and spawned sessions under a continued child inherit that root. This only affects observability grouping and root= filters. Re-rooting would mean a data migration plus a filter-semantics change, so I left it out of scope.
• Derived children created before this fix (unbound, no message yet) still show the agent default until the user picks a model.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Continued and forked sessions now appear as top-level sessions rather than children of their source. Spawned sessions remain nested under their parent.
  • Goal commands and active-child work signals now follow the correct session hierarchy.
  • Unbound sessions retain their selected runtime and use it ahead of agent defaults, including after resuming.