DR-113 — Stale-family marking is a recall-path concern, not a mine-time room

Context

DR-112 defined four tiers, of which T3 Stale-marked was to be realised by mining the DR-106 stale families into room = archive so recall could down-rank them. Executing the mine in S519 proved that tier cannot exist as designed.

miner.detect_room walks a file’s path parts outermost-first and returns on the first part matching any room name or keyword. Every DR-106 family sits below a family that already owns a room:

T3 keyword	lives at	first matching part	actually lands in
intended-architecture	initiatives/core-product/canonical-pipeline/…	initiatives	initiatives
phase-0-investigation	initiatives/core-product/canonical-pipeline/…	initiatives	initiatives
_archive	under specs/, runbooks/, reference/, continuation-prompts/, initiatives/	the parent family	never archive
themes	deleted from disk (fa71b6bf)	—	—

Only archive (the repo-root journals) and product-functionality (top-level) resolve. Confirmed post-mine: intended-architecture/01-vision.md and 03-tech-stack.md both return room: initiatives. Declaration order cannot fix it — path depth dominates.

A second constraint compounds it: make_drawer_id_from_chunk hashes the room into the drawer id, and file_already_mined(..., check_mtime=True) skips any unchanged file. So a previously-mined file cannot be moved to a different room by re-mining — the mine skips it, and forcing it through would mint new ids beside the old drawers rather than replacing them.

Decision

The stale-family discriminator is source_file path matching applied at recall time, not a room assigned at mine time. DR-112’s T3 is withdrawn as a mine-time tier; the archive room keeps only the keywords that actually resolve (archive, product-functionality), and the mempalace.yaml does not list unreachable keywords. DR-106 remains reader discipline, now enforceable in the recall path (DR-112 Q6, in scope for id-383).

Changing any mined file’s room is delete-then-re-mine, never a metadata patch — patching room in place leaves a drawer id that no longer matches its recipe, so the next edit to that file forks it into parallel drawers.

Alternatives Considered

• Reorder the room declarations. Does not work: detect_room iterates path parts in the outer loop, so a shallower part always wins regardless of declaration order.
• Drop initiatives as a room keyword so the deeper stale keywords can match. Rejected: every other initiatives file would then fall through to content scoring or general, trading a precise failure for a diffuse one.
• Move the stale trees to a top-level _archive/. A large docs-site refactor that relocates live published URLs to fix a marker, and DR-106 explicitly wants those docs readable for lineage. Available later if the recall-path route proves insufficient.
• Patch room metadata in place on the 39,270 affected drawers. Cheaper (no re-embedding, no LLM closet spend) but seeds a latent duplication bug via the drawer-id recipe. Rejected by the owner in favour of delete-then-re-mine.

Consequences

• The archive room means “repo-root journals and product-functionality” — not “every stale family”. Anything reading room = archive as a completeness signal is wrong.
• DR-112 Q4 is a no-op and was not executed. Moving 01-vision.md up a directory was premised on path routing sending it to archive; initiatives matches four levels earlier, so the move changes a published URL and nothing else.
• DR-112 Q6 is promoted from “in scope” to load-bearing. Without the recall-path change there is no stale-marking mechanism at all. That change must key off source_file.
• Blocking Q6 today: mempalace_search with room= returns 0 results for queries that match plainly unfiltered — the #1665 filter defect known for wing applies to room too. Filter client-side until fixed.
• Mechanism detail and the executed numbers: runbooks/mempalace-repair.md §13.4.