← Reports
For Elmar · before implementation

The simple mental model for Luci, MC, and workers

This is the operating model as an interactive map: how tickets move, who decides, when workers are called, how runtime guidance works, and what must be visible on the board.

1. Controller decidesLuci/Lucienne choose routing, workers, tools, models, and gates.
2. Mission Control recordsMC is the durable ledger: tickets, comments, evidence, status, audit trail.
3. Runtimes executeClaude, Codex, Kimi, Gemini, Grok, scripts, browser, Larry/Mac are replaceable adapters.
01 · System flow

One line: decide → record → execute → prove

The important separation is between decision authority and durable state. The controller decides; MC records the state; workers do the work; evidence is harvested back before the user hears “done”.

1
Human intentTelegram, MC comment, schedule, or event trigger.
2
Controller decisionLuci/Lucienne decides whether to answer, plan, spawn a worker, or ask Elmar.
3
MC ledgerTicket/comment/status/evidence trail is recorded for visibility.
4
Worker executionClaude/Codex/Kimi/Gemini/Grok/script/browser does the work.
5
Evidence gateTests, screenshots, review, logs, links — then Done.
02 · Board

Elmar sees three columns. Complexity hides inside labels.

Mission Control should feel like a clean task list: Inbox, Todo, Done. Internal states like reviewer, waiting, blocked, or validator live as labels/details inside Todo — not as a second mental model.

Inbox new / untriaged

“Improve Control Room model”
needs triage

Todo active / waiting / review

Build event-driven ticket hooks
coderClaude Code
Review design proposal
waiting_elmarplease review link
Validate runtime policy
reviewerGrok

Done closed with evidence

Control Room explainer
validatedevidence linked

Click a ticket card to see what its label means.

03 · Team

Roles are gates, not mandatory people every time

The team model gives the controller a checklist. A small task might skip almost all of it. A risky UI/runtime change might use the full chain.

04 · Runtime/model guidance

The controller can pick any fitting capability

This is guidance, not a constraint. The controller may choose any tool, runtime, subagent, subprocess, direct script/API, browser harness, remote host, or future adapter it judges best — then records the choice and evidence back to MC.

Pick a task type

Choose a chip above to see advisory defaults. The controller can override them whenever a better capability fits.

05 · When you comment

A comment notifies the controller; it should not auto-spawn a random runtime

The desired model is “message to the owner/controller”, not “immediately inject into whichever runtime used to be attached”.

1
Elmar comments“Please review this report and tell me if it’s right.”
2
Hook/watcher firesEvent goes to Luci/Lucienne controller, not directly to stale runtime.
3
Controller decidesAnswer directly, call reviewer, ask for input, or spawn worker.
4
MC updatesTicket comment shows who acted, with evidence and next step.
06 · Scheduled work

Hermes cron and MC scheduled tasks both stay — for different jobs

Use deterministic Hermes cron for cheap alerts/watchers. Use MC scheduled tasks for complex recurring work with artifacts and evidence.

H Hermes cron

Best for lightweight watchers and human-facing alerts.

  • Runs deterministic Python/script
  • no_agent: true
  • Empty stdout = silent
  • Near-zero cost

MC MC scheduled tasks

Best for recurring work that produces evidence or artifacts.

  • Lives in ~/workspace/tasks/
  • Uses runtime profiles
  • Records task runs
  • Suitable for reports/audio/audits
07 · Audit trail

Every worker leaves a useful handoff comment

The board should show what happened without making you inspect tmux panes or raw logs.

Luci
Assigned phase: PlannerScope: turn Elmar’s intent into implementation plan. Runtime: Hermes/Kimi. Next: designer only if UI surface changes.
Planner
Outcome: completedEvidence: plan link. Risks: runtime/comment hooks and board labels. Next: Coder with Claude Code or Codex.
Coder
Outcome: implementation completeFiles changed, tests run, known gaps. Next: Reviewer. Reviewer must be different provider/model.
Reviewer
Verdict: send_back / approved / blockedFindings with severity, file paths, suggested fixes. No self-approval by Coder.
Tester
UI evidenceBrowser journey steps, 375px screenshot, console result, UX blockers. Required for UI Done.
Validator
Final gateChecks evidence, host, tests, screenshots, diff, deploy approval. Controller then marks Done.
08 · Vocabulary

Four words to keep straight

Runtime

Executable surface

Claude Code CLI, Hermes CLI, Codex, Gemini, script, browser harness, Larry SSH.

Provider

Vendor/account

Anthropic, OpenAI, Google, xAI, Z.AI, Moonshot, MiniMax.

Model

Specific brain

Opus, Sonnet, GPT, Gemini, Grok, GLM, Kimi, MiniMax.

Profile

Operating lane

Runtime + provider + model + tools + permissions + reporting contract.

Implementation readiness:Spec is understandable; implementation should start with plan + council + board/label design, not direct code.