Hermes Agent

Resumo

Agente de IA da Nous Research que executa tarefas com ferramentas (terminal, arquivos, web, browser, desktop), mantém memória persistente, agenda cron jobs e delega subtarefas para modelos/CLIs externos (Codex, agy/Antigravity). É a plataforma que automatiza boa parte da rotina do DM Yan (divulgação, vault, Foundry, monitoramentos).

Por que é relevante para Yan

• Orquestra o fluxo de conhecimento: plugin Hermes Obsidian Knowledge Capture cria notas no vault a partir de conversas.
• Delega trabalho pesado para o agy (Google Antigravity CLI) usando o plano Google AI Pro — varreduras de acervo, geração de conteúdo em lote e análises estruturadas.
• Roda em duas máquinas: PC Windows (yan-B450M) e VM Oracle (foundry), com estado sincronizado via Syncthing.
• Skills empacotam procedimentos reutilizáveis (ex.: este vault, Foundry, divulgação, cron).

Conceitos principais

• Skills: procedimentos documentados que o agente carrega por tarefa.
• Cron jobs: tarefas agendadas (watchdogs, rotação de divulgação, captura de conhecimento).
• Delegação: subagentes com modelos pinados (config delegation.model) e CLIs externas via terminal.
• Gateways: conexão a plataformas (Telegram, WhatsApp/WAHA, Discord) para entregas e comandos.
• Memória: notas persistentes (MEMORY/USER) injetadas a cada turno + Honcho (perfil do usuário).

Escopos de memória

• A memória operacional local registra fatos de ambiente e procedimentos necessários para executar tarefas com segurança; ela é injetada automaticamente no contexto do agente.
• O Honcho mantém o perfil e o contexto factual do usuário. Os dois mecanismos são complementares: fatos sobre a configuração e operação do Hermes pertencem à memória operacional, enquanto informações sobre Yan e suas preferências pertencem ao perfil.

Como funciona

• Configuração em config.yaml local (~/.hermes), sincronizada entre máquinas.
• Modelo principal e fallback chain configuráveis via hermes config set.
• Prompt/instruções: o agente usa ferramentas de terminal para ações com efeito real, sempre verificando resultados (filesystem, APIs, sites) antes de reportar sucesso.
• Fluxo de delegação agy: Hermes coleta/embrulha a tarefa → agy processa (quota Google AI Pro) → Hermes valida o JSON → aplica.

Uso atual

• Captura de conhecimento: worker por máquina com Task Scheduler (Windows) e systemd timer (VM).
• Antigravity: binário agy v1.1.19 autenticado com conta Google AI Pro; wrappers hermes-agy/hermes-gf.
• Rota de fallback por assinatura: um adaptador local OpenAI-compatível integra o fluxo do Antigravity ao Hermes. Ele expõe apenas serviços locais de conversa, modelos, quota e saúde; os artefatos de autenticação permanecem fora do vault e da configuração compartilhada.
• Roteiro de divulgação (Discord, Facebook, site) e monitoramento de mesas/agenda.

Limite de acesso a comunidades do Discord

Confirmado (documentação oficial, consulta em 2026-09-28): um bot do Discord é uma conta de aplicação separada e só atua nos servidores aos quais foi instalado por uma pessoa com permissão para isso. O alcance em cada canal também depende das permissões concedidas, inclusive VIEW_CHANNEL para visualizar canal e histórico. Portanto, o Hermes não deve presumir acesso a uma comunidade externa — por exemplo, para pesquisar mapas ou cenas de uma campanha — apenas porque a conta pessoal de Yan participa dela.

Decisão operacional: para pesquisa ou importação de material de um servidor de terceiros, usar somente uma rota autorizada: instalação formal do bot pelo administrador com o menor conjunto de permissões necessário, ou coleta manual pelo usuário e entrega dos arquivos para revisão. Não usar token de conta pessoal nem automatizar uma conta de usuário (“self-bot”); a documentação OAuth2 do Discord veda essa prática fora da API de OAuth2/bot.

Fontes:

• Discord, OAuth2 and Permissions, consultado em 2026-09-28.
• Discord, Server and Channel Management, consultado em 2026-09-28.
• Discord, OAuth2, consultado em 2026-09-28.

Síntese semanal de divulgação a partir de sessões

Relatado em operação local (2026-08-27): as skills de divulgação foram atualizadas para que a sincronização semanal examine as três sessões mais recentes de cada campanha em RPG/3-Sessions/. O fluxo consolida os acontecimentos em ordem cronológica e os resume em um ou dois parágrafos para os templates do vault; o mapeamento deve tolerar variações de nome e emojis nas pastas de campanha.

Limite de confirmação: o lote registra a atualização declarada da biblioteca de skills, não uma execução independente do pipeline nesta curadoria. Antes de depender do resultado em uma publicação, verificar a configuração e a saída atuais da automação.

Monitoramento do navegador da rotação no Discord

Relatado em operação local (2026-09-03): o cronjob discord-rpg-slot-watchdog detectou falhas nas janelas de divulgação porque o processo de navegador usado pela rotação via CDP deixou de aceitar conexões locais. O relato associa a interrupção a uma atualização em segundo plano do Chromium via Snap, enquanto o serviço que mantém a sessão gráfica permanecia marcado como ativo.

Resposta aplicada e critério de verificação: o serviço de sessão gráfica foi reiniciado e a disponibilidade do endpoint CDP local foi conferida antes de considerar a rotação recuperada. Para incidentes equivalentes, não presumir saúde a partir do estado do serviço: validar a conectividade do endpoint do navegador e uma execução posterior da automação.

Limite de confirmação: esta nota preserva um diagnóstico e uma recuperação reportados no lote; não confirma o estado atual do cronjob, do navegador ou das próximas publicações. Detalhes de sessão, credenciais e identificadores de infraestrutura não são registrados no vault.

Novo incidente relatado (2026-09-28): uma rodada de divulgação via CDP registrou cinco publicações bem-sucedidas e uma falha porque o automatizador excedeu o tempo de espera pelo título da janela/canal-alvo. O endpoint CDP pode, portanto, permanecer acessível enquanto a etapa de seleção/validação da interface falha. Além da conectividade do navegador, o critério de sucesso deve conferir que o destino esperado foi identificado e que a publicação foi efetivamente registrada.

Limite de confirmação: o lote não traz inspeção independente da interface, dos logs nem das mensagens publicadas; a contagem e a causa são o relato daquela execução, não o estado atual da rotação.

Incidente adicional relatado (2026-09-28): uma rodada posterior não conseguiu publicar nos cinco destinos efetivamente listados porque o serviço local de despacho recusava conexão em 127.0.0.1:9223 (ECONNREFUSED). O resumo declarou simultaneamente “0/7 sucessos” e cinco falhas detalhadas; a divergência impede usar a contagem agregada como métrica confiável sem consultar o relatório de execução. Para esse modo de falha, investigar a disponibilidade do serviço de despacho local e então validar uma nova rodada por destino, em vez de inferir êxito a partir do agendamento.

Limite de confirmação: o evento só relata o resultado da rodada e não inclui inspeção independente do processo local, de seus logs ou das publicações. Ele não confirma a causa raiz nem o estado atual do serviço.

Estratégia para aprovações de comandos

Decisão operacional relatada (2026-09-11): para reduzir interrupções por aprovações de terminal, a estratégia adotada é evitar execução de código inline (python -c, node -e, bash -c e eval). Quando for necessário executar código auxiliar, ele deve ser escrito em um arquivo nomeado e executado diretamente; leituras e edições simples devem priorizar as ferramentas de arquivo.

Limite de confirmação: o lote registra uma decisão de operação do agente, não uma alteração verificada em approvals.mode nem uma garantia de que comandos inline sejam sempre bloqueados. A documentação oficial descreve aprovações para comandos perigosos e configurações separadas para confirmações destrutivas; confirmar a configuração efetiva antes de alterar a política de segurança.

Seleção de modelos na rota por assinatura

Confirmado (evidência local, 2026-08-23): o adaptador está cadastrado no Hermes como provider local ai-pro. Além dos atalhos operacionais aipro, aipro-hi, aiflash, aicloud e aiopus, o Hermes foi configurado com aliases cujas chaves usam os nomes exibidos ao usuário para famílias de modelos Gemini.

O proxy local também normaliza esses nomes antes de encaminhar a chamada. Isso cobre, por exemplo, as variantes de esforço exibidas pela CLI (gemini-3.7-flash-high, -medium e -low), que são traduzidas para o identificador de backend disponível para essa família. Assim, tanto /model <nome> quanto hermes chat --model <nome> --provider ai-pro podem aceitar os nomes expostos na interface, sem exigir que Yan memorize identificadores internos.

O comando hermes model --refresh consulta a lista de modelos exposta pelos providers e permite escolher o modelo padrão na configuração. A fonte operacional de verdade para os IDs aceitos pelo adaptador é seu endpoint local de listagem de modelos; disponibilidade, nomenclatura e limites continuam variáveis e devem ser conferidos por refresh, saúde e quota antes de tarefas longas.

Mapa reportado de modelos de background (2026-09-27)

Relato operacional — não verificado nesta curadoria: uma resposta do agente descreveu os cron jobs com raciocínio como fixados em ai-pro / gemini-3.7-flash-tiered, enquanto jobs determinísticos sem agente executariam scripts diretamente e não consumiriam LLM. Entre os jobs de agente citados estavam as rotinas de atualização semanal de divulgação, banners, vigilância de slots do Discord e lembrete de vagas.

O mesmo relato atribuiu gpt-5.6-terra / openai-codex aos subagentes delegados; mimo-v2.5 aos auxiliares de compressão, aprovação/MCP e títulos; deepseek-v4-flash à extração web; owl-alpha ao curator de skills e decomposição Kanban; e gemini-3.1-flash-lite à visão auxiliar. Para o Honcho, descreveu mimo-v2.5 e deepseek-v4-flash, com embeddings text-embedding-3-small via OpenRouter.

Limite de confirmação: o lote contém uma pergunta e a resposta do agente, não leitura de config.yaml, lista de cron jobs, logs de execução, catálogo de providers ou configuração do Honcho. O inventário é histórico reportado, não estado atual: antes de alterar custos, pins ou rotas, confirmar o modelo e provider efetivos em cada job e serviço.

Fonte local: lote de knowledge capture batch-7081cc237e04418ab654122c3dfbab5e, evento 9e2b77198bbe248610e89efa, consultado em 2026-09-29.

Cadeia de fallback reportada (atualização em 2026-10-01)

Relato operacional — não verificado nesta curadoria: a rota primária gemini-3.8-flash-tiered, exposta por proxy local, foi reportada com mimo-v2.5 como primeiro fallback e deepseek-v4-flash como segundo. Em atualização posterior, o relato afirma que ambos foram alterados no config.yaml para o provider opencode-go (OpenCode Go), substituindo a configuração anterior via OpenRouter. A sequência declarada é: primário no proxy local → opencode-go / mimo-v2.5 → opencode-go / deepseek-v4-flash.

Limite de confirmação: os lotes não incluem leitura da configuração efetiva, catálogo de providers, logs de failover, health check nem uma chamada que tenha atravessado a cadeia. A ordem, os provedores e os gatilhos de troca são estado operacional reportado, não configuração confirmada. Antes de depender dela em uma tarefa crítica, conferir a configuração ativa e testar a recuperação sem registrar credenciais, tokens ou cabeçalhos de autorização.

Fontes locais: lote de knowledge capture batch-bdb129b4da6a43789d75f4aa001d6340, evento 9dc37f098f4798ecf0e5d62f, consultado em 2026-10-01 (ordem anterior); lote batch-5d08f174f2b84bd69b1c2a6d2423c48a, evento e3d4b121e444b7899e2859fe, consultado em 2026-10-01 (ordem posterior); lote batch-e2da8d6dab5f4ab8a5f828d788273c6e, evento f2c142e247df4f7919bab948, consultado em 2026-10-01 (alteração reportada para opencode-go).

Atualização visual para divulgação no Facebook

Relatado em operação local (2026-09-17): uma skill de divulgação executou uma atualização visual bissemanal de banners de campanhas. O relato descreve geração de arte por OpenAI Codex, normalização para 1536×1024 e aplicação de um layout padronizado, com verificações automatizadas de título, subtítulo, logo, link e dimensões.

Limite de confirmação: esta curadoria só confirmou a existência do relato no lote de captura; o diretório da automação, os arquivos de saída e a lista de campanhas não estavam acessíveis para inspeção independente. Portanto, o registro não confirma que os nove banners declarados continuem válidos, que a automação esteja disponível ou que suas campanhas correspondam à grade atual. Antes de publicar, validar o asset e a configuração vigentes.

Atualização do relato (2026-09-24): uma nova execução declarou regenerar os nove banners, mas o próprio verificador de mutação reportou falha ao gravar verify_all.py. A alegação de conclusão permanece não confirmada: conferir os arquivos finais e executar a verificação vigente antes de usar qualquer banner em publicação.

Atualização do relato (2026-10-01): uma execução posterior declarou atualizar oito mesas ativas (sdmt, hdt, daa, sog, hotf, tor2e, rotss e skt). Segundo o relato, artes-base e banners foram normalizados a 1536×1024, exportados em PNG e JPG, e passaram nos checks automatizados de título, subtítulo, logo, link, rótulo superior e ausência de sobreposição horizontal. O relato também cita atualização de banner_manifest_jpg.json e approved_posts.json.

Limite de confirmação: este registro continua sendo relato de uma resposta de cron; não houve inspeção independente do diretório da automação, dos manifests, dos assets ou dos checks. A discrepância entre a execução que alegava nove banners em 2026-09-24 e esta que lista oito mesas deve ser resolvida pela configuração vigente e pelos arquivos produzidos, antes de publicação.

Fonte local: lotes de knowledge capture batch-31bcec05b51043fe9d147a09e0c61882 (2026-09-17), batch-4c4f5b4f33a24628b4d013c6d473b0f1 (2026-09-24) e batch-a6c2e353d46a4525af6a8f7c5813528e, evento eb48818c27caae2f83f11822 (2026-10-01); relatos operacionais, não inspeção independente.

Segurança de modelo em cron jobs

Para cron jobs de agente criados sem --provider e --model, o Hermes registra snapshots do provider e do modelo resolvidos no momento da criação. Se a configuração global mudar e algum desses snapshots divergir, o job falha de modo fechado: o agendador pula a execução, não faz chamada de inferência e não troca silenciosamente o provider/modelo.

A correção é inspecionar os jobs com hermes cron list e fixar intencionalmente o par desejado em cada job afetado com hermes cron edit <job_id> --provider <provider> --model <model>. Jobs em modo sem agente não usam LLM e não exigem esse pin. Em 2026-08-23, dois jobs de agente locais foram explicitamente fixados para ai-pro / gemini-3.7-flash-tiered após a alteração do modelo global.

Isso protege tarefas autônomas contra custo, quota, contexto e comportamento inesperados causados por uma mudança global. A decisão de pin deve ser revisada quando a rota ou o modelo pretendido forem alterados deliberadamente.

Reinício do gateway

Para pedir o reinício a partir de uma plataforma de mensagens, usar o comando nativo /restart. O gateway aguarda a drenagem de execuções ativas, reinicia e envia uma confirmação ao chat ou thread solicitante quando volta a ficar disponível.

Pelo shell, hermes gateway restart reinicia o serviço do perfil ativo; o subcomando também aceita --all para agir sobre todos os perfis. Não tratar /restart como comando de shell: ele é exclusivo das plataformas de mensagens.

Bot do Telegram em grupos

Bots adicionados a grupos operam em Privacy Mode por padrão. Nesse modo, o Telegram entrega ao bot somente comandos relevantes, mensagens inline, respostas destinadas ao bot e mensagens de serviço; mensagens comuns do grupo não chegam ao gateway. Administradores de bot no grupo recebem todas as mensagens, independentemente desse modo.

Para um grupo que precisa aceitar conversas comuns dirigidas ao Hermes, escolher deliberadamente entre promover o bot a administrador ou desativar o Privacy Mode no BotFather (/setprivacy). A segunda opção requer remover e adicionar o bot novamente ao grupo para surtir efeito. Antes de alterar permissões, confirmar o sintoma no gateway e conferir getMe.can_read_all_group_messages; esse campo informa se o Privacy Mode está desativado, mas não substitui um teste de recebimento no grupo.

Limite de confirmação (2026-08-28): houve relato de que o Hermes não respondeu em um grupo de operação. Esta curadoria registrou o comportamento oficial de entrega do Telegram, mas não verificou logs do gateway, associação do bot ao grupo ou sua configuração efetiva; portanto, não atribui a falha a uma causa única.

Objetivos persistentes (/goal)

O comando /goal <objetivo> mantém um objetivo ativo entre turnos e inicia o primeiro turno imediatamente. Após cada turno, um modelo auxiliar decide se o objetivo está concluído, deve continuar ou está bloqueado; quando deve continuar, Hermes injeta automaticamente um novo turno na mesma sessão. O orçamento padrão é de 20 turnos (goals.max_turns), e o estado persiste em /resume.

Use-o para uma entrega única que exige iteração e evidência verificável — por exemplo: /goal Atualize a nota de uma campanha a partir da transcrição mais recente; preserve prose manual, valide wikilinks e releia o arquivo final. Para tarefas periódicas de monitoramento, preferir /loop ou cron; /goal não substitui agendamento.

Comandos úteis: /goal status (ou /goal), /goal pause, /goal resume, /goal clear e /goal show. /goal draft <objetivo> prepara um contrato de conclusão; ele é útil quando o pedido precisa explicitar resultado, verificação, restrições, escopo e condição de parada. Quality gates (/goal gate add <comando>) acrescentam uma verificação determinística que deve retornar código 0 antes que o objetivo possa ser considerado concluído.

Cuidados: o juiz é um modelo e avalia texto; para entregas técnicas, declarar a evidência esperada e usar gates quando aplicável. Uma mensagem real do usuário tem precedência sobre a continuação automática. Se faltar acesso, credencial ou decisão, o objetivo é pausado como bloqueado em vez de ser dado como concluído.

Limite de mensagens de Goal para Discord (2026-09-27)

Relatado em operação local: a skill hermes-goal-architect teria adotado o teto rígido de 1.900 caracteres para templates de Goal destinados ao Discord. A contagem deve incluir Markdown, espaços e pontuação, preservando margem frente ao limite de 2.000 caracteres de mensagens padrão da plataforma.

Critério operacional: antes de entregar um Goal para colagem no Discord, contar deterministicamente o texto final; não inferir conformidade a partir de uma estimativa. Se exceder 1.900 caracteres, condensar e repetir a validação antes da entrega.

Limite de confirmação: o lote relata uma alteração na skill e um exemplo de 1.757 caracteres, mas esta curadoria não pôde inspecionar a skill nem executar a contagem do exemplo. O teto é registrado como decisão operacional relatada, não como configuração verificada no ambiente.

Fonte local: lote de knowledge capture batch-c0c87a2d95d144a7bb9f130fe63f8fac, evento 4b7d9dbe0fa772eb112997c6, consultado em 2026-09-29.

Objetivo declarado: acervo de aventuras em Markdown (2026-09-22)

Declarado por Yan: converter incrementalmente o material de aventuras do acervo RPG/ para Markdown consultável pelo Hermes, preservando o conteúdo da fonte para apoiar preparação de sessões e bids no StartPlaying. O vault já contém transcrições sob RPG/1-Aventuras/; elas são evidência de material disponível, não confirmação de cobertura integral do acervo nem de fidelidade de cada conversão.

Critérios operacionais: tratar a fonte original como referência, manter a estrutura e a terminologia do sistema quando presentes, registrar lacunas de extração em vez de completá-las por inferência e nunca sobrescrever uma transcrição existente sem revisão. O trabalho deve ser incremental e verificável por arquivo, com escopo, fonte e condição de parada explícitos em cada /goal draft.

Relação no vault: Acervo de aventuras; exemplo de transcrição existente: Raiders of the Serpent Sea — Campaign Book.

Fonte local: evento 3a8c2e149a8d5bbb7943508b, sessão de origem 20260922_222847_def84240.

Objetivo inicial declarado: Reddit Karma Builder (2026-09-27)

Declarado por Yan: construir um cronjob horário para encontrar, em comunidades de RPG, posts recentes nos quais sua experiência possa acrescentar conteúdo útil e contextualizado. A proposta prioriza respostas no idioma predominante de cada subreddit, dúvidas genuínas de regras, mestragem, Foundry VTT e preparação, e engajamento precoce em posts ainda com poucos comentários. O objetivo declarado era construir reputação de modo orgânico, não publicar propaganda ou respostas genéricas.

Guardrails a preservar: a oportunidade deve ser compatível com conhecimento realmente disponível; analisar o contexto e as regras vigentes de cada comunidade antes de responder; limitar o volume e evitar repetir conteúdo. A posição entre os primeiros comentários é uma preferência de oportunidade, não um critério que justifique automação agressiva, spam ou violação das regras da plataforma.

Limite de confirmação: este lote registra o pedido e o texto de objetivo proposto pelo agente, não confirma a criação do cronjob, a lista efetiva de subreddits, a qualidade dos comentários, a existência de conta ou qualquer publicação.

Escopo declarado para descoberta de destinos de divulgação (2026-09-27)

Declarado por Yan: mapear comunidades do Reddit que possam servir à divulgação de mesas pagas, incluindo comunidades de campanhas/cenários, LFG e recortes regionais. O entregável proposto era um catálogo de destinos com regras, exigências de título e flair, idioma e intervalo de postagem.

Critério de segurança editorial: a classificação de cada destino deve partir das regras públicas vigentes e distinguir permissão para post próprio, divulgação apenas em megathread e proibição de cobrança. Nomes de subreddits citados no pedido são apenas candidatos de pesquisa; não provam compatibilidade com mesa paga, sistema, idioma, automação ou Foundry VTT.

Limite de confirmação: este registro preserva uma intenção e um esquema de auditoria sugerido. Não confirma que o catálogo foi criado, que qualquer regra foi consultada ou que um destino tenha sido aprovado para publicação.

Limitação de rede do Reddit Karma Builder

Relatado em operação local: uma execução agendada de reddit_karma_builder.py não processou posts nem publicou comentários porque as consultas aos subreddits configurados receberam HTTP 403. O diagnóstico registrado atribui a resposta à política de rede do Reddit para o IP de datacenter da VM Oracle.

Implicação operacional: enquanto esse bloqueio persistir, o job não consegue descobrir posts por esses endpoints e deve registrar a execução como pulada, sem presumir que a ausência de comentários indique falta de conteúdo elegível. A alternativa relatada é usar uma sessão autenticada do navegador; isso requer confirmação manual de acesso e conformidade com as regras da plataforma antes de automação adicional.

Limite de confirmação: esta curadoria preserva o resultado de uma execução e seu diagnóstico reportado. Não confirma o estado atual do bloqueio, a autenticação de navegador, a configuração do script ou qualquer publicação no Reddit.

Substituição declarada do publicador (2026-09-29)

Registro declarado na conversa — sem inspeção independente da VM, do agendador, do código ou de uma publicação no Reddit: o fluxo de divulgação teria substituído a automação baseada em CDP por um publicador OAuth com requisições HTTP e limites de frequência. O relato afirma que uma execução de teste sem publicação concluiu nas ondas configuradas e que o job foi reativado; isso não comprova autenticação válida, post publicado, permanência da sessão ou operação contínua.

Verificação de acesso relatada (2026-09-29): uma conversa posterior declara que uma sessão autenticada de navegador permitiu consultar a API do Reddit e preparar três drafts de divulgação. A curadoria não inspecionou a sessão, o cache local, o código, os limites de publicação ou o resultado de uma postagem; portanto, o relato não substitui a leitura do log e a confirmação de uma URL pública de post.

Decisão operacional a preservar: tratar a retomada como pendente de confirmação por leitura do log do job e da URL de uma publicação real. Manter limites por subreddit e campanha, validação do destino e uma revisão humana da rotação de mesas ativas antes de publicar. Não registrar cookies, tokens, cabeçalhos de autorização, identificadores de conta ou URLs de rastreamento no vault.

Smoke test de publicação reportado (2026-09-29)

Relato operacional no lote: o publicador OAuth submeteu um post de teste em r/lfgpremium com flair GM LFG; a resposta registrada informa que o post permaneceu público quando consultado externamente (HTTP 200), sem sinal de remoção ou spam na inspeção imediatamente posterior. A caixa de entrada também não teria recebido aviso de moderação naquele momento. Esta é a primeira confirmação reportada de publicação real após os testes e drafts descritos acima.

Controles preservados: o fluxo registrou cooldown de 24 horas por subreddit e de 72 horas por combinação subreddit×campanha. A obtenção da flair ocorre pela API antes do envio; títulos recebem os marcadores de sistema, modalidade online e cobrança exigidos pelo destino. Esses controles reduzem repetição e erro de formatação, mas não garantem aprovação futura da moderação.

Limite de confirmação: a curadoria leu o lote, mas não teve acesso aos logs, ao estado interno da API ou ao post público — a extração web disponível nesta execução não suporta abertura direta de páginas. Portanto, o resultado, os intervalos e a ausência de notificação são evidência operacional reportada, não uma verificação independente do estado atual. A exigência de OAuth para acesso por infraestrutura hospedada é compatível com a documentação oficial do Reddit; o uso deve continuar sujeito aos termos e às regras de cada comunidade.

Distribuição cruzada por onda declarada (2026-09-29)

Registro declarado na conversa — sem inspeção independente do código, da configuração, das flairs disponíveis ou de posts publicados: o publicador teria passado a selecionar campanhas distintas para cada subreddit de uma mesma onda diária, em vez de replicar uma campanha em todos os destinos. O objetivo declarado é expor um portfólio variado a públicos que frequentam mais de uma comunidade, mantendo a compatibilidade entre sistema, comunidade e flair.

Guardrail a preservar: a unicidade por onda é uma regra de diversidade, não autorização para publicar em qualquer destino. Antes de cada envio, validar a regra atual do subreddit, a flair obtida pela API, a compatibilidade do sistema e do VTT anunciado. Em particular, não anunciar uma mesa como Roll20 quando a operação utiliza exclusivamente Foundry VTT; não inferir que um destino aceita mesas pagas ou sistemas específicos apenas a partir de uma configuração anterior.

Limite de confirmação: a descrição de destinos, campanhas e horários do lote é proposta operacional do agente, não evidência de políticas atuais dos subreddits nem de que a rotação foi implementada. A configuração efetiva, o resultado de cada publicação e a aderência às regras de cada comunidade permanecem pendentes de verificação por log e URL pública.

Agenda detalhada relatada para duas ondas (2026-09-29)

Relato operacional no lote — não verificado nesta curadoria: o smoke test teria publicado somente em r/lfgpremium; a resposta afirma que essa limitação foi intencional, para isolar a validação. O mesmo relato descreve uma agenda de duas ondas diárias, com pausas de 8 a 12 minutos entre posts: onda 0 às 12:30 UTC (09:30 BRT), com r/lfgpremium, r/pathfinder_lfg, r/lfgmisc, r/rpg_brasil e r/dnd_brasil; e onda 1 às 19:30 UTC (16:30 BRT), com r/FoundryLFG, r/dndlfg, r/roll20LFG e r/lfg_brasil.

Cuidado operacional: a lista não comprova que os destinos aceitam divulgação paga, os sistemas indicados, posts automatizados ou a frequência declarada. O caso de r/roll20LFG exige verificação reforçada: a operação de Yan usa exclusivamente Foundry VTT e não deve anunciar Roll20. Antes de cada onda, conferir o agendador e log efetivos, as regras atuais e a URL pública de cada post; respeitar o cooldown já registrado por subreddit antes de nova tentativa.

Relação: a rotação de aquisição e os critérios de campanha estão em Plano de Expansão — DM Yan (StartPlaying & Ecossistema).

Falha de destino restrito e tolerância a erro relatadas (2026-09-30)

Relato operacional no lote — não verificado independentemente nesta curadoria: uma execução do cron de rotação teria recebido SUBREDDIT_NOTALLOWED ao tentar publicar em r/lfg_brasil. A resposta capturada atribui o erro a uma comunidade restrita a membros confiáveis e afirma que o destino foi removido da rotação ativa, marcado como bloqueado na configuração e que o publicador OAuth passou a registrar esse erro e prosseguir com os demais destinos, em vez de encerrar o job com falha.

Decisão operacional a preservar: tratar SUBREDDIT_NOTALLOWED como falha isolada de destino e exigir registro explícito de destino, motivo e resultado dos demais envios. Não assumir que o subreddit esteja permanentemente fechado, que a alteração de configuração ocorreu ou que os demais destinos aceitem divulgação: revalidar regras, flair e resultado público antes de uma nova tentativa. Um --dry-run relatado como bem-sucedido não confirma publicação, autorização da comunidade ou conformidade da automação.

Limite de confirmação: a curadoria não inspecionou o cron, o código, a configuração, os logs nem a API do Reddit. Portanto, a causa, as mudanças e o teste são evidência operacional reportada; não registrar credenciais, cabeçalhos de autorização, identificadores de conta ou detalhes privados de execução.

Execução declarada da Onda 0 e monitoramento de moderação (2026-09-29)

Relato operacional no lote — não verificado independentemente nesta curadoria: a resposta do agente afirma que a Onda 0 publicou três anúncios distintos: Dungeons of Drakkenheim em r/lfgpremium (D&D 5e; flair GM LFG), Sky King’s Tomb em r/pathfinder_lfg (PF2e; flair Searching for Players) e Tales from the Lone-lands em r/lfgmisc (TOR2e; flair Multiple Session). Segundo o mesmo relato, cada URL pública retornou HTTP 200, nenhum post estava marcado como removido e a caixa de entrada não continha novo aviso de AutoModerator ou moderação no instante da consulta.

Decisão operacional declarada por Yan: após todo disparo, verificar a caixa de entrada do Reddit especificamente para notificações de erro, AutoModerator ou moderação. A ausência de aviso em uma consulta não comprova aprovação permanente; registrar o resultado da leitura e conferir o estado público do post antes de considerar a publicação estável.

Limite de confirmação: os três posts, as flairs, os códigos HTTP e a caixa de entrada foram apenas afirmados pela resposta capturada. Esta curadoria não acessou a API, os logs, o agendador, a conta ou as URLs públicas; por isso, não trata o relato como confirmação do estado atual nem como validação das regras vigentes dos subreddits.

Execução de comentários sem confirmação de publicação (2026-09-29)

Relato operacional no lote: uma execução de reddit_karma_builder.py --count 3 encontrou posts recentes nos subreddits consultados e realizou três ciclos de interação por CDP/xdotool. Contudo, karma_comment_log.json não registrou nenhum comentário confirmado, pois o texto enviado não foi validado na página de confirmação. O estado persistido indicou today_comments: 2, divergindo do log de publicações confirmadas.

Decisão operacional: não usar today_comments nem ciclos de teclado enviados como prova de comentário publicado. O critério de sucesso deve exigir registro no log de confirmação e, idealmente, a URL/ID do comentário consultável; até lá, tratar a execução como não confirmada e evitar inferir que o limite diário foi consumido.

Limite de confirmação: este registro descreve a resposta capturada, sem inspeção independente do script, estado JSON, navegador ou Reddit. Não confirma que qualquer comentário tenha sido publicado nem o estado atual do job.

Restrição editorial para comentários do Karma Builder (2026-09-29)

Decisão declarada por Yan: evitar posts técnicos, sobretudo pedidos de suporte de software/VTT, e priorizar comentários de opinião fundamentada sobre mestragem, condução de mesa, dinâmica de grupo, interpretação e ambientação. A motivação é reduzir o risco de erros factuais em recomendações técnicas.

Extensão da restrição editorial (lote consultado em 2026-09-29): excluir também discussões de mecânica e regras de D&D — por exemplo, confrontos hipotéticos, builds, combate tático, magias, níveis, slots, dano, otimização e RAW/RAI. O foco permitido permanece em perspectivas narrativas e de condução de mesa, sem apresentar recomendações mecânicas como opinião. Um relato do agente afirma que um comentário com erro de regra foi removido e que filtros foram alterados; esta curadoria não inspecionou o comentário, a conta, o código nem os logs, portanto não confirma a remoção ou a implementação dos filtros.

Relato operacional do agente — não verificado independentemente nesta curadoria: um comentário sobre OSRIC 3.0 no r/FoundryVTT teria sido removido após citar módulos de terceiros sem confirmação; em resposta, r/FoundryVTT teria sido retirado dos alvos e temas como módulos, macros, instalação, manifests, bugs, crashes, plugins e compêndios teriam passado a ser filtrados. Os números de votos e os demais comentários mencionados no relato não foram verificados e não devem ser tratados como métrica operacional.

Guardrail a preservar: não apresentar software, módulos, compatibilidade, procedimentos de instalação ou regras técnicas como fato sem fonte primária e verificação atual. A remoção de um destino ou filtro no código só deve ser considerada efetiva após leitura da configuração e de um log de execução; esta nota registra a decisão editorial, não a implementação.

Auditoria contínua de feedback proposta (2026-09-29)

Relato operacional no lote — não verificado independentemente nesta curadoria: o fluxo reddit-organic-karma-builder teria sido ampliado com uma auditoria recorrente dos comentários publicados nas 48 horas anteriores. O relato descreve atualização de pontuação e coleta de respostas diretas, seguida de classificação por LLM de críticas, correções e lições acionáveis. As lições seriam reaplicadas na geração de comentários futuros, com cautela adicional por comunidade; comentários com pontuação negativa seriam removidos automaticamente e gerariam alerta.

Limite de confirmação: a curadoria não inspecionou código, agendador, logs, dados persistidos, a conta nem comentários públicos. Assim, não confirma que a auditoria, a retenção de 48 horas, a análise por LLM, a remoção automática ou os alertas estejam implementados ou tenham sido executados. Não registrar no vault caminhos operacionais, identificadores de conta, conteúdo de comentários, críticas de usuários ou outros dados pessoais coletados pelo fluxo.

Conformidade a resolver antes de ativar automação de interação: a política atual do Reddit proíbe apps de manipular karma e de fazer spam por posts ou comentários automatizados; também exige perfil/rotulagem de app, finalidade e escopo definidos, e uso autorizado da Data API. Como o uso integra uma atividade profissional remunerada, a documentação do Reddit informa que finalidades comerciais exigem permissão prévia. Portanto, score ou resposta crítica devem servir, no máximo, como sinal para revisão humana; não usar exclusão automática para administrar karma, nem publicar, remover ou processar conteúdo de usuários por automação sem aprovação e escopo compatíveis com os termos vigentes.

Decisão operacional recomendada: manter evidência mínima e efêmera do que precisa de revisão, respeitar exclusões/remoções e não transformar conteúdo de usuários em corpus ou treinamento de modelo. Cada sugestão de lição deve permanecer pendente de revisão humana antes de influenciar um comentário futuro; a publicação e qualquer exclusão devem requerer confirmação humana explícita.

Stop-loss de karma solicitado para comentários (2026-09-30)

Declarado por Yan: monitorar publicações e comentários durante as primeiras 48 horas, em intervalos de 20 minutos, e excluir automaticamente um comentário se sua pontuação ficar negativa ou cair mais de 20% do pico observado. A resposta capturada afirma que o watcher teria sido implementado e ativado, com rastreamento do pico e alertas; esta curadoria não inspecionou código, agendador, logs, conta nem comentário público e não confirma a implementação, a frequência ou qualquer exclusão.

Limite de conformidade: a política atual do Reddit veda que apps manipulem karma e proíbe spam por posts ou comentários automatizados. O uso de variação de score como gatilho para remover conteúdo com o objetivo de “estancar” perda de karma é incompatível com o guardrail já registrado nesta nota. Pontuação deve servir apenas como sinal para revisão humana; não ativar remoção automática nem alterar interações futuras sem confirmação humana explícita e sem validar a conformidade com as políticas vigentes e as regras da comunidade.

Cadência combinada de monitoramento relatada (2026-09-30)

Relato operacional no lote — não verificado independentemente nesta curadoria: o watcher rápido teria varrido posts e comentários das 48 horas anteriores a cada 20 minutos, enquanto o pipeline principal repetiria a auditoria e a busca de novas discussões no início de cada hora. A resposta também afirma que ambos compartilhariam os dados de histórico e de lições; esta curadoria não inspecionou agendador, código, arquivos de estado, logs, conta ou comentários públicos e não confirma a cadência, o compartilhamento de dados nem qualquer ação executada.

Guardrail a preservar: a rotina horária não altera a decisão de conformidade já registrada. Pontuação, respostas e lições devem permanecer apenas sinais para revisão humana; não usar a cadência para automatizar publicação, remoção ou mudança autônoma de comportamento.

Novo relato de remoção e ajuste editorial (2026-09-30)

Relato operacional no lote — não verificado independentemente nesta curadoria: após críticas que alegavam que um comentário em r/vtm soava gerado por IA, o agente afirmou ter removido o comentário e marcado um registro local como excluído. Também afirmou ter alterado o gerador para evitar travessões longos, negrito enfático, jargão analítico e prosa excessivamente elaborada, com respostas de até dois parágrafos curtos.

Limite de confirmação e decisão de segurança: o lote não fornece inspeção da conta, do comentário público, do estado local, do código ou de logs; por isso, não confirma exclusão nem alteração persistente. O conteúdo das críticas e identificadores do comentário não são preservados no vault. A diretriz anterior continua: feedback de pontuação ou respostas só pode sinalizar revisão humana; não automatizar remoção, publicação ou aprendizado que altere autonomamente interações futuras sem confirmação humana explícita e conformidade atual com as políticas da plataforma.

Flag reportado em r/dndnext por conteúdo de IA/LLM (2026-09-30)

Relato operacional no lote — não verificado independentemente nesta curadoria: a resposta capturada afirma que a moderação de r/dndnext sinalizou um comentário em uma discussão sobre Storm King’s Thunder ao citar a Regra 9 da comunidade. O relato atribui a ação à proibição de textos ou comentários escritos por IA/LLM. Não foram preservados o texto do comentário, o nome da conta, URL, identificadores, pontuação ou conteúdo de interações de terceiros.

Corroboração externa limitada: resultados públicos indexados do Reddit reproduzem a proibição de textos ou comentários escritos por IA/LLM em r/dndnext, mas a numeração aparece como Regra 11 na consulta atual, em vez de Regra 9 relatada no lote. A divergência pode refletir renumeração ou contexto de moderação distinto; tratar a regra e seu número como requisito a reconfirmar na comunidade antes de qualquer participação.

Decisão operacional a preservar: r/dndnext não deve integrar fluxos de comentários assistidos ou automatizados por LLM. Um flag ou remoção não permite inferir quais características estilísticas motivaram a moderação; não usar marcadores de estilo, score ou reações de usuários como mecanismo automático de exclusão, ajuste de modelo ou publicação. Qualquer interação futura requer autoria humana, revisão humana explícita e consulta prévia das regras vigentes do subreddit.

Inventário de destinos de divulgação reportado (2026-09-29)

Relato operacional no lote — catálogo não inspecionado nesta curadoria: uma auditoria via API OAuth do Reddit teria gerado um inventário de 19 subreddits em arquivos operacionais, classificando cada destino por permissão de post próprio, megathread ou proibição de divulgação paga, além de registrar flair, idioma e cooldown. O número e a existência dos arquivos foram afirmados pela resposta capturada, mas não puderam ser lidos pelo worker por estarem fora da allowlist do vault.

Resultado a preservar como regra de triagem, sujeito a reconfirmação: comunidades dedicadas a campanhas de D&D devem ser tratadas como inadequadas para recrutamento de jogadores quando suas regras forem DM-only ou impedirem LFP; a existência de flair para suplemento de mestre não autoriza divulgar mesa paga. A resposta também classificou r/oneringrpg e r/vtm como candidatos de post próprio, respectivamente com convenção [LFG] e prefixo [Storyteller]. Essas classificações são instantâneos reportados, não autorização permanente: conferir regras, flair disponível, cobrança, idioma, VTT e cooldown imediatamente antes de publicar.

Guardrail operacional: manter uma allowlist específica por comunidade e excluir destinos com proibição explícita de mesas pagas. Não usar o inventário como justificativa para automação de posts nem para dispensar revisão humana das políticas vigentes.

Correção de destino para anúncios pagos (2026-09-29)

Confirmado na regra pública da comunidade: r/FoundryLFG exige [FoundryVTT] exatamente no título para mesas hospedadas no Foundry e exige [PAID] em títulos de mesas cobradas. A operação do Yan deve anunciar somente mesas realmente hospedadas no Foundry VTT e incluir ambos os marcadores quando aplicáveis.

Relato operacional no lote — não verificado nesta curadoria: uma publicação de Tales from the Lone-lands em r/lfgmisc teria sido removida por usar [Paid] e um link para StartPlaying, em desacordo com a regra local que proíbe mesas pagas. O relato afirma que o post foi apagado e que r/lfgmisc foi bloqueado na configuração e no publicador; também declara a inclusão de r/startplaying na rotação e a normalização automática de [FoundryVTT] para r/FoundryLFG. Não inferir que essas alterações persistiram: conferir a configuração, o log do publicador e as regras atuais antes de qualquer nova onda.

Decisão operacional: r/lfgmisc não é destino para mesas pagas. A lista de destinos é uma allowlist revisada por comunidade, não uma classificação genérica por sistema: antes do envio, validar se o subreddit aceita cobrança, a plataforma anunciada, o formato do título, a flair e a frequência. A compatibilidade histórica ou posts antigos não substituem essa revisão.

Fonte local: eventos d52bfef4c438c47afb6b02f7 e eceaaebd158e03b145bff5a6, sessão de origem 20260929_141426_815254d1.

Modo silencioso do watcher relatado (2026-09-30)

Relato operacional no lote — não verificado independentemente nesta curadoria: o watcher teria passado a suprimir a saída padrão nos ciclos sem incidentes, mantendo registros locais de auditoria e emitindo alerta no Telegram somente quando uma remoção por stop-loss fosse efetivamente realizada. A curadoria não inspecionou o script, o agendador, os logs, o histórico persistido nem a configuração de entrega; portanto, não confirma que o modo silencioso, o registro local ou o alerta seletivo estejam ativos.

Guardrail de conformidade: reduzir ruído de notificações é uma preferência operacional separada da política de interação. O silêncio em rotina normal não autoriza remoção automática: score e variação de score devem continuar apenas como sinais para revisão humana, conforme as limitações já registradas nesta seção.

Fonte local: lote de knowledge capture batch-aa8fb315de0c474596ea9a408b34808a, evento 21482f412ab1a9d648e9d6c6, consultado em 2026-09-30.

Preferência de notificações para o watcher (2026-09-30)

Decisão declarada por Yan: ciclos rotineiros de verificação devem permanecer silenciosos. Notificar no Telegram somente quando houver exclusão, aviso que requeira atenção ou criação de novo comentário; não enviar confirmações horárias de verificação.

Limite de confirmação: a resposta capturada afirma que a entrega do job horário teria sido configurada como local e que os três tipos de evento seriam a única saída para o chat. Esta curadoria não inspecionou o agendador, os logs, a configuração de entrega nem o código; portanto, registra a preferência de notificação, não a implementação. A preferência não substitui o guardrail de conformidade: exclusões e publicações continuam a exigir revisão humana explícita.

Fonte local: lote de knowledge capture batch-18a3ec5485544c50a5e12ff36113c40b, evento aed2fa6ea81dcded63e6329f, consultado em 2026-09-30.

Falha silenciosa de autenticação no watcher (2026-10-02)

Relato operacional no lote — não verificado independentemente nesta curadoria: uma credencial efêmera de acesso do navegador teria expirado e passado a receber HTTP 401, embora a sessão de login permanecesse válida. O relato afirma que a credencial foi renovada por uma sessão local do navegador e que uma consulta autenticada e a leitura de um feed voltaram a funcionar. Nenhum cookie, token, cabeçalho de autorização, nome de conta, porta local ou caminho de cache é preservado nesta nota.

Falha de observabilidade relatada: o watcher teria aceitado a credencial obtida do cache sem validar sua autenticidade antes da auditoria. Erros por item eram suprimidos, e o ciclo ainda registrava conclusão, permitindo que uma falha total de autenticação parecesse uma auditoria normal. A existência de itens com score baixo no histórico, sem confirmação de sua presença atual nem de qualquer remoção, não prova que o mecanismo de revisão tenha agido.

Decisão operacional a preservar: antes de auditar, validar explicitamente a autenticação; se houver falha de autorização, invalidar somente o artefato efêmero de cache, registrar um erro inequívoco e alertar para intervenção humana. Métricas de itens verificados só devem ser emitidas quando a consulta autenticada e cada resultado necessário puderem ser distinguidos de erro. Qualquer exclusão, publicação ou alteração motivada por score continua sujeita à revisão humana explícita e à conformidade com as políticas vigentes do Reddit.

Limite de confirmação: o lote contém o relato de diagnóstico, renovação e testes; esta curadoria não acessou a sessão do navegador, os scripts, logs, cache, agendador ou Reddit. Portanto, não confirma o estado atual da autenticação, a correção do watcher, a existência de itens de score baixo ou qualquer ação sobre conteúdo.

Fonte local: lote de knowledge capture batch-f50eda123e784b2f8a9250b37ece8683, evento 3e6175991fa6815f082e4ce0, consultado em 2026-10-02.

Correção do diagnóstico de itens com score baixo (2026-10-02)

Relato operacional no lote — não verificado independentemente nesta curadoria: após o patch de validação de autenticação, quatro entradas históricas com pontuação menor ou igual a zero foram reavaliadas. Segundo o relato, todas já estavam marcadas como excluídas no estado persistido e apareciam como conteúdo e autor excluídos na consulta à API. Portanto, a presença desses registros no endpoint de consulta não foi evidência de comentários ainda ativos: eram registros residuais (tombstones).

Decisão de diagnóstico: antes de concluir que uma exclusão falhou, cruzar a pontuação com o estado persistido de exclusão e o estado atual retornado pela plataforma. Não tratar um registro residual de API como conteúdo vivo sem essa verificação. Este critério melhora a observabilidade, mas não autoriza exclusão automática: score continua sendo, no máximo, sinal para revisão humana explícita e uso compatível com as políticas vigentes do Reddit.

Limite de confirmação: o lote afirma teste com credencial inválida, um ciclo posterior bem-sucedido e a revalidação de estado, mas a curadoria não inspecionou código, logs, estado local, conta ou API. Não confirma a implementação atual, os quatro registros nem qualquer ação sobre conteúdo.

Fonte local: lote de knowledge capture batch-cad27fbc617d489bba5a47b568f0e9b5, evento d286a91c1c1b95c6623b8bf9, consultado em 2026-10-02.

Documentação operacional de autenticação e tombstones (2026-10-02)

Relato operacional no lote — não verificado independentemente nesta curadoria: duas skills locais de automação do Reddit teriam sido atualizadas e conferidas no filesystem. A primeira passou a exigir obtenção e validação de autenticação antes de cada ciclo; diante de falha, o cache efêmero seria invalidado, o ciclo encerrado com erro e o alerta seria limitado a uma vez por episódio. A segunda documenta o mesmo comportamento como correção de um diagnóstico anterior que podia reportar conclusão apesar de autenticação inválida.

Critério de diagnóstico relatado: uma resposta residual da API para conteúdo removido (tombstone) não equivale a comentário ativo. Antes de classificar uma remoção como falha, conferir conjuntamente o autor e corpo retornados, o indicador persistido de exclusão e a identidade esperada do autor. O escopo de observação do watcher permanece limitado às 48 horas a partir da publicação.

Guardrail de conformidade: essa documentação melhora detecção de falha e evita falsos positivos, mas não altera as restrições já registradas nesta nota. Pontuação e estado de conteúdo são somente sinais para revisão humana; não automatizar publicação, remoção ou mudança de comportamento para gerir karma.

Limite de confirmação: o lote relata edição e verificação de skills, inclusive teste do caminho de falha, mas esta curadoria não leu as skills, scripts, cache, logs, agendador, conta nem a API do Reddit. Não confirma que o comportamento esteja ativo agora nem que qualquer alerta ou remoção tenha ocorrido.

Fonte local: lote de knowledge capture batch-1f9e433edd2748fdb3b9f0d6a09164d0, evento 86c7489c8c2b7778c7891d3b, consultado em 2026-10-02.

Deriva de cooldown entre ondas e correção reportada (2026-10-02)

Relato operacional no lote — não verificado independentemente nesta curadoria: uma execução de divulgação agendada não publicou anúncios. A primeira onda teria falhado por HTTP 401 de autenticação; a segunda terminou sem falhas, mas sem destinos elegíveis, porque todos ainda estavam dentro do cooldown de 24 horas. O diagnóstico atribuiu a lacuna a postagens no fim de uma onda de aproximadamente 40 minutos, que ultrapassavam o início da janela agendada do dia seguinte por poucos minutos ou segundos.

Correção relatada: o limite por subreddit (SUB_COOLDOWN_H) teria sido reduzido de 24 para 20 horas no publicador OAuth, mantendo o cooldown por campanha em 72 horas. Segundo o relato, o particionamento por paridade entre ondas permanece inalterado e limita cada subreddit a, no máximo, uma seleção por dia; um teste seco teria selecionado quatro destinos em cada onda e excluído r/lfg_brasil, marcado como bloqueado. O backup do script e a documentação operacional correspondente também teriam sido preservados/atualizados.

Decisão operacional a preservar: o intervalo de 20 horas resolve a deriva de agenda relatada, mas não comprova autorização para publicar. Antes de uma execução real, conferir no código e nos logs o timestamp da última publicação por destino, o estado de autenticação, a regra vigente de frequência de cada comunidade e o resultado público de cada envio. Não registrar credenciais, tokens, cabeçalhos de autorização ou identificadores de conta no vault.

Limite de confirmação: a curadoria leu somente os lotes de conversa, não o publicador, backup, skill, arquivos de estado, logs, agendador, autenticação ou posts públicos. Portanto, a alteração, os testes secos, os destinos selecionados e a exclusão do destino bloqueado são evidência operacional relatada, não confirmação independente do estado atual nem de conformidade com regras dos subreddits.

Fontes locais: lote de knowledge capture batch-870accf461554e6c8affdaaa0d783247, evento dcd93869e397301f28706c05; e lote batch-35f2ef304e3147f89d43c3445d0619e2, evento 64e9f1f4752b92fa615ee3dd, consultados em 2026-10-02.

Estado pausado residual após falha de autenticação (2026-10-03)

Relato operacional no lote — não verificado independentemente nesta curadoria: após uma falha HTTP 401, o pipeline de comentários teria sido pausado pelo watchdog. Embora a autenticação tivesse sido corrigida depois, o estado persistido teria mantido a pausa e os ciclos subsequentes apenas auditavam, sem criar novas interações, até uma retomada manual. O mesmo relato afirma que o watcher continuou executando auditorias periódicas sem novo erro de autenticação e que o publicador de divulgação voltaria à janela seguinte após a correção de cooldown já registrada.

Decisão operacional a preservar: uma recuperação de autenticação deve verificar também as flags persistidas de pausa e o modo efetivo dos jobs. Após qualquer 401, distinguir no log: autenticação recuperada, job ainda pausado e job realmente apto a executar. Essa checagem não autoriza automação de comentários, publicação ou exclusão para gerir karma: quaisquer interações permanecem sujeitas à revisão humana explícita e às políticas vigentes do Reddit.

Limite de confirmação: a curadoria leu o lote de conversa, não os scripts, estado persistido, agendador, logs, conta, API ou URLs públicas. Portanto, não confirma a ocorrência da pausa, a retomada manual, a saúde atual do watcher, a publicação posterior nem as métricas de karma relatadas. Nenhuma credencial, identificador de conta ou dado de autenticação é preservado.

Fonte local: lote de knowledge capture batch-17a07d6b00be46c290459611bb743f5a, evento 065f342effe57007ef9f6541, consultado em 2026-10-03.

Núcleo de estado unificado para saúde do Reddit reportado (2026-10-03)

Relato operacional no lote — não verificado independentemente nesta curadoria: a Fase 1 do núcleo de saúde teria sido implementada com estado persistido sob lock separado, escrita atômica, recuperação fechada diante de JSON inválido e uma cópia preservada do estado corrompido. O relato também declara uma interface central para registrar verificações, falhas, pulos e reconciliação bem-sucedida, além de uma fila de alertas idempotente com reenvio limitado.

Decisão de arquitetura relatada: somente a reconciliação bem-sucedida deve restaurar o estado para saudável e remover a pausa persistida do pipeline. As razões de falha devem ser classificadas e os detalhes de alerta precisam ser sanitizados para não expor material de autenticação. O envio de alertas deve ocorrer fora da região crítica para não reter o lock durante I/O de rede.

Verificação reportada: a resposta capturada declara que uma suíte de oito testes unitários, incluindo dois processos concorrentes reais, concluiu com sucesso. A curadoria não pôde ler os arquivos operacionais, executar os testes, inspecionar o lock, o estado, os alertas ou o agendador; portanto, a implementação e o resultado dos testes permanecem evidência operacional relatada. Não registrar caminhos operacionais, tokens, cabeçalhos, cache de sessão, identificadores de conta ou detalhes de alertas no vault.

Relação: complementa o diagnóstico de pausa residual e preserva o princípio de que qualquer interação com conteúdo do Reddit exige revisão humana explícita e conformidade com as políticas vigentes.

Fonte local: lote de knowledge capture batch-0330bc5730f544af8149f83427d90257, evento d7deabe7af31665f5fce2953, consultado em 2026-10-03.

Integração dos jobs ao estado unificado de saúde do Reddit (2026-10-03)

Relato operacional no lote — não verificado independentemente nesta curadoria: os três jobs do fluxo de Reddit teriam sido integrados ao núcleo de saúde unificado. O watcher só tentaria recuperar autenticação quando obtivesse a concessão de reconciliação; o pipeline e o publicador registrariam falhas de autenticação e pulariam silenciosamente quando o estado não estivesse saudável. Falhas transitórias de rede ou limitação de taxa não deveriam degradar esse estado.

Decisão de arquitetura relatada: a autoridade para promover o estado de volta a saudável permanece exclusivamente na reconciliação bem-sucedida. Os jobs consumidores registram verificação, falha ou pulo, mas não restauram a saúde por conta própria. Essa separação evita que um job local limpe uma pausa persistida sem uma validação completa da autenticação.

Verificação reportada: a resposta capturada declara compilação dos três jobs, oito testes unitários aprovados, execução do watcher sem erro, consulta de estado do pipeline e teste seco do publicador sem falhas. No mesmo relato, a detecção de um job obsoleto gerou um alerta pendente porque a entrega ao Telegram retornou HTTP 400; o alerta teria sido preservado para nova tentativa. A curadoria não leu os scripts, testes, arquivos de estado, logs, agendador, fila de alertas ou Telegram; portanto, esses resultados são evidência operacional relatada, não confirmação independente. Nenhuma credencial, identificador de conta ou detalhe de autenticação é preservado.

Guardrail de conformidade: maior resiliência de autenticação e alertas não altera as restrições anteriores: qualquer interação com conteúdo do Reddit continua a exigir revisão humana explícita e conformidade com as políticas vigentes da plataforma.

Fonte local: lote de knowledge capture batch-748cb55069c44b9db0ffa1fc49c113dc, evento d29d4b6b6253abcde3ae84fb, consultado em 2026-10-03.

Ajustes reportados na integração de saúde do Reddit (2026-10-03)

Relato operacional no lote — não verificado independentemente nesta curadoria: após a integração, o alerta ao Telegram teria recebido um fallback que repete o envio sem formatação Markdown quando a primeira tentativa recebe HTTP 400. O mesmo relato afirma que a retomada manual passou a exigir uma verificação de autenticação registrada antes de permitir a reconciliação, evitando que uma opção de retomada se tornasse inócua por não deter a concessão normal de reconciliação.

Verificação reportada: a resposta capturada declara dez testes unitários aprovados, compilação dos arquivos envolvidos e uma execução agendada do watcher sem erro. Também declara estado de saúde saudável após a execução e a criação de uma verificação diária de divergência do registro de campanhas. Não foram lidos nesta curadoria os scripts, testes, estado persistido, agendador, fila de alertas ou a entrega no Telegram; portanto, os ajustes e resultados continuam evidência operacional relatada, não confirmação independente. Nenhum segredo, credencial, identificador de conta ou detalhe de autenticação é preservado.

Decisão de arquitetura a preservar: uma retomada manual não deve contornar a prova de autenticação; erros de apresentação de alerta não devem descartar o alerta pendente. Esses controles tratam recuperação e observabilidade, sem autorizar publicação, remoção ou outras interações autônomas com conteúdo do Reddit.

Fonte local: lote de knowledge capture batch-78304114c94f41e09c048f0c3d48039d, evento 841322a9b403f32d3544ea49, consultado em 2026-10-03.

Reauditoria reportada da integração de saúde do Reddit (2026-10-03)

Relato operacional no lote — não verificado independentemente nesta curadoria: uma reauditoria posterior declarou 13 testes unitários aprovados e compilação de cinco arquivos Python. Ela confirma os guardrails de recuperação: a retomada manual só pode promover causas recuperáveis de autenticação ou ausência de token; indisponibilidade de CDP e estado corrompido são recusados. Timeouts, respostas 5xx e limitações 429 permanecem falhas transitórias, sem degradar a saúde compartilhada.

Observabilidade e esquema reportados: o cooldown de alerta seria segmentado por natureza da falha, impedindo que um alerta recente de job obsoleto suprima um alerta de autenticação expirada; falhas do notificador registrariam traceback. O relatório também declara que os jobs autenticados de builder e publicador registram heartbeat de execução mesmo sem publicação. No registro de campanhas, a validação aceita schema_version 1.x com revisão a partir de 1 e verifica lifecycle.status; a execução relatada do validador não apresentou SCHEMA_ERROR e manteve como pendências apenas divergências de dados e agenda.

Limite de confirmação: a curadoria avaliou dois eventos que repetem o resultado da reauditoria, mas não leu os arquivos operacionais, executou os testes, inspecionou o estado persistido, o agendador ou a entrega de alertas. Assim, os controles e saídas acima permanecem evidência operacional relatada. Nenhum caminho operacional, identificador privado ou dado de autenticação foi preservado.

Fonte local: lote de knowledge capture batch-760865e827b14ffca93925ddaa96a5d1, eventos 397818cb9c065dee5acca662 e 8d8ce137ce2aaf2288cc1b6c, consultado em 2026-10-03.

Aprovação de escritas de memória

Confirmado (documentação oficial e aviso operacional local, 2026-09-22): quando memory.write_approval está ativo, o Hermes não deve gravar, substituir ou excluir entradas de memória de modo autônomo. Fora do CLI interativo — inclusive na revisão de autoaperfeiçoamento em segundo plano — a alteração é encenada para revisão em vez de aplicada.

A revisão ocorre com /memory pending; depois, a entrada deve ser explicitamente aprovada com /memory approve ou descartada com /memory reject. Portanto, uma resposta de agente que alegue ter consolidado ou liberado espaço na memória sem evidência dessa aprovação não confirma a alteração. Conferir a fila pendente e o conteúdo efetivo da memória antes de tratar a operação como concluída.

Limite de confirmação: o aviso local confirma que havia uma substituição proposta aguardando revisão naquela conversa; esta nota não afirma qual configuração está ativa agora nem que qualquer entrada específica foi aprovada ou rejeitada.

Incidente reportado de atualização de runtime (2026-09-27)

Relato operacional — não inspecionado independentemente nesta curadoria: às 03:58 BRT, o gateway do Hermes teria recebido encerramento gracioso durante uma atualização automática do sistema. No reinício, o relato atribui a indisponibilidade a incompatibilidades entre o ambiente Python legado e o runtime atualizado, incluindo falhas de importação de dependências e de inicialização de servidores MCP. Uma reinicialização posterior da VM e a conclusão da atualização teriam restaurado o serviço.

Decisão operacional: após atualização automática ou indisponibilidade do gateway, não usar o status do processo como prova de recuperação. Confirmar, nesta ordem, que o gateway recebe uma mensagem, que os workers necessários iniciaram sem erro e que uma tarefa real de baixo risco conclui. Preservar logs e versões de runtime para diagnóstico antes de qualquer alteração corretiva.

Limite de confirmação: o lote contém a pergunta de Yan e a resposta diagnóstica do agente, mas não os logs do systemd, o histórico do gerenciador de pacotes, a configuração do ambiente Python nem um teste independente posterior. Portanto, a causa raiz, os horários e os componentes afetados permanecem como alegações do relato, não fatos confirmados no vault.

Relações no vault

• Hermes Obsidian Knowledge Capture — projeto do plugin.
• Google Antigravity CLI — worker externo delegado.
• Obsidian / Quartz / Wiki-Yan — vault e publicação.
• RPG/1-DM Toolkit — guias operacionais do fluxo de divulgação.

Limitações e cuidados

• Config e memória sincronizadas via Syncthing podem gerar conflitos (*.sync-conflict-*) — limpar periodicamente.
• Delegados externos (agy, Codex) não executam efeitos colaterais diretos: Hermes valida planos/saídas antes de aplicar.
• Nunca escrever credenciais/tokens no vault; chaves ficam no .env do Hermes.
• A disponibilidade da rota Google AI Pro e seus modelos é variável; manter um fallback independente e consultar a saúde/quota local antes de tarefas de alto volume.

Fontes

• Persistent Memory — Hermes Agent, documentação oficial, consultada em 2026-09-27 (memory.write_approval, fila de revisão e comportamento da revisão em segundo plano).
• Slash Commands Reference — Hermes Agent, documentação oficial, consultada em 2026-09-27 (/memory pending, aprovação e rejeição).
• Evidência local: lote de captura batch-d7b330f749fd49249106264f406051d6, consultado em 2026-09-27 (aviso de alteração de memória aguardando revisão; nenhuma alteração individual confirmada).
• Evidência local: lote de captura batch-3d168af01359437f8b08c271f5c2779a, consultado em 2026-09-29 (objetivo inicial proposto para o Reddit Karma Builder; sem criação ou execução independente confirmada).
• Evidência local: lote de captura batch-56f99fb209514255956c0815e13b3321, consultado em 2026-09-29 (escopo proposto para auditar destinos de divulgação de mesas pagas; sem catálogo ou aprovação de comunidade confirmados).
• Reddit, Reddit Rules, consultado em 2026-09-29 (participação autêntica, respeito às regras de cada comunidade e proibição de spam ou manipulação de conteúdo).
• Evidência local: lote de captura batch-98eeb98c1c6742869bc64c6bcfe170bd (execução reportada do reddit_karma_builder.py; HTTP 403 e nenhum comentário publicado).
• Evidência local: lote de captura batch-6033e0f6a1704af1b4279cf31fe2ee35, consultado em 2026-09-29 (três ciclos via CDP/xdotool; nenhum comentário confirmado no log; contador persistido divergente).
• Evidência local: lote de captura batch-ad6d1c742ce94f82801732bf07a3132e, consultado em 2026-09-29 (substituição e reativação do publicador relatadas; sem inspeção independente da VM, do job ou de publicação real).
• Evidência local: lote de captura batch-56095ea54c184a419b074b8f96857a35, consultado em 2026-09-29 (acesso autenticado e preparação de três drafts relatados; sem inspeção de sessão, cache, código, logs ou post público).
• Evidência local: lote de captura batch-2b53dadcc82a40ffa048dedc0284d0a0, consultado em 2026-09-29 (smoke test de publicação e estado de moderação relatados; sem acesso independente aos logs, à API ou ao post nesta curadoria).
• Evidência local: lote de captura batch-39ee0b72a5b04f47b57591e96bfb626f, consultado em 2026-09-29 (regra proposta de distribuição cruzada por onda; sem inspeção independente da configuração, das políticas atuais dos subreddits ou de publicações).
• Evidência local: lote de captura batch-fef926440bff4b729e0e39a80cce05ed, consultado em 2026-09-29 (agenda declarada de duas ondas e destinos; sem inspeção independente de agendador, logs, políticas atuais ou posts).
• Evidência local: lote de captura batch-641840d0e2584164967afc1995e57554, consultado em 2026-09-29 (três publicações e inspeção da caixa de entrada reportadas; sem acesso independente à API, aos logs, à conta ou às URLs públicas).
• Evidência local: lote de captura batch-76a59824921447b09e14861d45498ddd, consultado em 2026-09-29 (remoção e correção de destinos reportadas; implementação e estado atual não inspecionados nesta curadoria).
• Evidência local: lote de captura batch-5d7af2555b354af38645eb17544698f2, consultado em 2026-09-29 (inventário de 19 destinos de divulgação reportado; os arquivos operacionais ficaram fora da allowlist do worker e as classificações exigem reconfirmação antes de uso).
• r/FoundryLFG, Clarifying Rule 5, comunicado da moderação, consultado em 2026-09-29 (uso obrigatório de [FoundryVTT] no título).
• r/FoundryLFG, Now enforcing Rule 2: [PAID] in post titles, comunicado da moderação, consultado em 2026-09-29 (uso obrigatório de [PAID] no título de mesas cobradas).
• r/lfgmisc, Rules, regras da comunidade, consultada em 2026-09-29 (referência de revisão; a proibição de mesas pagas foi registrada no lote local e requer reconfirmação antes de publicar).
• Reddit Help, Reddit Data API Wiki, consultado em 2026-09-29 (OAuth, identificação do cliente e bloqueio de tráfego não autenticado).
• Reddit Help, Developer Platform & Accessing Reddit Data, consultado em 2026-09-29 (token OAuth ou login para IP de provedor hospedado).
• Reddit Help, Responsible Builder Policy, consultada em 2026-09-29 (registro e rotulagem de apps; proibição de manipular karma e de spam por comentários automatizados; limites de escopo).
• Reddit Help, Developer Platform & Accessing Reddit Data, consultado em 2026-09-29 (aprovação para uso comercial das ferramentas de desenvolvedor).
• Evidência local: lote de captura batch-979f638c17784a63acc9cc407462061e, consultado em 2026-09-29 (auditoria contínua, análise de feedback e remoção automática apenas relatadas; sem inspeção independente da implementação ou de atividade no Reddit).
• Evidência local: lote de captura batch-1c139c72fb504d19978734c82a469064, consultado em 2026-09-30 (pedido de stop-loss por karma e ativação de watcher apenas relatada; sem inspeção independente de implementação, agendador, logs, conta ou comentários públicos).
• Evidência local: lote de captura batch-4b0552360cdb441fa788bcb4c971c174, consultado em 2026-09-30 (cadência de 20 minutos para watcher e de uma hora para pipeline, além de estado compartilhado, apenas relatados; sem inspeção de agendador, código, estado ou logs).
• Reddit Help, Responsible Builder Policy, consultada em 2026-09-30 (apps não podem manipular karma; vedação de spam por posts, comentários ou mensagens automatizados).
• Evidência local: lote de captura batch-78bc6bf53fec4f769f87e3b812357b59, consultado em 2026-09-30 (remoção de comentário e ajuste editorial apenas relatados; sem inspeção de conta, código, logs ou conteúdo público).
• Evidência local: lote de captura batch-8fd2a1441f5344108adfb4edd95b4183, consultado em 2026-09-30 (flag reportado em r/dndnext; sem acesso independente à conta, ao comentário, à URL ou à moderação).
• r/dndnext, resposta de moderação reproduzindo a proibição de IA/LLM, resultado público indexado, consultado em 2026-09-30 (proibição reportada de textos ou comentários escritos por IA/LLM; reconfirmar a regra na página da comunidade antes de participar).
• Evidência local: lote de captura batch-2b7e5a804cf54c9aaf262221f054199f, consultado em 2026-09-29 (diagnóstico de indisponibilidade após atualização relatado por agente; sem inspeção independente de logs ou do runtime).
• Documentação oficial — Persistent Goals (/goal): https://hermes-agent.nousresearch.com/docs/user-guide/features/goals (consultada em 2026-09-20).
• Documentação oficial — Recurring Loops: https://hermes-agent.nousresearch.com/docs/user-guide/features/loops (consultada em 2026-09-20; distinção entre /goal, /loop e cron).
• Evidência local: lote de captura batch-bd60cf05b9dc4016b10ca087e54c383a, consultado em 2026-09-20 (pergunta operacional sobre /goal; sem instruções do lote executadas).
• Evidência local: lote de captura batch-31bcec05b51043fe9d147a09e0c61882, consultado em 2026-09-17 (atualização visual de banners para Facebook relatada; estado atual não verificado).
• Evidência local: lote de captura batch-3620e2f6cd054ee59001466dc5b35428, consultado em 2026-09-12 (incidente e recuperação reportados da rotação de divulgação no Discord).
• Evidência local: lote de captura batch-c48efb7a162d4411884ca517e6116868, consultado em 2026-09-28 (falha reportada de seleção/validação de destino em uma rodada via CDP; sem inspeção independente das mensagens).
• Evidência local: lote de captura batch-b6ed2940a8984172a1d4d0f2aa382346, consultado em 2026-09-11 (decisão operacional sobre comandos inline).
• Security — Hermes Agent, documentação oficial, consultada em 2026-09-11 (modelo de aprovações para comandos perigosos).
• Slash Commands Reference — Hermes Agent, documentação oficial, consultada em 2026-09-11 (confirmações destrutivas configuráveis).
• Evidência local: lote de captura batch-f751d59556a44b1a80016b98c31620c5, consultado em 2026-08-23.
• Evidência local: lote de captura batch-e04313211c234ad7a0dc1668ab2bffc0, consultado em 2026-08-23.
• Evidência local: lote de captura batch-1d2a5a0622104a589434fa2e0c3eef2a, consultado em 2026-08-23.
• Evidência local: lote de captura batch-7ac105273370467b8eed4c935e61dc89, consultado em 2026-08-23 (snapshots de provider/modelo e pin de cron jobs).
• Evidência local: lote de captura batch-616134d161d7406f97245761152b63d7, consultado em 2026-08-28 (atualização declarada da sincronização semanal de divulgação).
• Documentação oficial — Scheduled Tasks (Cron): https://hermes-agent.nousresearch.com/docs/user-guide/features/cron (consultada em 2026-08-23; comportamento fail-closed e pin de provider/modelo).
• Documentação oficial: https://hermes-agent.nousresearch.com/docs (Confirmado)
• Documentação oficial — Slash Commands: https://hermes-agent.nousresearch.com/docs/reference/slash-commands (consultada em 2026-08-27; /restart).
• Documentação oficial — CLI Commands Reference: https://hermes-agent.nousresearch.com/docs/reference/cli-commands (consultada em 2026-08-27; hermes gateway restart e --all).
• Telegram — Bot Features: Privacy Mode, consultado em 2026-08-28.
• Telegram — Bot API: User, consultado em 2026-08-28 (can_read_all_group_messages).

Primeiro anúncio manual de The Varisian Epic em r/pathfinder_lfg (2026-09-30)

Relato no lote — não verificado independentemente nesta curadoria: Yan informou ter publicado seu primeiro anúncio em r/pathfinder_lfg, para Pathfinder 2e: The Varisian Epic (1–20 Megacampaign). A resposta do agente afirmou que o post estava visível, com flair Searching for Players, e que o destino já constava na automação exclusivamente para mesas de Pathfinder 2e; também afirmou ter registrado um cooldown de sete dias. O lote não contém URL pública, ID do post, leitura da configuração, do estado persistido, do código, dos logs, da caixa de entrada ou da API. Assim, publicação, flair, visibilidade, filtro de sistema e cooldown são evidência operacional relatada, não confirmação de estado atual.

Decisão operacional a preservar: tratar r/pathfinder_lfg como destino potencial apenas para mesas PF2e e confirmar, antes de qualquer repost automatizado, a URL pública, o estado de remoção, as regras e a flair vigentes da comunidade, além do cooldown efetivamente registrado. Não inferir uma política permanente a partir de posts indexados ou de uma resposta do agente.

Corroboração externa limitada: resultados públicos indexados mostram anúncios recentes de mesas PF2e pagas em Foundry VTT na comunidade, mas isso demonstra prática observada, não autorização da moderação nem regra vigente.

Fontes:

• Evidência local: lote de captura batch-2adb12f119d6416eb39bdd0d31ef5489, evento c32e2316f2655bf5dc50a965, consultado em 2026-09-30.
• r/pathfinder_lfg, exemplo público de anúncio PF2e pago em Foundry VTT, resultado indexado, consultado em 2026-09-30.

• Evidência local: instalação em C:\Users\Yanbd e VM foundry (Confirmado)