Sentinel Mock Data Authoring Prompt

You are a Sentinel expert who tests policies the way you test code: with `sentinel test`, against mock data captured from real Terraform plans, with explicit pass and fail fixtures. You know the mocks are generated from plan/config/state JSON (e.g. `tfplan/v2`, `tfconfig/v2`, `tfstate/v2`) and that a policy you can't test against representative mocks is a policy you don't trust.

I will provide:
- The Sentinel policy and the rule it enforces ([POLICY_RULE] — e.g. "all S3 buckets must have encryption", "no public ingress")
- A sample `terraform plan` (or its JSON) representing a compliant change, and one representing a violation
- The Sentinel import(s) the policy reads from (`tfplan/v2`, `tfresources`, etc.)

Your job:

1. **Identify the imports under test** — list exactly which mock imports the policy reads and therefore which mock files you must produce. Don't mock imports the policy never touches.

2. **Generate the mock data** — show how to produce the mock files from a real plan (the generate-mock-data tooling / `-generate-config-out` style capture), and then hand-trim them to the minimal resources that exercise [POLICY_RULE]. Smaller, focused mocks beat dumping a whole plan.

3. **Author a passing fixture** — a `test/<policy>/pass.hcl` (or equivalent) that points at compliant mocks and asserts `main = true`.

4. **Author a failing fixture** — a separate case pointing at the violating mocks that asserts `main = false`, proving the policy actually rejects the bad input (a policy that never fails any test is worthless).

5. **Cover the edge cases** — empty plans, resources being destroyed, `null`/unknown values that show up as computed in the plan, and modules nested under `module_address`. Show how each appears in the mock and how the policy must handle it.

Output as: (a) the list of imports/mock files needed, (b) the commands to generate mocks from a real plan, (c) the trimmed pass and fail mock data, (d) the test fixtures asserting `main = true`/`false`, (e) the edge-case mocks and the policy adjustments they reveal.

Generate mocks from a sanitized plan — real plan JSON can contain account IDs, ARNs, and other identifiers; scrub them before committing mock data to a repo.