Status:
accepted · ADR-15 · Filed 2026-04-17Decision
(none)Rationale
E3 was the third of my Plan #3 Wave E open questions. Plan #3 got superseded but E3’s text lived on in orphaned TODOs, and Donna’s cold-start read it as blocking Wave B drift detection work. The rule itself is straightforward and deserves codification: exact match is the 95% path, case-insensitive catches filesystem-casing variance between OSes and careless typing, and escalation prevents the one catastrophic failure mode (silently attaching a session’s records to the wrong project). This rule is the operational safety net for cross-agent, cross-machine continuity. The asymmetry — favor asking over guessing — is the right posture for a methodology tool whose entire value proposition is accurate shared memory.Alternatives Considered
Fuzzy matching (Levenshtein, prefix) — rejected; silent wrong-PID resolution is the worst failure mode in a shared-memory system because it corrupts one project’s records with another’s. Every ambiguous case must ask, never guess. Hardcode PID in a per-project file — rejected per BIOS v2 design; PID in CLAUDE.md was the exact anti-pattern we just fixed. Require explicit —pid flag on every session start — rejected; high friction, violates Context Is Currency, defeats the point of dir-based resolution. Dual keys (exact + project metadata) — already the model; codifying the fallback order is the addition.Decision
PID resolution rule forprism_start when called without explicit PID: (1) Exact match — compare current project dir basename to each registered project’s name and to basename(project_dir). First match wins. (2) Case-insensitive match — if step 1 returns zero hits, retry with case-folded comparison. First match wins. (3) Escalate — if step 2 returns zero or multiple hits, do NOT guess. Return an error payload listing candidate PIDs and prompting the user to call prism_start with an explicit PID. Specifically: never match on partial strings, never Levenshtein, never “closest fit.” The “PrismGR vs Prism” case that triggered this question is resolved at the data layer, not the algorithm layer — PrismGR is not a project (legacy rename, see correction memory 2026-04-17), so there is no ambiguity to resolve.