Fredrin
Our project points its memory folder at `docs/` in project settings, so Workers write decision records to `docs/adr/` and use the root `CONTEXT.md` as the glossary — one context home shared with the repo instead of a separate `.fredrin/memory/` bundle. That works for ADRs, but the mapping only covers half the bundle. `ticket context-classify`'s `significant` branch tells the Worker to add an ADR *and* "update the concept doc under `.fredrin/memory/concepts/`". With the folder remapped there's no corresponding `docs/concepts/`, and our own FREDRIN.md guidance says not to fall back to `.fredrin/memory/`. So the Worker gets a half-mapped instruction and quietly skips the concepts half — nothing errors, the state layer just never gets written. Two things that would help: 1. Have the remap cover the whole bundle (concepts + adr + glossary), or let each be pointed separately. Right now "context root" behaves like "ADR root". 2. Expose the setting to the CLI so an agent can confirm where memory actually lives. `fredrin projects list` returns only id/slug/name/workspaceId, and `/api/projects/<id>` 404s, so there's no read path from a terminal — the only artifact asserting the remap is a paragraph we hand-wrote into FREDRIN.md, which can silently drift from the real setting.
Fixed both halves — PR #2232. You were right that "context root" was really "ADR root", and it was in the type: `ContextPaths` carried `adrDir` and `notesDir` and **no `conceptsDir`**, so the concept-wiki directory had no derived form and every caller hand-wrote a literal instead. `contextPaths()` now derives all three from the one root (including the repo-root sentinel `.`), so remapping moves concepts, decisions and notes together. The half-mapped instruction turned out to have a single source. `context-classify` itself is path-agnostic — it only ever returns `{tier, reasons, needsLlm}` — and the per-ticket wrapper had no reference to `contextRoot` at all. The `.fredrin/memory/concepts/` string lived only in the FREDRIN.md template. That text is now root-agnostic and points at a lookup rather than naming a folder. On your second point: it was a 405, not a 404 — the route existed but exported only `PATCH`/`DELETE`, while `docs/api.md` had documented the `GET` for ages. So there are now three ways to ask where Memory actually lives: - `./.fredrin/fredrin project memory` — from inside a ticket worktree - `fredrin projects get <slug|id>` — from any terminal - `GET /api/v1/projects/{projectId}` — returns the project plus a resolved `memory` block Each gives you `{root, conceptsDir, adrDir, notesDir, glossary, entryPoints, isDefault}` read from the live setting. `fredrin projects list` also carries each project's `contextRoot` now, so a remap is visible at a glance. Deliberately *not* done: interpolating your root into FREDRIN.md at worktree bootstrap. That just moves the drift you described one layer down — a snapshot baked into a committed file goes stale the moment someone changes the setting. Hence the lookup. Also fixed while in there: the Memory graph and decision-log panels were hardcoding `docs/concepts/` and `docs/adr/` in their empty states, so a remapped project was being told the wrong path in the UI too. One related thing your report surfaced that is **not** fixed yet, tracked separately as FRED-ROX3O9: `fredrin ticket context` resolves its root by probing a fixed list — `.fredrin/memory`, `docs`, `fredrin`, `.` — and ignores `contextRoot` entirely, because a worktree has no DB. Your project is on `docs`, the second candidate, so retrieval works for you. A project on a root outside that list is silently invisible to it. Same root cause, different subsystem, and fixing it revisits where the context pack gets computed — so it gets its own ticket rather than riding along here.