Skip to main content

onevcs

Version control and its remote host behind one host-neutral vocabulary, for agent workflows.

The review unit is a change request — GitHub maps it to a pull request, and a later host maps it to whatever it calls the same thing. Vcs owns the repository side (identities, sessions over an isolated worktree, preserved work); RemoteHost owns the host side (opening a change, reading its checks, merging it); a rules file decides, per repository, how a change publishes and what verifies it. Everything a run does is emitted as an NDJSON event stream.

The public surface is the approved contract — docs/contract.md — compiled, and it is implemented: the registry with its lazy migration, the rules engine, sessions over borrowing clones, bounded git, the FIFO merge queue, both publication strategies, recovery and provenance, the merge train, and the event stream.

What one change looks like

onevcs register ~/projects/widgets                 # once per checkout
onevcs rules check widgets                         # which policy, and why
token=$(onevcs session open widgets --branch feature/thing | jq -r .token)
# …work in the worktree the session printed…
onevcs publish "$token"                            # verify, then land it
onevcs events "$token"                             # everything it did, as NDJSON
onevcs release status "$token"                     # …and whether a release carries it

A branch that outlived the session that cut it is landed by name instead, under that same rules-resolved policy: onevcs publish-branch feature/thing --repo ~/projects/widgets for work that finished, and onevcs recover for a step that stopped half way, which publishes it with the attestation that verification cleared it. Whichever of the three refuses a branch names the one that takes it.

onevcs status REF answers what became of a piece of work, asked by whichever name you hold — a change request's URL, a session token, a branch, or a commit. It reports the identity's resolved policy, the session, every checkout and per-run clone holding the branch, whether the change landed and what says so, the host's checks, the last thing its merge path said about it, and the command that advances it. Landing is decided from the base's own history — a recorded landing, the change request's number in the base's log, or a landing trailer — so a change that squash-merged reads as landed rather than as unpublished however far the base has moved since, and one that history cannot decide reads as unknown rather than as work nobody published. A host that cannot be reached leaves its section unavailable instead of failing the command.

onevcs release answers what happens after a change lands, so an upgrade can be sequenced behind the release that carries it rather than behind the merge. onevcs release targets REPO lists what a repository releases and whether it adopts fast (the work is enough) or published (the release is what is depended on); onevcs release latest REPO [--target NAME] says what is out right now; and onevcs release status REF [--target NAME] says whether the release carrying one landed change has happened yet, asked by the same four names onevcs status takes.

A target's style decides its shape. An automated target carries a probe — a script the repository carries, or a one-liner run through sh — and is answered by running it under a bounded timeout; a human-step target carries no probe at all, because the release happens when a person does something, and is answered by onevcs release acknowledge REF --target NAME --version VERSION after they have done it. Recording the same version again is a no-op; a different one is refused until --supersede replaces it, which keeps the version it replaced.

Two answers stay apart everywhere, and a consumer routes on the difference: "not released" is a probe that answered, and "not answered" is a probe that did not — a timeout, a non-zero exit, or output that is not one usable version. A landing whose probe never answered is "not answered" for ever rather than being compared against a reading taken later, because the release carrying that very change may already be in it. Configure targets in $ONEVCS_HOME/releases.yml; a host with none behaves exactly as it did before there was one.

onevcs import BRANCH --repo PATH [--from SOURCE] [--as NAME] makes a branch reachable from an identity's registered checkouts, so a later run's clone can see work a stopped run left in its own. It writes refs and nothing else — no checkout, no working tree — and refuses a non-fast-forward overwrite by naming the commits it would lose.

onevcs sweep [--dry-run] [--min-age-hours HOURS] reclaims the workspaces those landings leave behind. Every branch published by name cuts a run root — a clone, a worktree, and the merge path's preserved logs — under the state root, and until this rule existed nothing removed one; thirty-one of them filled a host's disk twice in a single run. The rule runs whether or not anybody asks: each landing enforces it over its own family before cutting the next run root, and this verb is the same judgement asked deliberately and over every family at once.

A workspace is removed only where this tool can prove it is finished: its merge path recorded a verdict, no live session holds its occupancy lease, it was last written outside the age floor --min-age-hours sets, and removing it is something this host can do at all. Everything else is retained and reported with the reason — a workspace somebody is still publishing in is never removed, and neither is one belonging to another manager on a shared state root — and the per-run lifecycle clones a session keeps as recovery history are outside it entirely.

Two things a proven-finished workspace still gets to keep. Its preserved logs last at least as long as the age floor, because they are what an operator reads after a publication failed; and a clone still holding work that never reached the origin is kept past the floor too, until enough newer ones stand in front of it — under the same bound the per-run lifecycle clones a session keeps are kept under. Reclaiming a workspace also stops the processes that publication left running — a publication runs the repository's own verification and verifications start daemons, and unlinking files a live process holds open frees none of their blocks.

Everything durable lives under one state root — ONEVCS_HOME, otherwise ~/.onevcs.

GitHub is reached through gh, so whatever gh auth status reports is the credential. A fine-grained personal access token needs Actions: Read on the repository beside its contents and pull-requests access: GitHub will not let that credential class resolve a check run at all — there is no Checks permission to grant one — so a change request's checks are read from its workflow runs, and change_checks says so in the sources it answers with. Anything a third-party integration posted as a check run or a commit status is invisible to such a token, and a credential that can read neither source is refused rather than reported as having no checks.

Install

cargo install onevcs      # crates.io
pip install onevcs-cli    # a prebuilt wheel, no Rust toolchain
npm install -g onevcs-cli # a prebuilt binary, no Rust toolchain

All three install the same onevcs binary. Prebuilt binaries exist for Linux (x64, arm64), macOS (x64, arm64), and Windows (x64); every release also attaches the archives and their .sha256 checksums for a direct download.

Use

onevcs --help

--help is the command surface, and publish reserves its own exit codes for a verification that failed, a request that was invalid, and a base that moved under it.

Embed it

A command answers a process: an exit code and a line of prose. A caller embedding the crate wants the decision, so the same operations answer values.

let published = onevcs::publish(&providers, &token, &PublishRequest::default())?;
match published.outcome {
    PublishOutcome::Merged(sha) => journal.landed(sha),
    PublishOutcome::ChangeOpen(url) | PublishOutcome::Queued(url) => journal.awaiting(url),
    PublishOutcome::NothingToPublish => journal.nothing(),
    PublishOutcome::Failed { kind, reason, retained } => journal.failed(kind, reason, retained),
}

close_session and session are the same for the rest of a session's life, and EventStream::open(&token) reads its events as Envelopes, each attributed to the session that wrote it — so a caller following several publications at once can tell them apart. The command line is a rendering of these rather than a second path through them.

A consumer that wants some of what a session writes reads it through the filter grammar the three producing libraries share — EventStream::open_filtered(&token, filter), or onevcs events TOKEN --filter SPEC with the spec inline as JSON or in a file. An envelope passes when it matches any include matcher (or include is absent) and no exclude matcher, matching source by family, kind by glob (change-*), and the reserved label keys exactly:

include:
  - {source: vcs, kind: "gate-*"}
exclude:
  - {kind: lock-wait}

Before a caller has a token, session_holders(repo) answers who is in a repository: one SessionHolder per recorded session, carrying the token the calls above take, the branch and worktree it holds, and whether its owner is still running (Liveness::Live) or the session is the remains of a run that stopped.

Test against it, without a real GitHub

Embedding the crate, run_with(&cli, providers) takes the two implementations a run reaches Vcs and RemoteHost through; run is that with Git and GitHub, and every entry point above goes through the same seam. onevcs-testing ships in-memory and file-backed implementations of both, so a consumer's suite drives a real onevcs through a real journey against a host it seeded:

cargo add --dev onevcs-testing

They emit the events the real implementations emit — a claim this repository's own suite checks by running one publication journey on both backends and holding the two event streams to each other.

Develop

just bootstrap   # from a clean clone
just check       # the deterministic gate: format, clippy, tests, coverage, docs
just gate        # check, plus the diff-scoped LLM-judge tier — the pre-push bar

just --list is the full index.

License

MIT. See LICENSE.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distributions

No source distribution files available for this release.See tutorial on generating distribution archives.

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

onevcs_cli-0.13.0-py3-none-win_amd64.whl (1.4 MB view details)

Uploaded Python 3Windows x86-64

onevcs_cli-0.13.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.4 MB view details)

Uploaded Python 3manylinux: glibc 2.17+ x86-64

onevcs_cli-0.13.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (1.3 MB view details)

Uploaded Python 3manylinux: glibc 2.17+ ARM64

onevcs_cli-0.13.0-py3-none-macosx_11_0_arm64.whl (1.3 MB view details)

Uploaded Python 3macOS 11.0+ ARM64

onevcs_cli-0.13.0-py3-none-macosx_10_12_x86_64.whl (1.4 MB view details)

Uploaded Python 3macOS 10.12+ x86-64

File details

Details for the file onevcs_cli-0.13.0-py3-none-win_amd64.whl.

File metadata

  • Download URL: onevcs_cli-0.13.0-py3-none-win_amd64.whl
  • Upload date:
  • Size: 1.4 MB
  • Tags: Python 3, Windows x86-64
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for onevcs_cli-0.13.0-py3-none-win_amd64.whl
Algorithm Hash digest
SHA256 090ef06f6bbe987c2a7e8a7aaa32940a6e512c31a67d35086fd837318ebadb03
MD5 d40290ebd5f1b74cdf1438ff4289a163
BLAKE2b-256 5ac94c9929de7a069bd6a96a59a4b20a3f9efb136de58bce3775c54f772b2c42

See more details on using hashes here.

File details

Details for the file onevcs_cli-0.13.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for onevcs_cli-0.13.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 d3cb12c5990beba366989c8d814f3e48a42c4e31d49a4952c47a39a5c4267c27
MD5 f31623e5ee5e06f3191c60f00902f362
BLAKE2b-256 2e2b55721573b363a39cc285efee0c2b66975b30ba885e22ed0ebc353eb8a9b0

See more details on using hashes here.

File details

Details for the file onevcs_cli-0.13.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for onevcs_cli-0.13.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 74405d6260521ba31818a0f9e9bbb5c1bc5aacb2e0653fefd6ba8c41c1dca10d
MD5 ec833415e2481362d89e368cc2d983b8
BLAKE2b-256 b8ab7d6c05f37ee88994a643a3d1077f55625bbba40c24d17c9a2c9cfc8daf93

See more details on using hashes here.

File details

Details for the file onevcs_cli-0.13.0-py3-none-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for onevcs_cli-0.13.0-py3-none-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 100d7edb337180b845eed82d028822bb86ae6d29c8c9ad48c126849109da3385
MD5 898b9de2fc331378fdb92e8a38adcccd
BLAKE2b-256 1f728ba0c9abd65e53a16fef769a1a6917709fc0b839d843e46e8c4dda08649d

See more details on using hashes here.

File details

Details for the file onevcs_cli-0.13.0-py3-none-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for onevcs_cli-0.13.0-py3-none-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 ce0ad9cce71c7ac7aa934b5d5a4c14c4b0fc1274df2beefbebf4585df1de0892
MD5 64c874b18488a1949b1b0b411b0e4d27
BLAKE2b-256 72ab9cb5235cdafd8869aee7498819c83f535987d2c2f9ea022f8e3fc79b0e5a

See more details on using hashes here.

Release history Release notifications | RSS feed

0.18.0

5 files

0.17.1

5 files

0.17.0

5 files

0.16.3

5 files

0.16.2

5 files

0.16.1

5 files

0.16.0

5 files

0.15.10

5 files

0.15.9

5 files

0.15.8

5 files

0.15.7

5 files

0.15.6

5 files

0.15.5

5 files

0.15.4

5 files

0.15.3

5 files

0.15.2

5 files

0.15.1

5 files

0.15.0

5 files

0.14.1

5 files

0.14.0

5 files

This release

0.13.0 This release

5 files

0.12.3

5 files

0.12.1

5 files

0.12.0

5 files

0.11.1

5 files

0.11.0

5 files

0.10.0

5 files

0.9.0

5 files

0.8.1

5 files

0.8.0

5 files

0.7.0

5 files

0.6.1

5 files

0.6.0

5 files

0.5.0

5 files

0.4.2

5 files

0.4.1

5 files

0.4.0

5 files

0.3.1

5 files

0.3.0

5 files

0.2.10

5 files

0.2.9

5 files

0.2.8

5 files

0.2.7

5 files

0.2.6

5 files

0.2.5

5 files

0.2.4

5 files

0.2.3

5 files

0.2.2

5 files

0.2.1

5 files

0.2.0

5 files

0.1.3

5 files

0.1.2

5 files

0.1.1

5 files

0.1.0

5 files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page