# Specification
1. A configured bootstrap handle is normalized, persisted, and authorized to
add other handles, but it contributes no numeric Telegram ID to the
transport whitelist until explicitly bound.
2. Authorization of an account requires a trusted caller to bind one
preauthorized handle to one positive stable numeric Telegram user ID.
Username and display-name observations are metadata only and never
authorize or pin an account.
3. Once bound, a username change does not revoke a numeric identity.
4. The Telegram transport receives only the numeric whitelist required for
admission and group-membership checks.
5. Only an explicitly authorized numeric user with `can_add_users` may
preauthorize another handle; that handle remains unresolved until explicitly
bound to a numeric user ID.
6. Opaque Telegram group IDs are observed without storing Telegram chat IDs or
transport state.
7. Users and groups may be associated with one canonical Kweb root node.
Replaying the same association is idempotent; assigning a different root
after completion is a conflict. A completed group association is resolvable
from that canonical root; unknown or unfinished roots are not targets.
8. The library preserves existing SQLite directory data and schema semantics.
9. The library owns no HTTP routes, Telegram network transport, Kweb node
creation, orchestration, process listener, or credential vault.
10. The Telegram anonymous-group pseudo-user never becomes an observed Kennedy
identity or whitelist candidate.