Plan 682 — new Play screenshot 02

Plan 682 — new Play screenshot 02

• The Play listing's review-screen shot still shows the old confirm wording, which said a bottle was both counted and not counted. One agent will retake it on the dev server from the live branch, with copies of the old files kept first. Only 02 should change.
• After that I check it by eye and send it to the boss to upload.

---

Phase 694 — plan

• Read the bar site's traffic for 10-29 to 11-01 from the CDN's request counts (path, status, browser, country; the free zone can't show query or referrer).
• If something on that site is broken for real visitors, fix it on the open site branch and ask for one deploy.

Phase 680 — overnight check (boss: "Check everything")

• Site home and sheet page 200; app /login, /privacy, /terms, sign-up 200; POS guide page 307; connect endpoint 401 without a session. All as expected.
• Live DB: no new account since the 10-29 test; no funnel or sign-up source rows for 10-30 or 10-31. No ad or directory visitor has reached sign-up yet.
• The one POS link is the old sandbox one, marked revoked (known; the boss's production reconnect is still in forboss).
• cider2 tree clean apart from the never-commit files; clones on their main branches.

---

Phase 681 — both deploys; visit counter back on the site

• Site: deployed the sheet line. Pushing main was refused because the remote main held the boss's 10-27 visit counter commit, which every site deploy since then had left out. So the site has been live without the counter since at least the ad landing deploy. Merged it, added the counter to the POS guide page (it was the only page without one), redeployed, and pushed main. All three pages checked: counter present, sheet line present.
• Bar app: deployed the confirm wording and sign-up sources. Smoke checks were all as expected.
• Ad, 10-31: 1 click at $2.50, and no funnel row and no account. The click did not reach the sign-up page. $2.50 is the per-click line in the review rules: hold until Sunday's numbers, then decide whether to pause.

---

Phase 682 — new Play screenshot 02, plus a small confirm-list fix

• First retake: every bottle in the demo bar was counted, so the review screen said "every bottle counted". That doesn't match the caption about skipped bottles, and the old shot had the same mismatch.
• Second retake: the stale demo count was confirmed on the local dev DB only, then a new count was made with three bottles left out. The shot now shows "Not counted yet:" with three lines.
• Those lines repeated the name in brackets, e.g. "COFFEE LIQUEUR (COFFEE LIQUEUR)". Fixed on a new branch: the spoken name is shown only when it differs. One file changed; all test scripts and tsc pass. Pushed, not deployed.
• Third retake: the clean 02 is checked by eye at 1080x1920. 01 and 03-07 are byte-identical to before, and the old files are kept.

---

Phase 683 — deployed the confirm-list fix

• Boss: "Yes". Deployed the branch that drops the repeated name in brackets; it includes the confirm wording and sign-up sources. All six smoke checks were as expected. No DB change.

---

Phase 684 — checks for the next lever

• Play listing: the keyword title and short description were already live from 10-26 (in FACTS). Nothing to do there.
• Directories: from the 10-30 research, the two best are done (the open-source directory is submitted; the B2B review site profile exists and only needs claiming). The rest have no bar category, or no site link, or push a sales call. Not worth the boss's time now.
• Site: there is no security-policy header, so the visit counter loads. Every site page carries the visit source onto its sign-up links.
• Found one ad fix: the "how to do bar inventory" keyword lands on the home page, but the site's guide page matches it word for word. Added to Sunday's ask (scratch/bar-ad-review-rules.md) so it goes in one question with the ad numbers.

---

Phase 685 — the free spreadsheets link back

• The credit line in both downloadable sheets was plain text. It is now a real link to the home page, tagged with its own source for each sheet, so sign-ups from a kept sheet show in the tally. Raw XML edit: one hyperlink, one rels file, and one new underlined style per file. Everything else is byte-identical to before. LibreOffice renders the same layout with the line underlined. Branch pushed; not deployed (needs a yes).
• The Shopify listing pages for the two apps in review still answer 404 at the likely addresses, so they look to be still in review (day 16).

---

Phase 686 — the spreadsheet links are live

• Boss: "Deploy". Fast-forwarded the site's main to the spreadsheet-link branch, deployed and pushed main. The live liquor download carries the link with its source tag, the live beer download has its new link file, and both pages answer 200.

---

Phase 687 — a voice-count clip for the house channel

• Docent's mail asked for a bar-app clip, and the boss said "Do it now". The local dev server has no speech key, so filming there stopped at the voice step (no fake was used). The clip was filmed on the live app in our own review demo account, inside its empty 10-26 count, with no new session started.
• One hold of a spoken phrase came back as exactly the two right lines (2.5 and 3). The clip is 13 s, 1080x1920, silent, with the phrase in the caption band. I checked a held frame and the end frame by eye. The demo count is left open and unconfirmed, as it was.
• The clip and its claim file sit on the Sizecurve host, like the Flatdesk and Close of Day clips, so one Sizecurve deploy publishes them and the media-index test passes unchanged (3/3). The index row names the bar app, under the boss's 10-31 exception.

---

Phase 688 — the voice clip is live, and the first stranger Sizecurve install

• The boss said yes, and the Sizecurve release ran: 20/20 live promises verified, and the clip serves as video/mp4. Docent has been told the row is in.
• The boss spotted it in the Partner dashboard: a store that isn't ours installed Sizecurve on 10-26. Our records agree. It's on the free plan, and its catalogue has no sized products, so the 10-26 sweep found nothing.
• On a second empty sweep (Monday 11-02), the app would have sent "we could not read your store, a permission probably lapsed". That's wrong here. The boss said yes to one email to the owner. So, through an agent, a stall caused by no sized products now sends a set-up email instead: how to add a Size option, what the free plan shows, and that uninstalling is right if they don't sell sized goods.
• The agent copied my brief's "free plan covers 3 styles" line and flagged it as untrue under free plan v3. I changed it to what v3 actually shows. 712/712 tests pass. It goes live with the next release.

---

Phase 689 — the real clip in the bar app's home hero

• Read on a phone: the ad's landing page shows its main button on the first screen. No new sign-ups since 10-29, and the single ad click never reached sign-up.
• Through an agent, the home hero's still screenshot is now the real 13 s voice clip: muted, looping, playing inline, with a poster from its last frame (42 KB), and held still under reduced motion. Checked by eye at phone and desktop widths, light and dark: no distortion, no sideways scroll, and playback plus the reduced-motion pause both verified. It's on a site branch, waiting on one deploy yes.

---

Phase 690 — both deploys live

• The boss said "Deploy both". The site home with the clip is live, and site main is pushed. The Sizecurve release passed 712/712 and 64/64 tests and 20/20 live promises, so the no-sizes set-up email is live before Monday's sweep.
• Found on the live check: neither host answers a byte-range request with a part (they send 200 and the whole file). iPhone Safari wants parts for video, so on an iPhone the hero may show only the poster (the finished count) rather than play. Next: serve ranges for media.
• The installing store: its storefront is still behind Shopify's password page, so it hasn't launched. One public request, no products readable. It's most likely a store still being set up, installing apps before it adds products.

---

Phase 691 — media byte ranges on the bar app's site

• Through an agent: the site's Worker now slices /media/ files to answer Range requests (206, Content-Range, 416 for bad ranges, whole file for multi-range or a stale If-Range). The assets binding only ever sent the whole file, which iPhone Safari's video player won't take. 12/12 unit tests pass. Locally, a 0-99 range returns 206 with the right length, the home page and the beta form answer as before, and the clip plays in a phone-sized browser. It's on a branch, waiting on a deploy yes.

---

Phase 692 — the installer's real store sells sized clothes

• The boss found the brand behind the 10-26 install. One public read of its live store: 4 clothing sets in XS–XL. The install went onto a second, empty store. Recorded in FACTS.
• Drafted a short personal note (kept outside the repo, because it names the brand): install on the live store, here's what the free plan shows for your sets, read-only. Waiting on the boss's yes.
• Monday's automatic email can't be switched off for one store without code. The shop records live in a Durable Object with no operator write route, and the prefs link needs the app secret. If the note goes out, the cleanest follow-up is a small operator opt-out route in the next Sizecurve release.

---

Phase 693 — the installer's live store, checked, and one note sent

• The free public check on the brand's live store read all 4 sets with their sizes, and every size is sold out. So the free plan has nothing broken to show. The real offer is the paid one: per-size quantities for the next run, from their orders. Caveat: Shopify only shows the app the last 60 days of orders, and the products went up at the end of March. Their variants were edited today.
• The boss said yes and "just send it now". One personal note went to the contact address on the brand's page, through our mail provider (200). It covers the sell-out, the 60-day limit said plainly, $29 after a 14-day trial, read-only, and a heads-up to ignore Monday's automatic email from the empty store. Replies go to support. No off-switch release was needed.

---

Phase 694 — bar site traffic read, and a missing file found

• 10-29 to 11-01: the bar site's home page got roughly 110 US hits across iPhone Safari, Chrome and unknown agents, plus a few on the voice, POS, inventory, template and tools pages. The CDN can't tell people from bots on this plan, and it can't show the ad's tag, so this is a ceiling, not a count of people.
• The loudest single thing was 70 hits of 404 on /media/index.json, about one an hour. That is the house video scanner, which polls that path on every live host. The site never had the file.
• Fix: the site branch with the iPhone byte-range fix now also serves the clip index, a copy of the one on the Sizecurve host. The range tests still pass 12/12. Pushed, not deployed. One deploy ask covers both.