No Webhooks In Flight Substatus

Notifications (email + webhook) only fire at terminal (status, sub_status) pairs. In-flight sub-statuses like VendorOrderPending must not trigger any customer-f

Source memory file: feedback_no_webhooks_in_flight_substatus.md · Category: Feedback / working-preference This is a verbatim dump of Claude's persistent memory for the Octopus project. Rendered inside a code block so nothing is altered.

---
name: Never fire customer-facing notifications when sub_status is in-flight (e.g. VendorOrderPending)
description: Notifications (email + webhook) only fire at terminal (status, sub_status) pairs. In-flight sub-statuses like VendorOrderPending must not trigger any customer-facing event, even when the top-level status looks final (FAILED, CANCELLED).
type: feedback
originSessionId: 7fe8bffb-e88d-4c1b-b5db-499387047acf
---
Customer-facing notifications (email + webhook via `services.OrderNotifier`) fire **only at terminal `(status, sub_status)` pairs**. In-flight sub-statuses like `VendorOrderPending`, `VendorOrderCreated`, `VendorVoucherFetched`, `Processing` must never trigger a webhook or email — even when the top-level `status` is `FAILED` or `CANCELLED`.

**Why:** A `FAILED` order with `sub_status = VendorOrderPending` means the failure is preliminary — the refund hasn't run yet, the customer's wallet hasn't been credited, the lifecycle isn't done. Firing a webhook at that moment tells the client "your order failed" before the refund settles, and they may double-act on it (e.g. trigger their own refund flow on top of ours, or display a confusing UI). The webhook's contract is "this is the final word for this state" — only sub-statuses like `Refunded`, `Completed`, `Partial` carry that finality.

**How to apply:**
- The terminal pairs are: `(DELIVERED, Completed)`, `(PARTIALLY_DELIVERED, Partial)`, `(FAILED, Refunded)`, `(CANCELLED, Refunded)`. The notifier's `classifyOrderTransition` enforces this.
- Anywhere in the codebase that previously fired a webhook based on `status` alone, audit it — if the sub_status at that moment can be `VendorOrderPending` (or any in-flight value), the webhook is wrong and must move to the actual terminal transition site (typically the refund flow for FAILED/CANCELLED).
- Adding new states: extend the classifier with the new terminal pair; never branch on status alone in the dispatcher layer.
- This applies to webhooks AND emails uniformly. Both are customer-facing.