Luci Control Room and Runtime Independence Plan

Status: active plan / progress tracker Owner: Luci Created: 2026-05-21 Last reviewed: 2026-05-21 Lucienne review: /Users/elmar/PKA/lucienne-review-luci-control-room-runtime-independence-report.md on Lucienne Claude Code review: /home/lucienne/workspace/reports/claude-code-review-luci-control-room-runtime-independence.md Hermes GLM review: /home/lucienne/workspace/reports/luci-control-room-runtime-independence-plan-review.md Source prompt: review Shann Holmberg's Hermes Agent Control Room recommendations and compare them with the current Luci / Mission Control setup. Related report: /home/lucienne/workspace/reports/mc-orchestrator-flow-diagram.html Canonical progress file for this initiative: this document. Mission Control tracking ticket: MC-3898 (identifier, not SQLite row id; title: Luci control room and runtime independence foundation)

2026-05-24 Lucienne status / PRD addendum

Current controller-status companion PRD:

• /home/lucienne/workspace/reports/mission-control-recovery-prd-status-2026-05-24.md

Use that PRD/status ledger for the live MC-4000 recovery state: what is completed, tested, reviewed, browser/Tessa-verified, signed off, and still outstanding.

This original plan remains the historical architecture and runtime-independence plan. Do not use the checklist below as the only live tracker; it now needs the PRD/status ledger as the current source for completion gates.

Summary as of 2026-05-24:

• Runtime-independence foundation and control-room governance are substantially complete.
• Runtime adapter metadata has landed, but runtime-switch continuity and low-risk Hermes-through-MC proof remain open.
• Tasks/Scheduler has completed the strongest page slice so far, including live/browser evidence.
• Workbench/Console has completed an audit/fix cycle but needs fresh regression/browser validation after test health is restored.
• MC-4049 campaign-owner/controller separation remains in progress and is a key control-plane dependency.
• Full-suite verification is currently blocked by a collection error and additional focused runtime/workflow test failures.
• MC-4000 should remain open until the PRD acceptance criteria are met.

Why this exists

Elmar wants to get the most out of Hermes, but not become dependent on Hermes, Claude, Gemini, Codex, or any single runtime. Mission Control should remain the durable operating layer: tickets, history, workbench, runtime ledger, routing, reports, task status, and recovery should survive model/runtime churn.

2026-05-22 clarification from Elmar: this work is not a Hermes project. Mission Control must stay harness-independent: Hermes can be a preferred and capable open-source adapter layer, especially because it is multi-provider and inspectable, but MC must not depend on Hermes-specific behavior for its core workflow. If Hermes, Claude Code, Codex CLI, Gemini CLI, or any provider stops working tomorrow, MC should still preserve the work ledger, routing contract, evidence trail, and user-facing operating model.

This document is both:

1. A report on how our current setup compares to the Hermes Agent Control Room pattern.
2. A todo/progress tracker we can revisit and update.

Storage rule going forward

We have been inconsistent about where plans, docs, and reports are saved. For this initiative, use this rule:

• ~/workspace/reports/ = decision reports, audits, plans, progress trackers, and human-readable artifacts.
• ~/workspace/mission-control/docs/ = canonical architecture contracts that code changes must obey.
• ~/workspace/wiki/ = compiled/reference system knowledge intended for broader operational lookup.
• ~/workspace/tasks/ = scheduled task definitions only.
• ~/workspace/luci-manifest.md and ~/workspace/CAPABILITIES.md = inventory/capability manifests, updated when deployed reality changes.

When a report becomes an architecture contract, create or update the matching file in mission-control/docs/ and link back to the originating report.

Source-of-truth boundary

Lucienne reviewed this plan on 2026-05-21 and approved the direction with one required boundary: the control room must be a governance/navigation layer, not a second source of truth.

/home/lucienne/workspace/agent-control-room/

Purpose: governance, navigation, operational index, and cross-system runbook entrypoint.

Allowed contents:

• pointers to canonical docs
• inspection commands
• recovery runbooks
• redacted environment maps
• links to live inventories
• runtime profile summaries that point to actual config/code
• templates for future docs

Not allowed:

• duplicated live task state
• duplicated scheduler definitions
• duplicated runtime architecture that conflicts with MC docs
• secrets
• copied service inventory that should live in luci-manifest.md or CAPABILITIES.md
• aspirational profile claims that do not match code or smoke tests

/home/lucienne/workspace/mission-control/docs/

Purpose: canonical architecture contracts that code must obey.

The existing canonical runtime architecture contract remains:

/home/lucienne/workspace/mission-control/docs/runtime-architecture-refresh.md

If runtime independence becomes a governing principle, create a focused supporting doc such as:

/home/lucienne/workspace/mission-control/docs/runtime-independence.md

and link it both ways with runtime-architecture-refresh.md.

/home/lucienne/workspace/reports/

Purpose: human-readable reports, plans, audits, diagrams, and progress trackers. The living plan belongs here. If a plan becomes an architecture contract, mirror or move the contract into mission-control/docs/.

/home/lucienne/workspace/luci-manifest.md and /home/lucienne/workspace/CAPABILITIES.md

Purpose: deployed inventory and capabilities. The control room links to these files instead of copying their contents.

Executive summary

We are not far off the article's recommended architecture. In capability terms, Luci + Mission Control is already beyond the article's Level 4 pattern: we have an orchestrator, ticket board, scheduler, workers, runtime workbench, gateway, skills, memory, health checks, and recurring automation.

The gaps are mostly about packaging and resilience:

• We do not have one explicit Agent Control Room folder or index.
• Profiles/runtimes are powerful but not yet documented as a portable registry.
• Mission Control is too coupled to specific CLIs in some places.
• The scheduler and MC runtime layer are custom and should be documented as the durable control plane rather than replaced by Hermes-native cron/kanban.
• We need a clearer rule: MC owns workflow state; runtimes are replaceable execution adapters.

Design principle

Mission Control must be runtime-agnostic.

Hermes, Claude Code, Codex, Gemini CLI, Kimi, GLM, browser agents, direct APIs, and future runtimes should all be swappable adapters under MC. The durable state must live in MC and Luci's control room, not inside any one runtime transcript.

Terminology for this initiative:

• runtime = executable/control surface that can do work, e.g. Claude Code CLI, Hermes CLI, Codex CLI, Gemini CLI, browser harness, Larry SSH runtime, direct API script.
• provider = upstream model/API vendor, e.g. Anthropic, OpenAI, xAI, Z.AI/GLM, Moonshot/Kimi, MiniMax, Google.
• model = provider-specific model identifier, e.g. Sonnet, Opus, GPT, Grok, GLM, Kimi, MiniMax.
• profile = MC/scheduler binding that chooses a runtime/provider/model/settings combination for a class of work.

Claude Code must be named explicitly as a first-class runtime. claude_anthropic, claude_glm, claude_kimi, and similar entries are profiles using the Claude Code/Claude CLI runtime with different provider bindings, not separate runtimes by themselves.

Core invariant:

human intent -> MC ticket/workstream -> runtime_sessions ledger -> runtime adapter -> harvested MC history -> review/close

If a runtime disappears, changes licensing, gets retired, or loses tool support, MC should only need a profile/adapter update, not a redesign.

Current-state assessment

Already strong

• Mission Control is the real task bus and source of truth.
• Runtime Workbench is the execution cockpit.
• runtime_sessions is the runtime ledger.
• Ticket history preserves work across runtime turns.
• Scheduler tasks already handle Level 4 automation.
• Luci already acts as orchestrator, not passive chat.
• Workers report up; Elmar gets one voice.
• Skills and persistent memory are enabled.
• Hermes can load Claude skills via skills.external_dirs.
• System services and capabilities are tracked in manifest/CAPABILITIES.

Main weaknesses

• No single control-room index for agents, runbooks, ports, env maps, backups, runtime profiles, and decision history.
• Current docs are spread across reports, MC docs, wiki, AGENTS.md, manifest, CAPABILITIES, task files, and chat history.
• Runtime profiles are not yet treated as a clean portability layer with capability declarations and retirement plans.
• Some code paths assume Claude/Hermes-specific behavior, especially around MCP/signals/tooling.
• hermes profile list currently shows only the default Hermes profile, so specialist separation is mostly in MC rather than Hermes profiles.
• Hermes persistent config may differ from the active runtime/model used in a session; this needs explicit policy rather than accidental drift.
• We need a clean rule for what the WebUI may change vs what must be documented/committed.
• Hermes WebUI is itself a config write surface if it can mutate ~/.hermes/config.yaml; govern it as a runtime/config control surface, not only as a dashboard.
• Telegram UX currently differs materially between Hermes and Luci Persistent: Hermes has a direct home-channel feel, while Luci Persistent is mostly reachable through CCGram/forum topics. This is partly UX, but it becomes an architectural risk if a runtime swap creates ambiguous routing between home-channel messages and topic-bound ticket/runtime messages.

Target architecture

1. Control Room wrapper

Create an explicit Luci control room layer without moving production systems prematurely.

Proposed location:

/home/lucienne/workspace/agent-control-room/

Start with the smallest useful structure, not a large aspirational tree:

agent-control-room/
  README.md
  shared/
    commands.md
  docs/
    runtime-independence.md
    webui-governance.md

This is a governance/navigation layer. It points to MC as the real work system and must not duplicate live state. Add more folders only when real content needs to live there.

2. Runtime abstraction

Define every runtime profile as an adapter with declared capabilities:

• backend: CLI, API, browser, remote host, shell, MCP-enabled CLI, etc.
• model/provider: OpenAI, Anthropic, xAI, Google, Kimi, GLM, MiniMax, local, etc.
• tool support: file, terminal, browser, MCP, vision, web, GitHub, messaging.
• safe task classes: code, review, summarization, triage, browsing, UI QA, scheduler, direct API.
• forbidden task classes: e.g. direct API/sentinel profiles must not be assigned tasks that assume Claude CLI tool/file-edit semantics unless the script explicitly implements and declares those capabilities.
• cost band.
• retirement fallback.
• smoke-test command.

Runtime profile inventory must be generated from code, not memory. In particular:

• scheduler.py::PROFILE_PROVIDER is the scheduler-dispatch profile list.
• scheduler.py::PROFILE_META includes additional metadata and sentinel/direct categories such as direct_gemini, direct_anthropic_sdk, and direct_mixed.
• scheduler.py::PROFILE_DEFAULTS is a static fallback; _runtime_profile_defaults() may resolve live defaults dynamically and may read ~/.claude/env/mc-runtime-profiles.json when present.
• Active MC runtime-profile state is separate from Hermes model.default; do not imply Hermes defaults control MC ticket/scheduler routing.

This becomes the layer that lets MC carry on if Hermes, Claude, Gemini CLI, or any other runtime changes.

3. MC remains the durable source of truth

Do not move production orchestration into Hermes cron/kanban just because Hermes has those features.

Use Hermes features where useful, but keep MC as the durable surface for:

• tickets
• runtime sessions
• workbench
• history
• status transitions
• WAT decisions
• scheduled task visibility
• review evidence
• audit trail

Hermes should be a powerful runtime and gateway, not the only place where workflow state lives.

4. WebUI governance

WebUI is allowed for:

• inspection
• light config changes
• session visibility
• tool visibility
• gateway/platform visibility

WebUI should not be the only source of truth for:

• production scheduler definitions
• runtime routing policy
• service inventory
• secrets policy
• Mission Control runtime architecture
• worker guardrails

Any meaningful WebUI/config change should be reflected in one of:

• ~/.hermes/config.yaml backup/change note
• control room docs
• luci-manifest.md
• CAPABILITIES.md
• MC architecture docs, if runtime behavior changed

Before and after any meaningful Hermes WebUI/config change, capture a config snapshot or diff (~/.hermes/config.yaml backup plus hermes config/dashboard-visible setting summary) so WebUI drift is reviewable later.

Required gates

Architecture/docs gate

Any change to Mission Control runtime architecture, PKA operating behavior, or canonical docs requires Atlas-style review/signoff.

Code/runtime gate

Any code change touching runtime routing, provider selection, tmux/session lifecycle, scheduler dispatch, Telegram routing, or runtime profile enforcement requires:

• regression tests
• second-opinion/council review if the change is broad, security-sensitive, or touches provider/auth behavior

UI gate

Any change to Runtime Workbench, Mission Control UI, Hermes WebUI behavior, or dashboard pages requires Tessa validation with screenshot evidence.

Secrets/security gate

No secrets may be copied into the control-room docs. Environment maps must be redacted and point to the authoritative secret location/SOP.

Progress checklist

Legend: [ ] not started, [~] in progress, [x] done.

Phase 0: Preserve this plan

• [x] Create this durable plan/report in ~/workspace/reports/.
• [x] Patch this plan with Lucienne review: source-of-truth boundary, gates, deferred model-default decision, and inventory-first implementation order.
• [x] Add a reports index so future plans/reports are easier to find.
• [x] Decide whether this initiative also needs a Mission Control ticket or can stay as a standing plan. Decision: created MC-3898 before implementation.

Phase 1: Minimal control-room skeleton

• [x] Create /home/lucienne/workspace/agent-control-room/.
• [x] Add README.md explaining that MC is the production task bus and the control room is the governance/navigation layer only.
• [x] Add shared/commands.md with common inspection commands.
• [x] Add docs/runtime-independence.md with the runtime-agnostic principle and links to canonical MC docs.
• [x] Add docs/webui-governance.md with what can/cannot be changed through WebUI alone.
• [x] Do not create broader agent subfolders until there is real, source-linked content for them.
• [~] Add reverse link from mission-control/docs/runtime-architecture-refresh.md to agent-control-room/docs/runtime-independence.md (deferred — touches canonical contract; route via Atlas-style signoff per architecture/docs gate).
• [~] Phase 1 landed structurally, but reviewer amendments below must be applied before Phase 2/3 expands the registry.

Phase 1.5: Runtime adapter contract amendments

Purpose: make the implicit Luci/MC runtime contracts explicit before expanding the registry or changing any runtime/model defaults. This is the first safe implementation step because it is docs/inventory only: no service restarts, no model changes, no Telegram routing changes, no scheduler behavior changes.

• [x] Patch agent-control-room/docs/runtime-independence.md with a Runtime adapter contract section covering:
• runtime_sessions minimum ledger expectations: session id, ticket id or task id, runtime/profile, started/ended timestamps, status, harvest/log path, terminal summary/artifacts.
• terminal-state output shape required for harvested workers and recovery loops.
• worktree-pool rule: MC workers may claim ~/workspace/.claude/worktrees/pool-{0,1,2}; persistent Luci must not; worker runtimes must commit/push before DONE.
• CCGram one-poller invariant: CCGram remains the sole inbound Telegram poller unless explicitly replaced; long-running claude processes must use --settings ~/.claude/settings-worker.json.
• Telegram outbound safety: use approved POST-only notification path such as notify.py; no extra bot polling.
• runtime-profile honesty: scheduled task runtime_profile must match what actually runs; direct SDK/API scripts need explicit direct_* metadata/description.
• rollback rule: revert runtime profile/override first, verify, and restart only the affected service if operationally necessary and allowed.
• [x] Rebuild the runtime profile inventory from code:
• scheduler-dispatch profiles from scheduler.py::PROFILE_PROVIDER.
• metadata/sentinel categories from scheduler.py::PROFILE_META, including direct_gemini, direct_anthropic_sdk, and direct_mixed.
• default/fallback behavior from PROFILE_DEFAULTS, _runtime_profile_defaults(), and ~/.claude/env/mc-runtime-profiles.json if present.
• [x] Name Claude Code CLI, Hermes CLI, Codex CLI, Gemini CLI, browser harness, Larry SSH runtime, and direct API scripts as runtimes, separate from provider/model/profile names.
• [x] Add runtime-profile lint as an exposed smoke test: python3 scripts/audit_task_runtime_profiles.py --lint.
• [x] Add cost-baseline collection as a Phase 4 prerequisite before model/cost routing decisions; treat subscriptions as capacity/availability constraints, not only per-token cost.
• [x] Add CAPABILITIES.md/control-room discoverability entry if the control room is treated as deployed operational infrastructure.
• [x] Preserve MC-3898 as the correct Mission Control identifier; do not confuse it with SQLite row id 3907.

Phase 2: Registry and runbooks

• [x] Inventory before writing target-state docs.
• [x] Link luci-manifest.md and CAPABILITIES.md from the control room rather than duplicating them.
• [x] Add source-linked runtime registry: agent-control-room/docs/runtime-profiles.md.
• [x] Add class-level runbook index and first operational runbooks under agent-control-room/runbooks/.
• [x] Add per-agent/runbook pages only when they point to authoritative live files, configs, commands, or recovery procedures.
• [x] Avoid copied service inventory; link to manifest/CAPABILITIES instead.
• [x] Avoid aspirational profile claims that do not match code or smoke tests.
• [x] Add reverse links from canonical MC docs after Atlas-style signoff.

Phase 3: Runtime profile portability

• [x] Inventory current MC runtime profiles and where they are defined.
• [x] Create docs/runtime-profiles.md or agents/mission-control/runtime-profiles.md.
• [x] Add Phase 3 evidence file: agent-control-room/docs/runtime-portability-inventory.md.
• [~] Document registry-level backend/provider/model/cost posture and link read-only/lint smoke commands; per-profile fallback/smoke detail remains in runbooks/policy as needed.
• [x] Identify Claude-specific assumptions.
• [x] Identify Hermes-specific assumptions.
• [x] Identify Gemini/Codex/Kimi/GLM support status and retirement risk.
• [x] Document active migration path for Gemini CLI deprecation/retirement and equivalent future CLI retirement.
• [x] Document runtime-switch continuity requirements and verification query in runbook.
• [ ] Validate runtime-switch continuity with a low-risk ticket/session test.
• [x] Confirm direct API profiles are hidden or blocked for tasks requiring tools/file edits.

Phase 3.5: Hermes adapter reference hardening

• [x] Review lotsoftick/hermes_client as a concrete Hermes web-cockpit reference.
• [x] Add Lucienne addendum: ~/workspace/reports/lucienne-review-luci-runtime-independence-hermes-client-addendum-2026-05-22.md.
• [x] Add control-room reference note: ~/workspace/agent-control-room/docs/hermes-client-reference.md.
• [x] Add source note under Mission Control reports: ~/workspace/mission-control/reports/mission-control-hermes-client-source-note.md.
• [x] Convert the reference into a concrete HermesProfileRuntimeAdapter implementation brief before any code changes.
• [ ] Validate one low-risk Hermes profile/session path through MC before changing production runtime routing.
• [ ] If canonical MC runtime docs are patched, run Atlas-style signoff and link the evidence.

Phase 3.6: HermesProfileRuntimeAdapter implementation slice

Status: ready for coder lane; no live runtime changes made by this planning step.

Reference brief: - ~/workspace/reports/hermes-profile-runtime-adapter-implementation-brief-2026-05-22.md - ~/workspace/agent-control-room/docs/hermes-profile-runtime-adapter-implementation-brief.md - ~/workspace/mission-control/reports/hermes-profile-runtime-adapter-implementation-brief-2026-05-22.md

Evidence gathered read-only: - MC already has Hermes runtime profiles: hermes_grok, hermes_codex, hermes_glm, hermes_kimi, hermes_minimax. - persistent_luci.py::_command_for_profile() already has a cli == "hermes" command branch. - Hermes is installed on Luci at /home/lucienne/.local/bin/hermes and /home/lucienne/.hermes/hermes-agent/venv/bin/hermes. - Hermes CLI help confirms the required launch flags: --provider, --model, --source, --pass-session-id, --accept-hooks, --yolo. - models.preflight_runtime_profile() currently reports Hermes profiles as available.

Implementation intent: - Make Hermes runtime launch honest and inspectable before relying on it for production work. - Resolve the Hermes executable explicitly and use the same resolver for preflight and launch. - Record adapter metadata in runtime_sessions: adapter name, command contract version, resolved executable, redacted argv, MC runtime profile, Hermes profile/isolation mode, provider/model, cwd, source tag, pane log path, and reconciliation status. - Label current Hermes profiles as provider/model overrides on the default Hermes profile unless/until dedicated Hermes profiles such as luci-codex, luci-kimi, or luci-glm are created. - Define SessionFileReconciler as a future import path only; MC remains the source of truth.

Non-goals: - No Hermes update. - No default-runtime switch. - No Telegram poller change. - No service restart. - No scheduler authority change. - No wholesale copy of lotsoftick/hermes_client.

Phase 4: Model and cost routing policy

• [x] Decide intended default interactive Luci runtime/model. Decision: keep MC interactive/persistent on claude_opus_1m_medium for now; no live config change.
• [x] Decide whether Hermes model.default should be updated only after policy, capability inventory, and smoke tests. Decision: do not change Hermes default in Phase 4; revisit after WebUI governance and Hermes smoke tests.
• [x] Define default model bands: premium, standard, cheap/subscription, direct API, local/fallback.
• [x] Define subscription-aware routing bands: paid subscription capacity, metered API spend, quality/reliability, sensitivity, and tool support.
• [x] Define which work must use premium models.
• [x] Define which recurring tasks should use cheaper profiles.
• [~] Add monthly/weekly cost visibility report or link existing one. Phase 4 policy now defines the required report contents; implementation remains future work.
• [x] Audit scheduled tasks for runtime-profile honesty. Ran distribution pass across ~/workspace/tasks/*.md; lint verification below remains the acceptance check.
• [~] Phase 4 policy drafted from profile inventory, task distribution, and limited cost-ledger caveats; full cost/capacity baseline remains future work before routing changes.
• [~] Policy now requires quota/rate-limit/reliability evidence before expanding subscription-backed production routing; evidence collection remains future work.

Phase 5: WebUI and config workflow

• [~] Open Hermes WebUI/dashboard for inspection. Decision on 2026-05-21: do not open it without a concrete reason; WebUI remains optional, read-mostly convenience, not required infrastructure.
• [~] Document current visible config screens and what settings are safe to change there. Deferred until first actual WebUI use; boundary documented instead so we do not invent screen-level claims.
• [x] Add a config-change checklist: backup, change, verify, document, restart only when asked/needed.
• [x] Add rule that WebUI changes affecting production behavior must be mirrored into the control room docs.
• [x] Add explicit rule that Hermes WebUI must not become a shadow control plane for MC routing, scheduler behavior, worker launch settings, Telegram polling, secrets, or runtime-profile policy.

Phase 5A: Telegram home-channel and topic routing

• [ ] Decide the desired UX contract: one direct Luci home channel plus topic-bound ticket channels, or topic-only for Luci Persistent.
• [ ] Document the authoritative routing order for Telegram messages: explicit ticket reference, bound topic, explicit /luci, then home-channel persistent fallback.
• [ ] Ensure home-channel plain text cannot accidentally route into a ticket topic runtime.
• [ ] Ensure ticket-topic plain text cannot accidentally route into Persistent Luci unless explicitly rebound with /luci or /persistent_topic.
• [ ] Decide whether CCGram remains the only inbound poller, or whether an MC-native bridge should replace/augment it without violating the one-bot-token-poller rule.
• [ ] Add a collision test matrix covering private/home chat, forum general topic, persistent topic, ticket topic, and messages containing MC-123.
• [ ] Add this to the runtime-independence docs because replacing Luci Persistent with Hermes/OpenAI/Codex should not change Telegram routing semantics.

Phase 6: Report/index hygiene

• [x] Create ~/workspace/reports/README.md with report categories and canonical current plans.
• [x] Add this plan to that index.
• [x] Add the prior MC orchestrator flow diagram to that index.
• [x] Define naming convention: topic-purpose-YYYY-MM-DD.md for dated reports; topic-plan.md for living plans.
• [ ] Decide whether old important reports should be linked from the index.

Phase 7: Acceptance tests

The initiative is healthy when:

• [ ] Elmar can ask "where is the current Hermes/MC runtime independence plan?" and Luci can point to this file immediately.
• [ ] A new runtime can be added without changing MC's conceptual architecture.
• [ ] A runtime can be retired by changing profiles/adapters and fallback docs, not by redesigning workflow.
• [ ] Ticket history remains readable after runtime switching.
• [ ] WebUI changes are not lost because they are reflected in docs/config history.
• [ ] Scheduled jobs and runtime profiles remain honest about what model/provider they actually use.
• [ ] The control room can answer: what runs where, what ports exist, where secrets live, how to recover, and what runtime to use for a given job.

Immediate next actions

1. Use MC-3898 as the tracking ticket/project for this initiative; this is the MC identifier, while SQLite row ids may differ.
2. Complete Phase 1.5 before expanding Phase 2/3: patch the governance docs with the runtime adapter contract and rebuild runtime inventory from code.
3. Keep this first step docs/inventory-only: no service restarts, no model/default changes, no Telegram routing changes, no scheduler behavior changes.
4. Link any governing runtime-independence doc both ways with mission-control/docs/runtime-architecture-refresh.md via Atlas-style signoff.
5. Inventory runtime profiles and current provider/model defaults before proposing runtime-routing code changes.
6. Continue Phase 3 as portability/capability evidence. Keep Phase 4 policy separate and subscription-aware: most current work may be on subscriptions, but routing still needs capacity, reliability, sensitivity, and tool-support evidence.
7. Defer changing Hermes persistent default from grok-4.3 until model-routing policy, capability inventory, and smoke tests are complete.

Notes from initial review

Observed on 2026-05-21:

• Hermes profile list showed one profile: default.
• Hermes config summary showed persisted model default/provider as grok-4.3 / xai-oauth, while this chat was switched to gpt-5.5 via OpenAI Codex.
• Hermes cron list showed no Hermes-native cron jobs; production scheduling lives in ~/workspace/tasks/ and Mission Control scheduler.
• Mission Control DB exists at /home/lucienne/workspace/mission-control/mc.db.
• ~/workspace/tasks/ contains many production scheduled task definitions.
• ~/workspace/reports/mc-orchestrator-flow-diagram.html is an example of a valuable saved report that should be indexed.

Open decisions for Elmar

• Should the control room live inside ~/workspace/agent-control-room/, or somewhere more prominent like ~/agent-control-room/? Current working default: keep it in ~/workspace/agent-control-room/ unless Elmar explicitly changes it.
• MC tracking ticket: MC-3898 (identifier). Do not rename to MC-3907; that number is the SQLite row id observed during review, not the ticket identifier.
• Should Hermes persistent default be changed later, after model-routing policy and smoke tests? Current recommendation: defer.

Update protocol

When we make progress, update this file in place:

• mark checklist items [x]
• add date-stamped notes under this section
• link any created docs/reports/tickets
• do not bury progress only in chat history

Progress notes

• 2026-05-21: Created initial plan/report and progress checklist.

• 2026-05-21: Incorporated Lucienne review from /Users/elmar/PKA/lucienne-review-luci-control-room-runtime-independence-report.md: added source-of-truth boundary, required gates, minimal skeleton scope, inventory-first runtime profile approach, reports-index staleness fix, and deferred model-default decision.

• 2026-05-21: Created Mission Control tracking ticket MC-3898, Luci control room and runtime independence foundation.
• 2026-05-21: Phase 1 skeleton landed under ~/workspace/agent-control-room/ — README.md, shared/commands.md, docs/runtime-independence.md, docs/webui-governance.md. Includes observed runtime-profile inventory (scheduler/worker, Larry, Hermes) sourced from scheduler.py and mc_pickup.py. No runtime routing code, Telegram routing, Hermes defaults, scheduler state, or secrets touched. Reverse link from runtime-architecture-refresh.md deferred to Atlas signoff.
• 2026-05-21: Incorporated Claude Code and Hermes GLM review findings with scepticism. Accepted adapter-contract, runtime-inventory, CCGram, worktree-pool, rollback, cost-baseline, and WebUI-governance amendments. Rejected GLM's MC-3898→MC-3907 correction because database verification showed MC-3898 is the ticket identifier and 3907 is the SQLite row id.
• 2026-05-21: Executed the first safe step: patched ~/workspace/agent-control-room/docs/runtime-independence.md with the Phase 1.5 runtime adapter contract and code-derived runtime inventory; added Agent Control Room discoverability to CAPABILITIES.md and luci-manifest.md; ran python3 scripts/audit_task_runtime_profiles.py --lint successfully. No service restarts, runtime routing changes, Telegram changes, scheduler changes, or model-default changes.
• 2026-05-21: Continued Phase 2 with a source-linked runtime registry (agent-control-room/docs/runtime-profiles.md) and class-level runbooks (agent-control-room/runbooks/). Clarified that cost/model policy is Phase 4 and must be subscription-aware: most current work may run on subscriptions, so policy should account for quota/capacity, reliability, sensitivity, and tool support, not only token cost. No runtime routing, service, Telegram, scheduler, or model-default changes.
• 2026-05-21: Continued Phase 3 portability inventory in agent-control-room/docs/runtime-portability-inventory.md. Confirmed MC active runtime-profile state comes from ~/.claude/env/mc-runtime-profiles.json (claude_opus_1m_medium for persistent/ticket/default/worker and claude_glm for scheduler), separate from Hermes config. Documented Claude-specific, Hermes-specific, Codex/Gemini/Kimi, direct API, and subscription-capacity risks. No runtime routing, service, Telegram, scheduler, or model-default changes.
• 2026-05-21: Completed the remaining Phase 3 documentation gates by adding agent-control-room/runbooks/runtime-retirement-migration.md and agent-control-room/runbooks/runtime-switch-continuity.md. These cover Gemini CLI retirement/replacement, equivalent future runtime retirement, and continuity requirements for preserving old logs/session rows during runtime switches. No runtime routing, service, Telegram, scheduler, or model-default changes.
• 2026-05-21: Drafted the Phase 4 subscription-aware routing policy in agent-control-room/docs/subscription-aware-routing-policy.md. It keeps current MC interactive/persistent defaults on claude_opus_1m_medium, defers Hermes model.default changes, defines premium/standard/cheap-subscription/direct/local bands, captures scheduled-task runtime-profile distribution as evidence, and specifies the required future cost/capacity report. No runtime routing, service, Telegram, scheduler, or model-default changes.
• 2026-05-21: Applied second-opinion fixes to the Phase 3/4 plan and runbooks: downgraded over-strong completion claims, added runtime-switch validation as a future test, made cost/capacity evidence status explicit, added rollback/runtime-profile honesty/Telegram/worktree checks to runbooks, corrected OpenAI/Codex model wording, added a reproducibility command for task-profile distribution, and added the Atlas-signoff reverse link from mission-control/docs/runtime-architecture-refresh.md to agent-control-room/docs/runtime-independence.md. Atlas-style signoff returned PASS-WITH-NOTES for the scoped architecture-doc update. No runtime routing, service, Telegram, scheduler, or model-default changes.

• 2026-05-21: Closed the minimum Phase 5 WebUI/config governance gap without opening or depending on the WebUI. Updated agent-control-room/docs/webui-governance.md to state that Hermes WebUI is optional convenience, preferably read-mostly, and must not become a shadow control plane for MC routing, scheduler behavior, worker launch settings, Telegram polling, secrets, or runtime-profile policy. Kept screen-level documentation deferred until first real WebUI use to avoid inventing claims. No runtime routing, service, Telegram, scheduler, WebUI, or model-default changes.

• 2026-05-22: Lucienne reviewed lotsoftick/hermes_client as a concrete Hermes web-cockpit reference. Added ~/workspace/mission-control/reports/mission-control-hermes-client-source-note.md, ~/workspace/reports/lucienne-review-luci-runtime-independence-hermes-client-addendum-2026-05-22.md, and ~/workspace/agent-control-room/docs/hermes-client-reference.md. Treated it as adapter inspiration only: no service restarts, runtime routing changes, scheduler changes, Telegram changes, WebUI changes, or Hermes default changes.

• 2026-05-22: Lucienne added the concrete HermesProfileRuntimeAdapter implementation brief after read-only inspection of MC runtime profile code, Hermes CLI availability, and preflight behaviour. Added Phase 3.6 to this plan and linked the brief in reports/README.md. No live runtime routing, service, Telegram, scheduler, WebUI, Hermes update, or model-default changes.