Phase 2.4: engine-side auto-compensation (deferred until real driver needs it)

[intel352]

Tracker for Phase 2.4 deferred candidates from workflow#695 Phase 2.5+ design. Currently no active driver requires this.

Scope (when revived)

1. Engine auto-compensation — when wfctl-side hook fails post-driver-success, engine attempts inverse RPC (Delete on created, Create on deleted). Records ActionStatusCompensated or ActionStatusCompensationFailed. Requires per-driver Compensable capability declaration; partial-state error handling; coordinated cascade.

2. Per-plugin emission of COMPENSATED — plugin v_next opt-in; plugin author decides emission semantics (e.g., DO deferred-flush could emit COMPENSATED on partial-flush success).

3. Per-resource-type compensation policy — per-Driver capability declaration.

Affordances already in place (workflow v0.57.1)

• interfaces.ActionStatusCompensated enum value reserved (interfaces/iac_state.go:168) — engine does NOT emit; plugins may emit if they implement own compensation
• interfaces.ActionStatusCompensationFailed enum value reserved — semantically defined for post-driver-success hook failure
• IaCProviderFinalizer.FinalizeApply (Phase 2.5) provides per-driver post-loop hook point that future compensation logic would extend

Why deferred

No driver currently emits COMPENSATED. Per memory project_open_followup_queue.md: "Deferred until a real driver needs it." Implementing speculatively risks design lock-in to a wrong abstraction. Wait for a concrete consumer (likely DO Spaces key rotation, or App Platform replace-with-rollback) to drive the requirements.

References

• ADR 0040 (v2 action lifecycle + provider compatibility) — invariant 2 (engine populates one ActionOutcome per PlanAction)
• workflow#695 Phase 2.5 (FinalizeApply) — established post-loop hook surface this would build on
• workflow#698 Phase 2.3 (ActionStatus enums) — established the COMPENSATED/COMPENSATION_FAILED values

[intel352]

Audit result: still relevant as intentionally deferred design scope.

Verified against latest origin/main: ActionStatusCompensated / ActionStatusCompensationFailed are reserved and IaCProviderFinalizer.FinalizeApply exists, but there is no engine-side auto-compensation implementation. That matches this issue's stated intent: keep it deferred until a concrete driver requires it.

[intel352]

Rechecked with workflow-plugin-infra latest origin/master (7d3b9ee, 2026-06-03 local fetch). That repo is currently an infra-admin/module surface that delegates lifecycle work to configured IaC providers; it does not introduce a concrete post-driver-success hook failure or provider-specific compensation semantic that would justify reviving engine-side auto-compensation in workflow core now.\n\nConclusion: still relevant, but still intentionally deferred until a real provider/driver path needs it. No workflow-core implementation for #704 in this batch.

[intel352]

Rechecked after workflow PR #850 merged and after fetching current defaults.

Evidence:

• workflow latest origin/main: 80c50ebd50d08c9f24b30c0933e73f831032e81d.
• workflow-plugin-infra latest origin/master: 002c6a27c3ff9246ba6aebc9ed5c81cd7720b411.
• workflow-plugin-infra is still an abstract infra.* module/admin surface. It delegates provider behavior to configured IaC provider plugins and does not add a concrete post-driver-success hook failure path, compensable resource capability, or provider-owned compensation semantic.
• workflow core still has the intended Phase 2.3/2.5 affordances: ActionStatusCompensated / ActionStatusCompensationFailed, ApplyPlanHooks.OnPlanComplete, and IaCProviderFinalizer.FinalizeApply. Post-hook failures are surfaced as COMPENSATION_FAILED; the engine still does not attempt speculative inverse RPCs.

Conclusion: #704 remains relevant as deferred design scope, but still should not be implemented in workflow core or moved into workflow-plugin-infra yet. The next action should wait for a concrete provider/driver path that can define Compensable behavior and failure semantics without guessing.

[intel352]

Re-triaged as part of the current issue sweep.

I’m leaving this deferred rather than implementing a speculative auto-compensation layer now. The issue’s prior conclusion still holds: the tracker should be driven by the first real driver that needs compensation semantics so the API, persistence model, and failure modes are grounded in an actual provider workflow instead of a placeholder abstraction.

No PR filed for this one in this sweep; it remains open as the tracker for that future driver-backed implementation.