📖About

ROOT CAUSE of the Carol Chat send-fail. registry.db users.phone is TEXT UNIQUE, but register_user_by_channel inserts phone='' (empty string) for every web user. The first web row (uid=webapp) consumed the empty-string slot; every subsequent web sign-in collides on UNIQUE(phone)='', triggers 5 retries x 60s busy_timeout, and the request hangs past nginx's 60s gateway timeout. POST /dev/carol-chat/api/conversations returns 504; chat.db never gets a row; user sees a frozen UI.

Fix: insert phone=NULL (NULL does not violate UNIQUE in SQLite) for channel=web AND for any other channel where phone is not the identity. Migration: the existing users/admin/webapp row with phone='' must be migrated to NULL (or deleted so subsequent rows can be inserted). Re-verify by signing in fresh + sending a message + reading chat.db.

⚖️Decisions

• Closed by Albus health-check: code fix (phone=None instead of empty-string) was already applied in user_manager.py but the bypass session that made the edit was interrupted before closing. Fix verified correct — NULL does not violate SQLite UNIQUE constraint. (albus)
• requester rewritten ninad -> orion per CAROL-INI-744: orion is the only human-CLI requester — Backfill of historical rows after INI744 added API-level refusal of requester=ninad. Orion is Ninads CLI agent; all human-originated initiatives are filed with requester=orion. (orion)