Reserve a dedicated namespace for the first reconstructed trade deployment.
Put hard upper bounds on namespace-level CPU, memory, object count, and PVC growth before application manifests land.
Verify that workloads in the namespace can resolve and reach the shared trade-infra services for Postgres and Redis.
Recreate the R001 application surface in a controlled way: Hasura, trade-api, and trade-frontend.

Current Guardrails

Namespace: trade-r001-canary
ResourceQuota:
- requests.cpu=2
- limits.cpu=6
- requests.memory=4Gi
- limits.memory=12Gi
- pods=20
- services=10
- configmaps=20
- secrets=30
- persistentvolumeclaims=4
- requests.storage=100Gi
LimitRange:
- default request: 100m, 128Mi
- default limit: 1, 1Gi
- per-container maximum: 2, 4Gi

Notes

This namespace is intentionally conservative until item 14 and the validator protection envelope are fully defined.
Current shared infrastructure endpoints expected by canary workloads:
- postgres-host.trade-infra.svc.cluster.local:5432
- redis-host.trade-infra.svc.cluster.local:6379

Application Surface

postgres in this namespace is an ExternalName alias that points to postgres-host.trade-infra.svc.cluster.local.
Hasura uses the live R001 secrets copied from trade-staging, but connects to the host Postgres on sol.
trade-api and trade-frontend use the current live images from Gitea registry and the same bootstrap wrapper/config pattern as the source environment.
The canary workflow re-runs:
- postgres-migrate
- hasura-bootstrap before it waits for Hasura, trade-api, and trade-frontend to become healthy.

Operator Flow

From the repository root:

./environments/sol/trade-r001-canary/scripts/prepare-sol-postgres.sh
./environments/sol/trade-r001-canary/scripts/create-gitea-registry-secret.sh
./environments/sol/trade-r001-canary/scripts/sync-live-secrets.sh

After the prerequisites are seeded, push to main and let deploy-trade-r001-canary apply the environment.