See your intent coverage — Noea Code documentation

How much of this software do you actually have a grip on? Intent coverage answers with one picture: one square per code file, laid out by module, and the darker the square, the more of its lines your explanations cite. What is still blank and which explanations are out of date show at a glance. Point at an intent and the files it covers light up.

Open intent coverage

Start a new chat: before you send the first message, the chat area shows the Intent coverage card. You can also open Settings → Intent coverage (in the current project's group), where the card fills the page, which helps with large projects.

Intent coverage needs the Implementation folder to be a Git repository. Until the project has a coverage result, the card says “Not computed yet” and offers two ways in: “Explain” has the Agent write explanations first, and “Compute now” computes coverage from the explanations you already have. Large repositories mean reading every file, so it can take a while.

After that, the card updates every time Explain finishes. The right of its title line shows when the last Explain ended and the commit at that time, with a button to compute again.

Read the card

At the top of the card is a large number: the share of all code lines in scope that explanations cite. Beside it, “3 / 6 files” is how many files have intent behind them out of the total.

The Intent coverage card: 68% of code lines are cited by explanations, and 41 of 60 files have intent behind them. The modules area lays out a dot per file by folder, with each Intent Document listed below.

The bar below it has three parts, with a legend underneath:

Referenced lines: the solid part, as long as the percentage.
Explanation outdated: the hatched part, files changed after their explanations were written.
No intent: the empty part, files no explanation cites.

By module

The “Modules” area shows dots by default: one dot per file, one row per folder. Files with intent behind them get darker the more of their lines are cited; files whose explanations are out of date are hatched; files with no intent are empty. Point at a dot to see the file name and how much of it is cited.

The switch at the top right turns the dots into bars: one row per module, as long as its line count, divided into the three states.

Click a module to go one level down; a back button and the path appear in the title line. In the subscription service, for instance, the rows for billing, jobs, notify and web sit side by side, and the notify row is almost empty: the rules for notification emails haven't been written into intent yet.

By intent

Under the modules is the list of intents, one row per Intent Document, indented like the document tree, with a short line showing how many files it maps to. A document with no code behind it yet is greyed out with an empty line.

Point at a document: rows in the modules area that have nothing to do with it fade, and the layout stays put.
Click a document: unrelated rows fold away, the bar and dots show only the code this intent maps to, and a chip with the document's name and a × appears under the modules heading.
Click it again, click the chip's ×, or press Esc to clear it.

Click Renewal, for instance, and only billing/grace.ts, jobs/renewal-job.ts and a few test files remain. You see at once what a change to the renewal rules will touch.

What the number means

Coverage measures how much code your explanations cite. It isn't code quality, and it isn't test coverage. It helps you answer two questions:

Where is there no intent yet? A blank module is either code that doesn't matter much, or rules already running that you haven't thought through. The latter deserve a paragraph of intent and an Explain.
Where are explanations out of date? Heavy hatching means recent changes the explanations haven't caught up with; see When the code changes.

There's no need to chase 100%. Start with the parts you care about most and let those darken first.

Parnas Index

Settings → Parnas Index looks at the same thing from the other side: how far code changes reach into your intent. The name comes from David Parnas's principle of module decomposition: a good module hides a decision that is likely to change. In Noea, a passage of intent stands for a decision and a code file for a module.

The large number at the top is how many passages of intent are rechecked, on average, per file changed, with how many were fully checked and how many of those didn't change. The higher it is, the more decisions a single change pulls in. The time window can be 7, 30 or 90 days.

The page has two views:

View	Levels	Columns
Code → intents	Files, Definitions	Intents reached, Changes, Per change, No change
Intents ← code	Documents, Passages	Files cited, Code changes, Intent changes, No change

Click a row to open it in place. A file row shows how much of it explanations cite, the intents it reaches most, and “View in Intent coverage”; an intent row shows how many files it cites, the code that reaches it most, and a way to open that passage.

Under the file level of the first view is a “Coverage and reach” scatter plot: across, the share of lines cited by explanations; up, how many passages of intent each change reaches. Files at the top right are densely cited and often changed, so every change means rechecking a lot of intent; they may be worth splitting. Higher coverage isn't always better.

If the project has no Implementation folder linked yet, both pages ask you to link one in Settings → Project first.