feat(cli): move sessions, prompts and observations between projects

Open
  • Is something wrong?
#1,463 4 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
go, sqlite
Domain
api, cli

Research direction

Start from the existing RescueNullProjectOwnership transaction/journaling path and doctor repair's backup logic (under <ENGRAM_DATA_DIR>/backups/), plus the immutability guard ErrObservationProjectImmutable in internal/store/store.go. The deliverable is a new engram move --to <project> ... --dry-run|--apply subcommand with the anti-split guard reused from rescue, then the MCP mem_move_records admin counterpart; done means all six acceptance criteria pass with rescue-ownership and doctor behavior unchanged. Note the projects merge half depends on open #1451 and can be scoped out.

Written by the indexing model from the issue text.

Description

priority:medium status:needs-review type:feature
🔍 Problem Description

Engram sometimes stores information in the wrong project and there is no way to move a session, prompt or individual observation that already has a project assigned to another project, neither via CLI, MCP nor TUI.

Verified today on v2.2.1:

  • engram projects rescue-ownership --project <name> --session/--observation/--prompt <id> only rescues rows with NULL/empty project and reports already-owned rows as Blocked.
  • engram doctor repair --project P --check ... --apply (from #286) only reclassifies contaminated sessions when there is trustworthy evidence (git_remote/git_root or manual-save-{known-project} name), with SQLite backup under <ENGRAM_DATA_DIR>/backups/.
  • MCP mem_update exposes no project field and the store rejects project changes with ErrObservationProjectImmutable (internal/store/store.go).
  • engram projects consolidate and MCP mem_merge_projects {from,to} (admin profile) only merge name variants equivalent under normalization and reject arbitrary pairs like acmeapi → acme-api.
  • engram projects merge --from/--to requested in #1296 does not exist in v2.2.1 and its building block (#1451, MergeProjectsByName + CountProjectRecords) is still OPEN.
💡 Proposed Solution

New engram move --to <project> [--session <id>]... [--observation <id>]... [--prompt <id>]... [--dry-run|--apply], reusing the transaction/journaling of RescueNullProjectOwnership but WITHOUT requiring empty project, with prior backup like doctor --apply, recalculated ownership_mode, and rejection when an observation would be split from its session (same anti-split guard as rescue).

MCP counterpart mem_move_records under admin profile with identical parameters.

In parallel, engram projects merge --from A --to B --dry-run|--apply on top of #1451.

📦 Affected Area

CLI (commands, flags)

🔄 Alternatives Considered

Evaluated existing paths, none of which move already-owned records: rescue-ownership (NULL/empty rows only), doctor repair (evidence-based reclassification only), projects consolidate / mem_merge_projects (normalization-equivalent name variants only), mem_update (project immutable by design).

📎 Additional Context

References:

  • #286 (closest existing, CLI/MCP repair with backup)
  • #179 (mem_update never persisted project change)
  • #1296 (merge --from/--to, CLOSED without the subcommand)
  • #1451 (OPEN, pending seam)
  • #94 (TUI delete sessions, delete not move)
  • #107 (selective export TUI, not move)

Acceptance criteria:

  • Move one already-assigned session to another project via CLI with dry-run first and backup on apply.
  • Move one already-assigned observation to another project via CLI with dry-run first and backup on apply.
  • Move one already-assigned prompt to another project via CLI with dry-run first and backup on apply.
  • MCP admin equivalent (mem_move_records).
  • Docs updated.
  • Existing rescue-ownership and doctor behavior unchanged.
Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
10h 51m
Merged PRs (30d)
277

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.