Memory Appendix
No Speculative Vendor Paths
When fixing a vendor mapper bug, only handle the product types we actually receive — don't add untested branches for types we may never encounter
Source memory file:
feedback_no_speculative_vendor_paths.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: No speculative code paths for vendor product types we don't use
description: When fixing a vendor mapper bug, only handle the product types we actually receive — don't add untested branches for types we may never encounter
type: feedback
originSessionId: 6d23a24a-1767-4fe7-a186-f9c12bad237a
---
When fixing a bug in a vendor catalog mapper (DT One, SEAGM, etc.), only add code for product types that actually appear in our catalog. Don't add speculative handling for documented-but-unused types.
**Why:** While fixing DT One amount mapping (Nov 2026), I added a `RANGE_VALUE_RECHARGE` branch reading `destination.min`/`max`. The user pushed back: zero range products in the seed, no range support in the order-creation path, no UI for picking an amount within a range. The branch was dead weight that gave a false sense of correctness. The actual bug was that `FIXED_VALUE_PIN_PURCHASE` (Lebara/Lyca PINs) wasn't being treated as fixed — that's the only thing worth fixing.
**How to apply:** Detect what we use (e.g. `strings.HasPrefix(dp.Type, "FIXED_VALUE_")` covers RECHARGE + PIN_PURCHASE), let unsupported types fall through with `IsFixedAmount=false` and nil min/max. If a range product ever shows up in production we'll notice it broken and add the full path then — order code, UI, mapper. Don't half-implement vendor paths.