Files
dotfiles/claude/memory/feedback-preserve-dont-delete-when-retiring.md
T
David F GliddenandClaude Opus 4.8 3f9a89b00c chore(memory): Basic Memory trial begins — sync normalization baseline (283 files)
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized
live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds
long YAML description lines, strips final newlines. Bodies untouched —
verified via full diff classification. From this commit forward, any diff in
claude/memory shows only what Basic Memory or the session writes.

Trial design: MemPalace untouched as incumbent; git status check on this dir
at every wrap; end-of-day evaluation (recall quality, sync robustness,
rebuild-from-files, malformed-file behavior).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 09:52:17 +02:00

23 lines
3.0 KiB
Markdown

---
name: Preserve, don't delete — when retiring scaffolding, archive with provenance
description: When the steward says "remove" or "retire" about scaffolding, default
to archival (with clear retirement note + provenance), not deletion. Confirm before
destructive action.
type: feedback
originSessionId: efda5c2e-ca9a-4e55-9344-64aa9a3c1140
permalink: claude-memory/feedback-preserve-dont-delete-when-retiring
---
When the steward says *"can be removed"* or *"retire"* about an existing implementation file, spec section, or other scaffolding artefact, the default interpretation is **remove from active use, preserve the artefact with archival note**. Not deletion. Confirm before any destructive action.
**Why:** Steward verbatim 2026-04-27 after I `rm`'d `scss/AldineXXI/archive-v1/_marginalia.scss` in response to *"dormant marginalia can be removed"*: *"meant removed from the spec, but we archive it, correct?"* He was retiring the active reference, not the historical record. Same shape as the 2026-04-26 sibling-file integration with redirect notices (*"the record needs to be complete"*) — preservation is the consistent posture across ARC scaffolding decisions. The file was already in `archive-v1/` (already archived once); my deletion would have erased the implementation entirely. Restored from git (HEAD 5c059d8).
**How to apply:**
- *"can be removed"* / *"let's retire X"* / *"remove this from the spec"* → **archive with provenance, do not delete**. Move to a clearly-named archive location if not already archived; add a retirement note (date + reason + supersession references); leave a breadcrumb in the active artefact pointing to where the archived version lives.
- When in doubt about destructive vs preserving action, **ask first**. The cost of pausing is low; the cost of deletion is irreversible.
- Cousin to the 2026-04-26 *"the record needs to be complete"* pattern (sibling-file integration with redirect notices retained as audit trail). Both express the same posture: the work has provenance; provenance is preserved.
- Specifically applies to: ARC spec sections (AldineXXI Codex), ARC SCSS partials, ARC content/template files, chamber-library files, any thinking-folder artefacts. The default pattern is archival, not deletion.
- Also applies during cleanup passes (Phase 0 audits, etc.): the steward distinguishes *Batch A delete* (disposable cruft) from *Batch B/C archive* (anything with provenance value). Archive is the default; delete needs explicit per-item authorization.
- The git history preserves files at the file-path level, but archival-with-provenance is more legible than git archaeology. A retirement note in the active artefact + an archive location is what the steward consistently chooses when given the choice.
Cousin to: `feedback-canonical-workstream-tracker-discipline.md` (the record needs to be complete in canonical trackers); the 2026-04-26 sibling-file integration LOCK; `feedback-trust-contract-drift-pattern-tracking-is-the-discipline.md` (drift-tracking IS the discipline — preservation is its sibling).