Deep Before Wide

User prefers exhaustive depth on one resource over breadth across many. Especially true for testing/correctness work.

Source memory file: feedback_deep_before_wide.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: feedback-deep-before-wide
description: User prefers exhaustive depth on one resource over breadth across many. Especially true for testing/correctness work.
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 4a756616-78f2-4e8f-a906-fd34e36a1824
---

When scoping testing, refactoring, or hardening work that could plausibly fan out across multiple resources/verticals, **default to one resource fully covered before starting the next.** Build the reference suite (voucher), then port the same shape to topup, then eSIM.

**Why:** User explicitly course-corrected during the voucher/topup/eSIM money-leak test plan: "let's focus on one thing and do it well... we'll start with the vouchers first. Super deep and extensive tests first. I want to be confident that there's no monetary leak anywhere in this API. We'll port over the same changes to the other two resources after this." Parallelizing across verticals dilutes attention and produces shallower coverage everywhere.

**How to apply:**
- When the natural test/refactor plan would touch >1 resource with similar shape, propose the one-resource-first version unless the user says otherwise.
- Within the chosen resource, go *deep* — failure paths, refund symmetry, concurrency, idempotency, conservation invariants — not just happy paths.
- After the reference is locked and the user is confident, port the same harness shape to siblings.

Related: [[feedback_repo_test_coverage]], [[feedback_vendor_chaos_and_tests]] — same "ship the full coverage with the change" mindset, just scoped per-resource.