Plan 553

Plan 553

Read the LinkedIn launch post numbers and the kill count. Combine the two bar-app fix branches (the assetlinks key, the Play tap targets) into one release-candidate branch, and prove it locally with the type check, tests and the production build, so a yes needs one deploy and no fixing.

---

Plan 555

One agent, second accessibility pass on the bar app (local copy only): the voice, photo, count, recipes, sales, register, people, billing, new-bar and reset screens, at 412 and 320 wide, light and dark. Load only: no recording, photos or uploads. Fixes on a branch, not deployed.

---

Plan 556

Sizecurve's install records still show only our dev store. The bar app's Play listing is the nearest channel, and its App access form needs a reviewer sign-in. One agent: a one-command script that makes the reviewer demo account (a bar, one area, 12 bottles), proven on the local copy only, plus the App access answers field by field. It runs live only on the boss's yes.

---

Plan 557

The bar app's Play full description uses 1,588 of 4,000 characters and never names its paid features (sales, the Numbers sheet, recipes, the register link, more areas). Play search reads the descriptions. One agent: write a second version that covers every feature that exists in the code, in the same voice, with each claim traced to code. It goes in the gitignored Play pack, beside the current one, for the boss to paste.

---

Plan 558

The bar app's five Play screenshots show real drink brand names on every bottle, which is a trademark risk in a store listing. None of them shows a paid feature. One agent, local copy only: a v2 set with plain bottle names and two more shots (the Numbers sheet's sold against moved, and sales), written beside the old set.

---

Plan 559

Cloudflare, bar app site since 10-10 (GET 200, bots not separated): home 1,133, login 172, each guide or calculator page 35 to 65, and the two Excel sheets downloaded 20 and 15 times. Neither sheet says where it came from or that the app exists. One agent: one plain line in each sheet pointing back to the site and the voice app, with every formula and format kept. On a branch, not deployed.

---

Plan 560

Cloudflare, bar app since 10-10: the only sign-in posts are our own headless test runs, so no stranger has signed up. A web search for the app's own name finds nothing. The site has a clean sitemap and Bing verification but no IndexNow. One agent: an IndexNow key file and a submit script on a site branch, dry run only. Sending waits on the site deploy.

---

Plan 562

Sizecurve passed its kill line: 52 counted views against 50, window to 10-27. Its Google data for 30 days is about 35 impressions and no clicks, so search is not its channel. The bar app has had no stranger sign up. One agent: find recent public posts where bar staff ask how to count inventory, and draft a reply to each that answers the question first and names the app at most once, disclosed and with no link. Nothing is posted; the boss chooses.

---

Plan 563

The boss will submit the bar app on Play Console soon. The pack has every answer, but in eight files, and from before the v2 text and screenshots. One agent: a single run sheet in Play Console's own order, every field with its exact value, gaps marked for me to answer rather than guessed. Flatdesk is still waiting on the boss's recording sitting from 10-19, and Close of Day has been in review since 10-15; I ask about both.

---

Plan 565

The bar app and its site each had merges today that were never tested together and are not deployed. One agent: type check, tests and a production build of the app as merged, the website link file checked, a phone-width run through sign-up, counting and upgrade in Play mode and in a browser, and the site rebuilt to show it matches what is committed. No code changes; the answer is safe to deploy, yes or no.

Phase 553

• LinkedIn launch post, Buffer read at 02:53Z: 61 impressions, 32 reached, 2 reactions, 0 comments, 3.28% engagement.
• Kill read: still 49 of 50 views. The window closes 10-27.
• Bar app: branch rc/play-1 = master + fix/assetlinks-new-key + fix/play-a11y. The merge was clean. Type check clean; parse tests 277 of 277 pass, wells tests 17 of 17. The production build completes, and its assetlinks.json carries only the new upload key. Pushed to the app repo. Not merged to master, not deployed.

---

Phase 554

• Boss, 10-24: "merge merge". The bar app site: fix/phone-width fast-forwarded into main (df269dc) and pushed. The bar app: rc/play-1 fast-forwarded into master (d3ff8fe) and pushed. Neither is deployed; neither repo deploys on push.

---

Phase 555

• One agent ran the second accessibility pass on the bar app, local copy only: voice, photo, count, recipes, sales, register, people, billing, new bar and reset, at 412 and 320 wide, in light and dark. Pages were loaded only.
• Four tap targets under 48px, all fixed: the count screen's category link (now a 48px wrapper around the same tag), the back arrow on voice and photo at 320, and the Back and Home links on the new-bar screens. No missing names, no contrast failures (lowest 5.41 light, 6.27 dark), no sideways scroll. The re-run sweep was clean everywhere.
• tsc clean. I looked at the count screen before and after: no visible change.
• Not checked: the paid content of recipes, sales and register (the local bar is on the free plan), and screens after a recording.
• Branch fix/play-a11y-2 (c5303c7) pushed to the app repo. Not merged, not deployed.

---

Phase 556

• Bar app reviewer demo account: the one-command script (in the gitignored tools folder) signs up, sets up Demo Bar with one area, imports 12 unbranded bottles and types a count for each. On a second run it says "exists" and changes nothing. The password is made once, kept in the gitignored secrets folder (mode 600), and never printed. Checked: it is in neither the output nor the logs.
• Proven on the local copy only: done on the first run, exists on the second. Two earlier local runs failed (the dev server blocks its scripts on 127.0.0.1) and left two empty local test accounts. Nothing touched a live host.
• The Play App access answers are written field by field in the Play pack. The script runs live only on the boss's yes.

---

Phase 557

• Bar app Play listing: a new full description, 2,988 characters (the old one was 1,588). It keeps every old section and adds the Numbers sheet (free), plus sales, recipes, the register name match, and more areas with the whole team (all paid). It adds that plans are set up on the website and there is nothing to buy in the app.
• Every claim is traced to a file and line on master. Par levels, pour cost and order lists are left out: the app does not do them, only the website's calculators do.
• New short description (73 of 80): adds "bar inventory" to the voice line.
• I read the whole text. Both files are in the gitignored Play pack, and both were sent to the boss to paste.

---

Phase 558

• Bar app Play screenshots v2: seven at 1080×1920, made on the local copy with a plain-named bar. No drink brands, and no upgrade or price words. The old five are kept as they were, with two new shots: 06, the Numbers sheet with Sold next to Change, and 07, a pasted sales report coming off the shelf by recipe.
• Spoken sales was skipped, because it goes through outside speech-to-text. A pasted report was used instead. The app's own sales example and classic-drinks list name brands, so 07 shows the report's confirm screen.
• I looked at all seven. One flaw: in 06, one bottle added after the first count shows a dash.
• Zipped in the gitignored Play pack and sent to the boss to upload in place of the old five.

---

Phase 559

One agent added one line to each of the two downloadable Excel sheets on the bar app site, saying where the sheet came from and that the app counts a bar by voice, free for one area. Liquor sheet: the empty row under the instructions. Beer sheet: under the table on the first sheet. Only that one sheet file inside each workbook changed. Checked every formula, width, merge, validation and print setting before and after: all match. LibreOffice opened both, and with test numbers typed in the totals and order columns work. On a branch of the site repo, pushed, not merged or deployed.

---

Phase 560

One agent added IndexNow to the bar app site on a branch: a key file (not hex-shaped), a submit script that does a dry run by default and on send first checks that the live key file matches, and sitemap dates taken from each page's last change. The dry run listed all 13 pages; nothing was sent. I checked that the file name matches its content and pushed the branch. Sending waits for the site deploy. The bar app still has no stranger sign-up since 10-10, and a web search for its name finds nothing; Search Console is still the boss's step.

---

Phase 561

The boss said merge, merge, deploy. Merged the sheet-line and IndexNow branches into the bar app site's main, and the second Play accessibility branch into the bar app's master; all pushed, none deployed. Released Sizecurve with the p549 clips: 20 of 20 release checks pass live. Search Console: the search tool still covers only Sizecurve's host and refuses the bar app's site with a 403. Answered the boss's three questions: the reviewer sign-in, the AI key and the upload key backup.

---

Phase 562

The agent found 7 posts where someone asks how to count bar stock, and drafted a reply for each. None is from August 2026 or later, and none had a reply in 2026. The best are two payments-company community threads from 2023 and 2025, one marked solved, and a question-and-answer page about nine years old that cannot be fetched. The big bartender forum cannot be reached by the search tool. Replying to two-year-old threads would reach almost no one, so I am not asking to post any of them. Lesson: people asking for this in public, in places I can see, are too few and too old to be a channel; the Play listing remains the bar app's channel.

---

Phase 563

One agent wrote the Play run sheet: create app, the set-up tasks in the dashboard's order, the store listing, the release and the signing step after the first upload, every field with its exact value and its source file. It found the pack disagreeing with itself in four places. A second agent applied my decisions: the full description no longer says where plans are set up; voice recordings count as shared everywhere, including the content rating; Production track per the boss's 10-02 word, with a stop-and-screenshot fallback; six English-speaking countries; one app access text; README and the rule check updated for v2. Two fields stay for me to fill: the demo sign-in and the photos answer, both waiting on the boss. Sent the run sheet and the description to the boss.

---

Phase 565

The pre-deploy check passed on both repos. App as merged: type check clean, tests 277 and 17 pass, production build clean, the website link file holds the new upload key only. At phone width, sign-up, new bar, home, count, catalogue, numbers sheet, history and billing all load with no errors, in Play mode and in a browser. In Play mode the billing page has no price and no pay button; in a browser it shows the price and the upgrade button. Site: the build reproduces what is committed exactly, the IndexNow dry run lists 13 pages, and both sheets open with the new line. Both safe to deploy. One thing I saw on the screenshots: in Play mode the billing page still says to upgrade on the website in a browser. That is the same kind of pointer I just took out of the listing, and it may read to Play's review as steering to pay elsewhere. Next: a branch that drops that sentence, for the boss to choose.

---

Phase 566

Correction to Phase 565. Before making the branch, I read the store's payments FAQ again (the source the 10-23 research used): an app where nothing can be bought may say, in plain words with no link, "Go to our website to upgrade your subscription to Premium". The Play billing page's sentence is exactly that, and the code comment says so. No branch; nothing changed in the app. The listing's description keeps the shorter "There is nothing to buy in the app", which is also allowed.