V1 adoption pilots

V1 adoption pilots

Stable-v1 readiness requires four repeatable journeys against the exact candidate and binary:

1. a new Compose workspace can compile and render a deterministic plan;
2. a representative v0 project can preview, apply, and roll back a reviewed v1 intent without exposing secrets or touching v1 deployment records;
3. an existing Kubernetes target passes the complete live M7c lifecycle;
4. exact-pinned processkit install, verify, unchanged update, recovery, and uninstall pass through the direct opaque boundary.

After the live M7c and M5 producer evidence has been generated, run:

RELEASE_CANDIDATE_SHA="$(git rev-parse HEAD)" \
AIBOX_RELEASE_BINARY_SHA256="sha256:<tested-binary-digest>" \
  ./scripts/test-v1-adoption-pilots.sh

The harness refuses missing or candidate-mismatched prerequisites. It executes the local Compose and migration journeys, verifies the live Kubernetes and direct-processkit scenario sets, and writes .aibox/release-evidence/v1-readiness/adoption-pilots.json. Stable publication reruns this automatically and verifies the retained log digest.

This automated evidence establishes repeatability, not user sentiment. Record configuration friction, plan comprehension, recovery steps, terminology confusion, and documentation gaps from external pilots in their tracking issues. Do not convert an unrun or unsuccessful external pilot into a passing release marker.