V1 deployment boundaries and prerequisites

V1 is a deployment control plane for immutable workspace images; it is not a cluster, DNS-zone, ingress-controller, secret-manager, or processkit installer. It compiles typed desired state, records ownership, and asks an already-provisioned backend to reconcile only the resources it owns.

Infrastructure supplied by the operator

Before enabling a Kubernetes target, supply all of the following outside aibox:

• a reachable kube context with a namespace aibox is allowed to manage;
• an existing ingress class or gateway class when ingress is configured;
• an existing DNS zone when DNS reconciliation is configured;
• credential references that the selected backend can resolve, never secret values in aibox.toml;
• an immutable image reference and sha256: digest;
• a least-privilege identity limited to the target namespace and the selected DNS record scope.

Aibox refuses foreign, unlabeled, digest-mismatched, or missing-record resources during guarded destroy. These checks protect against accidental deletion; they are not a replacement for namespace policy, admission control, or credential rotation.

Operational limits

deploy plan and config compile are offline planning operations. deploy apply, status, logs, connect, and destroy use the selected backend. Only destroy removes resources, and it requires the matching local or verified remote deployment record plus all ownership labels/digests.

Processkit production delegation is a separate stable-v1 release gate. The current fixture protocol is not production authority. Likewise, fake-client Kubernetes tests are not evidence that a live disposable cluster behaves correctly.

The v1 processkit boundary has only two states:

• disabled — aibox performs no CLI discovery, creates no request file, starts no subprocess, and changes no project or harness state;
• direct — aibox passes one versioned request file to processkit execute --request ... and retains only the opaque structured result/provenance.

The boundary does not import aibox’s legacy processkit vocabulary, content fetch/install machinery, template paths, skill names, migration layouts, or MCP projection policy. Install, verify, unchanged update, recovery, and uninstall tests exercise the same direct boundary against the exact pinned processkit producer. Users may invoke that producer directly; aibox does not add a second interpretation of its result.

Release evidence

Run the diagnostic before declaring a stable-v1 release:

aibox config release-readiness
aibox config release-readiness --output json

It exits non-zero while a blocking gate is incomplete, but JSON is still printed for automation ingestion. Stable publication runs scripts/test-v1-stable-readiness.sh first. That harness executes the real migration/restore, ownership and secret canaries, dependency audit, and exact processkit alpha.3 producer tests. It writes one typed, candidate-bound ReleaseGateEvidence record per gate under .aibox/release-evidence/v1-readiness/. A record is retained only after its producer succeeds.

Stable readiness also runs scripts/test-v1-operational-readiness.sh for the support/deprecation/retirement policy and the ainfra/aibox/processkit portfolio boundary. The four-platform release and rollback gate is deliberately not manufactured inside the Linux container: after both native release phases and an exact-version rollback rehearsal, retain their artifacts with scripts/record-v1-platform-rehearsal.sh.

Automated adoption journeys are necessary but not sufficient. Stable readiness also requires all five external pilot feedback documents described in the support and retirement policy, recorded by scripts/record-v1-external-pilot-feedback.sh against the same candidate.

The readiness parser verifies the candidate commit, tested-binary digest, gate identity, and SHA-256 digest of every referenced producer log. Missing, candidate-mismatched, or modified logs block the release. M7c separately requires complete live disposable-cluster evidence at .aibox/release-evidence/m7c-live.json.

M7c passes only when the release workflow supplies both the exact candidate commit and tested-binary digest. A standalone diagnostic intentionally treats the artifact as unbound and remains blocked; use ./scripts/maintain.sh release <version> to evaluate it as release evidence.

The evidence artifact must be generated by the release suite and contain:

{
  "apiVersion": "aibox.projectious.work/v1alpha1",
  "kind": "DisposableClusterEvidence",
  "status": "passed",
  "candidateCommit": "<40-character-release-candidate-commit>",
  "binarySha256": "sha256:<tested-candidate-binary-digest>",
  "cluster": "<ephemeral-cluster-id>",
  "command": "cargo test --features e2e --test e2e kubernetes_kind",
  "scenarios": [
    { "id": "first-apply", "status": "passed" },
    { "id": "unchanged-apply", "status": "passed" },
    { "id": "changed-apply", "status": "passed" },
    { "id": "drift-recovery", "status": "passed" },
    { "id": "status-logs", "status": "passed" },
    { "id": "exec-port-forward", "status": "passed" },
    { "id": "ingress", "status": "passed" },
    { "id": "foreign-destroy-refusal", "status": "passed" }
  ],
  "recordedAt": "<RFC3339 timestamp>"
}

The artifact is release evidence, not a configuration knob. The producer adds a scenario only after it passed and validates the complete typed artifact with the Rust readiness parser before the test harness retains it. Unknown, missing, duplicate, or unexecuted scenarios are rejected. Do not add a hand-written passing marker to bypass a failed or unrun cluster test.