Every project starts with an idea of how its parts fit together. This part may use that one. That folder knows nothing about this one. Usually the idea lives in somebody’s head, or in a document nobody opens twice.
trueup lets you write that idea down in one small file. After that it reads your code and tells you, in plain words, whether the idea is still true.
A linter reads one file at a time and tells you about that file. A variable nobody uses. A keyword you forgot. It is looking at the code inside a file.
trueup looks at the lines between files. Which parts of your project are allowed to know about which other parts. Where a file should live. Whether a folder has quietly turned into a junk drawer.
None of that can be seen from inside any single file. That is why the shape of a project drifts for months and nobody notices.
A coding agent is an assistant that writes code in your project. Every edit it makes looks reasonable on its own. Reaching into another part of the project is the shortest road to a working feature, the tests stay green, and nobody objects. After a hundred edits like that, the project has a shape nobody chose.
You cannot read your way out of that. Not reading every line is the reason you asked for help in the first place.
So the rules have to sit where the agent meets them, every time, with nobody watching. And because an agent under pressure to make the build pass will widen a rule as readily as fix the code, every message here says which of the two we mean.
Sees through re-exports
Most projects have one file that gathers up a folder and passes it along. Other tools then see everybody importing that same file and cannot tell any of them apart. trueup follows the chain to the file where the thing you asked for is actually written.
Refuses a bad edit
Run it as a hook in Claude Code and it inspects a change before the change is saved. The agent gets the reason back and corrects itself in the same turn, without a trip through you.
Fails loudly
An import that leads nowhere. A rule that matches no file. A file no rule covers. Each of those is an error here, because a check that passes while checking nothing is worse than no check at all.
One report
Findings from the linter you already use arrive in the same report, under the same pass or fail.
It helps most when you have a TypeScript project that more than one person or one agent works on, and you have an opinion about how that project should be arranged.
It helps least when the whole project still fits in your head, or when you have not made up your mind about the arrangement yet. In that case there is nothing to hold the code to, and you would only be writing down a guess.
New here? Getting started sets it up on an ordinary project in about ten minutes.