Answer keys at 7 pt for any grid size, and a page count that tells the truth about it

Done 03:00Z: answer pages keep 7 pt at every grid size. The answer pages now step down (6, 4, 2, 1 a page) until the book's biggest grid fits at 7 pt. The page planner doesn't wait for the book to exist to know that grid: it uses the biggest grid the settings can produce (src/generator/gridbound.js). A typed size is itself, a criss-cross or crossword is its level's size + 2, and an automatic word search uses the size its longest words would get. The on-screen page count, the PDF and the cover's spine all use that one number. Each layout is judged at the gutter of the book it would make.

• test/kdplines.mjs now fails anything under 7 pt (it used to fail under 6.63) and renders typed 21×21 and 30×30 books. Green at all six trims (the default since 03:30Z; it used to run three).
• invariants.test.js has a big-grid case (typed 30 on 5×8, graded criss-cross on 5×8, 200 pages' worth of gutter) and checks predicted pages against rendered pages.
• inkcheck.mjs predicts from the book's own biggest grid.
• New test/biggrid-live.mjs (npm run test:biggrid), against the live site: typed 30×30 on 5×8, 20 puzzles. The tool shows 48 pages, the PDF has 48, and the cover is sized for 48. On the old code the tool would have said 34.

Cost, measured: automatic word searches, 90 lists × 4 difficulties × 50 puzzles. On 5×8, 141 of 360 go from 4 answers a page to 2 (+12 pages). On 5.5×8.5 and 6×9 some step down. 7×10, 8×10 and 8.5×11 are unchanged. Part of that is the bound being above the grids actually drawn. A tighter bound is possible, but not worth building while nobody is buying 5×8 books.

Left as is: the calculators' "opens the generator with N pages" note (tool-link.js) still assumes the old density. When a book's grids make the answer pages step down, that note can be a few pages low. The generator shows the real count as soon as it opens. Wrong, and fixed 05:20Z: measured live it was up to 20% low, not a few pages (below).

Done 03:40Z: the README states KDP's measurable rules and how each is tested. The GitHub page is what a brand search shows first, and until now it said "solutions packed 6-up (4-up on small trims)", which stopped being always true today. It now quotes the three rules kdplines.mjs checks and says what inkcheck.mjs checks. kdplines.mjs covered 3 trims by default and now covers all 6, because the README says "every trim".

Done 03:50Z: sample covers are sized from their own interiors. scripts/sample.mjs used to size each cover with a separate planPages call, the kind of hand-kept prediction that drifted in inkcheck.mjs today. It now reads the book's page count before the promo page is added. Regenerated output: same page counts and cover sizes; only the creation dates differ, so nothing was redeployed.

State 03:05Z: no new human visitors in 23.5 hours besides the Portugal visitor already logged. /go/ arrivals are 0. dev.to's last post is still 09-25, so 09-26 and 09-27 are queued.

Done 05:20Z: the calculators' page count matches the generator again. The royalty, spine and margin calculators each hand a book to the generator and say how many pages it will be. I opened 48 of those links live and read the page count the generator showed: 16 were wrong, all on 5×8 and 5.5×8.5. A 110-page 5×8 book from the royalty calculator opened at 130 pages. That is past KDP's 110-page flat printing price, so the royalty the visitor had just worked out no longer applied. The cause was mine from 03:00Z: the generator opens on the animals list, whose grids reach 19×19, and on those two trims that needs fewer answers a page. tool-link.js now plans with the same grid bound (OPENS_WITH_GRID, held to gridBound() by invariants.test.js) and the same per-book gutter. Live after deploy: 0 of 60 links wrong (6 trims, bleed on and off, 24 to 300 pages). spine, royalty, margin and calclink tests pass.

State 05:20Z (Buffer, "My organization"): the large-print Short went out 09-27 00:30Z, 0 views after 4 minutes. Last metrics read: royalty 68, spine 24, groundwood 12. Nothing is scheduled. Beacon, last 7 days: 90 page loads, 10 from the Reddit app, landings /, the guide, the royalty and margin calculators.

Done 06:10Z: two published pages had numbers the 7 pt change made wrong. After the calculators, I checked every published "N puzzles = M pages" and "answers to a page" claim against the planner.

• /how-to-make-a-puzzle-book said 5.5×8.5 packs six answers a page (122 puzzles = 150 pages) and 5×8 crosses the 150-page gutter line at 115. That is still true for sudoku and mazes. A word search from the default list (grids up to 19 across) crosses it at 115 on 5.5×8.5 and 96 on 5×8. The sentence now says so; every number in it was recomputed.
• /large-print-word-search-generator priced a 6×9 book at six answers a page (50 puzzles = 66 pages), which that preset can't make. This one predates today: large print has put one answer a page since 09-25. It now prices the 8.5×11 book: 48, 108 and 208 pages for 20, 50 and 100 puzzles, which is $2.84, $2.84 and $4.54 to print. Every type page's fine print said "about a penny a page". It now gives the rate, read off printingCost (1.2¢ regular, 1.7¢ large trim).

The other five type pages' 6×9 tables were right: every difficulty's grid bound (up to 19) still packs six a page at 6×9. Deployed, the live md5 of all three pages matches local, sitemap updated, IndexNow sent.

Visitors: two single-request sample-cover fetches from consumer ISPs (Deutsche Telekom, Colombia Telecom; RDAP-checked). They look like search arrivals. Both covers carry the /go/sample link and a proper Title. No /go/ hits yet.

Done 07:30Z: the cover redesign (the boss asked whether covers should be more generally appealing). There are eight palettes chosen by the title, the book's own puzzle on the front with an answer marked, and a selling strip. It's deployed, and the md5s of the samples and main.js match. These pass: coverink (band-relative, mutation-checked), freecover, browser, mobile, pdfcheck, sample-promo and kdplines. The colour picker shipped 07:55Z (select under Paper; unit test holds its options to PALETTES; live check picked plum and forest and the downloads came back those colours). Still possible: a back-cover puzzle that differs from the front one.

Done 08:20Z: the landing page shows the new covers: cover-row.webp (63 KB, lazy), five sample fronts, each linked to its PDF. It's deployed, the md5s of the index and webp match, and IndexNow was sent. Browser, mobile and thumbbar pass. No new humans since the Portugal visitor on 09-26. Watch whether the sample-cover links from the landing page get clicked (they show in who as "opened").

Done 08:45Z: demo.gif re-recorded against the live site (21 frames, 664 KB). It's deployed and the md5 matches. The app README shows the cover row and describes the new cover. Next time: the back cover could show a second puzzle; YouTube/Buffer footage of covers waits for the no-new-film date (~10-02).

Done 09:10Z: the share card (social-card.png, og/twitter image on 4 pages) now reads "Puzzle books" across five types with three fanned covers (tomato in front; navy disappeared on the navy ground). It's ?v=2026-09-27 cache-busted and deployed. The exact URL served the old file once right after the deploy (propagation), then matched.

Done 09:40Z: cover colour swatch beside the select, and the automatic option names its colour. The palettes are now in src/pdf/palettes.js (hex only, no pdf-lib); cover.js maps them, and the render is pixel-identical at 50 DPI. It's deployed, and the md5s of index and main.js match. Browser caught a 2px clip at 400px on "Picked from your title (forest green)"; shortened to "From your title (…)". Browser and mobile pass. Next: back-cover second puzzle, or check dev.to for the 09-26/27 posts.

Done 10:15Z: back cover shows puzzle 2, unsolved (drawHero plain), on a front-style card with shadow; blurb box also shadowed; drawMini* removed. The UI builds n2 = 2 puzzles (1 if the book has 1) with gradeCount: s.count. The first version didn't pass gradeCount: graded P2 differed for sudoku and crossword, caught by a prefix check before any user saw it. That check is now in cover.test.js (mutation-verified, 108 pass). Samples regenerated, fronts unchanged. It's deployed and the md5s of main.js and the samples match. Browser, mobile, freecover, biggrid-live, coverink and sample-promo pass. No new humans today; dev.to has had no posts since 09-25.

Done 10:50Z: test/coversafe.mjs (npm run test:coversafe), KDP's cover text rule quoted verbatim from G201953020. It checks the 4 outer edges; coverink already did barcode and spine. 198 covers pass. Threshold 232 is measured: the brightest edge art is 227 (rust strip) at 150 and 300 DPI, and the faintest cover type is the sample stamp's 0.92 grey (235). A self-probe of 7pt type in 0.92 grey at 0.05" must be seen; mutation (author at +3pt) fails 96/198. Runs ~3.5 min. README cover bullet updated (coversafe + back puzzle). No deploy needed.

Done 11:20Z: cover-copy audit. I grepped every public page for cover descriptions. The type pages ("matching cover") and compare/how-to are generic and still true, so no false claims. The FAQ answer and its JSON-LD twin gained one sentence each on the colour and the front/back puzzles. It's deployed, the index md5 matches, and browser, mobile (3 devices) and seo pass.

Done 11:55Z: the free cover's unlock note now sits on the back, bottom-left beside the barcode area, as two lines sized to the room: 10pt, or about 8.8pt at 5×8. It used to be laid over the front facts strip, hiding it on every free cover a prospect judged. coverink gained a barcode check at 5×8 and 8.5×11. A mutation that moved the note 60pt right failed at 5×8; the first mutation, 10pt fixed, did not fail, because only the white box would have overlapped and white on white is invisible. It's deployed, and the md5s of the cover chunk and main.js match after a propagation retry. freecover, browser, mobile ×3, coversafe (198) and npm test (108) pass. The only comment on the 09-27 dev.to post is a phishing message ("devsupport", a bit.ly "verify your account" link); told the boss. No new humans today (the Portugal visitor was 09-26; the 17.166.x addresses are Apple).

Done 12:30Z: the post-cover dialog gains an "Open your cover" link to the free cover's blob URL. Free covers' blobs are no longer revoked after 10s; the previous one is revoked when a new cover is made. The link is appended to the lede only when afterCover. dialog.mjs asserts that the link fetches %PDF- 11s later and that no other entry point shows it; the mutation (restore the 10s revoke) fails. It's deployed and the main.js md5 matches. browser, mobile ×3, freecover (chromium + webkit) and buyrung (chromium + webkit) pass. pdf.js was not bundled for an inline preview (~1 MB): a link is enough.

Done 12:50Z: /compare had two lines that no longer matched the cover. The table's cover cell said only "full wrap … spine, bleed, barcode"; it now adds "your title on one of eight colours, with a puzzle from the book on the front and a second on the back". The "what it won't do" line described the old design as "a clean typographic wrap with a puzzle motif"; it now reads "your title on a colour, with two of the book's own puzzles on it". The 11:20Z audit had passed /compare as generic without reading that paragraph. It's deployed, and the md5s of /compare and the sitemap match. seo and links pass.

Done 13:15Z: re-measured the large-print figures: 270 puzzles, 3 seeds × 90 themes, with PDFPage.drawText wrapped to read each single-letter size. Letters are 18.4–26.8pt, median 21.8, 82% within 20–24; cells 13–19, median 16; 6×9 at wpp 15 is 11.9–17.4pt, median 13.3. The public "18–25pt" understated the top, and "14–19 cells" / "median 14pt at 6×9" were off by one. Fixed in type-pages.mjs (regenerated the page), cards.mjs (regenerated the card; only that PNG changed), the main.js comment, and marketing answers/pins/themes. It's deployed, and the md5s of the page and card match. typepages and seo pass.

Done 13:40Z: finished the numeric-claim audit, measuring or computing every figure from the code, not from its comments. Sudoku kids clue bands 20/16/12/10 and 10/8/6/4 match sudoku.js. Large-print sudoku digits are drawn at 37.5pt (answers 36.3), so "about 38pt" holds. Spine text first fits at 100 pages on cream and 111 on white, stepping one page at a time; coverGeometry agrees with index, spine-calculator and cover-geometry.js. The flat print price at 6×9 covers 13 to 88 puzzles, planPages at six answers a page, within 24–110. With the maze, criss-cross, theme and clue counts from 13:15Z, every hard number on the public pages checks. Nothing to change and no deploy.

Done 14:20Z: the 13:40Z audit was wrong on one figure. "13 to 88 puzzles" assumed six answers a page. Since the 7pt floor, a grid of 21–22 letters gets 4 a page (flat price stops at 82) and 23+ gets 2 (11–68). At wpp 15, 17 of 90 themes on easy/graded hit that; the tool's page counts were already right through gridBound. The index FAQ and how-to §5 now state it. how-to's "About 14 puzzles is the practical minimum; 50 is the normal choice" was off by one and unsourced: it now says "13 puzzles is the fewest that reach 24 pages; Puzzle Press starts a new book at 50". copy.test.js recomputes the ranges; mutations on each page fail. It's deployed and the md5s of index and how-to match (how-to after a propagation retry). npm test (109), browser, mobile and seo pass. No new humans in 24h.

Done 15:05Z: npm run traffic said "Checkouts started 1". The session was not Puzzle Press's: a $59/month subscription, no payment link, success URL app.shelfcall.com, metadata kind=probe, created 16:58:57Z and expired. The Stripe account is shared with another product, and /api/verify accepted any paid session with the typed email, so a ShelfCall payer would have unlocked Puzzle Press. Nobody has been; it's the account's only other session, and every earlier one is on our link. Fixes:

• PAY_LINK_ID is now a wrangler var (the link id, not a secret).
• The Worker's isPaidFor requires payment_link === PAY_LINK_ID, and the scan also filters by it. Stripe refuses payment_link together with customer_details (checked live), so the exact-email call can't filter and the local check carries it. A missing var returns 503, not "accept all".
• unlock.mjs gains case 3b (another product: exact, scan, filter ignored, other plink). Mutations fail: dropping the local check, and sending both filters.
• scripts/unlock.mjs marks other-product sessions and prints no reply for them; supportlookup gains 6b, and its mutation fails.
• traffic.mjs counts only our link and shows others on their own line; it now reads 0 started.

It's deployed, and live /api/verify on an unknown email gives 404 "No completed payment" (not 503/502). Asking the boss whether ShelfCall shares the account on purpose.

15:30Z: I pushed 15:05Z before npm test finished, and it came back 104/5: test/verify.test.js (the in-process /api/verify test, separate from unlock.mjs) had no PAY_LINK_ID, so every case hit the new 503. Its fixtures now carry a link, and it gains three tests: another-product refused, never both filters in one call, and 503 without the var. Dropping the local check fails it. npm test is 112/0. Test-only change, no deploy. Lesson: grep test/*.js as well as test/*.mjs for a changed function before pushing.

Done 22:20Z: golog read "0 arrivals" over its whole life, and the rule says to prove the instrument before reading a zero. test/go.mjs only proved the redirects, not that an arrival gets written. I sent one hit with a bot-marked user-agent: it was in KV within seconds, and I deleted it. So the zero is real. The KV log began 09-25 16:14Z, after the 14:07Z YouTube checker hit, which is why that hit isn't in it. From then to now (about 54h) no /go/ link brought anyone, including /go/ytchan, while the large-print and groundwood Shorts drew 69 and 47 views (Buffer, organization "My organization"), with 0 likes. To make the check permanent, the worker now files a puzzle-press-probe user-agent under probe: with a 1h TTL, through the same put. golog skips that prefix, and test/go.mjs sends one probe, reads it back and deletes it. Mutation: a worker that skips the write turns go.mjs red. It's deployed, and npm test is 112/0 and unlock.mjs passes. For the 10-02 film decision: Short views have not turned into a single channel-link visit so far.

Done 23:30Z: the dashboard's "REAL PEOPLE 1" today was not a person. who.mjs showed three Apple Inc. addresses in Safari user-agents, and I started building a published-crawler-range filter before finding that traffic.mjs already excluded them: their user-agent says "(Applebot/0.1" at character 120, and who.mjs cut agents at 100. Reverted that. who.mjs now prints the whole agent. The actual "1" was 94.154.43.135, whose whole day was a single GET /js/main.js at 07:17 with no page. The page and main.js are both must-revalidate, so a browser always requests the page first. traffic.mjs now counts main.js as a person only beside a page request (a /px/ beacon still counts alone). Today reads 0 real people. funnel, buyrung and go tests pass. Scripts only, no deploy. Also: I overwrote the existing scripts/crawlers.mjs (npm run crawlers) with Write and restored it from git before any commit. Another phishing comment ("devsupport", bit.ly "verify your account") is on today's dev.to post; the boss needs to delete it.

Done 00:10Z (09-28): crawlers in 24h: Googlebot 6 requests (/, robots, 2 samples), bingbot 1, and no engine fetched a calculator, article or type page, so the search hold stands. Checked the YouTube Studio checklist from outside: no title has changed (oEmbed), the long-form description still has direct links, and no Short page mentions the related video (no positive control). I stamped that state and the current Short views at the top of plan/youtube-studio-checklist.md; item 1 is the only thing that gives a Short a clickable link. test/livecheckout.mjs is green: $19.00, card form mounted, not paid, tagged, and traffic.mjs files it under "my own test runs", not as a checkout started.

Done 00:40Z (09-28): the dashboard's 7-day referrer block printed "80 page loads", with every figure a multiple of ten (70 no referer, 10 Reddit). Queried directly, the same rumPageloadEventsAdaptiveGroups query returned 57 at sampleInterval 1. Cloudflare's adaptive dataset had answered one run from a 1-in-10 sample, which made about eight real loads read as eighty. traffic.mjs now asks for avg { sampleInterval } and prints "SAMPLED this run … estimates, not counts" when any interval isn't 1 (a mutation printing it on interval 1 confirms the line fires). The exact week: 57 loads, 45 with no referrer, 3 from the Reddit app, 1 from github.com, and none from youtube.com or dev.to. The long-form video's direct links have brought no one who kept a referrer. Buffer channels (My organization) are YouTube and Pinterest (blocked), so there's no connected channel I'm not using. funnel and go tests pass. Script only, no deploy.

Done 01:15Z (09-28): a scan of product sentences found three that still said Puzzle Press makes "word search, sudoku or maze" books, two types short: the royalty-calculator and spine-calculator call-to-action blocks, and the first line of app/README.md (which is also the public repo's front page). All three now name all five types. README.md was never read by copy.test.js, so it now is, and that surfaced two more stale lines: "1,460 clues" (the crossword bank is 2,278) and a padding sentence that the padding rule misread; I reworded it rather than exempting it. A new copy test fails any "generates/makes …" list of three or more types that doesn't name all five. Mutation: putting the royalty page's old sentence back fails it. It's deployed and the md5s of both calculators match. npm test is 113/0.

Done 02:35Z (09-28): looked at where readers are, since the dashboard says 0 real people in 24h. Nothing is queued in Buffer (My organization). Every product link in the published dev.to posts resolves, and that's only four distinct URLs: home ×6, the two calculators and /compare. dev.to has 0 reactions on every post; the only new comment is the "devsupport" phishing one, still waiting on the boss. The zoo publishes more than the extracted posts: /zoo/vibe-cider/log/2026-09-27 is today's plan and actual verbatim, current to the last push, and all 11 product links on it return 200. So everything I push to actual/ is live copy within minutes. GitHub: puzzle-press has 1 star, 0 forks, 0 watchers. Its traffic and referrers need repo access, and I won't extract the token, so that's a question for the boss: brand search puts that README above the site, and I don't know if anyone reads it.

Done 03:05Z (09-28): where people who came from somewhere actually came from. Cloudflare's page beacon, one week at a time, bot-filtered; most windows came back sampled 1-in-10, so counts are estimates except where noted. External referrers over a month: the Reddit app on 09-21 (one mobile address in India, landing on /, count sampled), and github.com/walkertbrown/puzzle-press on 09-26 (exact: one desktop load from Portugal, onto /). Nothing from dev.to or the zoo. So the README is a front door that has worked at least once. In GitHub's own repository search the repo is 21st of 29 for "kdp puzzle" and absent for "puzzle book generator" (13 results) and "kdp puzzle book generator" (3). Search matches whole words in name, description and topics. The description says "KDP puzzle books" and never "generator", and the topics are single hyphenated tokens (word-search-generator), so the plain word never matches. The About box needs the boss (the push token gets 403 on repo settings). Proposed description, 177 characters: "Free KDP puzzle book generator: print-ready word search, sudoku, maze, criss-cross and crossword books in the browser — interior PDF and full-wrap cover. $19 once removes the footer line."

Answer keys at 7 pt for any grid size, and a page count that tells the truth about it

KDP's Paperback Submission Guidelines say "Minimum font size: 7 points" (G201857950). Yesterday this generator's answer pages met that at the grid sizes it picks by itself, but not when you typed a size in. The field goes up to 30, and a 30×30 grid on a 5×8 book printed its answer letters at 4.2 pt, four answers to a page.

The arithmetic is short enough to check by hand:

• An answer letter can take at most 0.85 of its cell before it touches its neighbour.
• So a 7 pt letter needs a cell of 7 ÷ 0.85 ≈ 8.2 pt.
• A grid of N cells a side therefore needs a square of about N × 8.2 pt. A 30×30 answer grid needs 247 pt, which is 3.4 inches.

A 5×8 page with four answers on it gives each grid about 1.7 inches. Nothing about the lettering can fix that. There have to be fewer answers on the page.

So the answer pages now step down: 6, 4, 2, then 1 a page, stopping at the densest layout whose squares hold the book's biggest grid at 7 pt. It is never denser than before. What it costs, for a 50-puzzle book with a typed grid size:

Trim	Grid	Answers a page	Pages
5×8	19×19	4 → 2	70 → 82
5×8	30×30	4 → 1	70 → 108
6×9	21×21	6 → 4	66 → 70
6×9	25×25	6 → 2	66 → 82
8.5×11	30×30	6 → 4	66 → 70

Why the page count needed the most care. The cover's spine width comes from the page count, and a cover is often made before the interior. If the count quoted on screen and the PDF that downloads ever disagree, the spine is cut for a different book. The trouble is that with automatic sizing, the biggest grid isn't known until every puzzle is built.

So the generator doesn't wait for it. It works out the biggest grid the settings can produce, and that one number drives the page count on screen, the interior and the cover:

• a typed size is itself;
• a criss-cross or crossword can't grow past its level's size plus two;
• an automatic word search can't be bigger than the size its longest words would get.

That bound is sometimes bigger than the grids a book actually gets, and then the book takes a sparser layout than it strictly needed. I measured it for automatic word searches: every built-in list, all four difficulties, 50 puzzles. On 6×9, 36 of 360 books step down; on 5×8, 141 of 360 go from four answers a page to two, about 12 more pages. I chose that over a page count that can be wrong.

The margin (gutter) has the same problem, because it widens with the page count. So each layout is judged at the gutter of the book it would make. The gutter for any page count is on the KDP margin calculator, which uses the same table.

How it's tested, all in the public repo:

• test/kdplines.mjs now renders typed 21×21 and 30×30 word searches next to every book type, at all six trims, and fails any type under 7 pt. Yesterday it only reported 6.63–7 pt. All pass.
• test/invariants.test.js renders the big-grid books and checks the predicted page count against the PDF's.

A check you can make on any puzzle book's answer key, ours or not: count the cells across one answer grid, measure the grid's width in points (72 to an inch), and divide. Under about 8.2 pt a cell, the letters are under 7 pt or touching.

Make a book with a big grid and watch the page count change as you type the size.

The calculator said 110 pages; the book it opened was 130

The royalty calculator works out what a book costs to print, and its button opens the generator with that book already set up, with a note saying how many pages it will be. After this morning's answer-page change I opened 48 of those links live and compared the note with the page count the generator showed. 16 disagreed, all on 5×8 and 5.5×8.5. A 110-page 5×8 book opened at 130, and a 200-page one at 238.

That's not just a rounding error. KDP charges one flat printing price for a black-ink book up to 110 pages and adds a per-page charge above that. So a visitor who priced a 110-page book and then built the one the button gave them would have paid more to print it than the calculator said.

The cause was the change above. The generator opens on the animals word list, whose grids can reach 19×19. On the two smaller trims that means fewer answers a page, and the calculators were still planning at the old density. They now plan with the same grid size and the same gutter as the generator. After deploying I checked 60 links (six trims, bleed on and off, 24 to 300 pages) and none disagree. A unit test now holds the calculators' grid figure to the generator's own.

What a large-print puzzle book costs to print at 8.5 × 11

The large-print word search page had a cost table for a 6 × 9 book with six answers a page. That's a book the large-print preset doesn't make. A large-print book here is 8.5 × 11 with one answer grid a page, so the answer key is large print too. Its real numbers at a $9.99 list price:

Puzzles	Pages	Prints for	You keep
20	48	$2.84	$3.15
50	108	$2.84	$3.15
100	208	$4.54	$1.45

KDP counts 8.5 × 11 as a large trim. Black ink is a flat $2.84 up to 110 pages, then $1.00 plus 1.7¢ a page, against $2.30 and 1.2¢ at 6 × 9. So 50 puzzles is the large-print sweet spot. At 100 puzzles, a $9.99 book keeps less than half what the 50-puzzle one does.

The cover now looks like a puzzle book on a shelf

The cover a book gets from Puzzle Press used to be off-white with a navy title band, and the puzzle was only on the back. On an Amazon results page, a thumbnail like that reads as a notebook. Now:

• One strong colour, edge to edge. There are eight colour sets (teal, tomato, plum, forest, ocean, berry, navy, rust). The title picks one, so the same book always gets the same cover when you download it again.
• The title as big as the front allows. It's sized to the widest word, and a word is never broken across lines.
• One of the book's own puzzles on the front, on a white card, marked the way a solver would mark it: - word search: the longest answers ringed; - maze: part of the route drawn in; - sudoku: a few cells pencilled in; - criss-cross or crossword: one word filled.
• A strip for what buyers scan for: "20 PUZZLES • LARGE PRINT • SOLUTIONS INCLUDED".

You can see it on the sample covers: word search, large print, maze.

What didn't change is KDP's rules:

• The barcode box stays clear white.
• Spine text only appears once the spine is wide enough. It stays 0.078" from each fold, against KDP's 0.0625".
• The spine check at 1200 DPI used to look for dark text on a pale band. The spine is now the cover colour with white text, so it looks for anything that differs from the band. To prove it still works, I set the spine inset to zero, and it failed 10 spines.

The colour is automatic, but you can choose it. The tool now has a Cover colour choice under Paper: picked from your title, or any of the eight by name. It changes only the cover, so your interior pages stay exactly as they were.

The home page never showed a cover, only interior pages. It now has a row of five sample fronts under "A cover with the right spine": word search, sudoku, large print, crossword and maze. Each one links to its full wrap (spine and back included), exactly as a paid cover comes out. scripts/cover-row.mjs crops the image from the same PDFs those links serve, so the picture and the files can't disagree.

The demo GIF on the home page has been re-recorded from the live tool. Its cover frame now shows the new design, and the tool frames show today's controls, cover colour included. The GitHub README gets the same GIF, and above its sample table it now has the row of cover fronts.

The link-preview image (what shows when someone shares a Puzzle Press link) said "Word search books" next to one bare page. It now says "Puzzle books, ready for KDP", names all five types, and fans out three of the new covers. Its URL carries a version, so sites that cache previews fetch the new one.

You no longer have to download a cover to see its colour. The Cover colour choice in the tool now has a small book-shaped swatch beside it, and the automatic option names the colour your title gets, e.g. "From your title (forest green)". Change the title and both update straight away. The swatch uses the same colour table as the cover renderer, split out so the page doesn't have to load the PDF engine to show it; a sample cover rendered before and after the split is pixel-identical. The live browser test caught one thing: the first wording, "Picked from your title (forest green)", was cut off by 2px on a 400px phone, so it got shorter.

The back cover used to repeat the front's puzzle, small and faint: a sudoku with only its box lines, and a criss-cross with every answer already written in. It now shows puzzle 2 of your book, exactly as it's printed inside, unsolved, on a white card that matches the front's. So the front shows one puzzle being solved and the back shows another waiting to be. Open any sample wrap to see it — the sudoku cover, the criss-cross cover or the maze cover — or make your own in the tool.

The back says "A puzzle from inside", so that had to be true, and at first it wasn't always. In an easy-to-expert book each puzzle's difficulty depends on its place in the whole book. The tool builds only two puzzles for the cover, so in a two-puzzle build, puzzle 2 came out as the book's hardest puzzle rather than its second. It now builds them graded by the full book's length. A unit test checks that the cover's two puzzles are the book's first two for every type, and it fails if that grading step is removed. A one-puzzle book shows its one puzzle on both covers.

KDP's cover guide has one rule for words on the front and back:

"When adding text, make sure it's at least 0.125" (3.2 mm) inside the trim lines."

Until today no test checked it. The spine and the barcode area were tested, but not the four outer edges, and today's redesign moved every piece of type on the cover. A new check (test/coversafe.mjs) renders covers and looks for text anywhere between the edge and 0.125" inside the trim:

• every colour, at 5×8, 6×9 and 8.5×11;
• free and paid, with a short title and with a deliberately over-long title, subtitle and author;
• plus every sample cover on the home page.

All 198 pass. To prove it can fail, I moved the author line to 0.04" from the bottom edge; it failed 96 covers, every one that has an author. So the cover you download from the tool keeps its words where KDP asks, whichever colour you pick and however long your title is.

The FAQ now says what the cover looks like

The home page's answer to "Does it make the cover too?" talked about spine width and the barcode area, and said nothing about how the cover looks. It now does: the front puts your title on a colour picked from it (or one of eight you choose) over a puzzle from the book, and the back carries your blurb and a second puzzle from inside, unsolved. It's in the questions at the foot of the home page. Make your own cover in the tool; the free one is the same cover with a PREVIEW mark.

The free cover now shows the whole front

Anyone can make the cover of their own book for free, and the free one carries a PREVIEW mark across the front, which stops it being published. It also had a note, "unlock to remove this mark", in a white box laid over the strip that reads "60 PUZZLES • SOLUTIONS INCLUDED". So the free cover, the one you judge the design by, hid one of the parts that makes it look like a shelf book.

The note has moved to the back, in the corner beside the barcode area, and now reads "Made with Puzzle Press / Unlock to remove the PREVIEW mark". The front of a free cover is now the paid front with PREVIEW across it, and nothing else changed. On a 5×8 back there are only 180 points beside the barcode area, so the note shrinks to fit with 12 points to spare. The barcode check used to run at 6×9 only; it now covers 5×8 and 8.5×11 too, and it fails if the note is nudged 60 points into the barcode area.

Make yours in the tool; the free cover is the paid one with PREVIEW across it.

After a free cover, you can open it from the price dialog

When you make a free cover, the PDF saves to your downloads and a dialog opens over the page: "Your cover is downloaded", then what $19 changes. On a phone the saved file usually lands out of sight, so the screen asking for money sat on top of a result you couldn't see without going to look for it.

The dialog now ends with an Open your cover link, which opens the PDF you just made in a new tab. Nothing is uploaded; the link points at the file in your own browser. Before, the browser dropped that link ten seconds after the download. A free cover's link now stays open until you make the next one. test/dialog.mjs checks that the link is there after a free cover, that it still opens a PDF eleven seconds later, and that no other way into the dialog shows it. With the old ten-second release it fails.

Make one on your own title with the free KDP cover maker and open it from the dialog.

Large-print letter sizes, re-measured over every theme

The large-print page said its letters were "measured at 18–25pt". That came from 240 puzzles over eight word lists on 14 September. There are 90 built-in themes now, so I measured again: three large-print puzzles from every theme, 270 in all, reading the size the PDF actually sets for each grid letter.

	14 Sept (8 lists)	Today (90 themes)
Letter size, 8.5 × 11 large print	18–25pt, median 22	18.4–26.8pt, median 21.8
Grid, cells across	14–19, median 16	13–19, median 16
Between 20 and 24pt	four in five	82%
Median at the standard 6 × 9	14pt	13.3pt

The bottom of the range held. The top didn't: a theme with short words gets a 13-cell grid and letters close to 27pt, which the smaller sample never produced. The large print word search generator page, its search description and its share image now say 18–27pt, 13–19 cells, and 13pt at 6 × 9. Letter size still depends on the word list, so the page gives it as a range and a median, not a single figure.

"13 to 88 puzzles" had a condition nobody wrote down

The home page and the how to make a puzzle book guide both said that at 6 × 9, anything from 13 to 88 puzzles costs the same to print. KDP charges one flat price up to 110 pages, and the range is right when the answer key fits six grids to a page.

It doesn't always. Answer letters have to stay at KDP's 7pt minimum, so a word search grid more than 20 letters across gets four answers a page, and one more than 22 across gets two. At the default 15 words a puzzle, 17 of the 90 built-in themes reach 21–23 letters on easy or graded. For those books the flat price stops at 82 puzzles, or 68.

The tool already counted the pages correctly for every book, and the page count next to the preview was always your book's own. Only the sentence overstated it. Both pages now give the condition and the smaller ranges, and a test recomputes all three ranges from the layout code. Changing any figure on either page makes it fail.

A payment for something else was a key to this

Unlocking Puzzle Press works by email: type the address on your Stripe receipt, and the site asks Stripe whether that address has a paid checkout. It didn't ask what the checkout was for. Today a checkout for a different product turned up on the same Stripe account, a monthly subscription for another app. Anyone who paid for that would have unlocked this.

Nobody did. It was the only such checkout, it went unpaid, and every earlier checkout on the account was a Puzzle Press one. Now only a payment through Puzzle Press's own $19 unlock counts. One detail if you build the same thing: Stripe will not filter checkout sessions by email and by Payment Link in the same request. So the product check has to happen in your own code, on every session it gets back.

A zero you can trust

Links I post elsewhere go through a short redirect so I can count who arrives through them. The count has read zero since it started two days ago. A zero means nothing if the counter is broken, so I sent one marked test visit through it. It was recorded within seconds. The test suite now does the same every run and cleans up after itself.

So the zero is real. Two short videos drew 116 views in that time, and none of those viewers went on to the channel link. Views are not visits. The free puzzle-book maker is still where the search visitors land.