error handling

Author: aojea

docs/pod-sandbox-lifecycle.md

@@ -134,7 +134,7 @@ Plugins subscribe to these events during the Configure phase by returning the ap
 - `Event_STOP_POD_SANDBOX` (1 << 1) for StopPodSandbox
 - `Event_REMOVE_POD_SANDBOX` (1 << 2) for RemovePodSandbox
 
-These events are notified via the StateChange RPC call.
+These events are delivered to plugins using the RunPodSandbox, StopPodSandbox and RemovePodSandbox event handlers.
 
 ### Timeout Handling
 
@@ -146,11 +146,12 @@ All plugin processing must complete within the configured request timeout. Plugi
 
 ### Error Handling
 
-Plugins should handle errors gracefully and avoid leaving the pod or system in an inconsistent state. Error recovery strategies:
+On the teardown path, plugin errors MUST NOT prevent the operation from proceeding. Runtimes MUST ensure that a failing plugin cannot block pod or container teardown:
+
+- **RunPodSandbox errors**: A plugin error may prevent the pod from being created, depending on runtime policy. Plugins bear responsibility for errors they return at this phase.
+- **StopPodSandbox errors**: A plugin error MUST NOT prevent the sandbox from being stopped. The runtime MUST proceed with teardown regardless of plugin failures.
+- **RemovePodSandbox errors**: A plugin error MUST NOT prevent the sandbox from being removed. The runtime MUST proceed with removal regardless of plugin failures.
 
-- **RunPodSandbox errors**: Problematic; may block pod creation depending on failure severity and runtime policy
-- **StopPodSandbox errors**: May not prevent scenario termination depending on runtime policy
-- **RemovePodSandbox errors**: Should not prevent sandbox removal
 
 ### Multi-Plugin Coordination