When parse-guard intentionally lets a deal through
The 5%-of-list floor doesn't apply when there's no list price — and that's where the best Home Depot mistakes live.
The parse-guard rejects scrapes where `current_price < 5% × list_price_usd`. That clause has a deliberate asymmetry: targets with NO `list_price_usd` set are not gated at all. Why? Because that's where the best Home Depot penny errors live, and a 5% floor would silently hide them.
The HD penny pattern
Home Depot's clearance system has a quirk: when a SKU is being end-of-lifed, internal pricing rules occasionally produce \$0.01 to \$0.20 prices for valid in-store inventory. The candidates discovered via SerpAPI's home_depot engine for these don't carry a strikethrough/regular price (HD only surfaces `regular_price` for actively-marked-down items, not for pricing-system anomalies). When we promote them to live targets, `list_price_usd` is null. The parse-guard sees null, skips the comparison, and lets the alert fire.
Why this is safe
The risk we were solving with parse-guard was an accessory-cell at \$17.99 firing as a $1199 laptop deal. That class of bug requires a wrong reference price (the laptop's list) AND a low scraped price (the accessory). The HD penny case has no reference price at all — it's just 'this thing scraped at $0.06.' The detector's other layers (rolling-baseline drop %, threshold_drop_pct, manual floor_usd) still gate the alert. And in practice, $0.06 IS the price; the only question is whether stock is real, which the per-store check handles.
Setting list_price wisely
If you DO know the list price for a target (you saw it on the product page when you set up the watch), set it. The parse-guard then catches accessory-cell pollution. If you don't know it or aren't sure, leave it null — better to risk one false positive than to silence a real glitch behind a stale reference price.