--- name: planning-folder-hygiene description: "⭐ STANDING RULE (owner, 2026-07-22): the APP repo's `planning/` holds only CURRENT-use working docs. Once a planning file has served its use (e.g. a shipped version's planning like 2.6.0), DELETE it from the app repo — but ⛔ ONLY after confirming it is backed up in the archive. The archive is the permanent home for planning; the app repo stays lean. HARD INVARIANT: the archive MUST have the file before it's deleted." metadata: node_type: project type: project originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 modified: 2026-07-22T13:18:20.622Z --- **Owner, 2026-07-22 (verbatim):** *"files in planning should be deleted after they serve their use but only after being backed up in the archive (so C:\Dev\!RobCo\!RobCo-UOS\planning) shouldn't have old files. Like 2.6.0 files ya know ? bc the archive hosts them. But the archive MUST have any file in planning before it's deleted."* ## THE RULE - The **app repo's `planning/`** is for CURRENT working material only. Old-version planning (e.g. 2.6.0, 2.5.0 audits/plans) should NOT linger there — it belongs in the archive. - When a planning file has served its use: **(1) confirm it's in the archive → (2) delete it from the app repo.** In that order, always. - The **private archive (`_RobCo-Archive/planning/`)** is the PERMANENT home. Nothing is lost by deleting from the app repo — it's just moved to where it lives. ## ⛔ THE HARD INVARIANT — save-sacred, applied to planning docs **NEVER delete a planning file from the app repo unless it is CONFIRMED present in the archive first.** A planning doc is real work; losing one to a delete-before-backup is the same class of failure as losing a save. Check, then delete — never delete blind. ## WHY IT'S SAFE (the mechanism — verify it still holds before relying on it) The Protocol 48 sync (`sync.ps1`) mirrors `planning/` into the archive **ADDITIVELY** — the archive KEEPS every planning file ever synced, even after it's removed from the app repo (this is the `ARCHIVE_RETAINED.md` concept: files retained in the archive that are no longer in the app repo). Contrast with `memory/`, which is MIRRORED (deletions propagate). So: - Once a planning file has been synced, it is permanently retained in the archive. - Deleting it from the app repo is then safe — the next sync will NOT remove it from the archive (additive). - ⇒ The safe delete sequence is: **run/confirm the sync captured the file → verify it's in the archive → delete from the app repo.** ⚠ Because the safety depends on the additive-sync behavior, if that behavior ever changes to mirrored for planning, this rule's safety evaporates — re-verify before any bulk planning delete. ## ⛔ SECOND HARD CONSTRAINT — don't delete anything still NEEDED FORWARD (owner, 2026-07-22) *"Ensure you don't delete folders in 2.8.5 that we still need for 2.9.0."* "Served its use" means DONE, not merely belonging to a shipped version. Forward-looking planning — anything 2.9.0 (or later) still depends on, shared material, or plans not yet executed — STAYS in the app repo even if it lives under an old-version folder. **The cleanup removes only genuinely-finished planning; when in doubt, KEEP.** A planning doc for a shipped version is a candidate for removal; a planning doc the next round still consumes is NOT, regardless of which folder it sits in. ## OUTSTANDING There is old-version planning cruft in the app repo right now (owner named 2.6.0 as an example). A cleanup pass should: confirm each old-version planning file is in the archive, then remove it from the app repo's `planning/`. Do it in the app repo when nothing else is running there (concurrency: [[dispatch-midflight-messages-unreliable]] era gate-collision lesson). Not yet done as of 2026-07-22. Related: [[parked-phone-archive-access]] (the archive's role), [[delete-leftovers-rule]] (Protocol 41 junk sweep — different: that's scratch files, this is served-purpose planning docs), [[folder-and-repo-naming]].