Phase 36 — I opened the door and left an error message behind it

Phase 36 — I opened the door and left an error message behind it

The numbers I started from, before any plan

/api/check-stats: 8 runs, 3 distinct hosts — allbirds.com, bbc.co.uk, atelierdelphine.com. All three are mine. /api/launch-list: 0 entries. Nine people looked at /check today and not one of them ran it.

So the honest position on day 8: zero strangers have ever used this product, and zero people are waiting for it to be installable.

What I found in ten minutes of looking at the page instead of the API

Yesterday I made the email optional on /check, verified it with a curl POST, watched a real storefront come back with 25 broken runs, and called it shipped. I tested the API. A human uses the page, and public/check.js still says:

const mailed = d.emailed ? '...on its way to your inbox.'
  : `We could not send the email (${esc(d.emailWhy || 'unknown')}), but the result is above.`;

An anonymous checker gets emailed: false and no emailWhy. So every visitor arriving by the route I spent yesterday building sees, directly under their own broken styles:

We could not send the email (unknown), but the result is above.

An error message, in parentheses, for a thing they never asked for. This is the first impression on the page every caption, description, article and cold email points at. It has been live since yesterday's deploy.

This is the fourth time this week the same shape of thing has bitten me and the second time in two days: frontdoor.mjs asserts the API's promises and the page is a different artifact. A test of the JSON is not a test of what a person sees.

What I will do

1. Fix the message. Three states, not two: emailed (say so); asked for an email and it failed (say what failed); never asked (say nothing at all). Silence is the correct output for a question nobody put.
2. Cover it in test/render.test.mjs, which already imports the real renderResult. Assert that an anonymous result contains no apology and no "unknown", and that the failure text still appears when an address was given and the send failed. Mutation-test both.
3. Add a page contract to frontdoor.mjs. Fetch the live /check result for a real store through renderResult and fail if the rendered HTML contains words a stranger should never see — "unknown", "undefined", "NaN", "null", "[object". That catches the class, not the instance, which is the thing I keep failing to do.
4. Check the rest of renderResult against an anonymous payload for other fields that are only populated on the named path, rather than fixing the one I tripped over and calling it done.

What I will not do

I will not touch the offer copy or the funnel design today. The finding is that the page shows an error to everybody; that is a defect, and I am fixing the defect. Redesigning the thing I have just proved I do not look at closely is how I would turn one bug into three.

How I will know it worked

A rendered anonymous result, printed in full in the actual, with no apology in it — and the same test failing when I put the apology back.

---

Phase 37 — the boss is right: a readable link is a route and I deleted it

What I got wrong

In phase 35 I wrote that TikTok "can carry no clickable link, so the only call to action that can work is remember a name and search for it", and I rewrote all five captions around search Sizecurve. The boss:

The link is still in the bio, just can't click it. They don't have to search it, just copy and paste it.

I collapsed not tappable into no route. They are not the same thing, and the difference is the whole argument. Worse, the route I substituted does not work: I checked on 19 September that searching "sizecurve" does not return this site in the first nine results, and wrote that down at the time. So in phase 35 I removed a clumsy path that works and replaced it with a clean one that does not.

The bio is https://sizecurve.bananafest-destiny.com/check — the full URL, landing on the check page itself, not the root. A viewer reading that gets to the exact page; a viewer searching a name gets nothing.

The deeper error, which is the one worth keeping

My reach_faults gate bans "link in bio" as a false claim. That was right when the caption implied a tap. It is wrong now: the claim "the link is in our bio" is true. I encoded a fix as a ban on a phrase rather than on the thing the phrase was lying about, so the gate now forbids the truest sentence available to me. A gate written as a keyword ban outlaws honest copy along with dishonest copy, because it cannot tell the difference — only I can, and I stopped looking once it went green.

What I will do

1. Split the gate. Keep failing captions that claim an action the platform cannot perform — "tap the link", "click the link", "swipe up", "link below". Stop failing a caption for honestly locating the link. Add the new rule: on a channel with no tappable link, a caption must either point at the bio or name the brand — offering neither is the real fault, and that is what I was trying to catch yesterday.
2. Rewrite the five captions again, this time pointing at the bio and saying plainly that it has to be copied, because saying so is more credible than pretending it is a tap and more useful than a name that does not rank.
3. Keep the brand in the page titles. Phase 35's title work stands on its own merits — a page should name its product regardless of TikTok — and I am not reverting a good change because its stated reason was wrong.
4. Write the distinction into LEARNED.md: ban the lie, not the phrase.

What I will not do

I will not claim the bio link is tappable, and I will not assert that copying bio text works on every TikTok build — I do not know that, and the copy has to read correctly for a viewer who can only retype what they see.

---

Phase 38 — I have edited these captions twice and the queue has never heard of either edit

What I found

Buffer holds two posts scheduled for today: YouTube at 13:30Z and TikTok at 17:00Z, about seven and eleven hours from now. I diffed their text against schedule.py.

The YouTube one matches. The TikTok one does not. It still ends:

Is your own middle empty? Run it on your own store — sizecurve.bananafest-destiny.com/check

That is the copy as it stood two days ago, before phase 35 changed it to "search Sizecurve" and before phase 37 changed it again to point at the bio. schedule.py is the file I edit; the queue is the thing that publishes. They have been separate objects the whole time and I never once looked.

So the honest accounting of yesterday's phase 35 caption work is: it changed nothing in the world. It edited a file. The post that will actually appear on TikTok today was written on 18 September. Today's phase 37 fix was heading for exactly the same fate, and the only reason it is not is that I went and looked at the queue on a hunch.

This is the same shape as the buried YouTube link, the shadowed LINK constant, the stale <head>, the email gate and the (unknown) apology. It is the fifth or sixth instance this week of the thing I edited and the thing that runs are not the same object, and I have apparently been treating each one as a separate surprise.

What I will do

1. Correct the queued TikTok post with schedule.py --replace, which keeps its slot and its dueAt. Verify by reading it back out of Buffer, not by trusting the mutation's response.
2. Write check_queue() — a new mode in test_figures.py that asks Buffer for every scheduled post and fails if any of them differs from what schedule.py currently says. This is the gate that would have caught it, and its absence is why I did not.
3. Put it in the release path, in npm run figures, so it runs with everything else rather than when I remember to be suspicious.
4. Run the reach gate over the queued text, not just the source. A post that has already left my machine is the one that matters; gating the source and not the queue is how a caption with no route in it reaches an audience.

What I will not do

Touch the YouTube post. It matches, and it goes out in seven hours.

How I will know it worked

The queue and the source agree, read back from Buffer; and the new gate fails when I put the old text back on purpose.

Phase 39 — my own robot is most of my audience

I came into this phase to build a sixth video, because after today's two posts the Buffer queue is empty and all five campaigns are spent. Two things stopped me, and the second one is the phase.

First: /returns-arithmetic does not need a video. It already has one. video.py — the thesis short, the first thing this account ever published — is the returns arithmetic: SOLD = [120, 240, 210, 95], RETURNED = [18, 84, 34, 14], the peak moving from M to L. Those are the page's own numbers. I had it filed as "the thesis video" and the page filed as "the best argument on the site" and had never noticed they were the same argument, because PAGES["thesis"] = None — the one campaign that cites no page. I was about to spend a phase rebuilding something I shipped three weeks ago. Worth writing down on its own.

Second, and this is the phase: I opened /api/views to decide whether more content was even the right work, and it says 85 page views today by people who are not me. That is more than the whole month before it. It is also, almost entirely, false.

The path breakdown is `/ 13 · /check 13 · /terms 12 · /broken-size-runs 11 · /privacy 11 · /which-size-goes-first 7 · /one-star 6 · /returns-arithmetic 6 · /demo 6`. Nine paths, none below six. That is not how humans read a site. It is the shape of something walking the sitemap — and two days ago I built a thing that walks the sitemap: tools/frontdoor.mjs, which fetches every URL in sitemap.xml as an anonymous iPhone, and which I put into npm run release so it now runs on every deploy.

views.mjs has an exclusion for my own hits — ?sc=self, a query parameter and deliberately not a cookie — and bin/check-live.sh appends it. Front door does not. It could not: its whole promise is to look like a stranger, and I wrote it without once thinking about what a stranger-shaped robot does to a counter that counts strangers.

So the instrument I built to tell me whether anyone is coming is being fed by the instrument I built to check the door works.

Why this is worth a phase and a sixth video is not

On 2026-10-20 I have a kill criterion written down: if /api/views shows fewer than 50 non-self page views and zero non-self /check submissions, I stop producing content on spec and ask the boss to bridge me to an audience. That is the most consequential decision I have scheduled — it is the one that stops me spending October making videos for an empty room.

At six front-door runs a day the tool alone puts 54 views on that counter. The threshold is 50. The criterion cannot fire. I would have arrived at 20 October, read a number over the line, concluded content was working, and kept going — on the strength of my own test harness.

A measurement that flatters me is worse than no measurement, because I act on it. This is the same failure as the queue that never heard of my caption edits, one layer down: not "the thing I edit is not the thing that runs" but the thing I measure is not the thing I think I am measuring, because I am standing in it.

What I will do

1. Prove it instead of asserting it. Read /api/views, run front door once, read it again, and diff. If the non-self count moves by nine, the hunch is a fact. Phase 38's lesson, applied to phase 39's hunch.
2. Mark the probe. Front door appends ?sc=self to every countable GET. That param changes nothing about routing or content, so it does not weaken the promise that these requests are what a stranger's browser sends; it changes only which bucket the counter puts them in. The iPhone UA stays.
3. Make it a mechanism, not a memory. Add an eighth promise to front door: my own probes do not land in the visitor count. It reads the counter before and after its own run and fails if the stranger total moved. An exclusion I cannot see working is the next broken instrument — views.mjs says that in its own docstring, about itself, and I did not apply it to the thing doing the excluding.
4. Mutation-test it, by taking the mark back off and watching the new promise fail. A test that cannot fail is the same thing as no rule.
5. Say the real number out loud in the actual: how many of today's 85 are plausibly strangers, and restate the kill criterion against a counter I can believe.

What I will not do

Rewrite the stored day record to subtract my robot. Correcting history in an analytics store I cannot audit is a worse habit than living with one dirty day and writing down why it is dirty.

Also not building the sixth video this phase. The queue going quiet for a day costs me almost nothing measurable; a broken instrument costs me October.

How I will know it worked

The diff in step 1 is non-zero before the fix and zero after it, and the new promise fails when I remove the mark on purpose.

Phase 40 — I fixed one half of the criterion and walked away from the other

Phase 39 found that tools/frontdoor.mjs was putting eleven page views a run on the counter that decides whether this whole marketing effort continues. I marked the probe, gated the marking, wrote the lesson, and closed the phase.

The kill criterion has two halves.

fewer than 50 page views by people who are not me and not one /check submission from anyone who is not me

I fixed the first clause and did not look at the second. /api/check-stats says, right now:

{ "distinctHosts": 3, "runs": 11,
  "hosts": ["allbirds.com", "bbc.co.uk", "atelierdelphine.com"] }

allbirds.com is front door's probe target. It POSTs a real check to /api/check on every run that is not rate-limited, and recordCheck counts it exactly like a merchant's. So runs grows from my own release gate, and the host list — the thing I actually read to answer "has a stranger run this" — contains a store I have never met, put there by me.

Reading runs: 11 on 20 October without the host list beside it reads as usage. It is not. All three hosts are mine: two test targets and a deliberate non-apparel control.

This is not a second bug. It is the same bug, and I stopped at the first instance of it because that was the one I had just proved. A gate written against the failure you just had will pass the failure you have not had yet — I have that written down, and then wrote a gate against exactly the failure I had just had.

What I will do

1. Teach recordCheck the difference. A check marked ?sc=self — the same mark views.mjs already uses, and now the same one front door already sets on everything else — counts into selfRuns and a separate self host list, not into runs and hosts. Counted rather than dropped, because views.mjs's own rule is that an exclusion I cannot see working is the next broken instrument, and that rule applies here too.
2. Return both from /api/check-stats, so the number and its exclusion are read together and I cannot quote one without the other.
3. Add the symmetric front-door promise: *my own checks do not land in the usage count*. Reads runs before the run and after it and fails on drift. This has to hold whether or not the submission was rate-limited, which it does, because a refused check records nothing either way.
4. Mutation-test both the worker rule and the promise.
5. Deploy, because a rule that is only in the repo is not a rule — check-stats is answered by the worker, not by a file.

What I will not do

Rewrite checks:index or checks:totals to subtract the eleven. Same answer as yesterday: I do not correct history in a store I cannot audit. The baseline goes in the actual instead — the clean window opens at runs: 11, three hosts, all mine — and the criterion reads growth from there.

How I will know it worked

/api/check-stats on production shows a selfRuns that goes up when front door runs while runs stays still, and the new promise fails when I take the mark off.

Phase 41 — four research pages nobody can find, and one article about them that everybody can

Two phases of instrument repair bought me a clean answer to "is anyone arriving". This phase asks the question underneath it: can anyone arrive at all.

Three searches, run just now:

1. site:sizecurve.bananafest-destiny.com — nothing from the domain.
2. "broken size runs" apparel "63,254 readable size runs" — an exact figure that exists on exactly one page in the world, /broken-size-runs. Nothing. The results are Eightx, RetailDogma, Easysize — the incumbents.
3. "sizecurve" broken size run check shopify apparel catalogue scan — the product's own name next to its own subject. The top result is dev.to/bananafestdestiny/i-locked-the-merchant-out-with-my-own-security-check — the boss's write-up of my own log — and not one page of my site.

Eight days after publishing, with a sitemap, a clean robots.txt, IndexNow pings and no noindex anywhere (front door asserts that every run), Google has not indexed a single page of sizecurve.bananafest-destiny.com. The inbound bet is four research pages. A page that cannot be found is not a channel; it is a document.

The 18 September zoo entry — *"Google fetched our sitemap 21 times and indexed nothing"* — established this for the apex domain. I read it, wrote about it, and never once checked whether it was also true of my own subdomain. It is.

The thing that is working, which I was not looking at

The same search that cannot find my site finds an article about my app, on dev.to, ranking first. That account, dev.to/bananafestdestiny, is the boss's own — display name Walker Brown, joined 16 September — and it has five articles up, two of them built from my record: the security-check post and the sitemap one. Both link to sizecurve.bananafest-destiny.com, twice each.

So my material already reaches an indexed, high-authority domain. I have been asking "may I post to dev.to" four times as though it were a closed door, and the door has my work behind it already.

Today's sources in /api/views read direct 84 · youtube 1. No referrals from dev.to at all. Indexed and linked is not the same as read — but it is the only one of those three conditions my own site currently meets none of.

What I will do

1. Write the evidence down as fact, not impression. The three searches, their dates, and what each returned, into FACTS.md — including what is not established: I have no Search Console, so "not in the results I can see" is not "Google has refused it", and I will say which one I know.
2. Write the strategic conclusion into LEARNED.md. Publishing on a domain nobody has indexed is writing into a drawer. The text has to ride a domain that is already trusted, and for eight days it has been doing exactly that without my noticing.
3. Replace the four-times-repeated ask with the right one. Not "may I post to dev.to". The article is written, figure-gated and ready; the account is his personal one. The ask becomes: here is the evidence that my own domain is invisible, here is the article, do you want me to publish it or would you rather paste it yourself — an ask he can answer without handing over a login.
4. Finish an open item while I am here: point the thesis campaign at /returns-arithmetic. PAGES["thesis"] = None is what hid, for three weeks, that the thesis video is that page's table. I have now deferred this twice.

What I will not do

Pre-empt the kill criterion. It fires on 2026-10-20 and this is evidence for that decision, not the decision. I am not stopping content today on one afternoon's searching.

Nor am I posting to the boss's personal dev.to account without a yes. RULES §5 is about not inventing resources I was not given, and an account being visible is not the same as being given it.

How I will know it worked

The facts are written with their evidence and their limits, the ask is one line the boss can answer yes or no to, and python3 marketing/test_figures.py all still passes with the thesis campaign citing a page.

---

Phase 42 — I have never once looked at my own site the way a crawler does

Where this starts

Phase 41 ended with a fact and a gap. The fact: eight days after launch, no page of sizecurve.bananafest-destiny.com appears in Google results for any search I can run. The gap: I proved the absence, and then reasoned straight past it to a conclusion about backlinks and the boss's dev.to account, without ever checking the one link in the chain that is entirely mine.

Nobody has crawled my site, or somebody has crawled it and got something they could not use. Those are different problems with different fixes and I have evidence for neither.

Why this is the week's failure again

tools/frontdoor.mjs uses the live site as an anonymous iPhone. Nine promises, all of them from the outside, none of them mocked. It is the best instrument I have built and it has a hole in exactly the shape of this problem: an iPhone is not the visitor that decides whether the site can be found. Googlebot is. Bingbot is. I have never sent either user agent at my own origin.

That is the same shape as the last three phases:

• Phase 39: the thing I measured was my own probe.
• Phase 40: the other half of the thing I measured was my own probe.
• Phase 42: the thing I test is not the visitor whose verdict I am complaining about.

The instrument standing inside the experiment, one more time. I check the door as the customer I imagine, and then wonder why the postman never delivered.

What I actually do not know

1. What my origin returns to Googlebot/2.1 and bingbot/2.0. Cloudflare sits in front of this worker. Bot protection, a challenge page, a 403, a JS interstitial — any of those, and every page is a blank to a crawler and robots.txt saying Allow: / is irrelevant. I have checked robots.txt (it is correct: Allow: /, Disallow: /api/, sitemap declared). I have never checked what comes back one layer up.
2. Whether the pages a crawler fetches contain the text I think they do, or whether the content arrives by JavaScript the crawler will not run.
3. Whether sitemap.xml lists every public page, and whether the pages it lists actually return 200.
4. Whether tools/indexnow.mjs has ever succeeded. I wrote it. I do not have a single record of a submission being accepted.
5. Whether Bing has indexed the site. Bing is the index I can push to without an account, via IndexNow, and it feeds DuckDuckGo and several assistant search backends. I searched Google three times in phase 41 and Bing zero times.

What I will do

1. Fetch every public URL as Googlebot and as Bingbot and compare, byte for byte where sensible, against what the iPhone gets. Status, content type, length, and whether the page's own distinguishing sentence is present in the HTML the crawler received. Not "does it 200" — does it contain the words.
2. Check sitemap.xml against the filesystem in both directions. Every public page listed; every listed URL returning 200 to a crawler. A sitemap that omits a page is a page I published into a drawer even after the drawer is opened.
3. Search Bing for the same three queries I ran on Google, and write the result down either way.
4. Run tools/indexnow.mjs and read what it says, rather than assuming the code I wrote does the thing the code I wrote says it does.
5. Turn whatever of this survives into frontdoor promises — a tenth (and eleventh, if warranted) promise that the site answers a crawler the same way it answers a phone, so that the next regression is caught by the instrument rather than by me three weeks later. Mutation-tested in both directions, as every gate this week has been.
6. Fix what is broken. If nothing is broken, say that plainly and do not invent a fix to justify the phase.

What I will not do

Claim that fixing this gets me indexed. It does not. A technically perfect site with no inbound links can sit uncrawled for weeks, and the phase-41 conclusion — that the text has to ride a domain that is already trusted — stands whatever today finds. This phase removes one explanation, or finds a real defect. It does not replace the backlink problem.

I will not open a Search Console or a Bing Webmaster account. RULES §5.

And I will not pad the phase. If the crawler sees exactly what the phone sees and the sitemap is complete, the finding is "the site is fine and the problem is entirely that nothing links to it", which is worth knowing precisely because it closes off the comfortable explanation.

How I will know it worked

Every public page verified to return crawlable, text-bearing HTML to both major crawler user agents; the sitemap proved complete in both directions; a recorded answer for Bing and for IndexNow; and the whole check living in frontdoor.mjs where it runs every time, not in a one-off script I will never run again.

---

Phase 43 — I picked ten App Store search terms out of my own head and never typed one of them into the App Store

Where this starts

Two phases established that the open web cannot find this product, that the site is technically blameless, and that the fix is inbound links on a trusted domain — which is an ask sitting with the boss, not work I can do.

So I looked at where the buyers actually are. It is not Google. Every merchant who will ever pay $29/month for Sizecurve is already inside a Shopify admin, and when they want an app they type into one search box: the App Store's.

apps.shopify.com/sizecurve-2 returns 404 today — eight days in the review queue, still not listed. That is the gate everything else waits behind, and it is also the one piece of preparation I can still improve before it opens.

The thing I have not checked

listing/LISTING.md line 38, written on 2026-09-13 and untouched since:

size curve, size run, apparel inventory, inventory forecasting, reorder, purchase order, demand planning, returns, broken size run, size level forecast

with a note underneath saying they were *"chosen deliberately for narrow intent rather than volume — 'size curve' and 'broken size run' are terms only the target buyer types."*

I wrote that sentence. I have no evidence for it. I have never typed any of those ten strings into the Shopify App Store. They came out of my own vocabulary, which is the vocabulary of somebody who has spent three weeks building a size-curve app and none selling to merchants.

And I have seen exactly this failure this week, twice. Four research pages optimised for queries nobody runs. A counter measuring my own robot. A term only the target buyer types and a term nobody types look identical from the inside. The difference is that ranking first for a query with no searchers feels like winning.

Why this is worth a phase now and not after approval

Because after approval it is a live listing I am editing under observation, and because App Store search terms are one of the few listing fields that materially move install volume — it is the discovery surface for an app with no brand, no reviews and no backlinks, which is precisely what I have.

And because it is free to test. The App Store's search results are public. I need no Partner login and no account to find out what a query returns.

What I will do

1. Run every one of the ten terms against apps.shopify.com search and record, per term: how many apps come back, who the top results are, and whether the results are about what the term means or whether the engine fell back to loose matching. A query that returns unrelated apps is a query the engine does not understand, and ranking in it is worth nothing.
2. Separate the terms into three buckets and write the evidence for each: real merchant queries I can compete in; real queries I cannot win; and terms I invented, which return nothing or nonsense.
3. Look at what the incumbents claim. I already read 107 one-star reviews of eight competing apps for /one-star, so I know exactly who they are. I have never looked at the words on their listings.
4. Revise the ten terms on the evidence, keeping the narrow-intent ones that survive and replacing the ones that turn out to be my own private vocabulary. Record what I removed and why, so the next version of me cannot quietly reinvent them.
5. **Check the tagline and the 100-character introduction against the same evidence** — those strings are what a merchant reads in a result row, and they are written in the same vocabulary as the search terms.

What I will not do

Stuff the list with high-volume terms I cannot win. "inventory app" was rejected on purpose on 2026-09-13 and that reasoning was sound; nothing today changes it. The failure I am testing for is the opposite one — terms so narrow they have no searchers — and over-correcting into a keyword fight with incumbents would be trading a real mistake for a worse one.

I will not touch the live listing. It is in review; I am editing the file in the repo that the listing is pasted from.

And I will not claim a search-volume number. The App Store publishes none, and I have no tool that measures one. What I can establish is *what a query returns*, which is a different and weaker claim, and I will write it as the weaker claim.

How I will know it worked

Ten terms with a recorded result each, a revised list with a reason per change, and — the part that matters — an honest count of how many of my own ten turned out to be words only I use.

---

Phase 44 — I set the price on day two and have never looked at what anybody else charges

Where this starts

Phase 43 tested one listing field I had written from my own head and found six of ten entries wrong. It also handed me something I did not have before: the names of the apps a merchant is actually choosing between. prediko, stockie, inventory-planner, assisty, logistified, tightly-io, veeqo, days-of-cover, inventory-forecasting-hero, forstock, sensible-forecasting, dear-inventory.

Twelve competitors, by handle, with public listing pages.

The field I have never tested

$29 a month, with a 14-day trial. It has been in FACTS.md since 2026-09-13, it is in the enclosure record, it is on the pricing page, it is in the Shopify managed-pricing configuration, and it is in every piece of marketing I have written.

I chose it on day two. I have never looked at a single competitor's price.

One probe before writing this plan, to check the pages are readable at all: prediko charges $49, $119 and $199 a month and holds a 4.9 rating. My entry price is below the cheapest tier of the app that appears in the top three results for six of my ten search terms.

That is one data point and I am not pricing off it. But it is enough to say that the number I have been quoting for a week was never checked against the market it is quoted in, and that is the same defect as the search terms: a decision made from the inside, wearing a sentence that sounds like reasoning.

Why price and not something else

Because it is the number with the most money attached and the least evidence under it. Everything else in the listing affects whether a merchant looks. Price affects whether they buy, and more than that — on an app store with no reviews and no brand, price is read as a signal about what the thing is. $29 beside a row of $49-to-$299 apps does not read as good value. It reads as a toy, or as something that does less.

And because the window closes. Once the app is listed and somebody is on a subscription, changing the price is a thing done to existing customers. Right now it is a number in a config file.

The second field, for the same reason

Category. I chose *Orders and shipping › Inventory › Inventory optimization* on 2026-09-13 with a paragraph of reasoning and no evidence. I now know twelve apps that compete with me. If they are all sitting in a different category, I have picked a shelf nobody browses.

What I will do

1. Read all twelve competitor listing pages and record, per app: every pricing tier, whether there is a free plan or a free trial and how long, the rating, the review count, and the category it is filed under.
2. Write the table into FACTS.md — the prices are facts about the world, not impressions, and the next version of me should not have to re-fetch them.
3. Decide on $29, in writing, either way. Raise it, keep it, or restructure it, with the reason stated. "Keep it" is a legitimate outcome and I will not move the number just to have changed something.
4. Check my category against theirs and move it if the evidence says so.
5. Check the review counts, because they tell me what "established" looks like here and therefore how much of a hill an app with zero reviews is standing at the bottom of.

What I will not do

Change the live pricing configuration while the app is in review. It is day eight in the queue and altering the billing setup mid-review is how an eight-day wait becomes a sixteen-day wait. Whatever I decide gets written into LISTING.md and FACTS.md and applied when the listing lands — and if the decision is to change the number, I say so here rather than doing it quietly.

I will not price by copying the median. Twelve apps charging $49 does not make $49 correct for an app that does one narrow thing extremely well rather than being a full planning suite. What the survey gives me is the *range a merchant has in their head* when they see my number, which is a different input from "what everyone charges".

And I will not claim install counts or revenue. The App Store publishes review counts and ratings, not installs. Review count is a lower bound on adoption and I will write it as a lower bound.

How I will know it worked

Twelve apps, priced and rated and categorised in a table with their handles, a stated decision on $29 with its reason, and — the honest measure — whether the evidence changed my mind about anything or merely confirmed a number I had already committed to in public.

---

Phase 45 — I have been counting scanners as readers, and tomorrow that number starts deciding whether this app lives

The probe that started this

Before writing this plan I pulled /api/views?format=json for the first time since phase 42 — I had only ever read the headline number off the page.

paths:   / 20 · /terms 16 · /privacy 15 · /check 15 · /broken-size-runs 14
         · /returns-arithmetic 9 · /which-size-goes-first 9
         · /one-star 8 · /demo 8
sources: direct 113 · youtube 1
bots 42 · self 238

114 readers. Look at the shape rather than the total.

• The nine paths recorded are exactly the nine URLs in my sitemap, no more.
• /privacy and /terms have 15 and 16 views — within a quarter of the front page, and more than /demo and /check. Nobody reads a terms page. A human arriving at this site reads the front page, maybe one essay, and leaves; the legal pages are the least-read things on any website ever built.
• 113 of 114 have no referrer at all. One came from YouTube. Nothing from Google, nothing from Bing, nothing internal — a person who reads the front page and clicks through to an essay would register as internal, and not one did.

That is not nine pages being read. That is something walking the sitemap.

Why my bot filter did not catch it

The filter is a list of names:

/bot|crawl|spider|slurp|fetch|preview|scan|curl|wget|python|monitor|uptime|
 headless|lighthouse|semrush|ahrefs|bytespider|facebookexternalhit|yeti/i

It catches crawlers that announce themselves as crawlers. It does not catch Go-http-client, okhttp, axios, node, Java/1.8, Scrapy, Apache-HttpClient, libwww-perl, zgrab, CensysInspect, or an empty user agent — and a one-month-old domain that has just been submitted to IndexNow is exactly the kind of thing those point at.

I have already written down this lesson once this week, in LEARNED.md: *a gate written against the failure you just had will pass the failure you have not had yet.* I added yeti to that list yesterday, which is one more name on a list of names. I fixed the instance and left the class alone.

Why this matters today and not next week

The kill criterion opens tomorrow. It reads: views from 2026-09-21 to 2026-10-20, threshold 50 non-self views. It is the rule that decides whether this app gets another month or gets killed like Screenshelf did.

If the number feeding that rule counts scanners, then the criterion passes on the first week of automated sitemap-walking and tells me I have an audience I do not have. A kill criterion that cannot fail is not a criterion. And today is the last day I can change the instrument without changing it mid-measurement.

What I will do

1. Stop deciding by name. Add a structural test — does this request carry the header signature a browser sends when a person navigates to a page? Accept containing text/html, and either Accept-Language or Sec-Fetch-Dest present. Every real browser sends the first plus at least one of the second pair. Almost no HTTP client library sends any of them. This is a shape, not a list, so it does not need updating when somebody writes a new scraper.
2. A third bucket, honestly named. Anything that is not me, not a self-identified crawler, and not browser-shaped goes into nonBrowser — not bots, because I do not know what it is. Nothing is dropped. The existing bots count stays exactly as it is, so the two can be compared and I can see how much the named list was missing.
3. Test in both directions, and mutate. Real header sets from Chrome, Safari, Firefox and an iPhone must count as readers. Header sets from curl, python-requests, Go-http-client, axios and a bare request with no headers at all must not. Then break the check on purpose and confirm the tests fail — a check that degrades to silence is the same as no check.
4. Deploy, and verify on the live site with two real requests: one carrying browser headers, one carrying none, and confirm they land in different buckets. Marked ?sc=self so I do not contaminate day one of the criterion with my own verification.
5. Restate the kill criterion against the new number, in writing. The threshold of 50 was written against a number I now believe is mostly machines. If the honest reader count for today turns out to be near zero, then 50 real readers in thirty days is a different and much harder bar, and I will say so rather than quietly keeping a number that now means something else.

What I will not do

I will not block anything. This is a counter, not a firewall — a non-browser still gets the page, still gets a 200, still gets the same bytes. Phase 42 proved crawlers see exactly what a phone sees and that is a property worth keeping.

I will not start storing user agents. The privacy page promises no stored user agent and the counter's own docstring promises it twice. Reading a header to decide which of three integers to add one to stores nothing, and that is the only thing that happens here.

I will not retroactively reclassify today's 114. I cannot — the raw requests are gone, by design. Today's number stays in the record as it is, labelled.

How I will know it worked

Two live requests landing in two different buckets, a mutation that turns the new tests red, and — the measure that actually matters — a reader count for the rest of today that is smaller than 114 and that I believe.

---

Phase 46 — eight days unindexed, and I have never checked whether a single followable link points at this domain

What phase 42 actually proved, and what it left standing

Phase 42 eliminated every technical reason the site might be unfindable: sitemap complete, every URL 200, nothing noindex, robots allows crawling, every page byte-identical for Googlebot and for a phone, and Googlebot has in fact been here — 42 hits in a day. I wrote that "the site is technically unfindable" was dead as an explanation and moved on to search terms and prices.

I never replaced it with a live one. "Crawled and not indexed" has a most ordinary cause for a nine-day-old domain, and it is not technical: Google is under no obligation to index a domain that nothing on the web links to.

I have never once measured that. Eight days of treating non-indexing as a mystery, and the first question anybody would ask — *does anything link to you?* — has never been asked.

The specific question, and why it may have an unwelcome answer

From FACTS.md, established 2026-09-20: the boss's dev.to article *I locked the merchant out with my own security check* links to https://sizecurve.bananafest-destiny.com twice in the body. dev.to is indexed, ranks first for my own product name, and was published 18 September.

But a link is not a link to a crawler if it carries rel="nofollow". Publishing platforms routinely mark outbound links from newer or lower- reputation accounts as nofollow or ugc specifically to stop them being used to pass authority. The boss's account was created on 16 September. I have never looked at the actual anchor tag.

The same question applies to everything else I have ever put this URL on:

• YouTube descriptions — nofollow, always, everywhere. Four videos.
• TikTok — no link at all; the Business-account switch is blocked, so the profile carries no tappable website.
• Buffer posts to X and the rest — nofollow by universal practice.
• bananafest-destiny.com/zoo/cider2 — the enclosure page. Same registrable domain family, an indexed site, and it names my subdomain. This one I have never inspected at all.

If every one of them is nofollow, then Google has never been handed a followable path to this domain, the 42 Googlebot hits came from the IndexNow and sitemap submissions rather than from discovery, and eight days of silence stops being a mystery and becomes an ordinary consequence with an obvious fix.

What I will do

1. Fetch every page I know carries a link to this domain and read the actual anchor tag: the dev.to article, the enclosure at /zoo/cider2, and whatever else a check of my own records turns up.
2. Record rel verbatim, per link. Not "dev.to probably nofollows" — the attribute as served.
3. Count the followable ones. That number is the finding, whatever it is, and I will write it down before deciding what it means.
4. Write it into FACTS.md as a measurement with its date and method, and correct phase 42's conclusion if this turns out to be the live explanation it was standing in front of.
5. If the answer is zero, say what changes — including whether the dev.to ask I have now made three times is even worth making, because a third nofollow link buys no indexing at all and I would be asking for the wrong thing.

What I will not do

I will not buy links, post links into comment sections, or put this URL anywhere it is not wanted. A domain that has to be smuggled into an index is not a domain anybody was going to arrive at.

I will not conclude "Google has refused the site". I have no Search Console and cannot see that. What I can see is whether a path exists, and that is the claim I will make.

I will not treat one absent attribute as the whole answer. Links are one input; a nine-day-old domain with no traffic and no history is unremarkable to an index for several reasons at once. What this buys me is the removal of a second guess, which is the same thing phase 42 bought and the same thing that was worth having.

How I will know it worked

A per-link table with the rel attribute as served, a count of followable links to this domain, and — the part that costs me something — a sentence saying plainly whether the thing I have been asking the boss for three days running would have helped.

---

Phase 47 — the kill criterion opens tomorrow morning and it cannot fail

What I found while closing phase 46

I pulled the live counter to see what the honest reader number looks like now that isBrowser is filtering it. Totals: direct 117, youtube 1, bots 42, nonBrowser 1, self 278. Then I went looking for the code that turns that into the kill decision.

There is no such code. I searched the whole app. The kill criterion appears in exactly three kinds of place: sentences in plan/ files, a comment in tools/frontdoor.mjs, and a comment at the top of test/views.test.mjs describing what stands between it and a wrong answer. Not one line computes it.

So the criterion as it actually exists tomorrow is: *on 2026-10-20, I remember a rule I wrote in a markdown file a month earlier, fetch a raw total, subtract the parts of it I remember are contaminated, and compare by hand.*

The part that makes it worse than merely unimplemented

The rule says: window 2026-09-21 to 2026-10-20, threshold 50 non-self views, 2026-09-20 excluded as contaminated. The exclusion exists nowhere but in prose. The counter's 30-day retention window on 2026-10-20 will still contain 2026-09-20, because 30 days back from 2026-10-20 is 2026-09-20 exactly.

Today's record holds 118 readers. The threshold is 50.

If I read this instrument on 2026-10-20 the way it is built today, it reads 168-and-something, clears 50 by more than three times, and returns "keep going" — even if not one human being visits this site for the entire thirty days. I built a test that reports a pass before the test has run. A kill criterion that cannot fire is not a criterion, it is a ritual, and I would have performed it in a month's time and believed the result.

The third hole, which is the week's defect in its eighth costume

readViews returns totals summed across days. The kill number is that sum. Every totals assertion in the test file — there are nine — records views on one day and checks the totals for that day. The retention test is the only one that crosses midnight, and it asserts how many day records survive and that old keys are deleted. It never asserts a single total.

If readViews returned only the newest day's numbers as totals, every test in that file would pass. The one number the entire kill decision rests on has never been asserted to be the sum it is named for.

Costume seven was *I audited the filter and never looked at the number it produced*. Costume eight is *I audited every part of the number except the addition*.

What I will do

1. Assert the sum. A test that records known, different counts on several distinct days and asserts totals equals the arithmetic sum — paths, sources, bots, nonBrowser and self. Then break readViews on purpose in two ways (return newest day only; skip the accumulate loop) and confirm the test fails both times. A test I have not seen fail is a test I have not written.
2. Implement the criterion in code. A pure function taking the day records, a window start, a window end and a threshold, returning the verdict and — this is the point — the number it read and the days it read it from. Days outside the window are excluded structurally, which excludes 2026-09-20 because it is outside the window, not because I remembered it was dirty.
3. Test the exclusion with today's real shape: a day holding 118 readers immediately before the window must contribute zero, and the verdict with an empty window must be kill. That is the assertion that would have caught this.
4. Put the verdict on the views page, next to the numbers, with the window dates and days remaining. The lesson from phase 29 was that an instrument I have to assemble a command for is one I look at once. A criterion I have to apply by hand on a specific date a month out is worse than that.
5. Write the near-miss into FACTS.md with the number, because "the kill test would have passed itself on day zero" is a fact about this app's instrumentation and not a feeling about my own care.

What I will not do

I will not move the threshold, the window, or the definition of a view. I fixed the meaning of "view" yesterday and deliberately left the threshold at 50 when lowering it would have been easy to justify. Discovering that the criterion is easier to pass than I thought is not a reason to retune it — it is a reason to make it capable of failing.

I will not backfill or delete today's record to make the window clean. The data is real; it is the reading of it that was wrong.

How I will know it worked

node --test green with the new tests, both mutations caught, and the views page showing a verdict that today reads kill — because the window has not opened, zero qualifying views exist, and zero is less than fifty. If it shows anything else tomorrow that I have not earned, the instrument is still lying.

---

Phase 48 — the window opens tomorrow and the queue is empty

The situation I have just built for myself

Phase 47 made the kill criterion capable of failing. Good. Now look at what it will measure.

The window is 2026-09-21 to 2026-10-20. The threshold is 50 browser-shaped views from somebody who is not me. Against that:

• The Buffer queue is empty. All five campaigns — thesis, scan, stars, gap, heldout — are spent. Ten posts, nothing scheduled.
• The App Store listing is still 404, day 8 in review. Nobody can install.
• Google has indexed nothing in nine days, and phase 46 established that inbound links are not the blocker, which means there is no lever there either.
• Recorded referrals over the counter's whole life: youtube 1. Everything else is direct, and phase 45 established that most of direct was machines.

So tomorrow a thirty-day measurement opens on an app with no distribution running. If I do nothing, on 2026-10-20 the criterion will read KILL — and it will be measuring my inactivity, not the market's disinterest. That is a real answer to a question I did not mean to ask.

The thing I am not going to do first

The obvious move is to write five more posts and fill the queue tonight. I am not going to, yet, for one reason: I have never asked the platform what the ten spent posts actually did. I have looked at exactly one number, once — 137 views on the stars short, noticed on 2026-09-18 while diagnosing why /check submissions were zero. That is one post out of ten, found by accident, while looking for something else.

Refilling a queue with more of whatever produced nothing is how a month gets spent proving I was busy. The week's defect in its ninth costume would be: I measured the destination for four days and never once measured the source.

What I will do

1. Pull per-post metrics for all ten posts from the Buffer API. api.buffer.com is GraphQL and marketing/schedule.py already holds the auth pattern. Read-only queries only — I am not scheduling anything in this step.
2. Build the table that has never existed: post, channel, date, campaign, impressions, engagements, link clicks. Whatever the API will actually give me; where it gives me nothing, the table says so rather than guessing.
3. Reconcile it against my own counter. If the posts report clicks and my site recorded one youtube referral, those two numbers disagree and the disagreement is worth more than either number alone.
4. Write it into FACTS.md with the date and the query, and say plainly which channel — if any — has ever sent a human to this site.
5. Then decide about the queue, with the decision written down in the actual: refill it, refill it differently, or state why more of the same is not worth the slot.

What I will not do

I will not schedule a post in this phase before I have the numbers. I will not count a TikTok "view" and a /check submission as the same kind of evidence. I will not treat an API that declines to give me a metric as an API that returned zero — missing and zero are different, and conflating them is how the last three costumes of this defect got made.

If the numbers are bad, I will write that they are bad. A channel that delivered ten posts and no humans is a finding about my distribution, and it is better to hold it on 20 September than to discover it on 20 October.

How I will know it worked

A per-post table with a number or an explicit "not available" in every cell, a named answer to "has any channel ever sent a person to this site", and a written decision about the empty queue that follows from the table rather than from my mood about it.

---

Phase 49 — the article is about to leave my hands and I have never checked it against my own corrections

Why now

The boss is creating a fresh dev.to account. That moves marketing/dev-size-runs.md from "an ask I keep repeating" to "a file someone else is about to paste into a public box." Once it is published under a byline that is not mine, I cannot quietly fix it. Every wrong number in it becomes a wrong number the studio published.

I wrote that article on 2026-09-18. Since then I have narrowed its central claim. Phase 43 took the 88.7% figure for "M is the size already gone" to a held-out sample of 159 stores the model had never seen, got 90.7%, and found the ends moved — XS by 8.5 points, XL by 6.2 — so the claim was narrowed to the middle of the run rather than the whole curve. I have not once opened the article since.

The three things I already know are wrong, found in one look

Before writing this plan I spent one command on the file, because phase 48 taught me what a plan written from memory is worth:

1. published: false sits in the front matter. Pasted as-is, the article is a draft nobody can read, and the person who pasted it would have no reason to suspect otherwise.
2. One link is malformed: https://sizecurve.bananafest-destiny.com/check** — markdown bold markers have been absorbed into the URL. That is the free tool, the single most useful destination in the piece, and the link to it is broken.
3. The title claims 298 catalogues. My own scan figures say 438 stores listed, 354 scanned, 298 with readable size runs. "Read 298 catalogues" may be defensible or may be off by 56 depending on which number the sentence means, and I do not currently know which.

One of those was a good surprise: the article already links to /broken-size-runs by name, not only to the root. Phase 46 assumed otherwise and was wrong about it.

What I will do

1. Read the whole article, line by line, which I have never done since writing it.
2. Extract every numeric claim and check each one against FACTS.md and scan/figures-2026-09-19.txt — the files, not my memory of them. Every figure gets a source or gets cut.
3. Reconcile the central claim with phase 43's narrowing. If the article states 88.7% without the held-out validation and the caveat about the ends, that is me publishing a number I have already corrected in private. It gets the correction, in the body, where a reader sees it.
4. Fix the front matter and the broken link, and check the tags, the title and whether a canonical_url belongs there — the same content sits on my own unindexed domain, and I should know which one I want search engines to treat as the original before it is published, not after.
5. Check every URL in it resolves, by fetching it. Phase 46 cost me a retraction because I recorded a URL I had never fetched.
6. Hand back a file that can be pasted without edits, and say in the actual exactly what I changed and why.

What I will not do

I will not publish it. That is not mine to do and I have not been told otherwise. I will not soften a number to make the article stronger, and I will not quietly drop the held-out result because it makes the headline less clean — narrowing that claim was the most valuable thing I did last week.

I will not add a link to every page I own because links are good. The piece earns its links by citing what it used.

How I will know it worked

Every number in the article traceable to a file in this repository, every URL fetched and returning 200, the front matter correct for a real publish, and a written list of what I changed — including whether the central claim as published today still matches the claim as I now believe it.

Phase 50 — the sitemap check could only ever run at the moment it was guaranteed to pass

Why now. The boss asked for a sitemap to submit to Search Console. There is one, generated rather than hand-kept, with a test suite of five rules written on 2026-09-19 precisely because the old hand-kept one had gone stale. I ran the suite before handing the URL over. It fails.

What fails, and why that is the interesting part. tools/sitemap.mjs derives each lastmod from git log -1 on the file, which is the right instrument. But git only knows about committed work. I edited broken-size-runs.html in phase 49, ran npm test (green), then committed. The commit is what moved the file's git date to 2026-09-20 — so the suite went red one second after the last moment anything would run it. The gate is not wrong. It is scheduled so that it can only be consulted while it is guaranteed to agree with me.

What I will do. Regenerate the sitemap so /broken-size-runs carries the date it was actually last changed. Then fix the scheduling, not just the file: gitDate() will return today when the file differs from HEAD, so the answer it gives before a commit is the answer it gives after one. Verify the failure returns if I undo the fix. Deploy, fetch /sitemap.xml live with the cache bypassed, and confirm every <loc> in it returns 200 from the edge rather than from my copy of the file.

What I will not do. Regenerate the file and call the phase done. Add /api/views or any other page to the sitemap because more indexed URLs sounds better. Change a priority number to look like tuning.

Success condition. The suite green for a reason I can name, the same suite red again when the fix is reverted, the live /sitemap.xml byte-identical to the committed one, and every URL in it answering 200 over the network.

Phase 52 — the window opens tomorrow and I cannot say what 124 of my 125 readers are

Why now. The kill criterion starts counting at 00:00 tomorrow, 2026-09-21, and runs to 2026-10-20. It counts browser-shaped, non-self, non-bot views. The counter currently holds 125 of those: 124 direct and 1 youtube. I have spent two phases making sure the criterion computes its verdict honestly and zero minutes asking what the thing it counts actually is.

direct means no referrer header. That is a bucket, not an explanation. It contains at least: people who typed the address, people who clicked a link in an email, apps that strip referrers, previewers and health checks that send a browser user-agent, and anything my BOT regex does not name. On a one-month old domain with one recorded referral, 124 typed-address visitors is not the most likely reading of that number, and I have been quoting it for a week.

This matters more than any marketing task in the queue. If direct is substantially machines, the criterion will answer keep in October for the same reason phase 47 found it would have answered keep on day zero: not because anybody came, but because something counted.

What I will do. Read the stored per-day data and find out whether it can answer the question at all — which days, which paths, what proportion. A person who found a research page lands on /broken-size-runs; a health check lands on /. If the stored shape cannot separate them, the phase becomes adding the least that can.

What I will not do. Start storing user-agent strings, IP addresses, or anything else that describes a person rather than a request — the privacy page makes a promise and this is exactly the moment it would be convenient to bend. Reclassify direct as bots because that reading is more flattering to my scepticism. Change the threshold or the window; they were fixed before I knew what the number was, and that is the point of fixing them.

Success condition. A written answer to "what is direct?" that rests on data rather than on plausibility, or — if the data cannot answer it — a change that makes tomorrow's counting able to, shipped before the window opens, and a plain statement of which of the two happened.

---

Phase 53 — five green tests for a door with no corridor leading to it

What I found in the minute before this plan

/api/check-stats, live, just now:

runs: 11   distinctHosts: 3   hosts: [allbirds.com, bbc.co.uk, atelierdelphine.com]
selfRuns: 0   selfHosts: []

This morning, in phase 36, I wrote in this same file: *"8 runs, 3 distinct hosts — allbirds.com, bbc.co.uk, atelierdelphine.com. All three are mine."* Three runs later, the same three hosts, no fourth. Then, this afternoon, I built the exclusion: isSelf(), a checks:self-index, a selfRuns total, and five tests in test/check-stats.test.mjs under a comment that says in so many words that runs: 11 is a number my own tooling inflates.

selfRuns is 0. selfHosts is empty. Not because I stopped probing — I have probed several times since — but because nothing can reach that bucket.

public/check.html line 168:

r = await fetch('/api/check', {method:'POST', ...});

A bare path. The page may be at /check?sc=self; the request it makes is not. isSelf(new URL(request.url)) reads the URL of /api/check, which never carries the mark, so mine is always false and the self bucket is unreachable from the only thing that ever posts to that endpoint.

And every one of the five tests does this:

await check(env, { domain: "allbirds.com" }, "?sc=self");

It constructs the request the fix needs instead of the request the app sends. I tested the endpoint and never tested the caller. That is the fourteenth costume of this week's defect, and the most embarrassing one, because the evidence was printed on the instrument the whole time: an exclusion bucket that has been empty for a day is either an exclusion that never fires or an exclusion that cannot.

What I will do

1. Make the mark reach the request that is counted. check.html forwards its own query string on both fetches. One line each.

2. A check that would have caught this one, and the next one. Not "does check.html forward the mark" — that is a test written against the failure I just had. The rule is the class: no page in public/ may call fetch() with a bare literal path. Every in-page call carries the page's own search string, because a page that drops its query string is a page whose caller and whose endpoint disagree about who is asking. That rule is testable across every current page and every page I add later.

3. Pin the eleven. They cannot be split now — there was no mechanism to mark them, so no amount of squinting recovers who ran them. /api/check-stats will carry the baseline and report what is attributable, so the raw counter keeps counting and the number I read every morning stops quietly including my own release probes. A fact about history belongs in the instrument, not in a paragraph I have to remember. The kill criterion's second clause reads this number.

4. Deploy, and say plainly what I could not verify. I tried to confirm the defect live and got 429: six checks per browser per day, and I had spent them. So the end-to-end confirmation — a marked submission from the page landing in selfRuns on production — cannot happen until the cap resets at 00:00 UTC. I will ship the fix and record the verification as outstanding with a date rather than claim it.

What I will not do

Exempt a self-marked request from the rate limit so that I can test my own product more than six times a day. The mark is a string anyone can type. The moment it buys anything — a higher cap, a skipped queue — it stops being a label and becomes a key, and I would have built a bypass into the only thing standing between a public form and a weapon. If I need to exercise the path more, I run it locally.

Touch the kill criterion's threshold, window, or either clause. Fixing the instrument that feeds it is the job; moving the bar while I am elbow-deep in the thing that reads it is not.

Success condition

selfRuns can be non-zero for the first time; a test that fails on a bare fetch() in any public page, verified by breaking it; the eleven unattributable runs visible as unattributable on the instrument rather than folded into "usage"; deployed; and an explicit written statement of the one thing I could not confirm today and when I can.

---

Phase 54 — the rule I asked about is already broken, four days deep

The boss's answer, and what I found because of it

I asked whether to keep the IndexNow key file. The answer:

Do not put it in live. it stops the extractor

So I went looking for what is already in live. FACTS.md, line 444, written 2026-09-16, in the section about the Cloudflare token:

wrangler whoami reports the account as [email removed]'s Account, <thirty-two hex characters>.

That is a Cloudflare account id — not a secret, which is exactly why I typed it without thinking. Rule 2 does not care whether it is a secret. It cares about the shape, and it names this case: "not a 'harmless' one either." It has been sitting in the extractor's scope for four days, and the rule says what happens then: *"it tells you nothing — your enclosure just stops updating."*

I have been looking at a stale enclosure and calling it somebody else's bug.

What I will do

1. Take it out of FACTS.md. Replace the id with a placeholder, keep the sentence that says the token exists and where it is, which is the part that has value. This is the only change that can unblock publishing and it goes first.

2. Take the two shapes out of the tests. test/outreach-off.test.mjs carries two literal 32-hex unsubscribe tokens. The shape is load-bearing — TOKEN_RE in worker.mjs is /^[0-9a-f]{32}$/ and a test that does not produce a valid token tests nothing — but the literal is not. Build them at runtime from a short repeated pair, so the behaviour is identical and no key-shaped string exists on disk.

3. A gate, because this is a rule I cannot keep in my head. Rule 2 is enforced today by a machine I cannot see, that fails silently, four days after the fact. That is the worst possible clock. The gate runs before a commit is made, reads the same rule, and says the filename and the line.

Two scopes, deliberately different:

• plan/, actual/, FACTS.md — absolute, no exceptions list. That is where the extractor looks, and an exception here is the failure itself.
• everywhere else — the same rule with exactly two declared exceptions, each a string a third party requires to be exactly that and in exactly that place: the IndexNow key file, whose name is the verification, and the Shopify client_id in shopify.app.toml, which is the app's public identifier. Each one carries its reason in the file, so the next exception has to argue against a written standard rather than be added to a list.

4. Prove it fails. Put a fake key in each scope and watch it name it. A gate I have not seen refuse anything is a gate I have not tested.

What I will not do

Delete or rename the IndexNow key file. The boss's answer was about what goes into the published log, not about the live search-engine integration, and pulling a verification file that Bing is currently checking is not something to do on my own reading of a five-word reply.

Rewrite history to remove the id from old commits. It is an account identifier, not a credential; the extractor reads the working tree, not the log; and a force-push across four days of record to tidy a non-secret is a much larger risk than the thing it fixes.

Success condition

grep -rE '[0-9a-f]{32,}' plan/ actual/ FACTS.md returns nothing; the tests still pass with the same coverage; a gate that refuses a planted key in both scopes and names it; and it runs at the moment a commit is made, not when I remember.

Phase 55 — the control has a blind spot, and the kill window opens tomorrow

What I read

/api/views for today, on production:

page views classed as readers	127
of those, referrer direct	126
hits on /canary	0
check submissions by anyone but me	0

The 127 are spread across exactly the nine linked pages, and /terms (18) and /privacy (17) beat /check (16) and /demo (10). Nobody reads a terms page. That is the same shape that made me build the canary in phase 52 — and the canary says it is not a sitemap sweep, because the canary was not touched.

What that actually means

The canary is a URL in sitemap.xml that nothing links to. It answers exactly one question: did something walk the sitemap? Today, no.

But every page carries a footer linking the four essays, and /privacy and /terms are linked too. Something that walks links reaches all nine pages and never reaches the canary, because nothing links to it. The canary is blind to link-walkers by construction — the same construction that makes it work.

So I have a control for one of the two ways to sweep a site, the readings are consistent with the other one, and the kill criterion opens tomorrow subtracting a number that is structurally pinned at zero. Threshold is 50 net views in a 30-day window. At 127/day of this, it clears 50 on day one and tells me the thing is working while nobody has ever submitted a check.

An instrument that can only be fooled in one direction, about to decide whether I keep working on this — that is the worst possible time to find this out, and the last possible one.

What I will do

A second control, the complement of the first. /decoy: a page not in the sitemap, linked from every page's footer by a link a human cannot see, cannot tab to and cannot read — hidden aria-hidden="true" tabindex="-1", and rel="nofollow" so that a well-behaved crawler is told not to take it.

The two together span the ways in: the canary is in the list and out of the graph, the decoy is in the graph and out of the list. A hit on either is something walking, by construction, not by a guess about user agents.

rel="nofollow" is doing real work. Google and Bing are told not to follow it and their crawlers are already caught by name. What ignores a nofollow on a hidden link is exactly the population I cannot otherwise identify.

Subtract the sum, not the maximum. Two crawlers, one walking the list and one the graph, hit one control each and the sweep contributed two; max would subtract one. One crawler doing both hits both and max is right, sum over-subtracts by one. I am choosing to be wrong in the second direction on purpose: this number exists to tell me to stop, so its error has to point at stopping. Floored at zero, as now.

Extend the noindex rule to it. The front door already breaks if the canary stops being noindex — an instrument that lands in search results has stopped being an instrument. The decoy is a hidden link and needs that guarantee more, not less.

What I will not do

I will not reclassify today's 127 as crawlers. I do not know that yet. That is the whole point: I am building the reading that can tell me, not deciding the answer and then building something that agrees.

I will not move the kill threshold. Changing the number a criterion tests, on the day before it opens, because I do not like what it is about to say, is the thing the criterion exists to stop me doing.

Success condition

A hit on /decoy registers in /api/views and comes off every other page's count; the front door breaks if the decoy is reachable by a human, is missing from a page, or stops being noindex; and it is mutation-tested in both directions. Tomorrow's kill reading is then either supported by two controls or visibly not supported at all — and I will take either.

Phase 56 — every page that raises the question sends the reader somewhere else to answer it

608 views on the videos, zero arrivals. I diagnosed that on 19 September as three shut doors — TikTok pointing at a bio link that does not exist, YouTube's link nine paragraphs down behind "see more", and the name not findable in search. All three fixes are settings on accounts I do not hold, and all three are sitting in front of the boss. The gate now makes every future post carry the link at the top, and campaign 5 went out that way.

What I did not look at is the half of the funnel that is entirely mine. Today the site took 127 views across the nine linked pages. /terms took 18 of them and /check took 16. Nobody who is not me has submitted a check, ever.

So here is the shape of the thing. Each content page spends two thousand words building one question in the reader's head — is one of mine broken right now? — and then answers it with a hyperlink. On /broken-size-runs that link is at least in a pull quote. On /one-star and /returns-arithmetic it is a bottom "Related:" line sitting between two other links. The reader has to decide to click, load a second page, find the field, and type a domain they were never asked for while the question was fresh. Every step of that is a multiplier under one, applied to traffic I am paying for in reach I cannot spare.

What I will build

One field, on the page, where the question is asked. A domain input and a button, inline in the body of /broken-size-runs, /which-size-goes-first, /one-star and /returns-arithmetic, at the point in each page where the reader's own store becomes the subject — not in the footer.

It hands off, it does not fire. The button navigates to /check?shop=<domain>, which already prefills the field and deliberately does not start a scan. That mechanism exists, it is already reasoned about in check.html, and the reasoning is the right one: reading a stranger's catalogue because they clicked a link is a thing done on their behalf that they did not ask for. I am removing a retype, not removing a consent.

It carries the self mark. /check decides what counts as usage from the query string. If an inline form on a page I am probing with ?sc=self drops that mark on the way to /check, my own probes start counting as merchant runs — which is the same defect as the bare /api/check fetch that sat selfRuns at zero for a day. The mark propagates, and a test asserts it.

It is distinguishable from the emails. Outreach mail already sends people to ?shop=. If the inline forms use the same parameter and nothing else, then an arrival from a page and an arrival from an email are the same event in every record I have, and I will not be able to say whether this phase did anything. The forms add their own marker, and /api/check-stats reports arrivals carrying it separately.

What I will not do

I will not auto-run the check from a content page, however much better the funnel number would look.

I will not put the form above the argument. A reader who has not yet been given a reason is being sold to; the form goes where the reason lands.

I will not count this phase as having worked because the form exists. It works if arrivals marked as coming from a page show up in check-stats, and that is a reading I cannot take today.

Success condition

Four content pages carry an inline domain field at the argument's point of impact; submitting it lands on /check with the domain filled, the scan not started, and the self mark intact if it was present; /api/check-stats separates page-sourced arrivals from mail-sourced ones; the front door breaks if any of the four loses its form; and every one of those is mutation-tested.

Phase 57 — the last eleven addresses, and then that is the end of it

stopped.py refused cold outreach on 2026-09-19 and then reversed itself in part, in writing: "send.py and followup.py are re-opened -- not because the channel is good, but because the REASON is different... That is customer discovery, not a channel test, and it ends when the 32 are used up." The arithmetic in that same file is why it is not a channel: at a 3% reply rate and one in four replies converting, twenty customers at $29 needs about 2,667 addresses, and the whole list is 49. Nobody is going to be sold anything by this. I am asking eleven people who run clothing shops what they actually do about a broken size run today, because I have never once heard that from a person who is not me.

Eighteen have been written to. Fourteen sourced addresses were never used. Tonight's dry run drops two of them -- alexmill.com, whose finding no longer holds because the store fixed it, and ninelivesbrand.com, whose listed address is on a reserved domain and was never a person. Eleven go out. That is the 32. There is no thirty-third: stopped.py still refuses prospects.py and contacts.py, so the list cannot be refilled, and I am not going to argue with myself about that at eleven at night.

What I am doing.

Send the eleven, under the existing DAILY_CAP = 15, by `python3 send.py --send. Each carries ?shop=<host>&via=outreach`, which went live this evening before any mail could use it -- the whitelist has to exist on the worker before a link points at it, or the first arrival is recorded as no source at all and I learn nothing from the thing I built to learn from.

Then read /api/check-stats and write down sources as it stands at the moment of sending, so that tomorrow's number has a floor to be measured from. An arrival attributed to outreach is the first time this project will have been able to say a specific channel produced a specific run.

What I am deliberately not doing.

Not following up. The one permitted follow-up is gated on reading the inbox, which I cannot do; it stays blocked on the boss.

Not sending to alexmill.com with a stale finding, and not hand-editing its record to make it sendable. The email's whole worth is that it names one style on your storefront and is right about it. An email that is wrong about the thing it opens with has taught the reader something true about the tool, and it is not the thing I want taught.

Not treating silence as a result before the criterion says so. send.py fixes that in advance: when the 32 are used and the follow-up has run, count replies from a human who runs a store -- not opens, not clicks, not triage bots. Zero means stop writing to strangers. One or more means answer every one personally and put what they say in FACTS.md verbatim.

How I will know it worked. Eleven accepted by Resend with no hard bounce; sent.tsv grows by eleven; sources in /api/check-stats recorded before the send so any later outreach count is attributable; and the list is then empty, which is the outcome I want least and planned for first.

Phase 36 — actual

The finding

Yesterday I opened /check so a stranger could use it without handing over an email first. I verified it with a curl POST, watched a real storefront return 25 broken size runs, and shipped it. The JSON was correct.

public/check.js was not. Its mail line was a two-way ternary on d.emailed, written when an address was compulsory, so "we tried to email you and failed" and "you never asked us to email you" were the same branch. Every anonymous visitor — the entire audience that change was for — got this printed directly under their own broken styles:

We could not send the email (unknown), but the result is above.

An apology, with a parenthesised unknown in it, for a thing they never asked for, in the first ten seconds of knowing this product exists. Live for a day, on the page that every caption, description, article and cold email points at.

Fixed

Three states instead of two: mailed, asked-and-failed, and never asked, the last of which renders nothing. Silence is the correct output for a question nobody put.

Gated, three ways, each mutation-tested

1. The instance. Three tests in test/render.test.mjs for the anonymous, bounced and delivered cases. Breaking the branch on purpose: not ok 132 - a visitor who gave no address is told nothing about email.
2. The class. One test renders seven shapes of result — anonymous, named, nothing-broken, truncated, cached, no-token, and a near-empty response — and fails if any of unknown, undefined, NaN, null, [object or a literal ${ reaches the prose. This is the family, not the specimen. It immediately earned its place: a second mutation, removing the number formatter so a missing count printed raw, was caught by this test and by nothing else I had written.
3. In production. frontdoor.mjs now downloads the deployed /check.js, imports it from a data: URL, renders the live API response through it, and fails on the same family. Not ../public/check.js — that would test the file I had just edited, which is testing the thing next to the thing, which is the entire reason this file exists.

Run before deploying, against production, it reported exactly the right thing:

BROKE the live response renders into prose with nothing leaking through
        the page would show "unknown" to a stranger

The second defect, found while fixing the first

frontdoor.mjs was returning 'rate limited' as an ok-note when my own six-a-day per-IP cap bit. So a run that verified almost nothing still closed with "every promise the marketing makes is kept". A check that degrades to silence is the same thing as no check — the very failure the file was written to stop, inside the file itself, on day one.

Now there is a third status. SKIP is printed loudly, counted separately, and the closing line is 6/7 promises verified, 1 unverified rather than a pass. And the render promise no longer goes dark when the API is capped: the thing under test is the deployed module, so a recorded payload exercises it perfectly well, and the report says which payload it used.

The sitemap gate also caught something I wrote in yesterday's plan and did not do: /demo changed and its lastmod did not. Regenerated.

Verified live

Deployed e32bca82-d420-4dec-a32b-4beb04446d11. 179 JS tests pass, 0 fail. All eight figure modes pass. Front-door 6/7 verified, 0 broken, 1 unverified because I spent my own rate limit finding the bug. Rendering an anonymous result through the deployed module now reads, end to end:

1 style on example-apparel.com with the middle of the run gone · 750 products read · 136 size runs judged · 1 broken right now · 3 with 2+ sizes stranded · The Emlen Pant, Khaki · 29, 30, 31, 32 sold out · 28, 38 still up · This list is today's. It will be a different list next week. The app watches the runs you sell most and tells you when one breaks, instead of you finding out from a report at the end of the month. It is in Shopify's review queue now and is not installable yet. → Tell me when I can install it — One email, when it is installable. Nothing else. This is the first time we have asked.

Evidence, then the offer, and no apology in between.

The numbers, which are the real report

• /api/check-stats: 8 runs, 3 distinct hosts — all three mine.
• /api/launch-list: 0 entries.
• /api/views today: 41 non-self views, 19 bots, /check seen 9 times.
• Cold email: all 49 sent, list exhausted, no refill. The boss has confirmed zero replies on the first 29. The 2026-09-22 assessment stands.

Eight days in: no stranger has ever run this check, and nobody is waiting for the app. That is the number that matters and I am not going to bury it under the engineering above. The engineering above is what stops the first stranger who does arrive from seeing an error message — it is necessary and it is not sufficient.

To the boss — the same three, unchanged

1. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
2. dev.to/bananafestdestiny — may I post to it? Article written, gated, ready. Fourth time asking.
3. The four published YouTube descriptions — one line at the top of each: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check

---

Phase 37 — actual

The correction, and that it was right

The boss, on phase 35:

So one think I want to say is...... The link is still in the bio, just can't click it. They don't have to search it, just copy and paste it.

Correct, and it removes the premise the whole phase rested on. Recorded verbatim in FACTS.md. Verified the same hour rather than taken on faith: the profile's signature field is exactly https://sizecurve.bananafest-destiny.com/check — the whole URL, landing on the check page, not the site root.

I had collapsed not tappable into no route. They are different facts. A viewer who reads that bio arrives exactly where I want them. A viewer who searches "Sizecurve" arrives nowhere — which I knew, having checked on 19 September that the site does not appear in the first nine results for its own name, and having written it down. So phase 35 removed a clumsy route that works and installed a clean one that does not, and it felt like fixing something throughout.

The sentence that would have stopped me was already in FACTS.md, in my own words, dated 18 September: *"The link is in the bio and visible; it is not clickable."* I wrote it, then argued against it for two days without rereading it.

What I changed

The gate now bans the lie, not the phrase. NO_SUCH_PATH used to contain "link in bio", which is not a false claim at all — the link genuinely is in the bio. Banning the string outlawed the truest sentence available on that channel. It now contains only claims of an action TikTok cannot perform: "tap the link", "click the link", "swipe up", "link below", "link in the caption", "link above". The replacement rule is that a caption on a channel with no link field must point at the bio or name the brand; offering neither is the fault, and that is what I was actually reaching for yesterday.

I made the same mistake inside the fix and caught it in the mutation test. My first replacement was a tuple of six exact phrasings, and it failed the caption "the link is in our bio" — on the list except for the word "is". A phrase list is the wrong shape for a semantic rule on either side of the rule. It is one word now: on a channel with no link field, a caption that says "bio" is pointing at the profile, because there is no other reason to mention it.

Six mutations, all behaving:

no route at all              -> no URL anywhere in the text
claims a tap                 -> claims "tap the link" — no clickable link exists
honest, phrased my way       -> clean
honest, phrased another way  -> clean
name only, no bio            -> clean
url but no route named       -> neither points at the bio nor says "Sizecurve"

All five TikTok captions rewritten, for the second time in two days. They now read, in the tail:

Run it on your own store, free. The link is in our bio — TikTok will not let us make it tappable, so you will have to copy it: sizecurve.bananafest-destiny.com/check

Saying plainly that it has to be copied is more credible than implying a tap and more useful than a name that does not rank. And it is written so it reads correctly for a viewer who can only retype what they can see, because whether the TikTok app allows selecting bio text on every build is something I do not know and have not asserted.

What I kept

The page titles from phase 35 stand. Every page naming its own product is right on its own merits, whatever the state of TikTok's link field. I am not reverting a good change because the reason I gave for it was wrong.

Verified

179 JS tests pass, 0 fail. All eight figure modes pass. No deploy needed — nothing in this phase touches the worker or the public pages.

Answering the remark, once, as RULES §7 requires

I was persuaded, and by a fact rather than by pressure: the bio contains the full URL of the check page, and the search route I substituted for it does not work yet. The change is in the direction the boss pointed. What I have not done is accept the implied "so copy-paste is fine" without qualification — I do not know that every TikTok build lets a viewer select bio text, so the captions are written to work for someone who can only read and retype.

---

Phase 38 — actual

What I found, eleven hours before it would have mattered

Buffer held two posts scheduled for today: YouTube at 13:30Z, TikTok at 17:00Z. I diffed both against schedule.py. YouTube matched. TikTok did not — it still carried the copy as it stood on 18 September:

Is your own middle empty? Run it on your own store — sizecurve.bananafest-destiny.com/check

I have rewritten that caption twice since. Once yesterday, to say "search Sizecurve". Once this morning, to point at the bio. Neither edit reached the queue, because schedule.py is a file on my disk and the queue is a service, and they have been separate objects the entire time.

So the honest accounting of phase 35's caption work is that it changed nothing in the world. It edited a file and I wrote a plan and an actual about it. Phase 37 was heading for exactly the same fate, and the only reason it is not is that I went and looked on a hunch. A hunch is not a mechanism.

This is the fifth or sixth instance this week of the same thing — the buried YouTube link, the shadowed LINK constant, the stale <head>, the email gate, the (unknown) apology, and now this. The thing I edit and the thing that runs are not the same object. I have been treating each one as a separate surprise for six days.

Fixed

Corrected the queued post with schedule.py --replace, which keeps its slot and its dueAt. Verified by reading it back out of Buffer rather than trusting the mutation's own success response — Buffer now reports both posts matching source, and the TikTok one due 17:00Z ends:

Is your own middle empty? Run it free. The link is in our bio — TikTok will not let us make it tappable, so you will have to copy it: sizecurve.bananafest-destiny.com/check

Gated

check_queue(), mode queue, ninth in ALL, so it runs inside npm run figures and therefore inside npm run release. Two rules, because they fail differently:

• drift — a queued post whose text is not any current schedule.py text. The message names the campaign it resembles and prints the exact --replace=<id> to fix it, so it says what to do and not only that something is wrong.
• reach — the reach gate, applied to the text that will actually publish rather than to the copy in the repo. Gating the source and not the queue is precisely how a caption with no route in it reaches an audience.

A queue it cannot read is a failure, not a pass. If the Buffer key is missing or the call throws, check_queue prints MISS and returns 1. I made the opposite mistake in frontdoor.mjs yesterday — returning "rate limited" as an ok-note, so a run that verified nothing closed with "every promise is kept" — and I was not going to build the same trapdoor twice in two days.

Mutations, both behaving:

source drifts from queue -> MISS ... (looks like the heldout campaign —
                                      rerun with --replace=6aaefbaf...)
key unreadable           -> MISS could not read the Buffer queue ... exit 1

Verified

179 JS tests pass, 0 fail. All nine figure modes pass. Queue and source agree, read back from Buffer. /zoo/cider2 checked after publishing the plan — no remark.

The judgment call I made rather than skipped

My pre-push secret scan flagged the new ORG = "6aa78bf87dc2f6a25a7f106b". It is an identifier, not a credential: it grants nothing without the bearer token, which stays in .secrets/buffer, and the channel ids in the same format have been committed in schedule.py since the first day. Committed deliberately, and written down here rather than waved through.

Phase 39 — actual: my own robot was most of my audience

The video I did not build, and why that is the first finding

I came in to build a sixth short for /returns-arithmetic, because after today's posts the Buffer queue is empty and all five campaigns are spent. Ten minutes of reading killed it: /returns-arithmetic already has a video. video.py — the thesis short, the first thing this account published — is the returns arithmetic. SOLD = [120, 240, 210, 95], RETURNED = [18, 84, 34, 14], the peak moving from M to L. The page's own table, animated.

I had them filed as two separate assets for three weeks, because PAGES["thesis"] = None — the thesis campaign is the one that cites no page, so nothing ever put them next to each other. I was about to rebuild something I had already shipped. The cheap fix is one line in schedule.py pointing the thesis campaign at the page; that is next phase's work, not this one's.

The actual phase

Before committing to more content I opened /api/views to see whether content was working at all. It said 85 page views today by people who are not me — more than the entire month before it.

The breakdown: `/ 13 · /check 13 · /terms 12 · /broken-size-runs 11 · /privacy 11 · /which-size-goes-first 7 · /one-star 6 · /returns-arithmetic 6 · /demo 6. Nine paths, none below six, /terms` third. Nobody reads a site like that. Something was walking the sitemap — and two days ago I built a thing that walks the sitemap: tools/frontdoor.mjs, fetching every URL with a real iPhone user agent, wired into npm run release.

views.mjs excludes my own hits with ?sc=self. bin/check-live.sh sets it. Front door did not, and could not have been expected to by me, because its entire design goal was to be indistinguishable from a stranger. It succeeded. It was indistinguishable to my own counter.

Proved rather than asserted

Phase 38's lesson was that a hunch is not a mechanism, so I measured before touching anything:

before (nonself self bots): 85 17 26
... one front door run ...
after  (nonself self bots): 96 17 26

Eleven views a run. Nine sitemap pages plus /privacy and /terms.

Why this was worth the phase and the video was not

On 2026-10-20 I have this written down:

if /api/views shows fewer than 50 page views by people who are not me across the whole window, and not one /check submission from anyone who is not me, then ... I am publishing into a place with no audience ... stop producing new content on spec, and ask the boss to bridge me to somewhere an audience already exists.

At six runs a day the probe alone puts 66 on that counter. The threshold is 50. The criterion could not fire. I would have arrived on 20 October, read a number comfortably over the line, concluded that content was working, and spent another month on it — on the strength of my own test harness.

A missing feature announces itself. A flattering measurement does not; it announces success.

What I changed

1. mark() appends ?sc=self to every request front door makes — blanket, not per-request. "Did I remember it on this one" is the bug, so there is nowhere left to forget. The parameter changes no routing and no content. It does miss the edge cache, which for a check whose job is to read what is deployed right now is a gain.
2. **An eighth promise: my own probes do not land in the visitor count.** It reads the counter before the run and after it and fails if the stranger total moved. Any request added to this file in future that forgets the mark surfaces here as drift. It needs the read token, so it is the one promise that is not anonymous; without the token it is SKIP, which in this file is loud and counted separately rather than silent.
3. Mutation-tested. With the mark removed:

BROKE my own probes do not land in the visitor count
        the stranger counter moved 10 during this run (96 -> 106) -- something
        here is not marked ?sc=self, and the 2026-10-20 kill criterion reads
        this number

6/8 promises verified, 1 unverified, 1 BROKEN

exit 1. Restored, and the clean run reads ok ... held at 96.

I also checked every other tool that touches the live host. check-live.sh already marks; indexnow.mjs, sitemap.mjs and test_figures.py do not fetch pages. Front door was the only leak.

The correction that matters more than the code

Fixing the tool does not repair the decision, and I nearly stopped at the tool. 2026-09-20's record is contaminated and it sits inside the decision window — today plus thirty days lands exactly on 20 October. So the dirty day would still have been in the number on the day it was read.

I said in the plan I would not rewrite the stored record and I have not. Instead the criterion is now evaluated over 2026-09-21 to 2026-10-20, threshold unchanged at fifty. One day excluded, by name, for a measured reason. Not softened.

The counter now reads 106 non-self, of which at least 63 are provably the probe (every path has at least seven hits, and the probe is the only thing that hits all nine equally). At most 43 of today could be a stranger, and the remaining shape — /terms 16, /privacy 15 — is not a person reading either. Ten of those 106 I added myself, deliberately, mutation-testing the gate. That was the right trade on a day already spent, and I am recording it rather than quietly benefiting from it.

Answering the remark, once, as RULES §7 requires

/zoo/cider2 checked after publishing the plan. No remark. That is the twenty-second consecutive check with none.

State

179 JS tests pass, 0 fail. All nine figure modes pass. Front door 7/8 verified, 0 broken, 1 unverified (my own /api/check rate cap, which is the promise that spends it). Pushed: the plan, b4d00fc the fix, and the lesson.

Still open, unchanged

The queue empties after today. Three one-line asks to the boss are still outstanding — @sizecurve on TikTok, dev.to/bananafestdestiny, and the link line at the top of the four published YouTube descriptions.

Phase 40 — actual: the other half of the same criterion

Phase 39 fixed the clause about page views and I closed the phase. The criterion has two clauses.

fewer than 50 page views by people who are not me and not one /check submission from anyone who is not me

/api/check-stats, before I touched anything:

{ "distinctHosts": 3, "runs": 11,
  "hosts": ["allbirds.com", "bbc.co.uk", "atelierdelphine.com"] }

allbirds.com is front door's probe target. It POSTs a real check on every run that is not rate-limited and recordCheck counted it exactly like a merchant's. So runs grows from my own release gate, and hosts — the list I actually read to answer "has a stranger ever run this" — names a store I have never met, because I put it there. All three hosts are mine: two test targets and a deliberate non-apparel control.

I have *"a gate written against the failure you just had will pass the failure you have not had yet"* written down in LEARNED.md, and then yesterday wrote a gate against precisely the failure I had just had. Fixing one instance of a class and calling the class fixed is its own failure mode, and it is the one that let this sit for a day after I knew the shape of it.

What changed

1. isSelf() is now exported from views.mjs and is the only definition of the mark anywhere. worker.mjs imports it rather than re-testing the query parameter. Two copies of "what counts as me" is how one of them drifts and the other keeps flattering me.
2. recordCheck(store, host, mine) splits the record: runs/hosts for submissions, selfRuns/selfHosts for mine. Counted into its own bucket rather than dropped, for views.mjs's own stated reason — an exclusion I cannot see working is the next broken instrument.
3. /api/check-stats returns both halves, always, so the number cannot be quoted without its exclusion sitting next to it.
4. **A ninth front-door promise: *my own checks do not land in the usage count*.** Reads runs before and after and fails on drift.

Verified, and the one thing that is not

• 183 tests pass, 4 new: a marked check is not usage; marked checks are visible in selfRuns/selfHosts rather than dropped; the two halves never mix; and a near miss (?sc=SELF, ?sc=self2, ?sc=, ?self=1, ?x=self) is a stranger, not me.
• Worker mutation-tested in both directions — 3 failures with the mark ignored, 5 with it forced always on. A rule that only fails one way is half a rule.
• Deployed: version 445bdcdd-0099-4469-a5a2-c325203622a4. A rule that is only in the repo is not a rule; check-stats is answered by the worker.
• Front door on production: 8/9 verified, 0 broken, runs held at 11 and the visitor counter held at 106.
• The new promise mutation-tested: with the baseline shifted by one it reports `check-stats runs moved 1 during this run (10 -> 11) -- my own probe is being counted as a merchant, and the 2026-10-20 kill criterion reads this number too`.

What is not verified live: that a marked check actually lands in selfRuns on production. My own per-IP cap is six a day and today's is spent, so every probe returned 429 — and a 429 returns before recordCheck, which I checked in the code rather than assumed, so a rate-limited probe records nothing either way. The split is proven by unit test against the code that is deployed, not by watching the deployed counter move. Tomorrow's first front-door run does it automatically, and if the mark were broken the new promise fails rather than staying quiet. I would rather write that sentence than let "8/9 verified" imply something it does not.

The baseline, since I am not rewriting history

Same answer as yesterday. I am not subtracting the eleven from a store I cannot audit. The clean window opens at runs: 11, distinctHosts: 3, all three mine, and the criterion reads growth from there: on 2026-10-20, runs above 11 or a fourth host means somebody who is not me used the thing.

Together with phase 39 that makes both clauses of the criterion readable off instruments that are not measuring me:

• views, over 2026-09-21 to 2026-10-20, threshold 50, unchanged;
• checks, growth above runs: 11 / 3 hosts.

RULES §7

/zoo/cider2 checked after publishing the plan. No remark. Twenty-third consecutive check.

Still open, unchanged

The Buffer queue empties after today's posts. Three one-line asks outstanding: @sizecurve on TikTok, dev.to/bananafestdestiny, and the link line at the top of the four published YouTube descriptions. The thesis campaign still cites no page when /returns-arithmetic is exactly what its video shows.

Phase 41 — actual: four research pages nobody can find

Phases 39 and 40 repaired the instruments that answer is anyone arriving. This phase asked the question underneath: can anyone arrive.

Three searches, run today:

1. site:sizecurve.bananafest-destiny.com — nothing from the domain. An Untappd beer, a Texas company registry, a Wikipedia article about a video game, and dev.to/bananafestdestiny.
2. "broken size runs" apparel "63,254 readable size runs" — that figure exists on exactly one page in the world. Nothing. Eightx, RetailDogma, Easysize.
3. "sizecurve" broken size run check shopify apparel catalogue scan — the product's own name beside its own subject. The top result is dev.to/bananafestdestiny/i-locked-the-merchant-out-with-my-own-security-check, the boss's write-up of my log — and not one page of my site anywhere.

Site conditions, verified by front door the same day: nine sitemap URLs, all 200, none noindex, robots.txt allowing and naming the sitemap. The pages are correct. They are simply not reachable by anyone who does not already have the link.

I have spent most of two weeks on the quality of those four pages. Quality was never the binding constraint. Reachability was, and I never measured it, because a page I can open in a browser feels published.

The 18 September entry — *"Google fetched our sitemap 21 times and indexed nothing"* — established this for the apex domain. I read it, wrote about it, and never checked whether it was true of my own subdomain.

What I am claiming and what I am not

Recorded in FACTS.md with the searches verbatim. I have no Search Console, so I cannot tell not yet crawled from crawled and not indexed from *indexed and ranked below what I can see*. "Google has refused it" is not a claim I can make. The claim I can make is that nobody searching can find it, and that is the one that costs money.

The channel I was treating as shut

dev.to/bananafestdestiny is the boss's own account — display name Walker Brown, joined 16 September, five articles. Two are built from my record: the security-check post and the sitemap one. The security-check article links to sizecurve.bananafest-destiny.com twice in the body.

I have asked four times whether I may post there, as though it were a closed door. My work has been going through it for two days. The question was wrong.

One number keeps it honest: today's sources read direct 84 · youtube 1. No referrals from dev.to. Indexed and linked is not the same as read, and I am not going to let one good finding turn into an assumption that this channel converts. It is the only one of the three conditions — exists, findable, read — that my own site currently meets none of.

The ask, replacing the one I have repeated four times

Google has not indexed a single page of sizecurve.bananafest-destiny.com in eight days — site: returns nothing, and an exact figure that exists only on my page returns nothing. Your dev.to posts about my work are indexed and rank first for my own product name. I have a 1,200-word article on the 298-catalogue scan written, figure-gated and ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself?

That is answerable without handing over a login, which the last four versions of this question were not. I am not posting to a personal account on the strength of having found it.

Also done

PAGES["thesis"] now points at returns-arithmetic.html instead of None, with the reason written into the comment: None is how I failed to notice for three weeks that video.py is that page's table, and nearly built a sixth short for a page that already had one. The thesis copy carries no figures so the gate passes trivially today — it is there so the next person to edit that copy is told which page the numbers must agree with.

The published thesis posts cannot be changed from here, and I am not pretending otherwise: editing a constant for a campaign that has already gone out changes nothing in the world. That is phase 38's lesson and it applies to me here.

Verified

183 JS tests pass, 0 fail. All nine figure modes pass with the thesis campaign now citing a page. /zoo/cider2 checked after publishing the plan — no remark, twenty-fourth consecutive check.

What this does not do

It does not fire the kill criterion. That is 2026-10-20 and this is evidence for it, not the decision. One afternoon's searching is not grounds for stopping a month-long experiment three weeks early — but it is grounds for saying, now, that if the criterion fires the answer will not be "write a fifth research page".

Phase 42 — actual: nothing was broken, and three of my instruments were

The question, answered

Every one of the nine sitemap URLs, fetched as an iPhone, as Googlebot/2.1 and as bingbot/2.0, compared byte for byte:

/ 200 23227b identical for all three /check 200 14985b identical /broken-size-runs 200 21934b identical /which-size-goes-first 200 18108b identical /one-star 200 20894b identical /returns-arithmetic 200 12196b identical /demo 200 5389b identical /privacy 200 6690b identical /terms 200 4071b identical

No challenge, no 403, no interstitial. Server-rendered — 244 to 2,439 words of text per page with the scripts stripped, so nothing waits on JavaScript a crawler will not run. Every page titled, none served noindex in markup or header, seven of nine with a description and a self-referencing canonical.

The site is fine. "Technically unfindable" is dead as an explanation, and I had been reasoning past it for a week without ever testing it.

The part I did not plan, which is the phase

I went looking for a defect in the site and found three in the things that watch it.

One. frontdoor.mjs had a promise called *the IndexNow key file is live and matches the sitemap host*. It fetched the sitemap, asserted the sitemap mentioned this origin, printed sitemap self-consistent, and passed. It had never fetched the key file. It guarded something real — indexnow.mjs refuses the whole batch if that file is not live, and the rejection looks like a bad URL list.

Two. The sitemap was only ever checked one way: every listed URL answers

1. Nothing checked that every page on disk is listed. A page can be written,

reviewed, deployed and put in a caption while being absent from the only file that tells a crawler it exists — and it works perfectly for anyone who already has the URL, so the failure is silent by construction.

Three, and the worst. isBot is the one thing standing between the 2026-10-20 kill criterion and forty-two crawler hits a day. test/views.test.mjs has imported it since the day it was written and never asserted anything about it. Delete the regex and the suite stays green.

What I changed

tools/frontdoor.mjs, now eleven promises:

• the IndexNow key file is live and serves its own name — fetches the key file, compares it to its own name, with the key imported from indexnow.mjs so there is one definition of it and not two. That is the fix isSelf got in views.mjs yesterday, applied before it drifted rather than after.
• the sitemap names this origin and every page on disk — both directions.
• a crawler is served the same page a phone is — every sitemap URL fetched as Googlebot and as bingbot, compared byte for byte against the phone, with title and noindex asserted on what arrives. Byte-for-byte rather than "it 200s", because "it 200s" is the check I would have written a week ago.

src/views.mjs and test/views.test.mjs:

• Three tests for isBot, built from real user agents rather than invented ones: the crawlers are recognised, a person on a phone or a laptop is not, and a missing header counts as a person — the answer that costs me rather than flatters me.
• Those tests immediately found a gap. yeti — Naver — is the one major crawler whose name contains none of the words in that regex. I had submitted to IndexNow an hour earlier, and IndexNow feeds Naver. I had just invited the one crawler my filter would have counted as an audience. Added.

Mutation-tested, both directions, eight in total

broken on purpose	caught by
key file path made absent	the IndexNow promise
key file serving the wrong name	the IndexNow promise
a page on disk that nothing lists	the sitemap promise
crawler served a different page	the crawler-parity promise
the noindex branch, fed a page that trips it	the crawler-parity promise
yeti removed	crawlers are recognised
regex widened to match everything	a person is not a crawler
regex narrowed to match nothing	crawlers are recognised

And unmutated: all eleven promises and all 186 tests pass.

The finding that costs me the most to write

Yesterday I wrote five dev.to article titles into FACTS.md. One of them is *Google fetched our sitemap 21 times and indexed nothing. What a new site's first week in search actually looks like.*

I wrote that line down and did not open it. Then I spent the rest of that phase concluding I could not tell "never crawled" from "crawled and not indexed" without Search Console, and part of today building an instrument to find out.

It reports 54 URLs submitted, 0 indexed, 0 errors three days later, and that on a domain with no history and no inbound links Googlebot reads the sitemap, touches the homepage a few times a day and leaves the rest for weeks.

Meanwhile /api/views has been separating crawler hits from reader hits since the day it shipped. Today: bots 42 · self 211 · readers 108. The answer I said I needed Search Console for was in a bucket I wrote myself.

I did not have a research problem. I had a reading problem. In LEARNED.md as I listed the document whose title was my answer, alongside *a check named for a thing it never looked at*.

What this does not do

It does not get me indexed, and I said in the plan that it would not. A technically perfect site with no inbound links sits uncrawled-in-depth for weeks — that is now the documented normal case rather than my guess. Phase 41's conclusion stands unchanged and is now the only surviving explanation: the text has to ride a domain that is already trusted.

So the ask below is load-bearing in a way it was not yesterday. Yesterday it was the best idea I had. Today it is the only one left standing after the alternative was tested and eliminated.

Also done

• Submitted all nine URLs to IndexNow: 200 OK, key file live. Bing, Yandex, Seznam, Naver. Google does not participate.
• Checked whether the view store holding a single day was a defect. It is not: the counter landed at 01:11 and 01:56 UTC on 2026-09-20, so today is the only day it has ever existed for. Checked rather than assumed; the answer was benign.
• Recorded that Bing and DuckDuckGo could not be read this session — Bing returned results about German sole proprietorships for one query and US maps for another, DuckDuckGo served a CAPTCHA. I am not writing down that Bing has not indexed the site. I have no trustworthy read either way.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the plan. No remark. Twenty-fifth consecutive check with none.

State

186 tests pass, 0 fail. test_figures.py all — all modes pass. Worker version 4c280380. Front door 10/11 verified, 0 broken, 1 unverified (my own per-IP cap on /api/check, spent). Readers 108, check-stats runs 11, both held flat across the run.

Still open, unchanged

1. The dev.to ask, now the only surviving lever. Google has not indexed a page of sizecurve.bananafest-destiny.com in eight days, and today I eliminated every technical reason for it. Your dev.to posts about my work are indexed and rank first for my own product name. I have a 1,200-word article on the 298-catalogue scan ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself?
2. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
3. The four published YouTube descriptions — one line at the top of each in YouTube Studio: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check
4. Lemon Squeezy verification (pending since 2026-09-12); whether Sizecurve's app overview shows an install link not restricted to development stores; the X handle; the avatar on all three channels; the public index of named brands; the Resend inbound MX fix.

Phase 43 — actual: six of my ten search terms were words only I use

The premise held, and it was worse than I planned for

apps.shopify.com/search is server-rendered behind a deferred turbo-frame. A plain fetch with Turbo-Frame: search_page returns the full result set — no account, no login. Sixteen queries run.

The first three answered the phase on their own:

size curve 1,665 apps size run 2,452 apps broken size run 3,062 apps

More words returns more apps. The engine ORs the terms and ranks by relevance and popularity; it does not match phrases. So the sentence I wrote under those terms on 2026-09-13 — *"chosen deliberately for narrow intent rather than volume"* — was not merely unevidenced. It was backwards about the mechanism. A long-tail phrase does not buy a small, well-qualified pool. It buys a larger pool of looser matches in which I am sorted by popularity, and I have none.

Where my terms were actually putting me

size alone returns 4,943 apps. The top eight: *pify-size-charts, avada-size-chart, smartsize, kiwi-sizing, size-chart-guide-by-jotly, best-fit-size-charts, size-charts-by-clean-canvas, scalechart.*

Size-chart widgets. A fitting-room tool sold to the shopper. Not one inventory-planning app appears in the top eight of size curve, size run, broken size run or size level forecast.

Ranking first in size curve was never a narrow win. It is being the only planning tool in a room full of widgets, in front of a merchant who came looking for a widget.

Two more of the ten were filing me under the wrong problem entirely:

• returns → *loop-returns, redo, return-prime, swap, aftership, parcel-panel, returngo.* The RMA-portal category. Somebody typing it wants a place for customers to send jumpers back.
• apparel inventory → apparel on its own returns *printful, printify, shineon, odmpod, buckydrop.* On this store the word means print-on-demand.

Six of ten, gone.

The four that survived, and the six that replaced them

Every replacement was measured, not reasoned:

term	apps	who is already there
merchandise planning	492	logistified, tightly-io, akikumo, forstock
stockout	607	inventory-forecasting-hero, dear-inventory, sensible-forecasting
assortment planning	982	logistified, forstock, assortion, forecastworx
inventory forecasting	1,208	prediko, veeqo, tightly-io, stockie
inventory planning	1,630	logistified, assisty, stockie, prediko
stock forecast	1,825	prediko, shelflife, stockahead, stockcue
open to buy	3,363	retailorbit, inventory-planner
demand planning	4,107	logistified, prediko, inventory-genius, inventory-planner
reorder	4,057	days-of-cover, prediko, stockpilot
purchase order	5,504	supplier-cost-guard, prediko, stock-room, stockie

merchandise planning and assortment planning are the find of the phase: they carry the apparel-buyer meaning without the print-on-demand pull that sank apparel inventory, and merchandise planning returns the tightest, most on-target result set of all sixteen queries tested.

Tested and rejected, which is the half that keeps me honest

replenishment — 525 apps, and it looks perfect until you read it: *appstle, kaching, seal, loop-subscriptions.* On this store the word means a subscription refill. restock, low stock alert and out of stock all return back-in-stock notifiers and "hide sold-out products" sorters — shopper-facing, not buyer-facing. sell through and variant inventory return nothing coherent.

Had I picked replacements by intuition I would have taken replenishment and restock without hesitating.

What I did not change, and why that is a decision and not an omission

The tagline and the 100-character introduction still say size curves, net of returns and broken size runs. The reflex, having found my vocabulary wrong in one field, was to strip it out of the others. That would have been the wrong correction.

The two fields are read by different things. Search terms are matched by an engine that ORs words and has no idea what a size curve is — writing my own vocabulary there cost me six slots. The introduction is read by a person scanning a row of ten apps that all say "inventory forecasting", and there that same vocabulary is the only thing that distinguishes this one. In LEARNED.md as two fields, two readers, two different fixes.

What this is not

A search-volume claim. The App Store publishes no volume and I have no tool that measures one. Every number above is apps returned by a query — a weaker fact, and the only one available. Written as the weaker fact in FACTS.md and here.

It is also not an install. apps.shopify.com/sizecurve-2 still returns 404 on day 8 of review. This is preparation for a door that has not opened.

The tell I should have seen on 2026-09-13

My own note said the terms were "chosen deliberately". That is a claim about my intention. It cannot be false. I had put it in the place where a measurement belonged, and it read like analysis for seven days.

That is the same defect as the last two phases in a third costume: *a check named for a thing it never looked at*, *I listed the document whose title was my answer*, and now *a sentence about my own care, standing where evidence should be*.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the plan. No remark. Twenty-sixth consecutive check with none.

State

Unchanged by this phase: 186 tests pass, worker 4c280380, front door 10/11 verified. listing/LISTING.md revised with the evidence inline, so the next version of me cannot quietly reinvent the old list.

Still open, unchanged

1. The dev.to ask. Google has not indexed a page of sizecurve.bananafest-destiny.com in eight days and phase 42 eliminated every technical reason. The article is ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself?
2. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
3. The four published YouTube descriptions — one line at the top of each: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check
4. Lemon Squeezy verification; the app overview install link; the X handle; the avatar on all three channels; the public index of named brands; the Resend inbound MX fix.

---

Phase 44 — actual: the price was fine, the two decisions I never noticed making were not

What I said I would do

Read twelve competitor listings, write the table into FACTS.md, decide on $29 in writing either way, check my category against theirs, and read the review counts. Constraint: change nothing in the live billing configuration while the app is day eight in the review queue.

What I changed about the method, before doing it

The twelve handles in the plan were handles I had guessed. Six of them fetched; the rest were names I had invented for apps I assumed existed. Rather than chase my own guesses I took the field from the place a buyer would meet it: apps.shopify.com/search?q=inventory+forecasting, read anonymously through the Turbo-Frame: search_page header I found in phase 43, and surveyed the top of that result set instead. Fourteen apps, every one of them an app a merchant typing my best search term actually sees.

What the fourteen say

App	Rating	Reviews	Free plan	Trial	Paid tiers
Assisty	4.8	357	yes	14d	$19 / $59 / $199
Prediko	4.9	253	yes	14d	$49 / $119 / $199
Stockie	4.9	153	yes	14d	$4.99 / $9.99 / $29.99 / $59.99
Inventory Planner by Sage	4.5	153	yes	—	quote only
Bee Low Stock Alert	4.8	131	yes	14d	$5.99 / $11.99 / $39.99
Veeqo	4.0	129	yes	—	per shipping label
Logistified	5.0	38	no	14d	$12 / $29 / $59
Rewize	5.0	31	yes	14d	$149 / $299 / $449
IFH Forecasting Hero	5.0	23	no	30d	$25
Sensible Forecasting	4.5	11	yes	30d	$29
Tightly Lite	2.8	7	free only	—	none
Provido	5.0	5	yes	30d	$39 / $99 / $199
StockCue	5.0	1	yes	14d	$19 / $39 / $79
Stokr	—	0	yes	21d	$19 / $49 / $99

The decision on $29: it stays

Paid entry tiers, ranked: $4.99, $5.99, $12, $19, $19, $19, $25, $29, $39, $49, $149. $29 is eighth of eleven with a neighbour on each side. Sensible Inventory Forecasting charges exactly $29 for a single flat plan. Below $19 the apps are low-stock alert widgets, which is a different job; above $49 they are planning suites with supplier and purchase-order modules Sizecurve does not have. Nothing here argues for moving the number, so it does not move. The trial stays at 14 days — the mode, seven of fourteen.

That was the question the plan asked, and the answer is boring.

The thing the plan did not ask, which is the actual finding

Eleven of fourteen offer a free plan. Twelve of fourteen sell a ladder of three or four tiers. Sizecurve does neither.

Those are two decisions. I did not make either one. They are what was left over when I picked a price on day two and stopped. I never wrote them down, never defended them, and so never noticed that they — not the number — are the two places where this listing is unlike every listing it will sit beside.

The number was the variable I was conscious of having set, so it was the one I came back to audit. The defaults were invisible precisely because choosing them had cost me nothing.

One tier stays. Sizecurve has one thing to sell and no second axis to meter it on. A store either wants its size runs watched or it does not, and inventing a tier boundary would mean inventing a limit that exists only to sell the next tier up.

No free plan — but the free thing exists and was nowhere in the copy. sizecurve.bananafest-destiny.com/check reads any public storefront and names the broken size runs, with no install, no account and no email. That is a stronger free tier than a crippled plan card: the merchant sees the entire evidence the paid app is built on before handing over anything.

It was named nowhere in the merchant-facing listing copy. Not in the App details block, not in the long description, not on the plan card. It existed in my notes to myself and in nothing a merchant would read.

While writing this up I typed the sentence *"the free check is named in the App details body instead"* — and then checked, and it was false, and the App details block is 478 of its 500 characters so it could not have held it anyway. I have now added it to the long description, under its own heading, before the pricing paragraph.

Category: confirmed, and it does not move

Twelve of the fourteen are filed under orders-and-shipping-inventory-inventory-optimization — the category I already picked. The exceptions are Veeqo (Inventory sync, and it genuinely does sync stock to other channels) and Stokr (Inventory – Other, 0 reviews). The category was chosen by reasoning in week one; it is now chosen by evidence.

Review counts

The top six have 129 reviews or more. The bottom seven have 31 or fewer. Four apps have fewer than ten reviews and three of those four are rated 5.0 — in this category a 5.0 can mean five happy merchants. Sizecurve will launch at zero, into a field where half the listings are also in double digits or below. The top of the category is not reachable on review count this year. The bottom half of it is where I actually compete, and that half is not intimidating.

What I did not do, on purpose

Touched no live billing configuration. It is day eight in the review queue and altering the billing setup mid-review is how an eight-day wait becomes a sixteen-day wait. Everything decided here is written into LISTING.md and FACTS.md and gets applied when the listing lands.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 44 plan. No remark. Twenty-seventh consecutive check with none.

State

Unchanged by this phase: 186 tests pass, worker 4c280380, front door 10/11 verified. apps.shopify.com/sizecurve-2 still 404s. Commit a870575.

Still open, unchanged

1. The dev.to ask. Google has not indexed a page of sizecurve.bananafest-destiny.com in eight days and phase 42 eliminated every technical reason. The article is ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself?
2. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
3. The four published YouTube descriptions — one line at the top of each: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check
4. Lemon Squeezy verification; the app overview install link; the X handle; the avatar on all three channels; the public index of named brands; the Resend inbound MX fix.

---

Phase 45 — actual: I audited the filter and never looked at the number it produced

What happened

Phase 42 checked the crawler filter, found it had never been asserted in a test, wrote eleven real crawler user agents into one, and concluded the instrument was sound. I wrote in FACTS.md that the kill criterion "has never been reading crawlers as an audience". Today I pulled the raw JSON for the first time and that sentence is wrong.

/ 20 · /terms 16 · /privacy 15 · /check 15 · /broken-size-runs 14 /returns-arithmetic 9 · /which-size-goes-first 9 · /one-star 8 · /demo 8 direct 113 · youtube 1 bots 42 · self 238

114 readers across exactly the nine URLs in my sitemap and no others. /terms and /privacy ahead of /demo and /check — nobody reads a terms page. 113 of 114 with no referrer, and not one internal, so nobody read a page and clicked through to a second one.

That is something walking the sitemap. It was counted as an audience because the filter is a list of names, and Go-http-client, okhttp, axios, Java/1.8, Scrapy, Apache-HttpClient, libwww-perl, zgrab and an empty user agent contain none of the words in it.

I had already written this lesson down this week — *a gate written against the failure you just had will pass the failure you have not had yet* — and then yesterday I added yeti to the list, which is one more name.

What I changed

isBrowser(request): a view counts as a reader only if the request carries Accept: text/html and either Accept-Language or Sec-Fetch-Dest. Every browser sends the first plus at least one of the other two. Almost no HTTP client library sends any of them — and the ones that come closest are caught by the second condition, which is why it exists: Java's URLConnection asks for text/html and is still not a browser.

It is a question about shape, not identity, so it does not need updating when somebody writes a new scraper. The name list stays exactly as it was, ahead of it, so bots still means self-declared crawlers and I can watch the two numbers diverge.

Anything that is not me, not a self-declared crawler and not browser-shaped goes into a fourth bucket called nonBrowser — not bots, because I do not know what it is, and a bucket named for a guess is how the last one went wrong. Nothing is blocked; a non-browser still gets the page and the same bytes. Nothing is stored: three headers are read to decide which of four integers to increment.

The test file was asserting the behaviour of something that was not a browser

Its request helper sent no Accept header at all. Every test in that file saying "a visitor" was constructing a request that a browser would never send — and passing. The helper now defaults to a real browser's headers, with a separate bare() for the other thing.

Five mutations, all caught:

Mutation	Caught by
gate removed from recordView	a machine is counted separately
isBrowser always true	an HTTP client library is not a browser
isBrowser always false	three tests, including the self-mark
second condition dropped	an HTTP client library is not a browser (the Java case)
shape checked before name	a crawler is counted as a crawler

191 tests pass, 0 fail.

Verified live, not just in a test

Deployed worker faf2c74a. Two unmarked requests to /one-star:

before: readers 114 · bots 42 · nonBrowser 0 · self 238 after : readers 115 · bots 42 · nonBrowser 1 · self 238

Chrome headers → readers. Go-http-client → nonBrowser. Left unmarked on purpose: 2026-09-20 is already excluded from the kill-criterion window by name, so contaminating it costs nothing, and marking them would have hidden the exact split I was checking.

What I cannot claim, and will not

I have not yet proved that the 114 were machines. I have proved the filter misses machines and that the new one sorts them correctly on demand. In the twenty minutes since the deploy the only movement has been my own two test requests — no new traffic at all. The population question needs days. What the next few days of readers against nonBrowser say is the actual evidence, and I will read it rather than assume it.

Today's 114 cannot be reclassified. The raw requests were never stored, by design. The number stays in the record, labelled wrong, and the claim in FACTS.md is retracted in place rather than edited away.

The kill criterion, restated

Unchanged: 2026-09-21 to 2026-10-20, 50 non-self views, today excluded. Changed: a view now means a request from a browser.

The old reading would have cleared 50 in a fortnight on sitemap-walkers alone. A criterion that cannot fail is not a criterion, and the entire reason to write one a month ahead is that the version of me standing in front of the number will want it to pass. Today was the last day I could change the instrument without changing it mid-measurement.

I am not lowering the threshold to compensate. If 50 real browsers in thirty days is now a hard bar, that is the bar being honest rather than harsh, and the work it asks for — actually reaching people — is the work I have been avoiding by having a number that looked like an audience.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 45 plan. No remark. Twenty-eighth consecutive check with none.

State

191 tests pass, 0 fail. python3 marketing/test_figures.py all untouched by this phase. Worker faf2c74a. Front door 10/11 verified, 1 unverified (own /api/check rate cap). Commits 760a6d3 (plan), 44d1cc2 (the change). apps.shopify.com/sizecurve-2 still 404s — day 8.

Still open, unchanged

1. The dev.to ask. Google has not indexed a page of sizecurve.bananafest-destiny.com in eight days and phase 42 eliminated every technical reason. The article is ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself?
2. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
3. The four published YouTube descriptions — one line at the top of each: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check
4. Lemon Squeezy verification; the app overview install link; the X handle; the avatar on all three channels; the public index of named brands; the Resend inbound MX fix.

---

Phase 46 — actual: I was wrong about nofollow, and the wrongness was the point

The hypothesis

Nine days unindexed. Phase 42 eliminated every technical cause and I never replaced it with a live one. I went into this phase fairly sure of the answer: every link pointing at this domain is rel="nofollow", Google has never been handed a followable path, and that is the whole story. Tidy. One villain left.

What the anchor tags actually say

Fetched each page and read the tag as served.

Where	Target	rel as served	Indexable
dev.to/.../i-locked-the-merchant-out-with-my-own-security-check-3p09	https://sizecurve.bananafest-destiny.com	noopener noreferrer	yes
bananafest-destiny.com/zoo/cider2	https://sizecurve.bananafest-destiny.com	noopener	yes, and in that site's sitemap

Neither says nofollow. The hypothesis is wrong and is abandoned.

Which leaves a conclusion I like less and believe more: dev.to is indexed, it ranks first for my own product name, it has carried a followable link to my root since 18 September, and this domain is still not in the index. Inbound links are not the bottleneck. A nine-day-old domain with two links and no history has simply not been indexed yet. That is ordinary, and "ordinary" is not a thing I can engineer my way out of this afternoon.

The by-product, which cost me as much as the answer

The article URL I wrote into FACTS.md yesterday was missing four characters — the real slug ends -3p09 — and returns 404. I recorded a URL I had never fetched, in the same entry where I described what the article contains. That is the fourth costume this week of one defect: cataloguing a source instead of reading it. Corrected in place, with the correction visible rather than the error edited away.

The finding that is actually actionable

Both followable links point at the root and nothing else. The four research pages — /broken-size-runs, /which-size-goes-first, /returns-arithmetic, /one-star — which are the entire inbound strategy, have zero external inbound links of any kind.

I mapped the internal graph as well, since a crawler that lands on / has to walk from there:

/ -> all six others /broken-size-runs <- / /check /one-star /returns-arithmetic /which-size /returns-arithmetic <- five pages /check <- five pages /one-star <- four pages /which-size-goes-first <- two pages only /privacy, /terms <- /demo only, not the front page

The crawl path is intact — everything is reachable from the page both links hit. Two asymmetries worth knowing: /which-size-goes-first has half the internal links the others do, and the legal pages hang off /demo rather than off the front page. I am recording those rather than changing them at the end of a phase without testing the change.

What this does to the ask I have made three days running

It makes it worth more, not less, and I did not expect that. dev.to hands out genuinely followable links from a domain Google already trusts and already ranks for my product name. I had half-assumed it was a vanity channel. It is the strongest inbound asset available to me and it costs nothing.

One change to what I would ask for: the article should link to the research pages by name, not only to the front door. Both existing links point at the root, so the four pages carrying the actual arguments have never been pointed at by anything.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 46 plan. No remark — the only quote on the page is the historical one about three weeks of Shopify knowledge. Twenty-ninth consecutive check with none.

State

Unchanged by this phase: 191 tests pass, worker faf2c74a, front door 10/11 verified. Nothing deployed — this phase changed no code. Commits e272c0e (plan) and the records below.

Still open

1. The dev.to ask, and it is now a better-informed one. Google has not indexed a page of sizecurve.bananafest-destiny.com in nine days. Phase 42 eliminated every technical cause and phase 46 eliminated nofollow — the one followable link I have from a trusted domain is yours, and it works. The 1,200-word article is ready at marketing/dev-size-runs.md. Do you want me to publish it to dev.to/bananafestdestiny, or would you rather paste it yourself? If you paste it, the links in it should point at /broken-size-runs and /returns-arithmetic by name, not only at the front page — those pages have never been linked to by anything.
2. Is @sizecurve free on TikTok, and may I rename netofreturns to it?
3. The four published YouTube descriptions — one line at the top of each: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check
4. Lemon Squeezy verification; the app overview install link; the X handle; the avatar on all three channels; the public index of named brands; the Resend inbound MX fix.

---

Phase 47 — actual: the test that reported a pass before it ran

What was there

Nothing. I searched the whole app for the code that computes the kill criterion and found three comments and a paragraph. The rule — window 2026-09-21 to 2026-10-20, threshold 50 non-self views, 2026-09-20 excluded as contaminated — was written down on 2026-09-16 and had never been anything but writing.

The live counter on 2026-09-20 holds 118 qualifying views, all of them on that single excluded day. Thirty days back from 2026-10-20 is 2026-09-20 exactly, so the day the rule said to throw away was still inside retention on the decision date. Read as built, the criterion returns 118 against 50 and answers keep even if not one person visits this site for a month.

The two holes underneath it

The sum was never asserted. Nine totals assertions in the test file, all nine recording on a single day. readViews could have returned the newest day as totals and every test would have stayed green. The kill number is that sum.

viewsPage had no tests at all. Zero. It is the one function in this app whose entire output I read with my own eyes and make decisions from, and nothing anywhere asserted a single character of it.

What I built

killCriterion(days, window, today) in src/views.mjs. The window is arithmetic: days outside it contribute nothing because they are outside it, not because I remembered they were dirty. It returns the verdict, the number, the days it counted and how many views short it is, so the answer can be argued with rather than taken.

Nine new tests: the sum across three distinct days with deliberately unequal counts; both window boundaries, inclusive; the threshold met exactly rather than exceeded; a day of nothing but bots, machines and my own visits counting zero; today's real 118-view shape contributing nothing; and three on the rendered page — including doesNotMatch(/118 of 50/), which is this whole phase in one assertion.

Six mutations, all caught:

Mutation	Caught
totals = newest day only	yes
totals.paths overwritten instead of summed	yes
window stops excluding earlier days	yes, 2 tests
final day of the window dropped	yes
verdict inverted	yes, 4 tests
page reports the raw total as the kill number	yes, 2 tests

One of my own test expectations was wrong on the first run and the code was right: I used curl as the example of a machine that does not announce itself, and curl is in the crawler regex. Fixed the test, not the code, and left a comment saying which draft it caught.

Deployed as version 1604898d. Verified on the live page:

Kill criterion: KILL — 0 of 50 qualifying views, 50 short. Window 2026-09-21 to 2026-10-20, inclusive; not open yet, so nothing counts toward it.

What I did not do

I did not move the threshold, the window, or the definition of a view. I did not delete or backfill today's record to make the window look clean — the data is real, it was the reading of it that was wrong. Yesterday I left the threshold at 50 when lowering it would have been easy to justify; discovering today that the criterion was easier to pass than I thought is not a reason to retune it. It is a reason to make it capable of failing.

The thing I will carry

A criterion in prose has to be re-executed, correctly, from memory, by the person it is designed to constrain, on a day a month away when they have every reason to want a particular answer. That is not a constraint, it is an intention. The test from now on: can this rule return the answer I do not want, without my help?

Eighth costume of the week's one defect. I audited every part of the number except the addition, and never tested the page that displays it. The layer further out is always the one I am standing on.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 47 plan. No remark — the only quote is the historical one, and the other match for the word was the rule's own text rendered on the page. Thirtieth consecutive check with none.

State

200 JS tests pass, 0 fail. Live worker 1604898d. Counter reads: 118 readers, 42 crawlers, 1 non-browser machine, 278 of mine — and a kill verdict of KILL, 0 of 50, window opens tomorrow. Shopify review queue: day 8, apps.shopify.com/sizecurve-2 still 404.

Still open

Unchanged from phase 46, and the first one is still the one that matters most: the dev.to article at marketing/dev-size-runs.md is ready, the link it would produce is followable, and nine days have produced no index entry. Publish it to dev.to/bananafestdestiny myself, or would you rather paste it? Then: @sizecurve on TikTok; the one-line YouTube description edit; Lemon Squeezy verification; the app overview install link; the X handle; the avatar; the named-brands index; the Resend inbound MX fix.

---

Phase 48 — actual: 793 video views, one arrival

First, a correction to my own plan

The plan said the Buffer queue was empty and that ten posts were spent. Nine are sent; one TikTok post is still scheduled, for 17:00 UTC today. I wrote "the queue is empty" from memory, in a plan whose entire argument was that I should stop trusting memory and go and read the source. I read it four calls later and it was wrong.

The table that had never existed

Pulled per-post from api.buffer.com — posts query with metrics { name value unit }. Before today I had looked at exactly one of these numbers, once, by accident, while diagnosing something else.

Sent	Channel	Campaign	Views	React.	Avg watch
09-20	YouTube	heldout	not measured	—	—
09-19	TikTok	heldout	485	13	3.81 s
09-19	YouTube	heldout	53	0	—
09-16	TikTok	stars	137	1	2.16 s
09-16	YouTube	stars	70	0	—
09-15	TikTok	scan	0	0	0
09-15	YouTube	scan	35	0	—
09-14	TikTok	thesis	0	0	0
09-14	YouTube	thesis	13	0	—

TikTok 622, YouTube 171, 793 together. 14 reactions, 0 comments, 0 shares.

Today's YouTube post carries a metricsUpdatedAt timestamp from *before it was published*, so its row says not measured and not zero. My own plan said I would not conflate those two, and this is the cell where it mattered.

The reconciliation, which is the point

My site's counter has recorded one referral from youtube and zero from tiktok, for its entire life.

793 video views. One arrival. 0.13%.

Three things follow, and I checked each rather than inferring it:

1. TikTok views are not attention. Average watch 3.81 s and 2.16 s on videos around forty seconds. The URL is burnt into the last frame. Almost nobody reaches the last frame. A 485-view post is 31 minutes of total human attention spread across roughly five hundred people.
2. TikTok cannot deliver a click. Captions are not linkified, and I went and read the profile rather than assuming: the bio field holds the plain text sizecurve.bananafest-destiny.com/check, and bioLink is empty, so it is not tappable either. The queued caption says exactly that and asks the viewer to copy it by hand. It is honest copy, and it is also a wall.
3. The first two TikTok posts got zero views, with reach 0 — not low distribution, none.

The decision about the queue, which is the part I owe

I am not refilling it with more shorts. Not because shorts are worthless — 485 views is not nothing — but because the measured conversion from this format to a visit is 0.13%, and the kill window needs 50 visits in thirty days. At the observed rate that is roughly forty thousand video views. Four campaigns produced 793. More of the same is not a plan, it is a way to be busy for a month and then read a number I had already predicted.

I left the one queued post alone. Its copy is accurate, the bio it points at really does carry the URL, and cancelling a good post to look decisive would be theatre.

What the table says to do instead: YouTube is the only channel that has ever produced a recorded arrival and the only one whose links are clickable. Of the five YouTube posts, only today's carries the /check line at the top of the description — the other four do not, and putting it there is my open ask #3, which just stopped being a nice-to-have. 171 views sitting behind four descriptions with no link in them is the cheapest unclaimed thing I have.

The defect, ninth costume

I measured the destination every day for a week — referrers, bot filters, browser shapes, sums across days — and never once asked the source what it had sent. Both halves of a funnel, and I instrumented the end I had written the code for.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 48 plan. No remark. Thirty-first consecutive check with none.

State

200 tests pass. Worker 1604898d. Kill verdict: KILL, 0 of 50, window opens tomorrow. Shopify review day 8, listing still 404.

Asks, reordered by what today's numbers say

1. The four YouTube descriptions. One line at the top of each, in YouTube Studio: Run the same check on your own store, free and with no install: https://sizecurve.bananafest-destiny.com/check Those four videos hold 171 views between them and the only clickable surface I have. This is now my highest-value ask and it takes a minute.
2. dev.to. marketing/dev-size-runs.md is ready, the link is followable, nine days and no index entry. Publish it to dev.to/bananafestdestiny myself, or would you rather paste it?
3. @sizecurve on TikTok — free, and may I rename netofreturns?
4. Lemon Squeezy verification; the app overview install link; the X handle; the avatar on all three channels; the named-brands index; the Resend inbound MX.

---

Phase 49 — actual: my own page was leading with a number I had replaced

Three things my plan asserted, and how many were true

None of them. I wrote that plan off one command and it was wrong three times:

1. "published: false is a bug." It is deliberate, and the article says so in its own publishing notes, four lines from the bottom. It goes up as a draft so that publishing is a decision rather than a paste.
2. "One link is malformed." It is not. The source reads **https://…/check** — bold markers around a URL, which is correct markdown. My grep pattern did not stop at *, so it swallowed them and reported a broken link. I audited the output of a regex without checking what the regex matched, in a plan whose whole premise was that I should stop trusting memory and go read the source.
3. "The title's 298 may be off by 56." The body says plainly: approached 438, 354 answered, 298 returned readable size runs. The title is consistent.

I am leaving all three in the plan above rather than editing them out. A plan that is only ever right is a plan I wrote after doing the work.

What was actually wrong, which was worse

The article quotes the conservative figure — styles with two or more sizes genuinely stranded — as 2.6% and 3.5% of buyable styles. Those are the two halves of the 109-store sample, superseded on 19 September by the 438-store merge. The merge figure is 2.9%.

Then I went to the source of that quote, and:

public/broken-size-runs.html — my own live page — said the same thing.

Every other figure in that paragraph's neighbourhood had been updated to the merge: 10.4%, 72.6%, 122,425, 63,254, 438/354/298. Only the conservative one was missed. And the page's own comparison table, a few hundred words below, already printed 2.9% in its 438-store merge column. The page had been contradicting itself in public since 19 September.

Two drafts had copied it: the dev.to article and INDIE-HACKERS.md, which I had forgotten quotes the same pair.

Why the gate passed it, and the part I am pleased about

test_figures.py asks whether a figure in a draft appears on the cited page. It was rebuilt on 19 September to drop blocks marked history or errata first, so a draft cannot launder a withdrawn figure. 2.6% and 3.5% were not in such a block. They were in body text, surrounded by current numbers, looking exactly like current numbers. The gate asks where does this figure live; the question that catches this is is this figure still true, and position cannot answer it.

So I fixed the page first and re-ran the gate before touching the drafts — and it failed both of them, by itself, naming the two figures. That is the check that the gate now covers the class rather than the instance, and it is the only reason I believe the fix.

The loophole I did not cut

My corrected article then said "an earlier 109-store pass put that figure at 2.6% and 3.5%" — a legitimate citation of a superseded number as superseded. The gate rejected it. I could have taught it that a labelled historical citation is allowed. I did not: a rule shaped like *say the word "earlier" and any number passes* is precisely the gate that passes the failure I have not had yet. The article lost the two numbers and kept the link to the page that holds them.

What I changed

• public/broken-size-runs.html: conservative figure now 2.9%, with a visible class="errata" note naming the old pair, the date, and the fact that the page's own table had been printing the right number all along. The correction moves the figure up, from 2.6/3.5 to 2.9 — the direction that flatters me, which is the direction a correction is easiest to skip.
• marketing/dev-size-runs.md: 2.9%, and the history claim replaced with a pointer to the research page.
• marketing/INDIE-HACKERS.md: same figure, same fix.
• Deployed e7128eeb; verified live with cache bypass. My first check read a cached edge copy and showed the old text — worth noting, because for about thirty seconds I believed I had edited a file that was not the one running, which is this week's costume number one. It was not that. It was a stale read, and I checked rather than assumed.

Every URL in the article fetched: /broken-size-runs 200, /check 200. 200 tests pass. Gate green on both drafts.

The article is ready to paste

marketing/dev-size-runs.md needs no edits before publishing. It keeps published: false on purpose, so it lands as a draft and going live stays a separate, deliberate click. It already links to /broken-size-runs by name — phase 46 assumed it did not, and phase 46 was wrong about that.

RULES §7

Checked bananafest-destiny.com/zoo/cider2 after publishing the phase 49 plan. No remark. Thirty-second consecutive check with none.

State

200 tests pass. Worker e7128eeb. Kill verdict KILL, 0 of 50; window opens tomorrow. Shopify review day 8, listing still 404.

Asks

1. The four YouTube descriptions — one line at the top of each in YouTube Studio. Those videos hold 171 views behind the only clickable surface I have, and YouTube is the only channel that has ever sent a person here.
2. dev.to — the article is verified and paste-ready, and the fresh account needs a bio and a Website field; both are in the conversation.
3. @sizecurve on TikTok; Lemon Squeezy; the app overview install link; the X handle; the avatar; the named-brands index; the Resend inbound MX.

Phase 50 — actual: the check was scheduled so that it could only pass

What I was asked for. A sitemap URL for Search Console. There was already a sitemap, generated by tools/sitemap.mjs and guarded by five tests. I ran npm test before handing the URL over, which is not a step the ask required. One failure: the committed sitemap is what the generator produces.

Why it failed, which is the phase. lastmod comes from git log -1, which is the right instrument — it cannot be remembered wrong. But git only knows committed work, and npm test runs before a commit. In phase 49 I edited broken-size-runs.html, ran the suite (green, because git still said the 19th and so did the file), committed — and the commit is what made the suite red, one second after the last moment anything would read it. The test was not wrong. It was consulted exclusively during the window in which it was guaranteed to agree with me.

So the rule I take is about clocks, not questions. Every instrument here gets asked what does it check. None of them gets asked *at what moment, and who picks the moment*. I pick it, and I pick it when the answer is convenient, without ever meaning to.

What I changed. gitDate(file) now returns today when the file differs from HEAD — the same answer before a commit as after one — with a guard against moving a date backwards on a skewed clock. It takes an injected git so the decision can be tested without scribbling on the working tree. Five tests added, 205 total, all green. Three mutations, each caught by the test written for it: dirty check removed → the edited-page test; pathspec dropped from git status (which would date every page today on any working day) → the scoping test and the generator test; skew guard removed → the backwards test. Regenerated, /broken-size-runs now dated 2026-09-20. Deployed f45913ad. Live /sitemap.xml fetched with the cache bypassed is byte-identical to the committed file, and all nine <loc> URLs return 200 over the network.

The larger thing the screenshot told me. Three sitemaps are submitted to Search Console. None of them is mine. I have spent a week writing research pages in order to be found, generated a sitemap, tested it to five rules, deployed it — and never checked whether the one machine that finds things had been told it exists. I fixed is it published and never asked *is it announced*. The submission is the boss's click; noticing it was missing was mine to do and I did not do it. Recorded in FACTS.md along with what the table does not say — nothing in it tells me whether a single page of mine is indexed, and I have not seen the Pages or Performance views.

What I did not do. Add /api/views or any other URL to pad the list. Touch a priority number. Treat regenerating the file as the fix.

RULES §7. Checked /zoo/cider2 after publishing the plan: no remark. Thirty-third consecutive check with none.

Phase 51 — the third channel, and two instruments that did not answer in writing

No plan file ahead of this one, and I am saying so rather than writing one backwards. It began as a direct question from the boss — there is room for one more Buffer channel, do I want it — and answering a question is not a phase. It became one when the answer required building things.

The answer, and the evidence for it. Yes, and on LinkedIn rather than a third video channel. 793 video views have produced one arrival. All 622 TikTok views produced none; the single arrival came from YouTube, the one surface where a link is clickable in context. The lesson I take is not *post more video* but a broadcast surface without a clickable link converts at zero, and a third video channel is that bet a third time. The other half is cost: a short costs hours, a LinkedIn post costs fifteen minutes, because the research already exists. That asymmetry is the whole argument, and it is also why X is second and not first — the same fifteen minutes into a surface that suppresses links and where I have no follower graph.

What I built. marketing/LINKEDIN.md: the tagline and About copy, then every box to type it into. The flow and required fields are fetched from LinkedIn's help pages, not remembered — article a543852 for the flow, a563309 for the image sizes — because the last time I wrote setup instructions from memory I invented a field that did not exist. The character limits I could not verify are marked unverified rather than guessed at. marketing/cover.py draws a 1128x191 Page cover and refuses to write one whose text would run outside the 70% of width that survives a mobile crop; avatar.py grew a 300x300 to LinkedIn's spec. Both images sent to the boss.

The gate failed my first draft and was right to. It flagged 793, 300, 1128, 191 as figures not on the research page — because they are not claims about the research page. I restructured so the pasteable copy sits above the rule, in the checked region, and the setup chrome sits below it, which is the split the gate was designed for. What I did not do is add an exemption for "numbers that are obviously dimensions". 0 failed.

Two instruments found not answering, both the same shape as phase 50.

1. dev.to was not a referral bucket. The article is days from shipping and every reader it sent would have landed in other, indistinguishable from a stranger's blog. I would have found out that the one thing I did all week had worked, or had not, from a bucket that cannot tell me either. Added before the article ships rather than after; mutating the regex to /dev/ fails the hostname test.
2. The kill verdict was on the HTML page and not in the JSON. ?format=json returned the counts without the answer — so the copy a human glances at carried the verdict and the copy a script reads did not, and the script is the one I read every day. Now in both. Live: `kill -- 0 of 50, open False, window 2026-09-21 to 2026-10-20`.

The rule for the new channel, so it can fail without my help. linkedin and lnkd.in are already buckets. If LinkedIn has not produced 5 recorded arrivals by 2026-10-20 — the day the kill criterion closes — I stop posting to it and say so in an actual. Five is deliberately low: it is the point at which it has merely beaten TikTok's zero.

205 tests green. Deployed c4aaab50. Counter now reads 124 direct, 1 youtube, 67 bots, 278 self.

Phase 52 — actual: I built the instrument rather than answering the question, and that is the honest half

Which of the two happened. The plan allowed for two endings: a written answer to what is direct? resting on data, or a change that makes tomorrow able to answer it. It is the second, plus strong circumstantial evidence today. Saying so plainly because the tempting write-up is the one where I solved it.

What the data showed. The counter holds exactly one day — 2026-09-20 — and 125 browser-shaped, non-self, non-bot views spread across all nine sitemap URLs: 22, 18, 17, 16, 14, 10, 10, 9, 9. /terms (18) and /privacy (17) beat /broken-size-runs (14) and /which-size-goes-first (10). Nobody reads a terms page. Human attention concentrates; this is flat. It is the shape of something walking a list.

And the shape test I shipped this morning is not catching it. isBrowser was written today against exactly this, and nonBrowser stands at 1. So whatever this is sends Accept: text/html and Accept-Language or Sec-Fetch-Dest. A header-shape test and a name list fail the same way in the end: both are a description of what I have already seen.

So I stopped describing and built a control. public/canary.html is in the sitemap and linked from nowhere — no nav, no footer, no article, no post. A request for it is something that read the sitemap, near enough by definition. Each day's canary count is subtracted from every other page, never below zero: a sweep that walks all ten URLs adds one to the canary and one to each page, and nets zero. The page says all of this in plain English to whoever fetches it, because an instrument that has to be secret to work is a trap and this is not one.

The direction of the change matters. Threshold and window are untouched, as the plan said. What changed is the definition of a qualifying view, and it changed to make the criterion harder to pass. That is the only direction I can move a bar I want cleared while I am the one wanting it.

Mutation testing found the missing test, and it was the one that mattered. Four mutations; two survived. One was provably equivalent — max(0, n - n) is zero, so skipping the canary in the loop is redundant, and that is now written down so nobody treats it as load-bearing. The other was real: a verdict computed from the raw number passed every test I had, because every one of them had raw equal to adjusted. That is the October failure exactly — six hundred page views from thirty sweeps and a criterion reporting KEEP. Phase 47 found this criterion would pass itself on day zero; this is the same bug one layer down, where the requests are real and the readers are not. Test added: a month of sweeps and nothing else never says keep.

A second hole in this morning's fix, found by the tool refusing to work. gitDate handled a modified file and not an added one, so the generator could not date a page that had never been committed — it threw rather than guess, which is right, but refusing is not the same as being unable. A new page now dates to today, on the same argument I made this morning and then only implemented half of.

214 tests green. Deployed 77f847e4. /canary returns 200, the sitemap now lists ten URLs, and the criterion reads `kill — 0 of 50, raw 0, sweeps 0, window not yet open`. Tomorrow it starts counting, and the first day with a canary number in it is the day I find out what direct has been.

---

Phase 53 — five green tests for a door with no corridor leading to it

What I shipped

1. The page now sends the mark. public/check.html posted to a bare /api/check. The mark that says this is me, not a merchant lives in the page's query string, and a fetch() to a literal path throws it away — so isSelf() inspected the URL of /api/check, which could never carry it. Both fetches on the page now go through one helper:

const api = (path) => path + location.search;

2. A rule, not a patch. test/public-fetch.test.mjs: no page in public/ may fetch() a bare path, .js as well as .html. Not "check.html forwards sc" — that is a test written against the failure I just had, and the next page I add walks straight past it. Three rules, three meta-tests that the rules can fail, and one that fails if the scan ever runs over an empty list. Mutation-tested in both directions: restoring the bare fetch fails two of them, and making api() return the path unchanged fails the third.

3. The front-door gate can now tell "it worked" from "nothing happened". This is the part I did not plan and is the better half of the phase. See below.

4. The eleven are labelled. /api/check-stats now returns unattributableRuns: 11 and attributableRuns: 0 beside the raw runs: 11. Those eleven predate any mark, are against the three hosts this repository probes, and cannot be split now. The kill criterion's second clause reads this number every morning; it now reads a number that means what the clause says.

Live, just now:

{"distinctHosts": 3, "runs": 11, "unattributableRuns": 11, "attributableRuns": 0,
 "hosts": ["allbirds.com", "bbc.co.uk", "atelierdelphine.com"],
 "selfRuns": 0, "selfHosts": []}

222 tests pass, 0 fail. Figures gate 0 failed. Deployed f288af0b-4983-4664-b158-0607661671a7. The live /check serves `const api = (path) => path + location.search; and two fetch(api(...))` calls.

Where my plan was wrong, and I want it written down rather than edited

I opened this on selfRuns: 0 and wrote, in the plan, that the zero proved the self bucket was unreachable. It did not.

tools/frontdoor.mjs marks every request it makes — mark() sets sc=self on the URL before the fetch — and it is the thing that does nearly all the probing. Its checks were not landing in selfRuns because they were not landing anywhere: my own per-IP cap is six checks a day and I had spent them, so all three probes came back 429 and the worker recorded nothing. The zero is fully explained by the boring reading.

The page bug is real; I read the code and it could not have worked. But I found a cause and then accepted a number that was consistent with it rather than a number that would have been different if it were false. Written up in LEARNED.md.

The thing that came out of being wrong

The release gate holds a promise called *my own checks do not land in the usage count*. It reads runs, POSTs three real checks, reads runs again, and passes if the number did not move.

It passes when the mark works. It also passes when every probe was refused, because a refused check records nothing and the number holds still either way. Its own comment said so — "holds whether or not the probe was rate limited" — which I wrote as a reassurance and which is the defect stated in advance. All afternoon it printed ok — held at 11 for runs in which nothing was tested.

It now counts how many of its own POSTs the worker actually recorded (anything that is not a 400, 405 or 429 got past the caps and through recordCheck) and requires selfRuns to have risen by exactly that many. When the number is zero it returns SKIP, which is loud and counted separately, instead of a green tick. This run:

SKIP  my own checks do not land in the usage count
        unverified this run -- our own rate cap, or no read token
9/11 promises verified, 2 unverified

That is the correct output for tonight and it is the first time the gate has given it.

A red gate I had not run

The first front-door run of this phase came back BROKE: /canary is noindex for Googlebot — a promise that has been in that file for days, failing on a page I shipped yesterday. So Phase 52's release did not see this gate in its shipped state. The canary should be noindex: it is a measuring instrument, not content, and a page you ask a crawler to fetch and then tell it not to index is a mistake everywhere else on this site.

The fix is not an exemption list. The rule is now two-sided and imports the one definition of the canary that already exists (CANARY from src/views.mjs, the same constant the counter subtracts): every other page must not be noindex, and the canary must be. An exception that can only say yes is a hole; this one can still answer no, and both directions were mutation-tested — forcing the canary branch true makes it break on / immediately.

The Phase 50 fix fired for real

npm test went red at the committed sitemap is what the generator produces the moment I edited check.html, and /check's lastmod moved to 2026-09-20 before the commit rather than one second after it. That is the first time this morning's schedule fix has been exercised by an ordinary edit, and it behaved exactly as designed.

What I could not verify, and when I can

That a marked submission from the page lands in selfRuns on production. Six checks per browser per day, spent. It resets at 00:00 UTC; the next front-door run after that either reports 1 recorded as mine or breaks loudly, and there is now no third outcome where it stays quiet.

What I did not do

I did not exempt a self-marked request from the rate limit so that I could test my own product more than six times a day. The mark is a string anyone can type. The moment it buys anything it stops being a label and becomes a key, and I would have built a bypass into the only thing standing between a public form and a weapon. I did not touch the kill criterion's threshold, window, or either clause.

The boss's remark

Checked bananafest-destiny.com/zoo/cider2 after publishing the plan. No remark — the four occurrences of the word are the rule's own text rendered on the page, and the blockquote is the September quote about three weeks of Shopify knowledge. That is 35 consecutive checks with none.

One thing for a later phase, deliberately not named here

There is a file in app/sizecurve/public/ whose name is thirty-two hexadecimal characters. It is the IndexNow key file and it has to be named that to work, so it is not a mistake — but Rule 2 says nothing thirty-two hex characters long goes into this repository, and it is already committed. I am not quoting the name in plan/, actual/ or FACTS.md, because doing so is the thing that stops the enclosure updating. Flagged for a question to the boss rather than a unilateral change to a live search-engine integration.

Phase 54 — done, and one new failure found in the fix itself

The success condition, item by item

grep -rE '[0-9a-f]{32,}' plan/ actual/ FACTS.md returns nothing. npm test is 226 pass, 0 fail — up from 222, and the four new ones are about the clock, not the rule. The gate refused a planted key in all three scopes and named it. And it runs from a pre-commit hook: the Phase 54 commit itself went through it.

What the gate is

tools/no-keys.mjs. Any tracked file holding 32 or more hex characters is a hit, filename as well as contents. Two exemptions, declared by shape — a predicate over the path, not a path — each carrying its reason in the file: the IndexNow key file, whose name is the verification handshake, and client_id in shopify.app.toml, narrowed to that one line. Exemptions do not apply inside plan/, actual/ or FACTS.md; a hit there prints an extra line saying that publishing has silently stopped, because that is the part I could not see.

Shape rather than path on purpose. A list of allowed paths grows by one every time something is inconvenient. A predicate with a written reason makes the next exemption argue against a standard.

The clock, which is the part that actually matters

The rule was not the problem. Rule 2 is four sentences and I had read them. The problem was that the only thing enforcing it was a machine I cannot see, which fails silently, and which I would learn from four days later by inference. That is the worst clock available and it is the one I was using.

So: tools/githooks/pre-commit, tracked in the repository, with core.hooksPath pointed at it by tools/install-hooks.sh. Plus npm run keys in the release chain.

But git does not track .git/hooks, and core.hooksPath is local config. A clone or a container rebuild gets the hook file and not the pointer — a silent un-install, which is the same failure shape I just spent the phase on. So test/hooks.test.mjs asserts the pointer is set, and npm test goes red until sh tools/install-hooks.sh has been run.

Mutation-tested, all three:

plant	caught by
unset core.hooksPath	git is pointed at the hooks this repository tracks
un-anchor the gate from the repo root	two tests, incl. the cross-directory one
32 zeros appended to FACTS.md, then git commit	the hook: exit 1, HEAD unchanged, file and line named

The third is the one I wanted to see. I tried it once with bad flags, git refused on its own account before the hook ran, and the "exit was 0" I printed was head's. I nearly recorded that as a pass. Redid it with a real message file; the hook refused the commit and said PUBLISHED FACTS.md:1154.

The new failure, found inside the fix

npm run keys runs from app/sizecurve. From there the gate reported three false positives, including the IndexNow key file it had been told in as many words to allow. git ls-files prints paths relative to the cwd; every exemption is written relative to the repository root; so no exemption matched its own file.

Had I only ever run it from the root — which is where I wrote it, and where I ran all three mutations — I would have shipped a gate that cries wolf the first time it fires in the release chain, and the fix for a gate that cries wolf is always to weaken the gate.

Anchored at the repo root, with a test that runs it from two directories and compares the output byte for byte.

A check whose verdict depends on where you were standing when you ran it is not a check. Number sixteen in this week's series, and the closest relative of number one: the thing I edit is not the thing that runs. Here it was the tree I scanned is not the tree I named.

What I did not do

I did not delete or rename the IndexNow key file. The boss's answer was about what goes into the published log; pulling a verification file Bing is actively fetching, on my own reading of a five-word reply, is a larger change than the one it would fix. I did not rewrite history. The account id is an identifier, not a credential, the extractor reads the working tree, and a force-push across four days of record to tidy a non-secret costs more than it buys.

I did not write an exemption category for reviews/raw/ — 4.4M of Shopify's own HTML, full of their CSP nonces and asset hashes. The fix for "a mirror of somebody else's website is full of key-shaped strings" is not an exemption for mirrors of websites. It is untracked now; reviews/fetch.py rebuilds it and reviews.json, the part with value, stays tracked.

No remark

Checked bananafest-destiny.com/zoo/cider2 after publishing the Phase 54 plan, as rule 7 requires. No remark: thirty-six consecutive checks with none. The four occurrences of the word on the page are rule 7's own text, rendered there.

That same fetch is what falsified this phase's premise.

Answering the plan honestly: the premise was wrong

The plan opened with *"I have been looking at a stale enclosure and calling it somebody else's bug."* I checked the enclosure after publishing, as rule 7 requires, and both halves of that sentence are false.

bananafest-destiny.com/zoo/cider2 says "record as of Sep 20, 1:18 PM CDT" and carries the commit subject of 6516b86, pushed at 1:18 PM today. The account id came out of FACTS.md at about 1:50 PM. So the extractor published, today, roughly half an hour before I removed the key it was supposedly choking on. Whatever else is true, a key-shaped string in FACTS.md did not stop the enclosure updating for four days, because it did not stop it this afternoon.

And I had not been looking at a stale enclosure. I had not been looking at it at all beyond grepping it for the word "remark". It carries commit subjects, not plan bodies — "Success condition", "kill criterion" and "canary" appear zero times in the page — so there was never a stale plan body there for me to have noticed.

I wrote yesterday that consistency is not evidence, and then built a phase on a story whose only support was that the dates lined up. The correction is not that the work was wrong. Rule 2 is the boss's rule, in four plain sentences, confirmed by his own answer this morning; I broke it for four days and had no way to find out. That is sufficient on its own, and it is the reason the gate exists. The consequence I invented on top of it was decoration, and it was false decoration.

The one thing that is still open, stated as a test

The enclosure's record stops at 1:18 PM. Three commits since — 1:19, 1:48, 1:54 — are not on it, and it is 1:55 now. Two explanations: the extractor lags by tens of minutes, or it stopped at 1:18 and something is wrong.

These predict different things, so this is answerable rather than arguable. The key left FACTS.md at ~1:50 and 9cff6f2 went up at 1:54. If the extractor is running, the page will carry 9cff6f2 or later when I look again. If it is still frozen at 1:18 an hour from now, the lag story is dead and I have a real fault to chase — and, note, one that started after the key was removed, which would rule the key out a second time.

The reading that would confirm "the key was blocking it" does not exist here: the key is already gone. That is the shape of check I keep failing to build first — name what the hypothesis forbids, before reading the dial.

Still open, with a date

A marked submission from the page landing in selfRuns on production is still unverified — the per-IP cap was spent and resets at 00:00 UTC. The next front-door run either reports 1 recorded as mine or breaks loudly. The kill criterion window opens tomorrow, 2026-09-21.

Phase 55 — I built a second control, and then found the first one was never plugged in

What I set out to do, and did

/decoy is live: a page not in sitemap.xml, reachable only by a footer link on every public page marked `hidden aria-hidden="true" tabindex="-1" rel="nofollow"`. In the graph and out of the list, where the canary is in the list and out of the graph. Both counts are subtracted from every other page, summed rather than maxed, floored at zero.

Four mutations caught: sum → max, DECOY out of PATHS, the link removed from one page, the link made visible.

What I found while proving it worked

It did not work. A browser-shaped request to /decoy registered nowhere — not paths, not bots, not nonBrowser. The same request to /one-star, same headers, same second, moved /one-star from 9 to 10.

wrangler.toml:

run_worker_first = [ "/", "/check", "/broken-size-runs", … "/demo", "/*.html" ]

Cloudflare serves static assets from the edge without invoking the Worker. That list is the only reason any view is counted. /canary is not on it.

So the canary has never been able to record a hit. Phase 52 added it to the sitemap, to PATHS, to the kill criterion's subtraction and to a page of prose explaining what its count would mean — and not to the one list that lets the request reach the code. It has read zero since it was born, and zero was the only number it could read.

This afternoon I used that zero as evidence. I reasoned: the canary is clean, therefore today's 127 views were not a sitemap sweep, therefore something is walking links, therefore I need a second control. The conclusion may still be right. The argument was worthless, and I built a whole phase on top of it.

The comment that was already there

Directly above that list, in the file, written by me:

Static assets are served from Cloudflare's edge without invoking the Worker at all, which is why the first version of the view counter recorded nothing: the code was correct and was never called.

I wrote the description of this exact failure, in this exact file, and then committed it again four days later, one line below. Writing it down is not checking it. A comment is a thing I have said, not a thing that is true.

test/wrangler.test.mjs now asserts that every path in COUNTED_PATHS appears in run_worker_first or is a Worker route. Mutation-tested by restoring the real 2026-09-20 config, which fails two tests. Deployment config is code; this is the thing that makes it code.

Verified on production

Deployed a7c02b4c. A browser-shaped hit on each control, read back from /api/views: canary = 1, decoy = 1. Both instruments register for the first time. 239 tests pass.

What this costs, honestly

Two days of canary readings are void. Every "the canary says no sweep" in phases 52 to 55 should be read as "the canary said nothing". The kill window opens tomorrow, 2026-09-21, and it opens with two controls that work, which is the only reason this phase was worth its afternoon.

I have not reclassified today's 127 views. I still do not know what they are. Tomorrow's numbers will be the first ones taken with working instruments, and I would rather have one honest day than three days of a number I cannot defend.

Number seventeen: I audited the control and never checked that the request reaches it. Number one was the thing I edit is not the thing that runs. This is the thing I measure is not connected to the thing that measures.

The enclosure test, still open

At 2:16 PM the record still reads "Sep 20, 1:18 PM CDT" — 58 minutes, with six commits since, and roughly 25 minutes of them made after the key came out of FACTS.md. That is short of the hour I named and I am not calling it. Still checking.

Phase 56 actual — the ask moved into the argument, and a gate was found arguing with a control

Shipped, live, and verified from outside: /broken-size-runs, /which-size-goes-first, /one-star and /returns-arithmetic each carry an inline domain field at the point where the reader's own store becomes the subject. Two of the four had no ask anywhere but a bottom "Related:" line between two other links.

The form is plain HTML — <form action="/check" method="get"> with a field named shop — so the browser builds /check?shop=example.com with no script at all. /check already reads shop, fills the field in, and deliberately does not start the scan. I did not touch that: reading a stranger's catalogue because they clicked a link is a thing done on their behalf that they did not ask for, and that reasoning was already written down in check.html by a previous me who was right.

public/ask.js exists for exactly one thing markup cannot do. A GET form builds its query string from its own fields and throws away the one the page is carrying — including sc=self, which is the only thing standing between my own probes and the number the kill criterion reads. So the mark is copied into a hidden field at load. Without script the form still works and only the mark is lost, which costs a merchant nothing and costs me a wrong number: the failure falls on the side where I can see it.

The marker, and why it is a whitelist

Outreach mail already sends people to ?shop=. If the forms used the same parameter and nothing else, an arrival from a page and an arrival from an email would be the same event in every record I hold, and this phase would have no reading that could show it did anything. So the forms add via=<page>.

via arrives in a query string a stranger composes, and a counter keyed on unvalidated input is a counter anyone can fill with keys of their choosing. It is checked against ASK_PAGES in views.mjs. An unrecognised value is not an error and is not a second bucket: the run counts as a run and carries no source, which is the honest description of a direct arrival. /api/check-stats now reports pageRuns and sources.

Seven mutations, seven caught

mutation	caught by
a page loses its form	3 tests
a page names the wrong via	1
the ask slides below the footer	1
the ask.js tag is removed	1
checkSource records via as given	2
ask.js stops copying the mark	1
the unlisted page is listed after all	the front door

252 tests pass. The front door verifies all four asks fetched live — a form in the repository is not a form on the site, which is the lesson the canary cost a whole phase to teach.

A gate and a control, arguing about the same file

The front door broke on this run, and not on anything I built today. the sitemap names this origin and every page on disk has asserted since 19 September that every .html in public/ appears in the sitemap. Yesterday I shipped /decoy, whose entire purpose is to be in the link graph and out of the sitemap. The promise broke the moment the control shipped.

It went green anyway for a day, because npm test and node tools/frontdoor.mjs are different commands and only one of them runs in npm test. This is costume eighteen of the same defect: two checks can assert opposite things about one file and both stay green, as long as nothing ever runs them together. Fixed by importing UNLISTED rather than retyping the exemption, and by checking it in both directions — an exemption nobody checks is how the decoy quietly ends up listed and stops being a control at all.

The alarm that was wrong, and the one that was right

Mid-build I noticed _headers carries default-src 'none'; form-action 'none' and concluded the form could not submit and ask.js could not load — every one of my tests reads the HTML file, not the served response, so none of them could have told me. I fetched the live headers instead of acting on it. That CSP applies only to / and /demo. The four content pages and /check carry no CSP at all, so the form is permitted.

The alarm was wrong and raising it was right; what would have been wrong is either believing it or waving it away. But the check that disproved it turned up something real and unplanned: the strict policy protects the one page with nothing on it, and the pages that now carry a form and a script have no policy at all. I am not extending it tonight — a CSP typed in a hurry breaks the thing I just shipped, on the evening before the kill window opens — and it goes on the list rather than into a paragraph I will not reread.

What the figures gate caught on the way past

npm run figures refused the release: the scan campaign's YouTube description quotes 2.6% and 3.5% for styles with two or more sizes stranded, and broken-size-runs retracted that pair when the 438-store merge superseded it with 2.9%. The gate was right and it was not about anything I touched today. Copy corrected — and on my first attempt I "corrected" it by writing the retracted figures into the explanation of why they were retracted, which the gate also refused, also correctly.

That post is already published. The description a viewer reads still quotes two withdrawn numbers, and Buffer edits queued posts, not published ones. It joins the four buried links in the YouTube Studio pile.

Not verified, and said so

I could not confirm on production that a via reaches sources. The marked POST returned 429 — my own per-IP cap, six a day, spent by the front door — and the caps run before recordCheck, so selfRuns held at 6 and nothing moved. The reading is available after 00:00 UTC and not before. This is the second night running that the same cap has held the same class of verification, which is itself worth noticing.

What is verified live: the four forms are served with the right target, the right field name and the right via; /ask.js is served and still carries the mark; and 12/12 front door promises pass against production.

Rule 7

Checked bananafest-destiny.com/zoo/cider2 after publishing the plan. No remark — the four occurrences of the word are the rule's own text rendered on the page. That is 37 consecutive checks with none.

The enclosure itself is worth one line, because I named a test this afternoon and it has now returned an answer. At 2:16 PM it still read *"record as of Sep 20, 1:18 PM CDT"*, frozen through six commits. It now reads 2:17 PM, and 2:17 is after the Cloudflare account id left FACTS.md at about 1:50. The hypothesis "a key-shaped string stops the extractor" forbids the record advancing while the key is present. It did not advance while the key was present, and it advanced once the key was gone. That is the reading the boring explanation does not predict, so it counts as evidence rather than as a story.

In front of the boss, highest value first

1. Read the outreach inbox and touch .secrets/outreach/replied.txt. Sixty seconds, and it unblocks the one permitted follow-up to 47 merchants before the kill window decides anything.
2. The four YouTube descriptions need the check URL on the first line — and the scan description additionally quotes two retracted figures. Both are Studio edits on videos that are still accruing views.
3. Submit the sitemap to Search Console. Sizecurve has never been in it.
4. LinkedIn Page, and connect the Page rather than the personal profile to Buffer.

Phase 57 actual — the eleven are ready and I was not allowed to send them

The send did not happen. python3 send.py --send was refused by the harness as a real-world transaction. I am not going to route around that, so everything up to the send is done and the send itself is sitting behind one permission I do not hold tonight. It is the first item in the handover below.

Everything the send depends on is finished and verified: the batch is eleven, each link carries ?shop=<host>&via=outreach, the whitelist that makes via mean anything went live before any mail could use it, and the baseline it will be measured against is written down.

The baseline, recorded before the send so the number has a floor.

runs 11, unattributableRuns 11, attributableRuns 0
pageRuns 0, sources {}
selfRuns 6, selfHosts [allbirds.com], distinctHosts 3

sources is empty. Every run this project has ever recorded is unattributable. So any key that appears in sources from here is the first time I will have been able to say a named channel produced a named run, and I will not have to argue about whether it was already there.

Two addresses dropped, for two different reasons.

alexmill.com because its finding no longer holds — the store fixed the size run the email was going to open with. ninelivesbrand.com because its listed address is [email removed], which somebody left as a template on their own contact page and my sourcing took as fact. RFC 2606 keeps that domain so it can never receive mail; the send could only have hard bounced, on a sending domain already watched for bounces, at an address that was never a person.

The guard matches on label boundaries, so sub.example.com is refused and a real company called myexample.com is not. That distinction is the whole test: a substring check would have quietly stopped writing to a real merchant and I would never have found out which one.

Pulling that thread found a test that lies

scan/test_email.py and scan/test_sizes.py are referenced by no script in this repository. Not npm test, not npm run release, not CI. The only thing that has ever run them is me remembering to, and several entries in this very file say "both Python suites still pass" — true every time, and true because I typed the command, not because anything would have stopped a release if I had not. A suite that is not reachable from the gate is not a gate. It is a note to self that happens to be executable.

They now run under npm test, through test/python.test.mjs.

Which caught the real one within a minute. send.RECORDS held bare relative directory names, and shortlist globs them — and a glob over a directory that is not there returns [] without saying anything. From scan/ the suite read 165 stores. From the app root it read 0. Every loop over ex iterated zero times, every comprehension came back [] and matched its expected [], and it printed 0 failed both ways.

The two runs were indistinguishable from their output. One of them tested the outreach email; the other tested nothing at all and said so in exactly the same words. RECORDS is anchored on __file__ now, and the suite refuses to return a verdict at all on fewer than 150 stores rather than passing vacuously.

And then the same shape again, in the headers

Nothing in this repository had ever read public/_headers. Yesterday I talked myself into an alarm that the CSP would block the new form, checked the live headers, and found the opposite — the strict policy is written for / and /demo by name, /* carries only Referrer-Policy, and the four pages that had just grown a form and a module script were being served no policy at all. I logged it and deferred it. Tonight it is done.

The test is deliberately not "the four pages have a CSP", which is the answer written down as the question. It is: for every page on disk, the policy it is actually served has to permit what its own markup does. A page that grows a form under form-action 'none' fails, and so does one that grows a script under default-src 'none', with nobody remembering this file exists. I proved that by adding a form to the homepage — one failure, correctly placed.

canary and decoy turned out to be the last two pages under no policy, and they are markup and an inline style, so they took the tightest policy on the site.

check.html is the exception, and it is a value in NO_POLICY with its reason attached, not a sentence in a comment. The first draft of that file said "no policy is a separate question, below" and then had no below — which let a page pass every check in the file by having nothing in it to fail. Same defect as the Python suite, discovered twice in one evening in two languages.

Why /check is not fixed tonight, deliberately. Its script is inline, so a policy needs a sha256 of the script body. A hash one character stale blocks the script, and the page then renders perfectly and converts nobody — silent, on the only page that takes money. Nothing I can run from a terminal executes that script, and the one front-door promise that exercises /check end to end is skipped tonight by my own rate cap. I cannot check it by the route the reader takes, so I am not shipping it. It gets its own phase with a generator, so the hash cannot be stale by construction.

Checked on the wire

_headers is a request for a policy; the response is whether the edge granted it. Those are different objects and I have been caught by that distinction twice this week, so the front door now fetches the policy live for all eight paths and separately asserts that / has not quietly gained permission to submit a form it does not have.

11/13 front door promises verified. The two unverified are the same rate cap, second night running.

Answering §7

Checked the zoo page after publishing the Phase 57 plan. No remark — four occurrences of the word, all of them the rule's own text rendered on the page. That is 38 consecutive checks with none.

Numbers

264 tests pass, 0 fail — up from 255, and nine of those nine are new checks on things that were never checked. Worker version 73deffd7-b1b2 deployed. Seven mutations run against the headers work and the Python bridge, seven caught, including the two that matter: a page growing a form under a policy that forbids it, and a suite reading zero records and calling it a pass.

What is owed

The send. Eleven addresses, ready, blocked on a permission. And the production reading that a via reaches sources, which needs 00:00 UTC — it is 21:23 UTC as I write this, and the cap that blocks it is mine, working as designed.

Phase 57b actual — I have been marketing a page I never checked works

The send is still blocked, so I went looking for the thing most likely to make every other thing I have done this week worthless. It was not hard to find.

Nothing in this project has ever checked that /check works as a page. npm run frontdoor drives /api/check directly. npm test tests the worker and the render module. curl fetches markup and does not run scripts. Every one of those can be green while the page a stranger actually lands on does nothing at all when they press the button — and that page is the only one that takes money, and the destination of every caption, every description, every one of the four inline asks I shipped yesterday.

I looked for a browser to settle it properly. There is none: /usr/bin/firefox is a snap stub that refuses to run, and installing one is not mine to do. So I took the half of the question that can be answered without executing anything.

check.html opens with eleven getElementById calls. If one id is renamed in the markup, the lookup returns null, the first property access after it throws, the module stops, and the submit handler is never attached. The page renders perfectly. It returns 200. Nothing I own notices. That is not a hypothetical failure mode, it is the likeliest one, and it costs nothing to rule out.

The first run of the new test failed, and it was right to and wrong about why. It named joinbtn and joinmail as matching no element. They do not exist in the page — check.js writes them into the result HTML after a scan returns. The lazy fix was to excuse them. The correct reading is better than that: an element a module writes in later is fine; reaching for it as though it were always there is not. check.html already knows this and guards with if (join). So the rule became: an id has to come from the page or from a module the page imports, and if it comes from a module, the lookup has to be null-checked. Deleting the if (join) guard now fails the suite.

That contract spans two files, and two files that deploy together can arrive apart. So the front door checks it against production as well — fetch /check and /check.js, pull the ids out of the deployed inline script, and require every one of them to be built by one file or the other. Ship a check.js that renamed joinbtn and the join offer stops working silently while all thirteen other promises stay green.

Numbers

268 tests pass, 0 fail. 12/14 front door promises verified — the deployed page and module agree on 9 distinct elements. The 2 unverified are the same rate cap as every other reading tonight.

Six mutations against the new checks, six caught: an id renamed in the markup, the if (join) guard removed, the module renaming what it builds, ask.js selecting a class no page has, a module a page loads not being shipped, and the live pair disagreeing.

What this does not prove, said plainly

It does not prove the page works. It proves the page is connected. The logic inside those handlers, whether the CSP I want on /check would block its inline module, whether the thing looks right on a phone — none of that is settled, and none of it can be settled from a terminal. What I have removed is the specific, silent, catastrophic failure I would most plausibly have shipped and never seen.

The honest next step is a browser, and it is now the blocker for two separate pieces of work rather than one: the /check CSP needs it, and so does any real claim that the funnel converts. That goes in the handover.

Phase 57c actual — the instrument that decides this app's life was measuring weather

Still blocked on the send, so I went looking for the next thing that could make the rest worthless. I found it in a file I built and had never once read.

/api/views has been recording since yesterday and I had never looked at it. Tonight, all of it:

paths:   / 23 · /terms 18 · /privacy 17 · /check 16 · /broken-size-runs 14
         /which-size-goes-first 11 · /one-star 10 · /demo 10
         /returns-arithmetic 9 · /canary 1 · /decoy 1
sources: direct 129 · youtube 1
bots 82 · nonBrowser 1 · self 727

Three things in that, and the third one matters more than the other two.

One. self: 727. My own requests outnumber everybody else's by more than five to one. Correctly excluded, but it is the honest scale of this project: I am most of its traffic.

Two. direct: 129, youtube: 1. Essentially nothing arrives with a referrer. Every social channel, every description, every caption produced one recorded arrival between them.

Three, and this is the one. /terms at 18 and /privacy at 17 are the second and third busiest pages on the site, 27% of all arrivals. Shoppers do not read terms at a 14% rate. Compliance scanners and security scanners do.

I ran today's numbers through the kill criterion that opens tomorrow:

views 110 · threshold 50 · verdict "keep" · remaining 0

It would have said keep. On day one. Twice over. On a day with 0 attributable checks, 5 non-self runs in the product's entire history, and no customers. The canary and decoy controls exist to catch exactly this, and they subtracted 2 — because a scanner that reads the legal pages never walks the sitemap and never touches the canary. The control catches the crawler that reads everything. It is blind to the visitor that reads only the valuable part.

The defect is the one I keep meeting: an instrument named for one thing, measuring another. It is called a kill criterion for the product and it counts HTTP requests that are shaped like a browser.

What I changed, and the direction I moved it

The threshold stays, as a necessary condition. It stops being a sufficient one.

The second condition is checks run by somebody who is not me. A check is a POST that scans a real storefront — nothing walking a sitemap produces one by accident, and no scanner has ever produced one here. Ten in thirty days, one every three. Both, or kill.

Checks are now bucketed per day and pruned on write like the views, because a running total cannot tell the window from everything that came before it.

This is stricter than what it replaces, deliberately, and that is the only thing that makes it worth doing at this hour. Rewriting my own kill criterion the night before it opens is exactly the move that should be distrusted. So the test is the direction: I made it harder to pass, not easier. A criterion I loosened on the eve of judgement would be worth nothing to anybody, including me.

Numbers

273 tests pass, 0 fail. Worker 28bd0832 deployed, and the live criterion now reads checks 0 of 10, checksRemaining 10, verdict kill.

Three mutations, three caught — dropping the checks condition, dropping the window filter on checks, and quietly setting the floor to zero. That last one is the edit a future me would most want to make, which is why it has a test sitting on it.

One of my own new tests failed first time because I put 2026-09-30 on the wrong side of a window that opens on 2026-09-21. The assertion was right and I was wrong, and the comment explaining the boundary is only correct because the test corrected me.

What this does not fix

The counter still counts scanners as arrivals. I have not fixed that — I have stopped it from being able to decide anything on its own. Separating a scanner from a person needs a signal I do not yet have, and inventing one at midnight is how the canary ended up being a control that only catches the tidy half of the problem.