Project memory
The part of Nemocode that is not in the code: what was decided, what must hold, what a document demands — kept with a reason, and offered back when it matters.
Why it exists
Code shows the current attempt at a requirement. It does not show the requirement. “Prices are always net”, “we stay on the old library because the new one drops Windows support”, “the spec says a draft must survive a crash” — none of that is readable from a diff, and all of it decides whether the next change is right or wrong.
Nemocode keeps those sentences per project, each with the evidence behind it and a pointer to where it came from. This memory is called the PUM, the Project Understanding Map.
What it is made of
| Part | What it is |
|---|---|
| Node | One statement — a fact, a decision, a constraint. Each has an id, a short list of topics, a weight and a status. |
| Rule | A node you or the curator marked as a rule: something that must hold. Rules are loaded at the start of every mission. You can make a node a rule, or demote it again, in the browser view and through the curator. |
| Edge | A connection between two nodes, with a kind — causal, temporal, contrast, logical, evidential, evaluative or constitutive — and an optional explanation. It can carry proofs of its own. |
| Proof | The evidence behind a node or an edge: a test, a file and line, a document, a conversation, a decision by you. Each proof either supports or refutes. |
| Conflict | Two statements that contradict each other. It waits at the gate until it is decided. |
| Status | active, rule, open question or superseded (retired, usually in favour of a newer statement). Superseded nodes stay in the history. |
The gate
When a mission ends, Nemocode proposes what it thinks is worth keeping. Most proposals wait at a gate. Open it:
/pendingEach entry shows the sentence, why Nemocode believes it, and where it came from — and its context: what the memory already says on the subject, what the proposal would replace, and what supports it. You approve it, reject it, or — if two entries disagree — decide which one survives: keep the first, keep the second, or dismiss when it is no conflict at all. Nemocode settles a conflict by itself only where it is clear beyond doubt; the doubtful ones are left for you. Keys are on the Keys page; the same list is in the browser (Pending).
What waits, and what does not. Waiting for
you: everything the curator's harvest proposes, everything another coding agent
sends, what /bootstrap seeds, and — from any source — every rule,
every decision and every deletion. Two things skip the gate: what
/learn files from the agent's notes, and the notes Nemocode files just
before it compacts a long conversation, are applied straight away unless they
are rules, decisions or deletions; and a team pull brings in the shared version
that colleagues already approved (see Sharing with a team).
Whatever was applied is in the history, and approvals can be undone.
What happened can be taken back: undo (u in the Pending tab of the gate and in the graph, the button in the browser) takes back approvals — including ones Nemocode applied itself —, verdicts on proofs, renames, conflict decisions, edited statements, rule changes, retirements, added or removed connections and deletions, but not a rejection. The browser's redo replays what you took back. When a pull from a team, or a rebuild of the code index, changes facts that the history still refers to, the undo and redo history is cleared.
Weight: how sure it is
Every fact carries a weight between 0 and 1, and the weight comes from the evidence, not from confidence. A statement backed by a passing test weighs more than one backed by “the agent thinks so”. Something you confirmed yourself weighs a lot — you are the source, not a witness. A refuted proof stops counting, and a statement with only refuted proofs falls to zero.
The kind of proof sets how much it can add: what you assert or decide yourself counts most, then a decision recorded by the team or an architecture note, then indicators such as an approved review, the blame of a line, a mention in the docs. Edges weigh in differently, too, by the kind of connection.
Some more numbers. A proof nobody has checked yet counts half; one that was checked — by Nemocode's checking model or by you — counts in full. Older proofs count less, but never below half. Every open conflict on a statement pulls it down. Different kinds of evidence together add a small bonus. A rule weighs exactly 1, a fact about the code itself 0.95, a retired statement 0.15.
What that does for you: from 0.8 up a statement is treated as
a fact. Below that it is a hypothesis and is said as one (“probably, check the
code”). When you ask the memory a question, weak statements are still offered,
labelled fact (0.8 and up), likely (0.4 to 0.8) or
weak (below 0.4); only refuted ones are left out. When a mission loads
the whole memory upfront (loading mode full), statements below 0.3 are
not put in; rules always are. You see the weight in /pum and in
the browser.
Conflicts
Two statements that contradict each other form a conflict. Nemocode opens one when its checking model finds a contradiction between two statements that say similar things, and when a statement about a piece of code loses its anchor because that code changed or vanished (if Nemocode can find the code again in exactly one other place, it moves the anchor by itself instead). You decide at the gate or in the browser: keep the first or keep the second retires the other statement in favour of the one you keep; dismiss says it is no conflict and both stay. A conflict about a connection to code can only be dismissed. While a conflict is open it lowers the weight of the statement it was raised against; deciding it lifts that again.
Two kinds of knowledge
| Kind | Where it comes from |
|---|---|
| Derived | Read out of the code itself: which files and which classes, functions and methods live where, what a file contains, and which files import which (for Python, TypeScript, TSX and JavaScript; other languages contribute files and symbols, but no import connections). It is a map of files and symbols with “contains” and “imports” connections, not a call graph. Nemocode keeps it current and does not ask you about it. Who calls whom is not stored: the language servers answer that live when the agent asks. |
| Asserted | Decisions, constraints, statements about the project. This is what goes through the gate. |
The code index covers more than thirty languages — among them Python,
TypeScript, TSX, JavaScript, HTML, Swift, Rust, Java, Kotlin, C#, Go, C, C++,
Ruby, PHP, Scala, Dart, Lua, Haskell and Elixir. It reads up to 500 files, skips
files over 400 KB and folders such as node_modules, dist,
build, target, coverage, virtual
environments and every folder whose name starts with a dot (so .git
and Nemocode's own folder). The language servers — for Python, TypeScript and
JavaScript, Go and Rust — are separate programs that Nemocode only starts: the
installer sets up the Python and TypeScript/JavaScript ones, while Go and Rust
need their own toolchain and server on your machine. Nemocode rebuilds the index by itself when it is out of date at the start of
a mission; /index rebuilds the derived part on demand.
What belongs in there
| Yes | No |
|---|---|
| Decisions and the reason for them | Anything you can read off the code in ten seconds |
| Constraints the project has to respect | Runtime data, user data, temporary state |
| What a spec, ticket or doc demands | A wish nobody agreed to |
| Why an obvious approach was rejected | Narration of what happened in one session |
You can write the rules for your project down yourself — see project rules.
Getting it back out
You rarely have to do anything: Nemocode pulls what a mission needs by itself. Beyond that:
| Command | What you get |
|---|---|
/pum | Browse it — the network, an overview, nodes, connections and conflicts (Tab or the keys 1 to 5 switch). v lets you open it in the browser. |
/areas | Choose which topics this session gets preloaded. Everything else stays reachable on request. |
/curator | Ask it questions, and let it argue with you about what should be in there. |
/pum-folders | Choose which folders feed the memory. |
The whole memory is also a page in your browser, where you can edit it by hand — see The memory in the browser. To share it with colleagues, see Sharing with a team; to use it from another coding agent, see Other coding agents.
Filling it
| Command | What it does |
|---|---|
/learn | Learn now: rebuild the code index, process what the agent noted during missions and has not been filed yet, and — only if the memory is still empty — seed it from the project's README and docs. |
/bootstrap | Seed from the README and the project's markdown files (up to eight) and its largest source files (up to eight), with at most twelve new facts at a time. For a project Nemocode has not worked on yet. The result lands at the gate. |
/index | Only the code index: symbols and structure. No proposals. |
/re-pum | Embed the whole memory again with the embedding model you have selected now. It asks before it starts, because it takes a while. |
/harvest | Let the curator harvest this session now. See The harvest session. |
Which folders feed it
By default the whole project feeds the memory. In a repository where only part
of the code matters — or where a folder holds generated files — tick the folders
that should count: /pum-folders, the Folders tab at the gate
(Space ticks, o opens and
closes a folder), or the Folders tab in the browser. Only folders the agent has
access to can be ticked. A ticked folder includes its subfolders. Only those
are indexed and harvested from then on. Unticking a folder keeps what the memory
already learned from it; it just stops learning there, and facts you or the
agent state outright are never filtered. Ticking none goes back to the whole
project. After adding folders, harvest new (h
in the gate's Folders tab, harvest now in the browser) reads exactly
the new ones.
The settings that shape it
| Setting | What it decides |
|---|---|
| PUM loading | map (the default) gives the mission an
overview and it pulls the detail it needs; full puts everything in
upfront. Map is cheaper and usually enough. Set globally under
/config ▸ General; a project can override it in the Project
tab. |
| PUM harvest | The source of new facts: agent (the default), curator, both or off. The curator's harvest is described under The harvest session. |
| Harvest trigger | automatic (the default): the curator
harvests every finished mission. manual: missions wait until you
type /harvest. |
| remember tool | Whether the agent can note something down mid-mission with a tool. Off by default: it then writes knowledge into its answer instead, which costs no extra round. Switch it on for models that do not follow that form. |
skill_review (Learn skills from missions) | On by
default. After a long mission (ten tool calls or more) the curator may write
a reusable procedure into ~/.nemocode/skills (for every project) or into the project's own skills folder (for this project only), or improve one it
wrote earlier. It happens in the harvest session, so you can read it, and
the files are yours: delete one, or move it into .archive/.
Switch it off and nothing is ever written. Environment:
NEMOCODE_SKILL_REVIEW. |
| Embedding model | Which model finds related facts. The default
ships with Nemocode and runs on your machine; a bigger one finds more and costs
more memory. Without any embedding the memory falls back to searching by
words. After changing it, run /re-pum. |
Documents
What your documents say can be remembered too — a spec, a ticket, your own
task description. Nemocode has no separate import for documents. Two routes fill
the memory from them: /bootstrap reads the project's README and
markdown files (and its largest source files), and during a mission the agent notes what a document demands and
the harvest proposes it at the end. Either way it goes through the gate.