antigravity-setup-system

The ai-stp installation component for Antigravity CLI.

Use ai-stp as the product entry point. Its CLI owns selection, authenticated acquisition and lifecycle orchestration; this component owns the final harness files and recovery. This repository remains the public source and release boundary, with the existing package identity. It is part of ai-stp, not a separate user workflow.

The isolated Rust CLI preview reports its implemented capabilities through its executable registry. Native writable lifecycle and production cutover are separate acceptance steps; this component's commands below do not claim that the preview already installs.

Installs, reselects, restores and removes a complete Antigravity CLI harness configuration, and owns the program lifecycle.

A setup here is the complete harness state — the system-prompt components and the whole configuration — not a pointer to somewhere the content really lives. That is what makes restore mean something: it returns the instructions, skills, agents, commands, hooks, MCP entries, plugins and settings together, in one step.

Status: implements the five core operations and the program lifecycle.

install, replace, backup, restore and remove all work, over the wire and from the local catalog.

The software lifecycle installs the product itself: a plan names the exact bytes offline, whoever holds the network fetches them, and apply verifies and installs with the network gone.

launch starts the exact executable that install placed, never a name found on PATH, and only when --target is the documented home. There is no environment override; an alternate root is refused by name.

Component maintenance and compatibility

These direct entry points remain available for existing integrations and component development. New user workflows belong to the ai-stp CLI.

antigravity-setup-system list
antigravity-setup-system install baseline    --target ~/.gemini
antigravity-setup-system status              --target ~/.gemini
antigravity-setup-system select full-auto    --target ~/.gemini
antigravity-setup-system diff                --target ~/.gemini
antigravity-setup-system reinstall           --target ~/.gemini
antigravity-setup-system backups             --target ~/.gemini
antigravity-setup-system hold --backup slot-000000000001 --reason "before the experiment" --target ~/.gemini
antigravity-setup-system restore --backup slot-000000000001 --target ~/.gemini
antigravity-setup-system remove              --target ~/.gemini

Every command takes an explicit --target. There is no default and no fallback to a configuration home: a change aimed at a guessed path is a change aimed at someone else's state. The documented home is printed by --help so it can be copied, not resolved.

Four setups

list names every setup this build carries. All four mean the same thing on all seven setup systems, expressed in each product's own format:

baseline	a working floor: instructions plus the shared autonomous posture
minimal	instructions plus the shared autonomous posture, and nothing else
full-auto	nothing asked and nothing sandboxed, in this product's own keys
nddev-builder	the full-auto posture plus the product-native NDDev authoring toolkit

full-auto is a setup posture — keys in a configuration file this product reads. nddev-builder keeps that posture and adds authoring knowledge; selecting the toolkit must not silently return development to an approval loop. Neither is an external execution profile and neither grants environment by itself.

The existing configuration lifecycle captures a backup before changing the configuration, so restore can return its bytes. Software install, update and remove use their own ownership/recovery records and do not capture configuration backups. restore with no reference means the most recent backup that existed when you asked — not the one the restore itself just took. These compatibility effects do not authorize automatic backups in a new ai-stp workflow.

Selecting a setup reaches its complete state, not a merge. If the setup you leave owned a file the one you choose does not, that file goes. A target is always exactly one setup plus whatever this provider never claimed. A bundle arriving over the wire is materialized the same way, for the same reason.

Point ANTIGRAVITY_SETUP_SYSTEM_SETUP_CATALOG at a directory to use setups of your own.

What it manages

Product	Antigravity CLI (Google)
Documented configuration home	~/.gemini
Environment override	none documented
Configuration lifecycle	owned
Program lifecycle	owned

The configuration home above is documentation. Every mutation takes an explicit absolute --target; nothing is inferred from a home directory or the working directory.

The two surfaces

This is one binary with two callers.

Provider (ai-stp protocol v3). provider-info, validate-bundle, plan-operation, apply-operation, recover-operation, status, and launch where the capability is declared. The vocabulary is owned by provider-kit/v3/manifest.json, vendored here and verified against its SHA256SUMS.

Human. list, status, install, select, reinstall, diff, backups, restore [--backup <ref>], hold, release, remove, adopt where a target may still carry a stamp from the estate that came before this one, and software and rollback, which read and re-point a program directory without a network.

Both go through crates/setup-core. A human command that reached the target directly would bypass the guarantees the wire surface owes its consumer, so it does not exist.

How a mutation is made safe

resolve target -> acquire lock -> re-check preconditions
  -> journal(prepared) -> capture backup -> stage -> promote
  -> journal(committed) -> verify -> clear

Each step is durable before the next begins, so an interrupted mutation leaves evidence rather than ambiguity:

• a journal in prepared means the effect may be partial — recovery restores the exact pre-operation target;
• a journal in committed means the effect is complete — recovery verifies the result and clears the tails.

While any journal, transaction directory or half-written backup slot is present, planning refuses with recovery_required instead of guessing. Only recover-operation may resolve that state.

Restore

restore with no reference restores the most recent backup. restore --backup <ref> restores a chosen one. Slots are numbered by a monotonic sequence rather than a timestamp, so "the last backup" does not change meaning when a clock does.

Installing

Linux and macOS:

sh install.sh

Windows:

powershell -ExecutionPolicy Bypass -File install.ps1

Each fetches the release artifact for this platform, checks it against the release's own SHA256SUMS, and places it at a predictable path: ~/.local/bin/antigravity-setup-system on Linux and macOS, %LOCALAPPDATA%\Programs\antigravity-setup-system\antigravity-setup-system.exe on Windows. Neither needs privilege and neither registers anything anywhere.

Somewhere else instead:

ANTIGRAVITY_INSTALL_DIR=/opt/antigravity-setup-system sh install.sh

The same variable on both scripts, and it is ANTIGRAVITY_INSTALL_DIR rather than the longer prefix the setup-catalog variable uses -- the installer is named after the product, not after the crate. It was always accepted and never written down here, which is how someone reading only this page installs into a home directory they did not mean to write to.

Releases carry six binaries — Linux, macOS and Windows, on x86_64 and arm64 — which is what provider-info declares, so the declaration and what you can download say the same thing.

Using the component through ai-stp

The ai-stp CLI selects an exact component release, authenticates its artifacts and invokes it through the provider protocol. Normal user workflows do not require installing this component as a second CLI. The native preview's implemented commands are described in its linked contract above; its writable lifecycle remains a separate acceptance step.

For maintenance, a locally built executable can be checked explicitly through the released CLI's expert conformance command:

ai-stp provider conformance --harness antigravity \
  --executable target/release/antigravity-setup-system \
  --target <empty-dir> --protocol-version 3 --unverified-provider --json

This checks protocol behavior in an explicit disposable target. A local build does not acquire release publisher authentication by passing conformance.

As a container

docker run --rm -v "$HOME/.config:/config" \
  ghcr.io/nddev-opennetwork/antigravity-setup-system:0.0.93 \
  status --target /config/<dir> --json

Distroless and non-root, holding this binary and nothing else — no shell, no package manager. linux/amd64 and linux/arm64, built from the same artifacts the release carries rather than compiled again, so the attestation on the image and the attestation on the binary are true of the same bytes.

Building

cargo build --locked --all-targets
cargo test --locked --all-targets
cargo clippy --locked --all-targets -- -D warnings
cargo fmt --all --check

The toolchain is pinned in rust-toolchain.toml. Building also requires a C compiler and libclang development library: SQLite is compiled into the binary, and its capability VFS bindings use bindgen. On Debian/Ubuntu these are supplied by build-essential and libclang-dev; macOS uses Xcode Command Line Tools; Windows uses MSVC Build Tools and LLVM. If libclang is outside the loader's search paths, set LIBCLANG_PATH to its library directory. These are build-time requirements; the shipped binary needs no SQLite server or libclang installation. CI runs these commands through python tools/with_libclang.py on Linux, macOS and Windows. The helper supplies a hash-pinned temporary Linux library, exposes the selected Xcode library and C headers on macOS, and uses the installed LLVM/MSVC SDK on Windows. It changes no system packages or runtime requirements.

Licence

AGPL-3.0-or-later. See LICENSE.