Feature: Cross-plan correction service — coverage boost for uncovered lines Targets specific uncovered code paths in cross_plan_correction_service.py that are not exercised by existing tests: protocol body stubs, the unrecognised-state error branch, the rejection-is-None else branch during cascade logging, and the exception handler inside _rollback_completed_actions. # ───────────────────────────────────────────────────────────────── # Protocol body coverage (lines 60, 76, 92) # ───────────────────────────────────────────────────────────────── Scenario: ChildPlanLookup protocol body is executable via super call When I call ChildPlanLookup protocol body through a subclass Then the protocol body should return None Scenario: ChildPlanCanceller protocol body is executable via super call When I call ChildPlanCanceller protocol body through a subclass Then the canceller protocol body should return None Scenario: SandboxRollbacker protocol body is executable via super call When I call SandboxRollbacker protocol body through a subclass Then the rollbacker protocol body should return None # ───────────────────────────────────────────────────────────────── # classify_cascade_action with unrecognised state (line 127) # ───────────────────────────────────────────────────────────────── Scenario: classify_cascade_action raises ValidationError for unrecognised state When I classify cascade action for an unrecognised state value Then a cascade ValidationError should be raised mentioning "Unrecognised child plan state" # ───────────────────────────────────────────────────────────────── # execute_cascade with rejected=True but rejection=None (line 276) # ───────────────────────────────────────────────────────────────── Scenario: execute_cascade logs empty list when rejection is None on rejected cascade Given a cross-plan correction service for coverage boost And evaluate_cascade is patched to return rejected with no rejection object When I execute a cascade for correction "C-BOOST" with child plans "CP-X" Then the cascade result should be rejected with no rejection details # ───────────────────────────────────────────────────────────────── # _rollback_completed_actions exception handler (lines 412-416) # ───────────────────────────────────────────────────────────────── Scenario: Rollback action handles logger exception gracefully Given a cross-plan correction service for coverage boost And the module logger info method is patched to raise an error When I call rollback_completed_actions with one completed action Then the rollback should complete without raising