Testing MemStack living memory projection into Cursor rules

I set up an isolated experiment to test whether MemStack's living memory can be projected into Cursor by writing the rendered block into .cursor/rules/*.mdc with alwaysApply: true in the frontmatter.

Isolation

Three things needed protecting. I cloned the repo from origin into a separate directory at commit 7bbe666, verified it has its own .git with no object sharing, and confirmed it landed clean. I copied the memory database, which holds 1,637 facts with 29 supersession links and 460 recall rows. Three writer processes were live at the time. I created an empty throwaway Cursor project with nothing but an empty .cursor/rules/ directory, so any correct answer Cursor gives cannot come from project contents.

Copying a WAL-mode database

The database runs in WAL mode. In WAL mode, committed transactions can live in a -wal sidecar file that has not yet been checkpointed back into the main database file. A byte copy of the main file alone, taken while a -wal exists, is a valid SQLite database that is quietly missing recent commits. It opens fine. PRAGMA integrity_check returns ok. Nothing announces the loss. The only way to know is to check for the sidecar before copying. Both -wal and -shm were absent before and after, so the copy is complete.

I used a raw byte copy with no database handle, bracketed by hashes of the source before and after. This proves the copy matches and nothing was written during the copy window. The backup API is safe but rewrites page layout, so a file hash cannot prove faithful capture.

Projection

I located the renderer in session_context.py and rendered the block against the copy. The renderer gathers facts for the project plus _global, sorts by score descending with id as tiebreak, and emits lines until the next one would breach a 1500-token budget, then writes a footer naming how many were dropped. The budget is enforced in characters at roughly four characters per token, with eighty characters held back so the footer always fits. For this database the block came to 5,991 bytes carrying 16 facts, with 1,055 omitted.

I wrote it into the throwaway project as an .mdc with frontmatter. The projection script reads the renderer's own output and prepends frontmatter, and asserts the body survives byte-identical. It also asserts the target directory is named cursor-testbed before writing anything, so a copy-paste cannot land in a real project. The file came to 6,241 bytes.

Rendering does not write to the database. record_recall is called only from the mem_recall MCP tool, not from the render path. The copy hashed identical before and after the render.

Next

The live test is a manual step. I need to open the throwaway project in Cursor, ask the prepared question, and compare against the recorded pass and fail answers. The primary test targets an agent-runner Manager deploy incident with an opaque session identifier that cannot be hallucinated. The control test targets the last fact in the block to detect truncation.

The result decides whether a Cursor port is a renderer plus a file writer, or something much larger.