📖About

Carol's Org is served by a per-app-user process (the registry per-app-user lane), but a systemd unit of the same name still exists for it. Restarting that unit does NOT reload the live app - it starts a SECOND copy that cannot bind the port, fails, and is restarted every 10 seconds for ever. Found on 2026-08-04 while shipping CAROL-INI-3644: an operator restart through the unit looked like it succeeded (systemctl returned 0, Radagast logged it, the app still answered 200) while the running code was NEVER reloaded, and it left a crash loop behind - 200 bind failures and a restart counter at 197 before it was noticed. Radagast's reclaim_port correctly refuses (the listener belongs to another OS user) and restart_app is the lane that actually works.

Two things are wrong and both are silent: (1) a restart that reloads nothing while reporting success, and (2) a dead unit that crash-loops unnoticed. Scope: decide the ONE lane that owns each app's lifecycle, retire or disable the stale unit, and make an operator restart through the wrong lane REFUSE with the right instruction rather than appear to work. Sweep every app for the same duplicate-lane condition - if Carol's Org had one, others will.

⚖️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)
• [delivery-check] 4 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (orion)
• [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

• Each registered app has exactly ONE lane that owns its lifecycle, recorded, with no duplicate systemd unit shadowing a per-app-user process. (must_have)
• An operator restart through a lane that does not own the app REFUSES and names the lane that does, instead of returning success while reloading nothing. (must_have)
• The stale unit for Carol's Org is retired or disabled and no longer crash-loops (zero bind failures over an hour). (must_have)
• Every registered app is swept for the same duplicate-lane condition and the findings recorded. (must_have)