Guard DeepSeek Harness native-session resume with a compatibility generation #6944

What problem are you trying to solve?

The current DeepSeek Harness profile adapter resumes a stored native session and skips the Open Design transcript when model, cwd, and the conversation cursor match. It cannot persist or compare the remaining compatibility dimensions required by the current DSH adapter contract:

• DSH executable identity and tested compatibility family;
• profile protocol and plugin compatibility generation; and
• behavior-affecting composition generation.

On pinned main 30fc648f6f615fde5b162cbee1177f94ea2dba6c, run construction resolves resume and transcript mode before spawn. The spawned profile's actual identity arrives later, but attachDshProfileSession() validates ready and immediately sends the already-built execute payload. Raw CLI/plugin versions gathered by detection are daemon-lifetime provenance, not a resume guard.

A production-source characterization created a real daemon SQLite row with matching model/cwd/cursor and passed a prospective changed composition generation to resolveAgentResumeContext(). Production has no persisted compatibility field and no resolver input for it, so it was ignored and isResuming remained true (expected false, received true). This proves a source-level spec-conformance gap; it is not a claim that a released build was observed failing during a credentialed DSH upgrade.

Hard resume rejection already uses the existing one-shot full-transcript reseed path. The remaining gap is proactive compatibility invalidation, especially when changed-but-loadable runtime/profile composition accepts the old session.

Describe the solution you'd like

Add an adapter-opt-in opaque native-session compatibility generation and persist it atomically with the native handle. For DSH, emit it in probe and ready, with the actual spawned ready value authoritative.

Preserve both full and incremental prompt candidates until ready. One shared decision should then control both native handle use and transcript mode:

• matching stored/spawned generation: resume with the old session id and incremental turn;
• missing legacy/active generation or upgrade/rollback mismatch: create a fresh session with full bootstrap/transcript context;
• non-opted-in adapters: preserve current behavior.

Acceptance should cover legacy one-time reseed, stale detection, profile replacement between detection and spawn, upgrade and rollback, validated-session cancellation persistence, existing missing/corrupt-target auto-reseed, sanitized diagnostics, and unchanged non-DSH adapters.

If application binary rollback is supported, a legacy writer must not be able to mutate a row while leaving a falsely trustworthy newer compatibility value.

Alternatives you've considered

1. Exact raw runtime fingerprint for every resumable adapter: simple but over-invalidates compatible raw version/path changes, forces fleet-wide legacy churn, and exposes the wrong abstraction.
2. DSH-only special case in generic session code: smaller immediate blast radius, but still requires ready-time prompt selection and repeats adapter-specific policy in shared persistence.
3. Expand Normalize cross-agent native-resume invalidation and fallback policy #5269 directly: not recommended without maintainer/contributor agreement. Its approved head owns a three-file shared prompt/failure-policy refactor, predates resumesSessionViaProfileStdio, currently conflicts with main, and does not cover DSH protocol/schema compatibility identity.

Additional context

• Alternative path: use native CLI resume/continue plus sessionMap instead of full transcript reinjection on every turn #744 remains the native-session umbrella/reconciliation tracker.
• Normalize cross-agent native-resume invalidation and fallback policy #5269 is the related shared-policy/rebase seam.
• No direct semantic duplicate issue/PR was found immediately before submission.
• Focused verification: 73/73 independent GREEN, 12/12 DSH runtime protocol GREEN, expected production characterization RED (isResuming remained true), and a broader 108-pass/1-skip focused batch.
• Real installed/credentialed DSH upgrade/downgrade and Windows/macOS profile replacement were not executed.
• I am willing to contribute a focused follow-up with maintainer guidance, but I am not claiming implementation ownership until maintainers decide whether this should follow Normalize cross-agent native-resume invalidation and fallback policy #5269 or be coordinated another way.

Would you be willing to contribute a PR?

Yes, with guidance from a maintainer.