# 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 bound by an eligible exact-handle observation or
the trusted administrative path.
2. The first non-anonymous observation with a positive numeric Telegram user ID
and a normalized username exactly matching an unresolved preauthorized
handle binds that ID to the handle. The observation and binding occur in one
immediate SQLite transaction; unmatched observations remain metadata only.
3. Once bound, a numeric identity survives username changes. A handle or
numeric ID already bound elsewhere is never reassigned.
4. A trusted caller may explicitly bind a preauthorized handle with
`authorize_user_id`; exact replays are idempotent and incompatible bindings
are conflicts.
5. The Telegram transport receives only the bound numeric whitelist required
for admission and group-membership checks.
6. Only an authorized numeric user with `can_add_users` may preauthorize
another handle; that handle remains unresolved until an eligible matching
observation or explicit administrative binding.
7. Opaque Telegram group IDs are observed without storing Telegram chat IDs or
transport state.
8. 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.
9. The library preserves existing SQLite directory data and schema semantics.
10. The library owns no HTTP routes, Telegram network transport, Kweb node
creation, orchestration, process listener, or credential vault.
11. The Telegram anonymous-group pseudo-user never becomes an observed Kennedy
identity or whitelist candidate.