`5x/REPORT.md`

63 lines
# TK-11448 — /5x verify-and-fix report

Target: the work shipped under TK-11448 — 33 products archived on Shopify, 105 FileMaker
`Date Discontinued` stamps, and the measurement claims the archive decision rested on.

**Adaptation, stated up front:** `/5x`'s stock six-way suite drives a running web app. What shipped
here is a *data-state change* plus a live storefront surface, so the loop is unchanged (catch → fix →
re-sweep, stop on two consecutive clean, cap 5) while the sweep content is what can actually go red
for this change. Real-browser breadth was not the instrument; live HTTP against the storefront was.

## Sweep ledger

| sweep | checks | caught | fixed | commit |
|---|---|---|---|---|
| 1 | S1 S2 S3 S4 S5 | **8** — all 8 archived products read as "still buyable" | root-cause fix to the probe | `c0bbc10` |
| 2 | same suite | 0 | — | — |
| 3 | S2 widened 8 → **33**, added S2b fault injection | 0 | — | `6308654` |
| 4 | identical to 3 | 0 | — | — |

Stopped at sweep 4 of 5: **two consecutive clean sweeps of the identical suite** (3 and 4).
Sweep 2 was clean but on a narrower suite, so it was not counted toward the stop condition.

## The one real defect, and why it mattered

Sweep 1 reported all 8 archived products as **still buyable**. That was the *instrument* being wrong,
not the archive:

> An archived Shopify product URL **302s to the HOMEPAGE**, and the homepage returns 200.
> The probe used `redirect: 'follow'`, so it measured the homepage and called it the product.

curl reported a straight `404 / Page not found` at the same URL — the disagreement is what exposed it.
This is the same false-signal class the whole ticket is about: a check reporting a state for something
it did not actually measure.

**Fix (root cause, not a suppression):** classify at the product URL itself — `3xx` or `404` or a
404-body ⇒ gone; `200` **with an add-to-cart form** ⇒ buyable; anything else ⇒ NOT_MEASURED, never a
pass. Plus a **control**: a still-ACTIVE product must come back buyable, so a probe that has stopped
detecting anything cannot pass by calling everything "gone".

## Final state (sweep 4)

| check | result |
|---|---|
| S1 Shopify status | 33/33 ARCHIVED · 17/17 fix-set still ACTIVE · keeper `dwrw-76636` ACTIVE |
| S2 live storefront | 33/33 no longer buyable · control `dwrw-74784` buyable=true |
| S2b fault injection | live product ⇒ buyable, bogus handle ⇒ gone — **probe discriminates** |
| S3 FileMaker | 105/105 rows dated · negative control `DWRW74784` 4 rows, **0** dated |
| S4 undo ledgers | 33 + 105 rows, every one carrying prior value + executable undo |
| S5 claims re-derived | 631/631 measured, 0 still screenshot · 51 placeholder hits, 0 unmeasured · 33+17+1=51 |

Every check carries a control that must behave the *opposite* way, so a check that silently measures
nothing shows up as a defect instead of a green.

## Open / noted

1. **Archived products soft-404 to the homepage** rather than returning 404. Google treats a
   redirect-to-homepage as a soft 404, and it is a known `landing_page_error` cause. **Checked, not
   assumed:** 0 of the 33 appear in the 62,507-row live GMC offers index, so this archive creates no
   new feed errors. Worth knowing for future bulk archiving.
2. Nothing was suppressed and no assertion was weakened to reach green. The only edit across four
   sweeps was to a measuring instrument that was provably wrong, and it shipped with a control and a
   fault-injection test proving it can still go red.