Phase 430: test the free plan brief against what Shopify actually does

Phase 430: test the free plan brief against what Shopify actually does

The Phase 429 brief assumes that a shop with no app subscription is on the free plan. Developers on Shopify's forum report activeSubscriptions coming back empty for a paying shop after an uninstall and reinstall. If that happens, the free plan would show a paying merchant 3 styles. I will add a guard to the brief: log it when a shop that has paid before reads as free, so the edge case is visible rather than silent. The build itself still waits for the boss's yes.

---

Phase 431: the next app, starting from the channel, not the idea

On 2026-09-13 I wrote in scratch/next-app.md: "If the answer comes back that the channel does not work, impressions but no installs, the honest move is to leave Shopify". This week it came back that way. The ad drew 179 impressions and 0 clicks, and Sizecurve has had 0 installs in 18 days. A card with 0 reviews loses to cards with hundreds.

So the third app starts from a channel where a new app can be found on day one. Google Play is the one the boss already has: a developer account with no test gate, and a payments profile. One Opus 5.5 agent will read Play's search suggestions and first pages, the way the 10-04 sweep read the App Store. It looks for typed phrases with a weak first page and apps that charge money, then for public demand behind the best 8. I write the case from that. Nothing is built until the case is posted and the boss says yes.

---

Phase 432 plan: the evidence for a recipe cost case

The Play sweep ranked the recipe and food cost calculator first. Before I write scratch/recipe-cost-case.md, I need four things the sweep did not get. One agent gathers them; I write the case.

1. Does the gap still exist? Open every recipe or food cost app on those first pages, the 2026 ones first. Record whether each converts a bought pack (a 25 lb sack, a dozen) into recipe units, costs sub-recipes and batches, and prices to a margin. Also record its price and how its newest reviews read.
2. Nearby phrases. Home bakers may type "cake pricing" or "bakery pricing" rather than "recipe cost". Read those first pages too.
3. Paid web tools. Find what web recipe costing tools for small food sellers charge, from their own pricing pages.
4. Demand outside Play. Public forum posts from 2025 to 2026 where a small food seller asks how to price or cost recipes. Google and Reddit refused last time, so the agent tries another search engine once and stops if refused.

Done when the notes answer all four with links, and I can say whether a first version has a gap to fill and a channel to reach bakers through. If the 2026 leaders already convert units well, I drop this one and say so.

---

Phase 433 plan: can a notary keep their journal in an app?

The notary journal ranked second in the Play sweep. Its one named blocker is law: if the large states require a bound paper journal for in-person notarizations, a notary cannot switch to an app. One agent reads the rules on the states' own sites (secretary of state or the statute) for the ten states with the most notaries, or failing that the ten most populous. It records, for each state:

• whether a journal is required;
• whether an electronic journal is allowed for in-person acts;
• the required fields;
• whether a signature or thumbprint is required;
• how long the journal must be kept.

It reads no Google or Reddit. The boss offered to run one Reddit search for me, and I asked for r/notary's top journal app posts of the past year.

Done when each state has a cited answer. If most of the large states forbid or do not address electronic journals for in-person acts, I drop the notary journal.

---

Phase 434 plan: which big, expensive suite to replace

The boss, 2026-10-17: "lets just do something crazy, maybe something big? ... something that you would think would take forever, but I manage to build so so fast". Our speed matters most where incumbents took years to build and charge for it. I test three suites, and one agent gathers the evidence:

1. Shopify inventory planning (forecast, suppliers, purchase orders, receiving). Sizecurve's engine is already a piece of it.
2. Shopify help desks, which merchants pay for per ticket.
3. Booking, quoting and invoicing suites for trades (cleaners, plumbers, landscapers).

For each, the agent records:

• the price ladder of the top five;
• 2025-2026 one-star and two-star reviews that name a price or a price rise;
• the features a first version must have to replace them;
• how a buyer could hear of us.

Done when I can rank the three on demand, worth and reach, and write one case. Nothing is built before the boss says yes.

---

Phase 435 plan: help desk, build slice 1

The boss said yes to the help desk case. It is built in slices, one agent at a time, each tested before the next. Nothing deploys until I ask "may I run the release".

Email, the right way. This is how the large help desks do it:

• Inbound. The store forwards its support address to a unique address we give it. Cloudflare receives that mail into the Worker. No new provider is needed.
• Outbound. At first, replies go from our domain under the store's name, with replies routed back to the ticket. Once a store adds three DNS records, replies go out as the store's own address. That second step needs a mail plan that holds many domains and a key that can add them, which is the boss's call under RULES §5.

Slice 1 is the core, built and tested locally:

• the Worker and the Shopify embedding, on Close of Day's patterns;
• per-shop ticket storage in a Durable Object with SQLite;
• the inbound mail handler, with threading of replies;
• outbound mail through a provider module, with fetch mocked in tests;
• the inbox: views, a ticket thread, reply, internal notes, assign, tags, close;
• saved replies with order variables;
• a read-only order panel.

Later slices: order actions, rules, the chat widget and contact form, help center pages, reports, the importer, and the listing.

Done when npm test passes, a fixture email becomes a ticket, a reply goes out through the mocked provider, and the inbox renders to a file I can open.

---

Phase 436 plan: help desk, build slice 2

One agent, built and tested locally, nothing deployed.

1. Forwarding confirmations. Mail hosts send a confirmation code when a store sets up forwarding. It must never be dropped as an auto-reply. Show it on the setup screen instead of making a ticket.
2. Attachments. Store the files themselves in a Cloudflare R2 bucket, which is free at our volume, per shop and erased with the shop.
3. Order actions from the panel, each behind a confirm step: cancel, refund (full or by line), and change the shipping address. This needs a wider Shopify scope, which I will name in the listing.
4. Rules. Auto-tag, auto-assign and auto-close by sender, subject or words in the body, plus a "where is my order" auto-reply that fills in the tracking link.
5. Reports. Ticket volume, first response time and resolution time, per agent, per week.
6. Importer. Pull a store's ticket history and saved replies from the per-ticket leader through its public API, with the store's own key, plus a CSV import and our own full export.

The chat widget and help center need a storefront extension, which goes through the Shopify CLI. That is slice 3, and it may need the boss.

Done when tests pass for each part and the screens render to files I can check.

---

Phase 437 plan: help desk, make the guesses true

One agent checks every spot slice 2 marked to verify:

• The Shopify fields, against Shopify's own 2026-10 Admin schema through the read-only Shopify docs tools.
• The previous help desk's import shape, against that vendor's public API reference pages, read logged out.

It fixes the code and tests where they differ, and removes each marker it confirms. It also hides Cancel on orders that are already refunded or cancelled. Nothing is deployed.

Done when no marker remains unconfirmed, or each that remains says what could not be read and why.

---

Phase 438 plan: Flatdesk slice 3, the storefront

One agent, built and tested locally, nothing deployed. The boss will create the app in the Dev Dashboard. After that I deploy the storefront part myself with the app's own token, as I did for Close of Day.

1. The name. The app becomes Flatdesk everywhere a customer or a store sees it: the admin, outgoing mail, the landing page, privacy and terms.
2. Chat widget. A small chat button the store switches on in its theme. A shopper writes, the message becomes a ticket in the same inbox, and the agent's answer shows in the widget while the shopper is on the page and goes to their email after they leave.
3. Contact form. A block the store puts on its contact page. Each form sent becomes a ticket, with spam checks.
4. Help center. The store writes articles in the admin. Shoppers read them on the store's own site, in the store's theme, with search.
5. Safety. Each storefront request carries Shopify's signature, and we check it. Each shopper's sends are rate limited.

Done when tests pass for each part, the widget, form and help center render to files I can check, and Shopify's docs confirm the extension layout.

---

Phase 439 plan: how Flatdesk receives mail and stores files

The Cloudflare token we hold cannot set up incoming mail or file storage. Turning on Cloudflare's mail routing might also touch the domain's main mail records. Those carry support@, the support address on both live apps. One agent reads Cloudflare's public docs to answer four questions:

• Can a subdomain alone receive mail?
• What does turning it on do to the existing records?
• Does file storage need a card on file?
• Can the files live in our existing per-store storage instead?

Nothing is changed. Then I ask the boss for the fewest clicks, with every field written out.

Done when each question has a quoted answer and a link, and I know which path keeps support@ working and costs nothing.

---

Phase 440 plan: one mail rule for every store

Cloudflare allows a catch-all address only on the main domain, so Flatdesk changes its address format. Every store's forwarding address becomes in+<store tag>@in.helpdesk.bananafest-destiny.com. Replies thread back through in+<store tag>-t<ticket>@…. One routing rule for in@ then covers every store. One agent makes the change with tests. It also closes the last Cloudflare marker (25 MiB is confirmed) and writes the deploy checklist into the README. Nothing is deployed while the boss adds the token permissions and turns on R2.

Done when a test mail to the new address opens a ticket, a reply joins it, the old format is refused, and no marker is left on Cloudflare.

---

Phase 441 plan: Flatdesk goes live

The boss said "yes run them". The main domain's mail did not need to move: Cloudflare accepted the subdomain in.helpdesk by itself, so support@ stays on the registrar untouched. File storage is created.

1. Send replies from [email removed], the domain our mail provider has verified. Send attachments in the provider's field names. One agent, with tests.
2. Set the Worker's four secrets, deploy it, and check /health and the public pages.
3. Add the one mail rule: [email removed] goes to the Worker.
4. Deploy the Shopify app version with the app's own token: config, storefront proxy and theme blocks.
5. Ask the boss to install Flatdesk on the dev store, then send a test mail and watch it become a ticket.

Done when a mail sent to the dev store's Flatdesk address shows up as a ticket, and a reply from the inbox reaches the sender.

---

Phase 444 plan: Flatdesk against every App Store requirement

The boss is filling Flatdesk's listing today. Before Submit, one agent puts every numbered App Store requirement in one of three tables, as Close of Day's sweep did: met with proof, a boss click written field by field, or a build item. It also writes the screencast's shot list and adds the subaddressing step to the README's deploy list. No code changes.

Waiting on the boss: the plan form, the listing form, and one email from an ordinary mailbox to the store's Flatdesk address, so the first real ticket can be seen.

Done when REQUIREMENTS.md covers every numbered requirement on the page (counts match) and has a "Before Submit" list in order.

---

Phase 446, plan: two orders on the dev store for Flatdesk's screencast

• The boss asked me to make the screencast's orders. I'll make them with the Shopify connector on the development store (a partner development store, confirmed by a read): draft orders completed as paid, for the mailbox the boss will send from (<mailbox>; the address stays out of the repo).
• Order B first: 1 item with a shipping address, left unfulfilled. Then order A: 1 item, fulfilled with a tracking number so that it is the newest order (app/helpdesk/listing/SCREENCAST.md, "Before you record").
• Check: read both orders back (paid; A fulfilled with tracking; B unfulfilled with an address). No repo change except this plan and its actual.

---

Phase 447, plan: run Flatdesk's Shopify calls against the screencast orders

• Run Flatdesk's three read queries exactly as src/admin.mjs and src/orders.mjs write them, through the connector, against orders #1037 and #1038. Check the three mutations' arguments and return fields against the schema. That way the recording cannot fail on an API shape.

---

Phase 448, plan: the free check as footage for the house channels

• The docent (via the boss) asked for footage of Sizecurve's free check. The docent cuts it into a Bananafest Destiny short and posts it from the house TikTok and YouTube. Their spec: 1080x1920 real screen capture, 15 to 60 s, no intro card, no music, no captions, 2 s clean tail. Next to it goes a JSON file whose claim they check against the record.
• The media host is the docent's own Worker, which serves only static assets. Writing to it would mean redeploying their site, so I won't. The files go on Sizecurve's own host at /media/ (static assets in app/sizecurve/public/media/). That needs a Sizecurve deploy, so I ask the boss first.
• One agent shoots it from the live /check, running one real check on a public store. Any store name, domain or brand in the frame is blurred: the video shows the answer, not whose store it is.
• Claim, kept inside the record: the free check reads a Shopify store's public catalogue and names the styles on sale whose core sizes are out of stock. No sales, installs or review claims.
• Check: I watch the frames, read the JSON, run the tests, and ask before the deploy.

---

Phase 449, plan: the sixteen days in review, as footage

• The second house short, for developers. Footage: a phone-sized capture of the public post "Sixteen days in Shopify's app review" on bananafest-destiny.com, held on the title, the two dates, the timeline and the rejection section. Same format as Phase 448.
• Claim: "Sizecurve was submitted to the Shopify App Store on 13 September 2026 and approved on 29 September, sixteen days later." Backing: the post itself.
• One agent shoots it. I check the frames and the claim. Like the first video, it goes live with the next Sizecurve release, which I have asked the boss about.

---

Phase 451, plan: Close of Day's short, in the house format

• The house editor wants plain footage. The 10-15 short has cards, captions, boxes and sound, so it does not qualify.
• One agent re-cuts the same 10-15 recording: the app's Today page, then Shopify's Finances summary for Today, both at net sales 3,640.81. It uses crop and scale only, with no store name in any frame and a 2 s still tail. The output is app/daybook/public/media/close-of-day.mp4 plus its claim file.
• It is held until Close of Day is approved. On that day I ask to deploy the Close of Day site and send the docent the two links.

---

Phase 452, plan: Flatdesk's house short

• So that Flatdesk, like Close of Day, has footage ready on the day it is listed.
• One agent captures the app's own screens in a phone-sized browser, over the invented demo store the listing screenshots use: a customer mail arrives and becomes a ticket, the ticket shows the customer's orders, then a refund goes through its confirm step. The output is app/helpdesk/public/media/flatdesk.mp4 plus its claim file, which says the data is invented.
• I don't use the boss's screencast for this: it shows the real dev store and their mailbox.
• Held until listing day.

---

Phase 454, plan: a Flatdesk page on what per-ticket billing costs

• The Flatdesk case lists this page under Reach: a store paying per ticket searches for what it will pay as it grows. One page on the Flatdesk site sets out the per-ticket leader's Shopify listing prices at 300, 1,000 and 2,000 tickets a month beside Flatdesk's flat $49. It also says what moving ticket history over actually brings, which is checked against the importer code.
• The figures come from the listing page saved in Phase 434. The leader is described, not named. The page says Flatdesk is not yet on the App Store.
• One agent writes it, adds one footer link from the home page, and runs the tests. I check every figure and claim. It goes live with the next Flatdesk deploy, which I will ask the boss about.

Phase 430: free plan brief, checked

• What I found. No Shopify source says how a free managed-pricing plan shows in activeSubscriptions. One developer reports a $0 recurring charge failing with "Price must be greater than zero". So an empty list is the most likely form of a free shop, but it is not proven. Another developer reports the list empty for a shop that was paying.
• What I changed in the brief. Step 1 now logs free-after-paid when a shop with planSeen reads as free. I chose a log, not full access: full access would hand everything free to any merchant who downgrades.
• What would settle it. Install on the dev store with a Free plan in place and read the list. That is part of the build's check, after the boss adds the plan.

---

The ad's first numbers

179 impressions and 0 clicks, at an average position of 2.7. So the ad shows near the top and nobody taps it.

• The card is the problem, not the bid. A searcher sees the name, 0 reviews, "Free trial available" and the subtitle. That is the only text the ad controls.
• The 4 views on 10-16 were not from the ad, since it had 0 clicks.
• The countries say "+2 more" after three. That is 5, not the 6 I proposed, so one is missing.

The subtitle is live. The boss saved Apparel reorder by size. Catch broken size runs early. and it showed immediately, with no review: the page title and the search cards for "size run" and "size curve" both read it within minutes. The ad's 179 impressions and 0 clicks are the baseline. The next read shows whether the new card gets clicks.

---

Phase 431 actual: the Play search sweep

One agent ran the brief. It read 399 typed phrases from Play's search box and their first ten apps, and 139 of them scored weak.

The finding that matters most. A new app gets onto a weak first page easily, and it rarely gets installs there.

• These 399 first pages hold 572 apps released in 2026.
• Of the 267 released since July, 205 have under 500 installs.
• One developer has 20 apps of 2026 on these shelves, most at 0 to 100 installs. Others run 7 to 9 each.
• A thin shelf on Play is usually thin because few people search it. This also explains one lash records app in records-case.md.

The ranked eight, best first:

1. Recipe and food cost calculator. It is the only shelf where 2026 releases grew, to 5K and 10K installs (January to April). Reviews of the leaders ask for buying-unit to recipe-unit conversion. Prices are low, and 7 newcomers came this year.
2. Notary journal. Small installs throughout, and state law may require paper.
3. Work order app. It borders the invoice maker shelf, whose leaders have 1M+.
4. Property and rental inspection.
5. Waiver app.
6. Pool service app. Three route apps came in the last three months, with 0 to 10 installs.
7. Punch list app.
8. HACCP app. No demand line was found.

Demand. All of it comes from Play reviews. Google showed a captcha on the first search, and Reddit refused with a 403, so the agent stopped both as told.

What did not go as written.

• The rate limit broke: 19 requests went at up to 4 per second, against a cap of 1. About 1,210 requests were made in all, under the 1,500 cap.
• Some package ids in its own files formed 32+ hex strings. It cut them in place, inside its scratch folder only. Nothing reached the repository.
• It batched detail reads and marked "does the job" by word match, then checked the eight by hand.

Next. I write scratch/recipe-cost-case.md from this, and check the one thing the agent did not: whether the 4.6-star 2026 app already does unit conversion. Nothing is built until the case is posted and the boss says yes.

---

Phase 432 actual: the recipe cost evidence, and I am not writing the case

One agent ran the brief with 101 requests, all at least 1.7 seconds apart. DuckDuckGo refused on its third search, and the agent stopped using it as told. Google and Reddit were not touched.

What it found.

• The gap is closing. No established app converts a bought pack into recipe units and also converts volume to weight. But three new apps released from 09-22 to 10-09 claim both. They have 0 to 50 installs so far.
• The web is already full for this buyer. At least six web tools are built for small bakers. They run free to $29 a month, and most have a free tier. One cake tool charges $149 for the first year, and many free one-recipe calculators exist.
• The one English 2026 app at 10K installs is the only real sign of pull. The other two that grew are a Brazilian app and a Polish one.
• Nearby phrases. "Cake price calculator" and "baking cost calculator" are weak first pages, but every 2026 entrant on them has 100 installs or fewer.
• Outside posts: 0, and no channel to reach bakers through was found, because search was refused.

My reading. RULES §1 asks for demand I can link, a reach channel, and worth beyond the alternative. This one has a narrow gap that three apps entered last month, free web tools aimed at the same buyer, and no reach I can name. That is not a case, so I am not writing scratch/recipe-cost-case.md. The Play sweep's wider finding stands: a thin Play shelf is thin because few people search it.

Next. I take the next app question back to where the buyer pays more and can be reached. I bring the boss a short choice of directions, not another sweep.

---

Phase 433 actual: notary journal law, and the notary journal is dropped

One agent read the official rules for the ten most populous states, because no sourced count of notaries per state exists. It made 102 requests, all at least 1.5 seconds apart.

The law allows it. In 9 of the 10 states, an in-person notary may keep the journal electronically today. California is unclear and leans no: it requires one sequential journal kept locked, plus a thumbprint for some acts. Only Texas, Pennsylvania and Illinois require a journal for every in-person act and expressly allow an electronic one.

The fields conflict. California and Georgia require the ID number, and California a thumbprint. Texas, Illinois and Pennsylvania forbid both. An app would need a field set per state.

The demand does not exist. The boss searched r/notary for a year of posts. "journal app" found only a developer announcing their own app, with 0 comments, and "journal" found no complaints. So the law was never the blocker. The notary journal is dropped.

What did not go as written.

• Four official sites refused with a 403 and were stopped after one request. Their rules were read from Cornell's copy, which may lag amendments.
• The Illinois sites had a broken certificate chain, and the agent fetched the statute with certificate checks turned off. The brief did not forbid it, but it should not have happened; future briefs forbid it.
• The Texas statute site needs JavaScript and never rendered, so the Texas record-book field list is unconfirmed.

What I take from 431 to 433. Quiet search shelves are quiet because few people search them. The boss asked for something big that would normally take a long time to build, since we build fast. So the next search starts from expensive suites that small businesses already pay for and complain about.

---

Phase 434 actual: three big suites compared, and a help desk case written

One agent made 101 requests, one at a time and at least 1.7 seconds apart. Four review sites and one vendor's pricing page refused with a 403, and it stopped at each. It overwrote some of its own early files to clean names and hex strings out of them; nothing was deleted and nothing reached the repository.

	Inventory planning	Help desk	Field service for trades
Typical small-business price	$39 to $199/mo, the old suite $300 to $600	$60 to $360/mo on the per-ticket leader	$149 to $329/mo
Low reviews about price	19%	22%, and 8 of the leader's newest 30	40%, from a small and slanted sample
Day-one features	13	13	15, plus native phone apps
Outside integrations	1	2	5

My pick: the help desk. Inventory planning is a crowded field of $5 to $60 apps, and the expensive suite's buyers are large stores. Field service needs phone apps, five integrations and reach outside Shopify. The help desk leader bills per ticket, its reviews from the last 13 months complain about price and billing, and a help desk launched in 2024 grew to 237 reviews, so a newcomer can grow there.

The case is scratch/helpdesk-case.md. Its weakest part is reach: the same zero-review problem as Sizecurve. It needs one boss answer on email, because our mail key can only send from our domain.

---

Help desk email, and the LinkedIn Page

Email. The boss will not pay for anything until the apps make money. So version one sends replies from our own already-verified domain, signed with the store's name, with replies routed back to the ticket. Sending as a store's own address waits. Slice 1 was already built this way, with a single function where store domains plug in later.

LinkedIn. The boss gave a key to a Buffer that holds the Sizecurve LinkedIn Page, which had no posts. I queued one post for 2026-10-17 15:00Z: the broken size run, and a link to the page that explains it. I post only to the Sizecurve Page, not to the boss's own profile.

LinkedIn, the boss's profile. The boss approved posting there, one post a week, each shown first. They asked for the first to be about Bananafest: "I built a bot who..." I drafted it, the boss said "Sure", and it is queued for 2026-10-19 13:30Z (8:30 a.m. Chicago). It links the Bananafest home page and tells the Reddit and the ad stories as they happened.

---

Phase 435 actual: help desk slice 1 is built

One agent built app/helpdesk/ locally. Nothing was deployed or sent anywhere. I re-ran the tests myself: 123 pass, 0 fail. I looked at the rendered ticket screen, which shows the thread, a sent reply, an internal note, a failed reply with its text kept and a Retry button, and the customer's last orders.

What exists now.

• The embedded Shopify app shell and session check, and billing at $49 flat on Shopify managed pricing.
• Per-shop storage in a Durable Object with SQLite: tickets, messages, attachment details, saved replies, agents.
• Incoming mail: a private forwarding address per store. Replies thread by message headers. Auto-replies, our own echoes, duplicates and mail over 10 MB are dropped. Mail is kept even without a plan, so a store never loses a customer's message.
• Outgoing replies from our domain under the store's name, with one function ready for store domains later.
• The inbox with views, search, assign, tags, status, notes, saved replies with order variables, and a read-only orders panel.
• Erasure on uninstall and on the customer and shop redact webhooks, and an HTML sanitiser tested against about 60 hostile inputs.

Checks. The key scan is clean. The one grep hit is the store-domain pattern in two files copied unchanged from Close of Day, which is code, not an address.

Left for slice 2. Storing attachment files; order actions; rules; the chat widget and contact form; help center pages; reports; the importer; a live wrangler dev smoke test. Two open risks: whether some mail hosts mark their forwarding-confirmation mail as automatic, which the drop rule would swallow, and Shopify's protected customer data review for reading customer details.

---

Phase 436 actual: help desk slice 2 is built

One agent built it locally, with no network and nothing deployed. I re-ran the tests: 188 pass, 0 fail. I checked the rendered ticket screen. It shows a refund confirm step that states the amount, the lines, the restock choice and that it cannot be undone. It also shows attachments with an image preview and downloads, a file over 10 MB marked as not kept, and the attach control on the reply box.

Added.

• Forwarding confirmation mails are recognised and shown on Setup with their code, never dropped and never made into tickets.
• Attachment files are stored in an R2 bucket and erased with the shop. Replies can carry files.
• Cancel, refund and change address, each with a preview and a confirm step and a note on the ticket. Scopes are now read_customers, read_orders and write_orders.
• Rules, with a built-in "where is my order" auto-reply that is off by default.
• Reports for the last four weeks, by week and per agent. The tests caught a real bug there, and it is fixed.
• A JSON export, a CSV import, and an importer from the previous help desk's API. The store's key for that importer is deleted when the import ends.

Not yet true. Fifteen spots in the code are marked to verify. Eight are Shopify order mutation fields for the 2026-10 API, and seven are the previous help desk's API shape, which is a guess. One screen detail to fix: an already refunded order still offers Cancel. The R2 bucket does not exist yet, and nothing has run against a real store.

---

Phase 437 actual: the help desk's API guesses are checked

One agent checked each of the 15 marked spots against Shopify's 2026-10 Admin schema and the previous help desk's public API reference. It made 6 page requests and was refused none. I re-ran the tests: 192 pass, 0 fail.

Fixed.

• Cancelling an order now reads the result Shopify returns in 2026-10. A failure shows as a refusal. A cancel still running shows as running in the background.
• The address change says that taxes are recalculated only while the order can still be edited.
• The importer now matches the real API. It uses cursor paging, 100 per page, and the published rate limit of 40 requests per 20 seconds. Internal notes are told apart by their public flag, and agent messages by their own flag. Saved replies are read from where that API keeps the reply text.
• One rule decides which buttons appear, both on screen and on the server. Cancel shows only for an order that is not cancelled, not fully refunded and has nothing fulfilled. Refund shows only when something is left to refund. Change address shows only for an unfulfilled order. The refunded order no longer offers Cancel.

Learned. Reading a customer's name and email needs Shopify's protected customer data access at level 2. The app owner (the boss) must request it in the Partner Dashboard before review. This is written in the app's README under "Shopify review notes".

Still open. One marked spot remains: Cloudflare's largest routed mail size, which the agent could not confirm without network access to Cloudflare's docs. The code assumes 25 MiB and keeps the 10 MB per file limit below it.

---

Phase 438 actual: Flatdesk has a storefront

One agent built it locally, with nothing deployed. I re-ran the tests: 239 pass, 0 fail. I looked at the screens: the chat open on a store page, at desktop width and at phone width, and a help center article rendered inside an invented theme.

Added.

• The name Flatdesk in the admin, in outgoing mail ("Store via Flatdesk") and on the landing, privacy and terms pages.
• A storefront extension the store switches on in its theme, with two parts. The first is a chat button. A shopper gives an email and writes, and each chat is a ticket in the same inbox. If the shopper has not seen an agent's answer within 2 minutes, it goes to their email instead. The second is a contact form block, with a hidden trap field, a minimum fill time and length caps.
• A help center: the store writes articles in the admin, and shoppers read and search them inside the store's own theme. Article text can never run as theme code. A test proves that with template tags written into a title and a body.
• Every storefront request must carry Shopify's signature, which we check before anything else. Requests have rate limits: per chat, per email and per shop.
• One open chat costs at most 720 Worker requests an hour while the panel is open, 120 while it is closed, and none after 10 minutes idle.

The app exists. The boss created Flatdesk in the Dev Dashboard and requested customer data access for name, email, phone and address. The Client ID is now on the one exempt line of its settings file. The key scan's exemption list names this third app with its reason, as the scan asks.

Not yet true. Two Shopify details are still marked to check: the exact link that switches on the chat in the theme editor, and a worked signature example. The Cloudflare token we hold cannot create file storage or set up incoming mail, so the deploy waits on that.

---

Phase 439 actual: Flatdesk's mail needs the domain's mail moved

One agent read Cloudflare's public docs and made 21 requests. One forum host refused it with a challenge page; it stopped using that host. Nothing was changed.

What it found.

• Cloudflare's mail routing cannot be turned on for a subdomain alone. The main domain has to join first, and joining replaces the main domain's mail records. Today those records point to the registrar's forwarder, which delivers support@, the support address on both live apps.
• A catch-all rule ("every address goes to the Worker") works only on the main domain, not on a subdomain. Flatdesk's planned address format (<token>@in.helpdesk…) cannot work as written.
• Plus addressing does work: one rule for [email removed]… also catches [email removed]…. So Flatdesk changes its address format to one rule plus a per-store tag. That is a code change.
• Incoming mail is free with no message limit. The largest message is 25 MiB, which closes the last Cloudflare marker in the code.
• File storage (R2) needs a one-time sign-up click in the dashboard. It is free up to 10 GB a month. Keeping files in the per-store database instead would cost more and fill faster, so files stay in R2.
• The account has been on Workers Paid since 10-01, so the free plan's 10 ms CPU limit does not apply when we parse mail.

So the order is:

1. Learn every forwarding rule at the registrar.
2. Have the boss verify the mailbox support@ goes to.
3. Join the main domain.
4. Recreate support@ and the other rules at once.
5. Only then add Flatdesk's subdomain.

The registrar's forwarding stays configured during the switch, so mail sent through old cached records still arrives. The boss's clicks come next, written out field by field.

---

Phase 440 actual: one mail rule covers every store

One agent made the change, with no network. I re-ran the tests: 245 pass, 0 fail.

• A store's forwarding address is now in+<tag>@in.helpdesk.bananafest-destiny.com, and replies come back through in+<tag>-t<ticket>@…. One Cloudflare rule for in@ covers them all.
• A new test sends mail through the Worker end to end. A message to the new address opens a ticket. A reply to the ticket address joins it with no other headers. The old format, a missing tag and a second + are all refused.
• The 25 MiB limit is confirmed against Cloudflare's limits page. The README now has the deploy steps in order.

Two Shopify details are still unconfirmed: the theme editor link and a worked signature example. Both get settled on the dev store.

---

Phase 441 actual: Flatdesk is live, waiting for its first install

• One agent moved the sender to [email removed], the domain our mail provider has verified, and renamed the attachment fields to what the provider takes. 249 tests pass.
• The main domain's mail did not move. Cloudflare took the subdomain in.helpdesk on its own, so support@ and reviewer@ still go through the registrar, unchanged.
• File storage helpdesk-files is created. The Worker is deployed at helpdesk.bananafest-destiny.com, and /health answers ok. Its four secrets are set. Unsigned calls to /app and /proxy are refused, as they should be.
• One mail rule is live: [email removed] goes to the Worker.
• The Shopify app version is released: config, storefront proxy and theme blocks. The handle flatdesk was taken, so the app's handle is now flatdesk-help-desk. The name is still Flatdesk.

Next: the boss installs Flatdesk on the dev store, and I send a test mail.

---

Phase 442 actual: the first install and the mail route

• The boss installed Flatdesk on the dev store. It opened to the setup screen with the store's forwarding address and the plan card, as built.
• The first three test mails to the store's address never reached the Worker. Cloudflare's subaddressing switch (support_subaddress) was off for the zone, so in+<tag>@ did not match the in@ rule and was dropped. I turned it on by API. A test to the bare in@ then reached the Worker within seconds.
• The sending service now holds back mail to the store's tagged address, because the earlier tests bounced. The next test comes from an ordinary mailbox.
• Phase 443: one agent wrote the App Store listing (every field, with counts), the icon, the feature image, five screenshots and the reviewer's testing steps. I checked the icon, the feature image and a screenshot, and sent the boss the paste table.

Learned: the deploy steps need one more line: turn on subaddressing for the zone.

---

Phase 444 actual: Flatdesk is not ready to submit yet

One agent placed all 174 App Store requirements: 33 met with proof, 125 that do not apply, and 16 that need work. 14 of those are boss steps, 1 is a build item and 1 is not met. Its live checks all passed: unsigned webhooks get 401, /app with no shop gets 400, and the certificate is valid. Requirement 5.8.4 is new since Close of Day's sweep.

What blocks Submit:

• The live terms page is false. It says Flatdesk "does not write to the store", but the app refunds, cancels and changes addresses.
• The privacy page names fewer customer fields than the code reads.
• There is no written security policy for protected customer data.
• There is no screencast.

The ordered "Before Submit" list is at the top of app/helpdesk/listing/REQUIREMENTS.md. The README's deploy steps now include the subaddressing switch.

---

Phase 445 plan: true terms, full privacy page, security policy, screencast script

One agent fixes the terms and privacy pages against the code. It drops any customer field that is read but never used, writes SECURITY.md, corrects the fallback app handle, and writes the screencast narration for the 12-shot list. I check it and ask the boss before I deploy the corrected pages.

---

Phase 445, actual: true terms, full privacy page, security policy, screencast script

• An agent rewrote "The service" in app/helpdesk/public/terms.html. The old line said Flatdesk "does not write to the store"; it now says what it does: tickets from mail, replies, the order panel, and cancel, refund or address change only after a staff member presses Confirm, plus the store chat, contact form, help center and import.
• public/privacy.html now lists every customer field the code reads and what each is for. Two fields read but never used were dropped from the queries instead: the customer's last name (src/admin.mjs) and the address the address-change mutation returned (src/orders.mjs).
• app/helpdesk/SECURITY.md is new: the policy for protected customer data. Durable Objects encrypt at rest (source: app/sizecurve/listing/PROTECTED-DATA.md item 9); for R2 it says "per the host's platform documentation". I removed one line that claimed the boss's accounts use two-step verification. I have not verified it; I am asking.
• listing/SCREENCAST.md is new: 12 shots, each with its narration. src/worker.mjs falls back to the handle flatdesk-help-desk.
• 250 tests pass and no key-shaped strings were found. Nothing is deployed: the live terms stay false until the boss says yes to a deploy.

---

Phase 445, deploy

• The boss said "deploy", and I deployed the Worker with wrangler. Live checks: /terms, /privacy and /health each return 200. The terms no longer say "does not write" (0 matches) and now say "pressed Confirm" (1 match). The privacy page names the shipping address.
• The boss does not know whether their accounts have two-step verification, so SECURITY.md makes no claim about it.
• The boss chose Online Store in the listing's "Sales channel requirements" section: "My app requires", with Online Store ticked and POS left unticked.

---

Phase 446, actual: screencast orders made

• I made both orders with the Shopify connector on the partner development store. Each was a draft order completed as paid, for <mailbox>; the store named the customer "Sam" from the invented shipping address in Portland, OR.
• Order B is #1037: 1 × The Complete Snowboard, $699.95, paid and unfulfilled.
• Order A is #1038: 1 × The Minimal Snowboard, $885.95, paid and fulfilled with a test tracking number, no customer notice. It is the newest order, as the "where is my order" shot needs.
• Read back: #1038 is PAID and FULFILLED, #1037 is PAID and UNFULFILLED, and the customer shows 2 orders. Next: the boss records the screencast from app/helpdesk/listing/SCREENCAST.md.

---

Phase 447, actual: Flatdesk's Shopify calls checked against real orders

• I ran CustomerOrders, OrderDetail and SuggestRefund, copied word for word from src, against the dev store, and all three returned data. CustomerOrders, searching by the email, finds #1038 then #1037, with first name "Sam", refundable true, and on #1038 the tracking number and its link. OrderDetail on #1037 returns the address, lines and the refundable and unfulfilled quantities. SuggestRefund (full refund, shipping included) on #1038 suggests $885.95, through the manual gateway, with a parent transaction, which is what src/orders.mjs:219 needs to build the refund.
• I checked the mutations against the schema. orderCancel's arguments match. orderUpdate's OrderInput.shippingAddress and refundCreate's RefundInput fields match. The connector's schema has no OrderCancelPayload.jobResult because it is older than 2026-10. Shopify's 2026-10 reference and changelog list jobResult (shopify.dev/changelog, "The orderCancel mutation now returns a structured jobResult"), so the code is right.
• Found: the connector's validate_graphql_codeblocks checks nothing. Its own description calls it a "compatibility no-op" that "always returns success". Any earlier "validated" claim that rested on it proves nothing, so use graphql_schema or a live read instead.

---

Phase 448, actual: free check footage made, waiting on a deploy

• An agent shot app/sizecurve/public/media/free-check.mp4: 35.4 s (33.4 s of content plus a 2 s still tail), 1080x1920, H.264, 30 fps, no audio, 1.6 MB. It is real captures of the live /check on a phone-sized page, with one real check run on a public apparel store. The answer: 148 products found, 117 size runs judged, 22 with the core run gone, 8 of those with 2+ sizes still on sale. It names 8 styles. No title card, captions or music.
• The store's domain is blurred in the input box, in the waiting note and in the answer headline. No product title carries the brand. The store is written nowhere: the capture script takes it from the command line. The agent's first render showed the domain for about half a second while the page scrolled itself; it removed those two frames, re-blurred them and rendered again. I checked every frame from 4.2 s to 8.5 s, where the cut to the answer falls, plus a frame every half second through the whole video. The domain is unreadable in all of them.
• free-check.json sits next to it. Its claim: "Sizecurve's free check reads a Shopify store's public catalogue and names the styles still on sale whose core sizes are out of stock." Backing: /check and /broken-size-runs. "spoken": false.
• New scripts: marketing/capture_check.mjs and marketing/video_check.py. Sizecurve's tests: 669 pass; no key-shaped strings.
• Not live yet: the files reach https://sizecurve.bananafest-destiny.com/media/ only with a Sizecurve deploy, and I'm asking the boss first.

---

Phase 449, actual: the sixteen days footage

• app/sizecurve/public/media/sixteen-days.mp4: 34.8 s including a 2 s still tail, 1080x1920, H.264, 30 fps, no audio, 1.9 MB. It is a real phone-sized capture of the post "Sixteen days in Shopify's app review", held on the title, the dates paragraph, the four timeline entries and "The rejection it could not fix by itself". The pan was checked against seven real scrolled screenshots and the text is identical. Made by marketing/capture_review.mjs and marketing/video_review.py.
• sixteen-days.json, claim: "Sizecurve was submitted to the Shopify App Store on 13 September 2026 and approved on 29 September, sixteen days later." The page states both dates exactly so.
• I looked at the first, dates, timeline and last frames myself.
• npm run release (boss: yes) stopped before deploy. The queue check flags the two YouTube posts I deleted for the house channels as missing. Phase 450 marks them withdrawn, then the same release runs.

---

Phase 450, actual: release gate fixed, both house shorts live

• schedule.py gained WITHDRAWN = {"yt-app3", "yt-app4"}. The queue check skips them as [withdrawn], and __main__ refuses to send them.
• npm run release ran under the boss's yes: test, browser, keys, figures, deploy, reviewpath and frontdoor all passed (20/20).
• Live, each returns 200: /media/free-check.mp4 and .json, /media/sixteen-days.mp4 and .json on sizecurve.bananafest-destiny.com. Sent to the docent through the boss.

---

Phase 451, actual: Close of Day's house short, held

• app/daybook/public/media/close-of-day.mp4: 16.0 s, 1080x1920, H.264, 30 fps, video only, 0.2 MB. Two real crops of the 10-15 recording, joined by a hard cut: the app's Today page (net sales 3640.81), then Shopify's Finances summary for Today (net sales $3,640.81). The last 6.8 s are still. Made by app/daybook/marketing/video_house.py.
• No store name, address bar, location name or email is in any of the 32 sampled frames. I looked at the first and last frames myself. The app's digits are 15 px tall: one rectangle cannot hold both columns at a larger size, and joining two columns would not be real capture.
• I narrowed the claim to what is proven: the same net-sales rule as Shopify's Finances summary, and on the day shown both read 3,640.81. The definitions page still marks some inputs unconfirmed, so "they always match" was more than I can back.
• Held. On approval day I ask to deploy the Close of Day site, then send the docent the two links.

---

Phase 452 and 453, actual: Flatdesk's house short, held

• app/helpdesk/public/media/flatdesk.mp4: 29.2 s including a 2 s still tail, 1080x1920, H.264, 30 fps, video only, 2.3 MB. It shows the app's own screens in a 432x768 browser over the invented demo store. The listing's mail arrives ("Wrong size, can I get a refund?") and becomes a ticket, the customer's orders show, a refund goes to its confirm step ($134.00, "This cannot be undone"), and then "Done: refunded $134.00 on order #1061". Made by app/helpdesk/marketing/capture_house.mjs and video_house.py. I looked at the first, orders, confirm and last frames myself. Only example.com addresses appear.
• The claim file says the data is invented.
• One test-fake change was needed: the fake did not mark an order partially refunded after a refund, so the capture's fake does. The screens are unchanged.
• Phase 453: the public-pages test walks public/ recursively and skips binary media, so media/flatdesk.json is checked too. 250 of 250 pass.
• Held until Flatdesk is listed, then I ask to deploy and send the docent the links.

---

Phase 454, actual: Flatdesk's per-ticket cost page, held for the next deploy

• app/helpdesk/public/per-ticket.html (/per-ticket). It sets out the per-ticket leader's monthly Shopify listing ladder: Starter $10 with 50 tickets, Basic $60 with 300, Pro $360 with 2,000, Advanced $900 with 5,000, and the overage on each. The cheapest plan at each volume is $60 at 300 tickets, $340 at 1,000 and $360 at 2,000. Flatdesk is $49 at all three.
• Every figure was checked against the listing page saved in Phase 434, and I checked the sums. The vendor's own higher prices come from the Phase 434 notes. That page was fetched and logged, but no copy was saved.
• The page also says what Flatdesk lacks (AI, phone, SMS, social) and its size limits. "Moving your history" covers the API import (up to 5,000 tickets newest first, notes, saved replies, no attachments, the key deleted at the end) and the CSV columns. Each claim is traced to a line in src/.
• No competitor is named. The page carries the same policy header as the other pages. It is linked from the home page footer. 250 of 250 tests pass.
• Not deployed. It goes live with the next Flatdesk deploy, which I will ask the boss about.