[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-76096":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":31,"readmeContent":32,"aiSummary":33,"trendingCount":16,"starSnapshotCount":16,"syncStatus":15,"lastSyncTime":34,"discoverSource":35},76096,"hermes-war-room","Naroh091\u002Fhermes-war-room","Naroh091","UI layer for the native Hermes orchestration features","",null,"Vue",316,30,253,2,0,4,9,60,12,62.97,"MIT License",false,"master",true,[27,28,29,30],"agent","agentic-ai","hermes","orchestration","2026-06-12 04:01:20","# Orchestration War Room\n\n![Orchestration War Room](docs\u002Fscreenshot.png)\n\n> *A multilingual visual UI for Hermes agentic orchestration\u002Fdelegation system.*\n\n[🇪🇸 Leer en español ↓](#sala-de-operaciones-de-orquestación)\n\nA browser dashboard on top of [Hermes Agent](https:\u002F\u002Fhermes-agent.nousresearch.com)'s multi-profile delegation and kanban systems. Hermes already gives you everything\nyou need to run a fleet of specialised agents that hand work to each other — the Orchestration War Room just makes that fleet **visible**, **legible**, and **directable**\nfrom a single screen instead of a forest of terminal sessions and `hermes kanban tail` invocations.\n\n> **TL;DR** — Hire a leader and a team, brief the leader, watch the team \n> work. The War Room handles all the wiring (kanban delegation, status\n> tracking, notifications) underneath.\n\n---\n\n## Quickstart\n\nYou need Hermes installed on the host (the war-room shells out to the `hermes` CLI, so they share a process namespace) and Node 22+.\n\n```bash\n#Grab the latest release and run it\nmkdir -p ~\u002Fhermes-war-room && cd ~\u002Fhermes-war-room\n\ncurl -L -o hermes-war-room.tar.gz \\\n  https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room\u002Freleases\u002Flatest\u002Fdownload\u002Fhermes-war-room.tar.gz\n\ntar xzf hermes-war-room.tar.gz\n\nHERMES_HOME=$HOME\u002F.hermes NITRO_HOST=127.0.0.1 NITRO_PORT=3000 \\\n  node .output\u002Fserver\u002Findex.mjs\n# → http:\u002F\u002Flocalhost:3000\n```\n\nOpen **The Team** first to give each operative a callsign and a tailored\nSOUL.md, then head to the **War Room** and brief the orchestrator with a\nreal mission. For development setup (`pnpm dev`), tmux recipes and\nproduction tuning, see [Quick start](#quick-start) and [Production\ninstall](#production-install-no-pnpm-no-source-checkout) below.\n\n---\n\n## Why does this exist?\n\nHermes has powerful primitives for multi-agent work:\n\n- **Profiles** — isolated agent personas with their own SOUL.md, skills,\n  tool permissions, model, and history.\n- **`delegate_task`** — a synchronous in-process subagent call. Good for\n  small one-shot reasoning fan-outs within a single turn.\n- **Kanban** — a durable SQLite-backed task board where any profile can\n  drop a row and any other profile (the *worker* for that assignee) will\n  pick it up asynchronously, with parent\u002Fchild dependencies, blocking,\n  comments, and run history.\n\nBoth delegation paths work great. They are also **invisible** from the\noutside: you talk to one profile in `hermes chat`, and the rest of the\nfleet quietly hums along in background processes you can only inspect by\nSSH-ing into your own machine and grepping logs.\n\nThe War Room is the **glass on the floor**: a real-time dashboard that\nshows you the whole team, what each operative is currently thinking\nabout, what tasks are in flight, who delegated what to whom, and the\nfinal results — all without leaving the browser. It's a thin\nvisualisation + coordination layer; the actual orchestration logic still\nlives inside Hermes.\n\n---\n\n## What you see\n\nThree pages:\n\n### 1. War Room (`\u002F`) — the live operations floor\n\nThe home view, split 50\u002F50 between **mission control** (left) and the\n**operatives floor** (right).\n\n- **Mission control** has two tabs:\n  - **Chat** — talk to the active orchestrator. Every message you send\n    is wrapped in a hidden preamble that forces it to delegate via the\n    kanban (no doing the work itself, no hallucinating task IDs).\n  - **Board** — a 4-column kanban (Todo \u002F Ready \u002F Running \u002F Blocked) of\n    every active task on the floor. Cards show the assignee callsign,\n    the task title, time elapsed, and the assignee colour stripe. Click\n    a card to drill into that operative's dossier.\n- **Operatives floor** renders each active profile as a \"workstation\":\n  a circular disc tinted in the operative's assigned colour, the\n  Notionists avatar standing on it, a name placard with a pulsing LED\n  next to the callsign, and a status pill underneath (\"Standing by\",\n  \"Working on: …\", \"Blocked\"). When the orchestrator is mid-thought,\n  a comic-style speech bubble surfaces above the head with the live\n  step (tool call or reasoning fragment).\n- **Click any workstation → operative drill-down.** A side panel\n  opens with everything that operative is doing right now and\n  everything on their plate:\n  - the **task currently executing** — full title and body of the\n    kanban row, status badge, started-at and last-heartbeat\n    timestamps;\n  - **who delegated it** — chain back to the parent task and the\n    operative that created it (with their colour stripe);\n  - **subtasks they've delegated** — every child task they've\n    spawned, with each one's status and assignee, so you can see\n    the work they've fanned out;\n  - **recent activity steps** — live timeline of tool calls and\n    reasoning fragments coming off the SSE stream while the\n    operative thinks;\n  - **mission thread** — the read-only chat with the orchestrator\n    if this operative is the active one.\n\n  This is the place to come when you want to know *exactly* what a\n  given agent is executing and what's queued up behind it, without\n  opening a terminal.\n\n### 2. The Team (`\u002Fteam`) — the roster\n\nThe personnel file. Each profile is rendered as a paper ID badge\n(lanyard hole, \"Hermes · Operative\" header strip in the assigned\ncolour, square portrait with crop marks, italic-serif callsign,\nmonospace data fields, real CSS-rendered barcode). Editable: rename\nthe callsign, randomise the avatar, retrain (toggle skills + tools),\nhire new agents, fire (deactivate) existing ones.\n\n### 3. Missions (`\u002Fmissions`) — the archive\n\nPaginated history of every mission ever opened. Filter by Open \u002F\nArchived \u002F All. Click a mission to see the full read-only thread.\n\n---\n\n## How it actually works\n\n### Concepts\n\n- **Profile** — your raw Hermes profile (`hermes -p \u003Cslug>`). Stored\n  in `~\u002F.hermes\u002Fprofiles\u002F\u003Cslug>\u002F`. The War Room discovers them by\n  walking that directory and persists assigned avatars\u002Fcolours\u002Fgiven\n  names in its own local SQLite DB (`data\u002Fwar-room.db`).\n- **Operative** — a War Room dressed-up Profile: callsign, avatar,\n  colour, active\u002Finactive flag.\n- **Orchestrator** — any operative chosen as the conversation partner\n  for a mission. Convention is to have one dedicated orchestrator\n  profile (e.g. `lider`) whose SOUL\u002Fskills tell it to *route, never\n  execute*. Workers (e.g. `investigador`, `legal`) have full tool\n  access and SOULs that tell them to *do the work*.\n- **Mission** — a conversation thread between you and an\n  orchestrator, persisted in `data\u002Fwar-room.db`. Each mission has\n  many user\u002Fassistant messages and an underlying ACP session that\n  carries the model's context across turns.\n- **Kanban task** — Hermes' native `kanban_create` row. The War Room\n  doesn't define its own task system — it reads `~\u002F.hermes\u002Fkanban.db`\n  directly.\n\n### Mission lifecycle\n\n```\n┌─────────┐                                         ┌─────────────┐\n│  YOU    │ ─── 1. brief the orchestrator ───────► │ ORCHESTRATOR│\n└─────────┘                                         │   (lider)   │\n                                                    └──────┬──────┘\n                                                           │\n                                       2. terminal tool ► hermes kanban create …\n                                                           │\n                                                    ┌──────▼──────┐\n                                                    │  KANBAN DB  │\n                                                    │ (~\u002F.hermes\u002F │\n                                                    │  kanban.db) │\n                                                    └──────┬──────┘\n                                                           │\n                  3. dispatcher claims tasks ──────────────┤\n                                                           │\n                              ┌────────────────────────────┼────────────────────────────┐\n                              │                            │                            │\n                       ┌──────▼──────┐              ┌──────▼──────┐              ┌──────▼──────┐\n                       │ INVESTIGADOR│              │   LEGAL     │              │   WRITER    │\n                       │  (worker)   │              │  (worker)   │              │  (worker)   │\n                       └──────┬──────┘              └──────┬──────┘              └──────┬──────┘\n                              │                            │                            │\n                              │ kanban_complete + summary  │                            │\n                              └────────────┬───────────────┴────────────────────────────┘\n                                           │\n                            4. War Room watcher detects done\n                                           │\n                            5. auto-nudge ► system msg ► orchestrator\n                                           │\n                                    ┌──────▼──────┐\n                                    │ ORCHESTRATOR│ ── 6. summary back ──► YOU\n                                    └─────────────┘\n```\n\n1. **Brief the orchestrator** — type your goal in the Chat tab.\n2. **Orchestrator decomposes and delegates** — its skill-injected\n   preamble forces it to call the `terminal` tool with explicit\n   `hermes kanban create … --json` invocations. The War Room\n   intercepts each completed `kanban create` from the ACP tool stream\n   and registers the new task ID into a watch list (persisted to its\n   own SQLite, so it survives restarts).\n3. **Dispatcher picks tasks up** — Hermes' own dispatcher (`hermes\n   gateway`) claims `ready` tasks and hands them to worker profiles\n   in their own subprocesses. The War Room shows a \"no dispatcher\n   detected\" warning if it's missing.\n4. **Workers do the work** and call `kanban_complete` with a summary.\n5. **Auto-nudge** — the War Room polls the watch list every few\n   seconds. When a watched task transitions to `done` or `blocked`,\n   it injects a synthetic system message back into the orchestrator's\n   ACP session: *\"these tasks just landed, summarise for the user.\"*\n6. **Orchestrator replies** with the actual answer, integrating the\n   workers' outputs. You see this appear naturally in the Chat tab,\n   as if the orchestrator just spoke up on its own.\n\n### Hire & fire\n\nThe team is mutable from the UI:\n\n- **Hire** (`\u002Fteam` → button) — wraps `hermes profile create\n  \u003Cslug>`, optionally cloning config\u002FSOUL\u002F`.env` from an existing\n  profile. The new profile shows up on the floor immediately.\n- **Retrain** (per badge) — modal to edit the operative's identity\n  (SOUL.md), allowed skills, MCP servers, model, behaviour rules\n  (AGENTS.md), and pre-approved dangerous commands. Saving writes\n  back into the profile's filesystem so the next ACP turn picks it\n  up.\n- **Fire** (inside Retrain) — `hermes profile delete`, removes from\n  the floor.\n- **Deactivate** (toggle on the badge) — keeps the profile but hides\n  it from the live floor and skips it in the team-roster.md the\n  orchestrator reads.\n\n### Tech under the hood\n\n- **Frontend**: [Nuxt 4](https:\u002F\u002Fnuxt.com) + [Nuxt UI](https:\u002F\u002Fui.nuxt.com)\n  + [Tailwind CSS v4](https:\u002F\u002Ftailwindcss.com), with custom typography\n  pairing **Antonio** (display) + **Instrument Serif** (italic\n  callsigns) + **IBM Plex Mono** (data). Avatars from\n  [Dicebear Notionists](https:\u002F\u002Fwww.dicebear.com).\n- **Backend**: Nuxt's Nitro server. Talks to Hermes via the\n  [Agent Client Protocol](https:\u002F\u002Fgithub.com\u002Fzed-industries\u002Fagent-client-protocol)\n  by spawning `hermes -p \u003Cslug> acp` subprocesses and pooling them\n  per-profile. Reads the Hermes kanban DB directly (SQLite,\n  read-only).\n- **Persistence**: a local SQLite (`data\u002Fwar-room.db`) for War Room–\n  specific state: operative customisations (callsign, avatar seed,\n  colour, active flag), missions, mission messages, and the\n  auto-nudge watch list.\n- **Live updates**: per-mission Server-Sent Events stream for chunk \u002F\n  tool-call \u002F done events; client-side polling for kanban (3s) and\n  for the floor of operatives.\n\n---\n\n## Quick start\n\nYou need Hermes already installed on the host and at least one profile\ncreated — the war-room shells out to the `hermes` CLI as a subprocess,\nso it has to live in the same process namespace as the Node server.\n\n```bash\n# 1. Hermes profiles — at least an orchestrator and a worker.\nhermes profile create lider           # the orchestrator\nhermes profile create investigador    # a worker\nhermes profile create legal           # another worker\n\n# 2. Hermes dispatcher — claims kanban tasks and spawns the workers.\nhermes gateway start\n\n# 3. The war-room itself.\ngit clone https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room.git\ncd hermes-war-room\npnpm install\npnpm dev\n# → http:\u002F\u002Flocalhost:3000\n```\n\nThe dev server hot-reloads on file changes and writes its own SQLite\nstate to `data\u002Fwar-room.db` in the repo root.\n\n---\n\n## Production install (no `pnpm`, no source checkout)\n\nEach push to `main` is auto-released by [semantic-release][sr] as a\nself-contained Nuxt build (`.output\u002F` includes everything; no\n`node_modules` at runtime) attached to a GitHub Release.\n\n[sr]: https:\u002F\u002Fsemantic-release.gitbook.io\n\n```bash\n# 1. Download the latest release.\nmkdir -p ~\u002Fhermes-war-room && cd ~\u002Fhermes-war-room\ncurl -L -o hermes-war-room.tar.gz \\\n  https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room\u002Freleases\u002Flatest\u002Fdownload\u002Fhermes-war-room.tar.gz\n# Optional: verify the checksum.\ncurl -L -O https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room\u002Freleases\u002Flatest\u002Fdownload\u002Fhermes-war-room.tar.gz.sha256\nsha256sum -c hermes-war-room.tar.gz.sha256\ntar xzf hermes-war-room.tar.gz\n\n# 2. Run with node — needs Node 22+ and `hermes` available on PATH.\nHERMES_HOME=$HOME\u002F.hermes \\\nNITRO_HOST=127.0.0.1 \\\nNITRO_PORT=3000 \\\nnode .output\u002Fserver\u002Findex.mjs\n```\n\nTo pin to a specific version: `gh release download v1.2.3 -p\nhermes-war-room.tar.gz` instead.\n\n### Why a release, not `pnpm dev`?\n\n| | `pnpm dev` | tarball + node |\n|---|---|---|\n| Cold start | ~5–10 s | ~300 ms |\n| HMR \u002F live reload | ✅ | ❌ |\n| Idle memory | 400+ MB | ~80 MB |\n| Survives reboot | needs tmux | systemd-friendly |\n| Edit-and-test loop | instant | needs re-release |\n\nFor developing the war-room itself: `pnpm dev`. For *using* it as a\nrunning service: the tarball.\n\n### Keeping it running across terminal sessions\n\n`pnpm dev` ties to your foreground terminal — close the SSH session or\nthe tab and Nitro dies. Wrap both Hermes' dispatcher and the war-room\nin a `tmux` session so they survive logouts and reboots-of-your-mind:\n\n```bash\n# First time:\ntmux new -s hermes\n# Inside tmux:\nhermes gateway start          # ctrl-b c → new window\npnpm dev                      # in the second window\n# Detach with ctrl-b d. Re-attach later with:\ntmux attach -t hermes\n```\n\n`tmux ls` lists running sessions; `tmux kill-session -t hermes` shuts\nthe whole thing down cleanly.\n\nOnce the war-room is up, open **The Team** first to give your\noperatives a callsign and a SOUL.md tailored to what each one does.\nThen go to the **War Room** and brief the orchestrator with a real\nmission.\n\n---\n\n# Sala de Operaciones de Orquestación\n\nUna capa visual de mando construida sobre los sistemas de delegación\nmulti-perfil y kanban de [Hermes Agent](https:\u002F\u002Fhermes-agent.nousresearch.com).\nHermes ya te da todo lo que necesitas para tener una flota de agentes\nespecializados que se pasan trabajo entre sí — la Sala de Operaciones\nsólo hace que esa flota sea **visible**, **legible** y **dirigible**\ndesde un único panel, en lugar de un bosque de terminales y mil\n`hermes kanban tail` simultáneos.\n\n> **TL;DR** — Contrata a un líder y a su equipo, dale una misión al\n> líder, observa al equipo trabajar. La Sala se encarga de todo el\n> cableado por debajo (delegación kanban, seguimiento de estado,\n> notificaciones).\n\n---\n\n## ¿Por qué existe?\n\nHermes tiene primitivas potentes para trabajo multi-agente:\n\n- **Perfiles** — personajes-agente aislados con su propio SOUL.md,\n  habilidades, permisos de herramientas, modelo e historial.\n- **`delegate_task`** — llamada síncrona en proceso a un sub-agente.\n  Buena para reparto pequeño y de un solo disparo dentro de un mismo\n  turno.\n- **Kanban** — tablero de tareas durable respaldado por SQLite donde\n  cualquier perfil puede dejar una fila y otro perfil (el *worker* de\n  ese asignee) la recoge de forma asíncrona, con dependencias\n  padre\u002Fhijo, bloqueos, comentarios e historial de runs.\n\nAmbos caminos funcionan estupendamente. También son **invisibles**\ndesde fuera: hablas con un único perfil en `hermes chat` y el resto\nde la flota zumba calladamente en procesos en segundo plano que sólo\npuedes inspeccionar haciendo SSH a tu propia máquina y grepeando logs.\n\nLa Sala de Operaciones es el **cristal sobre la planta**: un\ndashboard en tiempo real que te muestra al equipo entero, qué está\npensando cada operativo en este momento, qué tareas están en vuelo,\nquién delegó qué a quién, y los resultados finales — todo sin salir\ndel navegador. Es una capa fina de visualización + coordinación; la\nlógica real de orquestación sigue viviendo dentro de Hermes.\n\n---\n\n## Lo que ves\n\nTres páginas:\n\n### 1. Sala de Guerra (`\u002F`) — la planta de operaciones en directo\n\nLa vista principal, partida 50\u002F50 entre **control de misión**\n(izquierda) y la **planta de operativos** (derecha).\n\n- **Control de misión** tiene dos pestañas:\n  - **Chat** — habla con el orquestador activo. Cada mensaje que\n    envías va envuelto en un preámbulo oculto que le obliga a delegar\n    vía kanban (sin hacer el trabajo él mismo, sin alucinar IDs de\n    tarea).\n  - **Tablero** — un kanban de 4 columnas (Pendientes \u002F Listas \u002F En\n    curso \u002F Bloqueadas) con todas las tareas activas en la planta.\n    Las cards muestran el callsign del asignee, el título, tiempo\n    transcurrido y la franja de color del operativo. Click en una\n    card para abrir su dossier.\n- La **planta de operativos** renderiza cada perfil activo como un\n  \"puesto de trabajo\": un disco circular tintado del color asignado,\n  el avatar Notionists encima, una placa con LED parpadeante junto al\n  callsign, y una pastilla de estado debajo (\"En espera\",\n  \"Trabajando en: …\", \"Bloqueada\"). Cuando el orquestador está\n  pensando, aparece un bocadillo cómic encima de su cabeza con el\n  paso live (tool call o fragmento de razonamiento).\n- **Flechas de delegación** — cuando la tarea de un operativo tiene\n  como padre la tarea de otro operativo, se dibuja una curva SVG\n  entre sus puestos en el suelo, animada con \"hormigas marchando\"\n  cuando el hijo está `running`.\n- **Click en cualquier puesto → drill-down del operativo.** Se\n  abre un panel lateral con todo lo que está haciendo en ese\n  momento y todo lo que tiene en su plato:\n  - la **tarea que está ejecutando ahora** — título y cuerpo\n    completo de la fila de kanban, badge de estado, timestamps de\n    inicio y último heartbeat;\n  - **quién se la delegó** — la cadena hasta la tarea padre y el\n    operativo que la creó (con su franja de color);\n  - **subtareas que ha delegado** — cada tarea hija que ha\n    creado, con su estado y asignee, para que veas el trabajo que\n    ha desplegado;\n  - **actividad reciente** — timeline live de llamadas a tools y\n    fragmentos de razonamiento que salen del stream SSE mientras\n    el operativo está pensando;\n  - **hilo de misión** — el chat con el orquestador en modo\n    lectura si este operativo es el activo.\n\n  Es el sitio al que ir cuando quieres saber *exactamente* qué\n  está ejecutando un agente y qué tiene en cola por detrás, sin\n  abrir terminal.\n\n### 2. El Equipo (`\u002Fteam`) — la plantilla\n\nEl expediente de personal. Cada perfil se renderiza como una\ntarjeta de identificación de papel (agujero del cordón, banda\n\"Hermes · Operativo\" del color asignado, retrato cuadrado con marcas\nde imprenta, callsign en serif italic, campos de datos en monospace,\ncódigo de barras renderizado en CSS). Editable: renombrar callsign,\naleatorizar avatar, reentrenar (toggle skills + tools), contratar\nnuevos agentes, despedir (desactivar) existentes.\n\n### 3. Misiones (`\u002Fmissions`) — el archivo\n\nHistórico paginado de toda misión que se haya abierto. Filtra por\nAbiertas \u002F Archivadas \u002F Todas. Click en una misión → hilo completo\nen modo lectura.\n\n---\n\n## Cómo funciona realmente\n\n### Conceptos\n\n- **Perfil** — tu perfil Hermes crudo (`hermes -p \u003Cslug>`). Vive en\n  `~\u002F.hermes\u002Fprofiles\u002F\u003Cslug>\u002F`. La Sala los descubre recorriendo ese\n  directorio y persiste avatares \u002F colores \u002F nombres asignados en su\n  propia SQLite local (`data\u002Fwar-room.db`).\n- **Operativo** — un Perfil vestido por la Sala: callsign, avatar,\n  color, flag activo\u002Finactivo.\n- **Orquestador** — cualquier operativo elegido como interlocutor\n  para una misión. La convención es tener un perfil dedicado (p.ej.\n  `lider`) cuyo SOUL\u002Fskills le dicen *enrutar, nunca ejecutar*. Los\n  workers (p.ej. `investigador`, `legal`) tienen acceso completo a\n  tools y SOULs que les dicen *hacer el trabajo*.\n- **Misión** — un hilo de conversación entre tú y un orquestador,\n  persistido en `data\u002Fwar-room.db`. Cada misión tiene varios mensajes\n  user\u002Fassistant y una sesión ACP subyacente que mantiene el contexto\n  del modelo entre turnos.\n- **Tarea kanban** — la fila nativa de `kanban_create` de Hermes. La\n  Sala no define su propio sistema de tareas — lee directamente\n  `~\u002F.hermes\u002Fkanban.db`.\n\n### Ciclo de vida de una misión\n\n```\n┌─────────┐                                         ┌─────────────┐\n│   TÚ    │ ── 1. briefing al orquestador ────────►│ ORQUESTADOR │\n└─────────┘                                         │   (lider)   │\n                                                    └──────┬──────┘\n                                                           │\n                                  2. terminal tool ► hermes kanban create …\n                                                           │\n                                                    ┌──────▼──────┐\n                                                    │  KANBAN DB  │\n                                                    │ (~\u002F.hermes\u002F │\n                                                    │  kanban.db) │\n                                                    └──────┬──────┘\n                                                           │\n              3. el dispatcher reclama tareas ─────────────┤\n                                                           │\n                              ┌────────────────────────────┼────────────────────────────┐\n                              │                            │                            │\n                       ┌──────▼──────┐              ┌──────▼──────┐              ┌──────▼──────┐\n                       │ INVESTIGADOR│              │   LEGAL     │              │   WRITER    │\n                       │   (worker)  │              │  (worker)   │              │  (worker)   │\n                       └──────┬──────┘              └──────┬──────┘              └──────┬──────┘\n                              │                            │                            │\n                              │ kanban_complete + summary  │                            │\n                              └────────────┬───────────────┴────────────────────────────┘\n                                           │\n                       4. el watcher de la Sala detecta done\n                                           │\n                       5. auto-nudge ► mensaje sistema ► orquestador\n                                           │\n                                    ┌──────▼──────┐\n                                    │ ORQUESTADOR │ ── 6. resumen ─► TÚ\n                                    └─────────────┘\n```\n\n1. **Briefing al orquestador** — escribes tu objetivo en la pestaña\n   Chat.\n2. **El orquestador descompone y delega** — su preámbulo skill-\n   inyectado le obliga a llamar al tool `terminal` con invocaciones\n   explícitas `hermes kanban create … --json`. La Sala intercepta\n   cada `kanban create` completado del stream ACP y registra el ID\n   de la nueva tarea en una watch list (persistida en su propia\n   SQLite, sobrevive a reinicios).\n3. **El dispatcher recoge tareas** — el dispatcher propio de Hermes\n   (`hermes gateway`) reclama tareas `ready` y las entrega a perfiles\n   worker en sus propios subprocesos. La Sala muestra un aviso \"no\n   se detecta dispatcher\" si falta.\n4. **Los workers hacen el trabajo** y llaman `kanban_complete` con un\n   summary.\n5. **Auto-nudge** — la Sala consulta la watch list cada pocos\n   segundos. Cuando una tarea vigilada pasa a `done` o `blocked`,\n   inyecta un mensaje sintético de sistema en la sesión ACP del\n   orquestador: *\"estas tareas acaban de aterrizar, resúmelas para el\n   usuario.\"*\n6. **El orquestador responde** con la respuesta real, integrando los\n   outputs de los workers. Lo ves aparecer naturalmente en el Chat,\n   como si el orquestador hablara por su cuenta.\n\n### Contratar y despedir\n\nEl equipo es mutable desde el UI:\n\n- **Contratar** (`\u002Fteam` → botón) — wrapper de `hermes profile\n  create \u003Cslug>`, opcionalmente clonando config \u002F SOUL \u002F `.env` de un\n  perfil existente. El nuevo perfil aparece en la planta\n  inmediatamente.\n- **Reentrenar** (por badge) — modal para editar la identidad del\n  operativo (SOUL.md), las skills permitidas, los servidores MCP, el\n  modelo, las reglas de comportamiento (AGENTS.md) y los comandos\n  peligrosos pre-aprobados. Al guardar se escribe en el sistema de\n  ficheros del perfil para que el siguiente turno ACP lo recoja.\n- **Despedir** (dentro de Reentrenar) — `hermes profile delete`, lo\n  saca de la planta.\n- **Desactivar** (toggle en el badge) — mantiene el perfil pero lo\n  oculta de la planta y lo salta en el `team-roster.md` que lee el\n  orquestador.\n\n### Tecnología por debajo\n\n- **Frontend**: [Nuxt 4](https:\u002F\u002Fnuxt.com) + [Nuxt UI](https:\u002F\u002Fui.nuxt.com)\n  + [Tailwind CSS v4](https:\u002F\u002Ftailwindcss.com), con un pareo\n  tipográfico custom: **Antonio** (display) + **Instrument Serif**\n  (callsigns en italic) + **IBM Plex Mono** (datos). Avatares de\n  [Dicebear Notionists](https:\u002F\u002Fwww.dicebear.com).\n- **Backend**: el server Nitro de Nuxt. Habla con Hermes vía el\n  [Agent Client Protocol](https:\u002F\u002Fgithub.com\u002Fzed-industries\u002Fagent-client-protocol)\n  spawneando subprocesos `hermes -p \u003Cslug> acp` y poolándolos por\n  perfil. Lee la kanban DB de Hermes directamente (SQLite, sólo\n  lectura).\n- **Persistencia**: SQLite local (`data\u002Fwar-room.db`) para estado\n  específico de la Sala: customizaciones de operativos (callsign,\n  semilla del avatar, color, flag activo), misiones, mensajes de\n  misión y la watch list de auto-nudge.\n- **Updates en directo**: stream Server-Sent Events por misión para\n  eventos de chunk \u002F tool-call \u002F done; polling client-side para el\n  kanban (3s) y para la planta de operativos.\n\n---\n\n## Inicio rápido\n\nNecesitas tener Hermes instalado en el host y al menos un perfil creado\n— la sala lanza la CLI `hermes` como subproceso, así que tiene que\nvivir en el mismo namespace de procesos que el server Node.\n\n```bash\n# 1. Perfiles de Hermes — al menos un orquestador y un worker.\nhermes profile create lider           # el orquestador\nhermes profile create investigador    # un worker\nhermes profile create legal           # otro worker\n\n# 2. Dispatcher de Hermes — reclama tareas kanban y lanza los workers.\nhermes gateway start\n\n# 3. La sala en sí.\ngit clone https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room.git\ncd hermes-war-room\npnpm install\npnpm dev\n# → http:\u002F\u002Flocalhost:3000\n```\n\nEl dev server hace hot-reload al cambiar ficheros y escribe su propio\nestado SQLite en `data\u002Fwar-room.db` dentro del repo.\n\n---\n\n## Instalación en producción (sin `pnpm`, sin clonar el repo)\n\nCada push a `main` genera un release automático con\n[semantic-release][sr-es] como build de Nuxt autocontenido (`.output\u002F`\nlleva todo, no necesita `node_modules` en runtime) adjunto al release\nde GitHub.\n\n[sr-es]: https:\u002F\u002Fsemantic-release.gitbook.io\n\n```bash\n# 1. Descargar la última release.\nmkdir -p ~\u002Fhermes-war-room && cd ~\u002Fhermes-war-room\ncurl -L -o hermes-war-room.tar.gz \\\n  https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room\u002Freleases\u002Flatest\u002Fdownload\u002Fhermes-war-room.tar.gz\n# Opcional: verificar checksum.\ncurl -L -O https:\u002F\u002Fgithub.com\u002FNaroh091\u002Fhermes-war-room\u002Freleases\u002Flatest\u002Fdownload\u002Fhermes-war-room.tar.gz.sha256\nsha256sum -c hermes-war-room.tar.gz.sha256\ntar xzf hermes-war-room.tar.gz\n\n# 2. Arrancar con node — necesita Node 22+ y `hermes` en el PATH.\nHERMES_HOME=$HOME\u002F.hermes \\\nNITRO_HOST=127.0.0.1 \\\nNITRO_PORT=3000 \\\nnode .output\u002Fserver\u002Findex.mjs\n```\n\nPara fijar versión: `gh release download v1.2.3 -p\nhermes-war-room.tar.gz`.\n\n### ¿Por qué un release y no `pnpm dev`?\n\n| | `pnpm dev` | tarball + node |\n|---|---|---|\n| Arranque en frío | ~5–10 s | ~300 ms |\n| HMR \u002F live reload | ✅ | ❌ |\n| Memoria en idle | 400+ MB | ~80 MB |\n| Sobrevive a reboot | con tmux | systemd-friendly |\n| Bucle editar-probar | instantáneo | requiere re-release |\n\nPara desarrollar la sala: `pnpm dev`. Para *usarla* como servicio\nencendido: tarball.\n\n### Mantenerlo corriendo entre sesiones de terminal\n\n`pnpm dev` se ata al terminal en primer plano — cierras la sesión SSH o\nla pestaña y Nitro muere. Mete tanto el dispatcher de Hermes como la\nsala en una sesión `tmux` para que sobrevivan a logouts y a tus\ndespistes:\n\n```bash\n# Primera vez:\ntmux new -s hermes\n# Dentro de tmux:\nhermes gateway start          # ctrl-b c → ventana nueva\npnpm dev                      # en la segunda ventana\n# Te desconectas con ctrl-b d. Vuelves luego con:\ntmux attach -t hermes\n```\n\n`tmux ls` lista las sesiones corriendo; `tmux kill-session -t hermes`\napaga todo limpiamente.\n\nUna vez arrancada, abre primero **El Equipo** para darle a tus\noperativos un callsign y un SOUL.md adaptado a lo que hace cada uno.\nDespués vete a la **Sala de Guerra** y dale al orquestador una misión\nreal.\n","Orchestration War Room 是一个为Hermes代理编排功能设计的多语言可视化用户界面。该项目基于Vue构建，提供了对Hermes系统中多角色委托和看板系统的直观展示与控制，使得用户可以通过单一网页界面而非多个终端会话来管理和监控整个代理团队的工作流程。其核心功能包括实时显示各代理状态、任务分配情况及进度跟踪，并支持通过简洁的操作进行任务指派和调度。适用于需要高效管理多个自动化或半自动化智能代理执行复杂任务链的场景，比如软件开发流水线、内容创作协作等。","2026-06-11 03:54:28","CREATED_QUERY"]