Metadata-Version: 2.4
Name: oneport
Version: 0.1.0
Summary: The Oneport pre-ship gate — one command runs every Oneport check and tells you if your code is safe to ship.
Author: Oneport
License: MIT
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: click>=8.1.0
Requires-Dist: rich>=13.0.0
Requires-Dist: pyyaml>=6.0.0
Provides-Extra: dev
Requires-Dist: pytest>=8.0; extra == "dev"
Requires-Dist: pytest-cov>=4.0; extra == "dev"

# 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.

`op 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?**

```
$ op 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 op ship again.
```

## Install

```bash
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
```

`op doctor` shows which tools are installed.

## Use

```bash
op init          # scaffold .oneport/oneport.yaml + guidelines.md
op ship          # run the gate on the whole repo
op ship src/     # or a subpath
op ship --format json      # machine-readable, for CI
op ship --fail-on critical # only critical findings block
op list          # show which gates will run
op usage         # token usage from the local ledger
```

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

## Configure — `.oneport/oneport.yaml`

```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 `op` 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. `op` 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.
