📖About

Ninad's ruling 2026-07-31: Carol's User Engagement app should include subscription details if it does not already. MEASURED BEFORE FILING: it does not — nothing anywhere in that app mentions subscriptions. It shows who Carol is talking to, what she knows about them, their conversation history and the proactive log, and it already distinguishes web users from WhatsApp users, so no channel work is needed. WHERE THE TRUTH LIVES: each person's subscribed services are recorded in their own configuration file inside their folder and read through the shared subscriptions accessor — so the app must READ that accessor rather than keep its own list (cookbook 856: derive from the record, never hardcode). SCOPE: show, for each person, the services they are subscribed to, and register the meaning of anything counted in the data dictionary (cookbook 938 — a displayed number without a definition row is a defect). This is the prerequisite for Leo being given a subscriber-scoped view of the same app.

⚖️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)
• Read subscriptions through the shared accessor, never a copy — Each person's subscribed services live in their own configuration file and are already served by a shared accessor. A second list inside the app would drift the moment a subscription changed. (Ninad)
• This is filed ahead of Leo's access on purpose — Leo's view is to be scoped to Blueprint subscribers, which the app cannot express until it can see subscriptions at all. Doing them in one initiative would hide a dependency inside a change. (Ninad)
• [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

• Looking at a person in User Engagement shows which services they are subscribed to. (must_have)
• The subscriptions shown are read from each person's own record, so granting a subscription changes the page with no edit to the app. (must_have)
• A person with no subscriptions is shown honestly as having none, rather than being left blank or omitted. (must_have)
• Any count the page introduces has its meaning registered where the estate keeps definitions. (must_have)