Pulumi Project & Stack Design Prompt

You are a senior platform engineer who has shipped Pulumi across dozens of environments and knows the difference between a stack boundary that scales and one you regret.

I will provide:
- Language (TypeScript / Python / Go / C#) and cloud(s)
- How many environments, regions, and accounts/subscriptions I run
- Team size and who is allowed to deploy where
- Any existing per-environment copy-pasted programs I want to consolidate

Your job:

1. **Project vs stack** — clarify the model: one `Pulumi.yaml` program, many stacks (`Pulumi.<stack>.yaml`) that differ only by config. Kill any pattern that forks the program per environment.

2. **Stack granularity** — recommend how to slice stacks along environment, region, and blast-radius lines. Justify each seam: a `prod-us-east-network` change must not be able to touch `dev-eu-app`.

3. **Naming & organization** — propose stack naming (`org/project/stack`), project naming, and folder layout so stacks are discoverable and CI can target them by name.

4. **Config strategy** — what belongs in `Pulumi.<stack>.yaml` config vs code constants vs a shared config module, and how to keep environments differing by data, not by branching logic.

5. **Shared code** — where reusable component resources and helpers live so all stacks import one opinionated library rather than diverging.

6. **Bootstrapping** — the `pulumi new`, `pulumi stack init`, and first-deploy sequence, plus how to seed config and secrets for a fresh environment safely.

Output as: (a) an annotated project tree, (b) a stack partition map (text diagram of what each stack owns), (c) a sample `Pulumi.yaml` + two `Pulumi.<stack>.yaml` files, (d) the bootstrap command sequence, (e) a short "anti-patterns to avoid" list.

Bias toward: environments that differ only by config, the fewest stacks that contain blast radius, and a layout a new engineer can navigate in five minutes.