Cross chat todo persistence

Cross-Chat Todo Persistence

Keep todo sessions alive between conversations. On a new chat, detect unfinished work, resume the most recent one, and offer to switch. This is the state concern only — render with swiss-grid-todo-display, decide when to surface with contextual-todo-triggers.

When to use

• Work spans multiple sessions and the user expects continuity ("where were we?").
• You need to manage several parallel projects and switch focus between them.

Session data model

{
  "id": "design-system-project",
  "title": "Design System Project",
  "todos": [
    { "content": "Review MCP server documentation", "status": "completed", "priority": "high" },
    { "content": "Test Swiss Grid implementation", "status": "in_progress", "priority": "medium" }
  ],
  "lastModified": "2026-07-18T10:00:00.000Z",
  "lastWorkedOn": "2026-07-18T10:00:00.000Z"
}

status ∈ pending | in_progress | completed | cancelled. lastWorkedOn drives recency ordering.

Operations

Operation	Behavior
save(session)	Upsert by id; stamp lastModified/lastWorkedOn.
loadAll()	Return every stored session keyed by id.
getIncomplete()	Sessions with at least one pending or in_progress item.
getMostRecentIncomplete()	Incomplete sessions sorted by lastWorkedOn desc → first.
switch(id)	Set current session, re-stamp lastWorkedOn, return it. Fail clearly if id missing.

New-conversation resume flow

1. On chat start, call getIncomplete().
2. Zero incomplete → "No active todos found. Ready to create a new session!"
3. One or more → resume getMostRecentIncomplete() as current, render it, then list the others as an overview:
   • • {title} — {completed}/{total} complete, {inProgress} in progress ({lastWorkedOn date})
4. Ask once: "Continue with {title}, or switch to a different session?"

Storage

Runtime-agnostic default: a single JSON file, one object keyed by session id.

Claude Desktop-specific (isolated): the original MCP server stored at ~/Library/Application Support/Claude/todos.json. On any other runtime, use a path you control (e.g. $XDG_DATA_HOME/todos.json or ./.todos.json). The reference implementation takes the path as a constructor argument — no host assumption baked in.

Reference implementation

reference/session-store.mjs — self-contained, file-backed ES module. Constructor takes a storage path; exports the operations above. Run node reference/session-store.mjs for a demo against a temp file.

Agent-runtime notes

The data model and flow are runtime-agnostic. Only the default storage path is host-specific and is isolated in the reference constructor argument, not hard-coded.