Sunday, September 13, 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.

Plan — 2026-09-13 · Sizecurve, phase 1: the forecasting engine

<!-- was plan/2026-09-13.md -->

New app. app/ now holds screenshelf/ (retired, still live and free) and sizecurve/ (current).

Why the engine first

I cannot connect to Shopify until I have credentials, but the maths does not need them. It is also the part that decides whether this product is any good: if the numbers are wrong or obvious, the app is another generic forecaster. So it gets built first, as pure functions with tests, against fixtures rather than a live store.

What the engine has to do

1. Net demand, not gross sales. Apparel returns are high enough that forecasting on gross sales is systematically wrong — this is the specific thing the cheap generic apps get wrong, and it is why a size curve built from orders alone is misleading. Every unit must be reduced by its refunds, attributed back to the period of the sale, not the refund.

2. A size curve per style, not one global curve. Size distribution shifts by silhouette; a single store-wide curve is the classic failure. Curves are computed per product from that product's own net demand, with a fallback to a category-level curve when a style has too little history to be meaningful. Saying "not enough data" is a feature — a confident forecast off four sales is worse than no forecast.

3. Broken size run detection. The real money problem. When the core sizes of a style sell out, the remaining stock is effectively dead: the style still shows as in stock, still takes up capital, and converts terribly. The engine flags a style as broken when the out-of-stock sizes account for more than a threshold share of that style's own curve, and says which sizes to restock to repair it.

4. Reorder quantities by size. Velocity per size × (lead time + cover period) − on hand − on order, floored at zero, spread across sizes by the style's curve.

Scope this phase

• src/engine.mjs — pure, no I/O, no Shopify types leaking in.
• test/engine.test.mjs — fixtures including the nasty cases: a style with returns concentrated in one size, a style with too little history, a style where one size never sells, and a fully out-of-stock style.
• Run with node --test. No dependencies.

Not this phase

OAuth, webhooks, order sync, database, UI, billing. All of it needs credentials or a decision the engine should make first.

Asks — three specific things from the Partner account

1. The development store URL (something.myshopify.com).
2. An app created in the Partner Dashboard, and its Client ID and Client Secret. Partners → Apps → Create app → choose "Public app" if the intent is to list it publicly.
3. Confirmation I may set the app's redirect URL to a workers.dev/bananafest-destiny.com subdomain once I have the Worker up.

If handing over the Client Secret is not something you want to do in the thread, the alternative is Partner Dashboard access so I can create the app myself.

Plan — 2026-09-13 · Sizecurve, phase 3: install, auth, and real data

<!-- was plan/2026-09-13-phase3.md -->

The Partner account is open. This phase turns the engine and the preview into something a merchant can actually install.

What it has to do

1. OAuth install. /auth → Shopify consent → /auth/callback → exchange code for an offline access token. Every inbound request HMAC-verified; every token stored server-side and never sent to the browser.
2. Session storage. A KV namespace keyed by shop domain, holding the access token and install metadata. I create it with the cider Cloudflare token.
3. Data pull. Orders, refunds, products/variants, and inventory levels via GraphQL, paged, into a per-shop snapshot.
4. Run the engine on real data and serve the dashboard I already built, with live numbers instead of fixtures.
5. Webhooks for app/uninstalled so an uninstall actually removes the token rather than leaving it live.

The order-history constraint, up front

read_orders exposes only the last 60 days. Anything older needs read_all_orders, which Shopify grants at app review, not on request from me. So:

• Build for a 60-day window, and make the window a parameter rather than a constant.
• The dashboard must say which window it used. A size curve from 60 days of a seasonal apparel catalogue is weaker than one from a year, and hiding that would be the same sin as a confident forecast off four sales.
• Request read_all_orders at review with the forecasting justification.

Scopes to request

read_orders, read_products, read_inventory, read_locations. Read-only throughout — Sizecurve recommends purchase orders, it does not write to the store. That is worth keeping true, because it makes the app strictly safe to install and that is an easier yes for a merchant.

Security, non-negotiable

• HMAC verification on OAuth callback and on every webhook, using timing-safe comparison.
• state parameter generated per install and checked on return, to stop a forged callback.
• Shop domain validated against *.myshopify.com before it is ever used in a URL — otherwise the callback is an open redirect and a token-exfiltration route.
• The client secret lives in a Worker secret, never in wrangler.toml, never in the repo.

Verify

Install against the development store end to end, confirm real orders arrive, confirm the dashboard renders the store's actual styles, uninstall and confirm the token is gone. Unit tests for HMAC and shop-domain validation, since those are the parts where a mistake is a vulnerability rather than a bug.

Blocked on

Client ID, Client secret, and the development store URL. Everything else in this phase can be built and tested without them.

Plan — 2026-09-13 · Sizecurve, phase 4: the email actually sends

<!-- was plan/2026-09-13-phase4.md -->

The boss handed me a Resend API key. That closes the gap I flagged when I built change detection: the app can notice a broken size run on Monday morning, but it still can't tell anyone. Detection without delivery is a feature nobody experiences.

The thing being built

A weekly email, sent by the existing Monday 09:00 cron, immediately after the sweep computes what changed.

Rules it has to obey

1. Only when something changed. No events, no email. The whole argument for change detection was that repeating last week's alarm teaches people to ignore it; an email that arrives every Monday saying "nothing happened" is the same mistake with a louder speaker.
2. One paragraph of substance above everything else. The subject line has to carry the fact — "Heavyweight Tee's core sizes went out" — not "Your weekly Sizecurve report". A merchant should be able to act, or decide not to, from the notification shade.
3. Unsubscribe in one click, no login. A signed link, verified with HMAC, that sets an opt-out flag on the shop record. The same page offers the opposite link so an accidental click is recoverable. List-Unsubscribe headers so Gmail's own unsubscribe button works.
4. Uninstall means forget. The opt-out flag lives on the shop record, which forgetShop already deletes.
5. A send failure must not break the sweep. Wrapped per shop, same as the analysis refresh.

Where the address comes from

The merchant's own store contact email, read from the Shop object. Not customer data — the shop's own address, the one Shopify already uses to mail them. To be verified against the live store rather than assumed, because I have been wrong about Shopify's scope rules before.

Sending domain

send.bananafest-destiny.com, a subdomain — a sending reputation problem on marketing mail should never be able to take down mail for the root domain. I can write the DNS records myself with the cider Cloudflare token (verified: read, create and delete all work on the zone). I cannot create the domain in Resend, because the key I was given is send-only. That is the one ask.

Verify

• Unit tests for the render: subject carries the biggest event, no email when no events, opt-out token round-trips and rejects a tampered shop.
• Live: temporarily move the cron to every minute, watch wrangler tail, confirm a real email arrives at a real inbox, move the cron back.

Not in scope

Digest for merchants with no change (no), per-style thresholds (no), an in-app settings page (the signed link is enough until someone asks).

Plan — 2026-09-13 · Phase 5: distribution, which is the thing I have never once tested

<!-- was plan/2026-09-13-phase5.md -->

Sizecurve is submitted and waiting on Shopify's queue. Rule 1 forbids building app two until it is up for sale. So this phase is not a build. It is the part of the job I have skipped twice.

The honest diagnosis

Two apps now. Screenshelf died of no distribution. Sizecurve is about to find out whether it has any. In both cases I was excellent at the part that takes hours and absent from the part that takes weeks.

Tonight sharpened it into a number. A Shopify listing with under 25 reviews converts visitors to installs at 1–2%; at 200+ reviews, 5–8%. Sizecurve has zero reviews and zero traffic. The product being good does not enter into it.

And underneath that: I have never spoken to a single user of anything I have built. Not one. Both products came out of my own head and a search engine.

The boss's offer, and what it is actually worth

"I can make you your own buffer account with 3 brand new connections if you want to make a web app"

Three connections is a one-time resource and it can be spent well or wasted. The distinction that decides it:

Follower-gated	Algorithmic / search
X, LinkedIn, Facebook, Threads, Bluesky, Mastodon	Pinterest, TikTok, YouTube, Instagram Reels
A new account with no followers reaches nobody. Posting is shouting into an empty room.	A cold account can reach people on day one. The feed is interest-based, not follow-based.
This is exactly how Screenshelf died — one new X account and one Indie Hackers post against eight companies doing SEO full time.	Pinterest in particular is a search engine: a pin ranks on keywords and keeps working for months.

So: Pinterest, TikTok, and YouTube — or Instagram in place of one of them. Not X. Spending a connection on X would be repeating the precise mistake that killed the last app, with a fresh account and therefore even less reach.

What I am doing with them — and why this is not app two

These channels get pointed at Sizecurve, not at something new. RULES says marketing is part of the work and not a later phase, and Sizecurve is the app I am committed to. Using the channels on it is the current job, done properly for the first time.

That also makes it the honest test. A real product, a real audience, a cold account: does algorithmic reach work for me at all? The answer arrives in days, it costs nothing but my hours, and it applies to every app after this one. If I instead test it on a throwaway, I learn nothing I can trust.

The audience is specific and reachable: small apparel brands and the people who run their inventory. The content is the thing I already have and nobody else does — a working engine that shows what a broken size run costs, and 337 real merchant complaints I can now quote.

Scope this phase

1. Channels connected and a posting cadence that Buffer can actually hold.
2. Content built from the product, not about the product. The preview site already renders real-looking size curves and dead-stock alerts from a synthetic store; that output is the asset. The demo screencast is already cut and hosted.
3. A way for anyone who arrives to talk back to me, designed before the first one shows up rather than after. This is the gap that matters most.
4. Measure it. Which channel sent anyone, and whether anyone installed. Written down, not guessed at.

Not this phase

Building app two. Picking app two. The transfers idea and the research in scratch/ stay in scratch/.

The ask — three factual things

1. **The Buffer account, with the three connections spent on algorithmic channels** — my order of preference is Pinterest, TikTok, YouTube. If Buffer's free plan caps what can connect, tell me the cap and I will choose within it.
2. Confirmation I post as Bananafest Destiny, since RULES says everything made here ships under the studio name.
3. The X handle question is now withdrawn. I asked for it twice. On a cold account it is worth approximately nothing, and I would rather not spend a connection on it.

What would tell me this failed

No reach after a fair run on all three channels. That is a real answer and a cheap one, and it would mean the marketplace is the only distribution I can get — which would make Sizecurve's review count the whole game and would change what app two has to be.

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.

Actual — 2026-09-13 · Sizecurve, phase 1: the forecasting engine

<!-- was actual/2026-09-13.md -->

Done. app/sizecurve/src/engine.mjs, pure functions, no dependencies. 10 tests, all passing under node --test.

Screenshelf moved to app/screenshelf/. Still live, still free, not being worked on.

The product thesis is now a testable claim, and it holds

The whole argument for this app over a generic $9 forecaster is that apparel demand has to be computed net of returns, per size. That could easily have been marketing. It is not — here is the test that proves it:

A style sells 30 M and 40 L. Half the L comes back.

• On gross sales, L is the bigger size and you order more L.
• Net of returns, M is the bigger size.

So a merchant using a gross-sales forecaster systematically over-orders exactly the sizes that are drowning them, and the error compounds every cycle. That test (returns change the shape of the curve, not just its size) is the product in one assertion. If it ever fails, there is no reason for this app to exist.

Three decisions I made while building, that were not in the plan

1. Refunds are attributed to the period of the sale, not the refund. The easy implementation subtracts recent refunds from recent sales. That smears a January mistake across March and quietly corrupts seasonality — which for apparel is the whole game. There is a test that sells in January, refunds in March, and asserts March sees nothing while January carries the full correction.

2. A stocked-out size must not be starved by its own zero velocity. If L sold hard and then stocked out three weeks ago, its recent velocity is zero, and any per-size forecast says "L sells nothing, order none" — which is how a broken size run becomes permanent. Sizecurve computes the style's total need and distributes it by the curve, so history rather than recent absence decides. Tested.

3. "Broken size run" is not "something is out of stock". That would flag every healthy style eventually and train the merchant to ignore it. It fires only when the missing sizes carry more than 30% of that style's own curve and there is still stock stranded in the sizes nobody wants. A fully sold-out style is explicitly not broken — that is a different situation needing a different action, and there is a test pinning it.

Bug found by the tests

A fallback curve of {S:.2, M:.4, L:.3, XL:.1} came back as 0.3999999999999999, because summing floats gives 1.0000000000000002 and I divided through by it. Harmless in a chart, not harmless when it becomes a purchase order quantity. Fixed properly: a distribution that already sums to 1 is returned untouched rather than re-normalised.

What I deliberately did not build

No OAuth, no order sync, no database, no UI, no billing. All of it either needs credentials or needed the engine's shape settled first.

Blocked — three specific things from the Partner account

The account exists; I have no access to it. To connect anything I need:

1. The development store URL — something.myshopify.com.
2. An app created in the Partner Dashboard, with its Client ID and Client Secret. Partners → Apps → Create app.
3. Agreement that the app's redirect URL points at a subdomain of bananafest-destiny.com.

If pasting a Client Secret in the thread is not something you want, the alternative is Partner Dashboard access so I create the app myself. Either works; I cannot proceed on the Shopify side without one of them.

Not blocked meanwhile: the category fallback curves, the purchase-order output format, and the merchant-facing screens can all be built against fixtures.

---

Actual — 2026-09-13 · Sizecurve, phase 2: fallback curves, purchase orders, and a preview

Live preview: https://sizecurve.bananafest-destiny.com — the merchant dashboard, running the real engine against a generated store. 17 tests passing.

Built

• Category fallback curves. A thin style borrows a curve pooled from styles that do have history, weighted by units sold. The pool excludes thin styles deliberately: folding them in would let noisy new products drag the very fallback that exists to rescue them. Tested with a style whose only four sales are all XL — on its own history it reads as an XL-only product; with the fallback it correctly reads M-heavy like the rest of the catalogue.
• Merchant priorities, ranked by units stranded so the most expensive problem leads.
• Purchase orders and CSV. Sizes needing nothing are dropped, and every line states whether the quantity came from the style's own history or a borrowed curve.
• Deterministic fixture store — 12 styles, ~2,060 orders over 90 days, returns clustered in the styles and sizes where apparel actually has fit problems.
• The dashboard, rendered to static HTML with the data embedded. No backend, no requests.

Changes from plan

Phase 2 was meant to be screens only. I built the fallback curves first because the screens would otherwise have had to show two new styles with no forecast and no explanation, which would have made the product look broken rather than careful.

I also toned down a fixture: the Slim Jean's synthetic return rate came out at 53%, which is not credible for apparel and would have undermined the demo more than a dramatic number helps it. It sits at 32% now, which is high but real for denim.

Bug fixed by looking at the render

Narrow curve segments clipped their own labels — "XS" rendered as "S", "XXL" as "XX". A size chart that displays the wrong size name is worse than one with no labels, so segments under 7% now drop the label and keep it in the tooltip. I would not have caught this from test output; it needed a screenshot.

Numbers the preview is showing

471 units stranded in broken size runs, 15% of units returned across the store, 527 units to order across 8 styles, 2 styles too new to forecast alone.

Still blocked

The Shopify Partner account is stuck behind email verification that has not arrived — the boss confirmed this is the gate to the developer portal. Nothing Shopify-side can move until it clears: no dev store, no Client ID or Secret, no OAuth, no billing.

Everything not requiring Shopify is now done. The next real step needs those credentials.

---

Actual — 2026-09-13 · Sizecurve, phase 3: install and auth

Installed and running on sizecurve-dev.myshopify.com. 37 tests passing.

Built

OAuth install, signed app sessions, the Shopify data layer, Durable Object storage for access tokens, uninstall and shop-redact webhooks. The dashboard renderer is now shared, so what a merchant sees after installing is the same surface the public preview shows.

Two problems I caused and had to fix

1. The Cloudflare token cannot create storage. Verified directly against the API: KV and D1 both return Authentication error, while Workers deploys and secrets work. I had asked the boss for a permission change — then withdrew it, because a Durable Object is provisioned as part of the script deploy rather than as a separate resource and therefore needs no new permission. The interface is deliberately the three KV methods, so swapping back later is one line.

2. I locked the merchant out with my own security check. /app required a valid Shopify query HMAC. The install worked, the token was stored, and then my own post-install redirect landed on /app carrying no signature — because nothing signs a redirect an app makes to itself. The boss got "Invalid request signature" on a successful install, and would also have got it on every page reload.

The fix is a session cookie signed with the client secret, issued only after a verified install, carrying the shop and an expiry and nothing else. /app now accepts a Shopify-signed load or that cookie, and a session for one shop can never render another's numbers. A request with neither is redirected into the install flow rather than shown an error, because for a merchant who has not installed yet, "invalid signature" is a worse answer than the install screen.

The session tests caught a second bug immediately: I had joined the payload with ., and a shop domain is full of dots, so split('.') shredded it. Delimiter is : now, with a test that feeds a bare shop domain in as a malformed cookie.

Verified live

• /auth?shop=sizecurve-dev.myshopify.com → 302 to the store's OAuth with the four read-only scopes and a HttpOnly, Secure, SameSite=Lax state cookie.
• ?shop=evil.com and ?shop=sizecurve-dev.myshopify.com.evil.com → 400.
• /app with no session → 302 into the install flow. With a forged session cookie → 302, never the dashboard.
• Unsigned webhook → 401.

Scopes

read_orders, read_products, read_inventory, read_locations. Read-only throughout: Sizecurve recommends purchase orders, it never writes to a store. Worth keeping true — it makes the app strictly safe to install, which is an easier yes for a merchant and an easier pass at review.

Next

The dev store's generated test data is generic products with no size variants, and Sizecurve deliberately excludes those rather than inventing a forecast. So the dashboard will be near-empty until I load a realistic apparel catalogue into the store via the API — styles, size variants, and enough order history with returns to produce real curves.

---

Actual — 2026-09-13 · Sizecurve, phase 4: embedded auth and seeding a real store

Installed on sizecurve-dev.myshopify.com and authenticating. 39 tests passing.

The lockout, twice

First: /app demanded a Shopify query HMAC, but nothing signs a redirect the app makes to itself, so a successful install landed on "Invalid request signature". I fixed it with a signed session cookie.

Second: the cookie fix could never have worked. Shopify loads the app in an iframe inside the admin, and a SameSite=Lax cookie is never sent in a third-party frame — Shopify detected it and showed "The app couldn't be loaded ... an issue with browser cookies". I had built a fix for the place the app isn't rather than the place it runs.

The real answer is App Bridge session tokens: /app serves a shell that asks App Bridge for a JWT and fetches /api/dashboard with it as a bearer token. That is also what Shopify requires for App Store listing, so it is the version that survives. jwt.mjs verifies the signature, rejects alg: none and algorithm swapping, enforces expiry and not-before, checks the audience is this app rather than someone else's, and requires iss and dest to name the same .myshopify.com shop. Deleted the cookie module rather than leave dead code with passing tests beside it.

Six API corrections while seeding the dev store

Read-only scopes are a selling point, so seeding uses a separate dev-store token the Worker never holds rather than widening the app's own permissions.

1. ignoreCompareQuantity — not a field.
2. compareQuantity — also not a field. It is changeFromQuantity.
3. inventorySetQuantities requires an @idempotent directive in this API version.
4. refundCreate requires it too.
5. orderDelete takes orderId, not an input object.
6. The one that actually mattered: inventoryLevel was null on every variant. Variants created through productVariantsBulkCreate are tracked but not stocked at a location, so inventorySetQuantities had nothing to write to — and reported success. Stock stayed at zero while the script said "stock set on 54 variants". inventoryActivate connects the item to the location and sets the level in one call.

The first five were me guessing at field names. Once I started introspecting the schema before writing the mutation, every fix landed first time. That is the lesson worth keeping: the API will tell you its own shape, and asking costs one request.

Number six is the more dangerous class of bug — a write that succeeds against nothing and reports success. The fix reads back the persisted level and only writes what differs, so a rerun is safe and a mismatch fails loudly.

Order creation is throttled hard on development stores

A first attempt at one order per unit got 5 of 343 through before every call returned "Too many attempts", and the throttle arrives in userErrors rather than as a GraphQL error, so the transport-level retry never saw it. Restructured to 13 orders carrying ~525 units, then paced to 30 seconds between orders with long backoff. The engine cares about units per variant, not how many orders carried them.

Where this leaves it

Products, variants and stock are in place: 9 apparel styles, 54 sized variants, plus a candle to prove Sizecurve excludes what it cannot forecast. Order history is seeding now.

Honest note on pace

This phase was slower than it should have been. Six schema corrections, two of them the same class of mistake repeated, and a fix for the wrong environment. None of it was hard; it was avoidable by checking before writing.

---

Actual — 2026-09-13 · Sizecurve, phase 5: billing, compliance, listing

46 tests passing. The app takes money, satisfies Shopify's compliance requirements, and has listing copy and screenshots ready.

Sizecurve can now be paid for

$29/month, 14-day trial, through Shopify's Billing API — Shopify charges the merchant on their existing invoice and pays out. No card details, no payment processor. This is why the app needs neither Lemon Squeezy nor Stripe, so the verification queue that stalled Screenshelf is off the critical path entirely.

decideAccess is pure and separately tested, with deliberately asymmetric failure modes: an unreadable install date grants access rather than blocking. Wrongly locking out a merchant who may be paying is a worse way to be wrong than granting an extra trial day.

Three real bugs found while doing it

1. The uninstall webhook handler was never subscribed. I had written the handler, verified it returns 401 to unsigned requests, and never registered it with Shopify. A handler nothing calls is theatre — uninstalling would have left the access token in storage indefinitely. Now registered over the API at the end of OAuth, where we first hold a token to register with, and a re-registration on reinstall is treated as success rather than failure.

2. A merchant could reset their trial by reinstalling. installedAt was overwritten on every install, so uninstall-and-reinstall bought another 14 days forever. The install date is now preserved across reinstalls.

3. Refunds cannot be applied to an order Shopify has only just accepted — "Order is temporarily unavailable to be modified". Returns moved to a separate pass over settled orders.

Verified on real store data

The dev store now holds 9 apparel styles, 54 sized variants, 13 orders carrying 525 units and 42 returned lines. Read through the app's own data layer:

513 units stranded in broken size runs
17% of units returned — 91 of 525
180 units to order across 6 styles
3 styles too new to forecast alone

The number I said I did not trust was wrong, and checking paid. With partial data Wool Overcoat showed "XXL, XL out of stock — 100% of demand", which I flagged rather than shipped. With the full history it drops off the list entirely — it was a small-sample artefact, not a bug. Heavyweight Tee settled from 64% to 58%, Pleated Chino from 79% to 53%.

Slim Jean's seeded return rate came out at 44%, higher than the 30% I aimed for, because concurrent refund passes double-counted a few lines. That is at the top of what real denim sees rather than impossible, so I left it — but it is not a number to put in a listing screenshot without saying it is a demo store.

Compliance

• Privacy policy at /privacy. Short, because the app holds one record per shop: domain, access token, install date. Every claim in it is checkable against src/shopify-data.mjs rather than boilerplate.
• The three mandatory GDPR webhooks, all HMAC-verified, all returning 401 unsigned. customers/data_request and customers/redact deliberately do nothing, and that is the honest answer: line items are reduced to a variant id and a quantity before anything is retained, and the app does not hold scopes that could see a customer.

Listing

listing/LISTING.md is ready to paste, with three screenshots at 1600×900. Search terms chosen for narrow intent rather than volume — "inventory app" is unwinnable against incumbents, but "size curve" and "broken size run" are phrases only the buyer types. That is Screenshelf's lesson applied: do not enter a keyword fight I cannot win.

Blocked on one thing

A support email address. Shopify will not accept a listing without one. Everything else for submission is done.

---

Actual — 2026-09-13 · Sizecurve, phase 6: the install was built wrong

47 tests passing. The app is live. The install flow was architecturally wrong and is now rebuilt.

What happened

The boss spent an hour clicking through a broken install loop on my behalf. That is the part worth recording, more than the bug itself.

The root cause, and it was one thing

I built the classic OAuth authorization-code flow: /auth → Shopify consent → /auth/callback → exchange code for a token. Embedded Shopify apps do not use that flow. Shopify installs them itself, and the app is expected to trade the session token App Bridge already holds for an offline access token.

So /auth/callback was never reached, no token was ever stored, every Shopify API call returned 401, the subscription read as null, and the app showed a paywall — then, after I "fixed" that, a reconnect loop. Every symptom traced back to that single wrong assumption.

The cascade it produced

Each of these was a genuine bug, and each was the same mistake wearing different clothes — code written for a context the app does not run in:

1. Cookie sessions. SameSite=Lax is never sent inside a third-party iframe, so my first lockout fix could not have worked anywhere.
2. window.open(url, '_top'). Silently swallowed by the embedded frame. The button did nothing at all — no error, no navigation.
3. The app handle. I assumed it matched the app name; Shopify had assigned sizecurve-2. Merchants would have hit a 404 at the moment they tried to pay. Now read from Shopify instead of configured.
4. My own error handling. The app correctly served a "needs reconnecting" page with a 403, and my loader discarded it because it only accepted 200 — replacing a specific, actionable message with "Sizecurve could not load". A catch-all that throws away what the server deliberately said is worse than no handler.
5. A revoked token looked identical to no subscription, so the app offered a paywall when the honest answer was "reconnect". Subscribing cannot fix a dead credential.

Why my tests did not catch any of it

They exercise the server. Every one of these failures lives in the browser, inside an iframe I cannot reach, and all of them fail silently rather than raising. "47 tests passing" was a weak signal for this layer all day, and I kept quoting it as though it were a strong one.

What I should have done hours earlier

Built /api/diag — an endpoint authenticated by the same session token, returning the install state and a token prefix, never a secret. It answered the question in one call: hasRecord: false. No token had ever been stored. I had the client secret the whole time and could have minted a session token to interrogate my own app instead of asking the boss to click through the admin repeatedly.

What I still cannot verify alone

Shopify refuses to exchange a session token I minted myself — invalid_subject_token. That is correct behaviour on their part, and it means only a real load inside the admin can confirm the fix works.

The part that is genuinely solid

The engine is untouched by any of this: pure functions, no I/O, 47 tests, and verified against the real dev store — 9 styles, 525 units, 42 returns, with correct broken-run detection, size curves and purchase orders. The product logic was never the problem. The plumbing was.

Outstanding

• One load of the app inside the admin, to confirm token exchange works.
• Sizecurve's scopes must be read-only (read_orders, read_products, read_inventory, read_locations). The boss set them to write; that contradicts the listing, the privacy policy and the reviewer notes, all of which state the app never writes to a store.
• The /auth route is now vestigial and should be removed once token exchange is confirmed.

---

Actual — 2026-09-13 · Sizecurve, phase 7: what the logs said

44 tests. The install chain is fixed end to end, pending one load of the app by the boss.

Three real causes, found by instrumentation rather than guessing

The turning point was persisting failures instead of tailing for them, and probing my own storage before trusting what it reported. Once the app could tell me what happened, the log gave all three at once:

token exchange ok ... scope=
shopify 403: "Non-expiring access tokens are no longer accepted for the
Admin API. Start using expiring offline tokens"

1. Wrong install flow. I built the OAuth authorization-code redirect. Embedded apps use token exchange — Shopify installs them and the app trades its session token for an access token. /auth/callback was never reached, so no token was ever stored.

1. Wrong token type. Token exchange then worked, and Shopify rejected the result: new public apps must request expiring offline tokens (expiring=1), which live an hour and carry a 90-day refresh token. Implemented with refresh two minutes before expiry, and the new record persisted before use — Shopify retires the previous token the instant a new one is issued, so dropping a refresh result would revoke the only working credential.

1. No access scopes at all. The active app version declared none — not empty, absent — so every token could read nothing. The new dev dashboard treats config as read-only and expects changes to ship as an app version, so this is now a shopify.app.toml deployed with the CLI. Released as sizecurve-2-3.

Along the way the CLI settled the app handle by rejecting sizecurve as taken: it is sizecurve-2, which is what the managed-pricing URL is built from and which I had guessed wrong twice.

Cleanups that came with it

• The whole OAuth flow is deleted, along with the state cookie and the cookie reader. The app now sets no cookies at all — verified on the live site.
• Webhooks are declared in config and registered by Shopify at install, so the runtime registration code is gone rather than left duplicating it.
• /api/diag stays: session-token authenticated, returns a token prefix and never a secret, and round-trips storage before trusting its own report.

The lesson, which is not about Shopify

I spent hours asking the boss to click through the admin and report back what they saw, when I had the client secret the whole time and could have minted a session token to interrogate my own app. Ten minutes of building /api/diag replaced every one of those round trips and produced the actual answer immediately.

The rule for next time: when a problem can only be seen in an environment I cannot enter, the first move is to make the app report from inside it — not to use the person as a debugger.

Actual — 2026-09-13 · Sizecurve, phase 4: the email actually sends

<!-- was actual/2026-09-13-phase4.md -->

Built, deployed and sending. 67 tests pass. Nothing is blocked.

What got built

• src/email.mjs — renders the digest and hands it to Resend. Pure render, so the rules are testable without a store or a network.
• mailDigest() in the sweep — runs after change detection, inside its own try/catch, because mail is the only part of this app that reaches a person and therefore the only part that can embarrass it.
• /email/prefs — signed opt-out, reversible from the same page, POST-safe for RFC 8058 one-click.
• The shop's contact address is read fresh from Shopify each week rather than cached. A merchant who changes it has told Shopify where they want mail.

Three decisions worth writing down

The subject line carries the fact. `Heavyweight Tee: M, L sold out (and 1 other change), not Your weekly Sizecurve report`. There is a test asserting the word "weekly" does not appear in a subject. A merchant should be able to decide whether to act without opening anything.

Unsubscribe is one click and needs no login. Demanding a login to stop email is how an app gets marked as spam instead, and a spam mark damages delivery for every other shop sending from the same domain. The same page offers the opposite link, so a mail client that prefetches the URL costs someone one click rather than their alerts.

The privacy page was wrong and is now right. It claimed "nothing else is written to disk" and "no other recipient of any kind". The analysis cache and the change history had already falsified the first; a mail provider falsifies the second. Both were true when written. That is the failure mode — a privacy policy is a claim about the code, so it has to be edited in the commit that changes the code, not audited afterwards.

Was blocked, now unblocked — same day

The first key was send-only: it could send mail but could not create a sending domain, and no domain on the account was verified, so every send came back 403 domain is not verified. The boss added the domain and handed over a full-access key, and the rest was mine.

• bananafest-destiny.com is verified in Resend, us-east-1, id 8102af61-588b-4e90-a07f-8ba2cd9e5a18.
• DKIM, the return-path MX and SPF, and a DMARC p=none record were written to the Cloudflare zone by me and confirmed resolving with dig @1.1.1.1.
• MAIL_FROM moved from the planned send. subdomain to the root, because the root is what the boss verified. The bounce path still sits on send., so the Porkbun forwarding that carries support@ is untouched.
• A real digest rendered and delivered: message f831a132-4d3a-467c-b5b1-2cf4499421be, subject Heavyweight Tee: M, L sold out (and 2 other changes).
• /email/prefs checked live: a valid token returns 200, a tampered one 403.

Nothing about the weekly email is outstanding. The boss can delete the full-access Resend key now; the Worker holds a send-only one.

Found while verifying

The dev store's shop record was gone from the Worker. That only happens on a correctly-signed app/uninstalled or shop/redact webhook, so the app was no longer installed on sizecurve-dev. Not a bug — opening the app once re-runs token exchange and restores it. The boss's reinstall, which the screencast records, did exactly that.

The screencast, and a bug it exposed

The boss recorded 3:08 of the real admin and I cut the captions to it: 28 lines re-timed frame by frame, burned in, tab strip and bookmarks bar painted out, address bar kept because it is what proves the app is embedded. Delivered as inbox/sizecurve-screencast.mp4. Timeline and departures from the shot list are in listing/SCREENCAST.md.

Reading the frames found a real bug that no test would have caught, because the test would have shared the mistake. On the first scan after install there is no prior snapshot, so every currently-broken style was reported as a transition: "M, L went out of stock. 279 units are stranded", dated today, minutes after install. The stranding is true. The event is not — nothing was observed going out of stock, the app had simply never looked before.

Events with no prior state for that style now carry first: true and are phrased in the present tense — "M, L are out of stock", "Returns are running at 44% of units sold" — and the email subject follows, "out of stock" rather than "sold out". The same fix covers a style added to the catalogue since last week. Five tests, 67 passing. Deployed as version 6491117d.

This is the kind of falsehood an app tells on the one screen where it is trying hardest to be trusted: the first one. Worth saying out loud that it survived a plan, a build and a test suite, and was only caught by watching somebody use it.

Two of the four remaining items closed by me, not by the boss — same day

The boss asked whether I could change any of the outstanding list or whether they had to. Two of the four were mine after all.

support@bananafest-destiny.com delivers. Measured, not assumed. A probe to support@ reported delivered; a control to a made-up address on the same domain bounced 554 5.7.1 … Relay access denied. Porkbun's forwarders refuse addresses with no rule, so acceptance is proof the rule exists. The reviewer's email will arrive.

The demo video is hosted on our own domain. public/demo.mp4 ships in the Worker's static assets and plays at /demo, a page with chapter notes and a media-src 'self' CSP widened for that path alone. The public preview header now links to it; the embedded dashboard does not, because a link out of the Shopify admin frame would be wrong. Shopify's App testing information takes any URL, so no YouTube account stands between this and submission. Deployed as version d89a4e95-2191-49db-ae51-abc5ddb9a132, 67 tests still pass.

Two genuinely need the boss: shortening the four managed-pricing bullets that the recording caught truncated, and pressing submit. Both are Partner dashboard work I have no credentials for.