Oneport — the pre-ship gate

One command runs every Oneport check across your repo and tells you, in one verdict, whether it's safe to ship.

onp ship orchestrates the whole Oneport tool suite — secret scanning, dependency vulnerabilities, migration safety, code review, API breaking changes, test gaps, and more — into a single ship-readiness verdict with a single exit code for CI.

It doesn't reimplement the tools. It runs each independent Oneport CLI, merges their findings by severity, and answers the only question that matters before a deploy: is this safe to ship, and if not, what do I fix first?

$ onp ship

Ship readiness: BLOCKED — 2 blocker(s), 3 warning(s)

MUST FIX before shipping
  ✗ [secrets]  AWS Access Key ID  config.py:12
      fix: Deactivate the key in IAM, rotate it, purge git history.
  ✗ [migrate]  Drops a column with no reverse migration  0042_auto.py:8

SHOULD FIX
  ⚠ [depcheck] requests 2.19 — CVE reachable in fetch.py:42
  ⚠ [review]   SQL injection risk  users.py:8

✓ apidiff  ✓ testgap

→ Fix the 2 blocker(s), then run onp ship again.

Install

pip install oneport          # the orchestrator (this package)
# plus whichever tools you want gated:
pip install oneport-secrets oneport-depcheck oneport-migrate oneport-review \
            oneport-apidiff oneport-testgap

oneport doctor shows which tools are installed.

Use

onp init          # scaffold .oneport/oneport.yaml + guidelines.md
onp ship          # run the gate on the whole repo
onp ship src/     # or a subpath
onp ship --format json      # machine-readable, for CI
onp ship --fail-on critical # only critical findings block
oneport dashboard     # the same verdict as a local HTML dashboard (nothing uploaded)
oneport list          # show which gates will run
onp tools         # the whole suite, by layer, with install status
oneport usage         # token usage from the local ledger

Exit code is 1 when any gate blocks, 0 when clear — drop onp ship straight into CI.

The whole suite, one front door

Every Oneport tool is a first-class onp subcommand — onp <tool> ... forwards to the tool's own CLI, so this one command is the way into the platform:

oneport standup daily                       # your git → standup notes
oneport impact analyze billing/stripe.py    # what breaks if I touch this?
oneport upgrade scan --to django:5.0        # deprecated-API readiness
oneport evidence report -F soc2 -o pack.pdf # SOC 2 evidence from your ship history
onp review --staged                     # AI review of what you're committing

Each tool is its own pip package — install only what you use; onp tools shows what's present and gives the install hint for what isn't. A tool that isn't installed never breaks the umbrella.

Configure — .oneport/oneport.yaml

gates:              # which gates run, in order (omit for sensible defaults)
  - secrets
  - depcheck
  - migrate
  - review
  - apidiff
  - testgap
fail_on: error      # verdict blocks on this severity or higher

Or keep the defaults and adjust with enable: / disable: lists. The same .oneport/ directory holds guidelines.md — the shared brain every Oneport tool reads.

How it fits together

• oneport_core — the shared spine: the result contract every tool's JSON is normalised into, config loading, the tool registry, and the usage ledger.
• oneport_cli — the oneport orchestrator: runs each gate as a subprocess, merges results, renders the verdict.

A tool that isn't installed is skipped; a tool that errors is surfaced (and, by default, blocks — a gate that can't run means the repo can't be certified). No tool failure ever takes down the whole run.

Privacy

Serverless by design. oneport runs the tools on your machine; each tool talks only to its model API on your own key. There is no Oneport server. The usage ledger (~/.oneport/usage.db) stores token counts and a one-way hash of the repo path — never your code.