MC_VISIBILITY_ONLY is enforced across the application—often as repetitive boilerplate within endpoint handlers—creating a fragile perimeter susceptible to future regressions.app.py (e.g. api_ticket_runtime_start around line 11933, api_add_comment, etc.)if MC_VISIBILITY_ONLY: return ... inside the handler body of every individual route or helper method. A new engineer writing a fresh runtime API route or modifying worker lifecycle methods could easily omit this boilerplate, accidentally reopening an execution vector.Recommendation: Refactor these guards into a single @visibility_only_forbidden decorator or a global before_request middleware targeting the execution-specific API routes.
Finding 2: Internal Primitives Unprotected
mc_interactive.py, and underlying functions like ticket_runtime.ensure_started().MC_VISIBILITY_ONLY. If a stray background thread or a missed API route invokes them, they will execute fully.if MC_VISIBILITY_ONLY exception inside ticket_runtime.ensure_started() and related lower-level spawn methods as defense-in-depth.1. Does current MC code default to visibility-only? Cite evidence.
Yes. In app.py (Lines 75-80), MC_VISIBILITY_ONLY evaluates to True unless explicitly disabled by setting the environment variable to "0", "false", "no", or "off".
2. If a human comments on a ticket via /api/v1/tickets/<id>/comments, does it launch or inject a runtime? Trace the code path and cite evidence.
No. In app.py (Lines 9891-9898), the api_add_comment route intercepts human comments when _controller_notify_enabled() is active (which is forced on by MC_VISIBILITY_ONLY). It routes the request to _handle_controller_notify_comment. This function adds the human comment and an audit record atomically. It skips _route_human_comment and _queue_and_pickup entirely. Finally, it attempts to dispatch an event via control_room_events.dispatch_controller_event, but this is safely neutralized because control_room_events.controller_hooks_enabled() evaluates to False.
3. Are non-human/system comments prevented from legacy auto-dispatch when controller notify is active/visibility-only? Cite evidence.
Yes. In app.py (Lines 9899-9908), there is an explicit guard: if _controller_notify_enabled() and data.get("author_type") != "human":. If met, it persists the comment, broadcasts the UI updates, and returns early, completely bypassing the legacy _route_human_comment and auto-pickup block below it.
4. Do WAT/workflow actions auto-dispatch or only audit/record in visibility-only? Cite evidence.
Only audit/record. In app.py (_dispatch_workflow_action_inline, Lines 12452-12463), the function immediately checks if MC_VISIBILITY_ONLY:. If true, it writes a system comment stating: "[visibility-only] Workflow dispatch action recorded for Hermes Luci orchestration. MC did not create or inject into a runtime." and returns without making assignment or status mutations.
5. Are controller event hooks disabled in visibility-only? Cite evidence.
Yes. In control_room_events.py (controller_hooks_enabled, Lines 58-60), the function begins with if visibility_only_enabled(): return False, ensuring hooks cannot fire while MC acts as a passive board.
6. Are there remaining static code paths that can still launch MC workers/runtimes despite visibility-only? List any risks with severity.
The active known paths (_queue_and_pickup, API routes like api_ticket_runtime_start, and background tasks like control_room_pickup.py) are strictly guarded. The risk (Severity: Medium) is structural: since MC_VISIBILITY_ONLY relies heavily on repetitive inline checks inside endpoints instead of global middleware, any new /api/v1/runtimes/* endpoint added in the future without the boilerplate check will leak execution. Additionally, internal lifecycle primitives (e.g. ticket_runtime.ensure_started) lack self-checks.
7. Does the Kanban watchdog route internal Kanban stalls to Luci/internal handling rather than Telegram/Elmar? Cite evidence from the script/config if possible.
Yes. The script /home/lucienne/.hermes/scripts/luci_kanban_watchdog.py evaluates the .hermes/kanban database, groups stalls, and invokes _queue_orchestrator_inbox() which performs an SQL insert directly into mission-control/mc.db (orchestrator_inbox table). The script deliberately avoids Telegram and documents its intent: "This is Luci-owned control-plane work. Do not escalate to Elmar unless it exposes a genuine human/product/credential blocker." and "Deliberately no stdout for handled findings" to prevent cron-based Telegram paging.
8. What hardening should we do next? Prioritize minimal, reversible changes.
- Route-Level Decorators (Minimal & Reversible): Replace the scattered if MC_VISIBILITY_ONLY: return code blocks throughout app.py API handlers with a unified @visibility_only_forbidden decorator.
- Deep Primitives Guard (Minimal & Reversible): Inject a fail-safe if MC_VISIBILITY_ONLY: return natively into core Python execution functions like ticket_runtime.ensure_started() and _ticket_runtime_direct_send().
/api/v1/runtimes/test_leak that attempts to start a worker without a MC_VISIBILITY_ONLY check. Ensure the proposed decorator successfully catches and terminates the request.orchestrator_inbox table inside mc.db to confirm that the kanban_watchdog items are arriving securely and with the intended prioritization.