Backend roadmap: extract native authoritative backend ports with a checked storage-coupling inventory #1587

Type: implementation slice of the accepted SDK-first/backend-neutral direction; precise API and adapter design remain proposals. Parent: #1399, not a reproduced runtime defect.

Outcome: shared SDK PM semantics run against an explicitly selected native backend. Packages implement storage primitives/capabilities rather than create/update/claim/restore business rules. Existing filesystem behavior remains the compatibility baseline, not a required emulation protocol.

Evidence: item store mixes fs, policy, history and extension orchestration; list query imports store enumeration, metadata caches/indexes, paths and settings; schema migration already separates a deterministic planning intent but execution uses filesystem/schema/store helpers. These are extraction seeds, not proof all coupling has been enumerated.

Work:

1. Produce a machine-checked inventory rooted in public SDK/CLI/MCP operations, including create/import, read/list/search, update/delete/restore, history/integrity/compaction, relationship/schema/settings/policy/author stores, claims/fencing, snapshots/transactions/recovery journals, extension artifacts and derived indexes. Classify each dependency as PM semantics, authoritative persistence, projection/cache, host configuration, or explicitly filesystem/Git domain behavior. Record direct and transitive dependencies and supported public entrypoints, not only node:fs grep matches.
2. Derive the smallest typed persistence ports from that inventory: stable workspace/item identity, revision/conditional commit, coherent enumeration, authoritative state plus audit acknowledgement, transactional/coordinator capabilities, schema/config and retention needs. Names are not prescribed. Keep pure normalization/validation/policy/relationships/query interpretation and hook orchestration upstream. Distinguish commit atomicity from multi-step compensation, and shared-store concurrency from independent-copy reconciliation.
3. Move filesystem mechanisms behind its native implementation incrementally. Maintain the old pmRoot client path as compatible selection. A backend-neutral call must not need a dummy .agents/pm tree. Keep actual local file/Git operations capability-gated rather than banning all filesystem use from every SDK module.
4. Extend the existing static SDK boundary gate, not a disconnected linter. Existing SDK-first rules already prohibit CLI/MCP private-core edges; the new boundary is within the backend-neutral semantic layer. Cover aliases, re-exports, type imports, dynamic imports and indirect helpers; declare approved native/host boundaries explicitly.

Acceptance:

• Every inventory operation has an owner, declared capability and conformance scenario or explicit unsupported outcome; unclassified new persistence dependencies fail CI.
• Existing create and update semantics—including their documented hook differences—remain covered. Stale revision or lost ownership refuses before a self-persisting adapter callback; successful acknowledged item/history state cannot diverge silently.
• Settings work extends SDK: no supported reader for an extension's own settings section, so packages re-read settings.json by path and lose their configuration on non-filesystem backends #1580; artifact work extends SDK: generic immutable content-addressed artifact store for extensions #1565. Existing graph adapters remain projections, not mistaken for authoritative stores.
• A negative-control import/re-export from the semantic layer into native fs implementation fails the boundary gate. Legitimate fs adapters/domain actions still pass.
• Packed public SDK plus CLI/MCP tests preserve author/schema/extensions, errors, budgets, complete pagination and references. Claims about compatibility are bound to tested revisions; no mandatory database/server/default switch.

Tradeoff: a short-lived inventory classification is necessary to extract safely, but it must not become a permanent growing bypass allowlist. Avoid forcing provider-specific isolation or durability into one lowest-common-denominator CRUD API.

Intake: Targeted all-status issue searches and canonical source records were rechecked on 2026-10-25. Reuse #1399 / pm-gh1399 as the parent; if a more specific canonical owner already covers this slice, attach it there rather than create a competing PM item. This report is static source evidence at df5bf4aa4db17b7743b4f6bfddb32098f2cbd521, not executed backend tests or a claim of a reproduced defect. No deadline, assignee, deployment or backend switch is implied.