Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About
Ninad ruling 2026-07-31 (CLI-186): UAT acceptance must carry NO hardcoded acceptor table. (1) The acceptor is DERIVED from the requester record: whoever requested the initiative does its UAT — for any registered agent, not a fixed list. Found defect: the pipeline UAT routing has branches only for Leo, Orion/Ninad, Albus and Hermione, so every Elrond-requested filing (e.g. the six rsi-loop/scoped-review items in review since mid-July) falls through to manual and is skipped ungraded every sweep. (2) UAT is performed by RE-PERFORMING the process that identified the need to raise the initiative — the origination activity (re-run the failing process for a monitoring alarm, re-run the raising check for an rsi-loop refile, re-perform the review scope for a scoped-review follow-on) — never by reading checklist rows alone. (3) The UAT ask travels back on the ORIGINATING CHANNEL: an initiative requested via a chat window communicates the UAT request into that same chat conversation, addressed to the employee (human or agent) who requested it; CLI-requested work stays with the operator as today.
⚖️Decisions
- Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
- No hardcoded acceptor routing: the UAT acceptor is DERIVED from the requester record (owner = requester), for any registered agent. A per-agent branch table is the defect class this initiative removes. — Ninad ruling 2026-07-31 (CLI-186), after the six Elrond-requested initiatives were found skipped ungraded since mid-July: the routing had branches only for Leo, Orion/Ninad, Albus and Hermione, so elrond fell through to manual. (Ninad)
- UAT is performed by RE-PERFORMING the process that identified the need to raise the initiative — the origination activity — never by reading checklist rows alone. — Ninad ruling 2026-07-31 (CLI-186). Generalizes the verify-by-doing UAT policy (cookbook 739): the origination context (monitoring alarm, rsi-loop refile, scoped-review finding, chat request) defines WHAT to re-perform. (Ninad)
- The UAT ask is communicated on the ORIGINATING CHANNEL: an initiative requested via a chat window has its UAT request delivered back into that chat conversation, addressed to the employee (human or agent) who requested it. CLI-requested work stays with the operator. — Ninad ruling 2026-07-31 (CLI-186): the requester can only re-perform the origination process if the ask reaches them where they asked. (Ninad)
- [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
- Criterion 'the six Elrond-requested initiatives are graded' stays OPEN at close BY DESIGN: the two changed files are OS-locked core, installed via Radagast core_install only AFTER bypass_end (the install lane needs the review row). It is stamped with proof after the install + the first sweep run grades the six. — CAROL-INI-3296 core-install ordering; honest criterion state over a premature tick. (orion)
- DELIBERATE DEFERRAL: delivery of the UAT ask to a HUMAN chat requester (a Carol WhatsApp/web user) is not built here - no human-chat-requested initiative exists in review today. The channel record + deliver() seam are in place; wiring Carol's outbound lane is its own initiative when the first such requester appears. — Build the mechanism at the seam that has users; do not wire a channel blind (Ninad ruling scope, CLI-186). (orion)
- [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
- [delivery-check] 1 must-have criteria remain pending at bypass_end — delivery FAILED live re-performance; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): test test_ini3518.py: FAIL (no tests ran in 1.20s) (orion)
- [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)
✅Success criteria
- A finished initiative requested by ANY registered agent is routed to that agent's own acceptance — no per-agent routing branch decides who accepts, and registering a new agent needs no acceptor code change (must_have)
- The requester's acceptance verifies delivery by re-performing the activity that raised the initiative, and the recorded verdict cites that re-performance as evidence (must_have)
- An initiative requested through a chat conversation has its UAT request delivered back into that conversation addressed to the requester, who can accept or reject from there (must_have)
- The six Elrond-requested initiatives stranded in review since mid-July are actually graded by Elrond's acceptance (accepted, or rejected with live evidence) instead of being skipped to manual (must_have)