<div align="center">

lore

An independent code reviewer that remembers your codebase between sessions

Reviews are the mechanism. The memory is the product.

</div>

---

Every AI coding session starts amnesiac. It rediscovers the same conventions, re-raises the same settled questions, and repeats the same mistake you corrected last week.

lore is the memory. It reviews a branch before it merges — with models that did not write the code — and everything it learns doing so becomes a fact the next session already knows.

<div align="center">

| | | |:--|:--| | 🧠 | It remembers. 544 live facts about six codebases, each with provenance and an expiry | | 🔍 | It disagrees with you. 3,890 findings raised; 215 of your justifications rejected | | 🚫 | It never bluffs. A review that did not run is never reported as one that found nothing | | 🔒 | It is not your author. Every tier is a non-Anthropic model, enforced by absence |

</div>

---

What a finding actually looks like

Not a nit about naming. This one is from lore reviewing its own commit, this morning:

e8d3f8a3 · medium · src/core/memory.ts:61

Claim. SPEC D-151 says an unparseable LORE_MIN_AVAILABLE_MB "refuses to start rather than falling back to the default", but nothing validates it at boot: floorBytes() throws lazily inside review_start and inside checkHealth. The startup-validation idiom for exactly this knob class exists 60 lines away and was not used.

Failure scenario. Operator sets LORE_MIN_AVAILABLE_MB=2g — the SPEC's own example — and runs make up: the container starts green and answers /healthz 200, so the operator believes the value was accepted. In fact every review_start fails with an error shown only to client agents, /status answers 500, and the beat's only signal is deadman silence. The monitor dies on the misconfiguration instead of reporting it.

Asks. Fix this, or tell me why it is not a problem. Both are real answers, and I may be wrong.

It read a sentence in a spec, checked it against the code, found the code narrower than the claim, and traced what an operator would believe as a result. That is the class of defect this is built to catch — a false statement about a failure, which is what nearly every real bug in this repository has turned out to be.

---

The idea that makes it work

When a reviewer raises something you believe is wrong, you do not argue in a comment thread. You write the reason in the code:

// lore-ok[a1b2c3d4]: bounded by the caller's schema check at api/route.ts:31,
// so a negative amount cannot reach here.
export function capture(amount: number) { … }

That is proposing a piece of lore. The reviewer ratifies it — and your reason becomes something the codebase knows about itself — or rejects it, and the finding returns at higher severity, because a wrong justification is worse than a bug.

flowchart LR
    F["finding raised"] --> J["you answer:<br/>fix it, or justify it"]
    J -->|"fix"| V["reviewer re-reads<br/>the corrected tree"]
    J -->|"lore-ok"| R{"reviewer<br/>rules on it"}
    R -->|"ratified"| K["it becomes<br/>shared memory"]
    R -->|"rejected"| H["returns,<br/>higher severity"]
    K --> E["the code moves,<br/>the reason expires,<br/>the finding comes back"]

The author never closes its own finding. That single rule is what keeps the loop honest: it terminates when the code is correct, not when the author gets persuasive.

And a justification expires. It was a claim about specific code; when that code changes the reason may no longer hold. Live proof: 8,088 of this deployment's knowledge rows have been retired as their sources moved, against 544 still standing. Without that, a design like this rots into rubber-stamping within months.

---

The ladder

Deterministic tooling first — a model should never be paid to decide what a typechecker decides for free. Then progressively dearer models, each seeing only code the previous tier already passed.

| tier | engine | vendor | paid by | |:--|:--|:--|:--| | T0 | the repo's own tsc · eslint · cargo check/clippy · ast-grep · semgrep | — | free | | T1 | GLM-5.3 | Z.ai | subscription | | T2 | Kimi K3 | Moonshot | subscription | | T3 | GPT-5.6 Sol | OpenAI | subscription |

Three tiers, three vendors — two tiers from one model family share blind spots and are not two independent opinions.

flowchart TD
    T0["T0 — tsc, eslint, semgrep, ast-grep<br/>free, deterministic"] --> T1["T1 — GLM-5.3"]
    T1 -->|"findings"| FIX["you fix, or justify"]
    FIX -->|"a fix is unreviewed code"| T0
    T1 -->|"clean"| DEEP["T2 — Kimi K3 &nbsp; + &nbsp; T3 — GPT-5.6 Sol<br/>run together, different vendors"]
    DEEP -->|"findings"| FIX
    DEEP -->|"all agree"| P["passed<br/>one signed line saying what was checked"]

Every reviewer is a model that did not write the code. That rules out the strongest model on the board on purpose: a model reviewing its own output confirms the design it already had in mind. It is enforced by absence — no Anthropic credential is ever deployed to the reviewer.

One paid route exists and it is off by default. When a subscription hits its billing-cycle limit the chain can reach the same model through OpenRouter, which bills per call. The measured difference on this deployment is stark:

| route | calls | cost | |:--|--:|--:| | subscriptions | 4,458 | $0 | | metered fallback | 93 | $230.53 |

LORE_ALLOW_METERED (default 0) decides whether lore may walk onto one. At 0 the tier is skipped and named in checks_skipped — a weaker review said out loud, rather than a bill nobody chose.

---

What it has actually done

Measured on the live deployment, 2026-09-17, from the database rather than from memory:

<div align="center">

| | | | | |--:|:--|--:|:--| | 609 | reviews, over 5 weeks | 341 | reached a clean verdict | | 3,890 | findings raised | 786 | of them high severity | | 2,394 | findings fixed | 215 | justifications rejected | | 544 | live facts remembered | 8,088 | retired as the code moved | | 4,551 | model calls | 14.1B | tokens | | 6 | codebases | 4.1 | rounds per review |

</div>

54 of those reviews were lore reviewing lore. Most of what it has found, it found in itself — and the shape of those findings is the reason the project has the shape it does:

Nearly every real defect was a false statement about a failure, not a wrong algorithm — a review that timed out and reported clean, a cap that discarded a round someone paid for, a status command that guessed at why it had no status, a paste-able config that could never have been pasted. The ladder logic, the fingerprinting and the VEX mapping all worked first time. MEMO.md has every one of them, including the retractions.

---

What you get, concretely

| you do | lore does | you get | |:--|:--|:--| | push a branch and ask for a review | runs your own tsc, ESLint, semgrep, ast-grep, then up to three models from three vendors | findings with a failure scenario, not style notes | | fix, or write a lore-ok[…] reason | re-reads the corrected tree; rules on your reason | the reason becomes shared memory, or comes back at higher severity | | merge | signs one line naming the tree, the tiers, the vendors and the verdict | an attestation: what was checked, never "the code is correct" | | start tomorrow's session, amnesiac | hands the reviewers what this repository already taught it | a review that does not re-raise what you settled last week |

---

Use it

1. Try it on a laptop, with no service at all

npm ci
node ./src/index.ts review \
  --branch feat/holds --into main \
  --ticket "Release the hold when a capture declines"

Exit codes are the API, because the caller is usually a program:

| code | meaning | |:--|:--| | 0 | passed — cleared by the full ladder: every tier ran, each a distinct vendor | | 3 | passed_thin_ladder — cleared, on a thinner ladder: a tier above the highest that ran never looked, or fewer vendors read the code than tiers ran | | 1 | findings — fix or justify, then run again | | 70 | did not run — never confuse with "found nothing" | | 75 | quota exhausted — also not a pass |

0 and 3 are both successes, and 3 is the ordinary one here — 287 of 341 clean verdicts. A script treating 3 as failure blocks on nearly every clean review; one treating it as 0 loses the distinction the ladder exists to make. Choose deliberately.

2. Run it for your whole team

One deployment on one box serves every engineer. That is the intended shape rather than a scaling story bolted on afterwards: knowledge is per repository and shared by everybody who works on it (D-18, D-19), so what your colleague's review established on Monday is what your agent is handed on Thursday.

<!-- lore-ok[44763525]: the openai2 provider is staged by deploy/sync-opencode.sh whenever an account #2 login exists -->

# on the company server, once
cd deploy
cp .env.example .env          # three subscriptions by default, or one metered key
brew install opencode         # opencode 2.x; the container runs this same version
opencode auth login           # once per provider; the logins are pushed in by `make up`
make up                       # stages config, builds, starts, syncs credentials

# after re-logging a provider on the host
make sync-creds

# optional: a second ChatGPT subscription as `openai2` (D-157), renewed daily.
# The login is all it takes: it stages the provider and syncs the credential.
make login-openai2
make renew-daemon

# one line per engineer, per repository
make new NAME=alice GIT=git@github.com:acme/payments.git
make new NAME=bob   GIT=git@github.com:acme/payments.git
make new NAME=carol GIT=git@github.com:acme/console.git

# keep the mirrors fresh, so nobody has to remember
make mirror REPO=payments
make mirror-daemon

Each make new prints a revocable bearer token and the exact .mcp.json block to paste into that person's Claude Code, Cursor, or any other MCP client. Nothing else is installed on their machine, and nothing is installed per project.

| property | how it works | |:--|:--| | isolation | a token reaches exactly one repository; one engineer cannot poll, submit to or attest another's review (D-78) | | sharing | knowledge is per repository and shared by every session and teammate working on it | | capacity | a claimed round starts immediately — no worker queue — and the service refuses politely at 128 open reviews | | revocation | make tokens lists them by hash; make revoke TOKEN=<prefix> turns one off. The secret is shown once, and revoking never needs it back | | perimeter | LORE_BIND defaults to loopback. Put it on your tailnet, or bind it to the LAN deliberately — on a LAN, the tokens are the perimeter | | cost | flat subscriptions, one set for the whole team: 4,458 of this deployment's 4,551 calls billed nothing beyond them |

lore never talks to a remote and holds no git credentials. The mir