Wendy GCP Deployment

How Wendy deploys to Google Cloud. Status: intermediate. These conventions hold until v1 of the stack runs and the compute workload is consolidated (possibly k8s/GitOps later). The methodology (Pulumi, OIDC, PoLP) is expected to survive that transition; specific names may not.

Hard rules (non-negotiable)

1. Requirements before infrastructure. Never design infra without asking the user about the app's requirements first (see interview below). Never invent project names, regions, or scale assumptions.
2. Cost-consciousness is a MUST, not a preference. Read references/cost.md before choosing compute or a database.
3. PoLP via custom IAM roles. Prefer a custom role with the exact permissions needed over any predefined broad role. Needing to alter one DNS record never justifies roles/dns.admin. See references/iam-polp.md.
4. No service account keys. Ever. CI authenticates via GitHub OIDC / Workload Identity Federation (references/github-oidc.md); workloads use attached service accounts. If you are about to write credentials_json, export a key, or suggest one "as a stopgap" — stop; that path does not exist here.
5. No GCP credentials client-side. Frontends, device apps, anything running outside Wendy's server perimeter never holds GCP credentials of any form. Devices get mediated access via server-side proxies minting short-lived downscoped credentials (wendy-proxy pattern). Authority: the AAA contract, /home/sem/wendy/aaa-contract-*.md (read the latest version when touching auth between services).
6. dev/prod split by default. Default branch deploys to dev; semver tags (v*) deploy to prod. Skip the split only with a stated good reason. Today each repo keeps every env in one GCP project, split by resource naming (-dev / -prod suffixes): pki-core wendy-pki-secure, cloud cloud-c7e56 (incl. legacy-prod), wendy-auth wendy-auth (its envs are test / prod). Source: gcp:project (wendy-auth foundation: projectId) in each Pulumi.<stack>.yaml, foundation and platform. Every v* tag is a GitHub Release with generated notes. pki-core, wendy-auth and cloud additionally split each env into a foundation stack (network, DNS zones, custom IAM roles; applied by hand) and a platform stack (applied by CI, whose deploy SA is never widened) — see references/iam-polp.md.
7. Never clash with pre-existing resources. Check before creating — especially DNS records (references/dns.md) and anything in shared projects.

Requirements interview (always first)

Before proposing any design, ask the user (don't assume):