Function fresh_start_needs_disclosure 

fn fresh_start_needs_disclosure(
    attempted_resume_sid: Option<&str>,
    generation: u64,
) -> bool

Should a spawn that attached NO --resume disclose itself as a fresh start (subject to the caller also confirming prior history actually exists — see has_prior_transcript)?

SPEC_AGENT_PANE_HISTORY_ALIGNMENT_2026_08_05.md §2.1 deliberately left this case unreported, reasoning that a spawn with no session id has “nothing to lose”. That’s true for a brand-new agent and false for the case docs/status/STATUS_CROSS_CHANNEL_RESUME_STALE_SESSION_ID_2026_08_20.md recorded: a long-lived named agent opened in a fresh channel whose shared registry pointer is empty gets no --resume at all, so the CLI never errors, persistent_resume never tracks anything, and no outcome is ever emitted — while the pane renders the entire prior conversation through blockfile.rs’s cross-channel read fallback. That is exactly the silent disagreement between “what the pane shows” and “what the model has” that EmitSessionOutcome exists to prevent.

generation == 1 restricts this to a controller’s FIRST spawn. Later generations also spawn without --resume, but each already has its own disclosure or deliberately has none: retry_after_resume_failure’s no-recovery-candidate path emits Fresh itself, and respawn_once_for_leftover_queue restarts a session whose fresh-vs-resumed status was decided on an earlier generation. Only a first spawn can be the “pane just opened onto history this process never had” case.

Kept a pure free function (the FileStore lookup stays at the call site) so the gate is unit-testable without a controller or a spawned process.