Expand description
Backfill db_agent_native_memory_versions with one source: "agent_inferred" version per existing db_agent_native_memory row —
reagent P1 (re-review of PR #2674): the spec this migration completes
(docs/specs/SPEC_MEMORY_VERSION_CONTROL_AND_ARMORY_AUDIT_2026_08_19.md
§9 Rollout) explicitly calls for this backfill so history views aren’t
empty for pre-existing memory on upgrade. Without it, an existing
user’s first post-upgrade overwrite of a memory file records only the
NEW content as version 1 — the prior live content (everything that
file held before this feature shipped) is permanently unrecoverable
via MemoryRevert/MemoryDiff.
Global scope: db_agent_native_memory (source) and
db_agent_native_memory_versions (destination) both live in the
shared store (ctx.shared_store_path) — the same store id_store
resolves to at runtime, and the only one every native-memory RPC
handler actually reads/writes. The per-channel objects.db copies of
both tables exist only as id_store’s own pre-0011_shared_store_backfill
fallback (see each table’s own CREATE TABLE doc comment in
migrations.rs) — on any install that has already passed that
migration (a precondition of this one even existing, since v6/v8 of
the shared schema postdate it), they’re not the live data path, so
this migration doesn’t scan them.
Idempotent: only backfills a (agent_id, filename) pair that has NO
existing version yet. This matters for correctness, not just
re-run-safety — a pair that already has one or more versions (a normal
write happened after this feature shipped but before this migration
ran) must NOT get a backfilled version inserted now, because it would
land at the END of that pair’s chain (this migration runs after normal
startup writes are already possible) with content that’s actually
OLDER than what’s already recorded, corrupting the chain’s chronology.