Plan 2026-10-18

Phase 455: Flatdesk's per-ticket article, drafted for listing day

• The Flatdesk case's Reach section names two pieces: the /per-ticket page (Phase 454, waiting on a deploy) and an article on what per-ticket billing costs. The article goes on the studio's dev.to account, which ranks in web search and which I may run myself (FACTS, 09-30).
• One agent drafts it in scratch/helpdesk-devto.md. Every figure comes from the Phase 454 page, and every import claim from the code. No competitor is named.
• It is not posted. It goes up once the page is live and a stranger can install Flatdesk. Today they cannot, because Flatdesk is not on the App Store.

---

Phase 456, plan: the 10-20 verdict, written before the number

Sizecurve stands at 48 of 50 engaged views and 11 of 10 checks, with the window closing at the end of 2026-10-20. I am writing down now what each result means, so that I can't bend it once I've seen the number.

• The number is the one in the box on the arrivals page at the end of 10-20 UTC. It is the count the criterion has used since 09-21. Neither threshold moves.
• Ad clicks are reported beside it, not added to it. The ad sends people to the App Store listing, not to our pages, so its clicks are not views on the instrument. Counting them would loosen a criterion that is already running, and FACTS 09-20 says a running criterion may only get harder. If the ad brings an install, that sits outside the criterion and is worth more than any view.
• PASS (50 or more views and 10 or more checks): Sizecurve continues. I ask the boss to add the Free plan (3 styles) on the Partner Dashboard and to check whether saving it sends the app back to review. Then one agent builds the Phase 429 brief as checked in Phase 430, and I ask before deploying.
• KILL: Sizecurve stops taking new work: no free plan, no new pages, posts or ads after the ad is paused on 10-26. It stays listed and working, because a shop that installs it should get what it pays for. I answer any support mail and fix anything broken. The time goes to Flatdesk and Close of Day, and the lesson goes in LEARNED.md.

---

Phase 457, plan: test the developer's reply against our own scan

• On 10-17 a developer, replying in public, said Sizecurve might suit a store with 150k products or several locations, but that "most store owners would know what sells". That claim can be tested. If small catalogues rarely have a broken size run and big ones often do, the buyer is the big store. If small ones break just as often, owners do not know.
• One agent reruns the published definition over the 298 public catalogues already on disk, with no network. It groups the stores by number of sized styles, and gives the broken share in each group and its rank correlation with catalogue size. Stores are numbered, never named.
• It goes into LEARNED.md and into the 10-20 verdict's notes. It does not change the criterion.

---

Phase 458, plan: correct the size-runs article

• Phase 457 found that the dev.to article "I read 298 Shopify catalogues…" (live since 09-30) defines broken differently from the scan that made its figures. The article says "a size is sold out while sizes on both sides of it are still in stock". The scan (scan/detect.py) counts a run as broken when every size in its core, the middle half of the sizes listed, is gone while the style is still buyable.
• Checking it, I found worse. The article says "72.6% of broken styles are missing exactly one size". The figure is the share with exactly one size left, as /broken-size-runs correctly says. Its diagram and its "single hole" paragraph rest on that misreading.
• One agent rewrites the article's finding section to match detect.py and /broken-size-runs, adds a dated correction note, and checks the other two dev.to articles for the same error. I check it, then update the live article myself.

---

Phase 459, plan: a reply for the boss's developer-forum thread

• The one reply on the boss's 10-17 thread said Sizecurve might suit a store with 150k products, but that most owners know what sells. Phase 457 tested that against our scan. Broken runs come at the same rate, about 7%, from 25 styles up to 500 and beyond.
• I write a short reply the boss can post under their own account. It gives the numbers and what the scan cannot see, and it carries no link. It is the boss's thread, so the boss decides whether to post it.
• No new work goes into Sizecurve's site or app before the 10-20 verdict.

---

Phase 460, plan: Flatdesk's Community threads, found and answered in draft

• Close of Day has a set of drafted replies to the Community threads where its buyers ask for it, held until it is listed (Phase 403). Flatdesk has none. On listing day the first installs are most likely to come from owners already asking in public.
• One agent searches the Shopify Community for threads since 2025 where a store asks for a help desk or shared inbox, or complains about paying per ticket or per agent. It reads each once, decides Reply or Skip by the same tests as Phase 403, and drafts link-free replies held to app/helpdesk/listing/LISTING.md. Each reply answers the question first and names Flatdesk and its price once.
• The drafts go in scratch/helpdesk-thread-replies.md. Nothing is posted until Flatdesk is listed.

---

Phase 461, plan: what the docent asked for Flatdesk

• The docent found Flatdesk live from outside. The record still lists only Sizecurve as my app, so the house site shows four products when there are five. Six asks, in their order.
• Apps list. FACTS.md's "Current app" section now declares Close of Day and Flatdesk beside Sizecurve, each with its URL, status, price and plain description. Close of Day was missing too.
• Sitemap. One agent adds public/sitemap.xml and a Sitemap line in robots.txt to Flatdesk, as Sizecurve has. A test fails if a new page is left out. It goes live only after I ask "May I deploy Flatdesk?".
• The rest I answer in the conversation for the docent: - the two plain sentences; - the free thing: /per-ticket is a page anyone can read, not a tool, and I say so; - the price; - listing status with dates: not submitted, waiting on the screencast; - /health's public phase number, which stays, as a decision.

Phase 455, actual: Flatdesk's per-ticket article, drafted and held

• scratch/helpdesk-devto.md, about 1,000 words, published: false, titled "What a per-ticket help desk costs a Shopify store at 300, 1,000 and 2,000 tickets". It covers the leader's listing ladder, the sums ($60, $340, $360 against Flatdesk's $49) and why the step from 300 to 1,000 tickets is where the bill jumps. Then come four steps for leaving any help desk, and a short, fair Flatdesk section: what it lacks, that the import leaves attachments behind, and that it has no reviews yet.
• Every figure matches a line of /per-ticket, except the differences ($11, $291, $311) and "more than five times", which are arithmetic on those lines. I read it whole and checked the sums. No competitor is named, and it has two links, both to the Flatdesk site.
• It is held until /per-ticket is live and Flatdesk can be installed. On that day the listing prices are read again first.
• Sizecurve: 48 of 50 engaged views, 11 of 10 checks, with two days left before the 10-20 verdict. The free-plan brief from Phase 429 and 430 is ready if it continues.

---

Phase 457, actual: the reply tested against our own scan

• One agent read only the scan output on disk, with no network and nothing written in the repo. It used detect.py's own functions.
• It reproduced the published figures exactly: 298 catalogues, 234 with a broken run (78.5%), 64,268 runs, 5,773 broken styles.
• The broken share by catalogue size, in sized styles:

Sized styles	Stores	Median broken share	Middle half	Stores with at least one
1 to 24	66	0.0%	0 to 5.8%	22 (33%)
25 to 99	82	7.1%	2.3 to 12.7%	66 (80.5%)
100 to 499	107	7.6%	3.4 to 11.2%	103 (96.3%)
500 and up	43	6.7%	3.3 to 9.3%	43 (100%)

• The rank correlation between catalogue size and broken share is weak: 0.280 (n=298), and 0.153 without the stores under 10 styles. 30 of the 43 largest stores hit the scan's 1,000-product cap, so that row undercounts their size.
• What it says: from about 25 styles up, the share is flat at about 7%. A store of 60 styles is as likely to show a broken run as one of 600, and four in five of them have at least one. The reply's line, that owners know and only a store with 150k products needs this, is not what the catalogues show. Only the smallest stores break less.
• What it cannot say: the scan sees availability, not quantities or sales. A broken run may be a choice, such as a style being run down, and the owner may know about it. It cannot see stores with several locations.
• Doing this, the agent found that the live dev.to article states the definition of broken wrongly. That is Phase 458.

---

Phase 458, actual: the size-runs article corrected, live

• One agent rewrote the finding in marketing/dev-size-runs.md to match scan/detect.py: - The definition is now the scan's: every size in the core, the middle half of the sizes listed, is gone while the style is still on sale. It gives a 4-size example. - The 72.6% line now reads "have exactly one size left". So do the later line that repeated it and the code sample. - The diagram is now a run that the scan counts as broken. The agent checked it with judge(); the old diagram came out only as the looser reading. The rewritten code sample was checked against judge() for every run of 4 to 10 sizes. - The store table's first column was headed "loose", which reads as the looser rule. It now says "broken". - A dated correction note is at the end.
• The figures gate passes for the file, and the key scan is clean. No number was added; each one traces to /broken-size-runs or to figures.py.
• Neither error is in the other two dev.to articles or on any site page.
• I updated the live article through the DEV API: 200, edited 2026-10-18 11:20 UTC. A fresh read of the live body matches the repo text exactly. The title and URL are unchanged.

---

Phase 459, actual: the forum reply, drafted for the boss

The text given to the boss in the conversation, unposted:

I checked this against data I already had: a scan of the public catalogues of 298 Shopify apparel stores. It counts styles that are still on sale but have every middle size sold out. From about 25 styles up, the rate doesn't grow with the catalogue. It is 7.1% of styles at 25–99 styles, 7.6% at 100–499 and 6.7% at 500+. 4 in 5 stores with 25–99 styles had at least one. Only the stores under 25 styles broke less (median 0%). So I think you're right for very small shops, but not far past them.

On your XS example, the scan can't see stock counts, only what is sold out. What it shows is the opposite mistake: M and L gone while the page still says in stock, rather than too many XS. Whether owners know about those and leave them on purpose, a catalogue can't tell me. That's a fair hole in my case.

---

Phase 460, actual: Flatdesk's Community threads, drafted and held

• One agent searched the Shopify Community with 16 wordings since 2025. The forum rate-limited it on the 16th request, so it stopped as told. It never opened a whole thread: each decision rests on the first post's excerpt and the search blurbs.
• Its verdicts: 6 Reply and 22 Skip. The Skips are surveys and makers' research, threads already solved, off-topic threads, and asks for AI, phone or messaging channels that Flatdesk lacks.
• The Reply threads, by posts: - 692994 (13 posts, active 10-17): support costs growing fast, with a per-ticket price quoted; - 651458 (9); - 307434 (6); - 66927 (4); - 621681 (3), a two-person team doing 600 orders a month; - 571771 (2).
• The drafts run 122 to 147 words. - Each answers the question first, whatever the asker uses, then names Flatdesk, $49 a month flat, and one limit. - No links and no product names; both greps are empty. - Every claim is tied to LISTING.md. I cut one claim about other apps' trials that the listing cannot back.
• Held in scratch/helpdesk-thread-replies.md until Flatdesk is listed. Before each post: read the whole thread, check its views, and check that nobody has already said the same. At most two a day, and never 307434 and 66927 on the same day.

---

Flatdesk deployed: /per-ticket is live

• The boss approved one deploy. Tests: 250 pass, 0 fail. Wrangler deployed the Worker to helpdesk.bananafest-destiny.com.
• Read back: /, /per-ticket, /terms and /privacy return 200, and /per-ticket.html redirects to /per-ticket. The page carries its own CSP, and the home page footer links it.
• This was Phase 454's page. The dev.to article (Phase 455) and the thread replies (Phase 460) still wait for Flatdesk to be listed.
• The boss confirmed that Sizecurve's subtitle changed on 10-17. When I read the ad stats on 10-19 and 10-22, I split them at that change.

---

Phase 461, actual: Flatdesk's sitemap and card, held for deploy

• The apps list. FACTS.md now declares Close of Day and Flatdesk as current apps beside Sizecurve. Each has its URL, status with dates, price and a plain description. Committed before the agent ran.
• The sitemap. One agent added public/sitemap.xml with the four public pages (/, /per-ticket, /privacy, /terms), each read live as 200. It also added the Sitemap line to robots.txt, keeping its rules. - Four new tests: the XML is well formed, every URL is on this host and maps to a file, every public page except the 404 is listed, and robots ends with the Sitemap line. - The agent checked that the tests fail when a page is removed. - Tests: 254 pass, 0 fail.
• The card. public/media/flatdesk-card.png is a 1200x630 crop of listing screenshot 2, unstretched and 218 KB. It shows a ticket with its thread, an internal note and the customer's last orders. I looked at it: the data is all invented (example.com addresses, the made-up store from shots.mjs).
• Neither file is live until the next deploy, which I ask for first.
• My answers to the docent's six asks went to the boss in the conversation. They include /health: its public phase number stays, as a decision.