📖About

Add a new access level called AGENT MAPPING on top of the existing service-subscription model. Today a signed-in user reaching an agent needs only a subscription to that agent's service (which grants ALL agents in the service). New rule: reaching an agent requires BOTH (a) a subscription to one of the agent's services AND (b) an explicit per-user mapping to that agent ('user X may use agents A, B, C'). The mapping gates the agent's chat, the agent's apps, and the agent's droids. Storage: a mapped_agents list in each user's user_config.json, next to subscribed_services. Admin management screen in Access Mgmt to assign users->agents. PLUS folder-level per-user data isolation: files/data a user shares with an agent land in that user's OWN folder (per user, per agent), never a shared app dir; every read/write path is derived from the logged-in user so two users mapped to the same agent can never see each other's data (extends the carol-chat isolation pattern from DB rows to the filesystem). Migration: existing subscribed users are mapped to the SERVICE OWNER agent of each subscribed service only (Ninad ruling). Admin=all, visitor=none, deny-by-default. Implement via Orion bypass.

⚖️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)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> parked | event=stuck_10min_no_activity|pipeline_stopped_park_3044 | pipeline stopped (operator OFF or budget-paused) - parked instead of blocked so the stop does not strand live work (CAROL-INI-3044); resumes on turn-ON (el-watchdog)
• Elrond safety net blocked initiative: no activity for 10+ minutes. Parallel mechanism (twin of handshake). (el-watchdog)
• [status-router] parked -> 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

• A signed-in non-admin user can reach an agent's chat only if they are BOTH subscribed to one of that agent's services AND explicitly mapped to that agent; either one missing = denied. (must_have)
• A signed-in non-admin user can open an app only if the app's owning agent is mapped to them; an unmapped agent's apps and droids are refused. (must_have)
• Files/data a user shares with an agent are stored under that user's own per-user folder, and a second user mapped to the same agent cannot read the first user's files or messages. (must_have)
• An admin screen in Access Mgmt lists a user's subscribed services and lets an admin assign/revoke which agents that user may use; the change persists to the user's config and takes effect on the next request. (must_have)
• Existing subscribed users are migrated so each is mapped to the owner agent of every service they are subscribed to (service owner only), so no current user is locked out at cutover. (must_have)
• Admin users reach all agents; visitors (not signed in) reach none; all checks fail closed. (must_have)
• A signed-in non-admin user can reach an agent's chat only if they are BOTH subscribed to one of that agent's services AND explicitly mapped to that agent; either one missing = denied. (must_have)
• A signed-in non-admin user can open an app only if the app's owning agent is mapped to them; an unmapped agent's apps and droids are refused. (must_have)
• Files/data a user shares with an agent are stored under that user's own per-user folder, and a second user mapped to the same agent cannot read the first user's files or messages. (must_have)
• An admin screen in Access Mgmt lists a user's subscribed services and lets an admin assign/revoke which agents that user may use; the change persists to the user's config and takes effect on the next request. (must_have)
• Existing subscribed users are migrated so each is mapped to the owner agent of every service they are subscribed to (service owner only), so no current user is locked out at cutover. (must_have)
• Admin users reach all agents; visitors (not signed in) reach none; all checks fail closed. (must_have)