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. Both live in the same GCP project for now, split by resource naming (-dev / -prod suffixes).
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):