Best possible solution:

Land this compatibility slice only after the session/transcript migration owner confirms the deprecation window and accessor-backed write semantics match the SQLite flip sequence.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a refactor/compatibility PR, not a bug report with a failing reproduction path. The PR body includes live Gateway proof, and the diff adds focused regression tests for the compatibility helpers.

Is this the best way to solve the issue?

Yes, with maintainer sequencing review: routing through the existing accessor seam is the narrow owner-boundary fix, and keeping the SQLite flip, doctor migration, and transcript identity APIs out of this PR avoids the monolithic migration failure mode tracked in the canonical issue.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 2a0e63d12bde.

Label justifications:

• P2: This is a bounded SDK/runtime migration slice with compatibility-sensitive plugin and session-state impact.
• merge-risk: 🚨 compatibility: The PR changes public plugin SDK and injected runtime session helpers that existing plugins may call during upgrades.
• merge-risk: 🚨 session-state: The PR changes persisted session entry write paths during the broader session/transcript storage migration.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes after-fix live Gateway proof with health checks, an agent run, persisted session-row inspection, and a plugin debug entry written through the changed runtime session wrapper.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live Gateway proof with health checks, an agent run, persisted session-row inspection, and a plugin debug entry written through the changed runtime session wrapper.

PR surface:

Source +314, Tests +273, Docs +2, Generated 0. Total +589 across 11 files.

What I checked:

• Repository policy applied: Root plus scoped plugin SDK, plugin runtime, and docs AGENTS.md files were read; the applicable guidance treats plugin SDK and session-state migration surfaces as compatibility-sensitive and protected-label items as maintainer-handled. (AGENTS.md:20, 2a0e63d12bde)
• Live PR state: Live GitHub metadata shows the PR is open, contributor-authored, not draft, mergeable but unstable, and labeled maintainer, proof: sufficient, merge-risk: 🚨 compatibility, and merge-risk: 🚨 session-state; that blocks cleanup close and routes the remaining decision to maintainers. (16d684fd16d6)
• Current main still has the older SDK facade shape: Current main directly re-exports SDK read helpers from session-accessor.js and mutation helpers from store.js, so the PR is not already implemented on main. (src/plugin-sdk/session-store-runtime.ts:3, 2a0e63d12bde)
• PR head routes SDK wrappers through the seam: The PR head defines object-parameter SDK wrappers for get/list/read/patch/update/upsert and forwards them through the session accessor seam while keeping deprecated compatibility exports grouped. (src/plugin-sdk/session-store-runtime.ts:63, 16d684fd16d6)
• PR head mirrors runtime facade wrappers: The injected plugin runtime facade uses the same accessor-backed wrapper pattern and continues exposing the existing runtime.agent.session helper names. (src/plugins/runtime/runtime-agent.ts:88, 16d684fd16d6)
• Write-confirmation option is threaded through the accessor: The PR adds requireWriteSuccess to the accessor update options and forwards it into the file-backed update entry path, preserving fail-closed behavior for critical compatibility writes. (src/config/sessions/session-accessor.ts:272, 16d684fd16d6)

Likely related people:

• jalehman: Authored this PR, the canonical migration tracker, the merged accessor-seam predecessor, and recent session-accessor migration commits on current main. (role: migration stack author / recent area contributor; confidence: high; commits: 16d684fd16d6, ef47dd610c87, 49e6f5a524bc; files: src/config/sessions/session-accessor.ts, src/plugin-sdk/session-store-runtime.ts, src/plugins/runtime/runtime-agent.ts)
• Vincent Koc: Current checkout blame/log attributes the existing SDK/runtime facade files and nearby accessor option lines to a broad current-main refactor commit, though that appears less specific than the migration tracker history. (role: current-main line provenance; confidence: low; commits: 033162f20933; files: src/plugin-sdk/session-store-runtime.ts, src/plugins/runtime/runtime-agent.ts, src/config/sessions/session-accessor.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.