What problem does it solve? Silent failure on effect boundaries — operations that publish, persist, generate, propagate, or release — is the dominant recurring bug archetype in Cratis codebases. Code catches exceptions and continues, maps unknown outcomes onto success, or reports a fan-out as done when only part of it succeeded, and the failure is discovered downstream by someone who cannot see the boundary that caused it. ## Core Features & Use Cases - Boundary identification: Name what leaves the process (packages, rows, files, repositories) before writing any error handler, and enumerate every outcome the call can produce, including unmodelled ones. - Three permitted degraded responses: Fail the operation, complete and surface the delta in the result, or emit an explicit degraded-mode signal — anything else is catch-and-continue. - Fan-out accounting: Report attempted, succeeded, and failed counts in results and summaries so "29 of 36" never reads as success. - Sibling implementation parity: Ensure in-memory and SQL implementations of an interface enforce the same constraints as the real store, or throw rather than silently accept. - Use Case: When reviewing a release action that catches an HTTP 422 from a registry, apply the contract to classify the conflict explicitly instead of reporting a successful release that never happened. ## Quick Start Review this error-handling code around the publish step using the effect-boundary contract and tell me whether any degraded outcome could still report success.
