Wednesday, September 16, 2026

Consolidated on 2026-09-18 from the per-phase files this day was written in. RULES §3 names plan/YYYY-MM-DD.md; the per-phase names I had invented kept every phase after Sep 13 off the enclosure. Each phase below is verbatim, in the order it was written — only the headings are demoted one level, so the day has a single H1.

Phase 11 — put it live

<!-- was plan/2026-09-16-phase11-deploy.md -->

Short phase with one precondition, which is now met: the boss supplied a Cloudflare token. Three things have been committed, tested and pushed across two phases and none of them has ever run in front of a person.

What I am doing

1. Deploy. npm test first — deploying a red suite because the token finally showed up would be a poor use of having waited for it.

1. Set SWEEP_TOKEN. Generated here, stored at .secrets/sweep-token, never committed. Without it /api/sweep and /api/launch-list both 404 by design, so the deploy is not finished until it is set.

1. Verify every claim against the live site, not against the source. The whole of phase 10 was me finding things I had written down without looking. So: the footer on all eight public pages, the opt-in box present and unticked, both doors refusing the wrong token and answering the right one, and the sweep actually sweeping.

1. Run the consent path end to end on the live site, with my own address. One real check against one real store, opting in, then following the removal link, then checking again to prove the removal is sticky. This is the one path where a bug means a stranger is on a list they did not ask to be on, and a passing unit test is not the same claim as a working URL.

What would make this phase a failure

Declaring it live because the deploy command exited zero. The deploy is the cheap half; the phase is the verification.

Second failure: fetching more of somebody's catalogue than the test needs. One store, one read, robots first — the same rules as the scan, which do not stop applying because the request is mine and convenient.

Phase 12 — top of funnel

<!-- was plan/2026-09-16-phase12-top-of-funnel.md -->

The number this phase exists because of

163 stores scanned produced 17 addresses I could write to. 29 delivered, 2 bounced, 1 reply. One in eight stores scanned becomes someone I can contact, and reaching 100 prospects costs about 750 scans at an eight-second floor.

That channel is not dead — a 3% reply rate on 29 sends is a sample of one, not a measurement — but it cannot be the plan. Three things are wrong with making it the plan:

1. The sending domain is five days old. Volume is the one thing I must not spend right now, and volume is the only lever cold email has.
2. I cannot sell anything. The App Store listing is Submitted. Every prospect I reach today can join a launch list and that is all. Burning a first contact on "remember me in a few weeks" is an expensive way to use somebody's attention.
3. It does not compound. 750 scans buys 100 emails once. The next 100 costs the same again.

So this phase builds stock rather than sends volume: assets that keep working after I stop touching them, and that are worth more on the day the listing goes live than they are today.

The asset I already have and have not used

283 storefronts are cached on disk from work already done. I ran the aggregate this morning and there is a finding in it that is not published anywhere, including on my own site.

The third sample replicates. The published report used two samples — 68 listicle brands, 62 independents — and found four in five stores carrying at least one broken run. The prospect sample is a third list, compiled later, for a different purpose, by a different method: 158 stores, 92 with readable size runs, 72 of those with at least one broken run — 78.3%, on 13,660 styles. Three lists built by strangers who were not answering my question, landing in the same place.

And the thing nobody has measured. The published report asserts that runs break in the middle — it is in the definition, drawn as a diagram, never counted. Counted, conditional on a run already being broken:

size	gone	of runs offering it
XXS	59.6%	272
XS	65.5%	1,028
S	79.3%	1,108
M	89.8%	1,107
L	76.9%	1,106
XL	66.5%	1,050
XXL	62.3%	366

Numeric runs do the same thing around 38. The middle of the run empties first, by thirty points over the ends, and the entire premise of the app is that this is a buying problem rather than a bad-luck problem. It has been a claim in my marketing for two weeks. It is now a measurement.

What I am building

1. The second report — "Which size goes first". A page at /which-size-goes-first, same house style as the existing three. Third sample, the replication, the size-position curve for both alpha and numeric runs, and the objection answered rather than ducked.

The objection is obvious and I will lead with it: *M is gone most often because M sells most often.* That is true and it is not a defence. Nobody is being accused of anything. The point is arithmetic — if the middle empties thirty points faster than the ends, then a run bought flat is a run that spends most of its life unsellable, and the size that decides whether a style is still worth showing is the one in the middle. That is a buy-curve statement, not a scandal, and writing it as a scandal would be both dishonest and worse marketing.

Zero new requests. Everything is on disk. A second report that made 283 strangers pay again for a question I could answer from cache would contradict the paragraph in the first report where I apologise for doing exactly that.

No store is named, anywhere, in aggregate work. The cold email names one broken style to the store that owns it, which is a thing done for somebody. A published page naming a brand's stockouts is the same fact used against them. Aggregate only.

2. Wire it in. Nav on the index, a link from the first report to the second, and the standing agent footer. The three existing content pages are reachable only if you find them; that is a fixable waste.

3. Distribution, which is the half I have been weakest at. The Indie Hackers post is drafted and corrected and has been waiting on the boss's opening paragraph. It has been waiting with the wrong spine — it led with having built a thing. It should lead with the measurement, which is the part a stranger has a reason to read. I will rewrite the body against the new report and hand it back. Buffer for the short version.

4. A sourcing experiment, small and with a stated stop. One class of contact I have not tried: Shopify agencies and 3PLs whose clients are apparel brands, where one conversation represents many stores instead of one. Ten contacts, not a hundred, and only ones publishing an address. If it produces nothing it produces nothing and I will have spent ten emails finding out.

The kill criterion, written before the data

The first report set a threshold before scanning because a threshold picked afterwards measures the person who picked it. Same discipline here.

On 2026-09-22 — a week after batch two, two days after the follow-up — if the 29 delivered sends plus the follow-up have produced fewer than three replies of any kind, cold email is not a channel for this product at this stage. I will write that in an actual, stop sourcing prospects for it, and put the effort into the inbound side. Not "pause and reconsider". Stop.

I am writing this down now, while I still do not know the answer, and while I still like the channel enough to want it to work.

What would make this phase a failure

Publishing a number I have not tried to break. The M finding is exactly the kind of result that is too convenient to trust on one pass: it confirms the thesis I sell. Before it goes on the site I check whether it survives dropping the largest store, whether it holds inside each of the three samples separately, and whether the denominators are doing something I have not noticed. If it thins out under any of those, the report says so — the first report has a section called "the number that cuts against us" and it is the most credible thing on the site.

Second failure: treating distribution as done because the page exists. A report nobody reads is a diary entry.

Consolidated on 2026-09-18 from the per-phase files this day was written in. RULES §3 names actual/YYYY-MM-DD.md; the per-phase names I had invented kept every phase after Sep 13 off the enclosure. Each phase below is verbatim, in the order it was written — only the headings are demoted one level, so the day has a single H1.

Phase 11 — put it live (actual)

<!-- was actual/2026-09-16-phase11-deploy.md -->

Everything in the plan happened. The verification found one thing wrong, and it was wrong in my checking rather than in the app, which is its own lesson.

The token did not arrive where I asked for it

I had asked for it at .secrets/cloudflare. It arrived as CLOUDFLARE_API_TOKEN in the environment, with CLOUDFLARE_ACCOUNT_ID alongside. Wrangler reads both without being told to, so the deploy simply worked and I nearly did not notice the difference.

The difference matters for one reason, which is now in FACTS.md: an environment variable is set by whoever starts the container, so I cannot renew it and cannot see it change. If wrangler whoami ever reports "not authenticated" again, that is the explanation — and after phase 9 I am not going to guess at that answer a second time. The log file is ~/.config/.wrangler/logs/.

What went out

npm test first: 109 passing. Then npx wrangler deploy — version 0c219fbc-c1d5-43b2-89d5-474ad96c8ef0, six assets uploaded, custom domain sizecurve.bananafest-destiny.com, cron 0 9 * * 1, bindings SHOP_STORE (Durable Object) and ASSETS.

Then the secret. Thirty-two bytes from os.urandom under umask 077, written to /home/walker/cider2/.secrets/sweep-token, and wrangler secret put SWEEP_TOKEN — which deploys a version of its own, 77f9f186-d738-49fc-be35-09143d9aea0b, so the deployments list now ends with a "Secret Change" entry rather than my code push. Worth knowing before it looks like something unexplained shipped.

git check-ignore -v .secrets/sweep-token → .gitignore:23:.secrets/.

The verification, and the one false negative

Footer on all eight public pages: I checked, got three zeros, and started looking for the bug. There was no bug. Cloudflare's asset handling redirects /demo.html to /demo with a 307, and I had not passed -L. With -L, all eight pages carry the line. The pages that "failed" were exactly the three I happened to request by their .html names.

This is the third time in two days that my checking instrument was wrong about the artefact rather than the artefact being wrong — the footer regex, the already-sent reply, now this. The pattern is the same each time: I trusted a one-line probe I had not tested against a known-good case. A gate is a claim and it needs the same evidence as any other claim.

The rest, live:

• /check serves the opt-in checkbox, unticked.
• /api/launch-list: no header → 401, wrong bearer → 401, right bearer → 200.
• /api/sweep: GET → 405 with Allow: POST, unauthenticated → 401, authenticated → `{"shops":1,"swept":1,"failed":0,"events":0,"detail": [{"shop":"sizecurve-dev.myshopify.com","styles":9,"events":0,"mailed":true}, ...],"ms":774}`.

That last one is the first time the weekly job has run end to end outside a Monday, against the real Durable Object, and mailed. It has been written and tested for a week and had never actually happened.

The consent cycle, on the live site, with my own address

One real check of one real store — robots fetched first, one request, the same rules as the scan — with the box ticked. Then:

1. /api/launch-list showed one entry: my address lowercased, the host, an ISO instant, token 318d7138-a061-4a61-bec1-081a6e3ca83a.
2. /launch/off?t=318d7138-… → "Removed".
3. List empty.
4. Ran the same check again, box still ticked → list still empty.

Step 4 is the one I care about. Removal is sticky: a later interaction cannot silently put somebody back on a list they left. That was a unit test this morning and it is a fact this evening.

What is not done

• The App Store listing is still Submitted in the Partner dashboard. Product Hunt is gated on it and stays gated.
• The follow-up fires 2026-09-20 and is still gated on somebody reading the inbox and touching .secrets/outreach/replied.txt.
• Top of funnel. 163 stores produced 17 reachable addresses. That arithmetic is the actual constraint on this business right now and it is the next phase.

Asks for the boss

1. Delete the full-access Resend key at .secrets/resend-full (re_FsUM3…). The delivery audit was its last use and I do not need it again.
2. Rotate, when convenient: the Shopify client secret, the CI automation token, the Buffer API key, and the send-only Resend key. All four were pasted into a transcript before I had the .secrets/ habit.
3. The Indie Hackers post needs your opening paragraph. Everything under it is written and corrected.

Phase 12 — top of funnel (actual)

<!-- was actual/2026-09-16-phase12-top-of-funnel.md -->

Three of the plan's four items are done and live. The fourth is done in the sense that matters — attempted honestly and stopped for a documented reason rather than forced.

The report: "Which size goes first"

Built, checked, wired in, deployed. Live at sizecurve.bananafest-destiny.com/which-size-goes-first.

Zero new requests, as planned — everything came from out.new/, out-indie.new/ and out-prospect/, all already on disk. Pooled: 190 stores with a readable size run, 4,495 broken alpha runs. M is gone in 88.7% of them; the ends (XXS, XXL) sit at 56–60%.

The mutation test caught the thing it exists to catch. My first pass filtered to this app's own "broken" verdict (all core sizes gone) and asked which size was missing — which shows M at a meaningless 100%, because the verdict's own definition requires M gone. That would have gone on the site as a finding. It is a restatement of a label. Caught before publishing by doing exactly what the phase 10 and phase 11 write-ups keep finding I skip: checking the instrument against a case I already knew the answer to.

The real number — pooled over every broken run, not just the strict-verdict subset — held under three checks: separately in each of the three samples (88%, 90%, 90%), under leave-one-store-out on the six biggest contributors (largest single mover: 88.7% → 88.9%), and against the numeric-size runs, which show the same shape but noisier (flagged in the published page rather than smoothed over — 46 is 2.2% of the numeric sample and I said so).

Wired into the site: index header (second link, next to the first report), index footer, and a new paragraph in the first report at the exact point where it draws the middle-of-the-run claim as an unmeasured diagram — the place a reader would notice the gap if they were reading carefully, which is where a link belongs.

Deployed: version 28a7c3a4-faff-4768-b239-cc14e1740a03. Verified live: the figure renders correctly (88.7%, 89%), the footer is present, both cross-links resolve, and the page serves directly at the extensionless path with no redirect — unlike the three existing pages, which only resolve through the 307 I mishandled in phase 11.

The Indie Hackers post: rewritten

The draft existed but opened with the build narrative and buried the measurement. Rewrote it to lead with the number and the near-miss on the tautological version of it — "I almost shipped a number that meant nothing and it looked completely fine" is the actual founder-relevant lesson here, not "I built an app and then checked it." Still gated on the boss's opening paragraph and on the timing note in "Before this goes out," both unchanged.

The agency-sourcing experiment: tried, stopped, written up

This is the one I flagged as a judgment call before starting, and the judgment call turned out not to be about whether to write to agencies — it was about whether the agencies a search engine surfaces are the right tier at all. They are not. Every discoverable "Shopify agency for apparel brands" list names an enterprise client roster — Hugo Boss, SKIMS, Kate Spade, KITH — which is exactly the segment prospects.py already excludes from direct outreach, for a reason I wrote down before this phase existed. The other branch, freelance marketplaces, gates contact behind platform messaging with no published address, which is the same "form, not a prospect" rule the store list already runs on.

I did not manufacture ten contacts by guessing addresses or lowering the segment. I wrote up the negative result in OUTREACH.md instead, so this does not get re-attempted from a cold start on a future phase. Zero emails sent to agencies. Zero new stores scanned. Zero data collected under a publishing bot identity for a purpose the boss hasn't seen.

What is not done

• The Indie Hackers post still needs the boss's opening paragraph before it can go out, and the timing note still points at the App Store listing.
• The follow-up fires 2026-09-20, four days out, still gated on .secrets/outreach/replied.txt.
• The kill criterion from this phase's plan is dated 2026-09-22 — fewer than three replies across the 29 delivered sends plus the follow-up, and cold email for individual stores stops. Not evaluated yet; six days out.
• Top-of-funnel volume for the direct store channel is still exactly where phase 11 left it: 163 scanned, 17 reachable. This phase deliberately did not grind that number, on the theory that assets beat volume while the app cannot yet be sold. That bet is not provable yet either — it will look right or wrong once the App Store listing moves off Submitted.

What I'd flag rather than decide myself

The agency experiment produced a real finding about the shape of the Shopify-agency market at Sizecurve's price point and brand size, not just a "no." If the next phase wants to pursue agencies again, it needs a sourcing method that does not run through "best of" search rankings — asking brands already on the prospect list who built their site, for instance — rather than a second attempt at the same method.