AMOF Install Runbook

Status: public first-touch install guidance

This runbook explains the three supported public install paths:

• primary standalone artifact path built from a source checkout
• checkout-local fallback path from a source checkout
• optional pipx path for an isolated Python install

What AMOF Installs

AMOF installs a local CLI that can:

• run amof demo to a verified receipt (no provider key, no cluster)
• bind a promoted SHA with amof proof show
• check workstation prerequisites
• store app-data under user-local paths
• adopt an existing repo without polluting it
• store provider profile references
• run read-only planning or explicitly requested bounded execution
• expose Runtime Authority surfaces for write-scope, Kubernetes capability,

receipts, bounded loops, and execution evidence

First proof from a source checkout, before any install path:

git clone https://github.com/marekhotshot/amof.git
cd amof
python3 scripts/amof.py demo migration --non-interactive
python3 scripts/amof.py proof show AMOF-15MIN-RUNTIME-AUTHORITY-DEMO-001

AMOF is evidence-first. It does not auto-commit or push on its own, and it does

not store raw provider secrets in profile setup.

Primary Standalone Artifact Path

Use this path if you want a single-file public executable without pipx.

git clone https://github.com/marekhotshot/amof.git
cd amof
./scripts/build-standalone-amof.sh
./dist/amof --version

What this does:

• builds a single-file executable artifact at ./dist/amof
• bundles the AMOF CLI and its Python dependencies into that artifact
• lets you run AMOF without pipx and without keeping .venv/bin/amof as the only no-pipx path

The standalone artifact is not a native binary. It is a Python-based executable

artifact and still requires a compatible python3 runtime on the host unless

proven otherwise for your environment.

Checkout-Local Fallback Path

Use this path if you prefer the existing local virtualenv install:

git clone https://github.com/marekhotshot/amof.git
cd amof
./scripts/install-amof.sh
./.venv/bin/amof --version

This fallback remains supported for development and for users who want the AMOF

runtime installed into a checkout-local virtualenv.

Source Checkout Test Install

Use this path when developing AMOF itself or running focused operator tests from

a clean checkout:

python -m pip install -e ".[test]"
python -m pytest tests/test_remote_ial.py

The test extra is intentionally separate from AMOF runtime dependencies so

end-user installs do not pull in pytest.

Optional Pipx Path

Use this path if you prefer an isolated user install:

pipx install "git+https://github.com/marekhotshot/amof.git@v3.5.0"
amof --version

Expected version (after the v3.5.0 tag exists):

AMOF v3.5.0

v3.5.0 packages Write-Scope Authority, Kubernetes Capability Authority,

amof demo, and amof proof. Until the tag exists, verify a source checkout

with amof --version instead of the pipx pin.

First Commands After Install

amof check
amof doctor
amof setup provider --list

If you installed from a source checkout virtualenv, replace amof with

./.venv/bin/amof. If you built the standalone artifact, replace amof with

./dist/amof.

Adopt A Repo

From the repo you want AMOF to work with:

amof init --adopt .
amof doctor

Adoption records bindings and evidence in AMOF app-data. It does not write

AMOF runtime directories into the target repo by default.

Provider Profiles

Provider setup records metadata and environment variable references only:

amof setup provider --list
amof setup provider bedrock --print-template

Live provider use still requires the relevant environment variables in your

shell. AMOF does not store raw provider secrets in setup profiles.

Planning vs Execution

Read-only planning:

amof agent --plan "Inspect this repo" --no-follow-up

Bounded execution:

amof agent --plan-execute "Make a bounded change. Do not commit." --no-follow-up

Execution must still be reviewed as a Git diff. AMOF does not mutate, commit,

or push unless you explicitly ask it to do so.

Bedrock Precision

Installed CLI Bedrock no longer requires pipx inject amof requests.

In enterprise TLS-intercepted environments, Bedrock still requires a combined

CA bundle containing:

• system/public trust roots
• the corporate interception CA, for example Zscaler

Use the combined bundle with:

• SSL_CERT_FILE
• REQUESTS_CA_BUNDLE
• AWS_CA_BUNDLE