Apizr 0.4 in development

Not released

The latest published release is 0.3.0. This page describes capabilities integrated on master for the future 0.4, not a completed or published release. pip install outerspace-apizr==0.3.0 gives the stable local compiler and execution workflows, not the additions below.

What is available

Step	Implemented interface and detailed reference
Choose sources	Local directory, public Git HTTPS, or private Git with an explicit SSH agent and known_hosts
Analyze and select	Readiness and explicit exposure policy, shared by the CLI and Python compiler API
Configure and generate	Explicit apizr.toml, then REST/MCP repository bundles
Analyze from an MCP client	Optional apizr-mcp local stdio server: analysis, readiness and explicit planning, read-only
Prepare optional tools	Install, list, enable, run and disable isolated plugins; local/HTTPS wheels and locked local dependencies
Package and deliver	apizr-oci build and push: service image, immutable image identity, verified registry digest
Sign delivery	apizr-attest attest and verify: signed, RFC 3161 timestamped delivery receipt
Transport proof	publish, discover and fetch: OCI referrers, explicit proof digest, independent offline verification

Git acquisition and the compiler belong to the minimal core. OCI, Attest and Apizr's local MCP server are separately installed optional plugins. A generated business MCP server exposes selected functions; Apizr itself as an MCP server provides local stdio analysis and planning only. Postman synchronization, user-facing CI catalogue integrations, a plugin catalogue and automatic plugin updates are not implemented. Existing repository CI jobs are development validation, not those user integrations. Distribution qualification experiments do not constitute released 0.4 packages or catalogue admission.

Install a development wheel

These commands are executable as written on macOS/Linux with Git, uv and Python 3.11–3.14 already installed. Start in an empty working directory. Preparation may download the source, build backend and Pydantic dependency closure. It does not install optional application adapters or plugins.

git clone https://github.com/Alien6-Studio/outerspace-apizr.git apizr-source
cd apizr-source
git switch --detach origin/master
source_commit=$(git rev-parse HEAD)
work=$(mktemp -d)
printf '%s\n' "$source_commit" > "$work/source-commit.txt"
uv build --wheel --out-dir "$work/dist"
cp -R examples/project-config "$work/project-config"
cd "$work"
uv venv --no-python-downloads --python python3 core
uv pip install --python core/bin/python dist/outerspace_apizr-0.3.0-py3-none-any.whl
core/bin/apizr --version
cat source-commit.txt

The source revision is frozen at clone time; retain source-commit.txt with the wheel and its SHA-256. For an independently selected revision, replace origin/master with that full commit before building. The wheel still declares 0.3.0, and OCI/Attest/MCP plugin wheels declare 0.0.0. These are development builds from that commit, not the PyPI 0.3.0 release or published plugin releases. apizr --version alone cannot distinguish them. Build all plugin wheels from the same checkout; use separate core environments and plugin stores for stable and development work. The site build information identifies its documentation source, not the source of a wheel on your machine.

Generate locally, outside the checkout

The copied example includes src/calculator.py, both explicit JSON policies and apizr.toml. From $work, after the installation above:

core/bin/apizr readiness --project project-config/apizr.toml --report > readiness.json
core/bin/apizr expose plan --project project-config/apizr.toml --plan > plan.json
core/bin/apizr expose build rest --project project-config/apizr.toml --output-dir build/rest
core/bin/apizr expose build mcp --project project-config/apizr.toml --output-dir build/mcp

All four commands succeed: calculator.add is ready and explicitly selected; both bundles contain that public capability. Generation is static and offline: no import of the project, dependency installation, plugin or Docker invocation. The Git example prepares the same two local policy files and generates from an immutable remote commit instead. Git fetch accesses the chosen server; it does not download application dependencies. SSH additionally requires the explicitly prepared agent and host trust file.

Reproduce the complete delivery in a disposable environment

The existing integration script supplies the complete preparation that a real registry deployment otherwise requires: two disposable Linux Docker daemons, an authenticated HTTPS registry and explicit test CA, a local RFC 3161 authority, a test signing key, independent trust, pinned Attest/ORAS binaries, locked wheels, and fixture source. It builds and installs the core and plugins outside the checkout and exercises real REST/MCP services without the original sources.

Use a Docker host that permits privileged disposable containers and Linux amd64 images (with emulation already configured on arm64), Python 3.11+ and an installed Docker CLI. Return to the selected apizr-source checkout. This command is executable as written; the output directory is new:

proof_parent=$(mktemp -d)
python3 scripts/smoke_oci_registry.py --artifacts --output "$proof_parent/proof"
cat "$proof_parent/proof/outcome.json"
cat "$proof_parent/proof/artifact-fetch-result.json"

This script downloads preparation dependencies/images and publishes test images and proofs, exclusively into its disposable registry. It does not publish to Docker Hub, Trunx or a production registry, change machine trust or use release signing keys. It removes its named containers, volume and network; downloaded base images/build caches may remain. It retains public results, refusal cases, locks and test logs. Expect outcome.json to contain {"exit_code": 0} and the fetch evidence to confirm byte-identical proof files and an unchanged core. Read the integration proof contract for the independent, read-only consumer and networkless verification checks.

The script reuses this sequence rather than introducing another installer or build chain:

local/Git snapshot → readiness and explicit selection → REST/MCP bundle → service image → verified OCI push → signed and timestamped delivery receipt → OCI proof publication → untrusted discovery → explicit fetch → offline verify.

Keep results and verify operation states

For a deployment you control, use the complete JSON request examples on the OCI and Attest pages. Their registry.example, digests, signer identities and absolute paths are values to replace, not executable production defaults. Prepare the reviewed wheels, Docker/Buildx, authentication, trust and output parents first. The following commands assume core/bin/apizr, $work/plugins, build.json and push.json prepared as on those pages. Push actually publishes.

core/bin/apizr plugins run apizr-oci build --arguments build.json \
  --plugins-dir "$work/plugins" --timeout-ms 360000 > build-response.json
core/bin/python - <<'PY'
import json
from pathlib import Path
response = json.loads(Path("build-response.json").read_text())
assert response["status"] == "ok"
result = response["result"]
assert result["schema"] == "apizr.oci-build-result/v1"
assert result["published"] is False
Path("build-result.json").write_text(json.dumps(result))
PY

Fill push.json using that result's image_id, platform and inputs_sha256, plus your explicit destination, Docker and authentication parameters. Do not select a possibly moved local tag instead of image_id.

core/bin/apizr plugins run apizr-oci push --arguments push.json \
  --plugins-dir "$work/plugins" --timeout-ms 360000 > push-response.json
core/bin/python - <<'PY'
import json
from pathlib import Path
response = json.loads(Path("push-response.json").read_text())
assert response["status"] == "ok"
result = response["result"]
assert result["schema"] == "apizr.oci-push-result/v1"
assert result["published"] is True
assert result["digest_reference"].endswith("@" + result["manifest_digest"])
Path("push-result.json").write_text(json.dumps(result))
PY

Pass the absolute paths to these two result files, not the protocol envelopes, as build_result and push_result in attest.json. Its expected_reference comes from digest_reference; the expected signer and trust come from your independent selection. Keep the local immutable image until attest completes. Then follow the proof publication page using the exported proof directory. The consumer chooses an explicit artifact digest; discovery never chooses for it.

Operation	Required success evidence
`build`	`apizr.oci-build-result/v1`, checked image/platform/inputs, `published:false`
`push`	`apizr.oci-push-result/v1`, `published:true`, verified manifest/config identities and digest reference
`attest` / `verify`	`apizr.attest-delivery-result/v1`, expected identity, all five native checks pass, no warnings/skips; `receipt_published:false`
`publish`	`apizr.published-proof/v1`, `state:"verified"`, `receipt_published:true`, non-null artifact identity
`discover`	`apizr.discovered-proofs/v1`, `complete:true`; candidates remain `verified:false`, not selected or trusted
`fetch`	`apizr.fetched-proof/v1`, exact chosen artifact/image identities, verified exported proof and five native checks

A returned JSON object or exit zero alone is insufficient. Proof publication can return state:"remote_state_unconfirmed": that is not confirmed success. Image push can fail after transfer; the core redacts plugin errors. Interruption never proves rollback. Inspect remote state before retrying; nothing deletes remote artifacts automatically. Offline verify establishes receipt integrity, signer and independently configured trust, not current registry availability.

Boundaries that still apply

The OCI plugin accepts direct repository REST/MCP bundles and the supported server dependency closure, not arbitrary business dependencies or resources. A service image is different from the governed execution worker image.
Core, plugin and generated application dependencies live in different environments. Plugin local/locked installation is offline; HTTPS plugin acquisition is not. External tools are explicitly prepared, never silently downloaded during invocation. Docker base resolution may still access a registry.
Attest proves verified delivery, not a build supervised by Attest, SLSA or reproducible layers. Hash integrity is not author trust or independent signer trust.
Proof transport requires the documented single-image SHA-256 OCI profile and OCI 1.1 referrers API in the same repository, without tag fallback or multiarch. Docker Hub and Trunx have not been qualified by the disposable fixture.
The compiler does not execute source during analysis. Running generated services and trusted plugins does execute code; activation is not a sandbox. Process cleanup cannot undo daemon work or a completed remote upload.

Release preparation and remaining qualification are still separate from these integrated capabilities. An empty issue list would not establish 0.4 completeness.