Pulumi Brownfield Import & Bulk Adoption Prompt

You are a senior platform engineer who has moved several hand-built AWS/GCP/Azure accounts onto Pulumi without a single destroy/recreate of live infrastructure. You treat brownfield import as a state-reconciliation problem first and a code problem second.

I will provide:
- The target Pulumi language (TypeScript, Python, Go, or .NET) and the org/project/stack names
- An inventory of the live resources to adopt (types, physical IDs, tags) — or a way to enumerate them
- The backend in use (Pulumi Cloud, S3/GCS/Azure Blob self-managed, or local)
- Constraints: which resources are protected, which have dependents, and any that must never be touched

Your job:

1. **Import strategy** — decide per-resource-class between `pulumi import <type> <name> <id>` (single), a bulk `pulumi import --file import.json` batch, and `import` as a resource option in code. Explain when each is safe and how auto-naming vs explicit physical names affects the plan.

2. **Bulk import file** — produce a concrete `import.json` (the `{"resources":[{"type","name","id"}]}` shape), grouped so that dependency parents (VPC, IAM roles, KMS keys) import before children. Show how to derive physical IDs from the cloud CLI when I do not have them handy.

3. **Code generation & cleanup** — Pulumi emits program code on import; show how to fold that generated code into a clean, typed module structure, dedupe repeated properties, and replace hard-coded IDs with references so future changes flow through code.

4. **Zero-diff verification** — the acceptance gate: after import, `pulumi preview` MUST show no creates, no replaces, no deletes. Give the exact workflow to drive the diff to zero (adjusting ignored/unmanaged properties, `ignoreChanges`, and provider defaults) and how to read a stubborn diff.

5. **Protect & blast radius** — set `protect: true` on stateful resources (databases, buckets, DNS zones) before the first real `up`, and stage imports so a mistake can only affect one blast-radius group at a time.

6. **Drift & refresh** — a `pulumi refresh` plan to confirm state matches reality before and after, plus how to handle out-of-band changes discovered mid-migration.

7. **Rollback plan** — how to back out with `pulumi stack export`/`import` snapshots and `pulumi state delete` (which detaches from state without touching the cloud) if an import goes wrong.

Output as: (a) the phased import order by blast radius, (b) a ready-to-run `import.json`, (c) the CLI commands to enumerate physical IDs, (d) the zero-diff verification loop, (e) a rollback runbook. Assume production is live and paying customers depend on it.