ADR-006: One pack per Telegram account

Who is this for

Developers, operators and sales — read this before promising or building “one more try”.

TL;DR

• Limit = 1 + the extra attempts an admin has granted. Failed jobs do not count.
• Checked at /start, at outfit choice, and atomically when the job is queued.
• Status: accepted. ALLOW_MULTIPLE_PACKS=1 removes the limit, for tests and demos only.

Context

Each pack costs money and a share of the provider’s daily image quota. Without a limit one enthusiastic guest can occupy the station and the budget. The limit must hold against double taps and against two tablets.

Decision

• The limit counts jobs in queued, processing, delivering and done, plus a legacy pack recorded on the user row.
• The final check and the creation of the job happen in one BEGIN IMMEDIATE transaction (take_photo_and_enqueue in bot/db/db.py).
• A refused guest gets only a link to the existing pack, or “your pack is being prepared”. The bot does not explain how to get another one.
• The kiosk shows a friendly screen and returns to idle; the API answers 409 with the code pack_limit.
• Allow one more in the admin panel adds one to users.extra_packs_allowed and is written to the audit log.

Alternatives considered

Alternative	Why not
No limit	Unbounded cost and a hogged station.
Limit per phone number or per face	More personal data and more complexity than the problem deserves.

Consequences

• A guest unhappy with the result needs a staff member with admin access.
• Operators testing on their own account must grant themselves an extra attempt first.
• Pack numbering (pack<N>_…) continues from every pack the account ever had, because pack names are never reused — see ADR-010.

Evidence

• CLAUDE.md, hard rule 4; commit 1e68e2d.
• tests/test_pack_limit.py.

Where to go next

• State machines.
• Client FAQ — how to explain the limit.
• Decisions index.

---

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