📖About

Since OS-user isolation (CAROL-INI-2390) the dev apps run as the carolapps user, but Radagast's reclaim_port/restart_app run IN-PROCESS as the radagast user: lsof cannot see other users' listeners (reclaim_port reported port 7268 'already free' while the RSI app was live on it, 2026-07-13) and os.kill/relaunch lack privilege. Every code reload of a carolapps app currently needs operator root break-glass (2400-family gotcha, hit again for CAROL-INI-2749). FIX (Ninad ruling: extend Radagast rather than break-glass): (1) root-owned helper /usr/local/bin/carol-radagast-bounce-app that validates the app against a fixed baked-in registry, SIGTERMs the port's uvicorn listeners as root (never -9), relaunches via runuser as the app's registered user with canonical workers/log, and health-polls; (2) sudoers grant for radagast limited to that helper; (3) restart_app: registry gains rsi + quality-scorecard, and apps flagged .app_as_agent route through the helper (legacy in-process path unchanged for caroladmin apps). Root install steps (helper + sudoers + daemon restart) go via a STAGED SCRIPT Ninad executes, per the 2686 precedent.

⚖️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)
• Current state at filing (Elrond validity check): Radagast's reclaim_port and restart_app run as the radagast user and cannot see or control processes owned by the carolapps user; operators still need root break-glass to reload any per-app-user app. The proposed root helper, sudoers grant, and registry updates have not been implemented. (elrond)
• [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

• Ninad can get any registered dev app (e.g. the RSI Dashboard) serving freshly deployed code within a minute by one Radagast call, with zero manual root commands: after the call the app's page shows the new build and stays healthy (must_have)
• When an app is actually running, asking Radagast about its port tells the truth (a live listener is reported, not 'already free'), so operators no longer act on false port states (must_have)
• The RSI Dashboard at /dev/rsi/ serves the CAROL-INI-2749 per-measure governance view live, proving the reload path end-to-end (must_have)
• Security posture visible to the admin is unchanged or tighter: Radagast's new privilege is one auditable helper that refuses unknown apps and never force-kills, and every bounce appears in his Admin Log (must_have)
• The persistent regression suite proves the routing and refusal behavior, so a future regression is caught before an operator hits it (must_have)