Plan 499 — morning reads

Plan 499 — morning reads

One agent, read only: the five LinkedIn posts' numbers (Buffer), every dev.to article's views and reactions (the 10-20 rescan article first), and /api/views for the kill line and any dev.to or LinkedIn referrer on 10-20 and 10-21. Sizecurve needs 2 more engaged views by 10-27.

---

Plan 500 — the bar for the next case

From 10-20 (the boss: "Back links are the hard part"; "If it did we would have back links already"): every new case must now name how buyers find it, before demand and worth:

1. a word buyers already type that the incumbents do not own (shown without reading App Store search pages, which robots.txt forbids), or
2. a place where buyers already ask for it in public, and where we may answer; or
3. a channel we already have that reaches them.

A case with none of the three fails at Reach, however good the product. And the test the boss gave: if the idea worked, would it already have worked for us?

---

Plan 501 — stop search reads in code; sweep the Community for doors

One agent, two parts. (1) app/sizecurve/tools/rank.mjs refuses every App Store search read before any network call, citing robots.txt Disallow: *q=*, with a test that it does not fetch; npm test before and after. (2) A reach-first sweep of Shopify Community threads created 10-02 to 10-21 (robots.txt obeyed, no q= reads, at most 200 requests): keep threads with 100+ views or 5+ replies, group them into needs, and mark a need a door only if merchants ask more than once (or 500+ views), replies offer nothing cheap and good, and a small app could do it. Each door gets its shelf and how a buyer would find us. Notes only; I write any case.

---

Plan 503 — what gets a new app its first reviews

All three Community doors already have exact-fit 2026 apps with 0–2 reviews, and so does Sizecurve. Before the next case I need to know what the new apps that did get reviews have in common. One agent reads App Store category pages sorted by newest, and the listings of about 120 apps launched 2026-01 to 2026-07. It uses only the pages robots.txt allows: no q=, nothing under /internal/ or /services/. For each app it records reviews, months live, free plan, price, Built for Shopify, how many other apps the developer has, languages, and whether the name is a plain job word. Then it compares the apps with 5+ reviews to those with 0. This tests Plan 500 route 3 (a channel we have): if apps from developers with several apps get reviews and lone apps don't, our three apps can point to each other.

---

Plan 504 — duties with a start date, and no app yet

Phase 503 found that the one 2026 app over 5 reviews a month answered an EU duty with a start date. One agent lists the legal duties that bind small online shops and start between 2026-11 and 2027-12, in the EU, UK, US states, Canada and Australia. For each it records:

• the source text;
• the start date;
• what a shop must show or do;
• whether a theme, a checkout or an app is the natural fix;
• the shelf, from listing pages and web search (no q=), giving the closest apps with reviews, launch date and price.

The AU drip rule is already parked (memory, 11-04 check), so the agent only notes it. The output is notes only; any case is mine.

---

Plan 505 — dated duties beyond shops

Phase 504 found no shop duty worth a case. The boss allows any web app (10-02). One agent lists duties with a start date between 2026-12 and 2027-12 that bind small businesses of any kind in the US, the UK, the EU, Canada and Australia, where a small web tool is the natural fix. Examples: employers, landlords, contractors, clinics, food businesses, trades. A duty counts only if it adds a thing the business must keep doing (LEARNED 10-13), has no size floor that leaves small firms out, and needs no certified product or new commercial account (RULES §5). For each, the agent records the search words the duty creates and where those businesses already gather. Notes only; any case is mine.

---

Plan 506 — visitor levy: reach and route

Before a case for a UK visitor-levy tool for small hosts, one agent reads seven things:

1. who ranks today for the levy words (calculator, return, record keeping), by web search;
2. what the national portals take in (Scotland's visitorlevy.scot, Wales's WRA): upload, CSV, or typing by hand;
3. whether booking platforms collect the levy or plan to;
4. how many providers are registered or bound in Edinburgh, Glasgow, Aberdeen and Wales;
5. what calculators or tools exist now, and any sign that they are used;
6. what hosts ask in public, with dates, since Edinburgh began;
7. the exact rules a tool must get right (rate, cap on nights, exemptions, the room-only split, the provider's retained share).

Notes only.

---

Plan 507 — Flatdesk asks for a review

Phase 503: new apps that got reviews often got them minutes after install, which points to an in-app review request. Sizecurve asks after a purchase-order download, and Close of Day after a finished report. Flatdesk asks nowhere. One agent adds Shopify's App Bridge Reviews API call to Flatdesk's admin at the end of a successful workflow: after a reply to a customer is sent, once per page load, and only from the shop's 3rd sent reply on. It also adds tests. No deploy: it ships with the next Flatdesk deploy, which needs the boss's yes.

---

Plan 508 — Flatdesk asks after the first reply

The boss: 3 replies "could be a while". Phase 503 found that new apps get their reviews minutes after install, so Flatdesk should ask at its first real success: the shop's first sent reply, not its third. One agent changes the threshold from 3 to 1 in the Worker and the page, and updates the tests. No deploy.

---

Plan 509 — market-nana's three messages; Close of Day's to-the-cent proof

Answer market-nana. On size chart and order printer: size chart no, order printer not yet. On the Close of Day checks, say what is proven and what is not. Read the dev store's figures through the connector (ShopifyQL, read only) to see whether a full tie-out is possible yet. Ask the boss two things: one browser print of the Finance summary, and the bench token (Close of Day ask 6), so the tie-out in app/daybook/TIEOUT.md can run before approval day.

---

Plan 510 — order printing: asks, shelf and reach

Close of Day's review timing. Close of Day asks for a review when a report is printed or saved as a CSV or PDF. A shop can do that with Today's figures in its first minutes, so it needs no change like Flatdesk's (Phase 508).

Order printing. market-nana named Shopify's free Order Printer (about 3.6 stars) as the clearest named gap, but the leader has about 3,000 reviews. Under Plan 500 a case starts at Reach. One agent reads, within robots.txt and with no q= reads:

• Community threads from 2025 on about printing orders, invoices and draft orders;
• Order Printer's recent low reviews;
• the 8 closest apps and what each covers;
• what an app may do: attach a PDF to the confirmation email, print draft orders, and any dated B2C invoice duty;
• the words merchants use.

The output is notes only (scratch/orderprint-notes.md).

---

Plan 511 — free plans for Close of Day and Flatdesk

Phase 503 found that the 2026 apps with 5+ reviews more often have a free plan (79% against 61%) and less often a trial (42% against 57%). All three of ours are paid with a trial. I write a split for each app that meets the boss's 10-21 condition (a reason to pay), read Shopify App Pricing's rules on free plans, and put it to the boss. Nothing is built before each app is approved.

---

Plan 513 — what Sizecurve's recent visitors did

Read /api/views and /api/installs.

---

Plan 514 — Close of Day's Community replies, ready for approval day

The 10-03 drafts each end with a listing link, which the 10-15 rule forbids, and their threads may have moved on. One agent:

• re-reads the four threads;
• finds up to 6 newer ones;
• rewrites the replies with no link: an answer first, then a one-line disclosure with the fee;
• checks every claim against the code, including "reaches back 60 days".

Nothing is posted.

Phase 499 — morning reads

• LinkedIn: not read. Buffer answered 401 "Access token is not valid" for .secrets/buffer-linkedin (worked 10-20 in p485; file unchanged since 10-17). No retry, nothing changed in Buffer. A new key is needed from the boss.
• dev.to: the 10-20 rescan article has 0 views and 0 reactions so far. The 09-30 study article has 12 views. Across the account's 32 articles, the best are 85 and 76 views.
• Kill line (05:08Z): 48 of 50 engaged, 2 short, window to 10-27. Nothing added 10-18 to 10-21. On 10-20: direct 17, internal 24, zoo 1; /broken-size-runs 3 hits. No dev.to or linkedin referrer on any day, ever.
• Taken: neither dev.to nor LinkedIn has sent one counted visitor. With 6 days left, the 2 views will come from somewhere we do not control, or not at all.

---

Phase 501 — search reads stopped in code; Community doors swept

One Opus 5.5 agent, 77 requests (63 Community, 14 listing pages, none with q=) and 7 web searches.

rank.mjs. A search-term run now prints that apps.shopify.com/robots.txt disallows *q=* and exits 1 before any fetch. Any URL containing q= throws before it is fetched. The no-argument run reads the category pages only. A new test stubs fetch to throw and checks the refusal. npm test: 681 → 682, 0 fail.

Sweep (scratch/sweep-2026-10d-notes.md). Of 209 threads created 10-02 to 10-21 in 13 categories, 93 passed the bar (100+ views or 5+ replies); 39 were read in full, 28 kept, and none reached 500 views (largest 314). The Community's robots.txt disallows /search, so only the category lists were used. Three needs met the door test:

• D1 pickup-only carts: an exact-fit app at $4.99/mo has 2 reviews since May;
• D2 a stock buffer on supplier feeds: an exact-fit app has 0 reviews since May;
• D3 code left behind by uninstalled apps: five cleaners, all launched in 2026, all at 0 reviews.

My read. No case to write. Each door already has a cheap, exact-fit app that the same threads have not made sell. That fails the boss's test: if Community demand of this size sold a new app, it would have sold those, and it would have sold Sizecurve. Answers there carry no link (10-15 flag), so the route is the one we already have.

---

Phase 502 — kill read; ad terms mail answered

• Kill read (10-21): 48/50 engaged views, 11/10 checks, 2 remaining. No engaged view since 10-17.
• Mail from market-nana (a colleague, not the boss): the paused ad's impressions came almost entirely from "purchase orders" and "inventory forecast", both mismatched, and "size run" matched only shopper fit-tool searches.
• My answer: keep it paused and do not rebuild it for Sizecurve. Save the ~$82 left for Close of Day or Flatdesk on approval day.
• dev.to: the 10-20 rescan article has 0 views and 0 reactions after a day. The account's other recent posts have 0 to 20 views each.

---

Phase 503 — what new apps that got reviews have in common

One Opus 5.5 agent read 346 App Store pages: category lists sorted by newest, listings, reviews pages and developer pages. None contained q=. Two 429s each cleared after one 60 s wait. The brief's "on a second 429, stop" was ambiguous, and the agent read it as per request. Write-up: scratch/newapp-traction-2026-10.md.

• Sample: 118 apps launched 2026-01 to 2026-07. 90 have 0 reviews (76%), 21 have 1–4, and 7 have 5 or more. The median is 0 reviews a month. Sizecurve's 0 is the norm, not an outlier.
• 5+ against 0 (the 5+ side includes a top-up of 12 apps, so 19 apps): - free plan: 15/19 against 61%; - Built for Shopify: 5/19 against 0/90; - more than one language: 8/19 against 17%; - a free trial runs the other way: 8/19 against 57%.
• No signal: the developer's number of apps, a plain job name, or price.
• The outlier: a button for an EU withdrawal duty that started in mid-2026 has 105 reviews, 19 a month. It has a free plan, then $7.99. It is the only 2026 app over 5 a month: merchants came for a dated legal duty.

My read. Plan 500 route 3 (our apps pointing to each other) finds no support here. The one route that clearly worked for a new app is a legal duty with a start date, where there are no incumbents because the duty is new. A free plan is common among apps with reviews. That supports Phase 456's PASS step of adding Sizecurve's Free plan, but the sample is small and does not show cause. The AU drip-pricing lead (memory, 11-04 check) is the same kind of lead.

---

Phase 504 — duties with a start date, and no app yet

One Opus 5.5 agent, 68 requests plus web searches. EUR-Lex returned empty pages twice; recorded, not retried. Write-up: scratch/duties-2026-10.md.

25 duties start between 2026-11 and 2027-12. 8 could be fixed by an app and have a thin or empty shelf:

• EU credit-ad warning (CCD2, 2026-11-20);
• Illinois all-in price (2027-01-01);
• California prenatal-vitamin test results (SB 646, 2027-01-01);
• UK tobacco generational ban (2027-01-01);
• Spain VERI*FACTU invoicing (2027, likely moved to 2028);
• UK online knife sales (no start date yet);
• EU Cyber Resilience Act support period (2027-12-11);
• New Mexico PFAS label (2027).

My read: no case yet.

• Illinois already failed on 10-13 (Phase 407): a shop complies by deleting a fee, so there is nothing to install.
• Four of the eight may not bind a shop at all: CCD2 (the lender's own widget may carry the warning), the Cyber Resilience Act (it binds manufacturers), the PFAS label (unclear whether online listings need it), and SB 646 (it binds brand owners of prenatal vitamins only).
• The UK tobacco cutoff applies to tobacco, not vapes, and Shopify's own channels bar tobacco, so the market is small.
• Knife sales need ID checks through a verification provider (RULES §5), and there is no date yet.
• Spain is likely moving to 2028, and the software maker carries the fine.

Watch list: the UK knife-sales start date, Spain's 2028 move becoming law, and California's Prop 65 short form (2028-01-01, read from 2026-11, LEARNED 10-13).

---

Phase 505 — dated duties beyond shops

One Opus 5.5 agent ran 84 web searches and 5 page fetches. A 308 was logged and not followed. Write-up: scratch/duties-wide-2026-10.md. Of 55 candidates, 3 were kept:

• Connecticut sick leave for employers with 1+ staff (2027-01-01). General leave trackers already serve it, with tools that have 1,000+ reviews. A thin door.
• Scottish visitor levy. Edinburgh has run since 2026-07-24, and Glasgow (5%) starts 2027-01-25 and Aberdeen (7%) 2027-04-01. Hosts must work out the levy per booking on the room price, keep records and file quarterly. No turnover floor, so B&Bs and self-catering hosts are bound. No standalone tool was found; booking and check-in platforms are adding it. Hosts are asking on official FAQs and on a large short-let platform's forum, where they say the platform cannot do it.
• Wales. Every visitor accommodation must register by 2027-03-31, and Cardiff's levy applies from 2027-04-01 at £1.30 per person per night. Records must be kept per stay for 6 years.

My read. The UK visitor levy is the best lead since Close of Day. It is a dated duty with new words ("visitor levy calculator", "visitor levy return"), it adds a quarterly job, it binds hosts of any size, and Edinburgh's first returns fall about now. Two things are open:

• Reach. It would be a standalone web app, and our own sites draw about zero people (10-19). The new words may be winnable because nobody owns them yet, but that is not shown.
• The boss's test. Edinburgh has run for three months. If no tool has taken hold there, either no one has tried or hosts manage without one.

The next read: who ranks for the levy words now, and what the national portal takes in. Then the case.

---

Phase 506 — visitor levy: reach and route

One Opus 5.5 agent, 103 requests and searches. 403s from gov.wales, glasgow.gov.uk and others were recorded and not retried; edinburgh.gov.uk returned 503. Write-up: scratch/levy-notes.md.

• Reach. On 7 levy searches, government pages and one booking vendor's blog hold first place. No standalone tool ranks.
• Route. Scotland's portal takes typed monthly accommodation-only revenue and works out the levy itself. There is no CSV layout or API. No booking platform remits for hosts; the provider is liable.
• Size. Short-let licences: Edinburgh 3,209, Glasgow 687, Aberdeen 524. Wales has 16,000–55,000 providers (the Senedd's estimate).
• Shelf. A standalone tool exists already, built the way I would build it: import or type stays, apply the night cap, exemptions and VAT, and export the figures for 5 Scottish councils. It is free for one unit, then £6 a property a month. It launched 2026-07-31 and shows no sign of use. An Edinburgh-only tool launched 2026-07-24. A trade body launched a free members' calculator on 2026-10-16. Booking systems and hotel software build the levy in.
• Demand. 10 items. The strongest: hosts and a trade body report correcting bills by hand, because platforms cannot limit the levy by date or by night count.

Decision: drop. It fails the boss's test outright. The tool I would build has been live for three months with no visible use. The search words belong to councils and vendors. A trade body now gives the job away free, and the portal does the arithmetic. Wales (April 2027) has no tool yet, but the reach problem is the same, and gov.wales owns its words.

---

Phase 507 — Flatdesk asks for a review

One Opus 5.5 agent, brief p507-brief.md. No deploy.

• Worker. src/store.mjs: after a reply is sent, and after a retried send, the ticket now also returns repliesSent, counted only up to 3. It counts the shop's sent human replies. A rule's auto-reply, an imported message and a failed send do not count, the same as in the reports. /api/reply and /api/retry already pass the ticket through, so worker.mjs is unchanged.
• Page. public/inbox.js: new reviewAsker(). When a send comes back as sent and repliesSent is 3 or more, it calls App Bridge shopify.reviews.request() 1.5 s later. It asks at most once per page load. A missing shopify.reviews, or an error or refusal, never breaks the page. Shopify decides whether the dialog shows. This file was outside the brief's src//test/ scope, but the inbox runs as a static page module, so the call had to go there. I read the diff and accept it.
• Tests. test/review-request.test.mjs, 7 tests. npm test went from 291 to 298, all passing; I re-ran it.
• Ships with the next Flatdesk deploy, which needs the boss's yes. Flatdesk is still in review.

---

Phase 508 — Flatdesk asks after the first reply

The boss pointed out that 3 replies "could be a while". One Opus 5.5 agent (brief p508-brief.md) changed REVIEW_AFTER_REPLIES from 3 to 1 in src/store.mjs and public/inbox.js, and fixed the comments to match. The tests now show:

• a note, a failed send, a rule's reply and an imported reply each count 0;
• the first sent reply returns repliesSent: 1, and the page asks;
• the count stays at 1 after a retry and after later replies.

The imported-reply check is new. npm test: 298/298 pass; I re-ran it. No deploy: this ships with Phase 507 at the next Flatdesk deploy.

---

Phase 509 — market-nana's three messages; what Close of Day has proven

• Mail. Three messages from market-nana, a colleague (none is the boss and none goes in FACTS): - a "what would sell" brief; - a Close of Day shelf note: three summer-2026 apps with 0 reviews on "end of day report" and "z report"; - three checks before partner pitches to firms that hold many Shopify retail clients. I replied: - size chart no: about 50 look-alikes, and a chatbot makes charts free; - order printer not yet: about 3,000 reviews on the leader, and it needs a buyer phrase the leaders don't own; - a note that robots.txt disallows App Store *q=* and Play /store/search, the reads their shelf note used; - the answers to the three checks, below. All three messages moved to mail/read/.
• Dev store read (connector, ShopifyQL, last 30 days): - 10-15: 4 orders, gross 4,435.75, discounts −94.99, reversals −699.95, net 3,640.81; - 10-17: 2 orders, 1,585.90, both reversed on 10-19; - no shipping, no tax, no second location and no split tender on any day. So the only proof is net sales on 10-15 (the listing video), not a full tie-out to the cent.
• The three checks: 1. Can a printed Finance summary do the job? Unknown, so I am asking the boss. 2. Does it match to the cent? Not proven. I told market-nana not to pitch it. The pitch is "the same definitions as Shopify's Finance summary". 3. Cash drawers: the API gives per-session figures (CashTrackingSession, read_cash_tracking), but only for POS Pro locations, and we have never seen a real session. Leave it out of the pitch, or say "POS Pro locations" only.
• Blocked: the full tie-out needs the bench reseed (tools/seed-bench.mjs: 10 cases with refunds, split tenders, gift cards and two locations). That needs ask 6's token, which is not in hand. I am asking the boss.

---

Phase 510 — order printing: drop

• Close of Day review timing. It asks for a review when a report is printed or saved as a PDF or CSV (src/page.mjs), which a shop can do in its first minutes. No change needed.
• Order printing. One Opus 5.5 agent, brief p510-brief.md. It made 86 requests, all status 200, within robots.txt and with no q= reads. The Community's robots.txt disallows /search, so the agent found threads through web search, related topics and tags. Notes: scratch/orderprint-notes.md. - Threads. 41 kept from 47 read, in 8 needs, about 10,000 views in all since 2025-01. The biggest needs: - templates without code: 12 threads, 1,859 views; - UK/EU VAT invoices: 11 threads, 3,665 views, but 7 of the 11 are about Shopify's own VAT invoice, which no app can replace; - bulk printing: 6 threads, 1,248 views; - draft orders: 4 threads, 960 views. Rounding and search, two of the gaps market-nana named, have no thread since 2025. - Shelf. Every need is already met by a free or cheap app rated 4.9–5.0: free drag-and-drop, $29 one-off, $6.99 with 100 orders free, free up to 50 orders a month. Six of the 8 shelf apps email or link the invoice. - Platform limits. An app has no documented way to attach a PDF to Shopify's own confirmation email; it can only add a link through the merchant's template, or send its own email. Draft orders are readable with read_draft_orders, but there is no Print-menu target for them. - Reach. No shelf title uses "draft order" or "VAT". But the needs are already met for free, so an unowned word would only lead buyers to something they can get for nothing.

Decision: drop. Shopify's own app has a real 3.6 rating, but its gaps are already met by free or cheap, well-rated apps, and the asks are modest: about 10,000 views over nearly two years. No case.

---

Phase 511 — free plans proposed

scratch/free-plans-2026-10.md:

• Close of Day. Free: today and yesterday, the whole store, on screen and printed. Paid ($9): past days, the month, per location, PDF/CSV, the morning email and cash drawers.
• Flatdesk. Free: 50 new tickets a month and 1 agent. Paid ($49): order actions from the ticket, every agent, chat, form, help center, rules and import.

From shopify.dev (Shopify App Pricing): free plans are allowed, there can be one free public plan, plans can be added after listing, and a paid-to-free downgrade takes effect at the end of the cycle. Not yet known: whether a free plan appears in activeSubscriptions, which both apps' gates read. To be checked on the dev store before anything goes live. Put to the boss; no build until each app is approved.

---

Phase 512 — how to test a free plan

Shopify App Pricing docs (shopify.dev, read 10-21):

• The way to test is a private free plan, shown only to the dev store. On a dev store in our organisation, every plan is $0, so nothing public changes.
• The docs now point new apps at the Partner API's activeSubscription for gating. Ours read the Admin API's currentAppInstallation, which worked for Close of Day's paid plan on the dev store on 10-15.
• If a free plan does not show there, the gate needs a second check, not a Partner API token.

Added to scratch/free-plans-2026-10.md. No mail today since Phase 509.

---

Phase 513 — what Sizecurve's recent visitors did

• Installs. /api/installs: 1 installed shop, the dev store (since 09-14). Last week: 0 installs and 0 uninstalls.
• Kill reading. 48 of 50 engaged views. The last engaged view was on 10-17.
• Website, page renders by day. No visitor stayed or scrolled on any day, and no outside referrer came in. | Day | Renders | What | |---|---|---| | 10-19 | 1 | home | | 10-20 | 4 | home, broken-size-runs, privacy ×2 | | 10-21 | 0 | 7 direct arrivals, none rendered | | 10-22 | 0 | 1 direct arrival on how-many-of-each-size |
• App Store listing visits show only in GA4. I asked the boss for a Free-form screenshot from Oct 18 with surface_type and surface_detail.

---

Phase 514 — Close of Day's Community replies, ready

One Opus 5.5 agent, brief p514-brief.md. 46 requests (28 to the Community, within robots.txt; 18 web searches), no errors. Nothing posted. app/daybook/marketing/SHOPIFY-COMMUNITY.md is rewritten: the 10-15 no-link rule is at the head, and no link appears anywhere (checked: 0 URLs).

• Reply A, topic 414614 under post 85 (1,162 characters). Posts 85 and 87 are still unanswered. The reply gives the daily check (total sales + gift cards sold + tips = payments), explains how returns are dated, and gives post 87 a print-scale fix.
• Reply C, new topic 664939 under post 5 (1,062 characters). The POS session rolls over at UTC and splits a trade-show day. The reply shows how to keep one day's record.
• Reply B withdrawn. Topic 659995 got post 15 on 10-08, a developer pitching their own tool, so it now has two pitches.
• Not answered. Five threads skipped, each with its reason.
• Claims checked. Each claim in the replies gets its file and line. "Reaches back 60 days" becomes "for now it covers the last 60 days": read_all_orders is not in shopify.app.toml, and the month email skips days older than 58.
• Found. The in-app notice (src/page.mjs:91) says full order history "is requested". That is true only if the boss filed ask 5. The scope is not in the toml, so even an approved request would not reach the app until the toml and a deploy add it. Asking the boss whether ask 5 was filed.