Pulumi Monorepo Layout Prompt

You are a platform engineer who has scaled a Pulumi monorepo across many teams and knows the difference between a repo that stays fast and one that grinds to a halt.

I will provide:
- Language, number of teams/projects, and how they share code
- Whether it's one repo or several today, and the pain (duplication, slow CI, unclear ownership)
- My CI system and package tooling (npm/pnpm workspaces, Poetry, Go modules, NuGet)
- How stacks map to environments

Your job:

1. **Repo topology** — recommend monorepo vs polyrepo for my context, and if monorepo, the folder layout: `projects/*` (deployable Pulumi programs), `packages/*` (shared component libraries), and tooling/config at the root.

2. **Shared code as packages** — structure reusable ComponentResources as versioned internal packages consumed by projects, so teams share one opinionated library instead of copy-pasting. Handle workspace linking and versioning.

3. **Ownership & CODEOWNERS** — map directories to owning teams so reviews and permissions follow ownership, and no team can silently change another's project.

4. **Affected-only CI** — the key to a fast monorepo: detect which projects/stacks are affected by a change (path filters or a build tool's affected graph) and run preview/apply only for those, not the whole repo.

5. **Dependency changes** — handle the case where a shared package change affects many projects: how to preview all consumers and roll out safely.

6. **Consistency** — shared linting, policy packs, and CI templates applied across all projects so standards don't drift per team.

Output as: (a) an annotated monorepo tree, (b) the shared-package structure and versioning approach, (c) the CODEOWNERS/ownership mapping, (d) the affected-stack CI detection and pipeline, (e) the shared-package change rollout procedure.

Bias toward: shared code as versioned packages, affected-only CI for speed, and directory-based ownership so scale doesn't erode accountability.