diff --git a/src/lib/order-feed.ts b/src/lib/order-feed.ts
index a42ad44..21c2629 100644
--- a/src/lib/order-feed.ts
+++ b/src/lib/order-feed.ts
@@ -103,8 +103,13 @@ export interface OrderFilters {
  * Rows with no amount, no order reference and a single lifecycle event are not
  * purchases — they are a second entity minted from a mail describing an order
  * that already exists (Amazon "share your experience", DoorDash no-contact
- * delivery details, shipment notices). 755 of them; hiding lifts amount
- * coverage from 74% to 84%.
+ * delivery details, shipment notices). 904 of them as of 2026-08-12.
+ *
+ * It hid 755 when written. Board 219's zero-to-null repair took it to 904:
+ * those 149 rows had been failing the "no amount" test on a technicality — an
+ * unstated 0 they should never have carried — and they match the phantom
+ * signature on every other count, so hiding them is the predicate working, not
+ * collateral damage.
  *
  * This is a WORKAROUND for board 210, not a fix. The upstream defect is that a
  * lifecycle mail printing no order reference cannot join its own order, so it
@@ -114,6 +119,14 @@ export interface OrderFilters {
 const LIFECYCLE_ONLY = `NOT (
   f.order_total IS NULL
   AND f.reference_source = 'message_id_fallback'
+  -- TRIED AND REVERTED, 2026-08-12: exempting rows that carry line items, on
+  -- the theory that naming what was bought proves a purchase. It surfaced 442
+  -- rows and the very first window showed why it is wrong — the Amazon
+  -- "Ordered:" mail that mints a msg- phantom carries the item list too, so
+  -- Xelsluthe and YIWENTEC each rendered TWICE again, which is the exact
+  -- complaint this page was fixed for. Items do not separate an orphan
+  -- purchase from an item-carrying echo; only real deduplication does, and
+  -- that is board 210, deliberately not attempted here.
   AND (SELECT count(*) FROM extracted_facts ef
         WHERE ef.fact_type = 'order_event'
           AND ef.payload->>'_order_entity_key' = f.entity_key) <= 1