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

---
Plano 1: Roteiro de Exposição MCP (Principais 3 Capacidades)
Objetivo: Tornar Hermes descobrível e acessí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 (fetch → extract → 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.
- Nome 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.
Meta de cronograma: Primeiro endpoint (note-weaver) ao vivo dentro de uma sessão focada.
---
Plano 2: Atualização da Base de Conhecimento Wiki via FlashLib
Objetivo: Transformar seu wiki de uma coleção de páginas em um grafo de conhecimento agrupado, consultável, com hubs temáticos, detecção de duplicatas e rastreamento de deriva.
Fluxo de trabalho principal
1. Geração de embeddings
- Use seu embedder existente em todas as páginas do wiki + itens Raindrop.
- Armazene embeddings junto com metadados (título, origem, data, tags).
2. Clusterização com FlashLib
- Execute FlashKMeans (ou o método de clusterização recomendado pela biblioteca) em todo o corpus.
- Número alvo de clusters: comece 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 duplicatas: 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 você já usa para note-weaver para manter consistência.
- Estratégia de número de clusters: começar com método do cotovelo ou índice 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
Seu wiki se torna visivelmente mais poderoso — agentes (e você) podem navegar por tema ao invés de busca manual, duplicatas são marcadas automaticamente, e a deriva do conhecimento se torna 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 especificação do endpoint MCP assim que você escolher o ponto de entrada.