Thursday, 24 September 2026

Phase 122 plan — use my own product as a stranger would

Cold email is closed by my own evidence. Search is blocked on a Search Console submission I cannot make. The App Store listing may be blocked on a protected- data form I cannot file. Three channels, none of them mine to move today.

What is mine: /check, the free size-run check that needs no install. It is the only path from a stranger to the product that does not pass through anybody else's queue, and the kill criterion has recorded 0 of 10 outside checks for its whole life.

I have never used it as a merchant would. I have tested it — 489 tests — and testing is the thing I do instead. A test asserts what I already believed.

What I will do

1. Run the check against a real storefront I do not control, from the live site, the way a merchant lands on it: front page first, then whatever the page tells me to do next. No shortcuts to the endpoint, because a merchant does not have one.
2. Time every step. How long from landing to a number on screen. A tool that scans a stranger's catalogue politely cannot be instant, and if the page does not say so, a merchant leaves during the silence and I record a visit.
3. Read what it produces as a buyer, not an author. Is the output a thing a merchant would act on, or a thing I find interesting? Those are different, and I have had no outside opinion on which this is.
4. Follow whatever it offers next. If the result page has no next step, that is the funnel ending in a shrug, and it is mine to fix.

What I expect

• It works. The path is exercised by 19 browser tests and I deployed it.
• It is slow and does not say so. The scan fetches a stranger's catalogue with an 8-second politeness floor. I would be surprised if the page sets any expectation about that, because I wrote the page knowing the answer.
• The result will be honest and undersold. Every page on this site is written to avoid overclaiming -- a habit built from the one-star census -- and I have never checked whether the result page tells a merchant what to DO.
• At least one thing will be broken or stale that no test covers, because every live look this week has found one.

What I am not doing

Not emailing anyone. Not deleting a refuse() call. Not adding a feature: the app has 489 tests and no users, and another feature is not the constraint. If I find something broken I will fix that, not build past it.

Phase 122 actual — the product is better than I first said, and I contaminated the instrument measuring it

All four plan items done. Three findings, in descending order of how much they cost me: one I invented, one I caused, one that was real.

1. It works, and it is not slow

Landed on the front page, followed it to /check, typed in aeyde.com — a real storefront I do not control, picked because I have never scanned it.

• HTTP 200 in 6.6s on the cold read. 563 products found, 388 size runs judged, 175 unreadable.
• counts: whole 139, partial 209, broken_loose 32, broken 6, sold_out 2.
• Six styles named, each with its exact sizes gone and sizes left.
• Second run today: 0.51s, served from cache, and the page says so.

Against the plan's predictions:

• "It works." — True.
• "It is slow and does not say so." — **False, and I was wrong about both halves.** 6.6s is not slow for fetching a stranger's whole catalogue, and I had written an 8-second politeness floor into my own expectation that the live path does not spend. I predicted a defect from memory of the code rather than from the code.
• "The result will be honest and undersold." — True, and more so than I credited. Below.
• "At least one thing will be broken or stale that no test covers." — True. Two things, and one of them was the sentence I had written about the other.
• "Follow whatever it offers next." — There is a next step. With stranded.length non-zero the page prints the offer: *"This list is today's. It will be a different list next week… It is in Shopify's review queue now and is not installable yet,"* with an email field and a notify token minted only for somebody who has not already joined. The funnel does not end in a shrug. It ends in the one ask I can currently honour.

2. The finding I invented, and withdrew

I read the raw JSON before I rendered the page, saw that 4 of the 6 broken entries have a single size left, and wrote that the product was contradicting its own stated rule on a live merchant's catalogue. A live defect, four of six results wrong.

That was false and I withdrew it inside the same phase. public/check.js already does the right thing and has since Phase 90:

const stranded = broken.filter((b) => (b.stranded || b.left || []).length >= 2);

The headline counts stranded. The list draws from stranded. And it prints *"N more are down to one size still on sale, and calling those sold out is fair, so they are not listed."* The product was telling the truth. I graded it on a payload no merchant sees.

What that cost: I then "fixed" it by adding counts.broken_stranded to summarise(), with a comment congratulating myself for carrying a value across a boundary instead of rederiving it. The payload has shipped strandedStyles since the scanner's first day. Same number. Four lines below the line I typed. And I computed mine off b.left where that one computes off b.stranded — two predicates for one quantity, which is exactly the defect I was invoking as the reason to add it. Reverted within the hour (bce897f); the comment at strandedStyles now records that it happened.

Sixteenth instance of reconstruct-at-a-boundary, and I produced it while writing the phrase.

3. The finding that was real

One card said "6 broken right now", one line above a headline saying 2. Both numbers are correct. The page defines broken the strict way — core gone and two or more sizes still on sale — and headline and list both count it that way. The card was using the loose sense of the same word, one line apart, on a page whose whole argument is that it does not overclaim. A merchant reading top to bottom sees 6, then 2, and has no way to know which is theirs.

Each card now carries its own test rather than a shared word:

• 6 — with the core run gone
• 2 — of those with 2+ sizes still on sale

And the intro paragraph said the published 63.1% figures were *"counted the same way this page will count yours"*. They are not. They are the stricter count; the page shows both. Rewritten to say which is which and that you will see both.

render.test.mjs asserts both labels and refuses a bare broken card. Shipped and live: a9b22f2, deployed, 20/20 live promises verified.

4. The instrument I contaminated

To run the product as a stranger I called /api/check by hand — curl, then python. None of those three requests carried the self marker. So recordCheck() did what it is built to do with an unmarked request and filed all three as merchants'.

The kill criterion's second clause read 0 of 10 outside checks this morning. It reads 3 of 10 tonight. All three are me.

recordCheck() has carried this comment since the night it was written:

the only request that exercises the wire is one that would be counted as a merchant, and as of tonight would count toward the ten checks that decide this app

bin/check-live.sh appends the marker for exactly this reason. I had read the comment. I did not use the script. I was looking at the page and not at the counter.

I am not subtracting them. viewStats already refuses to clear views or checks, on the stated grounds that a number I can zero on demand is not evidence against me — and quietly removing three that embarrass me is that same act with a better excuse. The number stands. The correction is now a comment at the KILL constant (4cae0d1), where anybody reading checksRemaining: 7 will find it, and it says plainly: the true outside-check count for this window is zero.

5. The gap nobody has named yet

175 of 563 products — 31% — were unreadable on aeyde.com. The page is honest about it (*"We judged 388 of 563 products. The other 175 do not present a size run we can place in order, so nothing above is a statement about them"*), and that honesty is the right behaviour. But 31% is the largest single gap between what this product reads and what a merchant's catalogue contains, and it is the same limitation as the Gymshark case (893 of 999 unplaceable).

It is not a bug and I am not fixing it tonight. It is the thing a merchant is most likely to push back on, and I have never written down what the 175 are. I own that question.

Housekeeping

• Zoo checked per §7 after publishing the Phase 122 plan. No remark field; the only occurrences of the word are RULES §7 itself being displayed. Nothing to answer.
• One incidental: an authenticated request to /api/views from python's default user agent gets 403 at Cloudflare's edge, before the Worker runs. The Worker returns 401 for a bad token, so a 403 there is never an auth failure. Sending a UA fixes it. Not a product problem; a note so I do not spend ten minutes on a wrong token again.

The number

Kill criterion: 2 of 50 qualifying views, 3 of 10 checks *of which all three are mine — genuinely 0 of 10*, remaining: 48, 26 days to 2026-10-20. Verdict still kill. Traffic mix: 165 arrivals, 2 rendered, 82.5% machines. apps.shopify.com/sizecurve-2: 404, day 12.

489 tests, 19 browser tests, 20/20 live promises.

What the boss can unblock, unchanged in order

1. Protected customer data request — Partner Dashboard → the app → API access requests → Protected customer data access → Request access. Level 1, no protected fields. Paste-ready text is in actual/2026-09-23.md.
2. Search Console for bananafest-destiny.com — submit https://sizecurve.bananafest-destiny.com/sitemap.xml. 47 crawler visits, 0 from Google.
3. Does the Partner Dashboard show a review status or a reviewer message? Twelve days.
4. dev.to — publish marketing/dev-size-runs.md under your byline, or tell me the route.
5. A read-only Resend key.
6. TikTok — is @sizecurve free, and may I rename netofreturns?
7. Paste the corrected Long description into the live listing; upload the three regenerated screenshots.