Plan 532 — could the bar app reach strangers through the boss's Play account?

Plan 532 — could the bar app reach strangers through the boss's Play account?

The kill read is 49 of 50, with one view to go by 10-27. The boss's bar inventory app has had no stranger sign up: the only new accounts are my two test ones. People aren't reaching the web page. The boss has a Play account with no testing gate and a payments profile already set up (facts, 10-02), so a store listing is a channel where people search.

One agent researches it and builds nothing. It covers:

• whether a web app can be listed there, and how its buyers would pay: on the web, through a link out, or through the store's own billing;
• what a wrapper needs from the site;
• whether the hold-to-talk mic works inside it;
• the store's rules for wrapped sites;
• which bar inventory apps are already there, found without store search.

It is done when the case file answers each question with links and a recommendation. If the answer is go, I ask the boss before anything is built.

---

Plan 533 — "Delete my account" and a privacy page for the bar app

The bar app has neither. People expect both, and the Play listing (Phase 532) can't go ahead without them. Whatever the boss decides about Play, the web app needs them. One agent builds them on one branch, local only:

• In-app delete. A bar where you're the only person goes with your account, and its paid plan is cancelled first. If cancelling fails, nothing is deleted. You just leave a bar that has another owner. You're blocked while you're the only owner of a bar other people use.
• A public page explaining how to delete.
• A privacy page written only from what the code does. The boss approves its text.

It is done when the four checks pass and a local database proves each case with row counts. Nothing goes live without the boss's yes.

---

Plan 534: Add to Home Screen for the boss's bar inventory app

• Why: a bar owner counts weekly, on a phone. Today the app has only a favicon, so "Add to Home Screen" gives no real icon and opens in a browser tab. A manifest and icons are also the first step a later Play listing needs.
• Who: one Opus agent, on a local branch feat/home-screen from the live master. No push, no deploy.
• What: a simple mark drawn from the app's own tenths gauge; 192, 512, maskable and apple-touch icons; a manifest that opens full screen; a check that the bottom tab bar clears the phone's home indicator.
• Also: the public site is not in my Search Console tool (only Sizecurve is), and a web search for its own name finds nothing. I ask the boss whether the site is in their Search Console and whether my tool can see it.
• Done when: the branch builds, checks pass, and the icons render on light and dark and under a circle mask.

---

Plan 535: Play mode for the boss's bar inventory app, on a branch

• Read first: the kill read is 49/50 with 1 remaining. The live database has 4 accounts: the boss's 2 and my 2 tests. No stranger has signed up. A web search for the public site's own name still finds nothing from it. A search for voice bar inventory apps finds competitors' store listings, which is where they get found.
• Why: the Play route I recommended (p532) has nothing to buy inside the app. Every Upgrade button, checkout and billing portal has to become plain text there, while browsers keep them. This is the biggest code item on that list. The manifest, icons, account deletion and privacy are already on branches.
• Who: one Opus agent, on a local branch feat/play-mode. No push by the agent, no deploy, no Android project, no signing key.
• Design: - Launching with /?src=play sets a cookie, and the server renders plain text in place of each purchase path. - That cookie is shared with Chrome on the same phone. So in an ordinary browser tab (not standalone), a client check puts the buttons back. - In Play mode, the server actions for checkout and the billing portal refuse.
• Done when: a browser with no cookie shows exactly what master shows; the Play view has no purchase link in its HTML; the checks and the build pass.
• The Play build itself waits for the boss's yes. It also needs an upload signing key, and I don't mint keys, so I ask about that too.

---

Plan 536: the Play store listing pack for the boss's bar inventory app

• Read first (Cloudflare analytics for the public site, sampled, since 09-24): - Google's crawler has fetched robots.txt, the home page, four guides and two calculators, all with 200s. - Bing's crawler has fetched only robots.txt. - Google crawls the site, but a search for its own name still finds nothing. Without Search Console I can't see why.
• Why: if the boss says yes to Play, the boss needs words, images and form answers to paste into Play Console. Having them ready turns a yes into a listing the same day.
• Who: one Opus agent, working in the scratchpad only, with the app run locally in Play mode for the screenshots. It reads only Google's own help and policy pages, and no store search.
• What: - The listing text, with no price and no buy link. - 4–6 phone screenshots, a feature graphic and the icon checked against Google's spec. - The Data safety answers taken from the code, plus the content rating and app content answers. - Every rule checked, with its URL.
• Done when: every field is within its limit, every claim is traced to the code, and every image meets the spec.

---

Plan 540: four new Sizecurve house clips

The boss asked for several Sizecurve videos before anything else.

• One agent makes four new raw clips with claim files, in the house format: real phone-sized captures of the live pages, with no captions or music. The four: the size split calculator, pasting a sheet into it, "which size goes first", and the returns arithmetic.
• They use new slugs and are added to the media index. Nothing existing changes.
• I check every stop and every claim. Then I ask the boss: "May I deploy Sizecurve?" so the docent's scanner picks them up.

---

Plan 546: fix four phone-width faults on public pages

The clips showed four pages breaking at 360 px wide: three Sizecurve tables cut off on the right, and a figure on Flatdesk's cost page wrapping onto two lines. Phone visitors see the same thing. One agent fixes each with the smallest CSS change, checking at 320–412 and at desktop width. Nothing goes live until the boss says yes to a deploy.

---

Plan 548: recover the bar app's Play listing pack

The restart wiped the listing pack: the text, screenshots, feature graphic and form answers the boss pastes into Play Console. The boss is about to submit, so they need it. The two agents' transcripts survive, so one agent replays them to rebuild the pack on the persistent disk and re-shoots the screenshots locally. Then I send it to the boss.

---

Plan 549: two more number-first clips

As promised to the docent: a second number-first clip each for Close of Day and Flatdesk, on different pages and numbers from today's. One agent, with nothing going live until the boss says yes.

---

Plan 550

Read the launch post numbers; find why 20 Daybook browser tests skip; read the kill count.

---

Plan 551

One agent: phone-width fault sweep (320/360/390) of the bar inventory app's public pages and login, the pages a Play reviewer and a stranger see first. Fixes on a site-repo branch, not deployed.

---

Plan 552

One agent: check the signed-in bar inventory app (a local copy only) against the accessibility checks in Play's pre-launch report: 48px tap targets, buttons and fields with no name, and text contrast. Fix the real faults on a branch, not deployed.

Reads

• Kill read: 49 of 50 views, 1 to go, verdict "kill" until 10-27. Today brought one view.
• The bar app's live database: no stranger has signed up. The only new accounts since 09-24 are my two test ones from 10-22.

---

Phase 532 — the boss's Play account as a channel for the bar app

One agent, research only. The case is in the scratchpad, with every policy page dated by when it was read. What it found:

• Paying on the web is allowed. The store's payments FAQ lets an app be "consumption-only": people sign in to something they pay for elsewhere, and nothing can be bought in the app. The app may say "upgrade on our website" in plain words but can't link to it. The fee is 0%.
• The other two routes cost more. A link out to web payment costs 10% in the US and needs native code and per-sale reporting. The store's own billing costs 15% in the US and adds 6–8 days of work. Neither is worth it while no stranger pays.
• What blocks a listing today: - The store requires account deletion, both inside the app and on a web page, and the app has neither. - The app has no privacy policy. - The app has no manifest, no proper icons and no ownership file for the wrapper. - The upgrade buttons must turn into plain text in the store build.
• The mic: it should work, because the wrapper runs in the phone's own browser. No official page says so, so it needs a test on a real phone.
• Who's already there: the bar inventory apps found through links have between 50+ and 100K+ installs. All of them sign people in, with nothing to buy inside. The one voice-counting app at our price has 50+ installs. The market there is small, and nothing yet shows strangers would find us.
• The build: about 4.5 days. The boss would create the app in the console, upload the build, fill in the forms and send it for review.

Not started. A store listing is a new outward channel for the boss's app, so it waits for their yes. Account deletion and a privacy policy help the web app too, whatever the answer.

---

Phase 533 — "Delete my account" and a privacy page

One agent, on a local copy only. It built one branch, which I pushed. Nothing is live.

• Deleting an account. You confirm by typing your email. - A bar where you're the only person is deleted with everything in it, its recordings included. - If that bar is paid, its plan is cancelled first, at once. If the cancel fails, nothing is deleted. - You just leave a bar that has another owner. - If you're the only owner of a bar other people use, the delete is blocked. The app has no way to hand a bar to someone else, so the page says to write to us. - The database deletes run as one batch. A test fails if a future table is missing from the delete list.
• A public page saying how to delete, for people who can't sign in.
• A privacy page written from the code: no name is asked for, photos aren't kept, recordings are kept until you delete them, and the only cookie is the sign-in one.

What I sent back. The first draft said the app loads no analytics. The live walk in Phase 530 saw Cloudflare's analytics beacon on every page, added by Cloudflare rather than by the code. The page now says so. The draft also said recordings help the app "get better at hearing counts". Nothing in the app does that. It now says only what the code does: a word you correct is remembered for your bar.

Proof: 359 tests pass, 18 of them new, and the type check is clean; I reran both. The agent reported the scoreboard gate ok and 17 of 17 wells passing. On a local database with the payment processor stubbed, row counts were taken table by table at each step:

• a blocked delete changed nothing;
• a staff member's delete left the bar alone;
• a failed cancel deleted nothing;
• a successful cancel removed everything.

For the boss:

• the contact email (there is none in the app);
• the privacy text;
• whether the page should say that hand-marked recordings are used to test the app's matching. The repository's test fixtures hold transcripts that look like a real bar's counts.

---

Phase 534: Add to Home Screen, on a branch

• Branch: the boss's bar inventory app, feat/home-screen at 0044675 (three commits on the live master). Pushed; not merged, not deployed.
• The mark: the app's own tenths gauge, ten ticks with seven lit in the accent yellow on the dark ink. One hand-written SVG, plus a script that renders the PNGs from it, so the boss can replace the mark by editing one file.
• Icons: 192 and 512 icons, a 512 maskable icon whose mark stays inside the safe circle, and a 180 apple-touch icon with no transparency. I looked at the 512 icon and the circle-masked one myself.
• Manifest: opens full screen at /. A signed-out person goes to login; a signed-in owner with one bar goes to that bar's home.
• iPhone, opened from the home screen: the tab bar already padded by the bottom inset, but that inset reads zero unless the page uses viewport-fit=cover. The branch adds it, so the tabs clear the home indicator. With a simulated 34 px inset the tabs end at 810 of 844.
• Side effect: browsers now show the new mark in the tab instead of the favicon.
• Checks: 341 unit tests, types, voice score gate, 17 wells tests, and the build all pass. The manifest and every icon return 200 with the right content type.
• Found on the way: applying the migrations to an empty local database fails at the fourth migration with a foreign key error. Live is unaffected: it was migrated in order long ago. It matters only for a fresh copy.
• Search: my search tool sees only Sizecurve, not the bar app's public site. A web search for the site's own name found nothing from it. I asked the boss whether the site is in their Search Console and whether my tool can see it.

---

Phase 535: Play mode, on a branch

• Branch: the boss's bar inventory app, feat/play-mode at 18b2d17, two commits on the live master. Pushed; not merged, not deployed.
• How it switches on: - The Android app would open /?src=play. The home page sends that to a small route that sets a 30-day cookie and returns to /. - The app has no proxy, and a page can't set a cookie, so a route does it.
• What changes in Play mode: - Every Upgrade button and link reads "Upgrade this bar on [the site] in a browser." - A paid bar's card and plan button reads "Manage your plan on [the site] in a browser." - Prices are dropped where they sat next to a button. - The second, paid bar's checkout becomes the same words. - There are 5 price spots and about 7 more button paths: billing, the upgrade card on sales, recipes and the item list, the area limit on count and areas, and the people limit on invites.
• Refusal: in Play mode, the actions that start a checkout or the card page refuse with the same words, unless the form came from a browser tab.
• Browser tabs: - The cookie is shared with the phone's browser, so the server always renders the words. - A browser tab puts the buttons back after it loads. It counts as a tab when it reports display mode "browser" and has no app referrer. - When the page can't tell, the words stay. - A home-screen shortcut made from the same phone's browser would also show the words.
• Checks: - 350 unit tests (9 new), types, the voice gate, 17 wells tests and the build all pass. Lint is clean on the 15 changed files. - A phone-width walk: with no cookie, the markup matches master on all 10 pages. In app mode, the HTML has 0 checkouts, 0 pay forms and 0 prices. In a tab with the cookie, every button comes back. - I looked at the billing page in app mode and in a tab myself.
• To check on a real phone: that an ordinary browser tab reports display mode "browser". Two sources disagree on how reliable standalone detection is, so the code leans to showing the words.
• Fixes to my Play case: it said about 9 price spots; there are 5 rendered prices plus button paths without a price. The second-bar card would read better as "Add another bar on [the site] in a browser."
• Play list now: manifest and icons, account deletion, privacy and Play mode are all on branches. Still left: the asset-links file (it needs the signing fingerprint), the Android project (it needs an upload key), an offline page, the device test, store images and a reviewer account. Then the boss's yes.

---

Phase 537: the boss's answers, and the two branches live

• The boss's answers (FACTS 10-23): - Play: yes, and I make the upload key. - Search Console access for the public site is coming. - "Merge and deploy." - The contact address is the shared support address. - The launch post gets a general line about saving time.
• Merged into the app's master (now 612e524): fix/first-screen-words and feat/home-screen. - 341 unit tests, types and 17 wells tests passed before the deploy. - Deployed the app once; the earlier version is kept.
• Checked live: - The manifest is served as application/manifest+json. - The icons, the apple-touch icon and the SVG mark all return 200. - The login page carries the manifest link, the apple-touch icon and viewport-fit=cover. - The new mic hint is in the live script.
• feat/delete-account (now 1efc304): - The contact placeholder is now the support address. - The privacy page's analytics line said the same thing twice; it is now said once. - 359 tests pass. - Not merged: the privacy text still needs the boss's approval, and its date is set on approval day.
• The launch post: the bracketed line became a general one about saving time, with no number. It waits for the boss's yes to post.
• Running: the Play listing pack (Plan 536).

---

Phase 538: the privacy page approved

• The boss approved the privacy text and the recordings sentence (FACTS 10-23).
• feat/delete-account is now 8c78a5b, and pushed. On that branch: - The draft marker is gone and the page is dated October 23, 2026. - It now says recordings, with their corrections, may be used to test how well the app matches what was said to the right bottle.
• Merge check: a test merge into the live master is clean for both feat/delete-account and feat/play-mode. Merging and deploying either needs the boss's yes; I asked.
• Still waiting: the yes to post the launch text, and Search Console access ("I will let you know shortly").

---

Phase 536: the Play listing pack

• The pack is in the scratchpad, and nothing was submitted. It has: - the name, a 73-character short description and a 1,577-character full description; - five 1080×1920 phone screenshots of a made-up bar, in Play mode; - a 1024×500 feature graphic; - the Data safety, content rating and app content answers; - every Google rule checked, with its URL.
• The text names only free-plan features, each one traced to the code. It has no price and no buy link.
• Found that needs code: - The icon must be a full opaque square for Play. - The manifest description names a paid feature. - Play mode adds a second cookie that the privacy page doesn't mention. - There is no Privacy link once signed in. - Google's deletion guidance asks about processors' copies.
• Found by looking: capital letters split apart in the screenshots ("BOT TLES"). I don't know yet whether that is the headless renderer or the app's CSS.
• Corrections to my Play case: - The app collects no name. - Nothing is bought in the app, so purchase history is no. - The host's web analytics needs declaring. - The website field should stay blank, because the site shows the price.

---

Plan 539: one branch ready for Play

• Who: one Opus agent, on a new local branch feat/play-ready from the live master.
• What: - It merges feat/delete-account and feat/play-mode. - It fixes the Play icon, the manifest wording, the Privacy link on the More page, and the cookie words on the privacy page. - It checks what each speech and photo provider keeps, against the providers' own docs. - It finds and fixes the split letters, then re-shoots the screenshots.
• The deploy: the boss was asked to merge and deploy the two branches. A yes is carried out as this one branch, and the new privacy words are shown to the boss first.
• Done when: checks and build pass, Play mode and deletion work locally, and the screenshots render clean.

---

Phase 539, actual: one branch ready for Play

• feat/play-ready (1ca3897, pushed, not merged) is master plus the delete-account and Play-mode branches. One import conflict in lib/actions.ts; both sides kept.
• Added: a full-square 512 Play icon, the manifest line "Count your bar's bottles by voice." (free plan only), and a Privacy link on the More page.
• Privacy page, cookie words only: the Android app's second cookie is now named on the page.
• Split capitals in screenshots came from the headless renderer at a fractional scale, not the CSS. Re-shot at a whole scale: five 1080x1920 screenshots, clean.
• Checks: 368 unit tests, types, the voice gate, 17 wells tests, build and lint pass. Pages with no cookie match master pixel for pixel. Delete-my-account works end to end locally.
• Found: the speech provider used for counts keeps small samples for its own training by default. A one-word request setting opts out but doubles its rate. That conflicts with the approved privacy line, so it goes to the boss.
• Asked the boss: may I merge and deploy; opt out or disclose; is the second provider's key on a paid tier.

---

Phase 540, actual: four new Sizecurve house clips, not live yet

• New in app/sizecurve/public/media/, each with a claim file, all 1080x1920, no audio, no captions: - split-calculator (32 s): typing 60 into M's returns, and the order goes from 194 to 156. - paste-a-sheet (27 s): paste the rows, then "Copy the order". - which-size-goes-first (30 s): the title, the chart with M at 89%, the table and the finding. - returns-arithmetic (30 s): the worked example and "the ranking flips on units kept alone". It cuts past the cost-sources table, which names outside firms.
• Every claim is in the page's own words. Every pan stop matches a real scrolled screenshot.
• I looked at the end frames of each clip myself.
• The four clips are added to the media index. The daybook and helpdesk copies were updated to match, as the media-index test needs.
• Sizecurve tests: 682 of 682 pass.
• Page faults seen at phone width: the result table's last column header on /split and the held-out figure on which-size-goes-first are both cut off.
• Asked the boss: may I deploy Sizecurve so the docent's scanner picks the clips up?

---

Phase 541, actual: the Play-ready branch merged and live

• The boss: "merge and deploy."
• feat/play-ready was merged into master as 32cf097 and pushed, then deployed. The new version is live on both custom domains.
• Live reads: - /login, /privacy, /delete-account, the manifest and the Play icon each return 200. - / and /play return 307, as expected. - The privacy page shows "Effective October 23, 2026" and the new cookie line.
• Still to do, from the boss's "keep the defualt": a privacy line saying the speech provider keeps small samples for its own training. I draft it, then the boss approves it before it goes live.

---

Phase 542, actual: the four clips are live

• The boss: "Yes you can deploy". npm run release passed all its steps, and 20 of 20 front-door promises were verified live.
• All four clips are live, each mp4 and json returning 200, and the live media index now lists 8 clips. The docent's hourly scanner picks them up from the index.
• The privacy sentence about the speech provider's samples waits for the boss to approve its wording.

---

Phase 543, actual: the speech-provider sentence live; the docent wants more footage

• The boss approved the privacy wording ("Yes I approve"). The bar app's privacy page now says one provider keeps small samples of recordings to improve its own models, and that apart from those samples we don't share data for anyone else's use. Unit tests (368), tsc and the voice gate passed. Committed to master and deployed; the live page shows both sentences.
• The Play data-safety notes now answer voice recordings as Shared: Yes.
• Mail from the docent: all four of my earlier clips have posted. The Shopify-only TikTok has had nothing new since 10-21. What holds viewers best is one exact number on screen in the first second.
• Replied: the four new Sizecurve clips are live. For the next work wake: a second clip each for Close of Day and Flatdesk, and more Sizecurve numbers, aiming for one or two a week.

---

Phase 544, actual: four number-first clips, for the docent

• The docent asked for clips that show one exact number in the first second. Four new ones are in app/sizecurve/public/media/, each 17–21 s, with a claim file: - broken-runs-298 (Sizecurve): "190 of 298 catalogues (63.8%)" had a style on sale with its core sizes gone. - how-many-of-each-size (Sizecurve): "two shapes account for 47.4% of everything on the shelf". - per-ticket-cost (Flatdesk): at 1,000 tickets the cheapest per-ticket plan is $340 a month, against Flatdesk's $49. No other help desk is named on screen. - close-of-day-50-orders (Close of Day): up to 50 orders download straight away, and a larger export is emailed instead.
• All four sit on the Sizecurve host with full URLs in the index, so one deploy publishes them. The index copies on all three hosts are identical, and 682 of 682 tests pass. I looked at the first frames myself.
• Page faults found at 360 px: /per-ticket's price column wraps "$340" over two lines.
• Plan 545 has started: the bar app's Android bundle and its assetlinks file. The boss chose the package name.

---

Phase 545, actual: the bar app's Android bundle is built and sent to the boss

• A Trusted Web Activity is built: versionCode 1, versionName 1.0.0, target SDK 36, min SDK 24 (the helper library needs at least 24). It opens the live app in Play mode.
• It is signed with an upload key I made, kept outside every repo. Its password is in a file next to it and was never printed. Signing is verified on both the bundle and the APK.
• The only permission is the support library's own. The microphone is asked for by the browser, so no audio permission is needed.
• I sent the boss the .aab to upload to Internal testing.
• Branch feat/assetlinks (90a6d2a, pushed, not merged) adds the assetlinks file with the upload key's fingerprint. A local preview serves it with 200 and application/json, and every other page is unchanged. 368 tests and tsc pass.
• Not tested on a device: this machine has no hardware virtualisation for an emulator.
• Next: - The boss sends the Play app-signing fingerprint, and I add it beside the upload one. - I ask: "May I merge and deploy the assetlinks file?" - A reviewer demo login.

• The boss said "Merge". I fast-forwarded the bar app's master to the assetlinks commit (90a6d2a) and pushed it. It is not deployed. The deploy waits for the Play signing fingerprint and a separate yes.

• The boss approved the launch post for their bar inventory app on their LinkedIn profile. I queued it through the LinkedIn Buffer for 16:10Z, word for word as shown to them at 13:19Z. I checked the price in it against the app's own price label first.
• Buffer sent it at 16:10Z with no error. I didn't open the LinkedIn page: our rules keep me off it. I'll read its numbers through Buffer.

---

Phase 546, actual: stopped. Phase 547, actual: the Android bundle rebuilt after a restart

• About 16:42Z the machine restarted. The home folder and /tmp are now memory-only, so everything outside this checkout was lost: the Android upload key and build, the scratchpad clones, the Play pack, and the headless browser.
• Phase 546 (the phone-width page fixes) stopped at its first step: it had no browser, so nothing changed. I reinstalled the browser under .tools/ (gitignored), and the fixes will be rerun.
• I told the boss right away not to upload the first bundle, because its key is gone.
• Phase 547: an agent made a new upload key in the gitignored .secrets/ folder and rebuilt the bundle under .tools/. It has versionCode 1 and min SDK 24. I checked its signing certificate against the new fingerprint myself. A backup zip of the key is ready for the boss. I sent the new bundle.
• Branch fix/assetlinks-new-key (df43408, pushed, not merged) swaps the fingerprint in the bar app's assetlinks file. It needs the boss's yes to merge.
• Learned: keep anything that must outlive a restart under this checkout's gitignored folders, never in the home folder or the scratchpad.

Phase 546, actual (rerun): four pages fit a phone

• With the browser back, the agent measured and fixed all four pages using inline CSS only. The words and numbers are unchanged. - Split calculator: tighter table padding below 400 px. - Size-order and returns pages: number-column headers may wrap on phones. - Help-desk cost page: the table stops breaking figures mid-number. "$340" had split onto two lines.
• Every table fits at 320, 360, 390 and 412 px, and the calculator still fits with 4-digit numbers typed in. Desktop screenshots are byte-identical to before.
• Tests: 682 and 298 pass, browser 64 of 64, figures 253 ok. The sitemap dates were regenerated.
• I looked at the 360 px screenshots myself. Nothing is live yet; the deploys wait for the boss.

• The boss said "yes deploy". Sizecurve's release passed: 682 tests, 64 browser tests, deploy, reviewpath, and frontdoor 20/20. Flatdesk's passed with 298 tests. The phone-width fixes and the four number-first clips are live, and the media index lists 12 clips. I mailed the docent the four links.

Phase 548, actual: the Play listing pack recovered and sent

• The agent replayed the earlier agents' edits from their surviving transcripts. The five text files match the lost ones byte for byte by size. Only one file's full text was never printed, and its size matches too.
• It re-shot the five screenshots locally with the demo bar in Play mode: 1080×1920, no prices, no split letters. I checked the first one myself. It also re-rendered the feature graphic and copied the icon from the app.
• Local database: the fourth migration needs a venue row that only the real-data seed creates. One local row fixed it, with no code change.
• The pack is now in the gitignored .tools/ folder, so it survives restarts. I sent the boss a zip of it.

Phase 549, actual: two more number-first clips, not yet live

• close-of-day-9-a-month (22 s) opens on "$9 a month after a 14-day free trial" from Close of Day's home page.
• flatdesk-49-a-month (19 s) opens on "$49 a month for the whole store, every agent and every ticket".
• Every pan stop matches a real scrolled screenshot. No frame names another help desk. I looked at both first frames myself.
• Tests: 682, 298, and 483 with 20 browser tests skipped. The media index now lists 14 clips, and its three copies are identical.
• Both are fees, not rules, so they may hold viewers less well than the 50-orders clip.
• The deploy waits for the boss.

---

Phase 550

• LinkedIn launch post: Buffer last pulled its numbers at 16:07Z, before it went out at 16:10Z, so 0 reactions and 0 comments is no reading yet. Read again 10-24.
• Daybook: the 20 skips were only the browser path after the restart. With PLAYWRIGHT_BROWSERS_PATH set to the saved browsers, 503 of 503 pass, 0 skipped. No code change.
• Kill read: still 49 views against 50 (window to 10-27).

---

Phase 551

• One agent swept the bar inventory app's 13 public pages and its login at 320, 360 and 390 wide. Nothing scrolls sideways, and there were no console errors or failed requests.
• Two faults, both at 320 only: the tenths chart's ML column and the inventory sheet's ORDER column were cut off. Fixed with a 340px rule each (tighter padding, smaller header text), in the page source and both built pages. Checked: both tables fit at 320, and 360 and 390 are unchanged. I looked at the before and after shots myself.
• Branch fix/phone-width (df269dc) pushed to the site repo. Not merged, not deployed.
• Left alone: result numbers 10+ characters long clip by 1px in the calculators, but real values fit. Footer links and some buttons are under 32px tall.

---

Phase 552

• One agent checked the signed-in bar inventory app on a local copy, in light and dark, against the accessibility checks in Play's pre-launch report.
• Found: many tap targets under 48px (category pills, small buttons, number fields, Remove, Edit, back arrows, the show-password button, plain text links) and one textarea with no name. Contrast was fine everywhere: lowest 5.41 light, 5.68 dark. No sideways scroll.
• Fixed: 48px minimums in globals.css, a tap class on the standalone links, one aria-label. The sweep after the fixes was clean in both themes. tsc clean; lint shows the same 4 older errors before and after. I looked at the after shot of the count sheet: the layout holds.
• Branch fix/play-a11y (684d974) pushed to the app repo. Not merged, not deployed.