Inspect the lab lifecycle

The lab lifecycle is separate from release verification. A cluster can be healthy without having verified a candidate, and a successful gate can leave an expensive cluster running. The maintained lifecycle entrypoint makes inspection the default and places stronger guards around consequential changes.

This guide describes the owned GCP and Radius testnet lab. prod is the production-like namespace in that lab. Dev, staging, and prod share one zonal GKE cluster; namespace separation does not establish independent failure domains or public-production isolation.

Establish the target before an operation

An operator’s ignored platform_setup_scripts/config.env supplies public project, zone, cluster, and repository identifiers. It must never contain wallet keys, Secret values, payment signatures, copied cloud credentials, or authorization headers. The shared helper requires the exact Kubernetes context:

gke_<PROJECT_ID>_<ZONE>_<CLUSTER_NAME>

A mismatch is a stop condition. Correct reviewed local configuration and explicitly select the intended context through the operator’s normal process. Do not weaken the guard or rely on a familiar namespace name.

Read the current state

./scripts/lab-ops.sh \
  --config platform_setup_scripts/config.env status

status delegates to the read-only verifier. It does not promote Freight, sync an app, create a Job, patch resources, read Secret data, or contact the testnet. Narrow the investigation when appropriate:

./platform_setup_scripts/07-verify.sh \
  --config platform_setup_scripts/config.env --scope gate

Scope	Question
platform	Are the expected platform namespaces, controller signals, and secret-store prerequisites present?
gitops	Are the reviewed Argo CD and Kargo configuration resources present?
gate	Is the scoped gate identity and verification configuration present?
all	Do all current verifier scopes pass? This is the default.

A zero exit status answers these resource checks at inspection time. It does not prove completed reconciliation, valid Prometheus samples, a payment, an applied fault, or a release verdict. Record a new observation instead of treating the 3 October inventory as present-day live state.

Review bootstrap without applying

./scripts/lab-ops.sh \
  --config platform_setup_scripts/config.env bootstrap-plan

This uses the bootstrap workflow with its dry-run guard. The orchestrator stops after phase 06; verification remains separate. The phases cover tool/access preflight, APIs and state bucket, Secret Manager inputs, Terraform, controllers, cluster resources, and GitOps contracts. Phase 06 registers the release path; it does not itself promote, spend tokens, or run chaos.

Review public manifest rendering, project identity, source changes, and any infrastructure plan before a separately authorized bootstrap. Full phase instructions remain in the bootstrap runbook. This documentation build does not require a running lab or authorize a bootstrap.

Plan teardown with current state

./scripts/lab-ops.sh \
  --config platform_setup_scripts/config.env destroy-plan

The destroy plan reads Terraform configuration and may contact the remote backend and cloud to refresh state. It retains a normal state lock with a bounded wait. It does not apply deletion. Avoid running it beside another infrastructure operation, and review a fresh plan after state or configuration changes.

The maintained destroy path is deliberately interactive. It requires --apply, the exact --confirm-project, --acknowledge-owned-testnet-lab-destruction, a TTY, and a retype of the project ID. Only after those guards does it create a fresh saved destroy plan and apply that exact plan. It does not use a bare terraform destroy or fall back to cloud or Kubernetes deletion shortcuts.

An operator must first preserve evidence and establish that no candidate, payment exercise, or collection still needs the lab. Do not pipe a confirmation or automate away the interactive boundary. A successfully applied plan also requires resource readback; a local exit code alone does not prove every cloud resource disappeared. No teardown is claimed by the retained verification report.

The implementation and guard tests are lab-ops.sh, shared context helpers, verifier tests, and lifecycle tests. Continue with promotion only after the prerequisite observations agree.