Mike Swanson
c759f04674
The 39 files I deleted in0c00010got resurrected by sync-memory.sh on GURU-5070 (f8ed03c) because the script is additive-only. Re-deleted them (49 files this time -- some additional drift between machines). Also added feedback_memory_sync_destructive_ok.md capturing the policy shift: with everyone onboarded, the memory tooling no longer needs additive-only safety. memory-dream may apply proposed merges/deletions and sync-memory.sh should propagate repo-side deletions back to profile stores. Script updates to honor that are still pending -- without them, this round of cleanup is also vulnerable to resurrection. Self-check: 0 WARN, 1 FAIL remaining (autotask command -- manifest issue, not fixable on this machine; needs Mike to either un-localize /autotask or move it to capability-gated in baseline/manifest.json). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
name, description, type
| name | description | type |
|---|---|---|
| memory-dream / sync-memory may delete now — onboarding-phase additive-only constraint dropped | 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. | 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.mdno 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.shshould 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.