Context
PR #639 adds the v2 apply hook path so wfctl can persist state after each successful cloud mutation and prune delete state only after confirmed delete success. The old/v1 apply path still exists for compatibility, and PR #639 keeps conservative behavior there where possible.
That means v1 is now compatibility debt: it lacks the explicit action-boundary lifecycle contract we need for reliable drift/import/state behavior across providers.
Goal
Migrate wfctl and provider integrations onto the v2 action lifecycle, then deprecate and remove legacy/v1 apply support once compatibility is proven.
Scope
- Inventory all call sites still using legacy apply behavior.
- Define provider compatibility expectations for v2 apply.
- Add conformance coverage proving providers work through v2 action lifecycle semantics.
- Add deprecation warnings or docs once migration path is clear.
- Remove v1 apply code after releases/plugins no longer require it.
Required invariants
- State persists after each successful cloud mutation, not only after whole-plan success.
- Failed deletes do not prune state.
- Create/replacement persistence/routing/validation failures compensate cloud resources and routed secrets.
- Update failures do not delete existing managed resources.
- Provider-specific drift/import logic stays in providers; workflow owns generic plan/apply lifecycle semantics.
Notes
This should follow PR #639 and any plugin conformance updates. The migration should not be bundled into provider-specific fixes unless a provider is only changing to satisfy the v2 lifecycle contract.
Context
PR #639 adds the v2 apply hook path so wfctl can persist state after each successful cloud mutation and prune delete state only after confirmed delete success. The old/v1 apply path still exists for compatibility, and PR #639 keeps conservative behavior there where possible.
That means v1 is now compatibility debt: it lacks the explicit action-boundary lifecycle contract we need for reliable drift/import/state behavior across providers.
Goal
Migrate wfctl and provider integrations onto the v2 action lifecycle, then deprecate and remove legacy/v1 apply support once compatibility is proven.
Scope
Required invariants
Notes
This should follow PR #639 and any plugin conformance updates. The migration should not be bundled into provider-specific fixes unless a provider is only changing to satisfy the v2 lifecycle contract.