Metadata-Version: 2.4
Name: party-continuum
Version: 0.3.0
Summary: Change impact from Party's Continuum: what a change reaches, how risky it is, which tests reach it
Requires-Python: >=3.11
Description-Content-Type: text/markdown

# continuum

Change impact from Party's Continuum, for people and coding agents: what a
change reaches, how risky it is, which tests reach it, and what no test reaches.
Continuum keeps a dependency graph of each repository current as its default
branch changes; this CLI asks it about your checkout.

```bash
pip install party-continuum        # or: brew install maitai-inc/continuum/continuum
continuum login                    # a browser code; saves a revocable token
```

Before an edit:

```bash
continuum dependents billing/charge.py::charge --depth 2   # what depends on it
continuum impact --plan charge --change signature          # the reach of a planned change
```

After an edit (the working tree against the default branch):

```bash
continuum impact      # reach, impact and risk grades, and what drives them
continuum tests       # every test that reaches the change, with commands to run them
continuum untested    # reached code that no test reaches: add tests here
continuum explain api/refunds.py::refund   # why the change reaches it
```

Every command takes `--json`. `--repo owner/name` overrides the checkout's GitHub
origin, and `--base` / `--head` choose what to compare.

**Impact and risk are separate.** Impact is how much behavior the change can
reach. Risk is how much of that no test would notice: reached code no test
reaches, code still using something the change removes, and changes Continuum
cannot see through. A wide, well-tested change is high impact and low risk; a
small change to untested code is the reverse. Both are graded against the
repository's own recent changes.

**What it sends.** The paths of your changed files and the contents of changed
text files (at most 4 MB); never other files, and nothing unless you run a
command. The graph lives with Continuum, so answers take about a second.

**Tokens.** `continuum login` saves a token that reads Continuum and nothing
else; logging in again or using it keeps it alive, and `continuum logout` revokes
it. For CI and agent Environments, create a fixed token and set it as
`CONTINUUM_TOKEN`:

```bash
continuum token create --name "skipper Environment" --repo maitai-inc/skipper --days 90
continuum token list
continuum token revoke <id>
```

Requirements: Python 3.11+ and git. Continuum is for members of the Party
organization; `CONTINUUM_URL` points the CLI at another Party server.

## Setup and trusted development checks

`continuum login --validation` installs missing repository agent instructions; use
`--no-skill` to opt out or `continuum init` to install later. Custom skills are
preserved. `continuum doctor` diagnoses configuration without claiming a live
execution succeeded. Headless keys can also be created in dashboard Settings.

`continuum validate run --stage build` selects impacted tests, runs a frozen
snapshot locally, and reports results in one command. The indexed baseline policy
must opt in with `evidence.local_build = true` for those results to satisfy the
ledger. This trusts authenticated developers' build receipts; CI stages still
require an approved runner. Prepared private images need local registry access.

An operator-provided `CONTINUUM_EXECUTOR_URL` and request-only
`CONTINUUM_EXECUTOR_TOKEN` optionally delegate execution to a separate trusted
executor. Never give its signing credential or Docker access to the coding agent.
See [operator setup](../VALIDATION_LEDGER.md) for provisioning and reuse semantics.
