docs: add the onboarding concept cards as references, not assets

Seven cards, one per onboarding step, supplied by the owner and generated from
BRAND_GUIDE.md §22's own master prompt — which is the workflow that section
exists to describe. They settle the direction #29 asked for, including all four
steps that had no art at all.

They are NOT the shipping assets, and docs/design/dist/README.md says so at the
point somebody would otherwise drop them into res/drawable:

- raster, against a 1.9 MB release APK and §42's ask for vector paths
- titles and subtitles painted into the pixels, while the app already renders
  all seven through Heading(...) — used as-is every title appears twice, and
  baked text cannot be translated, scaled with font size, or read by TalkBack
- light mode only, with dark mode inbound and a preview-pair rule that exists
  because dark mode was silently broken for all of Batch 01
- card 7 shows a fertile window and ovulation that the first-forecast screen
  deliberately withholds; on a fresh install it shows confidence Low and Today
  reads "Not enough history to estimate"

Converted from the delivered PNGs to WebP at the original 1086x1448: same
resolution, 340 KB instead of 12 MB, and the format docs/data/img already uses.
Renamed from the generator's default filenames so the set reads as a sequence.

#29 stays open with the assessment recorded as a comment on it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
null 2026-08-18 19:28:50 -05:00
parent db46335a0f
commit 9d2a4b2fb1
10 changed files with 63 additions and 1 deletions

View File

@ -81,7 +81,7 @@ Where the two disagree, `PRODUCT_PLAN.md` is the specification and
| `docs/planning/` | `PRODUCT_PLAN` — the V1 specification. `PROJECT_PLAN` — the vision. Neither is the schedule; that is the tracker. | | `docs/planning/` | `PRODUCT_PLAN` — the V1 specification. `PROJECT_PLAN` — the vision. Neither is the schedule; that is the tracker. |
| `docs/qa/` | `ClaudeQAPlan` (playbook, passes AH), `ClaudeQACoverage` (what each pass reached), `ClaudeReport` (the verdict) | | `docs/qa/` | `ClaudeQAPlan` (playbook, passes AH), `ClaudeQACoverage` (what each pass reached), `ClaudeReport` (the verdict) |
| `docs/architecture/` | modules, boundaries, data shapes, the migration table; `GUARDS.md`; `githooks/README.md` | | `docs/architecture/` | modules, boundaries, data shapes, the migration table; `GUARDS.md`; `githooks/README.md` |
| `docs/design/` | `README.md` — tone, the four rules that settle arguments, and which specification sections own each surface. `BRAND_GUIDE.md` — the owner-supplied visual identity, which outranks `PRODUCT_PLAN.md` §39 on colour. `brand/` — the source PNGs the marks were cut from | | `docs/design/` | `README.md` — tone, the four rules that settle arguments, and which specification sections own each surface. `BRAND_GUIDE.md` — the owner-supplied visual identity, which outranks `PRODUCT_PLAN.md` §39 on colour. `brand/` — the source PNGs the marks were cut from. `dist/` — the onboarding concept cards, references rather than shipping assets |
| `docs/security/` | `SECURITY` — threat model, the advertising boundary, logging rules. `SECURITY_CHECKLIST` — the pre-release list | | `docs/security/` | `SECURITY` — threat model, the advertising boundary, logging rules. `SECURITY_CHECKLIST` — the pre-release list |
| `docs/history/` | `DEVELOPMENT_LOG` (dated, append-only), `HISTORY` (decisions and their reasons), `BATCH_LEDGER` (archived) | | `docs/history/` | `DEVELOPMENT_LOG` (dated, append-only), `HISTORY` (decisions and their reasons), `BATCH_LEDGER` (archived) |
| `docs/data/` | `README.md` — the rule, and why this folder cannot be exempted. `img/README.md` — the three required names, their dimensions and the 512 KB ceiling. `img/icon.webp`, `img/logo.webp`, `img/banner.webp` — the marks privacyllc.dev renders | | `docs/data/` | `README.md` — the rule, and why this folder cannot be exempted. `img/README.md` — the three required names, their dimensions and the 512 KB ceiling. `img/icon.webp`, `img/logo.webp`, `img/banner.webp` — the marks privacyllc.dev renders |

View File

@ -164,6 +164,13 @@ vocabulary — `PrivacyIllustration` encloses a ring in a shield, and enclosure
reads as protection without reaching for a padlock, which would read as a reads as protection without reaching for a padlock, which would read as a
security product rather than a calm one. security product rather than a calm one.
The onboarding half of that brief now has a decided direction: seven concept
cards, one per step, in [`dist/`](dist/). They are references and not shipping
assets — raster, with their titles painted into the pixels, light mode only, and
card 7 shows a fertile window the first-forecast screen deliberately withholds.
[`dist/README.md`](dist/README.md) says why each of those disqualifies them from
`res/drawable`, so that nobody mistakes a decided direction for a finished asset.
The remaining art is tracked as issues #29 to #32, not listed here. The remaining art is tracked as issues #29 to #32, not listed here.
The visual language is deliberately narrow — **overlapping circular forms** and The visual language is deliberately narrow — **overlapping circular forms** and

55
docs/design/dist/README.md vendored Normal file
View File

@ -0,0 +1,55 @@
# Onboarding concept cards
```
Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: docs/design/dist/** — the onboarding concept set and what it is for
Review trigger: Any concept set added or replaced here; the onboarding artwork
in issue #29 landing in the app
```
> **These are references, not assets.** Nothing in this folder ships in the APK.
> They are the decided *direction* for onboarding, drawn from
> [`../BRAND_GUIDE.md`](../BRAND_GUIDE.md) §22's master prompt, and the vectors
> that eventually ship are drawn *from* them.
Seven cards, one per onboarding step, numbered to match the steps in
`app/src/main/kotlin/dev/privacyllc/period/feature/onboarding/OnboardingScreen.kt`:
| File | Step | Composable |
| --- | --- | --- |
| `onboarding-01-welcome.webp` | 1 | `Welcome` |
| `onboarding-02-last-period-start.webp` | 2 | `LastPeriod` |
| `onboarding-03-period-end.webp` | 3 | `PeriodEnd` |
| `onboarding-04-previous-history.webp` | 4 | `PreviousHistory` |
| `onboarding-05-privacy-promise.webp` | 5 | `PrivacyPromise` |
| `onboarding-06-reminder-privacy.webp` | 6 | `NotificationPrivacyStep` |
| `onboarding-07-first-forecast.webp` | 7 | `FirstForecast` |
## Why they are not the shipping assets
Recorded here so nobody drops them into `res/drawable` and calls #29 done. The
full argument, with evidence, is in the comment on that issue.
- **They are raster.** The set is 340 KB as WebP; it was 12 MB as PNG, against a
1.9 MB release APK. §42 asks for Compose vector paths or `VectorDrawable`.
- **The titles and subtitles are painted into the pixels**, and the app already
renders all seven itself through `Heading(...)`. Used as-is, every title
appears twice — and baked text cannot be translated, cannot scale with the
user's font size, and is invisible to TalkBack.
- **They are light mode only.** `BRAND_GUIDE.md` §22 names the dark palette, and
[`../README.md`](../README.md) requires a light/dark preview pair per screen.
A vector set recolours from theme tokens; a raster set has to be drawn twice.
- **Card 7 shows a fertile window and ovulation**, which the first-forecast
screen deliberately does not — on a fresh install it shows confidence Low and
Today reads "Not enough history to estimate". That conflict is a product
decision to settle before anything is drawn, not a detail to fix in the art.
## Provenance and format
Generated from `BRAND_GUIDE.md` §22's master prompt, which is the workflow that
section exists to describe. Converted from the delivered PNGs to WebP at their
original 1086×1448 — same resolution, about a fortieth of the bytes, and the
same format [`../../data/img/`](../../data/img/) already uses for the marks
privacyllc.dev renders.

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB