--- name: planning-filed-by-roadmap-version description: "planning/ artifacts are filed by the ROADMAP VERSION the work belongs to, never by file modification date" metadata: node_type: memory type: feedback originSessionId: dba2683f-5342-4eb2-b606-b635b1298915 modified: 2026-07-20T20:09:24.059Z --- Files under `planning/<version>/` are bucketed by **the roadmap version the WORK belongs to**, decided by reading each doc's content — **never by file modification date**. **Why:** a prior reorg (twice now) bucketed by mtime — roughly "modified recently ⇒ next version" — and dumped a whole round's worth of work into the NEXT version's folder, even though that round had not started and its folder should not have existed at all. The owner caught it both times. Date is a proxy that fails exactly when a round's work spans a version boundary. **The governing test (owner, 2026-07-18, verbatim clarification): "which release's work PRODUCED this document?"** — NOT what era/version it discusses, NOT file mtime. An internal version stamp is legitimate evidence, but read it correctly: a stamp is usually the *code baseline the doc measured* ("what it talks about"), which is exactly what you must NOT file by when it differs from the producing release. **How to apply:** - Ask of each file: *which roadmap version was this work part of?* Read enough of the doc — header, baseline stamp, subject matter — to answer honestly; do not pattern-match on filename and do not trust the mtime. Use `QUEUE.md` as the arbiter of which release built what. - **A doc is filed under the release that built the THING it is planning/implementation material FOR.** An audit that measures old code in order to plan a later overhaul is material FOR that overhaul → it files under the overhaul's version, not the version it measured. - A doc authored during round X as **design input for a deferred deliverable in round Y** files under **X, the round that PRODUCED it** — owner's explicit rule. - A plan/spec/slate/design for a program files by that program's version. Baseline ≠ producing release. - A feature design for a feature the queue shows as already BUILT files by the version that shipped it. - **Nothing goes in a FUTURE bucket** it merely mentions. A version folder exists **only when it has real contents** — never pre-create an empty one, because that implies work exists. - `planning/` is gitignored, so a re-bucket only produces tracked changes via **reference updates** (`planning/<old>/…` → `planning/<new>/…`) in the committed docs, test comments, local `library/` docs and this memory store. The path-validating suite does not check `planning/` paths (gitignored, absent on CI) so it stays green regardless — update the refs anyway, for navigability. - The archive at `C:\Dev\!RobCo\_RobCo-Archive\` is **additive-only** for `planning/`, so a move looks like delete+add there; after re-bucketing, run the sync, then prune the stale old-path copies from the archive working tree and commit that (see [[backup-archive-repo]]). **The mistake to not repeat:** on the first pass I filed a large batch of analysis docs by their baseline stamp — i.e. by "what they discuss" — and moved them into older folders. The clarification corrected it: they were the analysis phase that produced a later overhaul, so they belong with the overhaul. Only genuine feature designs for already-shipped features legitimately move backwards.