How it works
Your agent writes the code. ShipSure checks the result against your project — not against another AI's opinion.
The loop
baseline records the state of your project before the agent touches it. verify runs afterwards and compares. That comparison is what turns “the tests pass” into “the tests that passed before still pass”, which is a different and far more useful claim.
What gets checked
Runs your project's own test command. Where the runner emits machine-readable output, individual test names are captured so a regression can be named rather than counted.
Confirms the project still builds. Compiling is not optional.
Runs tsc --noEmit or the equivalent for your stack, and reports new type errors.
Flags lint errors introduced by the change.
Compares against the baseline and names tests and checks that used to pass and now fail. This is the difference between 'new code works' and 'the agent did not break anything'.
Compares files the agent touched against what the task said it would touch. You asked for password reset; it also edited the payment module — you see that immediately.
Detects packages added, removed or upgraded during the run, so a new transitive dependency does not arrive unnoticed.
Files and folders you mark as sensitive — payments, auth, production config — are flagged or blocked when touched.
Your own rules, enforced every run rather than remembered in a prompt: no new dependencies, no schema edits, no production config changes.
Reads commits, modified and untracked files to establish what actually changed, and refuses to baseline a dirty tree without --force.
The verdict
Every run resolves to one of five states, and the CLI exits with a distinct code for each so a pipeline can act on it:
| Verdict | Exit | Meaning |
|---|---|---|
| Verified | 0 | Every required check passed. |
| Failed | 1 | A required check failed. |
| Blocked | 2 | A policy or approval gate stopped it. |
| Inconclusive | 3 | Could not verify reliably — say, no usable baseline. |
| Cancelled | 4 | Stopped before it finished. |
Inconclusive is not a failure and not a pass. Most tools would round it to one or the other. Reporting it honestly is the point — a run that could not be checked has not been checked.
Evidence, not opinion
ShipSure does not ask another model whether the work looks right. Every verdict rests on what your repository, your tests and your build actually did. The dashboard keeps the evidence — per-check status, durations, the exact commands run, the failing test names — so a result can be re-read later and reproduced locally.
The server also re-derives the verdict from the checks the CLI uploaded. If a client reports verified while carrying a failing check, the run is recorded as failed and flagged as a mismatch. We do not trust the client’s summary either.
Where it runs
On your machine. The CLI executes your project’s own commands in a child process with an explicit environment allowlist, hard timeouts, and secret redaction before anything leaves. Your source code is never uploaded — file paths and statistics are, so the dashboard can show what changed.
It works on a plain local folder. Git sharpens regression detection because there is a commit to compare against, but a hosted repository is not required, and the same binary runs in CI.
Not built yet
Named here rather than described as though they work. The full list is in the docs.
- Watch mode — auto-verifying when the filesystem goes quiet. Today you run
verifyyourself. - Approval gates — the blocked verdict exists in the engine; there is no screen to approve or reject one.
- Git host integrations — no PR status checks yet. CI works via the CLI and its exit codes.