📖About

An anonymous web user who asks Carol for a capability hits a dead end: the request becomes a silent pending subscription row, the admin (Ninad) is NOT notified (web/anonymous sessions are flagged is_test_request so the admin alert is skipped), no contact handle is stored, the notify-back relay is WhatsApp-phone-only so any update is silently dropped, and Carol over-promises (you will get a message; Leo will pick it up and walk you through) with no wiring behind it. FIX (full wiring): (1) Carol captures an EMAIL before filing and stores it on the request; (2) real web/anonymous requests notify Ninad (stop treating them as test); (3) the user is emailed on received / approved / rejected, with the approved mail carrying the link to continue scoping with Leo; (4) add an email fallback to the notify-back relay when the user has no phone; (5) align Carols intake script to reality - ask for email, say we will email you at X, set expectation that approval brings a link to continue with Leo (Leo does not proactively ping); (6) attach the users follow-up thoughts to the request so they are not lost. Decisions: capture email at request time; full wiring fix.

⚖️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)
• Scope expanded (Ninad): store every incoming request in the REGISTRY as the SST, and build a Requests inbox admin app listing all incoming requests. Email captured at request time; full wiring fix. (orion)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [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

• Incoming capability requests are stored in the registry as the SST (email, request text, status, linkage), not a silent side DB (must_have)
• Carol captures an email before filing and her script no longer promises a WhatsApp ping or that Leo will proactively contact the user (must_have)
• A real anonymous/web request notifies Ninad (no longer suppressed as a test request) (must_have)
• The user is emailed on received/approved/rejected; approved mail carries the link to continue scoping with Leo (must_have)
• A Requests inbox admin app lists all incoming requests with approve/reject actions; registered in the registry and routed (must_have)