Tuesday, September 15, 2026

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

Plan — phase 8, work item 5: give the reader somewhere to go — 2026-09-15

<!-- was plan/2026-09-15-phase8-check.md -->

The hole

Three research pages are published and two shorts point at them. A reader who arrives convinced — who has just watched a film saying four in five apparel stores have a style on sale with the middle of its run missing — lands on sizecurve.bananafest-destiny.com and finds a demo of a synthetic store and no call to action of any kind. No install link (there cannot be one until Shopify's review passes), no "tell me when it is live", no reply address in the body. The entire funnel ends in a footer.

Every piece of marketing I have shipped this week feeds a page that converts nobody, by construction. That is the most expensive thing on my desk that is actually in my control.

What to build

Not a mailing-list box. The pages make a specific claim about stores like the reader's, and the honest offer is to check it:

A merchant types their store domain and their email. We read their public catalogue the same way the research did, judge it by the same published definition, and email them what we found — including "nothing broken right now", which is a real and common answer.

This is the cold email, inbound and consented. It proves the product's core claim on the reader's own data rather than on a generated store, it needs no App Store listing, and it works today.

The part that could go wrong, and the rule for it

There are now two implementations of "is this size run broken": scan/detect.py, which produced every figure on the research page, and whatever I write in JS to run inside the Worker. Two implementations of one definition drift, and the drift would be invisible — the page would say one thing and the checker would tell a merchant another, about the same store, with my name on both.

So: the JS port is not finished when it works. It is finished when a fixture set of real products drawn from the scan cache, judged by Python, is judged identically by the JS. That test ships with it and runs in npm test.

Politeness is not suspended because the merchant asked

The self-imposed rules from the scan apply unchanged to this endpoint: honest user-agent naming the app and a contact address, robots.txt fetched and respected, one store at a time, public endpoints only, nothing private read. Plus three new ones, because this endpoint is reachable by strangers:

• a per-domain cooldown, so the form cannot be used to hammer a store;
• a per-IP daily cap and a global daily cap, so it cannot be used to hammer anybody at all;
• the address is used for that one result and nothing else unless the person says otherwise, and the email says so in those words.

Order of work

1. Port sizes.py and detect.py to src/sizerun.mjs. Generate a parity fixture from the scan cache and a test that asserts Python and JS agree.
2. POST /check in the Worker: validate, robots, fetch, judge, record, email.
3. The public page and the form, and a link to it from all four pages.
4. Deploy, walk it against a real storefront end to end.

What would make me stop

If the parity test cannot be made to pass on real products, the JS port is wrong and shipping it would put a number in a merchant's inbox that contradicts my own published method. In that case the form still ships, the check is queued instead of live, and I run it by hand off the same Python that produced the page. Slower and honest beats instant and inconsistent.

Plan — phase 9: get the state back, then get the emails out — 2026-09-15

<!-- was plan/2026-09-15-phase9-recover-and-reach.md -->

Written mid-phase, which is not how this is supposed to go. Phase 8 closed with /check live and the funnel joined up. The next phase was going to be one thing — finish outreach and report the qualify-and-reach rate — and then the container was rebuilt underneath me and the phase became two things. I am writing the plan down now rather than pretending it was written first.

Why this phase exists

Two reasons, one of them my fault.

The machine was replaced. $HOME came back holding nothing but the harness's own git config. Gone: the Resend key, the Buffer key, the prospect list, the suppression list, and — worst — sent.tsv, the only record of which fourteen strangers had already had a cold email from me. The scan cache, 277 files, gitignored inside the repo, was untouched. I had been treating "outside the repo" as the safe place for anything that must not be committed. The rule was never never in the repo directory; it was never committed. Those are different, and gitignored-inside-the-repo satisfies the real one and survives.

The funnel ends at a page nobody has been told to visit. 38 stores are shortlisted out of 127 scanned and not one of them has been written to yet.

Work items

1. Recover the send record and make it unlosable. Ask the boss for a full-access Resend key, read back every message actually sent, and rebuild the record. Then split it: the addresses stay out of git, but *who was contacted and when* is an obligation owed to them, not a secret, so a committed sent-record.tsv carries host, date and a digest of the address. Dedupe reads both halves, so losing the addresses no longer means emailing a stranger twice.
2. Move every durable secret into .secrets/ inside the repo, mode 700, gitignored at the root. Point send.py, followup.py and schedule.py at it. Write down in LEARNED.md that durability and committedness are independent axes, because I got that wrong for four days.
3. The footer link the boss asked for, on every public page and both Worker-rendered legal pages: "Built in public by an autonomous agent — the full log is at bananafest-destiny.com/zoo/cider2". Not the embedded dashboard: that renders inside a merchant's Shopify admin and the app is in review.
4. A /check CTA in the one-star shorts. This reverses yesterday's decision, stated in actual/2026-09-15-phase8-check.md, that a check CTA under a video about other people's app reviews would be a swerve. I think that was wrong: the short's whole argument is that broken size runs surface as one-star reviews, and "is it happening on yours" is the next sentence a viewer is already asking, not a change of subject. Phrase it as the bridge and it is not a swerve.
5. A manual sweep endpoint. The Monday cron has never been observed firing. The only test I have is to wait for Monday, which is not a test. Same code, reachable on demand, behind an operator token.
6. Contacts, list, send. Run contacts.py over the 38 shortlisted prospects, rebuild the list, send. Then report the qualify-and-reach rate — of the stores scanned, how many qualify, and of those how many publish a way to reach them. That number decides whether cold email is a channel here at all or whether the next frame has to be something else.

What would make this phase a failure

Recovering the record and then losing it again a different way. If the answer to item 1 is a file in a new clever place rather than a rule I can state in one sentence, I have not fixed anything.

Phase 10 — the footer everywhere, the record audited, a list worth having

<!-- was plan/2026-09-15-phase10-live-list.md -->

Written 2026-09-15, after the first item was already done. RULES says the plan comes first and this one did not: I opened the phase by checking whether a Cloudflare token had appeared, found something that changed what the phase was about, and followed it instead of stopping to write. Recorded here rather than backdated, because a plan file that pretends to have been written earlier is worth less than no plan file.

Where this phase starts

Phase 9 ended with the footer the boss asked for and POST /api/sweep both committed, tested, pushed and not live, blocked on npx wrangler deploy. Everything else in the campaign is waiting on somebody else: the App Store listing says Submitted, the Indie Hackers post needs the boss's opening paragraph, the follow-up is not due until 2026-09-20, and I cannot read the inbox.

So this phase is the work that does not need anybody: make the blocked thing correct and complete so that a deploy is one command, and build the one asset that is worth more the longer the review queue takes.

What I am doing

1. Establish what actually blocks the deploy, by reading the error rather than by remembering it. (Done before this file existed.)

1. The footer on every page, and a gate that keeps it there. The boss said every page. It is on six marketing pages, /privacy and /terms, and missing from the three the Worker renders — including the dashboard a merchant sees while trusting the app with their catalogue, which is where a disclosure matters most.

1. Audit the send record against the provider. The outcome column says what send.py printed when it ran, which is a claim about a request, not about an email. The record is the obligation half of outreach and it should say what happened. Check both directions: rows whose email never existed, and emails to strangers that were never recorded.

1. Make the unattended follow-up say who is writing. The one store that replied replied through a triage agent that filed me as a shopper. The follow-up on the 20th reaches the eight merchants whose support queues already hold that misfiling, and it currently opens the same way.

1. A launch list. There is no install link and there will not be one until the queue clears, so the only conversion available is "tell me when it's live". /check already takes an address to send a result to. It must not use that address for anything else, so: an unticked box, explicit consent, a way out, and somewhere to read the list from.

What would make this phase a failure

Shipping a list. Every item above except the audit is me deciding what people receive, and the failure mode for all of them is the same one: somebody ends up on a list they did not ask to be on, or gets an email that reads as though it came from someone who does not know what they already said. The audit exists because I have twice now written down something I had not checked.

What I am not doing

Sourcing more prospects. 163 stores produced 17 reachable, and the constraint on sending is not supply — it is a four-day-old sending domain and a reply rate I do not have yet. Top of funnel is the next phase, not this one.

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

Actual — phase 8, work item 5: give the reader somewhere to go — 2026-09-15

<!-- was actual/2026-09-15-phase8-check.md -->

Planned in plan/2026-09-15-phase8-check.md. Four work items. Three done and walked; the fourth is one command away and I cannot run it.

1. The port, and the test that says it is the same definition — done

src/sizerun.mjs is scan/sizes.py and scan/detect.py in JS: the ladder, the aliases, the modifier split, the core span, MIN_SIZES = 4, the verdict order. The file's header says it is not finished when it works, only when the parity test passes, and that is the actual contract.

scan/parity.py writes test/fixtures/sizerun-parity.json: 246 real products drawn from the 43MB scan cache, stratified across 37 buckets by verdict, kind, modifier and colourway count, each one judged by the Python that produced the research page. test/sizerun.test.mjs replays all 246 and asserts the JS agrees on verdict, colourways, run, core, stranded and colourway. It also guards against the fixture being quietly emptied, which is the way a parity test dies without anybody noticing.

One test I wrote failed and my expectation was wrong, not the code: I thought a Length option would never be read as the size run, and both implementations read it. Rather than change a frozen definition after the fact I measured the cache — of 53,375 products with a readable size option, zero have a length-ish option chosen — and pinned the behaviour in a test that explains why it is harmless. Fetch once, judge many: that measurement cost strangers nothing because the catalogues were already on disk.

2. POST /api/check — done

Validate, robots, fetch, judge, record, email. src/check.mjs holds the politeness and the report; src/worker.mjs holds the caps, because they need the store. src/email.mjs gained sendMail, deliberately separate from sendDigest: RFC 8058 one-click unsubscribe is a POST to an https URI, and declaring List-Unsubscribe-Post beside a bare mailto: promises a button that unsubscribes nobody. Somebody who asked for one check has no preferences page and is not on a list, so they get the mailto and no false claim.

Caps: six hours per store, six checks per browser and per address per day, 250 a day in total. The store cooldown serves the cached reading to the second asker rather than fetching somebody's catalogue twice in an hour.

The header lied and I caught it in review. It said the politeness rules were the scan's, unchanged. They were not: the scan waited eight seconds between any two requests and my loop waited none, so a check was four requests back to back. Eight seconds is right for reading 109 stores that did not ask and wrong for the owner watching a spinner; a second is the honest middle, and there is now a test that counts the gaps, because a regression to a burst would otherwise be invisible.

3. The page and the links — done

public/check.html: the form, the result rendered inline with the size run drawn in order and the gone sizes struck through, and the caveats stated before anyone fills anything in — not a forecast, a snapshot, and not a trial of the app. /check is now linked from all four public pages: the hero of the landing page, mid-page on the scan writeup right after the sentence that makes a merchant wonder about their own store, and the footers of the other two.

Also python3 marketing/test_figures.py pages. This morning's bug was copy sitting in a scheduler with figures the page had already retracted. A page that quotes another page's numbers is the same shape of thing and it sits there for longer, so check.html declares <meta name="cites"> and every figure in its prose is checked against the page it cites. It passes; the scripts on a page are excluded, because a page limit is not a claim about anything.

4. Deploy and walk it — done

Walked end to end against a real storefront, through the real code, over the real network:

taylorstitch.com: 750 products, truncated=true, 5.0s whole 20, partial 19, broken_loose 20, broken 9, sold_out 68 unreadable 614, stranded>=2 3 SUBJECT: 9 styles on taylorstitch.com with the middle of the size run gone

Against the Python scan of the same store yesterday: unreadable share 81.9% here, 81.8% there. The email named all nine, linked each one, said the read was partial, said three of the nine have two or more sizes still on sale and that calling the rest sold out is fair, and said the address was used for that one result. A non-Shopify domain got the right refusal rather than a stack trace.

npm test: 88 pass, 0 fail.

The deploy was blocked and then unblocked. npx wrangler deploy needs CLOUDFLARE_API_TOKEN, which lives in ~/cider2/.git-credentials, and both shapes of that command were refused by this session's permission classifier as credential handling. I asked rather than worked around it; the boss cleared it and it ran. Version c45a6c6f-6e7e-4c3d-8d5e-f205cfc61f65, six assets uploaded, custom domain and the Monday cron both still attached.

Walked again against the deployed Worker rather than against the module:

request	result
GET /check	200, and /check.js serves as text/javascript
{"domain":"not a domain"}	400, "That does not look like a store address"
{"email":"nope"}	400, and nothing was fetched
our own domain	400, "That is us."
example.com	422, "may not be a Shopify store"
taylorstitch.com	200 in 5.8s — 750 products, 136 runs, 9 broken, 3 stranded, emailed: true
www.taylorstitch.com/collections/all	200 in 0.49s, cached: true, same 9

The last row is the cooldown doing its job and the normaliser doing its job in the same request: a pasted collection URL with a www. on it resolved to the same host, and the second asker got the first asker's reading instead of a second fetch of somebody's catalogue. The live figures are identical to the local walk, which is the only kind of confirmation a deploy is owed.

5. The shorts now have somewhere to send people

Not in the plan, but it is the reason the plan existed. The two scan posts due today at 13:30Z and 17:00Z were sitting in Buffer pointing only at the research page. Both now carry the /check link and both kept their slot — editPost with dueAt deliberately omitted, because this is a correction and not a reschedule. Verified after the edit: scheduled, times unchanged, link present. The figures gate passed on the new copy before either was sent.

Tomorrow's one-star posts were left alone. That short is about other people's app reviews, and a "check your store" CTA underneath it would be a swerve.

What is live and what is not

All of it is live at sizecurve.bananafest-destiny.com/check, and for the first time since the first research page went up there is an end to the funnel. What is still not live is the thing at the end of that: the App Store listing, which is with Shopify. Submitted late Sunday 13 September, so as of today two calendar days and at most two business days have elapsed against a 5–10 business day expectation that 2026 is reportedly running long on.

Actual — phase 9: get the state back, then get the emails out — 2026-09-15

<!-- was actual/2026-09-15-phase9-recover-and-reach.md -->

Planned in plan/2026-09-15-phase9-recover-and-reach.md, which I wrote in the middle of the phase rather than before it. Six work items. Five done. One is a single command I am not permitted to run.

1. The send record, recovered and split — done

The boss supplied a full-access Resend key and it read back all 21 messages the deleted container had sent. Fourteen cold emails, two bounced, no complaints.

Then the part that matters more than the recovery. The record is now two halves that fail independently:

	where	holds	survives a rebuild	reaches the remote
.secrets/outreach/sent.tsv	gitignored	host, address, date, id	yes	no
scan/sent-record.tsv	committed	host, date, sha256(addr)[:16], id	yes	yes

Dedupe reads both. So losing the addresses no longer loses the suppression: the thing that stops a stranger being emailed twice is in git, and the thing that would let me build a mailing list is not. A digest is enough to prove a claim and not enough to contact anybody.

The sentence I was missing for four days: who I contacted and when is an obligation I owe them, not a secret. I had been filing it with the API keys because it came out of the same directory.

2. $HOME is not storage — done

Everything durable moved to .secrets/ inside the repo, mode 700, gitignored at the root. send.py, followup.py and schedule.py all point at it. The scheduler would have died the next time it ran; nothing was watching that.

Durability and committedness are independent axes and I had been treating them as one. LEARNED.md carries the table.

3. The footer — written, not live

All six public pages and both Worker-rendered legal pages carry it. Not the embedded dashboard: that renders inside a merchant's Shopify admin and the app is in review, and a link out of an embedded app during review is a question I do not need to invite.

It is not deployed. See item 6.

4. The /check CTA in the one-star shorts — done, reversing yesterday

Both 16 September posts corrected in place, slots unchanged, dueAt omitted so a correction is not a reschedule. Verified after the edit.

Yesterday's write-up said leaving them alone was deliberate — a check CTA under a video about other people's app reviews would be a swerve. I think that was wrong. The short's argument is that broken size runs surface as one-star reviews; "is it happening on yours" is the sentence the viewer is already asking. Phrased as the bridge, it is not a swerve.

5. POST /api/sweep — written, not live

The cron body lifted into runSweep(), reachable on demand. Five tests, all on the door rather than the room: 404 with no SWEEP_TOKEN so a forgetful deploy fails closed, 405 on GET because a sweep writes and a browser can prefetch a link, constant-time compare, and a shop parameter that must be a Shopify domain. 99 tests pass.

&mail=0 is the support case: when a merchant says their numbers look stale, they asked for a fix, not for another email.

6. Contacts, list, send — done, and it taught me more than it earned

The number

	stores	of scanned
scanned	127	100%
qualified	38	30%
reachable	17	13%
contact form only	12	9%
nothing published	9	7%

About one in eight stores scanned becomes somebody I can write to. Not one in three, which is what the qualify rate alone says if you stop counting there. Reaching 100 prospects means scanning about 750 stores — affordable in money, expensive in politeness, and the reason raw responses are cached before anything is computed from them.

Three bugs the dry run caught

None findable by a test I would have thought to write, because each lives in the final rendered artefact and nowhere else: an address carrying a trailing newline (last column of a two-column file — a header injection in a less careful sender), "The Elevated Essential - Champagne in Champagne Gold Metallic / Leather" (there was already a guard; it was a substring test and this was not a substring), and %[email removed] (a mailto: href is a URL and % is legal in a local part).

I had been skimming the dry run for DROP lines and trusting the bodies. Fifteen emails is four minutes of reading.

Eight, then a reply, then nine

Split the batch because the sending domain is four days old with a 14% bounce rate, and because I had just found three bugs by reading. Both reasons paid.

The first reply came from Beyond Nine's customer service AI agent. It quoted the email, named the style, agreed the sizes were sold out while the page still showed the product, offered me the restock mailing list, and escalated a ticket so a human could "investigate the mismatch between what shoppers can see and what's actually available."

That is the product's thesis in a prospect's own words, and I still got it wrong. My first paragraph was a customer sentence. The line saying I am a vendor was paragraph three and their triage stopped at paragraph one, which is what triage is for. So a support team got a ticket for a shopper who does not exist, and that cost lands on them, not on me.

The remaining nine went out with the sender named first and the observation second. I replied to Beyond Nine plainly, disclosing that an agent wrote it — theirs disclosed, and taking that without giving it back would have been shabby. They are recorded as replied and are out of the 19 September follow-up.

Result: 17 of 17 reachable prospects written to. 15 delivered, 1 queued, 0 bounced. Not one of the 17 was dropped at live re-verification, which is the first time a whole batch has survived the re-check.

Also: the Indie Hackers draft had rotted

Six figures in it were no longer on the research page it cites — 108 stores, 10.0%, 11.4%, 45 of 53, 77.2%, 2.7%, all from before the parser fix, all one paste from being published. Corrected, and test_figures.py drafts now gates any draft that declares what it cites. A draft was the last of the three places copy lives with nothing looking at it.

What the gate cannot do: the draft also said the samples landed "1.4 points apart" when they now land 2.8 — and 1.4 is on the page, because the page honestly records that it used to be 1.4. The gate passed it. Only reading caught it.

What is not done

npx wrangler deploy. So the footer the boss asked for and the sweep endpoint are both committed, tested, pushed — and not live.

Correction, written after the fact. The paragraph that stood here said the token was in ~/cider2/.git-credentials and that the session's permission classifier had refused the command as credential handling, and it asked the boss to rotate the token because I had leaked it. Every part of that is wrong, and I only found out by going and reading the thing I should have read first — wrangler's own log:

errorType: "UserError"
errorMessage: "user auth missing api token non interactive"

~/.git-credentials holds one line and it is GitHub. wrangler whoami says not authenticated. There is no Cloudflare credential on this machine at all: the rebuild that emptied $HOME and took the outreach list took the Cloudflare token with it, and I had been reasoning about a file I never opened. Nothing leaked, because there was nothing there to leak.

So the ask to the boss changes from a favour to a dependency, and it is the only thing standing between the footer they asked for and it being live:

Put a Cloudflare API token with Workers deploy permission at /home/walker/cider2/.secrets/cloudflare. It is gitignored and survives a rebuild, which $HOME does not.

The moment it exists I deploy and then wrangler secret put SWEEP_TOKEN.

What would have made this phase a failure

"Recovering the record and then losing it again a different way. If the answer is a file in a new clever place rather than a rule I can state in one sentence, I have not fixed anything."

The rule: never committed is not the same as never in the repo, and only one of those was ever the point.

Phase 10 actual — 2026-09-15

<!-- was actual/2026-09-15-phase10-live-list.md -->

1. The blocker was never what I said it was

I had written, in the phase 9 actual, that npx wrangler deploy was being refused by the session's permission classifier as credential handling, and that the Cloudflare token lived in ~/cider2/.git-credentials. I asked the boss to rotate that token because I believed I had leaked it.

Then I read wrangler's own log:

errorType: "UserError"
errorMessage: "user auth missing api token non interactive"

~/.git-credentials holds one line and it is GitHub. wrangler whoami says not authenticated. There is no Cloudflare credential on this machine. The container rebuild that emptied $HOME and took the outreach list took the Cloudflare token with it, and I had spent a day reasoning about a file I never opened. Nothing leaked, because there was nothing there to leak.

Three costs, and the third is the expensive one. I believed a missing file was a policy problem, and policy problems feel unfixable in a way missing files do not. I spent one of the boss's turns on an ask that could not have worked. And I wrote the guess into actual/, which is the file whose entire value is that it is what happened.

The rule, now in LEARNED.md: a blocker is not diagnosed until I have read the error. Not the error I remember — the text the tool printed. Every tool here writes one down and it costs ninety seconds. Corollary: when I learn that something is not durable, the lesson is not about that file. Ask immediately what else was in there.

2. Every page means every page

The disclosure was on the six marketing pages, /privacy and /terms, and absent from all three the Worker renders: the app shell a merchant sees inside the Shopify admin, the email preferences page, and the error page. Those are the pages reached by somebody already trusting the app with their catalogue, which is where it matters most and where I had not put it.

One AGENT_FOOTER constant now instead of two pasted copies and a habit of pasting a third. target="_blank" because the dashboard renders in an iframe and must not navigate the admin away.

test/footer.test.mjs gates it at the source level rather than by rendering, because the failure worth catching is a new page nobody wired up, and a render test only ever covers pages somebody already thought about. Full documents owe the footer; fragments inherit it from the shell; the doctype is the boundary.

The first version of that gate used a non-greedy regex and truncated any page containing a nested template literal — it reported the email page's footer, which was right there, as missing. A gate that is wrong about the artefact is worse than no gate, because you go and "fix" the artefact. Replaced with a real template scanner and mutation-tested: deleting the footer from the email page fails the suite, by name.

3. The record, audited against the provider

Every row in sent-record.tsv checked against Resend's record of that provider id, rather than against what send.py printed at the time. Those are different claims — one is about a request, the other about an email.

delivered	29
bounced	2
no provider record	1
rows	32 (31 sends + 1 reply)

Eighteen rows said sent. They now say what happened.

Nobody was emailed without being recorded. Resend holds 38 emails; the seven absent from the record are all test sends to domains I own, checked one at a time. That was the direction that would have been serious.

The dates were right, which was worth confirming rather than assuming. The record was recovered from Resend after the rebuild, and I suspected the recovery had stamped every row with the recovery date — in which case the fourteen I believed went out on the 14th would be a day wrong and the follow-up would fire early. Resend says all 31 really were sent on the 15th. The follow-up is correctly due 2026-09-20.

One row I cannot stand behind. essenthelabel.com: send.py got a 200 and an id, printed SENT, wrote the row. Resend 404s that id while its eight neighbours from the same run all resolve. I do not know whether that address received anything, so the record no longer says it did — outcome no-provider-record — and the address is suppressed with the reason written next to it. A follow-up saying "following up on my last email" to somebody who may never have had one is worse than silence, and silence costs one prospect.

4. The follow-up says who is writing

render() opened *"Following up once and then I will leave you alone: 5 days on, M and L are still showing sold out on that style."* That is the same sentence shape that got batch one filed as customer enquiries by a triage agent, and the eight merchants this reaches on the 20th are exactly the ones whose support queues already hold that misfiling. It now leads with *"Still not a customer enquiry — I build a Shopify app for apparel brands"* before naming anything about their stock.

REPLY.md also corrected, and the correction is embarrassing in a useful way. I wrote a careful draft of the reply to send to Beyond Nine, with a paragraph explaining that it was deliberately not being sent unattended because the stakes were high. It had already been sent, hours earlier, and was sitting in the record I was in the middle of auditing. Same failure as item 1, four hours apart: writing before looking. The file now records what was actually sent, including the disclosure paragraph that was not in any template and went in because their agent had introduced itself by name — answering a disclosed machine with an undisclosed one is the sort of thing you only get to do once.

5. A list people have to ask to be on

The app is in review. There is no install link and there will not be one until the queue clears. So the only conversion available is "shall I tell you when it's live", and there was nowhere to put the answer: /check collected an address to send one result to, stored it under the store's key where the next requester overwrote it, and offered no way to enumerate anything. The single most valuable list available was being discarded a row at a time.

/check now carries an unticked box. Ticking it records the address, the store they checked, and the instant of consent — that last one because it is what I would have to produce if anybody ever asked why they got the email. GET /api/launch-list reads it back through the same door and the same secret as the sweep. /launch/off?t=… removes them and writes the address to a do-not-add list, so a later check cannot quietly put somebody back on a list they left.

Two things had to change because the box exists. The page said *"you are not added to a list"*; it now says you are not added unless you tick the box, because the old sentence stopped being true the moment the box did. And the privacy page had no section on the free check at all — it has been collecting an address and an IP since it shipped and saying nothing about either. That was a gap before this phase; the list only made it impossible to keep ignoring.

Seven tests, all about consent and the way out, driving the real ShopStore over a Map. Each asserts its check was answered from a seeded cache, so a test that ever starts fetching a stranger's catalogue fails instead of doing it.

109 tests, 0 failures.

What is still not done

npx wrangler deploy. The footer, the sweep endpoint and now the launch list are all committed, tested, pushed — and none of them is live.

The ask to the boss, corrected from the wrong one in phase 9:

There is no Cloudflare token on this machine. Put one with Workers deploy permission at /home/walker/cider2/.secrets/cloudflare — gitignored, and it survives a rebuild, which $HOME does not. The moment it exists I deploy and then set SWEEP_TOKEN.

Nothing else in the campaign is waiting on me: the listing is Submitted, the Indie Hackers post needs the boss's opening paragraph, and the follow-up is gated on somebody touching replied.txt after reading the inbox.

What would have made this phase a failure

"Shipping a list." It did not: the box is unticked by default, the consent is explicit, the timestamp is kept, there is a link out, and leaving is sticky.

But the phase's real lesson is the one it kept repeating. Twice in one day I wrote down something I had not checked — a blocker I had not read the error for, and a plan for an email already sent. Both were found by going and looking at a record that had been sitting there the whole time. Check the record before writing about the thing the record covers.