Module 44 · 30 min

Knowledge That Outlives the Session

You can state why this plugin compiles knowledge into files instead of searching your notes, and name the one thing it refuses to do that every other memory tool does.

Surface
the decision, before any file exists
Claude Code
v2.1.251
Docs checked
2026-09-02

You told Claude something important three weeks ago. A decision, and the reason behind it. Today you open a new session in the same repository and it is gone, because a session is a conversation and conversations end.

Module 02 named that problem and reached for CLAUDE.md, a file Claude reads at the start of every session. That works until the file is four hundred lines long, at which point you are paying for the whole thing on every turn and the fact you need is buried in the middle of it.

This track builds the other answer. Eight modules, an empty folder at one end and a published plugin called llm-wiki at the other, which keeps knowledge as ordinary Markdown files in Git, injects a small map of them at session start, and lets Claude read the rest on demand. The finished plugin is at github.com/01000001-01001110/llm-wiki-plugin, nine files and 89 KB, and you will have written every one of them by module 51.

Before we write a line of it, we need to settle one decision, because it determines everything else. Let’s get into it.

The word that decides the architecture is “compiled”

There are two ways to give a model knowledge it did not have in its context, and picking the wrong one costs you a service you have to keep running for the rest of the project’s life.

The first is retrieval: keep the raw material, and at question time go find the parts that look relevant. This is what a vector database does. You embed your documents, meaning you turn each one into a list of numbers that places it near documents about similar things, and at query time you fetch the nearest few. It works, and it costs you a service to run, a schema to migrate, an index to rebuild, and an answer to the question “why did it return that?” that is usually “the numbers said so.”

The second is compilation: read the raw material once, decide what it means, and write the conclusion down as a page. Then the knowledge is a file. Finding it is Grep. Reading it is Read. Reviewing it is a diff. Nothing to run, nothing to migrate, nothing to explain to the next person.

Here is what those two look like side by side.

flowchart TD
subgraph R["Retrieval"]
  direction LR
  r1["raw documents"] --> r2["embedding index"] --> r3["query time: fetch nearest"] --> r4["answer"]
end
subgraph C["Compilation"]
  direction LR
  c1["raw documents"] --> c2["read once, decide meaning"] --> c3["wiki page in Git"] --> c4["answer"]
end
R ~~~ C
The two shapes. Retrieval keeps the sources and searches them at question time; compilation reads them once and writes down what they meant.

llm-wiki takes the second shape. Its README says why in one sentence, and it is worth reading twice: “Claude Code already supplies retrieval, routing, synthesis, and judgment. This plugin only adds the pieces that should be deterministic.”

Read that as a subtraction. Claude can already search a folder, read files, and work out what they mean. Building a retrieval service underneath it duplicates a capability you already have.

What Claude cannot do reliably is bookkeeping. Hashing a file the same way every time. Remembering which page depended on which source. Noticing that a page has drifted. That part becomes a script, and that script is most of what we build over the next seven modules.

The thing it refuses to do

Now for the part that surprises people. Most memory tools for language models are search infrastructure. This one has none, and the refusal is written into the design notes rather than left implied. From the README, under “Search”:

No QMD, embeddings, vector database, graph service, reranker, or query router in v1. Start with index.md + Claude Code’s Glob/Grep/Read. Add search infrastructure only after measured retrieval failures.

The last clause is the part worth keeping. It is not a claim that search infrastructure is bad. It is an ordering: you do not get to add an index until you can point at retrieval that actually failed. A wiki of eighty pages does not need a vector store, and if you build one anyway you now own it.

Where this stops working

Compilation has a real cost and this track will not pretend otherwise. Every source has to be read by a model before it becomes knowledge, so ingesting a thousand documents costs a thousand reads. Retrieval front-loads nothing and pays at query time instead. If your corpus is large, changes constantly, and is queried rarely, retrieval is the better trade and this plugin is the wrong tool. The case it fits is the opposite one: a body of knowledge that grows slowly, is read constantly, and is worth the cost of thinking about once.

Three directories and one rule each

Next up is the shape itself, and the good news is that it is small enough to hold in your head. Two directories of content, one directory of bookkeeping, and each carries a single rule that the rest of the track keeps returning to.

your-project/
├─ raw/
├─ wiki/
└─ .llm-wiki/
raw/

Evidence. Append-only: nothing here is ever edited or deleted.

Directory. Holds the source documents you feed the wiki.
Append-only and tracked in Git.

Example contents:
  raw/hsm-notes.md
  raw/hsm-notes-v2.md
Read more

A raw source is a file you got from somewhere: a meeting transcript, a vendor page, a spec. Once it is registered, changing its bytes is reported as an integrity violation rather than accepted as an update. A revised document arrives as a new file with a new identity. Module 46 builds this and shows what the violation looks like.

The shape at the end of module 45. Read raw/ first: its rule is the one that makes everything downstream checkable.

That is the whole system. raw/ is append-only. wiki/ is derived, so Claude may rewrite it freely. .llm-wiki/ is the script’s own record and no human edits it by hand. Three directories, three rules.

The reason we state those three rules this early is that together they are what makes the knowledge auditable. If a wiki page is wrong, you can find the source it was compiled from, and that source has not changed since, because changing it is an error the tool reports. Every claim has a receipt. That property is the whole reason for the append-only rule, and it is the first thing people give up when they let a source file be “corrected in place”.

Build

Nothing lands in a plugin this module. What lands is a decision you can defend, so write it down where you will find it again. In the project you intend to use this on, create a file called WIKI-DECISION.md and answer three questions in it: how many documents do you expect to feed this in the first month, how often will you read the compiled pages, and what is the one question you keep having to re-answer from memory. If the first number is in the thousands and the second is “rarely”, stop here and use a retrieval tool instead. This track is written for the other case.

The mistake most people make first

Treating the wiki as a place to dump the sources. You paste the meeting transcript into a page called meeting-notes.md, feel productive, and repeat it forty times. Six months later the wiki is a folder of transcripts, which is what raw/ already was, and the search you were trying to avoid is now unavoidable because nothing was ever decided. The tell is a page you cannot summarise in one sentence. A compiled page states a conclusion and cites the evidence; a dumped page restates the evidence and concludes nothing. This failure is silent, since a folder of transcripts looks exactly like a working wiki from the outside, and the only symptom is that reading it never answers anything.

Does this travel?

The architecture travels completely, because it is files and Git rather than an API. A wiki built this way is readable by any tool that can read Markdown, and a teammate on a different harness gets the same value from the same folder with no adapter. What does not travel is the automation: the hooks in module 49 are Claude Code’s hook system, and the slash commands in module 48 are Claude Code’s command format. Point another harness at the same wiki and you keep the knowledge and lose the bookkeeping, which is a better failure than the reverse.

Check yourself

  1. A colleague proposes adding a vector database so the wiki can answer questions about sources that were never compiled into pages. Using the ordering this module states, what has to happen before that is the right call?
  2. raw/ is append-only and wiki/ is not. What property does that difference buy, and which of the two directories would you look in first to check whether a wiki page is still true?
  3. Name the case where compilation is the wrong choice and retrieval is the right one, in terms of corpus size, change rate, and read frequency.