Mestre Arquivista — Pipeline de Sessões

Resumo

Automação interna de arquivamento: gravações de sessão capturadas pelo Craig chegam ao fluxo no n8n, que cria os registros de campanha em RPG/3-Sessions/ no Obsidian.

Incidente de ingestão (relatado em setembro de 2026)

Relatado em operação local: duas falhas independentes interromperam o processamento de sessões:

1. O n8n não conseguiu criar uma pasta de campanha no volume de sessões por falta de permissão de escrita (EACCES). A fila abortou após a prévia da primeira sessão, sem gravar o Markdown nem avançar os demais itens pendentes.
2. A autorização do Craig para o Google Drive expirou. As sessões continuaram gravadas no Discord, mas os arquivos não chegaram ao Drive e, portanto, não acionaram o gatilho do n8n.

Recuperação e decisão operacional

Relatado como correção aplicada:

• O diretório que o container usa para criar sessões recebeu permissão de escrita compatível com a criação dinâmica de pastas de campanha.
• As transcrições pendentes foram obtidas diretamente do Craig, reconstruídas no formato canônico esperado pelo pipeline e reinjetadas para processamento.

Recuperação de falha de upload do Craig (23 de setembro de 2026)

Relatado em operação local; não auditado independentemente: quando o Craig registra uma sessão no Discord, mas falha ao enviá-la ao Google Drive, a recuperação pode contornar o gatilho ausente sem depender de novo upload automático:

1. obter a transcrição disponível diretamente no Craig;
2. montar o arquivo no formato canônico aceito pelo workflow, com metadados de sessão e transcrição;
3. enviar esse artefato à pasta monitorada do Google Drive;
4. iniciar o webhook manual com o payload completo exigido pelo workflow;
5. conferir a prévia e aguardar a aprovação editorial antes da gravação definitiva da nota de sessão.

Esse procedimento recupera a ingestão, mas não comprova por si só que a nota foi criada ou que notificações posteriores foram entregues. Validar cada etapa no destino, sem registrar identificadores de gravação, links privados, credenciais ou dados de participantes.

Correção editorial de registros de sessão

Quando a transcrição ou a síntese atribuir incorretamente nomes de personagens e jogadores, enviar ao campo de alterações/correções do fluxo um mapeamento explícito, sem recontar a sessão inteira:

Corrija a seção Dramatis Personae e as menções no resumo com os nomes corretos dos jogadores e personagens:
 
- Mestre: [nome]
- [personagem]: [jogador]
 
Instruções:
1. No Dramatis Personae, formate exatamente como: * **[Nome do Personagem]:** [Nome do Jogador]
2. Substitua no texto apenas as referências incorretas pelo personagem correspondente.
3. Remova participantes ausentes quando isso for explicitamente informado.
4. Mantenha o restante da estrutura e narrativa intactos.

Decisão operacional: priorizar mapeamento personagem → jogador e substituições pontuais. Isso reduz a ambiguidade de nomes reconhecidos incorretamente na transcrição e limita a alteração ao crédito e às menções afetadas.

Correções fonéticas persistentes

Relatado no lote de conhecimento: o fluxo possui um dicionário fonético por campanha. Para registrar uma correção reutilizável de reconhecimento, informar pares explícitos no formato forma reconhecida -> forma correta (ou =>), em vez de depender apenas de uma instrução narrativa em texto livre.

Nomes a corrigir:
- [forma reconhecida] -> [forma correta]

Esse formato é relatado como entrada para a extração de pares pelo fluxo e posterior aplicação em sessões futuras da mesma campanha. O comportamento deve ser confirmado no workflow antes de qualquer alteração de implementação; esta nota não documenta caminhos internos, credenciais ou nomes concretos de jogadores.

Incidente de entrega pós-processamento (22–23 de setembro de 2026)

Relatado em operação local; não auditado independentemente: o workflow concluiu a síntese de uma sessão de TOR2e e gerou a crônica The Traitor’s Lure, mas falhou no nó de envio pelo WAHA com HTTP 500 e uma exceção relacionada à resolução de chat. Outras duas execuções de 19 de setembro apresentaram a mesma falha nesse ponto. Portanto, a geração do registro e a entrega por WhatsApp devem ser monitoradas como etapas independentes.

No mesmo relato, uma execução posterior falhou antes do processamento no Google Drive Trigger, atribuída a uma credencial OAuth2 inválida ou expirada. A reautenticação da credencial foi reportada como realizada em 23 de setembro; o lote não confirma um reprocessamento bem-sucedido após essa ação.

Sem retroprocessamento automático após reautenticação

Relatado em operação local; não auditado independentemente: em um incidente posterior, uma gravação já havia sido enviada ao Google Drive e o Google Drive Trigger chegou a iniciar uma execução, mas a autorização falhou antes do download e da síntese. Renovar a credencial depois disso não reprocessa automaticamente esse arquivo: o gatilho relatado reage a novas alterações (fileUpdated), não reconstitui eventos que falharam enquanto a credencial estava inválida.

Procedimento de recuperação: depois de confirmar a validade da credencial e que a gravação ainda existe no Drive, acionar uma execução manual do workflow com o arquivo pendente conhecido ou provocar uma nova alteração legítima do arquivo no Drive. Ao final, conferir separadamente a criação do registro de sessão, a etapa de aprovação e a entrega configurada. Não assumir que a simples reautenticação recuperou a gravação nem alterar arquivos já arquivados sem antes verificar duplicidade.

Chamadas manuais ao webhook

Relatado em operação local; não auditado independentemente: uma execução no nó de definição do ID da pasta ocorreu após uma chamada de teste ao webhook sem o payload obrigatório. A interrupção foi o comportamento esperado da validação de entrada, não evidência de falha do fluxo nem da autenticação do Google.

Decisão operacional: não usar requisições vazias como teste de disponibilidade do webhook de reprocessamento. Para validar o fluxo, usar uma gravação pendente conhecida com o payload completo exigido pelo workflow e conferir, ao final, o registro de sessão e a entrega separadamente. Se for necessário apenas testar conectividade, usar uma rota de health check que não inicie o pipeline.

Procedimento de validação

1. Confirmar que o registro de sessão foi criado no destino esperado antes de tratar a falha como perda de processamento.
2. Verificar separadamente o status da entrega pelo WAHA e a existência da mensagem no chat de destino.
3. Após reautenticar o Google Drive, testar o gatilho com uma gravação pendente conhecida e confirmar a execução até o fim, sem duplicar uma sessão já arquivada.
4. Registrar o identificador da execução e o nó de falha no diagnóstico operacional, sem copiar tokens, cabeçalhos ou identificadores privados para o vault.

Atualização de reexecução e entrega (23 de setembro de 2026)

Relatado em operação local; não auditado independentemente: nas execuções de 15 a 20 de setembro citadas no lote, a IA e a gravação da crônica no Obsidian teriam concluído; a falha recorrente teria ocorrido apenas no nó final de envio por WhatsApp, devido a erro interno do WAHA na resolução do chat.

O relato informa que a sessão WAHA foi recuperada e que um teste de envio recebeu resposta HTTP bem-sucedida. Isso não substitui a confirmação no chat de destino nem confirma que as execuções históricas foram reenviadas. Para recuperar uma execução já processada, usar a ação de nova tentativa no n8n e conferir as duas saídas separadamente: registro de sessão existente sem duplicação e mensagem efetivamente entregue. Para uma gravação pendente no Drive, acionar o fluxo manual somente após confirmar a presença do arquivo e a validade da credencial do Google Drive.

Correção de resiliência no envio WAHA (27 de setembro de 2026)

Relatado em operação local; não auditado independentemente: após uma falha HTTP 500 no nó de envio do workflow, atribuída pelo diagnóstico à perda da referência de chat na automação do WhatsApp Web, foram reportadas duas camadas de mitigação:

1. no cliente de automação, tentativa de fechar modal de atualização do WhatsApp Web antes do envio e de restaurar o script de integração quando ele não estiver disponível;
2. no nó de envio do workflow, configuração para continuar o fluxo mesmo se o envio pelo WhatsApp falhar.

A segunda medida isola a entrega de WhatsApp: ela não deve abortar as etapas anteriores de arquivamento e geração do registro de sessão. Não equivale a entrega garantida nem substitui a validação da mensagem no chat de destino. Como a primeira medida altera componentes internos da automação, revalidá-la após atualizações do WAHA/WhatsApp Web e preferir uma correção suportada pelo fornecedor quando disponível.

Verificação da cadeia de entrada (30 de setembro de 2026)

Relatado em operação local; não auditado independentemente: um teste controlado com arquivo de teste na pasta monitorada do Google Drive percorreu o fluxo de ponta a ponta até a etapa de solicitação de aprovação. Os artefatos de teste teriam sido removidos depois. Esse resultado separa a disponibilidade do workflow da disponibilidade das gravações: ele não demonstra que o Craig esteja enviando arquivos normalmente.

No mesmo diagnóstico, não foram encontrados novos arquivos de gravação nas pastas e buscas previstas do Google Drive após a última gravação conhecida. A hipótese operacional passa a ser falha antes do Google Drive Trigger — o Craig pode não ter gravado, pode ter perdido a autorização de upload, ou pode estar enviando a outro destino. Não tratar uma dessas hipóteses como causa confirmada sem conferir a origem no Craig e a integração de armazenamento.

Procedimento de triagem:

1. confirmar no Craig se a sessão foi efetivamente gravada;
2. se houver gravação, verificar o destino configurado e a autorização do Google Drive;
3. somente depois investigar o Google Drive Trigger e o restante do n8n;
4. ao corrigir o envio, validar com um arquivo novo e conferir no destino o registro, a aprovação e cada entrega configurada.

Incidente de disparo e encerramento da execução (29 de setembro de 2026)

Relatado em operação local; não auditado independentemente: uma sessão de Sombras de Merritt foi processada por acionamento manual do webhook, depois que o relato identificou ausência de novos eventos do Google Drive Trigger desde 28 de setembro. A síntese e a gravação do registro de sessão teriam sido concluídas, e o envio final ao Discord teria retornado sucesso.

A execução foi, ainda assim, marcada como erro porque o envio posterior pelo WAHA respondeu HTTP 500. Isso reforça duas distinções operacionais:

1. o status global de erro de uma execução não basta para concluir que a sessão não foi processada ou publicada em todos os destinos;
2. o fluxo de entrada pelo Drive deve ser verificado independentemente do webhook manual, pois este pode recuperar uma sessão específica sem demonstrar que o gatilho voltou a operar.

Ação de diagnóstico: para cada novo caso, conferir a ordem de evidências no destino: evento do Drive, execução iniciada, registro salvo, publicação no Discord e entrega no WhatsApp. Se a execução tiver sido manual, registrá-la como recuperação pontual e continuar investigando o Drive/Craig antes de considerar o incidente resolvido.

Limitações e cuidados

• Tratar falha de ingestão no Drive e falha de escrita no volume como incidentes distintos; uma não substitui a verificação da outra.
• Após qualquer alteração de permissões, validar criação de uma pasta pelo usuário do container e a gravação do Markdown resultante.
• Antes de acionar recuperação manual, confirmar a existência da gravação na origem e evitar duplicar sessões já processadas.
• Correções editoriais devem usar somente os nomes que o responsável pela sessão confirmar; não inferir identidade de jogador a partir da transcrição.
• Não registrar chaves, tokens, cookies ou links privados de recuperação nesta nota.

Relações no vault

• Obsidian — destino dos registros de sessão.

Fontes

• Evidência local: lote de conhecimento batch-c0ad3273ba6f4ba1b0743dc309bdde47, consultado em 2026-09-12. O lote registra o incidente e a recuperação relatados; não é uma auditoria independente do estado atual da infraestrutura.
• Evidência local: lote de conhecimento batch-46eae1a19168401d983664d6953216c2. Registra o modelo de instrução para corrigir créditos de personagem/jogador em uma sessão; os nomes concretos foram intencionalmente omitidos desta nota.
• Evidência local: lote de conhecimento batch-97bba887c85f4bfbb0c2d42b6aa80f4b, consultado em 2026-09-13. Registra o uso relatado de pares reconhecido -> correto (ou =>) para alimentar correções fonéticas persistentes; não constitui verificação independente da configuração atual do workflow.
• Evidência local: lote de conhecimento batch-1317b4678ee74997b5933c9931509981, consultado em 2026-09-23. Registra falhas relatadas de entrega WAHA e de autorização no Google Drive Trigger; o estado posterior da recuperação não foi verificado por esse lote.
• Evidência local: lote de conhecimento batch-d7906d2a8642450a9039bd86fc40b264, consultado em 2026-09-23. Registra que um teste manual sem payload obrigatório acionou a validação de entrada do webhook; não constitui auditoria independente da configuração atual.
• Evidência local: lote de conhecimento batch-2082955b4bb640c99e9680b88cfc11e8, consultado em 2026-09-23. Relata que execuções de 15 a 20 de setembro gravaram as crônicas antes de falhar no envio WAHA e que a sessão foi recuperada; não confirma, por si só, o reenvio histórico nem a presença das mensagens nos chats de destino.
• Evidência local: lote de conhecimento batch-77761840504f4693be12764954c78555, consultado em 2026-09-23. Relata uma falha de autorização no Google Drive Trigger após a gravação já estar disponível e a necessidade de reacionar o fluxo por execução manual ou nova alteração no arquivo; não é auditoria independente do comportamento atual do gatilho.
• Evidência local: lote de conhecimento batch-63a8bcacd3fe407f886b567891b98895, consultado em 2026-09-23. Relata a recuperação de uma falha de upload do Craig por transcrição direta, artefato canônico, upload ao Drive e acionamento manual sujeito à aprovação editorial; IDs de gravação, participantes e demais identificadores privados foram omitidos.
• Evidência local: lote de conhecimento batch-92da071c79864bddaf68449d2263a9d6, consultado em 2026-09-27. Relata uma mitigação no cliente de automação do WhatsApp Web e a configuração do nó de envio para não abortar o workflow; não confirma por si só a entrega de mensagens em produção.
• Evidência local: lote de conhecimento batch-fa371436db554acf83de06b51b77f9b8, consultado em 2026-10-01. Relata que uma sessão de 29 de setembro foi recuperada por webhook manual, com registro e publicação no Discord concluídos, enquanto o envio WAHA HTTP 500 deixou a execução em erro; não é auditoria independente do estado atual do Drive, do Craig ou do WAHA.
• Evidência local: lote de conhecimento batch-f44e8cec0e0840f58c1c442d6969d95e, consultado em 2026-10-01. Relata um teste controlado que percorreu o fluxo iniciado pelo Google Drive até a aprovação e a ausência posterior de novas gravações nas buscas previstas; não confirma qual falha ocorreu no Craig nem o estado atual de suas autorizações.