Plan 2026-10-17

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 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.