Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About
Requirement from Ninad (2026-07-02): EVERY Carol interaction that sounds like a request must be recorded in the Requests inbox (registry incoming_requests via the shared inbox module) and classified to an appropriate service. Today capture only fires on narrow paths (anonymous-user/subscription flows); normal Carol conversations that contain a request are never recorded. Scope: (1) add a request-detection pass to Carol's conversation flow so any request-sounding message creates an inbox entry with conversation context, sender identity, and timestamps; (2) run the service classifier on each captured request, populating is_request, classified_service, classification_confidence, classification_reason; (3) unmatched/ambiguous requests get a low-confidence classification and stay visible for triage, never silently dropped; (4) dedupe so one conversation thread yields one request row updated over the thread, not spam rows. Related defect discovered same day: regression tests test_ini666/test_ini718 send REAL approval emails and upsert the REAL inbox (mock mail + inbox in tests) - fix alongside or as sibling.
⚖️Decisions
- Filing mode changed planner -> bypass — Ninad: implement via bypass (2026-07-02) (orion)
- [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
- [status-router] executing -> blocked | event=stuck_10min_no_activity | Elrond safety net: initiative has had no activity for 10+ minutes. Blocking under the parallel safety mechanism. (el-watchdog)
- RSI diagnosed: 2026-07-02 17:23:01 -> improvement #(none). ({'_raw': 'ROOT CAUSE: The initiative was blocked because it entered "bypass" execution mode from the planner, which triggered an immediate transition to executing, but then experienced no activity for over 10 minutes, causing the safety net to block it.\n\nIMPROVEMENT: Add a pre-execution validatio (el-rsi-eng-01)
- Elrond blocked initiative under the CAROL-INI-2162 dead-Albus protocol. Albus was supposed to wake for step 0 (cause=albus_no_show) but did not respond. Cause: albus_no_show. Reason: Elrond safety net: initiative stranded 10+ min. Albus wake failed or produced no useful result. (el-s1)
- Universal request capture rides the EXISTING architecture (capture deterministic, intelligence in Carols Request Classifier droid, cron 5-min): extend the classifier to also sweep per-user WhatsApp DBs (users/<tier>/<folder>/carol.db wa_conversations) grouped per sender per ISO-week (stable queue id = thread dedup). Admin (Ninad) conversations ARE recorded but never trigger the approval email (self-approval is meaningless). Web path unchanged. (orion)
- [HYGIENE GATE apps_registered] skip: work_type=None does not require app registration (orion.bypass)
- [HYGIENE GATE design_filed] skip: no design_id provided (orion.bypass)
- [HYGIENE GATE architecture_compliance] pass: references architecture design #146 (agent-centric modular architecture) (orion.bypass)
- [HYGIENE GATE policy_check] fail: no policy_ids tagged — caller should explicitly acknowledge applicable policies or waive (orion.bypass)
- [HYGIENE GATE constitution_aligned] pass: soft-default pass; caller responsible for asserting via decision row (orion.bypass)
- [HYGIENE GATE cookbook_entry] fail: no cookbook_id provided — bypass should leave a recipe or explicitly waive (orion.bypass)
- [HYGIENE GATE logbook_entry] fail: no logbook_session_id provided — Orion bypass must write a Logbook entry (orion.bypass)
- [HYGIENE GATE apps_registered] skip: work_type=None does not require app registration (orion.bypass)
- [HYGIENE GATE design_filed] skip: no design_id provided (orion.bypass)
- [HYGIENE GATE architecture_compliance] pass: references architecture design #146 (agent-centric modular architecture) (orion.bypass)
- [HYGIENE GATE policy_check] pass: considered: P.04.01.06.08 (orion.bypass)
- [HYGIENE GATE constitution_aligned] pass: soft-default pass; caller responsible for asserting via decision row (orion.bypass)
- [HYGIENE GATE cookbook_entry] pass: cookbook 393: Universal request capture (CAROL-INI-2237): WhatsApp threads sweep + admin suppression (orion.bypass)
- [HYGIENE GATE logbook_entry] pass: logbook session 137: (orion.bypass)
- [status-router] blocked -> reviewing | event=operator_reopen | False block: bypass 478 completed with twin-review PASS and 4/4 criteria met; watchdog blocked it mid-session. Operator-correcting to reviewing per CAROL-INI-1938. (orion)
- [status-router] reviewing -> blocked | event=stuck_10min_no_activity | Elrond safety net: initiative has had no activity for 10+ minutes. Blocking under the parallel safety mechanism. (el-watchdog)
- Elrond blocked initiative under the CAROL-INI-2162 dead-Albus protocol. Albus was supposed to wake for step 0 (cause=albus_no_show) but did not respond. Cause: albus_no_show. Reason: Elrond safety net: initiative stranded 10+ min. Albus wake failed or produced no useful result. (el-s1)
- Orion remediated: Albus RSI group diagnosis (via INI 1000166): [procedural, confidence high] The initiative was repeatedly retracted from the 3-deep dispatch queue because it could not stay in the top-3 priority window long enough for an operator push, resulting in no execution and a 10-minute inactivity timeout that triggered the Elrond safety net. (orion)
- [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
- [rsi-group-cure] Cured by the group diagnosis on INI 1000166 (shared cause stuck_10min_no_activity); retriggered as INI 999900657. Root cause: [procedural, confidence high] The initiative was repeatedly retracted from the 3-deep dispatch queue because it could not stay in the top-3 priority window long enough for an operator push, resulting in no execution and a 10-minute inactivity timeout that triggered the Elrond safety net. (elrond.rsi_loop)
✅Success criteria
- A request-sounding message in any Carol conversation (any tier, any channel) produces a row in incoming_requests with conversation context and sender identity (must_have)
- Every captured request is classified to a service with confidence and reason populated; ambiguous ones are kept with low confidence, not dropped (must_have)
- One conversation thread yields one request row (updated in place), not duplicates (must_have)
- Regression tests no longer send real approval emails or write the real inbox (mail + inbox mocked) (must_have)