ADR-004: Consent in the bot, outfit choice on the tablet

Who is this for

Developers and the owner — read this before changing the order of steps a guest goes through.

TL;DR

Consent is one tap in the bot, tied to a Telegram account and stored with a timestamp.
Outfits are chosen on the tablet, not in the bot. Before consent the API refuses the choice with 409.
Status: accepted. The guest flow is fixed; changing it needs an explicit product decision.

Context

A face photo is personal data. Consent has to be explicit, provable and impossible to skip. At the same time the bot conversation should stay as short as possible: every extra screen on the phone slows the station down.

Decision

The bot shows the consent text after /start <token>; the Agree callback moves the session to consented and records users.consented_at (bot/handlers/consent.py).
The kiosk polls the session and shows outfit cards only when it sees consented; the camera is opened only then.
POST /session/{token}/template succeeds only from consented; POST /session/{token}/photo only from template_chosen (bot/api.py).
A session is created only when the guest taps Start, so abandoned QR codes do not pile up.

Alternatives considered

Alternative	Why not
Consent checkbox on the tablet	Not tied to an identity; anyone can tap it for someone else.
Outfit choice in the bot	Longer chat, small previews, and the tablet stands idle meanwhile.
Paper consent	Slow, and the organiser has to store it.

Consequences

Guests without Telegram cannot take part.
A photo is accepted only for a session in which a real Telegram user agreed, which also limits abuse of the public API.
The camera stays off on the idle and QR screens, so nobody is filmed before agreeing.

Evidence

CLAUDE.md, “Guest flow” and hard rule 3.
Commits 475ba4b (session only on Start) and 03326ad (camera only after consent).

Where to go next

Last verified: 2026-11-13 against ai-sticker-pack@b715418 and ai-stickers-landing@e350ff5.