Checkup

Every agent turn is checked as it happens: it has to compile and build before it is kept. But fifty green turns still add up to a system nobody has read as a whole. A checkup is that look at the whole thing, on demand or at a gate.

The Checkup page appears in your project from the Build stage; before that there is no built system to check. It has one status bar at the top, one Run checkup button, and one checklist below it in three groups: Setup, Code and Security.

The status bar gives one verdict across the whole list: red when something blocks Live or setup is broken, amber when something needs a look, green when everything is clear. Each row of the checklist is one check, and what it found is listed right under it — nothing is folded away. Run checkup re-checks the whole list.

Code and Security say how fresh their answers are: Code names the version the last checkup checked and when, and Security’s scans run on a schedule. Setup is re-checked every time you open the page, so it is always current. Earlier checkups stay on record; open one from Past checkups in the page’s ⋯ menu.

Setup

Setup answers a narrow question: did Sapilon set your project up correctly? As a project moves through its stages, Sapilon creates things for it — the project files, the backend app, the project’s database, the wiring between them. Each is made by a step that can occasionally fail half-way, leaving a project that says it is in Build while a piece of it is missing.

Setup checks each of those pieces every time you open the page and with every checkup. When something is wrong, its row says what, and a Fix button re-runs the exact step that should have created it — the same step a healthy project went through, so fixing can never leave you with something different. Fix all repairs everything that can be repaired at once. A few problems have no automatic repair; for those, the row says what it found, and you can raise a support request from Requests if it persists.

A checkup can’t pass while a setup check fails, so the status bar leads with setup when one does. Every checkup also records the setup checks, so Live can refuse a version shipped from a broken setup; what it recorded shows under the setup row it is about.

Code: what a checkup checks

Two kinds of check run against the same version of your code:

• Scripted checks — deterministic and cheap: the project builds, types are sound, the linter is clean, static analysis finds nothing, the test suite passes, no credentials were committed, dependencies carry no known vulnerabilities, and migrations are consistent with the schema.
• AI review passes — the same model in a reading posture rather than a writing one, with read-only access to the code and the project’s own conventions as its rubric. These are the passes that catch what scripts cannot: a page that has grown too big to maintain, an endpoint missing an authorization check, an obvious performance trap.

Static analysis is the one worth naming. It runs SonarSource’s rules — the industry’s catalogue of code that reads correctly and does something else: both branches of a decision doing the same thing, a list that is always empty, a password written into the source. It needs nothing set up, uses no AI, and runs at every depth.

Findings, and the four ways to close one

Whatever a check finds becomes a finding, listed under that check’s row with what it is and where. Open one to see what the check found; each closes in one of four ways:

• Fix with Agent — hand it straight back to the agent. It waits above the composer on a fresh session, so you pick the mode before anything runs.
• Turn it into a task — worth doing, not worth blocking on. It joins the queue instead of being forgotten.
• Waive it with a reason — you have judged it acceptable. The reason is recorded.
• Forward it to an expert — a Sapilon specialist picks it up from a written report rather than a cold codebase. See expert work pricing.

Nothing disappears silently: a finding is either fixed, queued, waived on the record, or escalated. A waived finding stays waived in later runs for as long as it stays the same.

Checkups and the gates

A checkup runs automatically when you promote: advisory before Rehearsal, enforcing before Live. Live needs a passing checkup of the exact version being shipped, so a checkup of last week’s code does not clear today’s.

Findings from the checks that guard Live — a broken build, a committed secret, a security problem — are marked Blocks Live and listed first under their check, and the status bar says how many stand between the checked version and Live. It also says when the project has moved on since the last checkup, because that checkup no longer covers what would ship.

That is the reason to run one yourself during Build rather than meeting it at the gate. Findings are cheapest when the system is still changing, and the gate is a bad time to discover a week of work.

A checkup judges the project, not your draft

A run reads the project — the code Rehearsal and Live run — not your working draft. So the first step of a checkup confirms adding any changes still in your draft to the project; if there are none, nothing changes. What gets checked is what would get shipped.

When you start one you also pick its depth: Quick runs the scripted checks only, Standard adds an AI review of the files changed since the last checkup, and Deep has the AI read the whole project. A routine check-in rarely needs Deep; a first Live release deserves it.

Security

The Security group shows how the app is protected, one row per check: the last checkup’s security review, the latest security scan and any open advisories, the web application firewall and security headers that protect the deployed app, and how people sign in. Scans run by themselves once the app is on Rehearsal; until then, each checkup scans dependencies and secrets. How Sapilon keeps your app secure covers what each row means.

Next: Automated Tests · Security · Promoting between stages