Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(store): offer a project privacy purge instead of retaining orphaned relations after hard deletion

Open
  • Is something wrong?
#1,780 0 comments 0 reactions 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
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go, sqlite
Domain
database

Research direction

Start in internal/store/store.go: the hard project deletion that marks memory_relations rows orphaned (around lines 9489-9505), the native import that uses INSERT OR IGNORE for relations (around 6740-6795), and the relation sync filter that excludes orphaned status (around 6144-6172). Done would be a scoped, dry-run-first purge that removes only the selected project's relation rows and payloads, leaves other projects untouched, and is opt-in rather than changing the default. The design needs maintainer input before implementation.

Written by the indexing model from the issue text.

Description

status:needs-review type:feature
🔍 Problem Description

A project-scoped privacy reset needs to remove old path-bearing memory data before restoring a sanitized native backup. In Engram 3.2.1, engram delete project <project-name> --hard retains associated memory_relations rows and changes their judgment_status to orphaned. The relationship reason/evidence payloads remain stored. This is explicit current implementation, not an assertion that deletion unexpectedly fails.

When importing the pre-delete backup, observations return with their portable sync identities, but existing relationship identities are skipped by INSERT OR IGNORE. Their original judged/pending statuses are therefore not restored. Once observation endpoints return, these rows are not necessarily dangling; they simply retain the orphaned status.

The expected privacy-reset outcome was complete removal of the selected project's data, including project-contained relationship payloads, without touching other projects. Current audit-preservation semantics and absence of a supported relationship purge make that outcome unavailable through this workflow.

💡 Proposed Solution

Provide a supported, explicitly destructive project privacy-purge operation (or an opt-in hard-delete flag), with a dry-run inventory and confirmation, that removes project-owned relationship records and sensitive payloads rather than retaining them as audit history. Define safe behavior for relationships crossing project boundaries and preserve unrelated projects. Do not change the existing audit-preserving default silently.

Document the difference between hard deletion, audit preservation, privacy purging, native backup import and normal sync. At minimum, expose retained relationship counts in deletion output and explain that importing an earlier backup does not restore existing orphaned relationship states. Consider a separately explicit restore/replace mode if status restoration is supported.

📦 Affected Area

Store (database, queries)

🔄 Alternatives Considered
  • Updating current observations via MCP: does not scrub old versions, prompts or session-directory metadata.
  • Sanitizing only Git chunks: protects a published copy, but leaves the local database unchanged and risks resurfacing values in later exports.
  • Exporting the selected project, sanitizing the native JSON, deleting the project, removing old .engram chunks, importing the sanitized JSON, then syncing: restores the current memories but retains original local relation rows with orphaned status. Accepted as a temporary operational tradeoff, not equivalent to full privacy purging.
  • Importing into a new empty database: isolated rehearsal restores relationships correctly, but replacing a live multi-project database would require preserving and separately validating all other projects.
  • Direct SQL deletion: avoided because no supported scoped purge contract was found.
📎 Additional Context

Environment: Engram 3.2.1, Linux x86_64; command-line backup/deletion/import with MCP observation edits. Native export format version: 0.2.0. No cloud purge or secure physical erasure claim is requested here.

Reproduction outline (run only against a disposable copy or isolated store, never an unbacked live database):

  1. Prepare a project with observations and judged/pending relationships.
  2. engram export backup.json --project <project-name>
  3. engram delete project <project-name> --hard
  4. engram import backup.json
  5. Export the project again and compare relationship identities/statuses with the backup. Existing relation identities remain orphaned rather than returning to their backed-up states.

A full-database-copy rehearsal restored 449 observations, 75 prompts and 47 sessions. Before deletion, the project's relationships comprised 405 judged and 19 pending rows; afterward all 424 remained orphaned, including after reimport. An empty-database import rehearsal instead preserved the backup relationship states. These are aggregate observations, not a minimal synthetic fixture or a claim that the live database was deleted.

The planned privacy workflow keeps backups outside the directory being removed, uses native export/import rather than rewriting sync internals, and sanitizes path-bearing strings in session directories/summaries, observations, prompts and relation reason/evidence while preserving language-study text, stable identities, timestamps and pins. Blank portable session-directory metadata is used where appropriate. It validates an isolated import/export round trip and checks newly generated sync chunks for residual personal paths before publication. No private project names, machine names, paths or source text are included in this report.

Normal sync excludes orphaned relation mutations, whereas native export includes persisted relation metadata. Thus a fresh sync can be clean even while old relation payloads remain in the local database and may reappear in a future native export.

Verified tagged implementation:

Related but different: #1455 addresses diagnosing legacy missing-endpoint relations; #1291 addresses backup/import behavior with absent endpoints; #1289 purges quarantined sync mutations. This request concerns intentional relationship retention during project privacy reset and a supported opt-in purge, not those earlier failures.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
8h 57m
Merged PRs (30d)
365

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.