---
name: memory-dream / sync-memory may delete now — onboarding-phase additive-only constraint dropped
description: The "additive-only / never delete" philosophy in memory-dream and sync-memory.sh was a transitional safety measure during fleet onboarding. As of 2026-06-02, with everyone onboarded, destructive operations are allowed — deletions in the repo should propagate to harness profile stores, and memory-dream may apply merges/deletions when proposed. Updates to memory-dream and sync-memory.sh to honor deletions are pending.
type: feedback
---

**Rule:** The "additive-only / never delete" constraint on the memory tooling is **lifted**. Sanctioned destructive operations include: cleaning orphaned memory files, applying memory-dream's PROPOSED merges/dedups, propagating repo-side deletions back to harness profile stores via `sync-memory.sh`.

**Why:** Mike (2026-06-02) — the additive-only philosophy was a transitional safety measure during fleet onboarding so a half-configured machine couldn't accidentally wipe other operators' memories during a sync. Everyone is onboarded now; the workflow is established; the safety net actively fights deliberate consolidation. Specific concrete bite: the 2026-06-01 memory consolidation (104 → 71 files) had its 39 deletions resurrected the next morning when `sync-memory.sh` ran on another machine and copied them back from that machine's harness profile store into the repo. The additive design didn't know they were deliberately removed.

**How to apply:**

- **Repo deletions are intentional.** When `MEMORY.md` no longer references a file and the file isn't present in the repo, treat that as a deliberate removal — do NOT restore it from profile.
- **`sync-memory.sh` should propagate repo-side deletions** (the script as written today does not). Acceptable approach: pull first, then for each file present in profile but absent in repo, REMOVE from profile rather than restoring TO repo. Pending script update — flag any drift seen until it lands.
- **memory-dream's PROPOSED section** can now be human-actioned destructively without ceremony — merges, dedup deletes, stale-fact removal are all on the table.
- **Profile-store hygiene during cross-machine cleanup:** when a repo-side consolidation happens, every operator's harness profile store needs the same cleanup (or sync-memory.sh updated) before the next round of cross-machine sync, or the deletions resurrect.

**Don't apply this to:**
- Tooling outside the memory store. The vault, code, project files — destructive operations there still go through their normal channels (git commits, agent flows, gated skills). This relaxation is memory-store-specific.