Self-Checks

A Self-check is a quick review of a handful of files against the project’s policies, run before anything is pushed. It tells a developer, or their coding agent, what the merge gate would say, in seconds, while the change is still on their machine. Not every check is a scan. A Self-check creates no findings, doesn’t change the project’s posture (its overall status on the Dashboard), and leaves the Dashboard exactly as it was. It’s advice for the person making the change, not a record of the project. Before you start: Self-checks are produced by two tools, so you need one of them set up:

• the Earnie pre-commit hook, or
• a coding agent connected to Earnie MCP, either with review hooks from earnie mcp setup, or calling the earnie_review_code tool itself.

​

When a Self-Check Runs

A Self-check runs when:

• a coding agent finishes a turn and calls its review tool, or
• the pre-commit hook runs before a commit lands.

Earnie reviews only the files it was handed, a slice of the codebase, against the project’s policies.

​

Finding a Self-Check

Self-checks are listed under Self-checks in a project’s sidebar, next to Scan history, and never inside it.

• Search matches a policy name, a detection’s file path, or its summary.
• Gate narrows the list to one verdict.
• Producer narrows the list to one source.
• A status toggle narrows the list to Running, Completed, or Failed.

Four columns matter:

​

Reading a Self-Check

Open a run to see its detail:

• Verdict — states the gate in one sentence.
• Violations — one entry for each policy the files broke. Each entry names the policy at the revision that was evaluated, and lists the detections that triggered it: a file and line, the kind of detection, and what was seen. Where Earnie can work one out, the entry also offers a remediation: a short summary and a prompt written for a coding agent. Copy prompt copies that prompt to your clipboard exactly as written.

Detections are not findings. They’re kept only for the life of the Self-check, and they never enter the Review queue.

​

Why a Pass Isn’t a Clean Bill of Health

A Self-check only ever sees a slice of the codebase, so some policies can’t be answered from it. The Not evaluated list shows each of these, with the reason. For example:

• an enrichment that didn’t complete
• an expression that couldn’t be evaluated
• a policy whose inputs none of the submitted files carried

The Verdict card repeats the count. A Pass above that list means nothing Earnie reviewed violated a policy. It doesn’t mean the change is clear of everything the project enforces. For the same reason, a Self-check’s coverage is always Partial. An inline check reviews the files it was given, never the whole codebase, and a partial run can never mark anything absent. See Coverage: Full vs Partial.

​

The Self-Check Trail

Below the Not evaluated list, a Trail section shows the run’s own history:

• Submitted — how many files it was given, and when the run expires.
• Completed — the gate, the coverage, how many policies were evaluated, and the violation and detection counts.
• Failed — for a run whose scanner never produced a verdict, the error code and message.

​

What’s Next

Self-checks and the merge gate keep problems out of your code. The next step is producing evidence of what your code contains for people outside your team: exporting an SBOM.