Decide if a change is safe to ship

openthunder can-i-ship turns "does this feel okay?" into one defensible decision, backed by evidence you can read. This guide explains how to run it, how to read the three verdicts, and how to gate merges on it.

Run it

With your change in the working tree (staged, unstaged, or committed on a branch):

openthunder can-i-ship

It is keyless and local , no AI key, nothing uploaded , and it caches on git state, so re-running on an unchanged tree is instant.

Read the verdict

You get one of three outcomes, each with file:line evidence behind it:

Verdict	Means	Do
SHIP	Low structural risk, checks pass, no high-severity findings in the diff	Merge with a normal review
CAUTION	It can go, but something needs eyes: a hub/fragile file, a high finding, or thin verification	Review the flagged files first, then decide
HOLD	Do not ship yet: failing checks, a critical finding, secrets, or an unauthenticated protected route	Fix the blocker; re-run

The verdict is never a bare label. It names why: which files drove the risk, what the blast radius is, and which findings or missing checks pushed it up or down.

What goes into it

Verification , the repo's own checks (typecheck, tests, lint, build) and their real results. Missing checks count as missing evidence, not as safety.
Blast radius , how far the change can reach across the architecture; the same change is riskier in a file everything depends on.
Findings , security and structural issues in or reachable from the diff.
Confidence and provenance , every input is labeled by source, so an AI-inference never outweighs a verified fact. See Evidence Packs and provenance.

Keep the receipt

openthunder evidence        # the Evidence Pack behind this verdict
openthunder pr-evidence     # a pull-request-ready pack

Attach it to the PR so reviewers see what was checked, not just a green check.

Gate CI on it

Run openthunder can-i-ship in CI and fail the job on HOLD. Pair it with openthunder security check, which fails on new critical findings, secrets, or unauthenticated protected routes. OpenThunder ships as a GitHub Action, a GitLab component, and an Azure DevOps task, so the same verdict blocks merges everywhere.

For risky work, use a mission

For auth, billing, database migrations, or security changes, a single verdict is not enough , run the change as a mission so an independent reviewer challenges it and its checks run before it is accepted. The mission's result is a diff plus an Evidence Pack, not just a diff. Create one with openthunder mission or the app.

Verify an AI-generated change before you commit , the full pre-commit loop.
Evidence Packs and provenance , what backs the verdict.
CLI reference , every command and option.