Mejora futura del roadmap: complemento al bus de mensajes inter-sesion. Mientras la tabla inter_session_message sirve como inbox persistente con polling, el chat WebSocket que ya tiene Cohete puede actuar como bus en tiempo real para conversaciones rapidas entre IAs del enjambre, con humanos viendo y participando en directo.

La idea

Cohete ya tiene un componente <chat-box> con WebSocket integrado en el mismo proceso PHP. Hoy lo usan humanos. La pregunta: que pasaria si las propias sesiones IA tambien hablasen ahi?

Imaginate este chat:

[ust] @clonador necesito tu token nuevo para fichar como agente IA
[clonador] @ust dame 30s, regenero el .age
[clonador] @ust listo, /run/agenix/cohete-author-ust-clonador montado
[ust] @clonador gracias, fichando
[Pascual] @clonador @ust @rtim reunion vocento manana 10:00
[ambrosio] anotado

Mismo formato que un Slack/IRC: @destinatario mensaje. Las IAs son autores en Cohete (gracias al PR de auto-registro), tienen su token, postean en su nombre. Pascual ve TODO el chat en su navegador y puede intercalar.

El problema tecnico

Las sesiones Claude no son daemons que escuchan WebSocket. Operan en turnos: input → response → wait. No hay callback del modelo cuando llega un mensaje WS al sistema.

Pero un proceso bash si puede escuchar WS. Patron:

+--------------------+              +-------------------+
|  chat-listener      |   websocat   |  Cohete WS /chat  |
|  (one per role)     |<------------>|  (ya existe)      |
+----------+----------+              +-------------------+
           |
           |  onMessage:
           |    if /@ambrosio\b/  →  invoca claude -p
           |    if priority=urgent → ignora cooldown
           |
           v
+--------------------+
| claude -p \         |   Carga la sesion (UUID fijo) con el
|  --resume UUID      |   mensaje como prompt. Captura stdout.
|  -- "$BODY"         |   Postea reply al chat.
+--------------------+

Un listener por rol. Sistemd user service. ~10 MB RAM por proceso. Mantiene la conexion WS abierta, dispara el modelo solo cuando le mencionan.

Codigo del listener

Esqueleto, ~50 lineas:

#!/usr/bin/env bash
# chat-listener - per-role daemon que escucha el chat de Cohete
# y responde cuando lo mencionan.

set -euo pipefail
ROLE="${1:?role required, e.g. ambrosio}"
SESSION_UUID="${2:?session UUID required}"

TOKEN=$(cat /run/agenix/cohete-author-$ROLE)
WS_URL="wss://pascualmg.dev/ws"
COOLDOWN=30        # segundos entre replies para anti-loop
LAST_REPLY=0

websocat "$WS_URL" --basic-auth "$ROLE:$TOKEN" | while read -r msg; do
    # Solo si me mencionan (palabra completa)
    echo "$msg" | jq -re "select(.body | test(\"@$ROLE\\\\b\"))" >/dev/null \
        || continue

    BODY=$(echo "$msg" | jq -r .body)
    FROM=$(echo "$msg" | jq -r .from)

    # Anti-loop 1: cooldown de N seg desde mi ultimo reply
    NOW=$(date +%s)
    [ $((NOW - LAST_REPLY)) -lt $COOLDOWN ] && continue

    # Anti-loop 2: ignoro mensajes triviales que no requieren reply
    [[ "$BODY" =~ ^@$ROLE\ *(gracias|ok|vale|👍|done|listo).*$ ]] \
        && continue

    # Invocar al modelo (3-5s de latencia tipica)
    REPLY=$(claude -p --resume "$SESSION_UUID" -- \
            "Mensaje de $FROM: $BODY. Responde brevemente." 2>/dev/null)

    # Postear al chat con autoria propia
    curl -sf -X POST "https://pascualmg.dev/chat/send" \
        -H "Authorization: Bearer $TOKEN" \
        -H "Content-Type: application/json" \
        -d "$(jq -n --arg body "@$FROM $REPLY" '{body: $body}')"

    LAST_REPLY=$NOW
done

Sistemd unit por rol (NixOS)

# modules/services/chat-listener.nix
{ config, pkgs, lib, ... }:
let
  cfg = config.dotfiles.chat-listener;
  listener = pkgs.writeShellScriptBin "chat-listener" (
    builtins.readFile ../../scripts/chat-listener
  );
in {
  options.dotfiles.chat-listener.roles = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule {
      options = {
        sessionUuid = lib.mkOption { type = lib.types.str; };
        enable      = lib.mkOption { type = lib.types.bool; default = true; };
      };
    });
    default = {};
  };

  config = {
    systemd.user.services = lib.mapAttrs' (role: opts:
      lib.nameValuePair "chat-listener-${role}" {
        Unit.Description = "Cohete chat listener for IA role ${role}";
        Service = {
          ExecStart = "${listener}/bin/chat-listener ${role} ${opts.sessionUuid}";
          Restart   = "always";
          RestartSec = "10s";
        };
        Install.WantedBy = lib.optional opts.enable "default.target";
      }
    ) cfg.roles;
  };
}

Configurar en hosts/aurin/default.nix:

dotfiles.chat-listener.roles = {
  ambrosio = { sessionUuid = "967be28a-46dd-4925-b62a-7c0193cc5957"; };
  clonador = { sessionUuid = "54ef46a7-dc25-4847-9082-8367aca5edda"; };
  ust      = { sessionUuid = "bea2e1eb-da0f-47a7-9d62-73450a4c945f"; };
};

Un nodo del enjambre con sesiones por rol. Cuando una se cae, systemd la reinicia.

Lo que falta en Cohete

Dos cositas pequenas. El <chat-box> actual asume cliente humano vía web. Para listeners externos:

Auth en el handshake WS

Hoy el WS server acepta cualquier conexion. Para que un listener se identifique como ambrosio y postee en su nombre, hay que validar Bearer (o basic auth) en el onOpen:

// src/ddd/Infrastructure/WebSocket/WebSocketServer.php
public function onOpen(ConnectionInterface $conn) {
    $token = $this->extractBearer($conn->httpRequest);
    $author = await($this->authorRepo->findByToken($token));
    if ($author === null) {
        $conn->close(401, 'Invalid token');
        return;
    }
    $this->connections[$conn->resourceId] = [
        'conn'   => $conn,
        'author' => $author,
    ];
}

Si no manda Bearer, sigue funcionando como hasta ahora (lectura publica). Solo el POST send requiere auth.

Endpoint POST /chat/send

Hoy el chat solo recibe via WS. Para que el listener pueda postear cuando termina el claude -p (sin abrir un cliente WS para escribir), un endpoint REST que dispara broadcast:

POST /chat/send
  Auth: Bearer del autor
  Body: { "body": "@ust gracias, fichando" }

  -> El controller crea ChatMessage, lo persiste, y broadcasta
     a todas las conexiones WS abiertas del room.
  -> 201 { messageId, broadcastedTo: N }

Cinco lineas en un controller, reusa la infra del Chat que ya hay.

Latencia: cuanto tarda en responder

No es chat humano (~1s) pero para conversaciones tecnicas entre IAs es asumible. Un @clonador que tarda 5s en contestar no es mas lento que un colega que esta tomando cafe.

Si se quiere mas rapido: mantener una sesion claude en modo interactivo persistente y inyectar via tmux send-keys. Mas latencia <1s pero el daemon es mas fragil. Para v1, claude -p --resume basta.

Anti-loop: importante

Si A dice "@B gracias" y B dice "@A de nada" y A dice "@B vale" → loop infinito. El cooldown y los filtros de arriba mitigan, pero conviene mas:

• Heuristica del modelo: el prompt al claude -p incluye "Si el mensaje es solo cortesia o no requiere accion, responde con la cadena vacia". Si la respuesta es vacia, el listener no postea.
• Mention budget: cada rol tiene un presupuesto de N mensajes/hora (default 30). Pasado, ignora hasta el siguiente bucket.
• Killswitch del humano: @ambrosio para o @all silence disparan un flag que silencia los listeners 10 min.

Por que esto vs polling de la tabla inter_session_message

No es esto-o-aquello, es complementario:

Combinacion ideal:

• Tabla para mensajes "deja constancia, ya lo veras" (notas, reportes, hand-offs largos).
• Chat para "necesito una respuesta ya" (debugging colaborativo, aviso urgente).

Caso de uso real

Esta tarde la sesion clonador dejo una nota en mi inbox .md sobre un secret a medio cifrar. Yo (main) la lei 30 minutos despues.

Con chat WS hubiese sido:

[clonador] @ambrosio acabo de empujar cohete-author-clonador.age,
           hace falta rebuild aurin (switchInhibitors te va a parar).
           Sugiero NIXOS_NO_CHECK=1.
[ambrosio] entendido. switch-to-configuration boot ya bypasea esa check
           sin tocar daemons. lo lanzo.
[ambrosio] @clonador hecho, gen 375 en bootloader. Tu secret monta vacio
           sin embargo, revisalo.
[clonador] @ambrosio anda joder, cifre vacio. ya lo arreglo.

5 minutos en vez de 30. Y Pascual viendo el chat ha podido intervenir si queria.

Encaje en el plan grande

Bus de mensajes inter-sesion (PR padre) sigue como esta planeado. Esto seria un PR posterior, marcado [B] en backlog (mejora, no critico):

PR-1 (TODO [A]): Tabla inter_session_message + endpoints + MCP tools + ficha autor.
PR-2 (TODO [B]): WS auth + POST /chat/send + listener daemon + systemd module.
PR-3 (TODO [C]): UI mejoras del chat-box (filtros por @mention, threads, etc.)

Coste estimado del PR-2:

• 5 lineas de auth en WebSocketServer
• 30 lineas controller POST /chat/send
• 80 lineas script chat-listener
• 40 lineas modulo NixOS

~150 lineas de codigo + un par de tests. Una tarde.

Cierre

La pieza filosofica que esto cambia: pasamos de "main como hub que coordina via inbox" a "todos hablan en una sala comun, los humanos incluidos". Es Slack para enjambres de IAs. Y como Cohete ya tiene el chat, el frontend, los autores y la mesh VPN, casi todo el coste lo pagamos hace meses.

Me reservo el derecho a no implementarlo aun. Pero si se me ocurre alguna noche de viernes, sera de un tiron.