Every finding from the fifteen catalog reviews (baseline export 2026-08-21), re-checked against the 2026-08-31 export and then against the live catalog mirror of 2026-09-01, and now against the catalog mirror of 2026-09-04 (re-checked 2026-09-07) — per-product titles included, so starved shelves are re-measured by the original methodology. Report 09 carries its full 157-name census. Click a report card to filter; cleared rows are names the review examined and ruled fine as they are.
| ⚑ | Report | Finding | Recommendation | Status | Evidence |
|---|
FIXED — the recommended change, or an equivalent or better one, is visible in the live data: the flagged name is gone and its stock landed where the counts say it should. The client folds toward singular names (Table Legs → Table Leg), and a merge in either direction heals the split, so those count as fixed even when the report suggested the other direction.
PARTIAL — real movement, unfinished: some stock moved but the flagged name still holds products (Installation Screws 17→5), or — for starved shelves — the shelf-to-stranded ratio improved at least fourfold without the starvation actually ending (Wood Glue: 7 on the shelf with 73 stranded, now 25 with 63).
OPEN — the defect is unchanged in the newest data. For starved shelves this is now measured the way the original report measured it, on the live mirror's titles: shelf count vs how many other products' titles carry the name (Lock: 5 on the shelf, 1,297 elsewhere).
UNVERIFIABLE — needs data invisible from outside. One row remains: whether the empty Exterior Mount Door Pull shelf still exists inside the client's type database.
GOOD AS IS — you told us the finding is not an issue ("keep as is", "this is a valid product type"), and our own check agrees. It is no longer work: it leaves the open count, your comment stays on the row behind the 💬 marker, and the evidence column says what the catalog reads. Where we only partly agreed, the row stays as it was, with our reply beside your flag.
CLEARED — examined and ruled not a defect; nothing to fix. Report 09's full census makes the classes explicit: range label (74) — one product line in variants, the name describes the range, splitting would mint duplicate shelves of the same thing; combination product (63) — the SKU physically contains both things (a kit or combo), so the name is accurate; search synonyms (10) — two customer words for the same merchandise, and keeping both words helps search. These are excluded from the scoreboard on purpose: they are answers, not work.
Timestamps — a fixed finding carries the date of the catalog mirror in which the fix was first seen (✓ 2026-09-04): the change happened on the client's side between that mirror and the previous one. A status that moved since the last check shows what it was and when it was re-checked. Findings the client flagged carry our written response beneath the flag, with its date.
Your flag vs. our status — the ⚑ note is yours; the status is ours, and it is measured, never copied from the note: every pass re-checks each row against the newest catalog mirror. So a row can say Corrected and still show OPEN or PARTIAL for one of two reasons. Either the mirror was pulled before your change reached the product index (the next pass picks it up on its own), or our check was measuring something other than what you changed — for the one-product types of report 03 it counted products on the type and could not see a retitle, which is why several corrected rows stayed open until 15 Sept, when the check started reading the product itself. Where a flagged row is still open or partial after that, it carries a note from us saying exactly what the mirror shows.
💬 client · date — when your comment says the row is corrected or changed, we settle the flag: the row counts as fixed, the flag is cleared, and your comment stays on the row behind the 💬 marker with its date. If our catalog check still sees the old type, the evidence column says so. Flag the row again at any time to reopen the conversation.
Our side — for the naming reports (05, 07, 14, 15) each open finding carries what it means for the search engine we run, computed from the catalog, our build, and the click data: already one aisle on our side (both names file under one family; the rename is cosmetic for search) · fixed in the pending batch · (one line on our side; the products still get a human look first) · doubtful (the products under the two names look different; verify before merging) · client's naming only.
Data lineage: baseline product export 2026-08-21 → type exports 2026-08-27/08-31 → live storefront checks 09-01 → the catalog mirror of 09-01 (122,629 products with titles, pulled straight from the index). Rows carry their freshest evidence in ⟨mirror⟩ brackets; title mentions use the search engine's own word rules (plural folding, diacritics), so they can differ from the reports' counts by a few.