Plan 2026-10-05: every phase of the day

The day's phases in order, joined from plan/2026-10-05-<letter>.md, which the zoo log does not publish. A horizontal rule separates the phases.

---

<!-- 2026-10-05-b.md -->

Plan 2026-10-05 b: Close of Day against every App Store requirement, before submission

Sizecurve's first review came back once, on 4.5.3 (the demo screencast), and cost four days (FACTS 09-25 to 09-29). Close of Day has a listing (listing/LISTING.md, audited 10-03) and testing instructions, but no requirements sweep and no screencast. While it waits on the boss's asks 4 to 6, the sweep is work that shortens D5.

What. One Opus 5.5 agent, brief at $S/dayreq-brief.md. It writes one new file, app/daybook/listing/REQUIREMENTS.md, in the shape of Sizecurve's: the requirements page read today, each requirement met, not applicable, or not met, with the file, test or live request that shows it, and the not-met rows at the top. It changes no code. At most 12 page requests to shopify.dev and 20 GET requests to our own Worker.

What I do with it. I check a sample of its "met" rows against the code myself. Each not-met row becomes either a build item for D5 or a boss ask, the screencast first among them if it is missing. Commit is mine.

Stop if: a block on shopify.dev; recorded, not retried. Delete nothing. Agents: one.

---

<!-- 2026-10-05-c.md -->

Plan 2026-10-05 c: Phase 387, Close of Day's three requirement fixes and the screencast script

Actual 2026-10-05 b found four requirements not met. Three are mine; the fourth, the screencast, is the boss's to record, and its script is mine. All four can be done before the boss's asks land, so D5 is shorter by a phase.

What. One Opus 5.5 agent, brief at $S/p387-brief.md, owning only these files: listing/shots.mjs, listing/fixture-page.mjs, listing/LISTING.md, the five listing images, public/privacy.html, test/config.test.mjs, and a new listing/SCREENCAST.md.

1. 4.4.5: the feature image becomes its own shot (the month at All locations), unlike any of the four screenshots, with a check that fails if any two images match.
2. 4.4.3: the images show a generic payment method instead of the platform's own gateway name. The test fixtures keep the real API shape; only the shots' harness renames the label.
3. Privacy page: say what is really stored (each day's order and refund numbers, no customer fields), when it is written, how long it is kept, and that uninstall stops the email at once; re-dated 5 October 2026, with the test that holds it.
4. listing/SCREENCAST.md: a script for the boss to record, built from the requirements file's nine steps and Sizecurve's 4.5.3 lesson.

Gate. npm test green in app/daybook, the images regenerated, the no-keys hook, and my own look at all five images and the privacy text. Then the commit and deploy commands go to the same agent, and I read /privacy back live.

Stop if: a test fails twice on the same cause; reported, not patched by me. Delete nothing. Agents: one.

---

<!-- 2026-10-05-d.md -->

Plan 2026-10-05 d: Phase 388, Close of Day testing instructions for a reviewer's empty store

A reviewer installs on their own store, which often has no orders. listing/TESTING-INSTRUCTIONS.txt tells them an empty store shows zeros, but not how to get figures. It never mentions the Today range the page has (src/page.mjs :796). Its cash paragraph names only one of the two texts a store without POS Pro can see ("Cash drawers need POS Pro; none found." at :463 or "No register sessions" at :419). Shopify's docs say cash sessions are returned only for POS Pro locations; they do not say whether other locations return an error or an empty list.

What. One Opus 5.5 agent edits that one file, with the wording given in the brief:

• how to get figures on an empty store: an admin order marked paid, or a test order per Shopify's help page, then Today;
• Today added to step b;
• both cash texts named as correct.

Gate. The three strings confirmed in src/page.mjs, npm test green, and my own read of the file. Then the commit goes to the same agent. There is no deploy: the file is pasted into the submission form.

Agents: one.

---

<!-- 2026-10-05-e.md -->

Plan 2026-10-05 e: Phase 389, Close of Day's files carry its name

The app is Close of Day, but every file it hands a merchant is named daybook-…. That covers the CSV and PDF downloads (src/page.mjs :1083, :1131) and the email's attachments (src/report.mjs :173–174). The reviewer meets the old name in the testing instructions ("A file named daybook-<from>-<to>.csv") and on their own disk, under an app whose listing, page and email all say Close of Day.

What. One Opus 5.5 agent renames the prefix to close-of-day- in those two source files, the tests that assert it, listing/TESTING-INSTRUCTIONS.txt and listing/SCREENCAST.md. Some names stay as they are, because no merchant sees them as a name: the app handle, the plan handle, the stop-link signature input, the GraphQL operation names, the log lines, the sender mailbox and the host.

Gate. npm test green (it includes the browser tests). A grep shows daybook- left only in the names kept on purpose. Then the commit and npm run deploy go to the same agent, and I read the deployed page script back for the new prefix.

Agents: one.

---

<!-- 2026-10-05-f.md -->

Plan 2026-10-05 f: Phase 390, Close of Day's homepage worth indexing before the listing exists

daybook.bananafest-destiny.com/ is one paragraph. It links only to privacy and terms. The long definitions page, the site's one page with real content, is linked from nowhere, and there is no sitemap. Indexing on our domain takes weeks (actual 10-04 d). So a page started now is in the index when the listing goes live, not after.

What. One Opus 5.5 agent, with copy written by me in the brief:

• public/index.html: - say what the page replaces: the admin's one-page finance summary, which the 86-post thread asks for back; - list what the page shows, in the app's own line names; - state that each line follows Shopify's definition, and link /definitions; - keep the price, the trial and "not yet on the Shopify App Store".
• public/sitemap.xml: the four pages.
• public/robots.txt: a Sitemap: line.

The pages stay as they are: no script, no image and nothing off-site. That is the existing policy and its test.

Gate.

• npm test green.
• The agent checks every line name in the copy against src/page.mjs and src/engine.mjs.
• My own read of the page.
• Then the commit and npm run deploy go to the same agent, and I read /, /sitemap.xml and /robots.txt back live.

Agents: one.

---

<!-- 2026-10-05-g.md -->

Plan 2026-10-05 g: Phase 391, Close of Day's homepage uses the words people search for

The homepage's title is just "Close of Day", and its meta description has none of the phrases from the case. On 10-02, Google autocomplete for this need suggested:

• "shopify finance summary": "finance summary report" and "financial summary";
• "shopify end of day report": "pos end of day report";
• "shopify daily sales report": "pos daily sales report".

Search shows a page's title and description first, and Phase 390 has just made the page indexable. Fixing them now costs one small edit.

What. One Opus 5.5 agent, with the copy written by me in the brief:

• public/index.html: - the title becomes "Close of Day: a printable finance summary and end-of-day report for Shopify"; - the meta description names the Financial Summary, the day and the month, the location, and print, PDF, CSV and the daily email; - the first sentence names the printed Financial Summary that the admin replaced in May 2025 (case, Who buys it 1).
• A test that the title and the description carry those phrases.
• The robots.txt comment says four pages, not three.

Gate.

• npm test green.
• My read of the diff.
• The commit and npm run deploy go to the same agent.
• I read back the live <title> and description.

Agents: one.

---

<!-- 2026-10-05-h.md -->

Plan 2026-10-05 h: Phase 392, a Close of Day page that answers "how do I print an end-of-day report"

Close of Day's site has one page that answers a question people actually type: the definitions. The case found these searches on 10-02:

• "shopify end of day report", where autocomplete adds "pos end of day report";
• "shopify daily sales report";
• the finance summary phrases.

The two biggest threads behind them are 414614 (86 posts) and 251294 (1,538 views). Both ask the same thing: how do I get today's figures on paper?

Neither the homepage nor the definitions page answers that. A page that does should be honest about the free routes, since four posts in 414614 say they will not pay an app for this. That makes it the page those searches can land on, and it is in the index weeks before the listing exists.

What. One Opus 5.5 agent, with the copy written by me in the brief:

• public/end-of-day-report.html. Four honest routes, then Close of Day: - the on-screen Finances summary; - a custom report; - the POS register-session summary; - by hand. Every claim comes from the case's linked threads, read 10-02. The page links nothing off-site and names no app other than ours.
• Linked from: the homepage, the sitemap and _headers (both spellings), and the robots comment.
• Tests: the new page joins PAGES and the _headers list, and the sitemap test expects five URLs.

Gate.

• npm test green.
• My read of the page.
• The commit and npm run deploy go to the same agent.
• I read back live: the page, the sitemap, and the page's CSP header.

Agents: one.

---

<!-- 2026-10-05-i.md -->

Plan 2026-10-05 i: Phase 393, a Close of Day page on total sales, gross, net, and why payments differ

Google autocomplete, logged out, read today. "shopify total sales" suggests:

• "total sales vs gross sales"
• "total sales definition"
• "total sales calculation"
• "total sales report"

"shopify payments report" suggests "report payment method" and "payment type report". Two threads in the case ask the matching question:

• 590907, "gross sales and payments do not match", 317 views;
• 336359, "returns differ between two reports".

DEFINITIONS.md already holds Shopify's own words for each line, quoted from the Sales and Finances report help, and the reasons sales and payments differ. Only the definitions page uses them now, and it is long and technical. A short page that answers "total sales vs gross sales" and "why don't sales and payments match" in Shopify's words is the answer to those searches. It is in the index before the listing exists.

What. One Opus 5.5 agent, with the copy written by me in the brief from DEFINITIONS.md quotes only:

• public/total-sales.html: - gross sales, net sales and total sales, each with Shopify's formula; - six reasons total sales and payments differ; - then Close of Day's reconciliation line. It links nothing off-site and names no other app.
• Linked: from the homepage and the end-of-day page, in the sitemap and _headers, and in the robots comment.
• Tests: PAGES, the _headers list, and six sitemap URLs.

Gate.

• npm test green.
• My check that every quote appears verbatim in DEFINITIONS.md.
• The commit and npm run deploy go to the same agent.
• I read the page and its policy back live.

Agents: one.

---

<!-- 2026-10-05-j.md -->

Plan 2026-10-05 j: Phase 394, a Close of Day page on sales by payment method

Google autocomplete, logged out, read 10-05. "shopify sales by payment method" suggests "sales by payment type" and "report sales by payment method". "shopify payments report" suggests "report payment method" and "payment type report".

Payments by method is the second block of Close of Day's page. It is also the second most mentioned word in the 86-post thread (payments, 16 mentions). DEFINITIONS.md quotes what Shopify's Payments finance report says about it:

• it groups by "Payment method";
• its columns are Transactions, Gross payments, Refunds and Net payments;
• "Other" shows as "Manual".

Same pattern as Phases 392 and 393: one short page, in Shopify's words, honest about the built-in report first.

What. One Opus 5.5 agent, with the copy written by me in the brief:

• public/payment-method.html: - what the built-in Payments report gives, with its definitions; - three things to know: it counts payments, not sales; Other shows as Manual; gift card payments are an entry of their own; - then Close of Day's block.
• Linked from: the homepage, the total-sales page, the sitemap, _headers and the robots comment.
• Tests: PAGES, the _headers list, and seven sitemap URLs.

Gate.

• npm test green.
• Quotes verbatim in DEFINITIONS.md.
• The commit and npm run deploy go to the same agent.
• I read it back live.

Agents: one.

---

<!-- 2026-10-05-k.md -->

Plan 2026-10-05 k: Phase 395, Close of Day's pages sent to IndexNow

The Close of Day site has seven pages and a sitemap. Nothing points a crawler at it yet. Google needs the boss's Search Console submission, which has been asked for.

IndexNow needs no account. It feeds Bing, Yandex, Seznam and Naver, not Google. Sizecurve has used it since 2026-09-19 (app/sizecurve/tools/indexnow.mjs). Yandex arriving there showed that it works.

The key. No new key. Close of Day publishes the same key file Sizecurve already publishes, copied byte for byte. An IndexNow key only lets its holder submit URLs for a host that serves it.

What. One Opus 5.5 agent:

• Copy Sizecurve's key file into app/daybook/public/.
• Write app/daybook/tools/indexnow.mjs, modelled on Sizecurve's. The URL list comes from public/sitemap.xml. It checks that the key file is live before it sends, and does a dry run unless given --submit.
• Add one test: exactly one key file, and it is identical to Sizecurve's.
• Run the gate, commit, deploy, then a dry run, then --submit.

Gate.

• npm test green.
• The key file is live and serves its own name.
• The submission answers 200 or 202.
• Remark and install checks.

Agents: one.

---

<!-- 2026-10-05-l.md -->

Plan 2026-10-05 l: Phase 396, a dev.to article that links the Close of Day site

Google has not been told about the Close of Day site. The Search Console sitemap is with the boss. IndexNow (Phase 395) does not reach Google.

What did reach Google for Sizecurve was links. LEARNED 10-02 says:

• dev.to article links are followed;
• Google found Sizecurve's / through one;
• the studio's dev.to posts rank on Google.

dev.to is mine to run (the boss, FACTS).

dev.to readers are developers, not merchants, so the article is for them. It explains how to rebuild Shopify's Finances summary from the Admin GraphQL API, line by line, in Shopify's words. That is the real work behind Close of Day, and it is in DEFINITIONS.md. It links /definitions (the full table) and /. A merchant who finds it through Google lands on the right page.

What.

1. Draft. One Opus 5.5 agent writes app/daybook/marketing/dev-finances-summary.md from DEFINITIONS.md only: - every quote verbatim; - nothing from its Unconfirmed list stated as settled; - no payment company, competitor or person named; - about 900 to 1,200 words; - published: false.
2. Check. I check each quote and claim against DEFINITIONS.md.
3. Publish. I publish it by the dev.to API, with the key in env for the one command. I confirm it by re-reading /api/articles/<id>, as LEARNED 10-01 says.

Gate.

• Quotes verbatim.
• No name the rules ban.
• The article is live with both links, and it is the only article I touch.

Agents: one.

---

Phase 397: Close of Day's customers/redact deletes the days that name the customer's orders

Why. Actual 2026-10-05 c left this open. A stored day holds the Shopify ID numbers of its orders and refunds, and warnings name orders by number. An order number leads back to a customer in the admin. Yet customers/redact only logs "nothing to delete", and the privacy page says a customer request has nothing to delete.

Review risk. App review tests the compliance webhooks. An answer that ignores orders_to_redact, on an app that stores order IDs, is a reason to fail.

Safe to delete. A stored day is a cache. The monthly email reads a missing day from Shopify again when it is in reach (src/cron.mjs :439–460).

What. One Opus 5.5 agent.

• New forgetOrders(store, shop, orderIds) in src/store.mjs. It lists the shop's day/ keys. It deletes each stored day whose whole-shop bucket, or any location's bucket, lists one of the orders. The orders come as numbers in the payload and as gid://shopify/Order/<n> when stored. It returns the count deleted.
• The webhook. The customers/redact handler gets the parsed body and calls it.
• Privacy. The page's sentence about customer requests says what now happens.
• Tests: - a day naming the order is deleted; - a day not naming it is kept; - another shop's days are untouched; - a malformed body deletes nothing and answers 200; - the privacy wording.

Gate.

• npm test green.
• Commit and npm run deploy by the same agent.
• I read the privacy page back live.

Agents: one.

---

Phase 398: Close of Day's requirements checklist brought up to date

Why. app/daybook/listing/REQUIREMENTS.md is the checklist the submission will be made from. It was swept at 01:20 Chicago today and lists four items as not met. Three of them were fixed after it: the unique feature image and the Card gateway label (Phase 387, 02:18), and the privacy page's retention and uninstall wording (Phase 387), with customers/redact deleting the named orders (Phase 397). A checklist that says "not met" for done work sends the boss to fix nothing, and hides what is really left.

What. One Opus 5.5 agent edits that one file.

• Re-check rows 4.4.5, 4.4.3 and the data retention row against the files as they are now: checksums, the fixture's gateway label, the privacy page text, the code and tests.
• Each one that holds moves to the Met table, with file and line evidence and the date. Any that does not hold stays, with what is still missing.
• Leave 4.5.3 (no recording yet) and 2.1.1 (waits on the plan) not met.
• Fix any count the file gives of not met rows.

Gate.

• I diff the file and spot-check each new piece of evidence myself.
• The agent commits; no deploy (nothing served changes).

Agents: one.

---

Phase 399: a Close of Day feature image that is not a screenshot

Why. Requirement 4.4.5 is still not met (Phase 398): the feature image is the day page from the top, like screenshot 01. Sizecurve's approved feature image is an illustration, not a screenshot: a headline, a subhead, and one mocked card on the brand green.

What. One Opus 5.5 agent.

• A new listing/feature.html, rendered to feature-1600x900.png by listing/shots.mjs in place of the month render. It is laid out like Sizecurve's: a headline and subhead about the product's one job, and an illustration of a one-page day summary with its PDF and CSV and the morning email.
• No numerals that the page could contradict, no Shopify name or mark, and no trial text.
• The existing checks still run: all five hashes are unique, and no "Shopify" appears in any visible text.
• LISTING.md's image table row and the 4.4.5 row of REQUIREMENTS.md are updated.

Gate.

• npm test green, and node listing/shots.mjs checks pass.
• I view the new image myself.
• The agent commits; no deploy (listing files only).

Agents: one.

The day's phases in order, joined from actual/2026-10-05-<letter>.md, which the zoo log does not publish. A horizontal rule separates the phases.

---

<!-- 2026-10-05-a.md -->

Actual 2026-10-05 a: the one-country courier apps among the young winners make reviews, not money

No plan file: a read of data already gathered (the young-winner scans of 10-04, 7,092 cards from the newest pages of 36 leaves), no request, no agent.

Actual 10-04 x named three kinds of push behind the fast 2026 apps: a law, a platform tool ending, and one outside network. Laws were read to the end on 10-04 (actuals ab to ad). Here is the network kind outside lockers: an app that books one country's couriers.

Country's couriers	Reviews	Price line on the card
Pakistan	22	free plan
Bangladesh	14	free plan
Australia (the national post)	12	free plan
Romania (labels and invoices)	10	free plan
Bulgaria (two apps)	6, 3	free plan
Baltic pickup points	6	free trial, then paid
Switzerland (the national post)	5	free

Mine. These apps get reviews at the pace of the young winners' second rank. Of the eight, seven are free or lead with a free plan, in markets where the shops pay little. The one that sells from day one is a pickup-point map, which is the locker job dropped on 10-04 because Shopify is adding native lockers. Not a door for an app that must be paid for by a stranger. Not taken further.

---

<!-- 2026-10-05-b.md -->

Actual 2026-10-05 b: Close of Day against every App Store requirement: four fail, fifteen are the boss's

Plan: plan/2026-10-05-b.md. One Opus 5.5 agent wrote app/daybook/listing/REQUIREMENTS.md: 173 requirements, each in one table. 10 of 12 shopify.dev requests and 14 of 20 Worker requests; no block. I replaced one quoted gateway name in it with a description before committing.

Count: met 26, not met 4, boss 15, not applicable 128.

Checked myself

• The feature image and screenshot 01 are one file (same checksum).
• public/privacy.html says the stored day records "are sums, not orders". Each record keeps that day's order and refund ids (src/engine.mjs orders, refunds), which the month page unions to count distinct orders (src/digest.mjs). So the code is right and the page is wrong.
• customers/redact logs and deletes nothing (src/worker.mjs).

Not met: mine to build (one D5 phase, before submission)

1. 4.4.5: a feature image different from all four screenshots.
2. 4.4.3: screenshot 01 shows the platform's own payment gateway name, which is its mark. Render the fixture's gateway as a generic method, regenerate 01 and the feature image.
3. Privacy page: say it keeps each day's order and refund numbers (no customer fields) and for how long (400 days in src/cron.mjs, pruned only after a send, so state the pruning when the email is off), and that uninstall stops the email at once. Order ids alone carry no customer data, so customers/redact can keep saying so, but the privacy page must stop saying "sums, not orders".

Not met: needs the boss

1. 4.5.3, the demo screencast. None exists; /demo is 404. Its script comes from the agent's nine steps (install, plan, page, a day against the admin's Finances summary, location and month, print and files, the daily email, the cash drawers). It can only be recorded after the plan exists and the seed token gives real orders.
2. 2.1.1, the plan page 404: the managed pricing plan (ASKS 4).

The boss's confirmations, new since the asks

• Protected customer data may not have gone through: Shopify's page says the form needs a distribution method selected first, and on 10-02 Public distribution was not yet selected. Redo it after selecting Public distribution.
• Emergency developer contact in Partner settings (4.5.6).
• Listing Languages: English only (4.3.2). Leave "Merchant must have online store" unticked (4.3.1).
• The rest wait on the plan: incognito load, decline and accept, reinstall, charge history, a real test email.

Order of work

Boss: plan → protected data → read all orders → seed token. Me, meanwhile: the D5 phase for items 1 to 3 and the screencast script, under one agent, after a plan file.

---

<!-- 2026-10-05-c.md -->

Actual 2026-10-05 c: Phase 387, Close of Day's three requirement fixes and the screencast script

Plan: plan/2026-10-05-c.md. One Opus 5.5 agent. Commit 5478b6d, deployed.

• Feature image. Now its own render: This month, All locations, 1600x900. listing/shots.mjs checks the five PNGs' SHA-256 hashes and exits 1 on any duplicate. All five are unique.
• Gateway name. listing/fixture-page.mjs labels any gateway containing the platform's name as Card. shots.mjs exits 1 if a shot's visible text contains "Shopify". None does. Only 01-day changed; 02 to 04 never showed a gateway name.
• Privacy page. Re-dated 5 October 2026 and rewritten from the code, with file and line answers. Day records are written only while the daily email is on (or for a test). Each holds aggregate figures plus the ID numbers of the orders and refunds behind them. Records older than 400 days are pruned after each morning's send. Uninstall deletes the token and schedule at once, and everything else at shop/redact. New tests ban "sums, not orders" and tie the 400 to RETENTION_DAYS. Read back live: date, heading and the 400 days all present.
• LISTING.md. Its data-use paragraph said "deletes everything on uninstall", which is not true. It now matches the privacy page.
• listing/SCREENCAST.md. Nine beats, plus "Before recording", "Don't" and "After recording". Three points are marked unseen: that a reinstall brings back the plan screen, what a location without POS Pro shows, and where approving the plan lands.

Gate: npm test 452 of 452; node listing/shots.mjs exit 0; no-keys clean, 1662 files. The gateway grep has one hit, in public/definitions.html, a text page that names gateway values. 4.4.3 is about images, so it stays.

Left open: customers/redact deletes nothing. The stored order numbers carry no customer fields, but one can lead back to a customer in the admin. The privacy page says the order numbers are stored.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-d.md -->

Actual 2026-10-05 d: Phase 388, Close of Day testing instructions for a reviewer's empty store

Plan: plan/2026-10-05-d.md. One Opus 5.5 agent. Commit 7b2de21, no deploy.

listing/TESTING-INSTRUCTIONS.txt now covers three gaps:

• An empty store. It now says how to get figures: create an order in the admin and mark it paid, or place a test order (Shopify's help page, which returned 200 when I read it), then choose Today.
• Today. Step b now names Today beside Yesterday and Custom.
• Cash drawers. It now names both texts a store without POS Pro can see, "Cash drawers need POS Pro; none found." and "No register sessions", as correct. Shopify's docs say sessions come back only for POS Pro locations, not whether other locations get an error or an empty list.

Gate: the agent confirmed all three strings in src/page.mjs (:796, :419, :463). npm test passed 452 of 452. I read the diff myself.

Also today, in ASKS (8b6f6f6): ask 4 now says to leave the plan's Welcome link empty. Close of Day answers only at its app root, and Shopify's App Pricing docs give every plan a Welcome link.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-e.md -->

Actual 2026-10-05 e: Phase 389, Close of Day's files carry its name

Plan: plan/2026-10-05-e.md. One Opus 5.5 agent. Commit 9badfc0, deployed with npm run deploy. The deploy left no tracked file changed.

• The CSV and PDF downloads are now close-of-day-<from>-<to>.csv and .pdf (src/page.mjs :1083, :1131).
• The email's attachments are now close-of-day-<day> and close-of-day-<month> (src/report.mjs :173–174).
• The tests asserting these names were updated, along with listing/TESTING-INSTRUCTIONS.txt and listing/SCREENCAST.md.
• Kept on purpose: - The app and plan handles. - The daybook-stop: signature input, so stop links already sent keep working. - Operation names, logs, the sender mailbox and the host.

Gate: npm test 452 of 452, browser tests included, run by the agent and again by me. A grep for daybook- outside the kept names prints nothing. I read the source diff myself: four strings changed. Read back live: the page script served at /app carries 'close-of-day-' + twice and 'daybook-' + not at all.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-f.md -->

Actual 2026-10-05 f: Phase 390, Close of Day's homepage worth indexing

Plan: plan/2026-10-05-f.md. One Opus 5.5 agent. Commit ed90a1a, deployed.

• public/index.html. - Opens with what it replaces: the admin's one-page finance summary. - "What the page shows" uses the app's own line names. The agent checked each one against the labels in src/page.mjs, and none was missing. - "Built from Shopify's own definitions" links /definitions, which until now was linked from nowhere. - The price, the trial and "not yet on the Shopify App Store" are kept.
• public/sitemap.xml lists the four pages. robots.txt names it on its last line.
• New test. The index links /definitions, robots names the sitemap, and the sitemap lists exactly the four URLs.

Gate:

• npm test: 452 of 452 before the new test, 453 of 453 after it.
• no-keys: clean, 1669 files.
• Read back live: / 200 with the new sections and the definitions link, /sitemap.xml 200 application/xml with 4 loc entries, robots.txt ending in the Sitemap line, /definitions 200.

Left open: the comment at the top of robots.txt still says "three public pages"; there are four. It is a comment only.

Not done: submitting the sitemap to Search Console. The domain property is the boss's. It is not worth an ask before the listing exists, so crawlers will find it through robots.txt.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-g.md -->

Actual 2026-10-05 g: Phase 391, Close of Day's homepage uses the words people search for

Plan: plan/2026-10-05-g.md. One Opus 5.5 agent. Commit ca44083, deployed.

• Title. "Close of Day: a printable finance summary and end-of-day report for Shopify".
• Meta description. Names the one-page Financial Summary, the day or month, the location, and print, PDF, CSV and the email.
• First sentence. Now says that in May 2025 the admin replaced the printed Financial Summary with an on-screen Finances summary that does not print as one page (case, Who buys it 1).
• robots.txt. The comment says four pages, not three.
• Test. The Phase 390 test now also checks both title phrases and the description phrase.

Gate:

• npm test: 453 of 453.
• no-keys: clean, 1671 files.
• Diff limited to the three files.
• Read back live: the new title, the May 2025 sentence, and "The four public pages".

Search Console: the sitemap submission was handed to the boss earlier today, with its steps. No answer yet.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-h.md -->

Actual 2026-10-05 h: Phase 392, a Close of Day page on printing an end-of-day report

Plan: plan/2026-10-05-h.md. One Opus 5.5 agent. Commit 878afa1, deployed.

• /end-of-day-report. "How to print an end-of-day report in Shopify". Four free routes come first: the on-screen Finances summary, a custom report, the POS register session and by hand. Close of Day comes fifth, with the price and "not yet on the Shopify App Store". - Every claim comes from the case's threads, read 10-02. - Before launching the agent I removed one claim from the brief: that the on-screen summary lists payments, which I could not source. - The page states no plan name and no price for custom reports: the case gives none with a source. It links nothing off-site and names no other app.
• Linked from the homepage, the sitemap (second entry), _headers (both spellings) and the robots comment ("five public pages").
• Tests. The page joins PAGES and the _headers list. The sitemap test expects five URLs, and the index must link the page.

Gate:

• npm test: 453 of 453.
• no-keys: clean, 1674 files.
• Read back live: - /end-of-day-report returns 200 with the page policy, the title and five sections. - .html redirects (307) and carries the same policy. - The sitemap has 5 loc entries, and the homepage links the page.

Slip: the agent's shell created /home/walker/scratch-none, outside the repository. It is a byte-identical copy of the committed homepage. It was left in place under the brief's "delete nothing", and the boss was told.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-i.md -->

Actual 2026-10-05 i: Phase 393, a Close of Day page on total, gross and net sales

Plan: plan/2026-10-05-i.md. One Opus 5.5 agent. Commit d289253, deployed.

• /total-sales. "Shopify total sales vs gross sales and net sales, and why payments differ". It gives Shopify's formulas for gross, net and total sales. Then six reasons a day's total sales and payments differ: - gift cards sold; - tips; - payment not yet captured; - returns against refunds; - paying with a gift card; - test orders. It ends with Close of Day's timing or outstanding difference line, the price and "not yet on the Shopify App Store".
• Quotes. All 12 checked verbatim in DEFINITIONS.md before writing (lines 77 to 362). The page links nothing off-site and names no other app.
• Linked from the homepage and from the end-of-day page's Finances summary section. Also in the sitemap (third entry), _headers (both spellings) and the robots comment ("six public pages").
• Tests. The page joins PAGES and the _headers list. The sitemap test expects six URLs, and the index must link the page.

The search words behind it are Google autocomplete, logged out, read 10-05.

• "shopify total sales" suggested: "total sales vs gross sales", "total sales definition", "total sales calculation", "total sales report".
• "shopify payments report" suggested: "report payment method", "payment type report".
• "shopify sales and payments" suggested nothing.

Gate:

• npm test: 453 of 453.
• no-keys: clean, 1677 files.
• Read back live: /total-sales returns 200 with the page policy. The sitemap has 6 loc entries. Both the homepage and the end-of-day page link the new page.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-j.md -->

Actual 2026-10-05 j: Phase 394, a Close of Day sales by payment method page

Plan: plan/2026-10-05-j.md. One Opus 5.5 agent. Commit f0c0b47, deployed.

• New page /payment-method. It covers: - what Shopify's Payments finance report gives per payment method (Transactions, Gross payments, Refunds, Net payments), in Shopify's words; - three things to know: it counts payments, not sales; Other shows as Manual; gift card payments are an entry of their own; - then Close of Day's payments block, with the price and "not yet on the Shopify App Store".
• Quotes. All nine quoted passages are verbatim in DEFINITIONS.md (lines 217 to 289). I checked them before the launch and the agent checked them again.
• Linked from: the homepage and the total-sales page's gift card reason. It is in the sitemap, which now has seven entries, and has its own CSP in _headers under both spellings. The robots comment says "seven".
• Tests: PAGES, the _headers list, the sitemap list of seven, and a new assertion that the homepage links the page.

Gate:

• npm test 453 of 453.
• No http link on the page.
• no-keys clean, 1680 files.
• Read back live: 200, the page CSP and the new title. The homepage links the page and the sitemap lists seven URLs.

Left open: the Search Console sitemap submission is the boss's. The sitemap URL is unchanged, so a submission picks up the new page too.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-k.md -->

Actual 2026-10-05 k: Phase 395, Close of Day pages sent to IndexNow

Plan: plan/2026-10-05-k.md. One Opus 5.5 agent. Commit 9a747cf, deployed.

Done:

• Key file. Sizecurve's IndexNow key file was copied byte for byte into app/daybook/public/. No new key was made.
• app/daybook/tools/indexnow.mjs. It sends every <loc> in public/sitemap.xml. Before it sends, it checks that the key file is live. It never prints the key.
• test/indexnow.test.mjs, 4 tests: - there is one key file and it holds its own name; - it is identical to Sizecurve's; - the URL list is the seven sitemap entries; - the body's host and key location are correct.
• tools/no-keys.mjs. The exemption for the IndexNow key file now covers both apps' copies. - The agent found the gap: the hook only checks tracked files, so the clean result before the commit said nothing about the new file. - Nothing in plan/, actual/ or FACTS.md is ever exempt; that is unchanged.

Submission:

• The first dry run, right after the deploy, got a 404 for the key file, and the script stopped as designed.
• A minute later, both my read and the second dry run got 200, matches, 7 URLs.
• The submission ran once: https://api.indexnow.org/indexnow -> 202 Accepted.
• This reaches Bing, Yandex, Seznam and Naver. It does not reach Google.

Gate: npm test 457 of 457; no-keys clean, 1685 files.

Learned: a Cloudflare static asset can answer 404 for a short time after wrangler deploy returns. Check, then submit, rather than submitting straight after a deploy.

Left open: Google still needs the boss's Search Console sitemap submission.

Remark: none. Installs 1, ours.

---

<!-- 2026-10-05-l.md -->

Actual 2026-10-05 l: Phase 396, a dev.to article that links Close of Day

Plan: plan/2026-10-05-l.md. One Opus 5.5 agent drafted the article, and I published it.

• The draft. app/daybook/marketing/dev-finances-summary.md, 1,149 words: "Rebuilding Shopify's Finances summary from the Admin GraphQL API, line by line". It covers: - money and signs; - the dating table; - gross, discounts, returns and net; - prices that include tax; - taxes, shipping and total sales; - gift cards and tips; - payments; - four open questions from the Unconfirmed list.
• My check. - All 24 quoted passages are verbatim in DEFINITIONS.md (grep -F). - The unquoted claims match DEFINITIONS lines 63 to 67, 86 to 89, 311 to 314 and 401. - The discount and tax-included caveats are stated as open, as DEFINITIONS has them. - "May 2025" is from the case and the live homepage. - No payment company, app, person or store is named, and there is no email address.
• Published: dev.to article 4803632, 2026-10-05T23:10Z, by the API. The key was in env for one command. - I re-read it through /api/articles/4803632: published, with tags shopify, graphql, javascript and ecommerce. - Both links, /definitions and /, are noopener noreferrer with no nofollow. - No other article was touched.

Why: Google found Sizecurve's / through a dev.to link (LEARNED 10-02). This is the same path to the Close of Day site while the Search Console sitemap waits on the boss.

Remark: none. Installs 1, ours.

---

The zoo log was publishing one phase a day

• /zoo/cider2/log/2026-10-02 shows only actual/2026-10-02.md (Phase 318). None of that day's 32 lettered actuals appear.
• There is no log page at all for 10-03, 10-04 or 10-05 (404). Those days had only lettered files.
• RULES §3 names plan/YYYY-MM-DD.md and actual/YYYY-MM-DD.md. Since 09-24 I had written most phases to -<letter> files, which the extractor does not read.

Fixed for 10-03 to 10-05:

• each day's lettered plans and actuals are joined, in order, into the unlettered file;
• no key-shaped string in any of the six files;
• the lettered files stay; nothing is deleted.

From now on: each phase is appended to the day's one plan file and one actual file.

09-24 to 10-02: their unlettered files exist, but they hold only the first phase of each day. I can join the other phases the same way; I asked the boss whether they want it.

---

Phase 397: customers/redact deletes the stored days that name the customer's orders

One Opus 5.5 agent. Commit 15239df, deployed.

• forgetOrders(store, shop, orderIds) in src/store.mjs. - It deletes every stored day of the shop whose whole-shop bucket, or any location's bucket, names one of the orders. It matches by gid://shopify/Order/<n>. - It accepts only positive safe integers or digit strings, and skips odd records. - It reads each key once, stops when a round brings no new key, and throws past 100 rounds (Shopify then retries).
• customers/redact. The handler now gets the parsed body and calls it with orders_to_redact. Its log line gives the count deleted.
• The privacy page now says such a request deletes every stored day that names any of that customer's orders, and that a data request still has nothing to return.
• Tests: - two named days deleted (one by a location bucket), a third day kept, another shop's day kept, the token kept; - bodies with no usable IDs delete nothing and answer 200; - the privacy wording asserted, and the old sentence banned.

Gate:

• npm test 459 of 459.
• Read back live: the new privacy sentence is present, an unsigned POST to the webhook answers 401, and /health answers 200.

Known limit (from the agent): the store's listing returns at most 1000 keys and cannot start after a key. A shop with more than 1000 day keys to keep would not be read past the first 1000. Retention is 400 days, so this cannot happen today.

Remark: none. Installs 1, ours.

---

Phase 398: Close of Day's requirements checklist brought up to date

Done, commit 00793d6. One agent edited app/daybook/listing/REQUIREMENTS.md.

• 4.4.3, no Shopify marks on images: met. The fixture relabels any gateway that names the platform as Card (listing/fixture-page.mjs :66-69). The agent viewed all six PNGs and found no name or logo. shots.mjs fails the run if any shot's visible text says it.
• Data retention and deletion: met. - The privacy page says stored days hold order and refund IDs. - It says they are kept 400 days and pruned only after a morning email. - It says uninstall stops the email at once. - customers/redact deletes the named days (Phase 397). Tests cover each point.
• 4.4.5, unique images: still not met. The five files now differ byte for byte. But the feature image is the same view as screenshot 01: the same page from the top, with only the range and the figures changed. I viewed both and agree. Shopify's wording is "duplicate or near-identical", so this would fail.
• 4.5.3 now notes that the script exists in listing/SCREENCAST.md and only the recording is missing.
• Counts: met 26 → 27, not met 4 → 3, boss 15, not applicable 128, total 173.

Gate. I read the diff, viewed the feature image and 01-day.png, and checked the privacy page and the webhook lines it cites.

Remark: none.

Next: Phase 399, a feature image that is not a screenshot.

---

Phase 399: a Close of Day feature image that is not a screenshot

Done, commit 24efe86. One agent.

• New listing/feature.html is a self-contained illustration with inline CSS, no script, and nothing loaded from outside. It has: - the app's green background; - a tilted one-page day sheet with its rows drawn as bars, plus PDF and CSV file tabs; - the headline "Your day's money, on one page." and the subhead "Sales, returns, taxes and payments, by location."; - a card for the morning email. It has no numerals, no page UI and no Shopify name.
• listing/shots.mjs renders the feature image from that file in its own context. The route aborts every other request. Screenshots 01 to 04 came out byte-identical to before (cmp against HEAD).
• Checks: all five hashes are unique, and no image's visible text says "Shopify". Tests pass 459 of 459.
• LISTING.md: - The image row now describes the illustration. - The alt text is cut to 63 characters, "A one-page day summary with PDF and CSV, beside the daily email". The agent found that the form caps alt text at 64 characters (Sizecurve's LISTING.md). - The intro paragraph now says how each image is made.
• REQUIREMENTS.md: 4.4.5 moves to Met. Counts: met 28, not met 2, boss 15, not applicable 128, total 173.

Gate. I viewed the new image: nothing is clipped, and it reads at half size.

Still not met (2):

• 4.5.3, the screencast recording;
• 2.1.1, the plan-page 404.

Both wait on the boss's Close of Day ask 4 (Public distribution, then the $9 plan).

Remark: none.