# Use Resume-First BYOC Activation

CP9 invokes the official unmodified BYOC account-setup script locally with the
configured customer account profile. Its three `aws cloudformation deploy`
operations keep normal CloudFormation create/update and per-stack rollback
semantics. CP9 does not attempt to turn those independent stacks, customer ECR
mirroring, and remote Kubernetes reconciliation into one compensating
transaction.

Before the first mutation, activation completes every immutable and read-only
preflight and persists an input fingerprint. It then records each stage in a
credential-free BYOC activation journal with status, attempt count, timestamps,
non-secret outputs, the last error, and the exact account-setup/image-closure
provenance. Rerunning `cp9 byoc activate` with the same fingerprint
live-revalidates completed stages and resumes or reconciles from the first
non-ready stage. Account-setup revalidation compares each bound stack's exact
ID, account, Region, recorded creation time, pinned template, parameters, and
ownership tags. Role-chain revalidation reads both live IAM hops—including the
customer role's exact trust contract—and the sanitized remote-runtime evidence.
A journal `done` value alone never proves live readiness.

`cp9 byoc status` is strictly read-only and reports observed stage health, the
failed or interrupted stage, and the exact activation command that resumes it.
Changing a fingerprinted customer account, Availability Zone, DNS, PCA,
identity-chain, or other immutable contract fails closed and requires destroy
and recreate. A late activation failure does not silently remove earlier
successful stacks, roles, mirrored images, or regional configuration. Only an
explicit `cp9 destroy` initiates broad two-account teardown, subject to the
documented customer-prerequisite and retained-image-cache exclusions.
Destroy uses the journaled provenance rather than the current code pin, so a
later reviewed bundle or image-closure bump can force destroy/recreate without
making teardown of an already-bound session impossible.
If an AWS CloudFormation delete waiter exits nonzero, destroy re-describes only
the journal-bound stack ID and accepts the postcondition only when that exact
stack is `DELETE_COMPLETE` or no longer exists. A different identity,
nonterminal status, canceled observation, or other read failure remains a
fail-closed destroy error.