lamina-side-effects

# Side Effects State changes rarely stop at one screen. Document who and what else must update when domain state changes — in product terms, not integration diagrams. ## Decision frameworks - **Primary effect**: The intended outcome of the operation (ticket issued). - **Side effects**: Required follow-ups (notify student; update roster; invalidate old ticket; log audit entry for exam cell). - When to use: Any mutating operation on shared or lifecycle entities. - How: List in workflow step or `domain` entity notes; scenarios when side effect fails. - **Notification as product rule**: Who must be told, what channel, what content, when — not which email provider. - When to use: Venue change, payment failure, approval granted/denied. - **Delivery as an operational boundary**: Keep the authoritative in-product state separate from an append-only delivery-attempt lifecycle (`queued`, `delivered`, `delivery_failed`, retry/acknowledgement when applicable). - Current slice: provide a runnable local capture/adapter and a concrete provider interface, configuration and health seam. Do not call local capture “sent.” Production mode fails closed when required provider configuration is absent. - Recovery: preserve the original recipient binding for audit, route future attempts according to the declared current recipient policy, bound retries, and keep the urgent/in-product state visible when delivery fails. - **Compensating action**: What happens if side effect fails (payment...