plan

Continuing day-to-day maintenance on Puzzle Press: no new feature work queued, the app is shipped and selling. Today's phase is upkeep — catch anything the new RULES.md publish-pipeline guard exposed, check crawler/visitor activity for anything actionable, keep the Pinterest queue from running dry, and close out the still-open dev.to provenance question if it's answerable without the boss.

• Sweep plan/, actual/, FACTS.md for the key-shaped strings the new RULES.md rule warns about, since that's a silent, high-cost failure (the boss's publish extractor stops updating the enclosure with no error).
• Check who.mjs for anything new since yesterday's IndexNow submission — looking for Bing/Yandex crawler hits, and for any genuine human visitor.
• Check the Buffer Pinterest queue depth against the standing refill plan in marketing/pins.md; queue the next word-list pin if it's thin.
• Try to resolve the dev.to (dev.to/bananafestdestiny) provenance question myself via public data before leaving it as an open ask to the boss.

RULES.md picked up a new publish-pipeline guard; swept and fixed two real hits

RULES.md changed on disk overnight (not my edit — it's given, I don't rewrite it) with a new rule: the boss's extractor that publishes the enclosure/status page refuses to run while a 32+ hex-char key-shaped string exists anywhere in plan/, actual/, or FACTS.md, and it fails silently — no error, the enclosure just stops updating. It says this blocked publishing for most of 2026-09-19, three times.

Swept all three locations (grep -rnoE '[0-9a-f]{32,}'). Found two real violations in FACTS.md, both pasted verbatim months ago: the Cloudflare account ID from the 2026-09-10 credentials investigation, and the Cloudflare Web Analytics beacon token the boss pasted on 2026-09-16. Redacted both to <account-id>/<token>. Separately found that the extractor itself had already redacted the two IndexNow keys inside yesterday's actual/2026-09-19.md (the real one and the accidental duplicate from the near-miss logged there) — committed that too so the working tree matches what's on disk. Re-swept after both fixes: clean. Committed as 8add92d and 92da63a, pushed.

Saved this as a standing memory (not just a one-off fix) so future sessions never write a bare key/token/account-id into these three files again.

dev.to provenance resolved — it's the boss's own blog

Yesterday's log flagged dev.to/bananafestdestiny as unexplained provenance rather than assuming whose it was. Checked today via WebFetch: the profile page displays as "Walker Brown Profile" — display name "Walker Brown", handle @bananafestdestiny, joined 2026-09-16, 5 posts, all specifically about this project's launch (Product Hunt, the Pinterest block, the spine calculator, the sitemap/indexing situation, and one about a security incident). This is the boss's own build-in-public writing under the studio brand, not a stranger's blog or anything to be suspicious of. No further question to put to the boss here — resolved from public data alone.

Checked crawler activity since yesterday's IndexNow submission

npm run who: still no Bing/Yandex/Seznam/Naver UA showing up yet (only ShapBot/Parallel.ai, SemrushBot, Amazonbot on the word-list pages) — expected, it's been under a day. One genuine-looking human visitor, 223.233.80.15 (Airtel/ABTS Delhi, residential), landed and left without running the app; nothing actionable on its own.

Refilled the Pinterest queue — Thanksgiving pin queued

Had a fork check the Buffer queue depth first rather than assume: 2 of 10 slots filled (the fishing pin sending today, and Tuesday's Halloween pin), nothing scheduled past 2026-09-22 — thin enough to warrant queuing the next one now rather than waiting for it to go empty.

Picked thanksgiving next, same seasonal-relevance logic as Halloween: Thanksgiving is the next holiday-themed word-list page in the rotation and the queue should stay a step ahead of the calendar, not catch up to it after the fact. Word count (50) and sample words (Abundance, Acorn, Apple, Autumn, Blessing, Bounty) pulled from the page's own <meta name="description">, not recalled. Reused 03-word-search.png and the same YouTube-video domain-block workaround as every other pin in the queue. Queued via Buffer (customScheduled, post id 6aaf7863566e1a89bc253778, 2026-09-25 01:00 UTC = 2026-09-24 20:00 CT — roughly the same day-and-a-half-to-two-day gap as the rest of the queue). marketing/pins.md updated: the row added, the unpromoted-page count now 86.

Tested the actual funnel for a bug, since real traffic still isn't converting

traffic.mjs still shows $0 revenue and 0 made-a-book despite real visitors running the app most days. Before assuming that's just low volume, checked whether the golden path itself is actually broken — that would be a much bigger problem than a marketing one. Rather than test against the live site (which would pollute the Web Analytics beacon like the scripts fixed yesterday), started wrangler dev locally and ran the existing test/coldjourney.mjs (a from-scratch mobile visitor, landing to a downloaded PDF, no assumptions) against it: landing to a finished book in 7.9s, accepting every default, no page errors.

That only proves the homepage path works — the actual traffic path from every Pinterest pin is /?theme=<x>#tool, not /, so wrote a one-off local check (not committed — deleted after) hitting http://127.0.0.1:8788/?theme=halloween#tool directly: page loads, scrolls to the #tool section correctly, the download button is present and clickable, no console/page errors (the one console error was a CORS failure on the analytics beacon call, expected on localhost, not a production issue).

Conclusion: the funnel is not broken. $0 revenue and low conversion so far is consistent with genuinely low real-visitor volume (who.mjs still shows single digits of non-bot visitors most days) rather than a bug turning real interest away. Also checked who.mjs for the first time since the IndexNow submission: Googlebot/GoogleOther now shows up on word-list pages too (previously only robots.txt/homepage/the three calculators) — 1-2 requests each, too small to call a trend yet, but it's the first sign of the crawl widening past yesterday's shallow pattern.

GitHub PAT still not rotated — flagging again.

Word-list landing pages were missing the trust signals the homepage has

Continued the funnel-copy audit into the pages real traffic actually lands on. Every Pinterest pin points at /word-lists/<theme> (marketing/pins.md), not the homepage, so checked those pages specifically rather than assuming homepage copy carries over.

Grepped all 91 public/word-lists/*.html for refund/no-sign-up language: zero matches. Compared against the 10 type-generator pages (crossword-book-generator.html etc.), which do carry a "No sign-up" line near their CTA (from scripts/type-pages.mjs) — so this wasn't a site-wide gap, it was specific to the word-list template. Read scripts/word-list-pages.mjs's .actions block directly: confirmed it had no equivalent fine-print line at all, unlike type-pages.mjs.

This is the actual first-impression copy for a cold visitor arriving from a pin with no other context about the site — the exact place "is this safe/a scam/going to charge me" doubt would need answering, and it said nothing.

Added one <p class="fine"> line to the template, matching the site's existing refund wording verbatim (index.html's "30-day refund, no questions asked"): "Runs in your browser — nothing you type leaves your computer. No sign-up. $19 once removes the watermark; 30-day refund, no questions." Regenerated all pages (node scripts/word-list-pages.mjs) — 90 theme pages picked it up (the /word-lists/ index page itself doesn't have this CTA pattern, same as the type-pages template, so correctly excluded). Ran test/wordlists.mjs: still passes, no regression.

Low-risk, template-level fix — one line, reused existing site copy, applies to all 90 current and any future theme pages automatically.

Deployed the trust-signal fix and identified the new dominant crawler

The previous commit only reached git — the site deploys manually (npx wrangler deploy, per README.md), so it wasn't live yet. Ran it (Cloudflare token confirmed still has Workers permission per the 2026-09-10 FACTS.md entry); 90 files uploaded, confirmed live via curl that halloween now serves the new refund line. Resubmitted the sitemap to IndexNow (115 URLs, HTTP 200) since the content on already-indexed pages changed and that's a real signal worth sending, not just new-URL discovery.

npm run traffic showed word-list page visits jump to 271 in 24h (from single digits) — but 0 calculators used, 0 downloads, so checked who.mjs before reading that as real interest. It's a crawler: 170 of those requests are ShapBot/0.1.0 (7 Google-Cloud-hosted addresses), previously undocumented in this project. Looked it up: it's Parallel.ai's crawler for their AI search/extraction API — the same category as the already-allowed OAI-SearchBot/PerplexityBot in ai-crawlers.md (a live-retrieval crawler that drives visibility in AI answers, not a training scraper). It isn't in the managed robots.txt block list and per Parallel's own docs it respects robots.txt, so this is already the correct policy — no action needed, just noting the new name in case its behavior changes later. Also present in smaller numbers: SemrushBot, Amazonbot — both previously known.

No real human conversions in this window (the "MADE A BOOK" rows in who.mjs are this machine's own testing IPs, correctly excluded from traffic.mjs's headline numbers).

Checked Google's actual indexing status directly, not just Search Console theory

npm run traffic has shown Googlebot/GoogleOther crawling for a few days now, so checked whether any of it has converted to actual indexing: WebSearch("site:puzzlepress.bananafest-destiny.com") returns zero pages from the domain itself — only things that reference it (the GitHub repo, the dev.to launch posts). A targeted search for exact copy from the Halloween word-list page found none of our pages either.

Read the dev.to post that already diagnosed this (google-fetched-our-sitemap-21-times-and-indexed-nothing, written 2026-09-14 when the site was 3 days old): conclusion then was this is normal new-domain crawl behavior, not a bug, and to check back after two weeks rather than daily. The site is 9 days old today (launched ~2026-09-11) — still short of that window, and robots.txt/meta-robots/X-Robots-Tag all checked clean (no accidental noindex on our end). So: no new problem found, the existing diagnosis still holds, just noting it's not resolved yet and the two-week mark is 2026-09-25 — worth a real check then, not before.

While checking, confirmed each dev.to launch post does link back to puzzlepress.bananafest-destiny.com (verified the Pinterest-block post specifically) — that backlink channel is already in place, nothing to add.

Also had a fork re-check the Buffer Pinterest queue rather than assume it needed refilling again: 3 of 10 slots filled (fishing 09-21, halloween 09-23, thanksgiving 09-25), spaced ~2 days apart, 5 days of runway from today. Fine as-is — no refill needed this cycle.

Same trust-signal gap on the calculator/guide pages — fixed those too

Extended the earlier word-list audit to every other top-level page: grep -L "refund|30.day|no sign|money.back" public/*.html found four more missing it entirely — royalty-calculator.html, spine-calculator.html, margin-calculator.html, how-to-make-a-puzzle-book.html. These are hand-written (no generator script, unlike the word-list/type pages), and these calculators specifically are exactly the kind of page that ranks for high-intent commercial searches ("KDP royalty calculator" etc.) from someone who has never seen the rest of the site and is actively comparing tools — the same first-impression gap as the word-list pages, just on different pages.

Added the same line to each CTA block: "No sign-up. $19 once removes the watermark; 30-day refund, no questions." royalty-calculator.html had no .fine CSS class defined (unlike the generated pages), so used an inline font-size:13px instead of inventing a class for one line; matched that same inline style on the other three for consistency, since none of the four define .fine. Re-swept afterward: every page in public/*.html now carries at least one trust-signal phrase.

npm test (93 tests) and test/copy.test.js (8 tests) both pass — no regression. Deployed live (wrangler deploy, 4 files), confirmed via curl on /spine-calculator and /how-to-make-a-puzzle-book.

GitHub PAT still not rotated — flagging again.

Listed Puzzle Press in a self-published-author tool directory

who.mjs showed nothing new since the last check, so looked for a distribution channel not yet tried rather than repeat the same audits. WebSearch turned up author.directory — a hand-curated directory specifically for self-published-author tools (269 tools, 30+ categories), with an explicit open call to submit anything missing: free, no login, no fee, reviewed by hand, and states affiliate relationships never affect inclusion. Checked FACTS.md/LEARNED.md/marketing/*.md first — no prior mention, genuinely untried.

Treated this the same as the IndexNow/sitemap-ping class of action (a factual listing of our own product on a service that explicitly invites it), not the "boss posts in his own voice" class (Reddit/HN) — nothing here represents the boss personally or posts into a community he'd want to be seen posting in.

curl+grep on /submit showed a Next.js app shell with no plain HTML form visible — confirmed with a quick headless-browser (Playwright) inspection that the real fields are server-rendered late: name (tool name), url, category (30-option dropdown), description, optional pricing and submitter_email, plus a hidden company field that's a spam honeypot (left blank). No plausible curl/POST path, so filled and submitted via Playwright directly against the live site.

Submitted: Puzzle Press, puzzlepress.bananafest-destiny.com, category Formatting & Layout (closest fit — generates the print-ready interior layout, not just cover/marketing assets), description factual about what it does and that it runs client-side, pricing "Free (watermarked); $19 once to remove watermark", contact support@bananafest-destiny.com. Confirmation page: "Got it — your tool is in the review queue." No stated review turnaround, so nothing to check back on soon — noting it here in case it shows up in referral traffic later. Scratch Playwright scripts used to inspect and submit the form were deleted after use, nothing left uncommitted.

GitHub PAT still not rotated — flagging again.

Tried the same directory-submission approach on SaaSHub — it rejected the submission

Looked for a second directory in the same class as author.directory: a free, no-login, self-serve "submit your product" form. saashub.com/services/submit fit (single URL field to start, no account required) and is a large, general software-alternatives directory (245k+ listed products) rather than an author-niche one, so a different audience than this morning's listing.

Submitting the URL auto-advanced to a real form that had already scraped our own site copy (auto-filled product name "KDP Puzzle Book Generator" from our <title>, and a tagline pulled near-verbatim from our meta description) — confirms the crawl-based auto-fill is reading our page correctly, at least. Corrected the name to "Puzzle Press" per their own instruction ("direct product name, not an explanation"), kept their auto-pulled tagline, picked three category matches from their live autocomplete (Puzzle, Self-Publishing Tools, PDF Tools), added the support email, and submitted on the free tier (declined the $75 paid "Priority+" tier — no reason to pay for placement on an unproven channel).

The submit came back with a generic "There was something wrong. Please try again." and the form reset to its scraped defaults — a real server-side rejection, not a client-side mistake I could see (no field flagged, no validation message pointing anywhere). Possible causes: bot/ automation detection on a headless browser, or a hidden rule I can't see from the form alone. Deliberately did not retry blindly — repeated failed POSTs to a real external form is the kind of thing that can get an IP or domain flagged as spam on their end, and guessing at the cause with more automated attempts isn't obviously worth that risk for one directory listing. Leaving this as a discovered-but-unsubmitted lead rather than pushing further; author.directory's clean submission today already used the same class of action successfully, so the approach itself is sound — this one specific site's form is the open question, not the pattern.

Deleted the scratch Playwright scripts; nothing submitted, nothing to verify.

GitHub PAT still not rotated — flagging again.

Turned the trust-signal audit into a test, and it immediately found a third gap

The last two fixes (word-list theme pages 2026-09-19, four hand-written calculator/guide pages this morning) were both found the same way: grep everything by hand, fix what turns up, hope nothing was missed. That's not a fix, it's a habit — so instead of doing a third manual pass, added a test to test/copy.test.js: any page carrying a class="btn" button whose href (query stripped) is / or /#tool — i.e. an actual "make a book" button — must contain refund/no-sign-up language somewhere on the page.

First run failed immediately: public/word-lists/index.html — the word-list collection page, which both earlier audits explicitly logged as correctly excluded ("doesn't have this CTA pattern, same as the type-pages template"). That reasoning was wrong both times; it has its own .cta block with its own "Make a word search book free" button (scripts/word-list-pages.mjs line ~199), just missed by eye because it looks different from the per-theme page layout. Fixed the generator template (not just the output file, so it survives the next regen), added the same fine-print line used everywhere else, regenerated, reran the full suite: 94/94 pass, up from 93 (the new test plus the fix).

Deployed live (1 file, word-lists/index.html), confirmed via curl. This is the better fix of the three — the first two were one-off corrections, this one is a standing check that would have caught all three gaps from a single run, and stays in place for whatever page gets added next.

GitHub PAT still not rotated — flagging again.

Identified a new crawler, then ran the live-site health checks after today's deploys

npm run who: still no real human visitor, but a name not seen before — SofyaBot/1.0 (+https://sofya.co/bot), 7 requests. Checked its own docs: it's an independent AI-agent search API (not affiliated with any of the major labs), respects robots.txt, crawl-delay, and backs off on 429/503/509. Same category as ShapBot/OAI-SearchBot/PerplexityBot under the existing marketing/ai-crawlers.md policy (allow live-retrieval agents) — already correctly unblocked, no action needed. Traffic on word-list pages from non-running visitors keeps widening (53 addresses this window, up from 30 two windows ago) — all identified crawlers so far, nothing unexplained.

Four deploys have gone out today (trust-signal fixes ×3, the regression test's own fix). Hadn't run the live health checks against any of them, so ran both: test/links.mjs against the production domain — 103 pages, 404 internal links/assets checked, 0 bad. test/seo.mjs — 103 pages, 100 share images, 0 problems. Nothing broke across today's changes.

GitHub PAT still not rotated — flagging again.

Confirmed the queued YouTube Short published; found an unlogged second app on the same channel

Traffic is still zero real visitors — who.mjs this cycle showed only crawlers (SofyaBot again, plus a new one, Lightpanda/1.0 from NTT America, 5 requests, landed and left — not yet looked into). Rather than start a new distribution channel from scratch, I went back and checked an existing one: FACTS.md records the boss approving ("do it") a Buffer-queued YouTube Short on 2026-09-11 alongside the five Pinterest pins, but nothing in FACTS.md or LEARNED.md ever confirmed it actually posted.

WebFetch on the channel's videos page came back empty — YouTube channel pages are client-rendered and don't yield anything to a markdown fetch — so I queried Buffer's own post history instead (get_account → list_channels → list_posts) via a read-only fork.

All 4 posts on the Bananafest Destiny channel show status "sent," none errored:

• puzzle-press-short.webm — sent 2026-09-11T23:48:02Z. This is the Short in question. Confirmed published.
• five-types-short.mp4 — sent 2026-09-14T00:10:02Z.
• The manually-uploaded landscape walkthrough (youtu.be/ph6q2ih6cBs) — posted 2026-09-11, already confirmed live in a prior log.
• A fourth post, customScheduled with a direct youtube.com/watch URL, posted 2026-09-15: youtu.be/ujpebRPm6CI. This one is not Puzzle Press marketing — it's for "Bulkhead," a browser deck-plan editor for sci-fi tabletop RPGs (bulkhead.bananafest-destiny.com / itch.io).

Bulkhead isn't mentioned anywhere in FACTS.md, LEARNED.md, or any plan/actual entry, and it's a second app sharing the Bananafest Destiny YouTube channel while I'm still committed to Puzzle Press under the one-app-at-a-time rule. I didn't make this post and have no record of touching Bulkhead — it reads like something the boss did directly (same pattern as the manual landscape upload to YouTube Studio), outside this repo. Not treating it as my problem to fix or investigate further; flagging it here as a fact worth the boss's attention rather than acting on it unilaterally.

GitHub PAT still not rotated — flagging again.

Re-ran IndexNow after today's deploys; scoped out three directory leads

scripts/indexnow.mjs (built 2026-09-19) had only ever been run once, before today's four deploys (trust-signal fixes on three pages, one of them the word-lists index). Re-ran it (npm run indexnow) so Bing/Yandex/Seznam/Naver see the changed content instead of waiting for their own crawl schedule — 115 URLs submitted, HTTP 200. Zero cost, no judgment call needed, matches the existing IndexNow policy exactly.

Also spent time looking for a second easy directory win like author.directory (SaaSHub, the other real attempt, rejected the submission and wasn't retried). Checked twelve.tools, findly.tools, startupfa.me, sideprojectors.com. None panned out as same-class actions: findly.tools and startupfa.me require an account to submit at all; sideprojectors.com's submission page is client-rendered and didn't yield anything to inspect without deeper Playwright work; twelve.tools' free tier isn't a plain form submission like author.directory was — it requires adding a dofollow backlink to twelve.tools somewhere on our own site (homepage or footer) as a condition of listing. That last one is a different kind of decision than filling out someone else's form — it means putting a permanent outbound link on our own pages for a directory's benefit, which trades off our own SEO authority. Not doing that unilaterally; leaving it as a lead, not attempting it.

GitHub PAT still not rotated — flagging again.

Identified Lightpanda/1.0, and started checking whether Pinterest pins are actually reaching anyone

Lightpanda/1.0 (NTT America, 5 requests, landed and left) showed up again in who.mjs, same as the prior cycle. Looked it up: it's an open-source headless browser engine built in Zig for AI agents/automation (Chrome DevTools Protocol compatible, so existing Puppeteer/Playwright scripts can point at it) — not a single company's named crawler with a stated identity or bot policy the way SofyaBot or ShapBot were. There's no operator to clear against marketing/ai-crawlers.md's allow-policy; it's infrastructure anyone could be running. Five requests, landed and left, nothing concerning — logging it and moving on, not treating it as an open question.

Still zero real human visitors after another full cycle. Rather than keep chasing individual crawler names, went looking for a more useful diagnostic: whether Pinterest pins (queued since 2026-09-14, against a backdrop of a denied spam-block appeal from 2026-09-12) are getting any real impressions at all, or whether the block is silently suppressing them. Kicked off a read-only Buffer check (post history + aggregated metrics for the Pinterest channel) — still running as of this entry; result to follow in the next cycle if it lands late.

GitHub PAT still not rotated — flagging again.

The Pinterest metrics check landed: the spam flag is suppressing every pin since the first one

13 pins have gone out on bananafestdestiny between 2026-09-11 and 2026-09-19. Only the very first one (2026-09-11, before the spam flag hit on 2026-09-12) shows any activity at all: 5 impressions, 0 saves. Every pin since — 11 to 12 of them, over 8 days — shows exactly 0 impressions, 0 saves, 0 comments, 0% engagement. Not low, zero. All the metrics carry the same fresh metricsUpdatedAt timestamp, so this is real returned data, not an empty/unpopulated field.

This isn't a "give it time" pattern — impressions never recovered across 7+ more posts and 8+ days. It matches exactly what a spam-flagged account would look like: pins accepted into the queue and marked "sent," but never actually surfaced to anyone. This is a real, confirmed answer to part of why site traffic is still zero — one of the two active distribution channels (the other being the YouTube Short/video posts, not checked this cycle) has been producing nothing since day two.

I'm not stopping the standing refill plan in marketing/pins.md on my own — the appeal itself needs the boss (filed through Pinterest's own account tools, same as the first denied attempt on 2026-09-12), and the plan already says "around mid-October" for that. But I want this surfaced clearly rather than buried: continuing to spend time writing new pin captions for a suppressed account is low-value until the appeal is actually re-filed and resolved. Flagging this as worth the boss's attention on its own terms, not just logging it and moving on.

GitHub PAT still not rotated — flagging again.

Checked YouTube metrics too, for symmetry with Pinterest — different shape of problem

Same read-only Buffer check, applied to the Bananafest Destiny YouTube channel's 3 Puzzle Press posts. Unlike Pinterest, YouTube is not suppressed — real, non-zero views:

• Landscape walkthrough (youtu.be/ph6q2ih6cBs, 2026-09-11): 8 views.
• puzzle-press-short.webm Short (2026-09-11): 24 views.
• five-types-short.mp4 Short (2026-09-14): 8 views.

40 views total, 0 likes/comments on any of them.

Worth noting: the unrelated Bulkhead post on the same channel (2026-09-15, flagged in an earlier entry today) has real engagement — 73 views, 2 reactions — more than all three Puzzle Press posts combined. Not analyzing that further, it's a different app.

So this is a different shape of problem than Pinterest. It's not a platform suppressing the content — 40 real views happened. But who.mjs has shown zero real site visitors this entire window, which means none of those 40 viewers clicked through. That's a funnel gap, not a distribution gap: people are seeing the videos and not acting on them. I haven't looked at what the video descriptions/end cards actually say or link to yet — that's the natural next thing to check, not done this cycle.

GitHub PAT still not rotated — flagging again.

Found the specific funnel gap in the YouTube videos: the link is real, but Shorts hide it

Pulled the verbatim published text for all 3 Puzzle Press YouTube posts. The link is genuinely there, correctly placed, on every one: https://puzzlepress.bananafest-destiny.com appears as plain text early in each caption (2nd paragraph on both Shorts), alongside the how-to-guide and calculator links. This isn't a missing-CTA bug like the word-lists page was — the copy is fine.

The actual problem: YouTube doesn't render Shorts description text as clickable in the player. It only shows up if the viewer taps to expand the description below the video, which most Shorts viewers never do — that's a platform UX fact, not something in our control. Neither Short has any on-screen text or spoken cue telling the viewer the link even exists in the description (checked the post text only, not the video frames themselves, but the recording script per actual/2026-09-11.md describes captions and an end card stating the free tier, not a "link below" callout).

This is a concrete, specific fix for the next video, not a vague one: bake an on-screen "link in description ⬇" (or similar) cue into the end card of future Shorts. Also ran the full test suite as a sanity check while doing this — 94/94 pass, nothing regressed today. Not attempting a video re-record this cycle — it's a real production task (re-render, re-encode to both WebM/MP4, re-upload via Buffer), better scoped as its own piece of work than squeezed into the remainder of this one.

GitHub PAT still not rotated — flagging again.

Correction: the videos DO have an on-screen link — I hadn't actually checked before saying otherwise

Last entry said "neither Short has any on-screen text ... telling the viewer the link even exists," explicitly caveated as "not checked here — only post text was reviewed." Went and actually read scripts/video.mjs (the generator both Shorts came from) this cycle: it builds an end card (lines 226–234) that displays puzzlepress.bananafest-destiny.com as large white-on-navy text for 3.6 seconds (Short) or 4.2s (landscape). That's a real, correct on-screen source of truth — the earlier claim was wrong, and I'm correcting it rather than letting it stand.

So the gap isn't "no on-screen cue" — it's that the URL is shown as static text you'd have to pause, remember or write down and then type by hand; there's no tappable link anywhere in a YouTube Short's actual viewing surface. Shorts do render pinned comments as clickable links, unlike the description. Checking now (still running as of this entry) whether Buffer's API can add/pin a YouTube comment — if not, a pinned comment with the bare URL on both existing Shorts is a 10-second thing the boss could do directly in YouTube Studio/the app, and worth handing off as a concrete ask rather than something I keep chasing through Buffer.

GitHub PAT still not rotated — flagging again.

Confirmed: pinning a YouTube comment is outside Buffer's API — a real ask for the boss

Checked Buffer's GraphQL schema directly (introspect_schema). The Mutation type only has post/content-item/template/idea operations (createPost, editPost, deletePost, movePostInQueue, the ContentItem/PostTemplate/Idea CRUD) — nothing for comments. There are comment-*adjacent* types belonging to Buffer's separate "Engage" product config, but no Query field to list comments and no Mutation field to post or pin one. This isn't a permissions gap, it's not reachable through this API at all.

So the concrete ask, not something I can do myself: pin a comment with puzzlepress.bananafest-destiny.com on the two live Shorts — youtube.com/shorts (search "Puzzle Press — a KDP puzzle book in under a minute" and "Five kinds of KDP puzzle book, one tool" on the Bananafest Destiny channel) — comment, then use YouTube's own "Pin" option. Takes seconds in the app or Studio, and unlike the description or the end card, a pinned comment is an actual tappable link in the surface people are already looking at. This closes the loop on the funnel-gap investigation that ran across today's last several cycles: Pinterest is confirmed suppressed (a boss-only appeal fixes that); YouTube reaches real people (40 views) but has no tappable path to the site (a boss-only 10-second fix closes that, since Buffer can't do it for me).

GitHub PAT still not rotated — flagging again.

Ran the live checkout health check — the money path is still intact after today's five deploys

test/livecheckout.mjs hadn't been run today, and five deploys had gone out since it was last checked (09-19). With distribution-side investigation mostly handed off to the boss now (Pinterest appeal, pinned comment), this was the other direction worth checking: whatever traffic does eventually land, does the actual purchase path still work.

Ran it against production — safe by design, tags its own session (selftest-) so it doesn't read as an abandoned customer on the dashboard. Buy link correct, opens a new tab with rel=noopener, checkout shows "Puzzle Press Unlimited" at exactly $19.00, no sandbox badge, no stale "per unlimited" copy, card form mounts. Tag confirmed on the live session via the Stripe API. LIVE CHECKOUT OK (not paid). Nothing broken.

GitHub PAT still not rotated — flagging again.

Ran the mobile suite too — last checked 09-19, and most social traffic will land on a phone

Same reasoning as the checkout check: today's five deploys were all text/copy edits (trust-signal lines, generator template), low risk, but test:mobile hadn't confirmed that against the live site since 09-19, and every current distribution channel (Pinterest pins, YouTube Shorts) sends whoever does click through straight to a phone screen. Ran all three combos against production:

• webkit, iPhone 13 (390px) — OK
• webkit, iPhone SE (320px) — OK
• chromium, Pixel 7 (412px) — OK

Each makes a real crossword book and cover on the phone, nothing overflows or truncates, controls stay thumb-sized. Nothing broken. Between this and the checkout check, both ends of the actual money path — arrival and purchase — are confirmed intact as of today's deploys.

GitHub PAT still not rotated — flagging again.

Re-audited Stripe for any real checkout activity since the 09-19 audit

09-19's log found a real, untagged abandoned-checkout pair from 9/15 and traced two live trust gaps from it (a tax-surprise line, and the already- settled "Pay Walker Brown" name — not re-litigating that one, it's a known fact per FACTS.md). Worth checking whether anything new has happened since. Queried Stripe directly (restricted key, extracted via the safe grep '^STRIPE_KEY=' pattern, not sourced) for every checkout session created in the last 26 hours: one session total, and it's mine — the selftest-20260920T230734 tag from today's livecheckout.mjs run. No untagged, no real customer activity since the last audit. A clean negative, not a new finding — logging it so "has anything changed" doesn't have to be re-asked from scratch next time. Scratch script written to the session scratchpad and deleted after use, nothing added to the repo.

GitHub PAT still not rotated — flagging again.

The boss posted to r/KDP — and real people showed up within minutes

The boss posted Puzzle Press to r/KDP from u/HeadroomDevs. Not the draft in marketing/reddit-kdp.md — the live post is titled "PuzzlePress", the body is "New puzzle generator!!!" and a bare link. 22 views, 1 upvote, 0 comments at three minutes old.

Checked traffic immediately. who.mjs (last 1h) found two consumer-ISP visitors who ran the app and stayed — Uniti Fiber Holdings on Chrome 153 (Mac, 14 requests) and Buckeye Cablevision on an iPhone running iOS 18.7 (10 requests). Both are residential ISPs on current browser builds, which is the exact fingerprint who.mjs was written to identify as a person rather than a crawler. After nine days of this number being zero, that is the first real human traffic I can point at.

And then the funnel, from traffic.mjs (last 2h): 3 ran the app, 2 did not bounce, 0 clicked Download, 0 made a book, 0 started a checkout. They landed, they stayed, they left without generating anything.

Three minutes is too short a window to call that a conversion failure — it may simply be people still on the page. But it is the first time the question has been askable at all, so it is the number to watch tonight, and the one worth logging before it gets buried.

The actionable gap is the post itself, not the product. 22 views in three minutes means the subreddit feed is actively showing it — and the body gives a reader no reason to click: it does not say it is free, does not say what it makes, does not mention print-ready KDP interiors or the spine width. That is the boss's call and their account, so it goes to them as an ask, not as something I do: edit the body (Reddit text posts stay editable) or add a first comment with substance. The spine-calculator angle in marketing/reddit-kdp.md is already written for exactly this and can be pasted as a comment as-is. Second risk worth naming: a bare-link promo post from a low-history account is the first shape r/KDP mods and spam filters remove, so the window may be short.

GitHub PAT still not rotated — flagging again.

Found why nobody downloads: on a phone the button is 5.4 screens below the CTA

The r/KDP post put real people on the site, so for the first time the question "where do they give up" had data behind it instead of speculation. The funnel said: ran the app 4, did not bounce 2, Clicked Download 0.

First guess was the landing page. Screenshotted the live site on an iPhone 13 viewport and that guess was wrong — the first screen is fine. It says what it makes, says "free", says "no sign-up", and both CTAs are above the fold without scrolling. Nothing to fix there.

So I tapped "Make a book free" the way a visitor would, and measured what happens next. The CTA jumps to #tool, which is the top of the form — eight-plus fields of puzzle type, title, subtitle, author, trim, count, price, ink, paper, two checkboxes and a 20-theme checkbox grid. #download sits at y=4767 with the form starting at y=1175: 3,592px, or 5.4 full phone screens of scrolling, with no button, no preview and no payoff visible anywhere in between.

The part that makes it a real defect rather than a layout quibble: every field is already filled in. Animal Word Search, 50 relaxing puzzles with solutions, 6"x9", 50 puzzles, $9.99. The book is finished the moment you arrive. The visitor just has no way to know that, after a hero that promised "a finished KDP puzzle book, in about a minute." What they get instead is homework, and the honest reading of "stayed, then left without downloading" is somebody scrolling a form looking for the payoff and running out of faith.

Fix shipped: a phone-only sticky bar carrying the existing primary action down the form — "Download interior PDF" plus "Free — watermarked". Deliberately not a second download path: it forwards the click to the same #download button, so there is one handler, one funnel signal, and nothing to keep in sync. It stays off-screen at the hero, rises once the form is genuinely what you are looking at, and drops back down when the real buttons scroll into view, because two identical Download buttons on screen at once is worse than none. Desktop is untouched — the preview already sticks there and the button is one short scroll away.

Considered and rejected: adding an analytics event for "interacted with the tool" to measure the middle of the funnel. The dashboard reads the funnel out of the request log with no beacon and no analytics script, on purpose, because the site promises nothing you type leaves your browser. A ping invented purely to be counted is a beacon wearing a costume, and the question it would have answered I could answer for free by driving the tool on a phone myself — which is what I did, and it gave a better answer than a counter would have.

Verified: npm test 94/94; all three test:mobile combos (iPhone 13, iPhone SE, Pixel 7) pass against the build with the bar in; new test/thumbbar.mjs (npm run test:thumbbar) passes locally and against production after deploy — it presses the bar and insists a real PDF comes out, because a renamed id would break the forward silently. Deployed with wrangler deploy, version da239520.

GitHub PAT still not rotated — flagging again.

The same gap existed on desktop — and one of tonight's two visitors was on one

Having shipped the phone bar I went back and measured the case I had not: desktop. One of the two real visitors tonight was a Mac on Chrome 153, so this was not hypothetical.

Measured against production at 1280x800 and 1440x900:

• form top #tool at y=671, #download at y=3580 — 3.64 screens below it (3.23 screens at 1440x900). The same defect as the phone, slightly smaller.
• but the preview section sits at y=695 and the puzzle itself at y=749, i.e. right at the fold, because .preview-stick is sticky above 800px wide.

So desktop and phone fail in opposite halves. A desktop visitor can see what they are making — the live puzzle follows them down the form — but cannot act on it without scrolling 3.6 screens away from the thing that convinced them. A phone visitor had the reverse problem: the preview is 6.00 screens below the form top, so they never see the puzzle at all. The bar shipped earlier gives the phone the action; it still does not give it the proof.

Fix shipped: a "Download this book" button inside the sticky preview header, beside the live puzzle and the "50 puzzles · 6"x9" · 66 pages" meta line. Desktop only — on a phone the fixed bar already covers that ground and a second button would just be something to scroll past twice. Forwards to #download exactly like the phone bar, so there is still one handler and one funnel signal. Bound before the IntersectionObserver guard, because unlike the bar it needs no observer and should survive a browser without one.

Extended test/thumbbar.mjs to cover both halves rather than writing a second test, since it is one feature — "the download is reachable from wherever the visitor actually is". The desktop half asserts the puzzle is still on screen (if the sticky preview ever breaks, the button's whole justification goes with it), that the real #download is genuinely off screen at that scroll position (otherwise the check proves nothing), that the header button is reachable, and that pressing it yields a real PDF. It also asserts the desktop button stays hidden on a phone.

Verified: npm test 94/94; test/mobile.mjs iPhone 13 and iPhone SE pass against the build; test:thumbbar passes locally and against production after deploy. Deployed with wrangler deploy, version 6237a4f1 — 1 file changed, 264 already present, confirming only index.html moved.

Still outstanding and still not mine: the two YouTube pinned comments and the Pinterest re-appeal. Comment text for all three videos handed over.

GitHub PAT still not rotated — flagging again.

Phones now get the proof, not just the button

Closing the half of tonight's finding that was still open. The sticky bar gave a phone visitor the action; it did nothing about the proof. Measured earlier: on an iPhone 13 the preview sat 5.95 screens and the puzzle itself 6.00 screens below the top of #tool, so somebody arriving from the r/KDP post tapped "Make a book free", got a wall of form, and never once saw a puzzle.

The fix turned out to be almost free, because of how the page is already built: the hero CTA points at #tool, and #tool is <main> — the form and the preview are its two grid children. So reordering the children on a phone moves the proof to where the CTA already lands, with no anchor change, no JS and no DOM move. Puzzle first, form second, "How it works" third. Desktop is untouched: above 800px the two columns sit side by side and the sticky preview already put the puzzle at the fold.

Result on an iPhone 13: the puzzle went from 6.00 screens below #tool to 0.08. One tap from the post now gets you a finished word search, the "50 puzzles · 6"x9" · 66 pages" line, and a Download button pinned underneath.

A bug I caused and caught in the same cycle. The first version used a bare .preview { display: contents } inside the mobile media query, and measuring showed the order coming out puzzle -> how-it-works -> form, which is not what I wrote. Cause: the base .preview { display: flex } rule sits further down the same stylesheet at equal specificity, so source order won and the section stayed a single grid item, dragging "How it works" along with the puzzle. Changed to main > .preview so specificity decides rather than position, and re-measured to confirm puzzle -> form -> how. Worth recording because the symptom was a layout that looked plausible in a screenshot — only the measured y-positions showed the rule had not applied at all.

Extended test/thumbbar.mjs again rather than adding a fourth browser launch: it now asserts the puzzle is within one screen of #tool on a phone, that the form is below the puzzle, and that "How it works" is below the form. A CSS order swap is exactly the kind of thing a later layout edit silently undoes.

Verified: npm test 94/94; all three test:mobile combos pass against the reordered build (they make a real crossword book and cover on the phone and check nothing overflows); test:thumbbar passes locally and against production. No horizontal overflow at 320px, 390px or 412px. Deployed with wrangler deploy, version e2cd8617 — 1 file changed, 264 already present.

Where this leaves the funnel: a stranger arriving from the r/KDP post on any device now sees a finished puzzle and a reachable Download button within one tap. Tonight that path was 5.4 screens of scrolling on a phone with no puzzle at the end of it, and 3.6 on a desktop. Whether it converts is a question only the next visitor answers.

GitHub PAT still not rotated — flagging again.