📖About

GAP: neither filing nor the dispatch preflight re-confirms that the problem an initiative was filed for STILL exists. Watcher-filed health/liveness alarms (Inspector/Hermione/Guardian/Sentinel detecting stale heartbeats, down processes, not-firing schedulers) can sit queued for days; by dispatch the subject is often healthy again, so the pipeline burns a full run fixing a non-problem (e.g. CAROL-INI-1336 Hermione stale-heartbeat, filed 2 weeks ago). FIX: add a premise re-validation step to Elrond dispatch preflight. For watcher-filed health-alarm initiatives, re-check the subject current liveness/heartbeat at dispatch time; if the condition has cleared, emit a halt finding that auto-closes the initiative as no-longer-reproduces instead of dispatching. Fail-open: if validity cannot be determined, dispatch normally (do not over-block).

⚖️Decisions

• Auto-detected remediation target INI-100000816 from title/description scan (matched CAROL-INI-1336 -> row id 100000816 (CAROL-INI-1336-00: Hermione unhealthy: Scheduler heartbeat stale after restart)); override by setting remediates_initiative_id explicitly at bypass_start. (system-auto-detect)
• 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)
• Added a premise re-validation step to Elrond dispatch preflight: for a watcher-filed health alarm, it re-checks the named subject current liveness (via process_liveness) at dispatch time. If the subject is healthy again, the initiative auto-closes as no-longer-reproduces instead of dispatching. (orion)
• Detection is REQUESTER-GATED (requester must be a watcher: inspector/hermione/guardian/sentinel/themis/argus/albus) AND carry a health keyword — NOT keyword-only, which falsely matched meta-initiatives that merely discuss alarms. Reads the initiative via the relay (iconnect), since the on-disk initiatives DB is a decoy. (orion)
• Fail-open throughout: anything that cannot be positively evaluated (unreadable, no subject matched, liveness unknown, any error) returns unknown and dispatches normally — the check never wrongly closes real work. Wired into dispatch_next loop; the existing stale-queue sweep cancels the closed row. (orion)
• Caller audit waived by Orion: the Dispatcher (ds_s1) edit is an additive, fail-open block at the top of the dispatch loop; callers (the dispatch-next API + timer, enqueue) see no contract change — only that genuinely-resolved watcher alarms are closed instead of dispatched. (orion)
• INI-1767 compliance gate refused close — CAROL-INI-1767 compliance gate refused close: [agent-access] design: dark-theme baseline palette not used — design #178 §1; [agent-access] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [agent-access] design: no empty state — handle the no-data case (design #178 §3); [audit] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [auth] design: dark-theme baseline palette not used — design #178 §1; [auth] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [auth] design: no empty state — handle the no-data case (design #178 §3); [build-cookbook] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [build-cookbook] design: no empty state — handle the no-data case (design #178 §3); [carol-costs] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [carol-costs] design: dark-theme baseline palette not used — design #178 §1; [carol-infra] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [carol-infra] design: dark-theme baseline palette not used — design #178 §1; [carol-infra] design: no empty state — handle the no-data case (design #178 §3); [carol-infra] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): collector.py; [carol_admin] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [carol_admin] design: missing responsive viewport meta — design #178 §6 (mobile-friendly); [carol_admin] design: dark-theme baseline palette not used — design #178 §1; [clara-chat] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [clara-chat] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [clara-chat] design: no empty state — handle the no-data case (design #178 §3); [daily_activities] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [design] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [design] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): closest_match_designer.py; [frankfurt_food] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [guardian_monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [inspector_monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [jarvis_monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [leo-monitor] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [leo-monitor] design: missing responsive viewport meta — design #178 §6 (mobile-friendly); [leo-monitor] design: dark-theme baseline palette not used — design #178 §1; [leo-monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [leo-monitor] design: no empty state — handle the no-data case (design #178 §3); [migration] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [migration] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): source_access.py; [migration-cookbook] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [migration-cookbook] design: no empty state — handle the no-data case (design #178 §3); [operations] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [org] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): agent_tasks_api.py; [palantir] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [plan_generator] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): cookbook_106.py, cookbook_106_wiring.py, dispatch_monitor.py, dispatcher_hook.py, reasoning_pass.py, review_trace_integration.py, reviewer_trace.py, reviewer_trace_hook.py, ticks.py; [plan_generator] architecture: data artifact in app dir: plangenerator.db (file) — the store lives in the central data folder and must be referenced by its central path; no .db may sit in an app dir (L1.5, design #275); [roadmap] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [roadmap] design: dark-theme baseline palette not used — design #178 §1; [roadmap] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [scheduled_processes] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [scheduled_processes] design: no empty state — handle the no-data case (design #178 §3); [sentinel_monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [session_induction] design: missing canonical topbar — include the shared component /static/dl/carol-topbar.js or the CAROL_LOGO_v4 block (design #178 §4); [session_induction] design: dark-theme baseline palette not used — design #178 §1; [session_induction] architecture: business-logic file(s) in app dir, must live in a droid behind a shim (L1.4): gate6_regression.py, handover_api.py, healthcheck.py, main.py, section1_documents.py; [sst] architecture: data artifact in app dir: sst.db (file) — the store lives in the central data folder and must be referenced by its central path; no .db may sit in an app dir (L1.5, design #275); [strategy-cookbook] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [strategy-cookbook] design: no empty state — handle the no-data case (design #178 §3); [strategy-cookbook] design: no error state — handle fetch/render failures (design #178 §3); [strategy-cookbook] architecture: data artifact in app dir: *.db (file) — the store lives in the central data folder and must be referenced by its central path; no .db may sit in an app dir (L1.5, design #275); [themis_monitor] design: no loading state — a data-driven app must show a loading indicator (design #178 §3). Bring the app to standard (Design System #178 / architecture #146/#173/#156), or add a decision row prefixed 'Compliance waived by' to override. (shared.bypass.bypass_end[INI-1767])
• [status-router] executing -> blocked | event=bypass_blocked | bypass transition (or-bx-01)
• Bypass session failed — initiative blocked (exec 380) — bypass_end called with success=False for exec 380, run 787 (shared.bypass.bypass_end)
• [status-router] blocked -> reviewing | event=operator_complete | twin-review pass; first close hit a transient gate false-block (orion)
• [status-router] reviewing -> executing | event=operator_put | Fix autoclose to close in-process (status-router) instead of self-HTTP. (orion)
• Fixed the auto-close to run IN-PROCESS via the status router instead of an HTTP call to the app own API. The self-HTTP call silently no-opped when dispatch ran inside the initiatives app (manual-trigger path); route_status works on every path and atomically records the close decision too. (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

• Watcher-filed health alarms are re-checked at dispatch; if the condition cleared, the initiative auto-closes as no-longer-reproduces instead of dispatching (must_have)
• The re-check reads the subject current liveness/heartbeat (process_liveness), not a guess (must_have)
• Fail-open: if the premise cannot be evaluated, dispatch proceeds normally (must_have)