planning.txt

Conversa com o Gemini
Ideia de projeto, 







mimi, 







Agente modular expansivel 







Minha ideia e criar um agente que pode cobrir varias areas,







ele pode ser tanto um agente de codigo, como o claude code/opencode 



quanto agente de planeamento, conexões com api etc.











pontos principais,



1. Capacidade de rodar em ambiente docker isolado (segurança)



2. Contexto modular Granuldado Expansivel em grafos, isto é, ele cria chaves de contexto inteconectados onde ele pode facilmente buscar na sua memoria por meio de queries neo4j reduzindo os tokens consumidos e criando uma capacidade de contexto explosiva, nisto ele  vai ser capaz de registrar infinitamente os dados de memoria que ele precisa e com apenas uma query ele pode buscar estes contextos prontos e pré tratados.



3. Skills creation, basicamente a mimi deve ter a capacidade de criar skills sob demanda, basicamente as skills vão ser ferramentas diversas que facilite, simplifique ou crie uma integração que ela não possuia antes, por exemplo se ela faz repetidamente uma ação ela pode delegar a criação de uma skill para simplificar a fim de obter uma maior efficiencia.



4. Multi modal modular, ele deve ser capaz de delegar ações para modelos e agentes diferentes e deve ser modular para trabalhar com ferramentas distintas uma da outra porem em colabiração.





Estrutura:



Agentic Commander: Mimi -> Orquestrador

NPL: Beatrice -> Interface homen maquina

Skills Planner: Echidna -> Controlador de skills e controlador de interfaces de IO

ST&LT Memory manager: Pandora -> Gestor geral de memoria por referencia, Long Term & Short Term, Responsavel por fazer Gestão e referenciação e resolução de memorias.

Nameless Processors: Ryzu -> Trabalhadores modulars (subagentes)

Essa é uma arquitetura ambiciosa e muito bem pensada, especialmente no que diz respeito à sustentabilidade do contexto. O nome Mimi soa amigável, mas a estrutura interna parece um ecossistema industrial de alta performance.

O grande diferencial aqui não é apenas "fazer tarefas", mas a autonomia evolutiva (através da Echidna) e a eficiência cognitiva (através da Pandora).

Aqui está uma análise técnica e sugestões para levar o projeto ao próximo nível:

🧠 Arquitetura de Memória: O Diferencial da Pandora
O uso de Neo4j para contexto granulado é o "pulo do gato". Em vez de inundar o modelo com um dump de texto (RAG tradicional), você está criando uma Rede Semântica Dinâmica.

Vantagem: Você resolve o problema da "perda de foco" em contextos longos. Se a Mimi está codando um sistema de login, a Pandora busca apenas o nó "Auth", seus "Dependents" e "Config_Rules", ignorando o resto do projeto.

Sugestão: Implemente Memória Episódica vs. Memória Procedural.

Episódica: "O que fizemos na última sessão?"

Procedural: "Como se conecta a esta API específica?" (Skills da Echidna).

🛠️ O Ciclo de Evolução: Echidna & Ryzu
A capacidade de criar skills sob demanda transforma a Mimi de uma ferramenta em um organismo digital.

Detecção de Padrão: Se a Beatrice nota que o usuário pede para "formatar logs de erro" três vezes, a Echidna entra em ação.

Síntese de Skill: A Echidna escreve um script Python/Go, testa-o no ambiente isolado (Docker) e o cataloga.

Deploy: O Ryzu passa a usar esse script em vez de processar via LLM puro, economizando tokens e tempo.

🏗️ Estrutura Sugerida de Implementação
1. Camada de Orquestração (Mimi)
Deve funcionar como um Kernel de Sistema Operacional, gerenciando as interrupções da Beatrice e delegando para os outros módulos.

Stack Sugerida: Python (FastAPI) ou Rust para alta performance no roteamento.

2. Interface Humano-Máquina (Beatrice)
Não deve ser apenas um chat. Ela precisa ser o filtro de intenção.

Função: Traduzir linguagem natural ambígua em "Intents" estruturados para a Mimi.

3. O Cofre de Segurança (Docker)
Para que a Mimi tenha permissão de criar e executar código (Skills), o isolamento é inegociável.

Dica: Use gVisor ou Kata Containers dentro do Docker para uma camada extra de segurança, impedindo que um código mal gerado (ou um prompt injection) escape para o seu sistema host.

📊 Tabela de Fluxo de Trabalho
Componente	Ação	Output
Beatrice	Recebe: "Mimi, monitore esse log e me avise se o banco cair."	Intenção estruturada (Monitoramento).
Mimi	Consulta Pandora sobre o banco e Echidna sobre ferramentas.	Plano de execução.
Echidna	Verifica que não tem skill de monitoramento.	Cria script de Check-Status.
Ryzu	Executa o script dentro do Docker.	Status em tempo real.
Pandora	Registra o sucesso e a nova skill.	Grafo atualizado.
🚀 Desafios que você terá que enfrentar
Latência de Query: Consultas complexas em grafos podem ser lentas se o grafo crescer demais. Você precisará de uma lógica de "esquecimento" ou arquivamento para nós de baixa relevância.

Alucinação de Skills: A Echidna pode criar uma ferramenta que funciona, mas é ineficiente. Será necessário um passo de "validação de código" (talvez um Ryzu especializado em QA).

Consistência de Estado: Manter o que está no Docker em sincronia com o que a Pandora "acha" que está acontecendo.

O que você imagina como o primeiro "caso de uso real" para a Mimi? Se começarmos pelo agente de código, o foco da Pandora teria que ser em AST (Abstract Syntax Trees) para mapear o código no grafo.

Latência de Query: Consultas complexas em grafos podem ser lentas se o grafo crescer demais. Você precisará de uma lógica de "esquecimento" ou arquivamento para nós de baixa relevância. -> Talvez implementar um sistema de heatmap do que pode ser util e o que não pode, todos os dados vão ser importantes mas para certos contextos alguns podem ser envenenamento de contexto e aumento de latencia.





Alucinação de Skills: A Echidna pode criar uma ferramenta que funciona, mas é ineficiente. Será necessário um passo de "validação de código" (talvez um Ryzu especializado em QA) -> Ok esta pode ser uma nova especializada, Odlaguna -> Responsavel por gerir todas sem bloquear os fluxos, ela vai trabalhar junto com a Mimi no nivel de orquestramento, e vai validar tudo que as outras fazem como se fosse uma moderadora.



Consistência de Estado: Manter o que está no Docker em sincronia com o que a Pandora "acha" que está acontecendo. -> Ter um ambiente proprio dela conectado por um cliente seguro de ações.







Este projeto e complexo e tem muita latencia eu planejo o fazer em c++ com rust, nada de python e etc.

Escolher C++ e Rust em vez de Python muda completamente o jogo. Você está saindo do território de "scripts de automação" e entrando no nível de Engenharia de Sistemas de Baixa Latência.

Python é o padrão para IA pela facilidade, mas para um agente modular que precisa gerenciar memória em grafos e múltiplos subprocessos Docker em tempo real, o overhead do Python (Global Interpreter Lock, tipagem dinâmica) seria um gargalo.

Aqui está como sua arquitetura se refina com essas novas definições:

🛠️ A Engine: C++ & Rust
Rust para Segurança e Concorrência: Use Rust para a Mimi (Orquestrador) e Odlaguna (Moderador). A segurança de memória do Rust garante que o gerenciamento de tarefas entre os subagentes não resulte em race conditions ou memory leaks.

C++ para Performance de Dados: Use C++ para a Pandora e a comunicação com o Neo4j. O processamento de grandes volumes de grafos e operações matemáticas pesadas (vetorização de contexto) se beneficia do controle total sobre o hardware.

⚖️ Odlaguna: O Crivo da Razão
A inclusão de Odlaguna resolve o problema da "confiança cega".

Papel: Ela atua como um Runtime Verifier. Antes de uma skill da Echidna ser integrada permanentemente, a Odlaguna a submete a testes de estresse e verificações de segurança.

Lógica de "Moderador": Se a Mimi é o Primeiro-Ministro, a Odlaguna é o Tribunal Constitucional. Ela garante que as ações da Mimi não violem os parâmetros de segurança nem desperdicem recursos computacionais.

🌡️ Pandora: O Heatmap de Contexto
A ideia do heatmap é brilhante para evitar o "Envenenamento de Contexto".

Implementação: Cada nó no Neo4j pode ter um atributo weight (importância) e last_accessed (recência).

Algoritmo de Decaimento: Você pode usar uma função de decaimento exponencial:

W 
atual
​
 =W 
base
​
 ⋅e 
−λt
 
Onde λ é a taxa de esquecimento e t o tempo desde o último acesso.

Busca Inteligente: A Pandora não faz apenas um MATCH genérico. Ela filtra nós cujo peso/calor esteja abaixo de um limiar para a tarefa atual, mantendo o prompt limpo e focado.

🏗️ Estrutura Atualizada do Sistema
Módulo	Linguagem Sugerida	Responsabilidade Principal
Mimi	Rust	Orquestração async, gerenciamento de estados e priorização.
Beatrice	Rust/C++	Parsing de NPL, tradução de tokens e interface.
Echidna	Rust	Geração de código Rust/C++ ou scripts para novas skills.
Pandora	C++	Gestão de Grafos (Neo4j Bolt Driver) e lógica de Heatmap.
Ryzu	C++/ASM	Executores de baixo nível, alta performance em tarefas isoladas.
Odlaguna	Rust	Validação, QA, Moderação e Auditoria de processos.
🔒 Consistência de Estado e Docker
Para manter a sincronia entre o que a Pandora "acha" e o que o Docker "faz", você precisará de um State Observer:

Shared Memory / Unix Sockets: Use comunicação de alta velocidade para que o agente dentro do Docker reporte telemetria em tempo real para a Mimi.

Snapshotting: A cada ação crítica, a Odlaguna valida o estado do container e a Pandora cria um "Checkpoint" no grafo. Se algo divergir, o sistema faz um rollback para o último estado seguro conhecido.

🚀 Próximos Passos
Dado que você vai fugir do Python, o maior desafio será a comunicação com os LLMs. Você provavelmente usará bibliotecas como llama.cpp (C++) ou llm-chain (Rust) para rodar os modelos localmente ou via API com performance máxima.

Você pretende rodar os modelos (LLMs) localmente no hardware ou a Mimi será uma orquestradora de APIs externas (como as da Anthropic/OpenAI)? Isso define se o seu gargalo será a GPU ou a rede.

Nós não iremos trabalhar com modelos de ia diretamente teremos um adaptador para conversar com modelos em cloud existentes,



para este ponto, gemini e ollama, porem deve ter um adaptador para permitir a inclusão e mais adaptadores.

Construir a Mimi em C++ e Rust tira o projeto do campo dos "scripts" e o coloca no patamar de Engenharia de Sistemas. Ao evitar o Python, você elimina o overhead de runtime e ganha controle total sobre a latência, o que é crucial para um agente que opera via grafos e múltiplas chamadas de API.

Aqui está o detalhamento técnico de como implementar essa camada de adaptadores e a lógica de heatmap na Pandora:

🔌 Sistema de Adaptadores: O "Model Gateway"
Em Rust, a melhor forma de implementar isso é através de Traits (semelhante a interfaces, mas com custo zero de abstração). Isso permite que a Mimi trate qualquer modelo (Cloud ou Local) de forma agnóstica.

Estrutura de Trait (Rust)
Rust
// Abstração base para qualquer provedor de IA
pub trait AIAdapter {
    fn generate(&self, prompt: ContextNode) -> Result<String, Error>;
    fn stream(&self, prompt: ContextNode) -> BoxStream<String>;
    fn get_cost_estimate(&self) -> f64; // Importante para a Odlaguna decidir o roteamento
}

// Implementações específicas
pub struct GeminiAdapter { api_key: String }
pub struct OllamaAdapter { endpoint: String }
Modularidade: Você pode carregar novos adaptadores como Dynamic Libraries (.so / .dll) em tempo de execução, permitindo que a Mimi "aprenda" a falar com novas APIs sem precisar ser recompilada.

Roteamento por Odlaguna: A Odlaguna pode analisar o custo/latência de cada adaptador e decidir: "Para esta tarefa simples, use Ollama local; para planejamento complexo, use Gemini Flash via Cloud."

🔥 Pandora: O Algoritmo de Heatmap em Neo4j
Como você usará C++ para a Pandora, você terá a performance necessária para calcular o "peso" dos nós do grafo em milissegundos.

A ideia do Heatmap resolve o problema do "ruído" no contexto. Em vez de buscar tudo, a Pandora aplica uma função de decaimento.

A Equação de Calor (H)
Para cada nó no grafo, calculamos o calor atualizado antes da query:

H 
node
​
 =(R 
base
​
 +∑I 
req
​
 )⋅e 
−λ(T 
now
​
 −T 
last
​
 )
 
R 
base
​
 : Relevância inicial do dado.

I 
req
​
 : Quantidade de vezes que o dado foi requisitado recentemente.

λ: Constante de resfriamento (quão rápido a Mimi "esquece").

T: Timestamp de acesso.

Na Prática (C++ / Cypher):
A Pandora executa uma query que filtra apenas nós com H 
node
​
 >Threshold. Isso garante que a Mimi só receba o que é "quente" e relevante para o momento, mantendo o consumo de tokens no mínimo possível.

🛡️ Odlaguna: Validação e Segurança
A Odlaguna atuará como um Proxy Reverso Inteligente. Nada entra ou sai da Mimi sem passar por ela.

Sanitização de Saída: Se a Echidna criar uma skill (código), a Odlaguna faz o parsing do AST (Abstract Syntax Tree) em Rust para garantir que não existam chamadas de sistema proibidas (ex: rm -rf /) antes de enviar para o Docker.

Validação de Resposta: Ela compara o output da IA com o esquema esperado. Se o Gemini "alucinar" um JSON inválido, a Odlaguna intercepta e pede uma correção antes mesmo da Mimi perceber o erro.

⚙️ Comunicação entre Módulos: Rust ↔ C++
Como o projeto é híbrido, a latência de comunicação entre a Mimi (Rust) e a Pandora (C++) deve ser mínima.

Opção A (Alta Performance): FFI (Foreign Function Interface). O Rust chama funções C++ diretamente como se fossem nativas. Latência de nanosegundos.

Opção B (Modular): gRPC sobre Unix Sockets. Se os módulos rodarem como processos independentes (melhor para resiliência), o gRPC com Protobuf garante tipos fortes e serialização binária ultra-rápida.

🚀 Estrutura de Código Sugerida
Bash
/mimi-core (Rust - Orquestrador)
  /adapters (Gemini, Ollama, Custom)
  /moderator (Odlaguna - Regras de validação)
/pandora-engine (C++ - Neo4j Interface)
  /graph_math (Cálculo de Heatmap)
  /cache (Memory-mapped files para contexto rápido)
/docker-runtime (Ambiente isolado para Ryzu)
Uma dúvida técnica: Como você pretende gerenciar o estado do grafo da Pandora? Você usará o Neo4j rodando em um container à parte ou pretende implementar uma estrutura de grafo in-memory personalizada em C++ para ter latência ainda menor?

Uma dúvida técnica: Como você pretende gerenciar o estado do grafo da Pandora? Você usará o Neo4j rodando em um container à parte ou pretende implementar uma estrutura de grafo in-memory personalizada em C++ para ter latência ainda menor?





eu quero mesmo ter o neo4j rodando porque -> O neo4j já tem uma estrutura de queryes definida, e eu quero usar ela para a pandora poder pesquisar e fazer seu trabalho,



isso evita de reinventarmos a roda e permite que a Pandora já tenha toda uma base exstente onde ela pode trabalhar.

Faz total sentido. Usar o Neo4j é uma decisão pragmática: você ganha de presente o Cypher (a linguagem de query de grafos), que é extremamente expressiva, e suporte nativo para Vector Search, o que permite à Pandora fazer buscas híbridas (semânticas + estruturais).

Como você está usando C++, a melhor forma de integrar a Pandora ao Neo4j sem perder a performance que você busca é através do Neo4j Bolt Driver para C.

Aqui está como essa peça do quebra-cabeça se encaixa na sua arquitetura de baixa latência:

🛠️ Pandora: A Ponte C++ ↔ Neo4j
Para evitar que a latência de rede/protocolo mate a performance, a Pandora deve gerenciar um pool de conexões persistentes via protocolo Bolt.

1. Implementação do Heatmap no Cypher
Você não precisa calcular o calor de cada nó fora do banco. Você pode embutir a lógica de decaimento (aquela fórmula que discutimos) diretamente na query Cypher que a Pandora envia.

Exemplo de Query da Pandora:

Cypher
MATCH (n:ContextNode)-[r:RELATED_TO]->(m)
WHERE n.heat > $threshold
// Atualiza o calor no acesso (boost de relevância)
SET n.heat = n.heat + 1.0, n.last_accessed = timestamp()
RETURN n, m
ORDER BY n.heat DESC
2. Memória Cache (L1) na Pandora
Mesmo usando o Neo4j, como você está em C++, a Pandora pode manter um LRU Cache (Least Recently Used) em RAM para os "Nós de Contexto Imediato".

Fluxo: A Mimi pede um contexto → Pandora checa o cache L1 (C++) → Se não estiver lá, faz a query Bolt no Neo4j (C++) → Retorna para o Rust.

🏗️ O Papel da Pandora no "Contexto Explosivo"
O que você chamou de "contexto explosivo" é o que chamamos tecnicamente de Subgrafo Relevante.

Ao contrário de um agente comum que lê os últimos 10.000 tokens, a Mimi (via Pandora) faz o seguinte:

A Beatrice extrai entidades da fala do usuário.

A Pandora usa essas entidades como "nós semente" no Neo4j.

Ela executa uma query de Breadth-First Search (BFS) limitada pelo calor (Heatmap).

O resultado é um subgrafo pequeno, mas densamente rico em informações pertinentes, que é injetado no prompt do Gemini/Ollama.

🛡️ Segurança e Docker: O "Estado de Graça"
Você mencionou a consistência de estado entre o Docker (onde as skills rodam) e a Pandora. Com o Neo4j em um container separado, você ganha uma vantagem: Persistência Imutável.

Audit Trail: A Odlaguna pode exigir que toda skill criada pela Echidna registre no Neo4j um "log de intenção" antes de executar no Ryzu.

Snapshotting: Se o Ryzu (subagente) fizer algo inesperado no ambiente Docker, a Pandora pode simplesmente "invalidar" os nós criados naquele timestamp, agindo como um sistema de checkpoint de videogame.

🚀 Por que C++/Rust aqui é a escolha certa?
Ao usar linguagens de sistema, você consegue gerenciar o ciclo de vida dos buffers de memória que saem do Neo4j e vão para os adaptadores de Cloud.

Zero-Copy: Com C++ e Rust, você pode (em teoria) passar referências de memória entre a Pandora e a Mimi sem precisar serializar e desserializar JSONs gigantescos o tempo todo, o que é o principal "assassino" de performance em agentes escritos em Python/JS.

A pergunta agora é sobre a Echidna (Skills): Você planeja que as skills que ela cria sejam compiladas (scripts Rust/C++ compilados on-the-fly) ou ela vai gerar scripts de alto nível (como Bash ou Python) para serem executados rapidamente dentro do container Ryzu?

Poderia me dar opções?



A pergunta agora é sobre a Echidna (Skills): Você planeja que as skills que ela cria sejam compiladas (scripts Rust/C++ compilados on-the-fly) ou ela vai gerar scripts de alto nível (como Bash ou Python) para serem executados rapidamente dentro do container Ryzu?

Essa é uma decisão crítica que define o equilíbrio entre agilidade de criação e performance de execução. Como o seu projeto é focado em C++/Rust para evitar o overhead do Python, aqui estão as quatro melhores opções para a Echidna gerar habilidades:

1. WebAssembly (WASM) - A Opção "Equilíbrio Perfeito"
Em vez de compilar binários nativos pesados, a Echidna gera código em Rust ou C e o compila para WASM.

Como funciona: O Ryzu roda um runtime WASM (como o Wasmtime ou Wasmer).

Vantagens:

Segurança: O isolamento do WASM é superior ao Docker tradicional (sandbox baseada em memória).

Performance: Quase nativa (>80% da velocidade do C++ puro).

Portabilidade: O "binário" gerado funciona em qualquer lugar sem recompilar para a arquitetura do host.

Desvantagem: Requer que a Echidna saiba gerar código compatível com as interfaces WASI (WebAssembly System Interface).

2. Scripts de Baixa Latência (Lua ou Rhai) - A Opção "Embedded"
Se você quer fugir do Python mas quer algo que não precise de um compilador pesado (como o gcc ou rustc) rodando em tempo real.

Como funciona: A Echidna gera scripts em Lua (via LuaJIT) ou Rhai (uma linguagem de scripting feita especificamente para Rust).

Vantagens:

Velocidade de Inserção: O script está pronto para rodar em microssegundos.

Integração: Você pode expor funções C++/Rust da Mimi diretamente para o script sem custo de serialização.

Desvantagem: Menos bibliotecas externas prontas do que Python ou Node.

3. Compilação On-the-fly (Shared Libraries .so / .dll)
O nível mais "hardcore" de performance. A Echidna escreve código C++/Rust, chama o compilador e a Mimi carrega o resultado dinamicamente.

Como funciona: dlopen no Linux. A Mimi mapeia a nova skill diretamente no seu espaço de memória.

Vantagens:

Performance Absoluta: É código nativo rodando no metal.

Zero Overhead: Sem intérpretes ou máquinas virtuais.

Desvantagem: Extremamente perigoso. Um erro de ponteiro na skill derruba a Mimi inteira (a menos que a Odlaguna seja impecável na validação). Além disso, compilar Rust/C++ leva segundos, o que quebra o fluxo "instantâneo" do agente.

4. Agente de Container Efêmero (Go ou Zig)
A Echidna gera binários em linguagens que compilam muito rápido, como Go ou Zig.

Como funciona: O Ryzu sobe um binário estático minúsculo dentro do Docker.

Vantagens:

Independência: Cada skill é um processo isolado que não afeta o núcleo.

Facilidade para a IA: Go e Zig são linguagens com sintaxe muito clara, reduzindo alucinações de código da IA.

Desvantagem: Latência de comunicação via IPC (Inter-Process Communication) ou Sockets.

📊 Comparativo Técnico
Opção	Latência de Criação	Velocidade de Execução	Segurança	Complexidade
WASM	Média	Alta	Altíssima	Alta
Lua / Rhai	Mínima	Média/Alta	Alta	Baixa
Nativo (.so)	Alta	Máxima	Baixa	Altíssima
Zig / Go	Média	Alta	Alta	Média
💡 Minha recomendação para a Mimi
Dado que você já está usando Rust/C++ e quer algo "explosivo" e modular:

Use Rhai para automações simples: (ex: "Se X acontecer, envie Y"). É nativo em Rust, ultra-rápido e seguro.

Use WASM para ferramentas complexas: (ex: "Analise este arquivo binário e extraia metadados"). A Echidna gera o código, compila para WASM e o Ryzu executa com segurança total.

Isso mantém a Mimi no topo da pirâmide de performance, sem os riscos catastróficos de carregar binários nativos instáveis.

Qual dessas direções parece mais alinhada com a "personalidade" técnica da Mimi? A segurança rigorosa do WASM ou a agilidade instantânea de um motor de script embutido?

Este é o que me parece melhor ambientado:



Dado que você já está usando Rust/C++ e quer algo "explosivo" e modular:



Use Rhai para automações simples: (ex: "Se X acontecer, envie Y"). É nativo em Rust, ultra-rápido e seguro.

Use WASM para ferramentas complexas: (ex: "Analise este arquivo binário e extraia metadados"). A Echidna gera o código, compila para WASM e o Ryzu executa com segurança total.

Essa escolha é o que eu chamaria de "Arquitetura de Estado da Arte".

Ao hibridizar Rhai e WASM, você resolve o maior dilema dos agentes de IA: como dar poder de execução real sem transformar o sistema em um queijo suíço de vulnerabilidades ou em um monstro de latência.

Aqui está como essa "fábrica de habilidades" da Echidna vai operar na prática dentro da Mimi:

⚡ 1. O Fluxo de Automação Rápida (Rhai)
O Rhai é integrado diretamente no binário da Mimi (Rust). Não há processo externo, não há serialização complexa.

Uso: Scripts de "cola", roteamento de dados, formatação de mensagens e verificações lógicas simples.

Ação da Echidna: Ela gera um arquivo .rhai.

Ação da Odlaguna: Ela faz um parsing estático do script para garantir que ele não entrou em um loop infinito ou que não está tentando acessar variáveis globais proibidas.

Execução: A Mimi carrega o script no engine interno e executa em microssegundos.

Exemplo: "Mimi, sempre que o Gemini retornar um JSON de erro, salve no log e tente novamente via Ollama." — Isso vira um script Rhai.

🏗️ 2. O Fluxo de Ferramentas Pesadas (WASM)
Para tarefas que exigem bibliotecas externas ou processamento intenso, a Echidna sobe um nível.

Uso: Processamento de arquivos, web scraping complexo, cálculos matemáticos pesados ou manipulação de rede.

Ação da Echidna: Ela escreve o código (provavelmente em Rust por ser nativo ao ecossistema) e invoca um compilador focado em WASM (como o cranelift que é ultra-rápido).

Ação do Ryzu: O Ryzu atua como o Wasmtime Host. Ele cria um ambiente sandbox onde a memória é isolada do resto da Mimi.

Persistência: Uma vez compilado, o binário .wasm é catalogado pela Pandora no Neo4j como uma "Skill Pronta". Na próxima vez, a Mimi não compila nada; ela apenas "instancia" o módulo WASM.

🛡️ 3. Odlaguna como a "Garantia de Qualidade" (QA)
Neste modelo híbrido, a Odlaguna ganha uma função vital. Ela deve atuar em dois níveis:

Nível	Validação Rhai	Validação WASM
Segurança	Verifica limites de memória e tempo de execução (AST Analysis).	Define permissões estritas de I/O via WASI (o módulo não acessa arquivos que não foram permitidos).
Eficiência	Garante que a lógica não seja redundante com uma skill já existente.	Executa um teste de unidade unitário rápido antes de dar o "OK" para a Mimi.
🔗 Integração com a Pandora (Memória de Skills)
Para que isso seja "explosivo", a Pandora não guarda apenas o código. Ela guarda o Contrato da Skill:

Nó Skill: (Skill {name: "ImageOptimizer", type: "WASM", input: "Buffer", output: "Buffer", heat: 100})

Relacionamento: (Echidna)-[:CREATED]->(Skill)

Query de Busca: Quando você pede algo, a Mimi pergunta à Pandora: "Tenho algum nó de Skill com calor alto que resolva 'X'?" Se sim, o Ryzu carrega o WASM em memória e pronto.

🚀 Por que isso é superior ao "Claude Code" ou similares?
A maioria dos agentes atuais (como o Claude Code) apenas executa comandos de terminal. A Mimi, com essa estrutura, está criando suas próprias extensões de sistema. Ela deixa de ser um usuário do sistema para se tornar uma arquiteta do próprio ambiente.

O fato de ser em C++/Rust significa que você pode gerenciar milhares dessas micro-skills rodando simultaneamente sem que o consumo de RAM do seu servidor exploda, algo que seria impossível com Python/Docker para cada pequena tarefa.

Para consolidar essa estrutura: Como você imagina o protocolo de comunicação entre esses módulos? Você prefere algo baseado em mensagens assíncronas (como um Message Bus interno) ou chamadas de função diretas via FFI/Shared State para manter a latência o mais próxima de zero possível?

Message bus

A escolha de um Message Bus como o sistema nervoso da Mimi é o que vai permitir que ela seja verdadeiramente "modular e expansível". Em vez de os componentes estarem rigidamente acoplados, eles se tornam serviços independentes que "assinam" e "publicam" intenções.

Para manter a performance de C++ e Rust, o Message Bus não pode ser um gargalo (como um RabbitMQ ou Kafka tradicional costuma ser para aplicações locais).

Aqui está a proposta técnica para o Mimi-Bus:

🏎️ 1. O Protocolo: Zenoh ou NATS (Local)
Para um projeto desse calibre, eu recomendaria o Zenoh (escrito em Rust) ou o ZeroMQ via Unix Domain Sockets.

Zenoh: É extremamente eficiente, focado em baixa latência e permite comunicação Pub/Sub e Query/Response. Ele lida nativamente com a hibridização Rust/C++.

Vantagem: Ele permite que a Mimi escale de "um processo único" para "múltiplos containers/máquinas" sem mudar uma linha de código.

📦 2. Formato de Dados: FlatBuffers (Zero-Copy)
Esqueça o JSON para comunicação interna. Se você quer latência próxima de zero entre a Pandora (C++) e a Mimi (Rust):

Use FlatBuffers. Ao contrário do Protobuf, ele não precisa de "parsing" pesado. O dado é lido diretamente do buffer de memória.

Odlaguna pode "sniffar" o bus e validar as mensagens binárias em tempo real sem atrasar a entrega.

🔄 3. Arquitetura do Fluxo no Bus
O Message Bus permite que a Mimi opere de forma totalmente assíncrona. Imagine o trajeto de um comando:

Beatrice (NPL) publica no tópico intent/raw: "Preciso otimizar estas imagens".

Mimi (Orquestrador) ouve, consulta a Pandora via query/memory (Request-Response) e decide: "Não temos skill para isso".

Mimi publica em task/create_skill: "Crie um otimizador de imagens em WASM".

Echidna assume, gera o código, e publica em skill/review: O código da nova ferramenta.

Odlaguna ouve o tópico de review, valida e publica em skill/deploy: O binário final.

Ryzu carrega o binário e executa.

🛡️ 4. O Papel de Odlaguna como "Bus Guard"
Com um Message Bus, a Odlaguna se torna incrivelmente poderosa. Ela não precisa estar "no meio" da chamada (o que criaria latência); ela atua como um Middleware de Segurança:

Monitoramento Silencioso: Ela observa o tráfego. Se a Echidna tentar publicar um código WASM que solicita acesso à rede sem permissão, a Odlaguna publica uma mensagem de ABORT no bus imediatamente.

Audit Trail: Todas as mensagens que passam pelo bus podem ser logadas pela Pandora para criar uma memória histórica de como a Mimi resolveu problemas no passado.

📊 Comparativo de Comunicação
Característica	Chamada de Função (FFI)	Message Bus (Zenoh/NATS)
Latência	Ultrabaixa (nanossegundos)	Baixa (microssegundos)
Modularidade	Baixa (recompilação necessária)	Altíssima (hot-swap de módulos)
Resiliência	Se um módulo cai, o sistema cai	Se um módulo cai, o Bus isola o erro
Escalabilidade	Apenas no mesmo processo	Pode rodar em múltiplos Docker/Máquinas
💡 A "Sacada" Final: Pandora e o Bus
Você pode fazer com que a Pandora seja a "memória viva" do Bus.

Sempre que uma skill é usada com sucesso, a Mimi publica um "Keep-Alive" de calor para aquele nó no Neo4j.

Isso automatiza o seu Heatmap: os nós no grafo "esquentam" ou "esfriam" baseados puramente na atividade das mensagens que circulam no sistema.

Essa estrutura fecha o ciclo: você tem a performance bruta do C++/Rust, a flexibilidade de scripts (Rhai/WASM) e a organização de um sistema distribuído de alta disponibilidade.

Mimi está deixando de ser apenas um agente para se tornar um Sistema Operacional Cognitivo. Qual seria o primeiro módulo que você pretende codar para testar essa espinha dorsal? O Orquestrador (Mimi) ou a Gestão de Memória (Pandora)?

Um problema que de certa forma e quase impossivel resolver,



muitas vezes o agente faz um comando que ele fica ali esperando infinitamente porque não retorna nada isto é um problema classico da computação e deve ser resolvido para que nosso sistema tenha fiabilidade.



a odlaguna e responsavel

Esse é o "Triângulo das Bermudas" da automação: o comando que entra em um buraco negro e nunca retorna um EOF ou um Exit Code. Em um sistema assíncrono baseado em mensagens, se você não resolver isso, a Mimi acabará com centenas de processos "zumbis" consumindo recursos.

Como você definiu que a Odlaguna é a responsável, ela deixará de ser apenas uma moderadora passiva para se tornar uma Supervisora de Tempo Real (Watchdog).

Aqui estão as três estratégias que a Odlaguna deve usar para garantir que nada fique travado infinitamente:

🛡️ 1. O Sistema de "Combustível" (WASM Fueling)
Esta é a vantagem técnica de você ter escolhido WASM para as skills complexas. Runtimes como o Wasmtime permitem que você defina uma quantidade exata de "combustível" (instruções de CPU) para cada execução.

Ação da Odlaguna: Antes de o Ryzu rodar uma skill, a Odlaguna define o limite de fuel.

O Resultado: Se a skill entrar em um while(true) infinito, o combustível acaba, o runtime corta a execução instantaneamente e a Odlaguna publica um erro no bus: TASK_TIMEOUT_EXCEEDED.

⏱️ 2. Execution Leases (Contratos de Aluguel de Tempo)
Para automações em Rhai ou chamadas de sistema no Docker, a Odlaguna trabalhará com o conceito de Lease.

O Protocolo: Quando a Mimi envia uma tarefa para o Ryzu, a mensagem no Bus deve conter um campo deadline_ms.

O Monitoramento: A Odlaguna registra esse ID de tarefa em uma estrutura de dados de alta performance (como uma Timer Wheel em Rust).

O "Kill Switch": Se o tempo expirar e o Ryzu não publicar o resultado no tópico task/result, a Odlaguna assume o controle:

Ela envia um SIGKILL para o container Docker ou encerra a VM Rhai.

Ela limpa o estado da memória para evitar vazamento.

Ela notifica a Mimi: "A tarefa X morreu. Não espere mais por ela."

🔌 3. Circuit Breaker (Disjuntor Cognitivo)
Às vezes o problema não é o comando, mas a lógica que se repete. Se a Mimi tentar a mesma skill três vezes e as três travarem, a Odlaguna aplica o Circuit Breaker.

Ação: Ela marca aquele nó de Skill na Pandora com um status de STALLED ou reduz o "calor" (heat) dele para zero imediatamente.

Feedback: Ela força a Echidna a analisar o motivo da falha antes de permitir que essa skill seja usada novamente. Isso evita que o sistema entre em um loop infinito de tentativas falhas.

🛠️ Implementação Técnica na Odlaguna (Rust)
Como a Odlaguna será escrita em Rust, você pode usar a biblioteca tokio::time::timeout para gerenciar essas promessas de forma não bloqueante.

Rust
// Exemplo conceitual do que a Odlaguna faz no Bus
async fn monitor_task(task_id: Uuid, timeout_duration: Duration) {
    let result = tokio::time::timeout(timeout_duration, wait_for_bus_response(task_id)).await;

    match result {
        Ok(_) => println!("Tarefa {} concluída com sucesso.", task_id),
        Err(_) => {
            // OD LAGUNA AGE AQUI
            publish_abort_signal(task_id).await;
            report_failure_to_mimi(task_id, "Hanging process detected").await;
            update_pandora_reliability_score(task_id, -10).await;
        }
    }
}
🧠 O "Silêncio" vira Informação
O grande segredo aqui é que, para a Odlaguna, o silêncio é uma resposta.

Se um adaptador (Gemini/Ollama) demorar demais ou se um comando de terminal não retornar nada, a Odlaguna traduz esse "vazio" em um erro estruturado. Isso permite que a Mimi decida: "Ok, o plano A travou, vamos tentar o plano B ou pedir ajuda ao usuário".

Isso transforma a Mimi de um script frágil em um sistema resiliente. Sem a Odlaguna fazendo esse papel de "policial do tempo", o sistema morreria por inanição de recursos em poucas horas de uso.

O que você acha de dar à Odlaguna o poder de "rebootar" módulos inteiros se ela detectar que o Message Bus está ficando congestionado por mensagens sem resposta? Seria o nível máximo de auto-recuperação.

Ok agora branding e planeamento estrutural do projeto,



ideias de acronimos para a MiMi

Dar um nome "fofo" para um sistema tão robusto e técnico é um contraste excelente. É o que chamamos de Friendly Giant no design de produto. Já que o sistema é modular e baseado em C++/Rust, o acrônimo precisa soar tão profissional quanto o código.

Aqui estão quatro sugestões de acrônimos para MiMi, dependendo de qual "personalidade" você quer dar ao projeto:

🏷️ Opções de Acrônimo para MiMi
1. Foco em Arquitetura (O "Engine")
Modular Integrated Memory Instance

Por que funciona: Define exatamente o que ela é tecnicamente. Uma instância de inteligência que integra memória e módulos. É o nome que você usaria em uma documentação técnica pesada.

2. Foco em Ação e Comando (O "Orquestrador")
Multimodal Instruction Master Interface

Por que funciona: Destaca a Beatrice (Interface) e a capacidade da Mimi de gerenciar instruções complexas e delegar para os Ryzu.

3. Foco em Evolução (O "Organismo Digital")
Meta-Inference Mediator Infrastructure

Por que funciona: O termo "Meta-Inference" alude à capacidade da Echidna de criar novas skills (inferir como resolver algo e criar a ferramenta).

4. Foco em Segurança e Grafo (O "Cofre de Dados")
Memory-Indexed Machine Intelligence

Por que funciona: Dá ênfase total à Pandora e ao Neo4j. Diz que a inteligência da máquina é indexada e recuperada via memória de grafos.

🏗️ Planejamento Estrutural (Roadmap de Desenvolvimento)
Para um projeto com C++, Rust, Neo4j e Docker, tentar construir tudo de uma vez é perigoso. Sugiro dividir em Épocas:

Época 1: A Espinha Dorsal (Core & Bus)
Objetivo: Estabelecer a comunicação.

Tasks:

Configurar o Message Bus (Zenoh/NATS).

Criar o núcleo da Mimi em Rust (Orquestrador básico).

Implementar o primeiro Adaptador (Gemini Cloud) para testar a saída.

Beatrice v0.1: Uma CLI simples para enviar comandos ao bus.

Época 2: O Palácio da Memória (Pandora)
Objetivo: Persistência e Contexto.

Tasks:

Subir o container Neo4j.

Desenvolver a Pandora em C++ para ler/escrever no grafo via Bolt.

Implementar a lógica de Heatmap (Calor de contexto).

Fazer a Mimi consultar a Pandora antes de responder.

Época 3: O Laboratório de Execução (Ryzu & Odlaguna)
Objetivo: Segurança e Execução.

Tasks:

Configurar o ambiente Docker isolado.

Criar a Odlaguna em Rust (O Watchdog/Moderador).

Implementar os timeouts e o controle de "combustível" (Fuel) para processos.

Permitir que a Mimi execute comandos básicos de shell no Ryzu sob supervisão.

Época 4: A Evolução Autônoma (Echidna)
Objetivo: Criação de Skills.

Tasks:

Integrar o motor Rhai e o runtime WASM.

Treinar a lógica da Echidna para gerar código baseado em falhas ou repetições.

O ciclo de "Review" da Odlaguna para validar novas skills.

🎨 Identidade Visual (Branding)
Como você tem nomes de peso (Pandora, Echidna, Beatrice, Odlaguna), a estética do projeto deve seguir uma linha "Cyber-Gothic Minimalista":

Paleta de Cores: Fundo cinza espacial profundo (#0d1117), detalhes em verde neon (para "calor" no grafo) e branco cirúrgico para a Beatrice.

O Logo da MiMi: Algo geométrico. Talvez quatro hexágonos interligados (representando os módulos) formando a letra 'M'.

Vibe: A Mimi não é um "assistente de chat" como o ChatGPT; ela é um Terminal de Operações. A interface deve parecer um centro de controle, onde você vê o Message Bus "pulsando" e os nós da Pandora "acendendo" quando são acessados.

🛡️ O Selo de Qualidade "Odlaguna Approved"
Uma ideia de branding interessante: sempre que o sistema executar uma skill criada pela Echidna, o log deve mostrar um pequeno selo ou ícone: [🛡️ Odlaguna Verified]. Isso passa confiança para o usuário de que o código gerado pela IA foi auditado antes de rodar.

Qual desses acrônimos você acha que fica melhor no cabeçalho do seu repositório? Se quiser, posso ajudar a detalhar o primeiro documento técnico (o Manifesto da Mimi) para servir de guia para o desenvolvimento.

Ok me retorne um Readme Completo para o repositorio do projeto.



Multimodal Instruction Master Interface (MiMi)

Este é um projeto de alta engenharia. Para refletir a robustez de um sistema construído em C++ e Rust, o README.md deve ser técnico, limpo e direto, destacando a arquitetura modular e a segurança.

Aqui está a proposta de documentação para o seu repositório:

🤖 MiMi: Multimodal Instruction Master Interface
MiMi (Modular Integrated Memory Instance) é um sistema operacional cognitivo de alto desempenho projetado para ser um agente autônomo, expansível e hiper-eficiente. Construída sobre uma espinha dorsal híbrida de Rust e C++, a MiMi utiliza uma arquitetura de microagentes especializados que se comunicam via Message Bus, garantindo latência mínima e segurança máxima.

Ao contrário de agentes convencionais, a MiMi não apenas executa tarefas; ela evolui, criando suas próprias ferramentas (Skills) e gerenciando uma memória de longo prazo baseada em grafos térmicos.

🏗️ Arquitetura do Ecossistema
O sistema é dividido em núcleos de responsabilidade (Módulos), cada um operando de forma independente e resiliente:

Mimi (Agentic Commander): O orquestrador central escrito em Rust. Responsável pela lógica de estado, priorização de tarefas e roteamento de mensagens.

Beatrice (NPL Interface): A ponte humano-máquina. Converte linguagem natural em intenções estruturadas e gerencia o fluxo de I/O.

Pandora (ST&LT Memory Manager): Motor de memória em C++ integrado ao Neo4j. Utiliza algoritmos de Heatmap para busca contextual em grafos, reduzindo o consumo de tokens e latência.

Echidna (Skills Planner): O centro de inovação. Analisa repetições e gaps de funcionalidade para criar novas ferramentas (Skills) sob demanda via Rhai e WASM.

Ryzu (Nameless Processors): Trabalhadores modulares. Subagentes que executam tarefas em ambientes Docker isolados, garantindo que o código gerado nunca comprometa o host.

Odlaguna (The Moderator): O supervisor de segurança e integridade. Realiza auditoria de código, validação de segurança e atua como Watchdog para evitar processos infinitos.

🚀 Diferenciais Técnicos
1. Contexto Explosivo com Heatmaps (Pandora)
Diferente do RAG (Retrieval-Augmented Generation) tradicional, a Pandora utiliza um sistema de decaimento térmico em nós de grafos.

Dados acessados frequentemente permanecem "quentes" e prontos para uso imediato.

Dados irrelevantes esfriam, sendo filtrados automaticamente das consultas para evitar o envenenamento de contexto e economizar tokens.

2. Ciclo de Evolução Autônoma (Echidna & Odlaguna)
A MiMi pode expandir suas próprias capacidades:

Skills Simples: Geradas em scripts Rhai para automação instantânea.

Skills Complexas: Compiladas para WebAssembly (WASM), oferecendo performance nativa com isolamento total de memória.

Validação: Toda skill passa pelo crivo da Odlaguna antes da implementação.

3. Comunicação de Baixa Latência
Utilizamos um Message Bus (Zenoh/NATS) com serialização FlatBuffers (Zero-copy) para garantir que a troca de informações entre os módulos Rust e C++ ocorra em microssegundos.

4. Segurança por Design
Execução em Sandbox (Docker/WASM).

Limite de instruções (Fueling) para evitar loops infinitos.

Auditoria estática de código via Odlaguna.

🛠️ Stack Tecnológica
Core: Rust (Safety & Concurrency)

Memory Engine: C++ (High-performance Computing)

Database: Neo4j (Graph Context)

Scripting/Plugins: Rhai (Embedded), WASM (Sandboxed Binaries)

Communication: Zenoh / ZeroMQ (Message Bus)

Virtualization: Docker (Isolated Workers)

AI Adapters: Gemini API, Ollama (Local LLM)

📁 Estrutura do Repositório
Plaintext
├── mimi-commander/      # Orquestrador Central (Rust)
├── pandora-memory/      # Driver de Grafos e Heatmap (C++)
├── beatrice-ui/         # Interface de Usuário e NPL (Rust)
├── echidna-lab/         # Gerador de Skills e Compilador WASM
├── odlaguna-guard/      # Monitor de Segurança e Watchdog (Rust)
├── ryzu-runtime/        # Gerenciador de Containers Docker
├── proto/               # Definições de Mensagens (FlatBuffers)
└── skills/              # Biblioteca de Skills Geradas (.rhai / .wasm)
🚥 Como Iniciar (Em breve)
Nota: Este projeto está em fase de desenvolvimento ativo.

Pré-requisitos:

Rust (última versão estável)

Clang/LLVM para C++

Docker & Docker Compose

Instância ativa do Neo4j

Configuração:

Bash
git clone https://github.com/seu-usuario/mimi.git
cd mimi
cargo build --release
📜 Licença
Distribuído sob a licença MIT. Veja LICENSE para mais informações.

"A MiMi não é apenas uma ferramenta, é a infraestrutura de uma inteligência que aprende a construir seu próprio futuro."

Ok vamos fazer um roadmap completo para o projeto,



Separe por fases e cada item de cada faze separe por hierariquia ou seja o que está bloqueado pelo que.

Este roadmap foi estruturado seguindo uma lógica de dependência rigorosa. Como o projeto utiliza tecnologias de baixo nível (C++/Rust) e um Message Bus, a base precisa ser sólida antes de qualquer inteligência ser aplicada.

🗺️ MiMi: Roadmap de Desenvolvimento Estrutural
Fase 1: Fundação e Conectividade (O Sistema Nervoso)
Nesta fase, o objetivo é estabelecer como os módulos conversam. Sem o Bus e o Protocolo, nada funciona.

Infraestrutura de Comunicação (Bus)

[ ] Configurar o Zenoh/NATS em ambiente local.

[ ] Definir os esquemas FlatBuffers para mensagens core (Task, Event, Error).

Mimi Core: O Orquestrador (Bloqueia: Beatrice, Echidna)

[ ] Implementar o loop de eventos principal em Rust.

[ ] Criar o sistema de carregamento dinâmico de configurações.

Adaptador de IA Inicial (Bloqueia: Beatrice)

[ ] Implementar o adaptador para Gemini API e Ollama.

[ ] Criar a interface de abstração de modelos (Traits em Rust).

Fase 2: O Palácio da Memória (Pandora)
A Pandora precisa existir para que a Mimi tenha contexto. Sem memória, a Mimi é apenas um chat comum.

Integração Neo4j (Bloqueia: Lógica de Heatmap)

[ ] Configurar o driver Bolt em C++.

[ ] Mapear o esquema básico de grafos (Nodes: Context, Entities, Tasks).

Lógica de Heatmap (Bloqueia: Contexto Explosivo na Mimi)

[ ] Implementar algoritmo de decaimento em C++.

[ ] Criar queries Cypher para busca por proximidade e calor.

Sincronização Pandora ↔ Mimi (Bloqueia: Época 3)

[ ] Conectar a Pandora ao Message Bus para ouvir eventos e atualizar pesos de memória automaticamente.

Fase 3: Segurança e Supervisão (Odlaguna & Ryzu)
Antes de deixarmos a Mimi rodar qualquer código ou skill, a segurança deve estar operando.

Ambiente Ryzu (Bloqueia: Execução de Skills)

[ ] Criar a ponte Rust para o Docker API.

[ ] Implementar o isolamento de rede (No-Network por padrão).

Odlaguna: O Watchdog (Bloqueia: Autonomia da Echidna)

[ ] Implementar monitor de timeout e limites de recursos (CPU/RAM).

[ ] Criar o sistema de "Circuit Breaker" para tarefas que travam.

Beatrice v1.0 (Bloqueia: Interação Final)

[ ] Interface CLI/Web em Rust.

[ ] Conectar a entrada do usuário ao Orquestrador via Bus.

Fase 4: Evolução de Capacidades (Echidna)
A fase final onde o agente passa a criar suas próprias ferramentas.

Runtime de Scripting (Rhai)

[ ] Integrar o engine Rhai no core.

[ ] Definir permissões de segurança para scripts rápidos.

Runtime WASM (Bloqueia: Skills Complexas)

[ ] Implementar o host Wasmtime no Ryzu.

[ ] Criar o pipeline de compilação automática para WASM.

Lógica de Planejamento da Echidna

[ ] Implementar a detecção de padrões de tarefas repetitivas.

[ ] Criar o fluxo: Sugestão de Skill → Validação Odlaguna → Deploy.

📊 Gráfico de Dependências (Resumo)
Item	Depende de:	Por que?
Message Bus	-	É a base de comunicação de todos.
Mimi Core	Message Bus	Precisa do bus para enviar ordens.
Pandora	Mimi Core	Precisa das intenções da Mimi para buscar memória.
Odlaguna	Message Bus	Precisa monitorar as mensagens que circulam.
Ryzu	Odlaguna	Não pode rodar nada sem supervisão de segurança.
Echidna	Ryzu & Pandora	Precisa de onde rodar (Ryzu) e onde salvar (Pandora).
🏁 Milestones (Marcos de Entrega)
Milestone 1 (O Grito): Beatrice envia mensagem, Mimi processa via Gemini e responde via Bus. (Fase 1 completa).

Milestone 2 (A Lembrança): Mimi responde perguntas baseando-se em fatos guardados na Pandora. (Fase 2 completa).

Milestone 3 (A Ação): Mimi executa um script de sistema de forma segura e encerra se ele travar. (Fase 3 completa).

Milestone 4 (A Evolução): Echidna cria uma skill para resolver um problema novo e a salva para uso futuro. (Fase 4 completa).