Lucienne Review: Luci Control Room and Runtime Independence Plan

Reviewer: Lucienne For: Luci Date: 2026-05-21 Subject: Review of /home/lucienne/workspace/reports/luci-control-room-runtime-independence-plan.md

Executive verdict

I approve the direction of the proposal, with required revisions before implementation.

The central idea is correct: Mission Control must remain the durable control plane, while Hermes, Claude Code, Codex, Gemini, Kimi, GLM, browser agents, direct APIs, and future runtimes are replaceable execution adapters.

The proposal is strongest where it says:

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

That matches Mission Control's existing runtime architecture contract. The work should therefore strengthen and package the current architecture, not create a parallel system.

My approval is conditional on one boundary: the proposed agent-control-room/ must be a governance and navigation layer, not a second source of truth.

Review scope

I reviewed the proposal against:

• the current Luci proposal file: /home/lucienne/workspace/reports/luci-control-room-runtime-independence-plan.md
• the existing reports index: /home/lucienne/workspace/reports/README.md
• the current Mission Control runtime architecture contract: /home/lucienne/workspace/mission-control/docs/runtime-architecture-refresh.md
• the observed Mission Control runtime/profile-related code paths, including:
• models.py
• runtime_picker.py
• dispatch_policy.py
• ticket_runtime.py
• runtime_pool.py

What is right in the proposal

1. The strategy is correct

The proposal correctly identifies the architectural priority:

Mission Control owns workflow state. Runtimes execute work.

This is the right direction. The system should survive changes in runtime availability, pricing, licensing, UX, or tool support. If Hermes disappears, Claude changes auth, Gemini CLI retires, or Codex becomes the preferred runtime, MC should need profile/adapter changes rather than a conceptual redesign.

2. MC should remain the durable layer

I agree that production orchestration should not be moved wholesale into Hermes cron, Hermes kanban, Claude transcripts, or any other runtime-native feature just because those features exist.

Hermes can be a powerful runtime and gateway. It should not become the only durable workflow store.

MC should remain authoritative for:

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

3. Runtime profile portability is the right problem

The proposal correctly spots that runtime profiles need to become explicit adapters with declared capabilities.

The system already has parts of this:

• runtime_sessions tracks cli, provider, model, effort, profile_key, and metadata.
• dispatch_policy.py distinguishes cheap external profiles, direct API profiles, safe defaults, and tool-using work.
• models.py references ~/.claude/env/mc-runtime-profiles.json.

But some current code remains Claude-shaped, especially tier defaults in runtime_picker.py.

This is not a reason to reject the plan. It is the reason to implement it carefully.

4. Telegram routing belongs in the plan

The Telegram section is important and should stay.

The difference between Hermes direct home-channel UX and Luci Persistent via CCGram/forum topics is not just cosmetic. If runtime swapping changes message routing semantics, Elmar will lose trust in the system.

Telegram routing needs an explicit contract and test matrix.

Minimum routing order should be:

1. explicit ticket reference, e.g. MC-123
2. bound topic
3. explicit /luci
4. home-channel persistent fallback

Required safety invariants:

• Home/private plain text must not accidentally route into a ticket runtime.
• Ticket-topic plain text must not accidentally route into Persistent Luci unless explicitly rebound.
• One bot token must not have competing independent pollers.
• Runtime replacement must not change routing semantics.

Main concern: avoid a second source of truth

The proposal says we do not have one explicit Agent Control Room folder or index. That is true at the Luci-wide navigation level.

But Mission Control already has a canonical runtime architecture contract:

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

That file explicitly governs:

• ticket runtimes
• Runtime Workbench
• WAT/workflow actions
• tmux/session handling
• provider/runtime profile selection
• Telegram runtime routing
• runtime QA gates

Therefore, the new control-room structure must not duplicate that contract.

Required source-of-truth boundary

Before implementation, add this boundary to the plan:

~/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

~/workspace/mission-control/docs/

Purpose: canonical architecture contracts that code must obey.

The existing runtime architecture contract remains:

docs/runtime-architecture-refresh.md

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

docs/runtime-independence.md

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

~/workspace/reports/

Purpose: human-readable reports, plans, audits, diagrams, and progress trackers.

The plan itself belongs here. But when a report becomes an architecture contract, the contract must move or be mirrored into mission-control/docs/.

~/workspace/luci-manifest.md and ~/workspace/CAPABILITIES.md

Purpose: deployed inventory and capabilities.

The control room should link to these files instead of copying their contents.

Staleness found during review

The plan checklist currently says:

[ ] Create ~/workspace/reports/README.md

But the file already exists:

/home/lucienne/workspace/reports/README.md

It already links this plan and the MC orchestrator flow material.

Required update:

• mark that checklist item done
• add a progress note that the reports index exists
• avoid redoing this step during implementation

Recommended implementation order

Do not start by creating a large new folder tree full of aspirational docs.

Use this order instead:

Step 1: Patch the plan

Update the existing plan with:

• source-of-truth boundary
• reports README already done
• explicit gates
• deferred model-default decision
• inventory-first runtime profile approach

Step 2: Create an MC ticket/project

This is multi-phase PKA/Luci system governance work. It should not live only as a report.

Create an MC ticket or project before implementation begins.

Suggested title:

Luci control room and runtime independence foundation

Suggested first phase:

Create control-room skeleton as pointer/index only

Step 3: Create the smallest useful control-room skeleton

Start with:

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

Keep these files concise. They should point to existing sources of truth.

Do not create every proposed subfolder until there is content that needs to live there.

Step 4: Link architecture contracts both ways

If mission-control/docs/runtime-independence.md is created, it must link to:

mission-control/docs/runtime-architecture-refresh.md

And runtime-architecture-refresh.md should link back to the runtime-independence doc if the new doc becomes governing architecture.

Step 5: Inventory actual runtime profiles

Before writing target-state runtime profile policy, inventory the current reality:

• where profiles are defined
• what profile keys exist
• which profiles are Claude CLI, Hermes, Codex, Gemini, Kimi, GLM, direct API, browser, or shell
• which profiles support tools
• which profiles support file edits
• which profiles support terminal
• which profiles support browser/vision
• which profiles are safe for sensitive work
• which profiles are cheap/public-read-only only
• smoke-test command for each profile
• fallback/retirement path for each profile

Step 6: Only then change runtime routing code

Once the inventory is accurate, decide whether code changes are needed in:

• runtime_picker.py
• dispatch_policy.py
• models.py
• ticket_runtime.py
• scheduler pickup/runtime selection

Any code change here needs regression tests.

Model default recommendation

Do not change the Hermes persistent default yet.

The proposal notes that Hermes config showed persisted default/provider as grok-4.3 / xai-oauth, while the active session was using GPT/OpenAI Codex.

That drift should be documented. But it does not automatically prove that the persisted default should change.

Correct order:

1. define model-routing policy
2. define task classes and cost bands
3. confirm tool support by runtime
4. smoke-test candidate defaults
5. then decide the persistent default

Until then, leave the default as-is and document that active session runtime may differ from persisted config.

Required gates

Before implementation, the plan should state these gates explicitly:

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.

Acceptance criteria I would add

The initiative is healthy only when all of these are true:

• agent-control-room/ exists as an index/governance layer, not a duplicate source of truth.
• Every inventory page links to the authoritative live file or config.
• reports/README.md links the plan and is up to date.
• runtime-architecture-refresh.md and any new runtime-independence doc link to each other.
• Runtime profile documentation matches actual config/code.
• Each runtime profile has a smoke-test command.
• Direct API profiles are explicitly marked as unsuitable for tool/file/terminal work unless proven otherwise.
• Runtime routing code changes have regression tests.
• Telegram routing has a collision test matrix.
• WebUI/config changes affecting production behavior are mirrored into config history, docs, manifest, or CAPABILITIES as appropriate.
• Elmar can ask “where is the current runtime independence plan?” and Luci can answer with the current file path immediately.

Inversion: how this plan could fail

Failure mode 1: The control room becomes stale

Probability: medium

If agent-control-room/ duplicates live state instead of linking to source files, it will rot quickly.

Mitigation: use it as an index and runbook layer only.

Failure mode 2: Documentation outruns implementation

Probability: medium

The team may produce polished runtime-independence docs while code still hardcodes Claude assumptions.

Mitigation: inventory current code/config before writing target-state policy.

Failure mode 3: Runtime profiles remain labels, not contracts

Probability: high

If profile capabilities are not smoke-tested or enforced, MC can still route tool-using work to incapable runtimes.

Mitigation: every profile needs declared capabilities, forbidden task classes, and a smoke test.

Failure mode 4: WebUI becomes hidden production state

Probability: medium

If settings are changed in WebUI but not mirrored into config/docs/history, behavior becomes mysterious and hard to recover.

Mitigation: WebUI governance doc plus config-change checklist.

Failure mode 5: Telegram routing ambiguity damages trust

Probability: medium

A single misrouted home-channel or ticket-topic message could make the runtime architecture feel unsafe.

Mitigation: explicit routing order and collision test matrix.

Failure mode 6: Governance slows useful work

Probability: low to medium

If every tiny doc update requires heavy process, the docs will stop being maintained.

Mitigation: heavy gates only for code/runtime/security/UI changes; lightweight updates for index docs.

Bias scan

Availability misweighing

Severity: medium

The proposal is partly shaped by the current Hermes/WebUI/GPT runtime discussion. That may overweight the runtime currently in front of us.

Mitigation: base default-runtime decisions on policy and smoke tests, not the latest successful session.

Overoptimism

Severity: medium

The plan assumes inventories and docs will remain current.

Mitigation: tie updates to actual change workflows and source-of-truth links.

Twaddle risk

Severity: medium

“Agent Control Room” sounds useful, but it only matters if each page points to real commands, files, configs, tests, or recovery paths.

Mitigation: no placeholder sprawl. Create only useful docs.

Reason-respecting

Severity: positive

The proposal has a clear reason: runtime independence. That is good.

Inconsistency avoidance

Severity: low/positive

The proposal correctly challenges current Claude/Hermes coupling instead of preserving it blindly.

Final recommendation

Proceed, but revise first.

I would authorize Luci to do the following now:

1. Patch the existing plan with the source-of-truth boundary and gate requirements.
2. Mark the reports README task as complete.
3. Create an MC ticket/project for the initiative.
4. Create a minimal agent-control-room/ skeleton as an index only.
5. Draft runtime-independence.md and webui-governance.md as concise contracts that link back to canonical MC docs.
6. Inventory current runtime profiles before proposing code changes.

I would not yet authorize:

• changing the Hermes persistent default model
• changing runtime routing code
• changing Telegram routing behavior
• moving scheduler/workflow state into Hermes-native features
• creating a large duplicated control-room folder tree

Suggested instruction to Luci

Luci, please revise your plan before implementation.

Keep the direction, but add the source-of-truth boundary: Mission Control remains the durable work system; agent-control-room/ is an index/governance layer; mission-control/docs/runtime-architecture-refresh.md remains the canonical runtime architecture contract; manifests/CAPABILITIES remain deployed inventory; no secrets or duplicated live state go into the control-room docs.

Then create an MC ticket for Phase 1 and implement only the minimal control-room skeleton. Defer model-default and runtime-routing changes until after the runtime profile inventory and smoke tests are complete.