Notification Scope Discipline

When working on the order notification system (OrderNotifier, email/webhook fanout), keep changes strictly to notification dispatch. Don't refactor wallet refun

Source memory file: feedback_notification_scope_discipline.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: Notification work stays in scope — don't bundle wallet/refund/lifecycle logic
description: When working on the order notification system (OrderNotifier, email/webhook fanout), keep changes strictly to notification dispatch. Don't refactor wallet refund flows, status-transition logic, or other adjacent concerns even when they appear to be "the right shape" for the centralisation.
type: feedback
originSessionId: 7fe8bffb-e88d-4c1b-b5db-499387047acf
---
When working on order notifications (OrderNotifier, BuildVoucherEmailData, classify/dispatch), keep changes strictly inside the notification layer. Don't drag wallet refund, status-transition, or other lifecycle logic into the same change — even when extracting a shared helper "feels right."

**Why:** I made this mistake by adding `services/order_refund.go` (`RefundOrderToWallet`, `FireWalletCreditedWebhook`) and restructuring the dispatcher's FAILED branch to do an atomic wallet credit, all framed as "fixing the FAILED notification gap." The user stopped me: "don't make wallet updates.. You just focus on notification flows." The refund/wallet flow is owned separately and may already be planned for a different change. Bundling it into the notification PR muddies the diff, expands review scope, and risks regressions in unrelated systems.

**How to apply:**
- Notifier work touches: `services/order_notifier.go`, `services/voucher_email.go`, the email templates, and the call sites that *invoke* the notifier (`h.OrderNotifier.Notify`, `Resend`, `ResendAsync`).
- Notifier work does NOT touch: wallet repositories, `UpdateWalletBalance`, refund transactions, status-transition restructuring, or anything that produces the `(FAILED, Refunded)` / `(CANCELLED, Refunded)` transition.
- If the notifier needs an order to be in a terminal sub-status that doesn't exist yet (e.g. `(FAILED, Refunded)` has no producer), surface that as a gap — don't fix it inside this work. Ask whether to wire notifier.Notify into an existing transition site, leave it for a follow-up, or get the user to point at the right site.
- "Atomic" is a red herring for splitting concerns. The refund and the notification are separate events; eventual consistency between them (refund → terminal sub-status → notifier picks it up later) is a valid design and avoids mixing layers.