bridge-parity-investigation

name	bridge-parity-investigation
description	Investigate established Pulumi-vs-Terraform parity gaps with bridge cross-tests. Use after triage establishes that Pulumi fails while Terraform succeeds and selects bridge parity work, or when the user asks for a bridge cross-test.

Bridge Parity Investigation

Use this skill only when the issue is already understood as a real parity gap: Pulumi has the problem, Terraform does not, and the bridge is the next evidence surface.

This skill is cross-test-only. Do not spend time debating provider-only tests, generic pkg/tests, or other harnesses here. If parity is not established, stop and switch back to the appropriate repro skill.

Stay in the bridge lane. Do not restart broad issue triage here unless the cross-test evidence contradicts the established parity story. Prefer triage-provider-issue first unless a prior pass already established the parity gap and selected this helper, or the user explicitly invoked this skill.

Read references/cross-test-playbook.md before editing.

Goal

Turn the parity gap into the smallest useful bridge cross-test investigation and narrow the failing boundary enough that the next pass can reason about root cause or workaround work.

Workflow

1. Restate the established parity gap in one line. Example: "Pulumi update+read fails, Terraform equivalent path succeeds."
2. Identify the lifecycle path that must be preserved. Examples: update then read, refresh, import, diff.
3. If the work belongs in the bridge repository, continue there only when the environment can preserve correct repository and artifact ownership. Otherwise leave a bridge-repository handoff with the exact cross-test required.
4. Build or refine the bridge cross-test around that path.
5. Preserve the dataflow that matters, not just the final values.
6. Instrument the failing boundary narrowly.
7. Run the targeted cross-test.
8. Record what the test proves and what it still does not prove.

Operating Rules

• Do not start this skill unless Terraform behavior is already known.
• Preserve lifecycle shape first, then minimize.
• If a synthetic case is too clean to reproduce the parity gap, widen only the dataflow you need. Avoid copying large chunks of provider business logic.
• If a bridge panic would crash the test process, recover it into an assertable test failure rather than abandoning the cross-test approach.
• Keep the output focused on the parity boundary, not a full implementation theory.
• If the bridge cross-test shows the parity gap cleanly, that is success even if the final root cause is not finished yet.
• If a focused cross-test still cannot preserve the real discriminator, stop, record exactly what constraint prevented it, and hand control back with that constraint instead of looping indefinitely on cross-test shaping.

Deliverable

Leave behind:

• current state
• confidence
• what is settled
• what is not settled
• next best action
• the focused cross-test
• the exact command to run it
• the lifecycle path preserved by the test
• the narrowed failing boundary
• the next unresolved bridge question
• what blocked execution, if anything
• workaround status