Play Store listing assets do not exist, and Batch 08 says the listing must be submittable #32

Closed
opened 2026-08-18 18:52:54 -05:00 by null · 1 comment
Owner

The Batch 08 milestone lands when "the store listing and Data Safety declaration are ready to submit". None of the store artwork exists.

What is true now

docs/data/img/ holds icon.webp, logo.webp and banner.webp, and those are for the project card on privacyllc.dev — a different consumer with its own required names and its own size ceiling, documented in docs/data/img/README.md. Nothing in this repository is sized or framed for Google Play.

What it costs

This gates submission rather than the build: the AAB can be produced today, and no release can be published without these. It is also the last place the product's promises get restated to a stranger, which makes it a compliance surface and not only a design one.

What to do

Produce the listing set — at minimum a feature graphic and phone screenshots, plus whatever the console requires for the form factors this app declares — and keep the sources beside the existing brand sources under docs/design/brand/.

Confirm the current required sizes and counts in the Play Console at submission time, not from this issue. That is the same rule docs/security/SECURITY_CHECKLIST.md already applies to the target-API deadline, and for the same reason: a number copied into a document is a number that stops being true without telling anyone.

Traps

  • Screenshots of a period tracker are screenshots of health data. Seed a deliberate demo history and never a real one, and check what the status bar and notification shade show before capturing — a discreet reminder in the shade of a store screenshot is a privacy failure published at scale.
  • No medical or contraceptive claim, in the graphics or the copy. PRODUCT_PLAN.md line 1942 and the security checklist both carry this, and artwork is the easy place to imply it accidentally — a fertility calendar rendered as a certainty says something the app deliberately refuses to say.
  • The screenshots must show the honest states. The forecast on a fresh install says confidence Low and fertility declines to estimate; a listing showing a confident forecast on day one is a promise the product does not make.
  • §42's forbidden list applies here too.

Why filed and not fixed

The graphics need an artist, and the screenshot set should be captured once the designed Settings screen from Batch 06 exists — capturing now would photograph a surface that labels itself a Batch 05 working surface.

Verify: A complete Play listing asset set exists with sources committed under docs/design/brand/, every screenshot is from seeded demo data with no real history and no notification visible, and nothing in the set states or implies a medical, diagnostic or contraceptive claim.

The Batch 08 milestone lands when "the store listing and Data Safety declaration are ready to submit". None of the store artwork exists. ## What is true now `docs/data/img/` holds `icon.webp`, `logo.webp` and `banner.webp`, and those are for the project card on privacyllc.dev — a different consumer with its own required names and its own size ceiling, documented in `docs/data/img/README.md`. Nothing in this repository is sized or framed for Google Play. ## What it costs This gates submission rather than the build: the AAB can be produced today, and no release can be published without these. It is also the last place the product's promises get restated to a stranger, which makes it a compliance surface and not only a design one. ## What to do Produce the listing set — at minimum a feature graphic and phone screenshots, plus whatever the console requires for the form factors this app declares — and keep the sources beside the existing brand sources under `docs/design/brand/`. **Confirm the current required sizes and counts in the Play Console at submission time, not from this issue.** That is the same rule `docs/security/SECURITY_CHECKLIST.md` already applies to the target-API deadline, and for the same reason: a number copied into a document is a number that stops being true without telling anyone. ## Traps - **Screenshots of a period tracker are screenshots of health data.** Seed a deliberate demo history and never a real one, and check what the status bar and notification shade show before capturing — a discreet reminder in the shade of a store screenshot is a privacy failure published at scale. - **No medical or contraceptive claim, in the graphics or the copy.** `PRODUCT_PLAN.md` line 1942 and the security checklist both carry this, and artwork is the easy place to imply it accidentally — a fertility calendar rendered as a certainty says something the app deliberately refuses to say. - **The screenshots must show the honest states.** The forecast on a fresh install says confidence Low and fertility declines to estimate; a listing showing a confident forecast on day one is a promise the product does not make. - **§42's forbidden list applies here too.** ## Why filed and not fixed The graphics need an artist, and the screenshot set should be captured once the designed Settings screen from Batch 06 exists — capturing now would photograph a surface that labels itself a Batch 05 working surface. Verify: A complete Play listing asset set exists with sources committed under `docs/design/brand/`, every screenshot is from seeded demo data with no real history and no notification visible, and nothing in the set states or implies a medical, diagnostic or contraceptive claim.
null added this to the Batch 08 — Polish milestone 2026-08-18 18:52:54 -05:00
null added the
P2
label 2026-08-18 18:52:54 -05:00
Author
Owner

The phone screenshots exist now — eleven frames committed at e7d38bc in docs/design/screenshots/, with a README carrying the seeded dates, the capture recipe and the rules.

This issue's sequencing note said to capture "once the designed Settings screen from Batch 06 exists". It does (#33), so that condition is met and frame 11 is that screen.

Every trap in this issue was checked rather than assumed:

  • Seeded, never real. Six invented starts — 8 Mar, 5 Apr, 3 May, 31 May, 28 Jun, 26 Jul 2026 — giving gaps of 28/29/28/28/29 days. On a 19 August clock that earns period likely in 4 days, most likely 23 August, expected 22–24 August, confidence High.
  • No notification in any frame. SysUI demo mode fixes the status bar to 9:30 / wifi / full battery on all eleven, and the top strip of every frame was cropped and compared in a single image to confirm it — that is the failure this issue calls a privacy failure published at scale.
  • The honest states are the ones shown. The forecast is earned by six cycles of history rather than asserted on day one, and the not-contraception line is visible in both the Today and Calendar frames.
  • No §42 imagery. Light mode throughout, which also sidesteps #44.

What this issue still needs, and why it stays open:

  1. A feature graphic. Not captured — it is artwork, not a screenshot.
  2. Play's own sizes and counts, confirmed in the Play Console at submission time rather than from any document here. The set is 1080 × 2400 WebP, which is a starting point, not a verified answer.
  3. Whatever the console requires for the other form factors this app declares.

Verify: unchanged.

**The phone screenshots exist now** — eleven frames committed at `e7d38bc` in `docs/design/screenshots/`, with a README carrying the seeded dates, the capture recipe and the rules. This issue's sequencing note said to capture *"once the designed Settings screen from Batch 06 exists"*. It does (#33), so that condition is met and frame 11 is that screen. Every trap in this issue was checked rather than assumed: - **Seeded, never real.** Six invented starts — 8 Mar, 5 Apr, 3 May, 31 May, 28 Jun, 26 Jul 2026 — giving gaps of 28/29/28/28/29 days. On a 19 August clock that earns *period likely in 4 days, most likely 23 August, expected 22–24 August, confidence High*. - **No notification in any frame.** SysUI demo mode fixes the status bar to 9:30 / wifi / full battery on all eleven, and the top strip of every frame was cropped and compared in a single image to confirm it — that is the failure this issue calls a privacy failure published at scale. - **The honest states are the ones shown.** The forecast is earned by six cycles of history rather than asserted on day one, and the not-contraception line is visible in both the Today and Calendar frames. - **No §42 imagery.** Light mode throughout, which also sidesteps #44. What this issue still needs, and why it stays open: 1. **A feature graphic.** Not captured — it is artwork, not a screenshot. 2. **Play's own sizes and counts**, confirmed in the Play Console at submission time rather than from any document here. The set is 1080 × 2400 WebP, which is a starting point, not a verified answer. 3. Whatever the console requires for the other form factors this app declares. Verify: unchanged.
null referenced this issue from a commit 2026-08-20 02:14:13 -05:00
null closed this issue 2026-08-20 02:14:13 -05:00
Sign in to join this conversation.
No Label
P0
P1
P2
release-blocker
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: null/Privacy-Period-Tracker#32
No description provided.