📖About

Carol Chat on /dev/carol-chat/ is the public web surface a prospect lands on (e.g. after clicking Try Me Out on Carolverse). Today it is broken in five distinct ways:

1) GUEST NAMES NOT USED. Google sign-in returns the user's name and Carol's registration code does call register_user_by_channel(channel=web, identifier=email, name=name) — but the prompt builder's guest path (_build_guest_system_prompt) does not surface the name to Carol so she greets every guest as Guest/anonymous. Carol must address guests by their Google-verified first name from the very first message.

2) PROMPT EVOLUTION (DOCUMENT ONLY, DO NOT BUILD): Guest starts with the unverified-tier prompt. As the conversation builds, a per-user prompt is supposed to be authored automatically over time. As the user subscribes to services, service prompts come into effect. Carol is supposed to educate guests pro-actively about the services on offer — one service per turn, not a brochure dump. This mechanism does not exist yet; build it in a follow-on initiative.

3) ORIGIN UNKNOWN. Carol has no idea where the conversation came from. The carol-chat surface must accept an origin hint (direct link, via_whatsapp, via_carolverse_tryme, via_landing_other) — captured from query string ?from=carolverse-tryme or similar — persist it on the conversation row, and pass it to Carol's brain on every turn so she can tailor the first turns (e.g. on tryme: explain what Carol is in one line; on whatsapp-redirect: pick up where the WhatsApp thread left off).

4) NO NEW-USER PING + NO DEDUPE + NOT IN USER ENGAGEMENT. (a) First-ever sign-in: Carol must WhatsApp Ninad — 'New web sign-in: () — origin: '. (b) Return sign-in starting a NEW conversation (per the same conversation-window definition used by the User Engagement app — i.e. a fresh conversation row, OR a session-break threshold matching the User Engagement app's rule): ping Ninad 'Returning web user: () — conversation N'. (c) Every web user must be registered in the User Engagement app the same way WhatsApp users are; today web users live only in registry.db. Single source of truth for User Engagement metrics across channels. (d) Same human across channels = one record. Carol must ASK the new web user (in the first 1-2 turns) if they are already on WhatsApp and/or for their phone number; if matched, link the web identity to the existing WhatsApp record via the existing admin link endpoint flow (auto, not manual).

5) INPUT PATH BROKEN. chat.db shows the last three sign-ins (Ninad, Werner, [email protected]) all got Carol's greeting and ZERO follow-up user messages were recorded — the send button or the POST /api/conversations//messages path is not working end-to-end. Diagnose and fix the input + reply round-trip so prospects can actually chat.

Scope: ship 1, 3, 4, 5 via bypass in this initiative. File a clear follow-on for 2 (prompt evolution + service education).

⚖️Decisions

• Elrond stuck-watchdog: 3 consecutive failed recovery attempts since 3 strikes recorded. Initiative idle past 600s with no live queue row; Albus invoked 4 times without progress. Flipping to blocked and surfacing on operator queue per CAROL-INI-403. (elrond.handover_watchdog)
• 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)

✅Success criteria

• Carol greets a freshly-signed-in guest by their Google-verified first name in the first turn (not Guest or anonymous). (must_have)
• The carol-chat URL accepts a ?from=<source> query string (carolverse-tryme, whatsapp, direct, etc.), persists the origin on the conversation row, and includes it in the context Carols brain receives every turn. (must_have)
• Carol greets a freshly-signed-in guest by their Google-verified first name in the first turn (not Guest or anonymous). (must_have)
• First-ever web sign-in pings Ninad on WhatsApp with the new users name, email, and origin within 60s of the sign-in completing. (must_have)
• The carol-chat URL accepts a ?from=<source> query string (carolverse-tryme, whatsapp, direct, etc.), persists the origin on the conversation row, and includes it in the context Carols brain receives every turn. (must_have)
• A return sign-in that starts a NEW conversation (per the User Engagement apps existing conversation-window definition) pings Ninad with returning-user details and the conversation count. (must_have)
• First-ever web sign-in pings Ninad on WhatsApp with the new users name, email, and origin within 60s of the sign-in completing. (must_have)
• A return sign-in that starts a NEW conversation (per the User Engagement apps existing conversation-window definition) pings Ninad with returning-user details and the conversation count. (must_have)
• Every web user is registered in the User Engagement app via the same data path WhatsApp users use; metrics queries return identical fields for both channels. (must_have)
• In the first 1-2 turns, Carol asks every new web guest whether they are already on WhatsApp and/or for their phone number; if a match is found, the web identity is auto-linked to the existing WhatsApp record (one row per human across channels). (must_have)
• Send-message round-trip works end-to-end from the public Carol Chat surface: a typed message persists as a user row in chat.db, Carols brain returns a reply, and the reply persists as a carol row - verified by a smoke test that posts a real message and reads back both rows. (must_have)
• A separate follow-on initiative is filed (status=planned) capturing the deferred prompt-evolution + service-education mechanism: per-user prompt authored over time, service prompts activate on subscription, Carol pro-actively educates guests about one service per appropriate turn. (must_have)
• Every web user is registered in the User Engagement app via the same data path WhatsApp users use; metrics queries return identical fields for both channels. (must_have)
• In the first 1-2 turns, Carol asks every new web guest whether they are already on WhatsApp and/or for their phone number; if a match is found, the web identity is auto-linked to the existing WhatsApp record (one row per human across channels). (must_have)
• Send-message round-trip works end-to-end from the public Carol Chat surface: a typed message persists as a user row in chat.db, Carols brain returns a reply, and the reply persists as a carol row - verified by a smoke test that posts a real message and reads back both rows. (must_have)
• A separate follow-on initiative is filed (status=planned) capturing the deferred prompt-evolution + service-education mechanism: per-user prompt authored over time, service prompts activate on subscription, Carol pro-actively educates guests about one service per appropriate turn. (must_have)