Keychain initialization encountered an error: Object does not exist at path “/org/freedesktop/secrets/collection/login” Using FileKeychain fallback for secure storage. Loaded cached credentials. Error executing tool read_file: Path not in workspace: Attempted path "/home/lucienne/.hermes/scripts/luci_kanban_watchdog.py" resolves outside the allowed workspace directories: /home/lucienne/workspace/mission-control or the project temp directory: /home/lucienne/.gemini/tmp/mission-control Error executing tool list_directory: Path not in workspace: Attempted path "/home/lucienne/workspace" resolves outside the allowed workspace directories: /home/lucienne/workspace/mission-control or the project temp directory: /home/lucienne/.gemini/tmp/mission-control - Date/time: Saturday, June 6, 2026 - Verdict: PASS WITH RISKS
Mission Control's codebase effectively enforces a visibility-only posture. The default state correctly disables automatic runtime dispatch, and human/system inputs reliably execute safely, recording intent as durable audit comments instead of blindly auto-routing. However, the architectural approach to enforcing this boundary—relying on scattered conditional checks across 17+ individual API routes—introduces a structural risk. If new control-plane endpoints are added without manually replicating these guard rails, worker dispatches could accidentally leak. The Kanban watchdog could not be verified because its source exists outside the authorized, version-controlled workspace.
app.py (lines 7877, 8414, 11216, 11933, 14527, etc.)if MC_VISIBILITY_ONLY: return _visibility_only_runtime_response(...) inside the handler body of every individual route. A new engineer writing a fresh runtime API route 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 /api/v1/runtimes and ticket claiming namespaces.
Finding 2: Untracked Kanban Watchdog Script
~/.hermes/scripts/luci_kanban_watchdog.py./home/lucienne/workspace/mission-control/). It bypasses centralized review, test boundaries, and agent visibility.luci_kanban_watchdog.py into the scripts/hermes/ directory and manage it alongside luci_ticket_watcher.py.1. Does current MC code default to visibility-only? Cite evidence.
Yes. In app.py (Line 75) and control_room_events.py (Line 48), 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 (api_add_comment, Line 9815), the comment is saved to the DB with a durable audit record. Following this, if hooks are enabled, it calls control_room_events.dispatch_controller_event(...) which merely sends a decision prompt to the external persistent Controller. The code block explicitly documents: "The hook NEVER dispatches a worker, mutates status/assignee, or auto-routes — Controller decides."
3. Are non-human/system comments prevented from legacy auto-dispatch when controller notify is active/visibility-only? Cite evidence.
Yes. In app.py (api_add_comment, Line 9899), an explicit bypass was added: if _controller_notify_enabled() and data.get("author_type") != "human":. This branch saves the system comment and safely returns early (Line 9910), intentionally averting the legacy _queue_and_pickup and Telegram notification paths below it that would mutate ticket statuses or trigger Elmar.
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, Line 12452), the function immediately evaluates if MC_VISIBILITY_ONLY:. 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 any workflow assignment or state mutations.
5. Are controller event hooks disabled in visibility-only? Cite evidence.
Yes. In control_room_events.py (controller_hooks_enabled, Line 67), the function begins with if visibility_only_enabled(): return False, safely neutralizing the hook behavior when MC is acting 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.
Currently, all static paths known to launch runtimes are guarded. The standalone scripts (scripts/control_room_pickup.py, mc_review_retry.py, and mc_shadow_review.py) all verify the MC_VISIBILITY_ONLY flag and exit gracefully. Legacy _queue_and_pickup immediately returns. However, the risk (Severity: Medium) lies in the fragility of app.py. A missing if MC_VISIBILITY_ONLY: check in future endpoints would break the perimeter. Additionally, internal functions like _should_use_ticket_runtime_for_pickup lack an explicit flag check, failing safely only because their callers guard the perimeter.
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.
I cannot definitively confirm this. The path provided (/home/lucienne/.hermes/scripts/luci_kanban_watchdog.py) falls outside the authorized bounds of my agent workspace (/home/lucienne/workspace/mission-control/), preventing me from inspecting its configuration or logic.
8. What hardening should we do next? Prioritize minimal, reversible changes.
- Centralize Guards: Replace the repetitive MC_VISIBILITY_ONLY blocks in app.py API handlers with a unified @visibility_only_forbidden route decorator.
- Defense in Depth: Add an explicit if MC_VISIBILITY_ONLY: return False to internal decision nodes like _should_use_ticket_runtime_for_pickup inside app.py.
- Relocate Logic: Move the untracked luci_kanban_watchdog.py script into mission-control/scripts/hermes/ to subject it to standard code review and agent-assisted auditing.
luci_kanban_watchdog.py or run a --dry-run to trace exactly how it resolves stall alerting.api_add_comment (Lines 9828-9831) are being caught cleanly by the Controller's secondary polling fallback. /api/v1/runtimes/dummy_dispatch is added without the MC_VISIBILITY_ONLY boilerplate, proving that execution logic would leak without a global middleware.