Author here! Coding agents kept reworking decisions we'd already settled - reviving an approach we ruled out in an ADR, redoing something a requirement already pinned. The context was in the repo; the agent had no current view of it.
Lore serves your team's durable knowledge - requirements, decisions, designs, roadmaps, prompts - all as typed Markdown, read-only to Claude Code / Cursor over MCP, so the agent cites your decisions instead of contradicting them.
The bet: retrieval is deterministic. No embeddings, no vector store, no model call to pick what's relevant — same query, same bytes, same result, offline. It's not a RAG competitor; it composes — recall fuzzily, then verify the EXACT, CURRENT decision in Lore (it declines the ones you've superseded). Runs in CI (rac validate / rac gate) too.
pipx install rac-core
rac quickstart
claude mcp add lore -- rac mcp
What it isn't: a search index, a memory layer, or an AI feature — the engine makes no LLM calls, no telemetry unless you opt in. Early, and my corpus is small, so I'd like to hear where deterministic grounding breaks down for you vs. where fuzzy recall is enough.(Lore is the product; the engine under it is RAC — Requirements as Code, the `rac` package.) Apache-2.0, typed.
Hi! What I'm not quite getting from a cursory overview of the docs is how does RAC overlay overlapping decisions over each other? My mental model is a Docker overlay filesystem where RAC somehow manages to construct a cohesive view of the entire set of decisions over time, but how does that happen deterministically?
Let's say ADR 1 specifies users are unique by e-mail and should be soft-deleted, and ADR 2 says users are unique by username. Will RAC pick up on the fact that users still need to be soft-deleted? Is there a lot of manual "reference ADR 1 from ADR 2" to help with determinism?