Lintorn

Audits your code and the memory your AI assistant reads — and tells you when the two drift apart.

Coding assistants read your project documentation: CLAUDE.md, architecture notes, persistent memory files. That documentation is written once and then quietly rots. The assistant keeps reading it, keeps trusting it, and keeps acting on rules that no longer match the code.

Lintorn checks both sides. It runs the usual quality tools over your codebase, and it verifies that every path, rule and claim in your AI-facing documentation still corresponds to something real. When they disagree, it says so.

$ pip install lintorn
$ cd your-project
$ lintorn --init
$ lintorn

=== Lintorn - RAPPORT AUDIT ===
[ OK ] Ruff (lint Python)          rien a signaler
[ !! ] Doc vs code                 124 chemin(s) cite(s), 12 introuvable(s)
[ ?? ] Memoire IA vs code          46 chemin(s) cite(s), 3 a verifier
[ OK ] Hook pre-push               branche et executable

Read this before installing

Lintorn speaks French. Its console output, its report, its --guide manual and the comments in the config it generates are all in French, as you can see above. That is a deliberate choice, not an oversight — but you should know it before installing rather than after. The full documentation is in French too: README.fr.md.

It is also experimental, and not stable at 100%. Concretely:

• it is updated often, to fix defects found along the way — some of them found by Lintorn auditing itself;
• it has been tried on a handful of projects only (Django + React, FastAPI, a Go project, a folder with no source code at all). On a layout it has not seen, detection can misfire;
• the configuration format still moves. It will be frozen at 1.0, not before.

Nothing is being sold here. It is a tool written for my own use, published because it may help developers like me. If detection goes wrong on your project, that is useful information — please open an issue.

The idea it is built around

A check that goes quiet is more dangerous than a check that goes red.

A red check gets fixed. A check that silently stops working leaves you feeling covered while nothing is being watched. Lintorn treats that as the primary failure mode, everywhere:

• a tool that is not installed reports as unavailable — never as "0 problems found";
• a rule whose target directory does not exist is dropped, not reported as passing;
• a rule that read no file at all says so, instead of counting as upheld;
• its own git hook is checked down to the executable bit — git ignores a non-executable hook in complete silence, which is exactly how this project lost its guard for four days.

What it checks

Everything is auto-detected. No Django? The Django checks do not appear at all — rather than sitting there permanently "unavailable", which is how a warning light becomes furniture.

Lintorn is written in Python; it does not require your project to be. The checks that make it unusual are language-agnostic and work on any repository. Anything else plugs in through [[commandes]]: phpstan, eslint, go vet, cargo clippy.

An AI assistant makes setup much faster

Lintorn contains no LLM and never calls one. That is what keeps it free, offline, key-less, and able to run inside a git hook with any Python on the machine.

It is, however, built for the loop where an assistant reads its output — and setting it up on a project is where an agent saves the most time. It reads your code and your CLAUDE.md, writes the config, and drafts the patterns for your house rules: the one thing Lintorn cannot guess, because a house rule is a decision, not a property of the code. From then on the assistant corrects itself against the report as your rules land.

Not a requirement. Without one, Lintorn works exactly the same — you write the config yourself, and lintorn --init and lintorn --esquisser-regles prepare the ground.

Safe by default

The first run cannot damage anything. Lintorn does not modify your files, does not reach the network, and does not execute your project's code unless you ask. Those are opt-in.

Lintorn itself has zero dependencies, deliberately, so it can run inside a git hook with any Python on the machine. The tools it calls belong to the project being audited, so that ruff applies your rules and pytest sees your dependencies.

Prefer pipx install lintorn for a machine-wide install. pip cannot warn you at install time — a wheel is unpacked, never executed, so there is no hook to run and no way to ask a question. The Python du projet (venv) check is what tells you afterwards which interpreter actually did the auditing.

Commands

lintorn                      full audit
lintorn --rapide             skip the slow tools (what the pre-push hook runs)
lintorn --init               generate the config for this project
lintorn --esquisser-regles   draft a [[regles]] block per uncovered rule
lintorn --installer-hook     install the pre-push hook
lintorn --installer-outils   install the external tools, after confirmation
lintorn --doc                documentation check only
lintorn --guide              the one-page manual: what it is for, how to read a report
lintorn --maj-securite       what pip-audit suggests (dry run)

Requires Python 3.11+.

Configuration, house rules, excluding tutorials and changelogs, choosing the interpreter, running without a git repository — all of it is documented in README.fr.md.

License

AGPL-3.0. Use, modify and share it freely. If you distribute it — or offer it as a network service — you must release your source under the same license.

That is deliberate: Lintorn is given away, and this license stops anyone from closing it up and reselling it. Copyright holder: Olotorn. For a commercial license exempting you from the source-disclosure requirement, get in touch.

Contributing

Not open to outside code contributions yet — bug reports and ideas are welcome, and they are what helps most at this stage. When it opens, contributions will require a CLA, so that dual licensing remains possible. Details in CONTRIBUTING.md.