Plan 581

Plan 581

Sizecurve's free plan is live in code, so a merchant who asks in public about sizes selling out, reordering by size or returns can now be told about something free to try. One agent reads the Shopify Community category lists for threads opened 10-21 to 10-26 (category lists and thread pages only; robots.txt rules out search) and drafts at most two replies for merchant asks that the free plan truly answers. Each draft answers the question first, names the app and its free plan last, and has no link (the 10-15 flag). Nothing is posted: the drafts go to the boss for a yes. Checked first: the kill tally reads "keep" (52 of 50), there are no new installs, and the reviewer demo page already explains that its plan-gate segment predates the free plan.

Correction, before any read: app/sizecurve/marketing/SHOPIFY-COMMUNITY.md records (09-30) that the Community Code of Conduct removes self-promotion outside the Ask and Offer board. So no replies in other threads. Instead the agent reads only our own Ask and Offer thread for posts since our last reply, says whether any question there is unanswered, and drafts one reply that tells the thread about the free plan. It names the app and its free plan, answers any open question, and has no link. It is for the boss to post once the Free plan shows on the listing.

Plan 587

The boss is about to fill in the Play Console for the bar inventory app from the v2 pack. Anything a reviewer or the form follows has to be live before then. One agent works read-only through every URL and live claim the run sheet and its App content files ask the boss to paste: the privacy policy, the account deletion page, the support and contact pages, the Digital Asset Links file, and the live site's sign-in page at phone width. It reports anything that is missing, redirects somewhere odd, or contradicts the pack. Nothing is changed; any fix gets its own brief. The 10-26 Sizecurve sweep runs from 09:00Z, so I check that next wake.

---

Plan 592

The boss is partway through the Play Console for the boss's bar inventory app. They hit five screens whose sub-questions the run sheet doesn't answer: age-restricted promotion, digital goods and rewards, the account creation method, partial delete, and the advertising ID screen. The boss is angry that the sheet is missing them. Every unanswered screen costs a round trip, and the Play listing is the bar app's channel to a stranger.

One agent will read Google's Play Console help pages for each section the run sheet has left (App content declarations, Store settings, Store listing, the Production release and countries, Send for review) and list each question Console actually asks. It adds every missing question to the run sheet with its exact answer, taken from the code and the pack, and marks the answer "ASK CIDER" where neither settles it. It also writes in the answers given today and fixes where the App signing page is. It edits only the pack, which is outside the repo. Afterwards I check the run sheet's answers against the code and send the boss the new run sheet.

---

Plan 593

Checks first:

• Sizecurve's Monday sweep ran at 09:02Z with 12 styles and no error. The dev store token was refreshed (new expiry 10:01Z), so the refresh path works.
• Sizecurve: 0 installs last week.
• The boss's bar inventory app has no stranger sign-up. Its five users are the boss's two, two test accounts from 10-22 and the demo.

The Play listing goes live once review passes, and the bar app's site is the only place a bar owner sees the app outside Play. One agent will make a branch on the site repo that links the Android app from the home page and the voice-counting page. It is a plain text link to the Play listing, styled like the page's other links, with no Google badge image (the badge has brand rules). The branch stays unmerged until the listing is live, and the site deploy still needs the boss's yes. I check the diff and render the pages at phone width.

---

Plan 595

Sizecurve's own site gets almost no people: 1–2 a day since 10-22, nearly all direct. GA4 showed 3 listing users from 09-23 to 10-20, and the ad is paused. More pages won't fix that today.

Close of Day and Flatdesk have been in Shopify review since about 10-22, and that is the nearest path to a stranger. A reviewer who finds a broken live app rejects it, and we only learn of it days later through the boss.

One agent will check both apps live, read-only, the way a reviewer meets them:

• the landing, privacy and terms pages answer 200;
• the install entry redirects to Shopify's OAuth and does not error (followed one hop only, never into Shopify);
• the three privacy webhooks answer 401 to a bad signature;
• TLS is valid;
• the unit tests pass on main.

Then I ask the boss whether Shopify has written about either review.

---

Plan 596

The bar inventory app's site had about 0 real visitors in two weeks (Cloudflare page loads: a few a day, all US and likely us). Play is the channel that's coming, so the Play review must not fail.

A rejection risk I found: in the Android app (Play mode), the bar app tells users "Upgrade this bar on <site> in a browser." and "Manage your plan on <site> in a browser." Google Play's payments policy bans leading users inside an app to a payment method other than Play billing. The pack kept the website off the listing for exactly that reason, yet the app itself says it.

One agent will:

• read Google's current Payments policy pages, including any US-only change about external offers, and say what applies in the six countries we picked;
• audit Play mode for every way it can lead to payment: those words, the billing page, prices, plan names, links to the website;
• on a branch, change the words to neutral ones that name no website and no browser, and hide prices and website links in Play mode;
• run the tests and render the billing page in Play mode at phone width.

The fix waits for the boss's merge and deploy. The bundle needn't change, because the words come from the website.

---

Plan 597

• Search export says people want "liquor / bar inventory" words; on Play nobody knows the brand, so the store title and short description carry the search.
• Draft a Play listing name and short description with those words, for the boss to apply after the first review passes (changing them mid-review could restart it).

---

Plan 598

• Play listing still 404 (not public). Payment path was proven 10-22, so no re-check.
• Backlinks need something only we have. Write the eyeballed-tenths study design in scratch/tenths-study.md and ask the boss one question: can someone at their bar run it?

---

Plan 599

• No answer yet on the tenths study. Make approval day for the bar inventory app's Play listing a checklist, so it goes live on the site and LinkedIn within the hour Google approves.

---

Plan 600

• One agent walks every signed-in screen of the bar inventory app at phone width in Play mode, as the reviewer will, read-only, signed in as the demo account.

---

Plan 601

• The walk's history screen showed a count started on the demo bar at 3:24 AM. Read the database to see who signed in as the demo, and when (read-only).

---

Plan 602

• The boss: the bar inventory app is live on Google Play. Run the approval-day list: merge the play-link and indexnow-ua branches into the site's main, queue the LinkedIn post the boss approved, and ask before deploying the site.

---

Plan 603

• The boss said "Do it" to the Google Play link on the spreadsheet page. Put it in the shared start block, so every built guide and tool page gets it.

---

Phase 604

Day-1 check of the bar app's sign-ups after the Play launch, and a way to see where sign-ups come from. Today the app keeps no trace of how someone found it, and market-nana's trade-press notes (judged 11-16) need that. An agent adds a daily tally per source (the Android app, the linking site, or direct). It isn't linked to any account. It goes on branch feat/signup-sources, with one sentence on the privacy page. Merging, the hand-applied table and the deploy each wait for the boss's yes.

Phase 581

One agent read our Ask and Offer thread with one request (200). Nobody has posted since our post 10 on 10-15: 99 views, and no open questions. Post 1 still shows as hidden after the 10-15 flag. The agent drafted a 114-word reply (in the session scratchpad, not the repo) with no link, mention or exclamation mark. It says Sizecurve now has a free plan (broken runs, stranded units and return rates for every style, plus the weekly email) and that $29 Standard adds curves, reorder quantities and the CSV. It then asks again how merchants round a split into whole units. I checked the "three in ten" returns line against the alert threshold in the code (0.3). The draft is held for the boss, and is not to be posted until the Free plan shows on the listing. With post 1 hidden, a new post may draw a second flag, so the boss decides.

Phase 582

The boss said yes. I merged fix/free-first-screen into main and released Sizecurve: 705 of 705 unit tests, and 20 of 20 live checks. Free shops now see the heading "Where your size runs are broken.", and an "Upgrade" link on each reorder alert. The boss is adding the Free plan in the Partner Dashboard: invoice name Free, handle free, redirect "/", no fee, development stores not free, features "Broken size run alerts" / "Returns by style" / "Weekly email". The app reads that plan as free by its $0 price, or by the name Free when no price can be read.

Phase 583

The boss saved the Free plan. I read the public listing once (200). It now shows "Free plan available", a Free plan card with its three feature lines, and Standard at $29 a month with the 14-day free trial. No review prompt was reported.

Phase 584

The boss showed Shopify's 10-15 message about post 1 of our Community thread. It is still hidden, and editing it after 10 minutes unhides it. Since the post is still hidden, the 10-15 revision was probably never applied. So the new free-plan reply is dropped. Instead, the boss gets the 10-15 revision with one line changed, the disclosure, which now reads "free plan for broken size runs and returns; $29 a month adds reorder quantities". It goes in as an edit to post 1. Nothing else is posted. One post, low-key, no link.

Phase 585

The boss could not edit post 1. There is no edit control under the post, and neither the date nor the "e" shortcut opened an editor. It is likely past the forum's edit time limit (26 days). Post 1 stays hidden. Our Community thread is closed as a channel. No new post, reply or thread from us, since a repost would read as advertising and could flag the account. The free-plan reply draft is dropped.

Phase 586

The boss: "give any dev.to posts to docent". I mailed docent the spoken-counts article to post as written, with needs_reply: no. The boss has not yet submitted the bar inventory app on Play and asked for the materials again. I rebuilt the pack zip from the current v2 files, because the 10-23 zip still held the v1 text and five shots. It has the run sheet, listing text, seven screenshots, icon, feature graphic, the App content answers and the app bundle. I sent it with the run sheet. The App access step still needs the demo sign-in, which waits on the boss's yes. I gave the full site URLs for the three Search Console indexing requests in the reply only, not here.

Phase 587

The first pass checked the wrong host. My brief named the bar app's marketing site, but the Android app wraps its app subdomain. I re-ran it on the right host (33 requests in all, no errors).

• The privacy page, the public account deletion page and the sign-in page all answer 200 with no sign-in. At phone width, the sign-in form fits without scrolling. The deletion page gives the in-app steps, a mail route for people who can't sign in, and what is deleted and kept.
• The site-verification file returns 404 on the app host. It is in the app's main branch (merged 10-23, with the upload key) but not deployed. So until the next deploy, the Android app would open with a browser bar.
• Three declared data-safety items have no sentence on the privacy page: country inferred from the IP address, uploaded audio files, and what one provider keeps after an account is deleted. Plan 588 handles these.
• The marketing site's price button says "Start free, upgrade inside the app". The Android app itself shows no payment links (Play mode), so this is not a Play problem. I left it.

Plan 588

One agent adds the three missing privacy sentences on a branch of the bar app's repo, checks each against the code, and makes no other change. Wording on the privacy page goes to the boss before any merge. The next deploy then carries both this and the site-verification file.

Phase 588

One commit on the bar app repo's fix/privacy-play-gaps branch, pushed, not merged. The privacy page now says:

• the analytics shows the country a visit came from, inferred from the IP address, and the IP address isn't kept;
• audio files you upload are kept like recorded takes (the file picker in the code confirms uploads exist);
• deleting the account doesn't remove samples the one provider has already kept.

The public deletion page lists those samples under what's kept. Typecheck 0 errors, lint clean, tests 277 and 17, all passing, the same as main. I read the diff. "Not kept" is backed only for our own code and config. Whether Cloudflare keeps the address can't be checked from here, so the sentence says "we". Waiting on the boss for the wording, and for a yes to merge and deploy.

Phase 589

The boss typed a password into Play's App access form, which I took as the yes to make the demo sign-in. I created the reviewer account on the live bar app with an address on our own domain and the boss's password, which is stored only under .secrets/play/. It has Demo Bar, one area (Back bar), 12 bottles, and a count on each; the Numbers tab totals 18.4. On the first try the page never fired its load event (it answered 200 in 0.5s by curl). A copy of the script that waits only for the DOM went through. The original script is unchanged.

---

Phase 590

• The boss filled in the Play Console App content and Data safety for the boss's bar inventory app. I answered each screen: no age-restricted promotion, no digital goods, no rewards, not a browser; accounts by username and password; no partial delete; no advertising ID. I also gave the whole data-types table in one message, because the boss had to ask screen by screen.
• The boss sent the Play app signing certificate. The fingerprint they typed matches the deployment certificate in the zip.
• An agent added it as the second entry in assetlinks.json on the bar app branch fix/assetlinks-play-key (1dcd4ed). The JSON parses, with 2 entries. The branch is pushed, not merged and not deployed.
• Waiting on: the boss's yes to merge fix/privacy-play-gaps and fix/assetlinks-play-key into master and deploy the bar app.

---

Phase 591

• The boss said "merge". I merged fix/privacy-play-gaps and fix/assetlinks-play-key into the bar app's master (06a8818) and pushed. The typecheck is clean.
• The boss said "deploy". Parse tests pass 277 of 277, with no new migrations. The bar app is deployed; the earlier version is kept for rollback.
• Live checks: assetlinks.json answers 200 with the package and both fingerprints (upload key and Play signing key). The privacy page has all three new sentences, and the delete-account page has the samples sentence. Login, privacy and delete-account all answer 200.

---

Phase 592

• One agent finished the Play run sheet for the boss's bar inventory app, using 22 of Google's own Play Console help pages and no errors. It added every sub-question the sheet lacked, each with an exact answer: - today's five screens; - target audience step by step; - the full Government, Financial and Health checklists; - the advertising ID screen; - tags and contact; - a new Pricing section (Free); - the countries tab, release notes and release warnings (no deobfuscation file: safe to ignore); - publishing overview. - The App signing menu path is fixed and section 5 is marked done.
• One ASK CIDER item is left: Photos and other audio files, Shared yes or no. It waits on whether the AI key's project has billing on.
• My check: the sheet has no key-shaped strings, no provider names and no demo credentials. The rewritten rows (target age, tags, advertising ID, countries) are present. The sheet went from 351 to 507 lines and was sent to the boss.
• Things it couldn't confirm against the live Console: the exact wording of Government and App details, External marketing, and the tag list.

---

Phase 593

• Sizecurve: the Monday sweep at 09:02Z had no errors (12 styles), and the dev store token refresh works. 0 installs last week.
• The boss's bar inventory app: no stranger sign-ups. Its five users are the boss's two, two test accounts from 10-22 and the demo.
• One agent made feat/play-link on the bar app's site repo (36a3085). It adds a plain "Android app on Google Play" text link under Start free on the home page and the voice-counting page, and moves those two sitemap dates. I checked the diff and the phone screenshot: the link is 24px tall with no overflow. The home headline scrolls 10px sideways at 412px, but only with the fallback font (the web fonts were blocked locally), and that was there before.
• The branch is pushed and stays unmerged until the Play listing is live. I asked the boss if I may deploy the site (main 1e77f55: sheet credit line and IndexNow).

---

Phase 594

• The boss said "Yeah" to deploying the bar app's site. Deployed main 1e77f55; the earlier version is kept. Rebuilding the pages gave no diff, and there are no new migrations. (The signup table was made by hand long ago and was never recorded as a migration. I left it.)
• Live checks: home, bar inventory, tenths chart, voice page and sitemap all answer 200, and the sitemap lists 13 pages. Both downloadable spreadsheets match the repo byte for byte, with the new line.
• IndexNow first refused: Cloudflare answers the script's default Python User-Agent with 403. The key file itself is live and correct for a normal client. One agent gave the script its own honest User-Agent on fix/indexnow-ua (d87f648, pushed, not merged). Sent from that branch: IndexNow status 202 for 13 URLs.

---

Phase 595

• Sizecurve traffic: the site has 1–2 people a day since 10-22, nearly all direct. The kill window stays at 52 views (keep).
• One agent checked Close of Day and Flatdesk live, read-only, the way a reviewer meets them: 20 requests, nothing broken. - Landing, privacy and terms answer 200 on both. - /app with no shop answers 400; the install entry /app?shop=<shop> answers 200 with App Bridge and a frame-ancestors header. - The three compliance webhooks answer 401 to a bad signature on both. - TLS is valid: Close of Day for 66 days, Flatdesk for 81. - Tests on main: Close of Day 483 pass, 0 fail (20 browser tests skipped); Flatdesk 298 pass, 0 fail.
• I asked the boss whether Shopify has written about either review.

---

Phase 596

• The boss asked whether anyone has visited the bar inventory app's site. Cloudflare page loads over 30 days come to about 17. Most are US desktop, likely ours. There was one from LinkedIn on a phone (10-09) and one each from Germany and Ireland (09-27). The site has one beta sign-up (09-24) and no stranger app accounts.
• The boss corrected me: the sitemap was in Search Console before I took over. Recorded in FACTS and LEARNED. Search has had weeks and sends no one.
• One agent read Google's Payments policy (answers 9858738 and 10281818). A consumption-only app "may choose to provide additional information about purchasing options without direct links", for example "Go to our website to upgrade". So the old words were allowed, and my rejection worry in Plan 596 was too strong; I told the boss so.
• The agent made fix/play-no-steer anyway (35b4add, pushed, not merged), with neutral wording and no upgrade links in Play mode. A past-due bar no longer names the payment processor.
• Results: typecheck 0; parse 277/277; wells 17/17; play tests 11/11 (2 new). Lint is unchanged from master. Screenshots were skipped because the dev server rejects symlinked node_modules.

---

Phase 597 — Play listing words from the search export

• Mail: market-nana found 4 backlink targets (community-college beverage-cost courses; the boss would send). I sent the page URLs and an honest one-line description, and asked that the email say the page mentions the paid app.
• Sizecurve site: 0 views on 10-25 and 10-26; kill window verdict still keep.
• Drafted for the bar inventory app's Play listing, in the gitignored pack: name "<app>: Bar Inventory" (24/30) and short description "Liquor and bar inventory by voice. Walk the shelves and say what you see." (73/80). In 10-23 I chose the plain name, following Google's advice to avoid common terms. The new evidence: the brand has no searchers, and the searches that do show the site all say liquor or bar inventory. To apply only after the review passes.

---

Phase 598 — a study only we can publish

• The Play listing page answers 404: not public yet.
• Wrote scratch/tenths-study.md. Two people eyeball 20 open bottles in tenths; each bottle is weighed then, and again empty, giving true fill. It publishes the error in tenths, ounces and cost, with brands and venue removed. Its limits: one bar, assumed density.
• Asked the boss whether someone at their bar can run it.

---

Phase 599 — approval-day checklist for the Play listing

• Wrote APPROVAL-DAY.md in the gitignored Play pack (it names the product, so it stays out of this repo).
• My seven steps: confirm the listing is public; merge the play-link and indexnow-ua branches; deploy the site; send IndexNow; show the boss a LinkedIn post and queue it on a yes; log it.
• The boss's steps: the approval screenshot, then the optional v3 title and short description.
• What I'll measure: new non-our accounts on day 1, 3 and 7.
• Confirmed the branches are still where they were. The site branch changes 4 files.

---

Phase 600 — the reviewer's walk, signed in, at phone width

• 14 screens, all 200. No sideways scroll and no cut-off text. Privacy on More sits 68px above the bottom bar.
• The first walk reported live upgrade buttons in Play mode. That was the test, not the app: a plain browser tab puts the buttons back by design. Re-checked two ways. The server HTML for areas, sales and billing has words only, no payment form and no price. With the in-app flag and standalone display mode, there are words only too. I looked at the billing screenshot myself: plan text and "upgrade on the website in a browser", no button.
• Small: the Numbers header says "No count yet" while home says "Count in progress" (the demo bar has an open count). Left as is.

---

Phase 601 — someone used the demo account after submission

• Demo sign-ins (UTC): 07:17 (the account was made), 08:22, then three at 23:08–23:11 (the Phase 600 agent).
• At 08:24 a count was started on the demo bar and left open with nothing said. That is 12 to 14 minutes after the boss submitted, about 08:10.
• Either the boss tried the demo account or Google's review or pre-launch test did. I asked the boss.
• No new users since 10-22 except our own.

---

Phase 602 — live on Google Play

• The listing page answers 200, rated Everyone. Recorded in FACTS.
• The boss said "Merge. Post it. I'll change it."
• Site main is now 6b09956: the play-link branch fast-forwarded and indexnow-ua merged on top. Pushed. The home and voice pages each carry one link to the listing. Not deployed: "merge" is not a deploy, so I asked.
• LinkedIn: the post shown to the boss, word for word, is scheduled on the boss's profile for 10-27 14:30Z, a weekday morning in the US. First I checked that the listing link answers 200 and that "one area free, for you and one more person" matches the billing screen.
• The boss will apply the v3 Play title and short description in Play Console.

---

Phase 602, continued — site deployed

• The boss said "Deploy". The site's main 6b09956 is live (the old version is kept for rollback).
• Checked live: the home and voice pages each carry the Google Play link and answer 200. The spreadsheet page doesn't have it; it was never in that change.
• IndexNow: 200 for 13 URLs, sent with the new honest User-Agent.

---

Phase 603 — Play link on every built page

• One agent did it on branch feat/play-link-all (6857ac6, pushed, not merged). It is one line in the shared start block plus the rebuild: 12 files, one line each. The sitemap and the hand-written home page are untouched.
• Checked: the diff is that line only. The spreadsheet page has the link once. At 390 wide nothing scrolls sideways. I looked at the screenshot. The voice page now has it twice, about 1,300px apart.
• Asked to merge and deploy.
• The boss said "Merge it". Site main fast-forwarded to 6857ac6 and was pushed. Not deployed; I asked.
• The boss applied the v3 Play name and short description. I confirmed both on the live listing.
• The boss said "yes deploy". Site main 6857ac6 is live. Checked live: the spreadsheet, tenths chart and home pages have the Play link once, and the voice page twice. IndexNow: 200 for 13 URLs.

---

Phase 604

• Day-1 sign-up check: 5 accounts in all, none from a stranger. The newest is our demo account (10-26 07:17Z).
• The app keeps no referrer; the only place it reads one is the Play-mode check. The site's page loads already show referrers (one from LinkedIn on 10-09).
• I briefed an agent on feat/signup-sources (it's running).
• The agent's branch feat/signup-sources (2ee5a89) adds a came_from cookie (30 days) and a daily tally table (migration 0014), with no link to any account. A local check gave the row trade.example n=2, and the tests, lint and type check passed. The privacy page now names all three cookies. Pushed; merging, the hand-applied table and the deploy wait for the boss.