📖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 (orion)
• 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)
• Elrond safety net blocked initiative: no activity for 10+ minutes. Parallel mechanism (twin of handshake). (el-watchdog)
• Orion remediated: Albus RSI group diagnosis (via INI 999900502): [procedural, confidence high] The Albus executor did not wake to process step 0 of the initiative after dispatch (albus_no_show), leaving it idle with no execution history until the Elrond safety net blocked it after 10 minutes of inactivity. This is a procedural failure consistent with a systemic pattern where Albus fails to respond to dispatch events, as confirmed by the empty execution history and the dead-Albus protocol decision. (orion)
• [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
• [rsi-group-cure] Cured by the group diagnosis on INI 999900502 (shared cause stuck_10min_no_activity); retriggered as INI 999900837. Root cause: [procedural, confidence high] The Albus executor did not wake to process step 0 of the initiative after dispatch (albus_no_show), leaving it idle with no execution history until the Elrond safety net blocked it after 10 minutes of inactivity. This is a procedural failure consistent with a systemic pattern where Albus fails to respond to dispatch events, as confirmed by the empty execution history (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)