Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About
Today there is no UI surface anywhere in Carol that shows what an agent or droid is actually instructed to do. Agent identity (character, roles, rights, duties) is exposed via /api/employee/{id} (port 7147) and rendered on /employee/{id}, but the actual system prompts that govern behavior — Elrond identity.md, ip-s1 _PROMPT, el-s1 _STANCE_PROMPT, ir-s1 close-decision prompt, al-sh-01 verdict prompts, every Forge/Argus/Sage prompt, etc. — are buried in .py files reachable only via SSH+grep. This makes prompt review (e.g. checking that Elrond carries the no-sudo Hard Rule) effectively invisible to Ninad and to anyone auditing pipeline behavior. Add a Prompts tab to /employee/{id} that lists the agent identity prompt and every owned-droid prompt, with copy + diff + change-tracking via prompt hashes.
⚖️Decisions
- Follow-on to parent INI 999900481 (elrond)
- Scope inherited verbatim from parent INI 999900481 per CAROL-INI-361. (elrond.initiative_author)
- [status-router] planned -> dispatched | event=dispatch | RSI: auto-promoted bypasses depth limit (CAROL-INI-2198) (spb-01)
- [status-router] dispatched -> 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 999900575): [procedural, confidence high] The initiative blocked because the Albus executor never received a proper activation signal (bypass_start was never called) after dispatch. The execution history is empty and the dispatch queue status is 'cancelled', consistent with the pattern in prior diagnoses where the operator failed to invoke bypass_start on bypass-mode initiatives, leaving the initiative stranded until Elrond's 10-minute inactivity safety net triggered. (orion)
- [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
- [rsi-group-cure] Cured by the group diagnosis on INI 999900575 (shared cause stuck_10min_no_activity); retriggered as INI 999900875. Root cause: [procedural, confidence high] The initiative blocked because the Albus executor never received a proper activation signal (bypass_start was never called) after dispatch. The execution history is empty and the dispatch queue status is 'cancelled', consistent with the pattern in prior diagnoses where the operator failed to invoke bypass_start on bypass-mode initiatives, leaving the initiative strand (elrond.rsi_loop)
✅Success criteria
- Design and implement /api/employee/{id}/prompts and /api/prompts/audit endpoints in apps/org/app.py. The /api/employee/{id}/prompts route must return the agent's identity.md content and a list of owned droid prompts with content, source_file, and sha256 hash. The /api/prompts/audit route must return all prompts across all agents with the same fields. Verify by: (a) querying /api/employee/elrond/prompts returns identity.md content + droid prompts; (b) querying /api/prompts/audit returns a row for every active agent; (c) sha256 changes when identity.md is edited. (must_have)
- Coverage check: /api/prompts/audit returns a row for every active agent in registry.db (count matches) and every owned droid is either prompt-resolved or marked no-prompt-found (must_have)
- Sha256 changes when the underlying file is edited (verify by touching identity.md and re-querying) (must_have)
- No regression on existing /employee/{id} rendering or /api/droids/{agent_id} response shape (must_have)