Neo: Dois planos concretos (Detalhes ao nível de Jobs)

---
Plano 1: Roteiro de Exposição MCP (Top 3 Capacidades)
Objetivo: Tornar Hermes descobrível e acionável por agentes via endpoints MCP. Isso aborda diretamente a observação de “novo SEO”.
Ordem de prioridade
1. note-weaver (valor imediato mais alto)
2. pipeline de ingestão wiki (Raindrop + EPUB → wiki)
3. habilidade de clusterização FlashLib (nova)
Etapas de implementação
- Fase 1 (note-weaver)
- Expor a lógica existente do note-weaver como uma ferramenta MCP.
- Parâmetros necessários: source_path (arquivo ou URL), target_vault (padrão: ~/wiki), tags (opcional).
- Retorno: markdown estruturado + lista de links gerados automaticamente + Pontuações de Conexão.
- Adicionar streaming de progresso para que ingesta de longa duração reporte status.
- Fase 2 (ingestão wiki)
- Criar um endpoint MCP dedicado ingest-to-wiki que envolva toda a pipeline (buscar → extrair → note-weaver → cross-link).
- Suportar itens únicos e coleções em lote.
- Expor metadados (origem, data, tags originais) para que agentes possam tomar decisões informadas.
- Fase 3 (clusterização FlashLib)
- Assim que a habilidade de cluster existir, expor cluster-corpus e get-cluster-summary como ferramentas MCP.
- Permitir que agentes solicitem agrupamento temático de qualquer coleção e recebam sugestões de páginas hub.
Pontos de decisão
- Autenticação: começar apenas localmente (stdio) e depois adicionar token se necessário.
- Nomeação das ferramentas: usar nomes claros e amigáveis para agentes (note_weaver, ingest_to_wiki, cluster_documents).
- Documentação: cada endpoint deve incluir uma descrição de um parágrafo + exemplo de chamada para que agentes possam se auto-descobrir.
Prazo alvo: Primeiro endpoint (note-weaver) ativo em uma sessão focada.
---
Plano 2: Atualização da Base de Conhecimento Wiki via FlashLib
Objetivo: Transformar sua wiki de uma coleção de páginas em um grafo de conhecimento agrupado, consultável, com hubs temáticos, detecção de duplicados e rastreamento de deriva.
Fluxo de trabalho principal
1. Geração de embeddings
- Usar seu embedder existente em todas as páginas da wiki + itens Raindrop.
- Armazenar embeddings junto com metadados (título, origem, data, tags).
2. Clusterização com FlashLib
- Executar FlashKMeans (ou o método de clusterização recomendado pela biblioteca) em todo o corpus.
- Número alvo de clusters: começar com 30–80 (ajustável).
- Saída: ID do cluster + lista de membros para cada documento.
3. Pós-processamento
- Hubs temáticos: Para cada cluster, gerar automaticamente uma página hub com:
- Nome do cluster (gerado por LLM a partir dos principais documentos)
- Top 5 trechos representativos
- Lista de todas as páginas membros com links
- Detecção de duplicados: Marcar documentos com similaridade cosseno > 0,92 dentro do mesmo cluster.
- Rastreamento de deriva: Reexecutar a clusterização mensalmente e comparar mudanças na associação dos clusters ao longo do tempo.
4. Integração
- Nova habilidade: wiki-cluster (ou estender note-weaver).
- Comando único: wiki-cluster --collection raindrop --output hubs/
- Resultados escritos como arquivos markdown que se tornam páginas wiki de primeira classe.
Pontos de decisão
- Modelo de embeddings: reutilizar o que já usa para note-weaver para manter consistência.
- Estratégia de número de clusters: começar com método do cotovelo ou escore de silhueta, depois permitir override manual.
- Frequência de atualização: nightly para itens novos, reclusterização completa mensalmente.
- Privacidade: todo processamento permanece local.
Resultado esperado
Sua wiki se torna visivelmente mais poderosa — agentes (e você) podem navegar por tema ao invés de busca manual, duplicados são automaticamente sinalizados, e a deriva do conhecimento torna-se mensurável.
---
Próximo passo
Qual plano você quer começar, ou devemos rodar ambos em paralelo? Posso produzir imediatamente o primeiro arquivo de habilidade ou a especificação do endpoint MCP assim que você escolher o ponto de entrada.