fix(memory): terminal-state precedence in m[1] mutation-log fold (#12); accept archive non-revival (#13)

#12 — getMemoryMutationsForRender coalesced newest-id-per-target with no terminal
precedence, so archive-then-update on a rendered memory emitted <updated> in the
m[1] <memory-updates> delta even though the memory left the active set (an
archived row won't reappear in the next m[0] baseline → the agent is told a gone
memory is present/changed). Fix: a terminal mutation (archive/delete/superseded)
now outranks a later non-terminal update for the same target, regardless of id
order; same-terminality still resolves newest-id-wins. Safe because un-archive
(restore) happens via an epoch-bump full re-materialize that advances the cursor
past the archive row — there is no un-archive signal inside the log. Shared core
fn, so OpenCode + Pi both get it (Pi imports getMemoryMutationsForRender from
core). +3 fold tests (archive>update, update-then-delete, multi-update).

#13 — ACCEPTED as designed (not a fix): archiving is a deliberate dreamer/user
suppression, so re-observing a fact must NOT silently revive it. getMemoryByHash
matches the archived row, bumps seen_count (recurrence recorded), does not
re-insert/un-archive; revival is restore-only (epoch bump). Characterization test
relabeled from 'CURRENT BEHAVIOR' to a locked contract.

plugin 1706/0, Pi 403/0, tsc + biome clean, both dists rebuilt.

Author: ualtinok

packages/plugin/src/features/magic-context/memory/promotion.test.ts

@@ -365,13 +365,14 @@ describe("promotion", () => {
         });
     });
 
-    // Audit finding #13: getMemoryByHash does NOT filter by status, so a
-    // re-observed fact whose prior instance was archived matches the archived
-    // row, bumps its seen_count, and is NOT revived (stays archived/invisible).
-    // This characterization test documents the CURRENT behavior so we can decide
-    // whether revival-on-re-observation is wanted before changing it.
+    // ACCEPTED BEHAVIOR (audit decision): archiving a memory is a deliberate
+    // dreamer/user suppression, so re-observing the same fact must NOT silently
+    // revive it. getMemoryByHash matches the archived row by (project,category,
+    // hash), bumps its seen_count (recurrence is still recorded), and does not
+    // re-insert or un-archive. Revival happens only through an explicit restore
+    // (which bumps the project epoch). This test locks that contract.
     describe("#given a previously-archived fact is re-observed", () => {
-        it("CURRENT BEHAVIOR: dedupe matches the archived row and does not revive it", () => {
+        it("dedupe matches the archived row and does NOT revive it (archive is deliberate)", () => {
             db = makeMemoryDatabase();
             const content = "Use SQLite for cross-session memory";
             const hash = computeNormalizedHash(content);

packages/plugin/src/features/magic-context/storage-memory-mutation-log.test.ts

@@ -113,23 +113,20 @@ describe("storage-memory-mutation-log", () => {
         expect(getMemoryMutationsForRender(database, "/repo/a", 0, [])).toEqual([]);
     });
 
-    // Audit finding #12: render coalescing is "newest mutation-log id per target",
-    // with no terminal-state precedence. If a memory rendered in m[0] is archived
-    // and then later updated (update does NOT gate on status), the update row has
-    // the higher id and WINS — the m[1] <memory-updates> delta shows the memory as
-    // present/updated even though the canonical table state is archived. This
-    // characterization test documents the CURRENT behavior so we can decide
-    // whether archive/delete should take precedence over a later update before
-    // changing it.
-    test("CURRENT BEHAVIOR: a later update outranks an earlier archive (no terminal precedence)", () => {
+    // A terminal mutation (archive/delete/superseded) takes precedence over a
+    // later non-terminal `update` for the same target, regardless of id order.
+    // Without this, archive-then-update would render the memory as
+    // present/updated in the m[1] <memory-updates> delta even though it left the
+    // active set (an archived row won't reappear in the next m[0] baseline).
+    test("a terminal archive outranks a later update for the same target", () => {
         const database = makeDb();
-        queueMemoryMutation(database, {
+        const archive = queueMemoryMutation(database, {
             projectPath: "/repo/a",
             mutationType: "archive",
             targetMemoryId: 10,
             queuedAt: 100,
         });
-        const update = queueMemoryMutation(database, {
+        queueMemoryMutation(database, {
             projectPath: "/repo/a",
             mutationType: "update",
             targetMemoryId: 10,
@@ -138,11 +135,50 @@ describe("storage-memory-mutation-log", () => {
             queuedAt: 200,
         });
 
-        // Memory 10 was rendered in m[0] (active at materialization), then archived,
-        // then updated. Newest-by-id wins → the render shows the UPDATE, not the archive.
         const rows = getMemoryMutationsForRender(database, "/repo/a", 0, [10]);
         expect(rows).toHaveLength(1);
-        expect(rows[0]).toEqual(update);
-        expect(rows[0]?.mutationType).toBe("update"); // archive is masked
+        expect(rows[0]).toEqual(archive); // terminal wins; update is masked
+        expect(rows[0]?.mutationType).toBe("archive");
+    });
+
+    test("update-then-archive still resolves to the archive (newest terminal)", () => {
+        const database = makeDb();
+        queueMemoryMutation(database, {
+            projectPath: "/repo/a",
+            mutationType: "update",
+            targetMemoryId: 10,
+            newContent: "edited",
+            queuedAt: 100,
+        });
+        const archive = queueMemoryMutation(database, {
+            projectPath: "/repo/a",
+            mutationType: "delete",
+            targetMemoryId: 10,
+            queuedAt: 200,
+        });
+
+        const rows = getMemoryMutationsForRender(database, "/repo/a", 0, [10]);
+        expect(rows).toEqual([archive]);
+    });
+
+    test("multiple updates with no terminal → newest update wins", () => {
+        const database = makeDb();
+        queueMemoryMutation(database, {
+            projectPath: "/repo/a",
+            mutationType: "update",
+            targetMemoryId: 10,
+            newContent: "v1",
+            queuedAt: 100,
+        });
+        const newest = queueMemoryMutation(database, {
+            projectPath: "/repo/a",
+            mutationType: "update",
+            targetMemoryId: 10,
+            newContent: "v2",
+            queuedAt: 200,
+        });
+
+        const rows = getMemoryMutationsForRender(database, "/repo/a", 0, [10]);
+        expect(rows).toEqual([newest]);
     });
 });

packages/plugin/src/features/magic-context/storage-memory-mutation-log.ts

@@ -4,6 +4,18 @@ export type MemoryMutationType = "archive" | "delete" | "update" | "superseded";
 
 const MEMORY_MUTATION_TYPES = new Set<string>(["archive", "delete", "update", "superseded"]);
 
+// Terminal mutations mean the memory LEFT the active set (renders as
+// <removed>/<superseded>). `update` is non-terminal — the memory is still
+// present with new content (renders as <updated>). The render fold gives
+// terminal states precedence over a later `update` so an update queued after an
+// archive/delete cannot resurrect a memory that is gone (archive is deliberate;
+// un-archive happens via an epoch-bump full re-materialize, never via the log).
+const TERMINAL_MUTATION_TYPES = new Set<MemoryMutationType>(["archive", "delete", "superseded"]);
+
+function isTerminalMutation(row: MemoryMutationLogRow): boolean {
+    return TERMINAL_MUTATION_TYPES.has(row.mutationType);
+}
+
 export interface MemoryMutationLogRow {
     id: number;
     projectPath: string;
@@ -118,11 +130,30 @@ export function getMemoryMutationsForRender(
         )
         .all(projectPath, afterId ?? 0, ...uniqueIds) as MemoryMutationLogDbRow[];
 
-    const newestByTarget = new Map<number, MemoryMutationLogRow>();
-    for (const row of rows) {
-        newestByTarget.set(row.target_memory_id, toMemoryMutation(row));
+    // Coalesce to one row per target. Newest-id wins among same-terminality, BUT
+    // a terminal mutation (archive/delete/superseded) always outranks a
+    // non-terminal `update` regardless of id order — otherwise an update queued
+    // after an archive would render the memory as still-present/updated even
+    // though it left the active set (it won't appear in the next m[0] baseline).
+    const chosenByTarget = new Map<number, MemoryMutationLogRow>();
+    for (const dbRow of rows) {
+        const candidate = toMemoryMutation(dbRow);
+        const current = chosenByTarget.get(candidate.targetMemoryId);
+        if (!current) {
+            chosenByTarget.set(candidate.targetMemoryId, candidate);
+            continue;
+        }
+        const currentTerminal = isTerminalMutation(current);
+        const candidateTerminal = isTerminalMutation(candidate);
+        if (currentTerminal && !candidateTerminal) continue; // keep terminal over later update
+        if (!currentTerminal && candidateTerminal) {
+            chosenByTarget.set(candidate.targetMemoryId, candidate); // terminal supersedes update
+            continue;
+        }
+        // Same terminality → newest id wins (rows are ASC, so candidate is newer).
+        chosenByTarget.set(candidate.targetMemoryId, candidate);
     }
-    return [...newestByTarget.values()].sort((left, right) => left.id - right.id);
+    return [...chosenByTarget.values()].sort((left, right) => left.id - right.id);
 }
 
 export function getMaxMemoryMutationId(db: Database, projectPath: string): number | null {