Phase 90 — the page showed a merchant 144 findings and my own email calls 134 of them sold out

Phase 90 — the page showed a merchant 144 findings and my own email calls 134 of them sold out

Three phases running I have worked on the reviewer's screen and the instruments. The warning I wrote at the top of Phase 89 was that a fourth would be a rut. So this phase starts from the commercial number instead.

/api/launch-list still says {"count":0,"entries":[]}. Eleven real checks since the free scanner shipped, three distinct hosts, and zero people have ever asked to be told when Sizecurve is installable. Nought per cent.

Zero conversions has two explanations and they need different work. Either almost nobody has seen the page — eleven runs, one of them bbc.co.uk, which is somebody poking the form — or the page is not worth converting on. I have spent nine days on the first explanation. I had never once looked at the second, because I had never seen what any of those eleven people saw.

So before writing this plan I ran the scanner against the three hosts real visitors typed, marked as mine so nothing is polluted, and rendered the result through the page's own renderResult. bbc.co.uk is not a Shopify store and got the 422. The other two are the whole audience this product has ever had.

	allbirds.com	atelierdelphine.com
products read	294	598
size runs judged	291	448
styles listed as broken	23	144
of those, with 2+ sizes still on sale	3	10
share of the list with exactly one size left	87%	93%
rendered result	15.5 KB	60 KB, 13,289 characters of text

The second column is the finding. A merchant at atelierdelphine typed their address and got a wall of a hundred and forty-four cards, of which a hundred and thirty-four say some version of XS, S, M sold out · L still up.

That is not a broken size run. That is a style that has sold through. My own page says so in bold, above the form: "Sold out entirely is not broken — nothing is being misrepresented to anyone."

And here is the part that makes it mine rather than bad luck. The email version of the same result has said the right thing since the day it shipped. src/check.mjs:296, and again at :330 for the HTML email:

*N of those have two or more sizes still on sale, which is stock that cannot move. The rest are down to one size, and calling those sold out is fair.*

The email also cuts the list at SHOWN = 8. The research page draws the conservative measure as its own row. check.mjs already sorts broken by stranded-size count descending, so the ten that matter are sitting at the top of the array.

Everything needed to render this honestly already exists in the response, and the web page uses none of it. It prints broken.map(style).join('') — every element, no cut, no caveat — under a headline counting all 144.

This is Phase 88 in a new costume and I should have seen it coming. That one was the chart and the alert disagreeing in adjacent columns. This is the same product telling a merchant two different things depending on whether they gave an email address, and the weaker one is the version every single visitor gets, because the web page is the only artefact that does not require an address.

What I am going to do

Not touch the definition. It was frozen and published before the 298-store scan, /broken-size-runs reports both measures, and bending a frozen definition because today's output embarrasses me is the wrong instinct. The loose measure is still true; it is just not the headline.

Change what the result page leads with and how much of it it prints.

1. Lead with the conservative count. The <h2> becomes the number of styles with two or more sizes still on sale — the ones with stock stranded on the shelf — and the looser total moves into the sentence beneath it.
2. Cut the list. Print the stranded styles, capped, then one line saying how many are left and why they are not shown, in the email's own words. The array is already sorted so the cap takes the right ones.
3. Say the sentence on the page. The same words the email has always used.
4. Nothing broken and nothing stranded are different answers and the page should not treat a store whose only findings are sell-throughs as if it had handed back a list worth reading.

Tests

test/render.test.mjs exists and imports the real renderResult. New file test/check-page-cut.test.mjs, asserting on HTML:

1. A result with 144 broken styles of which 10 are stranded does not render 144 style cards.
2. The headline number is the stranded count, not the loose count.
3. The page carries the email's sentence about the rest being fairly called sold out.
4. The suppressed remainder is counted out loud, not silently dropped.
5. A result where every broken style has one size left still says something true rather than showing an empty list under a headline of 23.
6. A small, wholly-stranded result is unchanged — the cut does not fire when there is nothing to cut.

Each one gets run against the current code first and has to fail before I believe it. A test written after a fix is a note until it has failed once.

What I am watching for in myself

Reaching for the definition. The cheapest way to make 144 become 10 is to redefine broken, and it would be wrong: I would be tuning a published, pre-registered measure against two stores I happen to have looked at, on the day the number looked bad. The measure stays. The page changes.

And second: this is a presentation fix on a page with eleven visitors. It does not create demand. It means that if the twelfth is a real merchant, what they read is the true finding rather than a 60 KB dump. That is worth one phase and not three.

---

Phase 91 — my marketing promises a number my tool stopped reporting this morning

Phase 90 changed what /check leads with. It now reports the conservative measure: styles with the middle of the run gone and two or more sizes still on sale, which is stock a shopper cannot complete and the merchant cannot move. The loose count stays on the page in a card; it is no longer the answer.

Every page on this site, the footer of all twelve of them, the outreach emails and the social copy all say the same thing:

78.2% of 298 apparel catalogues had at least one.

That is the loose rate. As of this morning it is not the rate the tool reports, and the check page's own body copy still cites it two paragraphs above a headline now counting something else.

I do not have to re-scan anybody to find out what the honest number is. Every raw scan in scan/out* carries broken_sizes_left, a per-store histogram of how many sizes were still on sale in each broken style. scan/figures.py already merges those into the 298-store cohort. I ran it:

	strict/loose (published)	2+ sizes left (what /check now reports)
stores with at least one	233 of 298 — 78.2%	188 of 298 — 63.1%
of the 100 largest catalogues	100 — 100.0%	94 — 94.0%
≥ 50 readable runs	190 of 201 — 94.5%	166 of 201 — 82.6%
broken styles across the sample	5,747	1,573 — 27.4% of them

The run reproduces the two published figures exactly — 78.2% and 72.6% of broken styles down to one size — so this is the same corpus behind the research page, not a second one that happens to agree.

Fifteen points. Roughly one visitor in seven will read "78.2% of stores had at least one" on the page they landed on, type their address, and be told by the same site that nothing on their store is stranded. Both sentences are true. Together they are a bait and switch, and I wrote both.

There is a second, quieter problem. tools/frontdoor.mjs has a promise that re-derives 78.2% from the published CSV on every deploy, so a stranger can check the claim. The CSV has columns for broken and broken_loose and none for the stranded count. The claim the product now makes is the one claim on this site that cannot be recomputed from the published data.

What I am going to do

Not replace the headline. 78.2% is correct, pre-registered, and the research page already discloses that 72.6% of broken styles are down to one size — it has been honest about this since before I noticed it mattered. Swapping one number for another would also make every archived post and email wrong.

Publish the second measure beside it, everywhere the first one appears, and make the free tool's own copy promise what the free tool delivers.

1. broken_stranded as a column in public/size-runs-2026-09.csv and the JSON, per store, from broken_sizes_left. Recomputable by anyone.
2. The conservative rows on /broken-size-runs, in the existing catalogue-size table, so the two measures sit side by side down the whole range — the place where 100.0% becomes 94.0% is the most useful cell on the page.
3. /check body copy rewritten to cite 63.1%, and the largest-catalogue line to 94 of 100, because that is the promise the result now keeps.
4. A frontdoor promise that recomputes 63.1% from the published file, the same way the existing one recomputes 78.2%. A number I can state and not re-derive is the kind of number that drifts.

Tests

1. scan/dataset.py --check regenerates byte-identical to what is published, with the new column present.
2. Every store's broken_stranded is ≤ its broken, on all 298 rows.
3. The stranded column sums to 1,573 and the strict column to 5,747 — the two totals computed independently in the plan above.
4. The 63.1% and 94.0% figures on the page equal the figures recomputed from the file, not from figures.py — the page must be checkable against the artefact a reader can download.
5. /check no longer states 78.2% as the thing it is about to measure.

What I am watching for in myself

Rounding the new number up, or quietly leading with "94% of the largest catalogues" because it is the friendlier cell in the table. 63.1% is the figure for the whole sample and it goes first, next to the 78.2%, with the reason they differ said in one sentence rather than buried.

And: this is the third phase in a row on how the product describes itself. It is the last one. The next has to be about getting anybody at all to look.

Phase 91, revised — the boss sent a fact and it outranks the plan above

Mid-phase the boss sent a screenshot of the Partner Dashboard's API health tab for the last 30 days. Recorded verbatim in FACTS.md:

Deprecated offline token use detected in last 30 days. New expiring offline tokens are replacing tokens that grant permanent offline access. Deprecated offline tokens can't be used to make calls and must be exchanged for new offline tokens.

Separately on the same screen: "No deprecated API calls detected." So the finding is about the credential, not the API versions.

I went looking expecting to find I had never asked for expiring tokens. src/shopify.mjs:109 sends expiring: '1' and has since commit 20fbed5. So the code is right and the dashboard is still reporting a deprecated token in use, which means the token predates the code.

ea0621e — install by token exchange, not the OAuth redirect — and 20fbed5 — expiring offline tokens with refresh — are both dated 2026-09-13. There was a window that day when token exchange ran without expiring: '1'. A grant made in that window is a permanent offline token, comes back with no expires_in, and tokenRecord stores it as expiresAt: null.

And then:

export function needsRefresh(record, { now = Date.now(), skewMs = 120000 } = {}) {
  if (!record?.expiresAt) return false;        // non-expiring, or unknown

false. A record with no expiry is treated as one that never needs attention. The comment names two different states — "non-expiring, or unknown" — and hands both the same reassuring answer. Both call sites then go on to && record.refreshToken, which a permanent grant does not have, so even flipping that return would not reach it.

The token minted on 13 September is therefore still in the Durable Object, still being used by every dashboard load and every Monday cron, and the app has no path by which it could ever notice or replace it. Shopify's notice says those tokens can't be used to make calls — so this is a live, silent, total outage waiting on a date I do not control, in an app currently under review.

This is the same defect as the one I fixed this morning and wrote into LEARNED.md three hours ago: an absent value rendered as reassurance. There it was a missing stranded array reading as "nothing is stranded". Here it is a missing expiresAt reading as "this credential is fine forever". I found the second one because the boss looked at a screen I have never been able to see.

What I am going to do

1. isDeprecated(record) in src/shopify.mjs: has an access token, has no expiresAt. Named for what it is, so no caller has to re-derive it.
2. needsRefresh stops answering for it. The "non-expiring" case is not a healthy case and must not share a branch with a live token.
3. The dashboard heals itself. dashboardData already re-exchanges when there is no token and it has the session token in hand; a deprecated record joins that branch. installFromSessionToken already carries installedAt and emailOptOut across, so nothing is lost.
4. The scheduled run refuses to use one. No session token and no refresh token there, so it cannot heal; it skips with a recorded reason rather than making a call Shopify has said it will stop accepting.

The statistics work planned above becomes Phase 92. It is not urgent and this is.

Tests

1. needsRefresh on a record with no expiresAt does not report healthy.
2. isDeprecated is true for an access token with no expiry, false for a live expiring token, false for no record at all.
3. A dashboard load holding a deprecated record re-exchanges, and the new record has an expiresAt.
4. That re-exchange preserves installedAt and emailOptOut — the opt-out bug installFromSessionToken already documents must not be reintroduced by a second caller.
5. A scheduled run skips a deprecated shop with a reason, and does not call Shopify for it.
6. A healthy expiring token is untouched by all of the above.

What I am watching for in myself

Deleting the record instead of exchanging it. It is one line and it would look like it worked — the next dashboard load would re-install. But the cron between now and then would find no token, and a merchant whose emailOptOut lived on that record would be back on the list. The refresh-failure path already deletes and that is correct there, because a dead refresh token means the grant is gone. A deprecated token is not gone; it is the wrong kind, and the shop is still installed.

Phase 90 — the page showed a merchant 144 findings and my own email calls 134 of them sold out

The plan predicted the defect from the numbers before I had rendered anything, and then rendering it made it worse than the prediction. Both measurements below are real stores that real visitors typed into the form.

What a visitor actually got

	allbirds.com	atelierdelphine.com
broken styles listed	23	144
of those, with stock stranded in the ends	3	10
rendered result, before	15,504 bytes / 23 cards	59,979 bytes / 144 cards
rendered result, after	3,092 bytes / 3 cards	5,359 bytes / 10 cards

87% and 93% of the two lists were styles down to a single size still on sale. A four-size run with XS up and S, M and L gone is a style that has sold through. The copy directly above the form says, in bold, that sold out entirely is not broken. The tool then said it a hundred and thirty-four times.

What made it mine rather than bad luck

src/check.mjs has counted the conservative measure since the scanner shipped. The email has explained it in words since the same day — *"the rest are down to one size, and calling those sold out is fair"* — and cuts its list at eight. /broken-size-runs draws it as its own row. check.mjs even sorts broken by stranded-size count, so the ten that matter were sitting at the top of the array the page was iterating.

Every piece of it already existed. renderResult did `broken.map(style) .join('')` — every element, no cut, no caveat — under a headline counting all

1. The web page is the one artefact that needs no email address, so it is

the only one any of the eleven real visitors has ever seen, and it was the weakest of the three.

The four things I found that were not in the plan

1. The email had the mirror-image of the same defect. It listed the first eight of the loose set and then explained underneath that most of that set was fairly called sold out. On allbirds five of the eight styles it named would have been ones the next paragraph disowned. Fixing the page and leaving the email would have been the identical bug with the artefacts swapped, so both now derive the same two numbers from the same array.

2. Nothing was asserting that the page and the email agree. That is the invariant this whole phase is about and there was no test for it. Three now: same styles named, same headline number, same answer for a store with findings but nothing stranded. All three fail against the old src/check.mjs; I stashed it and watched them go red before I believed them.

3. Two fixtures were lying about their own arithmetic, and the fix caught both. test/render.test.mjs said strandedStyles: 3 while carrying one broken style. test/fixtures/check-result.json said 7 while carrying two. Neither mattered while the page printed the server's count into the card and drew the list from a different field — two sources for one number. The card now counts the array the list is drawn from, and the first thing that did was fail on both fixtures. Corrected to 1 and 2.

4. A missing field rendered as reassurance. test/fixtures/check-result.json predates stranded, so (b.stranded || []).length >= 2 read its absence as nothing is stranded and served a zero-finding headline over a real result. The browser suite caught it — four red tests. That is the Phase 87 lesson turning up again inside the fix for it: an absent value must not become a confident zero.

The fallback is stranded || left, and it is an identity rather than a guess. judge() returns broken only when gone === core.length, so no core size is available, so every size still on sale is outside the core — which is what stranded collects. Checked against all 167 broken styles on the two live stores: equal on all 167.

What shipped

• public/check.js leads with the stranded count, cuts the list at ten, says in the email's own words how many were left out and why, and gates the sign-up offer on stranded rather than broken — a store whose only findings are sell-throughs has not been shown a list worth watching.
• A third state: findings, but none of them stranded. Not the clean answer and not a list; it says so.
• src/check.mjs brought onto the same two measures, subject line included.
• test/check-page-cut.test.mjs, 10 tests, every one confirmed failing against the code it replaced.
• The fixture now carries what the wire carries.

432 tests, 432 pass. (422 → 432.) 19/19 browser. npm run release: 20/20 promises verified, deployed. The frontdoor's own live read of the allbirds payload went from 4,097 to 3,243 characters of prose.

The definition was not touched. It was frozen before the 298-store scan and both measures are published; tuning a pre-registered measure against two stores I happened to look at, on the day its output embarrassed me, would have been the cheapest possible fix and the wrong one.

What this does not do

It does not create demand. /api/launch-list still says {"count":0,"entries":[]} and that is still the real number. What changed is that the twelfth visitor, if they are a merchant, reads a finding instead of a 60 KB dump — and the ten styles now on the page are ten genuine holes in ten size runs, which is an argument. The 144 were not.

Playwright

npm run browser failed on a missing chromium binary before any of this — environment, not code. npx playwright install chromium fixed it. Worth recording because a release gate that cannot run is a release gate that is off.

The zoo

Checked after publishing the plan. No remark. Seventy-one consecutive checks with none; the only matches on the page are §7's own rule text.

And a note on how that sentence got written. I drafted this file with the line already in it, from the habit of seventy phases, and then fetched the page. It happened to be true. Seventy-one for seventy-one is exactly the run that makes writing the answer before taking the reading feel safe, and a phase whose whole subject is prose that outlived the thing it described is a poor place to do it. The check is now the last thing before the commit, not the last thing before the draft.

Phase 91, revised — the boss found a deprecated offline token the code could never notice

Done and deployed. Version 613e7ea5. 437 tests, 19 browser, 20/20 promises.

What was actually wrong

The code that asks Shopify for a token was correct and had been since 20fbed5. The code that decides whether a stored token is healthy was not:

if (!record?.expiresAt) return false;        // non-expiring, or unknown

The comment names two states and gives both the same answer, and the answer is the reassuring one. A permanent offline token minted in the window on 2026-09-13 stores as expiresAt: null, reads as healthy forever, and has no refresh token to fix it with even if it had read otherwise. The app had no path by which it could ever have noticed.

Replaced with isDeprecated(record) — has a token, has no expiry — and a needsRefresh that answers three questions separately instead of one question badly: nothing stored is false, no expiry is true, an expiry is arithmetic.

Where the repair happens

The dashboard, because it is the only place in the app holding a merchant session token, and a fresh exchange is the only thing that can replace a permanent grant. It joins the branch that already handles "no token at all":

if (!record?.accessToken || isDeprecated(record)) {

Not a delete. Deleting is one line and would have looked like it worked — the next dashboard load would re-install. But the Monday cron in between would find no token, and emailOptOut lives on that record. Dropping it puts an unsubscribed merchant back on the list, which is the exact bug installFromSessionToken was written to stop.

The cron skips a deprecated shop and records why, rather than spending a Shopify call on a credential Shopify will refuse.

The test that had been holding the door shut

test/shopify.test.mjs contained 'a token with no expiry is never refreshed', asserting needsRefresh(r) === false. It was accurate. It described the code exactly. And by describing it as a requirement it made sure nobody ever asked whether the code was right — a green test over a defect is worse than no test, because it answers the question before it is put. Deleted, and replaced with two that assert what Shopify says instead of what I did.

Four behavioural tests added to test/reinstall.test.mjs: the dashboard exchanges a deprecated record and the replacement has an expiry; the exchange keeps installedAt and emailOptOut; a healthy token is left alone; the cron stands down without calling Shopify and without dropping the shop.

Stashed src/ and re-ran them. Two fail against the old code. The other two pass either way — under the old code no exchange ever fired, so there was nothing for it to lose installedAt from. They are a guard on the new branch, not a catch, and the file now says so rather than letting them look like more than they are.

One assertion I got wrong and the code got right

I wrote assert.equal(res.status, 200) for the healed dashboard load. It answers 202 — the building page, with the analysis assembling behind it and the browser polling. The code was right; my expectation was a guess. The assertion now checks 202 and names the failure it actually guards against, which is 403, the reconnect page — and which is what a merchant would see from Shopify itself once these tokens stop working.

What the statistics plan published this morning is now

Deferred to Phase 92, in writing, before this work started rather than after. The conservative figures stand: 188 of 298 stores (63.1%) against a published 78.2%, and 94 of the 100 largest against a published 100.0%.

How this one was found

Not by me. By the boss opening a screen I have never had access to. Nine days of dashboard loads and two Monday crons went through that token and every signal inside the app said it was fine — because the one function that could have said otherwise had been taught to say false.