docs: log the screenshot capture and what the seeding taught

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/history/DEVELOPMENT_LOG.md

@@ -32,6 +32,55 @@ written and stay true. It is exempt from review for the same reason a receipt is
 
 ## Entries
 
+### 2026-08-19 — Eleven screenshots, and the day the seeding chose a bad hero
+
+Privacy: Period Tracker was the only Privacy LLC product without a page on
+privacyllc.dev — the other three have one, `/work/privacy-period-tracker` returns
+404 — and no screenshot of this app existed anywhere in the repository. There are
+eleven now, in `docs/design/screenshots/`.
+
+**They match the house style**, which was worth reading the site to learn rather
+than guessing: the product pages run a portrait gallery of six or seven captioned
+images, no device frames, no decorative background, with a one-line *Data
+posture* under Platform notes. `/privacy` itself shows no screenshots at all — 18
+sections of text and a 64 px logo — so it was never the target.
+
+**The seeding is the substance of the work.** Six invented starts giving gaps of
+28/29/28/28/29 days, so the forecast on screen is earned by history rather than
+asserted. #32 is blunt about why that matters: a screenshot of a period tracker
+is a screenshot of health data.
+
+**And the first seeding produced a bad hero.** It landed the capture day exactly
+on the estimated ovulation date, so Today read *"estimated ovulation in 0 days"*.
+Entirely true, and the wrong lead for a gallery — a fertility-forward first
+impression for a privacy product, and a hero number of zero. Shifting the history
+ten days earlier gives *"period likely in 4 days"* with the 72sp number, which is
+the screen this app is built around. Worth remembering that seeded data has a
+composition as much as a value.
+
+**The status-bar check was the useful discipline.** SysUI demo mode fixes the bar
+to 9:30, wifi, full battery on every frame; then the top strip of all eleven was
+cropped into one image and compared. That is what proves the thing #32 actually
+warns about — a reminder notification visible in a published screenshot — rather
+than trusting that none appeared.
+
+A smaller find: the trust map still said `splash.png` after that file became
+`splash.webp`. `doc-claims.sh` tolerates a bare filename, so nothing failed;
+corrected here.
+
+- **Closed:** nothing. #32 keeps its two remaining halves — a feature graphic,
+  which is artwork rather than a screenshot, and Play's own sizes confirmed in
+  the console at submission time. Recorded as a comment on it.
+- **Next action:** the page itself is admin work on privacyllc.dev — the agent
+  API has no asset or media route, so the gallery cannot be populated from here.
+  Hand the eleven frames over. Then Batch 06's remainder: #37 is smallest and
+  unblocked, #35 export next.
+- **Blockers:** #9, the webhook, still needs a person. #44 needs one re-render.
+  And §4 requires the privacy promise on the public privacy page — the live page
+  carries no Period-specific promise and no per-app page exists, which is a
+  compliance row on `SECURITY_CHECKLIST.md` and what #37's policy link is waiting
+  for.
+
 ### 2026-08-19 — Full-bleed onboarding heroes, and a hash check that proved the wrong thing
 
 The onboarding illustrations went from 11–17% of the screen to a third of it,