📖About

Ninad's ruling 2026-07-31: Leo should have access to Carol's User Engagement app, but only to users subscribed to the Blueprint service — the service Leo heads. MEASURED BEFORE FILING: the app belongs to Carol, is classified confidential and is admin-access today, so Leo can reach nothing in it; and exactly ONE person currently subscribes to Blueprint (the operator), so the fenced view will show one person until Blueprint has more subscribers — the mechanism is what is being built, not a populated screen. DEPENDS ON the subscription-details initiative: the app cannot scope a view by subscription until it can read subscriptions. SCOPE: give Leo reach to the app, and fence WHAT HE SEES to people subscribed to Blueprint — a row-level fence, since the estate's confidential classification governs how much is visible rather than whether the door opens (CAROL-INI-3526). The fence must be derived from each person's own subscription record and from the service Leo owns, never from a written-in list of names or a hardcoded service key.

⚖️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)
• Fence what Leo SEES, not whether the door opens — The estate already rules that reaching a confidential app is allowed while how much is visible is what is fenced (CAROL-INI-3526). A row-level fence therefore matches the existing model; widening the app's access level would not. (Ninad)
• Derive the fence from the subscription record and the service Leo owns — A written-in list of subscribers, or a hardcoded service name, would go stale the first time someone subscribed. Cookbook 856 and 963 both apply. (Ninad)
• Filed with the one-subscriber reality recorded — Exactly one person subscribes to Blueprint today, so a green result here shows one person. Recording it now stops a future reader reading the small number as a broken fence. (Ninad)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> reviewing | event=uat_open | pipeline_uat uat_open (uat)
• [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

• Leo can open Carol's User Engagement app. (must_have)
• Leo sees only people subscribed to Blueprint there, and a person who is not a subscriber is absent for him. (must_have)
• Carol and the operator continue to see everyone, exactly as before. (must_have)
• Subscribing a new person to Blueprint makes them visible to Leo with no change to any app. (must_have)
• An agent with no claim on Blueprint still sees nothing in that app. (must_have)