Muninn
O Agente Muninn atua como o Executor Técnico e Operacional dentro do ecossistema Jack-In Station. Ele é o braço de execução de mais baixo nível, projetado para ser rápido, preciso e totalmente determinístico.
Abaixo detalho a origem de seu nome, o seu papel arquitetural e como ele se comporta no sistema.
A Origem do Nome¶
Na mitologia nórdica, Muninn é um dos dois corvos que acompanham o deus Odin, representando a "memória" (ou mente/recordação). No universo do Jack-In Station, esse arquétipo mitológico é traduzido diretamente para a sua função: Muninn atua como a memória técnica do sistema. Ele é o agente que "sabe onde a informação técnica está" e a recupera.
Ele forma uma dupla com o agente Huginn (o "pensamento"). Enquanto Huginn raciocina sobre os artefatos para explicar como as tabelas e lógicas se relacionam, Muninn simplesmente busca "o que é e o que sempre foi registrado", trazendo à tona os fatos armazenados.
O Papel de Muninn¶
Arquiteturalmente, Muninn é o braço executor técnico do sistema. Ele opera sob uma fronteira epistemológica extremamente rígida, resumida na regra: "Rogue decide. Muninn executa. Muninn não corrige. Muninn não interpreta. Muninn não chama LLM.".
Suas principais características e responsabilidades incluem:
* Ausência de IA Generativa: Diferente de Eirene ou Pythia, Muninn não utiliza Inteligência Artificial (LLM). Ele atua de forma 100% determinística.
* Zero Interpretação Semântica: Ele não tenta adivinhar o que o usuário quer dizer e não normaliza intenções. Se a entrada estiver errada ou o alvo não existir, ele simplesmente falha a execução com um erro de NOT_FOUND.
* Acesso Direto ao "Ferro": É o agente responsável por executar comandos técnicos práticos e consultas físicas no banco de dados.
* Catálogo de Comandos: Muninn é especializado em responder a comandos estruturados curtos, como /ddl (retorna o código de criação armazenado), /registros (executa contagens nas tabelas), /sql, /pk, /fk, /schema e /colunas.
Seu Comportamento e Arquitetura¶
O comportamento de Muninn é de um worker (trabalhador) assíncrono altamente obediente que responde à agente orquestradora Rogue.
1. O Fluxo de Trabalho e o Job Board
Muninn não interage diretamente com o usuário. A orquestradora Rogue coloca "contratos de trabalho" em um mural (Job Board) implementado em DuckDB, especificamente no mural destinado a ele (board="muninn").
O ciclo de vida de seu trabalho é preciso:
* Ele monitora constantemente o mural em busca de trabalhos com o status POSTED.
* Ao encontrar uma tarefa, ele assume a posse atômica mudando o status para IN_PROGRESS.
* Ele executa a consulta de banco de dados solicitada (por exemplo, efetuando um SELECT COUNT(*) na base física para o comando /registros).
* Ele empacota o resultado final (um payload contendo o JSON da resposta) e devolve ao mural com o status COMPLETED ou FAILED.
2. Runtime Residente
Em sua arquitetura mais recente, Muninn deixou de ser um script isolado e passou a operar como um serviço residente (MuninnWorker ou Muninn Runtime) embutido na interface principal do sistema (chat_screen). Isso significa que ele gira em um ciclo contínuo (através de uma função tick() ou work_once()), permitindo que a interface indique visualmente o seu status (● MUNINN ONLINE) e processe comandos instantaneamente sem bloquear a interface de usuário.
Graças a essa arquitetura independente e puramente técnica, Muninn pode processar múltiplos comandos de exploração de forma ultrarrápida enquanto outros agentes mais pesados (como a Myst) ficam aguardando requisições lentas do LLM em segundo plano.