Changelog

2026-10

• 3.1020.0003 Appointment slots deletable - a grade gravada de hoje a D+6 passa a ser fixa, as 60 posições das 07:00 às 22:00 de cada dia aberto, que toda rodada do create-appointment-slots confere sem ler o marcador, com o expediente só dentro dessa faixa na dash e na set_schedly_business_hour; a migration 2026-10-20-keep-schedly-appointment-slots.sql faz a troca de expediente só remarcar, deixa no lugar o bloco livre dos dois cancelamentos e derruba a policy de delete do authenticated, e nada mais apaga linha de schedly_appointment_slots; aplicar a migration na produção, antes do «deploy all», fica com o dono.
• 3.1019.0125 Changelog depends on vercel - a página pública do changelog passa a ser construída pelo vitepress/scripts/publish.sh no checkout principal da VPS de desenvolvimento e servida pelo Caddy dela em changelog.testenv.tech, sem senha e com Cache-Control: no-cache; o deploy-all.sh e a barra de status largam o projeto dek-changelog da Vercel, e as páginas Changelog de dek-landing, dek-affiliate e dek-super abrem o endereço novo no iframe; ligar o site e recriar o Caddy na VPS de desenvolvimento, antes do «deploy all», fica com o dono.
• 3.1018.1135 Custom days closed - a migration 2026-10-18-widen-schedly-days-closed-to-custom.sql dá a schedly_summaries a coluna custom_days_closed, que o write-days-closed não regrava, e faz a extend_schedly_appointment_slots criar já fechadas, menos o intervalo, as posições novas dos dias dela, como as de days_closed; a página «Dias fechados» (/dias-fechados) da dash do schedly-consumer mostra os feriados nacionais só para leitura e deixa o barbeiro acrescentar e tirar os dias fechados dele, fechando e reabrindo na hora a grade de hoje a D+6; aplicar a migration na produção, antes do «deploy all», fica com o dono.
• 3.1018.1126 Advance day closing - o schedly-consumer perde a página «Dias» (/dias-de-atendimento), o item dela no menu e o ramo do updateBusinessDay que reabria data depois de D+6, e a migration 2026-10-18-trim-schedly-closed-day-to-short-window.sql deixa a data fechada só de hoje a D+6: a book_schedly_appointment para de recusar a posição que falta quando um horário de D+7 a D+44 está marcado «Indisponível», e a set_schedly_business_hour para de refazer, fechar e apagar a data fechada depois de D+6; aplicar a migration na produção, antes do «deploy all», fica com o dono.
• 3.1018.0940 Holiday slots created then closed - a migration 2026-10-18-store-schedly-days-closed.sql dá a schedly_summaries as colunas days_closed e days_closed_write_until_day_key e faz a extend_schedly_appointment_slots criar já fechadas, menos o intervalo, as posições novas dos dias de days_closed, e a atualização n8n/updates/20261018_holiday_slots_created_then_closed/ troca o ramo national-holiday-closing do schedly-appointment-slots por um nó só, o write-days-closed, que grava os feriados nacionais de hoje ao fim de M+1 sem chamar a rota create-appointment-slots, para o feriado nascer fechado ao entrar em D+6; aplicar a migration e depois importar o workflow, na dev e na produção, fica com o dono.
• 3.1017.2231 Advance booking window - a Agenda (/) do schedly-consumer, a grade pré-gerada e as rotas create-appointment-slots e verify-appointment-slots do dek-server passam à janela curta de hoje a D+6, enquanto o seletor do «Agendar» do Resumo e a página «Dias» vão de hoje a D+44 e montam em memória, pelo hydrateAppointmentSlotsDay, os dias abertos que não têm linha no banco; a migration 2026-10-18-shrink-schedly-booking-window.sql faz a book_schedly_appointment gravar em D+7..D+44 só os blocos da reserva, a cancel_schedly_appointment e a cancel_customer_appointments apagarem os blocos livres que liberam a partir de D+7, a extend_schedly_appointment_slots e a set_schedly_business_hour semearem só até D+6, e limpa os livres abertos já gravados a partir de D+7; aplicá-la na dev e na produção, depois da 2026-10-17-keep-schedly-closed-day-on-business-hour.sql e antes do «deploy all», fica com o dono.
• 3.1017.1955 Skychat initial context window - a migration 2026-10-17-restore-schedly-chat-initial-context-window.sql reconcilia a get_schedly_chat_initial_context unindo o teto de Hoje até D+6 em America/Sao_Paulo da 2026-10-16-add-schedly-booking-window.sql à remoção de call_muted_until e placeCallMutedUntil da 2026-10-16-remove-place-call-muted-until.sql, o runbook de docs/services/skychat.md registra que a RPC traz os dias de Hoje até D+6 com horário livre a pelo menos 55 minutos de antecedência no fuso de São Paulo, e aplicar a migration na dev e na produção fica com o dono.
• 3.1017.1938 National holiday closing - o workflow novo national-holiday-closing, em n8n/updates/20261017_national_holiday_closing/, roda às 01:00 e às 04:00 de São Paulo e, quando a D+6 é feriado nacional - os nove de data fixa da lei federal ou a Paixão de Cristo, com a Páscoa calculada na própria query -, leva a grade de cada place com tenant até ela pela rota do create-appointment-slots e fecha todo horário livre da data pela regra da página «Dias», sem tocar reserva nem intervalo; a rodada das 04:00, depois do dek-monitor, fecha a place em que a rota falhou às 01:00; importar e publicar o workflow na dev e na produção fica com o dono.
• 3.1017.0746 Advance day closing - a página «Dias» do schedly-consumer, no menu depois de «Horários», abre e fecha num toque cada data da janela de hoje a D+45 num UCalendar, pelo gravador do switch «Dia aberto/Dia fechado» da Agenda, que passa ao useHAppointmentSlots e registra business_day_updated no sucesso e business_day_update_failed com o contexto na falha; a migration 2026-10-17-keep-schedly-closed-day-on-business-hour.sql refaz a set_schedly_business_hour para que o horário novo e o que deixa de ser intervalo nasçam fechados na data fechada, e aplicá-la na dev e na produção, depois das duas de 16/10, fica com o dono.
• 3.1017.0623 Dek logs event context - a migration 2026-10-16-structure-dek-logs-event-context.sql esvazia o dek_logs e passa a exigir event como identificador, message como resumo de até 900 caracteres e meta como objeto com a flag is_allowed_customer_viewing, sem fallback para o formato antigo, com a busca do get_dek_logs lendo também o evento e o meta, sem curinga; Skychat, apps Nuxt, dek-server, dek-logs-read, os scripts do evogo-watchdog, do n8n-runners-watch e do dek-backup e os workflows dek-monitor, dek-login, dek-reminder, get-prospect-message e dek-voice-call, em n8n/updates/20261016_dek_logs_monitor_context/ e n8n/updates/20261016_dek_logs_business_context/, gravam evento, resumo e contexto, e as telas de logs do dek-super e do consumidor mostram o resumo inteiro e expandem o meta; a virada coordenada - parar a emissão antiga, aplicar a migration, o rebuild do skychat, instalar os scripts, publicar os workflows e o «deploy all» - e o acesso do Log Meta Status ao Supabase ficam com o dono.
• 3.1016.1950 Advance booking - o «Agendar» do Resumo do schedly-consumer abre a escolha de dia e horário de hoje a D+45 em São Paulo e leva ao formulário da Agenda, que reserva pela book_schedly_appointment com a tentativa como identidade e relê a agenda antes de dizer sucesso, e o cancelamento vai pela cancel_schedly_appointment; a migration 2026-10-16-add-schedly-booking-window.sql dá à schedly_appointment_slots a guarda que só deixa a reserva mudar pelas RPCs e recusa reserva sobre reserva, o meta recalculado pelo banco em toda escrita, a extend_schedly_appointment_slots e a set_schedly_business_hour, e o teto de Hoje a D+6 na get_schedly_chat_initial_context e na gravação do chat; a agenda carrega a janela inteira em páginas, ouve inserção, alteração e remoção da place e vira o dia sozinha, e as rotas create-appointment-slots e verify-appointment-slots do dek-server estendem e conferem a grade até D+45 em lotes, com 500 na falha; a migration na dev e na produção, depois da do monthly, e o «deploy all» ficam com o dono.
• 3.1016.1947 Token create signs any user - o POST /token/create do dek-server deixa de assinar o id, o tipo e o prazo que o corpo manda e recebe só a prova: o código de acesso, que ele confere no /verify-access-code do dek-login, no login e no cadastro, ou o link da demo, cujo claim_demo ele roda pela service role; o sub, o type e o exp do JWT saem da linha de users que a prova encontra, com 30 dias, ou do fim da visita, e o cadastro grava a linha no servidor antes de assinar; saem o POST /supabase/check-is-new-user, que devolvia a linha de users pelo telefone, e o POST /supabase/user-create; as sessões já emitidas valem até o exp, e o «deploy all», do servidor e dos apps juntos, fica com o dono.
• 3.1016.1714 Voice call confirmation silences other requests - o dek-voice-call passa a ignorar o telefone confirmado por 30 minutos no Redis, inclusive em pedidos de outros clientes, preservando as cinco religações a cada cinco minutos e a recusa de callbacks inválidos; modelo, perfil e indicador deixam de usar o prazo de ligações, e a migration 2026-10-16-remove-place-call-muted-until.sql retira call_muted_until do contexto, da tabela e do seed, preservando o controle manual e as notificações; publicar o workflow e o client, aplicar a migration depois de terminarem as execuções antigas e conferir o TTL no destino ficam com o dono.
• 1.1016.0500 Monthly service reports - o schedly-consumer ganha a /relatorios, com o item «Relatórios» no menu, que mostra, em um mês ou em três, as Entradas - a soma do preço da reserva dos atendimentos concluídos, no mês do atendimento em São Paulo - e a quantidade por serviço, em barras e na tabela «Serviços executados», e a lista «A concluir» e «Concluídos», em que o dono conclui, desfaz e informa o valor da reserva antiga; a migration 2026-10-16-add-schedly-appointment-slots-solve.sql faz a schedly_appointment_slots guardar o nome e o preço do serviço na reserva e o instante da conclusão, recusar alterar ou excluir o concluído fora da demo e ganhar a set_schedly_appointment_solved e a get_schedly_service_report, e a agenda passa a ler só de hoje em diante, em páginas; a migration na dev e na produção e o «deploy all» ficam com o dono.
• 1.1015.2012 Skychat attending not on consumer layout - o Skychat grava, a cada turno do agente, pela set_schedly_chat_presence da migration 2026-10-15-create-schedly-chat-presences.sql, até quando a conversa segue em atendimento, agora mais 600 segundos na que fica à espera e agora na que fechou, numa linha por place e telefone da schedly_chat_presences, que só o dono da place lê e a supabase_realtime entrega; o CWhatsappConnection do schedly-consumer troca o robô verde pelo i-lucide-bot-message-square pulsando, com o título «Assistente atendendo no WhatsApp», enquanto alguma conversa da place não venceu, e a escrita que falha deixa a skychat_presence_failed sem segurar a resposta; a migration na dev e na produção, o rebuild do skychat e o «deploy all» ficam com o dono.
• 1.1015.1904 Skychat future slots not offered - a get_schedly_chat_initial_context, pela migration 2026-10-15-widen-schedly-chat-initial-context-days.sql, passa a trazer todos os dias futuros com horário livre, sem o fim da janela em D+5 nem o corte nos três primeiros, e o «Agendar para qual dia?» do Skychat oferece os três primeiros dias em que o plano cabe, «Hoje» e «Amanhã» pelo nome e os outros com o dia da semana e a data, como «Terça-feira, 20/10»; o Context Guard deixa no fluxo natural, com reason=no_free_slots, a mensagem fora de conversa em andamento quando o contexto não traz nenhum horário livre, sem armar nem desarmar o relógio do agente, e a aplicação na produção e o rebuild do skychat ficam com o dono.
• 1.1015.1728 Evogo leftover qr client after pairing - o ramo Pair do schedly-consumer-whatsapp, na atualização n8n/updates/20261015_pair_waits_connected_client/, só pede o código de pareamento ao Evogo depois que o GET /instance/status responde Connected para o cliente que o POST /instance/connect subiu, com até cinco esperas de 1 s, e o Pair do Evogo reaproveita esse cliente em vez de subir um segundo cliente de QR, o que sobrava do pareamento e tomava o lugar do logado; no fim das cinco esperas o ramo segue para o pair como antes, o contrato do whatsapp-login não muda, e o import na bancada e a aplicação na produção ficam com o dono.
• 1.1015.1644 Voice call outcome not in dek logs - o dek-voice-call ganha, na atualização n8n/updates/20261015_voice_call_outcome_logs/, o nó log pressed, depois da resposta do stop-voice-call ao Twilio, e o log loop ended, na saída falsa do If retry, que gravam em dek_logs as linhas dek-voice-call pressed place=<slug> e dek-voice-call loop ended place=<slug> reason=<motivo>, com o motivo pressed ou max-retries e a place pelo slug, nunca pelo telefone; o pedido, as religações e o silenced seguem sem linha, e o import na bancada e a aplicação na produção ficam com o dono.
• 1.1015.1634 Evogo instance webhook unchecked - o evogo-watchdog, em toda rodada que mede as conexões do evogo_auth, confere antes as instâncias schedly- conectadas do evogo_users e grava em dek_logs, só com o nome, uma linha warn evogo-watchdog webhook fora do padrão na instância <nome> para cada uma com webhook diferente de http://skychat:3000/webhook/schedly-input ou events sem MESSAGE; a linha não reinicia o evogo e fica fora do evogo_percentage_max, a consulta que falha não encerra a rodada, e o git pull do checkout principal de cada VPS, que leva a conferência ao cron, fica com o dono.
• 1.1015.1131 Skychat wait click left to silence - o toque num «aguardar» da última oferta do Skychat, o Aguardar o <nome> da saudação ou o Prefiro aguardar o <nome> do «Não entendi» e do stale_click_options, deixa de falhar o turno e segue ao nó novo specialist_awaited, que diz que uma nova mensagem reinicia o atendimento automático e fecha a conversa; a resposta dele que o Evogo aceita pede a ligação ao dek-voice-call logo depois, sem a linha skychat_agent_silent, e o relógio de 30 s fica para o silêncio; o n8n não muda, e o build do Skychat nas duas VPS fica com o dono.

• 1.1014.22221 Skychat silent agent without voice call - o Skychat ganha o relógio do agente, ao lado do relógio do remetente: a mensagem que o Context Guard libera arma 30 s, que a resposta aceita pelo Evogo e o agent_inactive desarmam, e o silêncio deixa a linha skychat_agent_silent e um pedido por episódio ao webhook request-reply-whatsapp do dek-voice-call, com o places.phone que a RPC do guarda traz e o N8N_WEBHOOK_TOKEN do skychat/.env; o n8n não muda, e o token em cada VPS, o dek-voice-call publicado na bancada e o build do Skychat ficam com o dono.
• 1.1014.16199 Manual whatsapp disconnect not in dek logs - o toggle do WhatsApp em Configuração → Editar, no ConsumerExtension.vue da schedly-consumer, passa a gravar em dek_logs, logo depois do logout que deu certo, a linha warn «WhatsApp desconectado manualmente.» do dek-client, com o tenant_id da instância no Evogo; o logout que falha e a queda pelo celular ou pelo nosso lado seguem sem essa linha, e o «deploy all» dos apps e a conferência na dash da dev ficam com o dono.
• 1.1014.92241 Evogo auth connections leak - o build do Evogo 0.7.2 ganha o evogo-auth-db-pool.patch, e o StartClient passa a montar a sessão do WhatsApp sobre o pool do evogo_auth aberto no boot da API, com 25 conexões no máximo, em vez de abrir um pool novo a cada conexão, que prendia duas conexões até o reinício; a imagem passa a evogo:0.7.2-whatsmeow-1235-9a4bd9b-auth-pool, o watchdog e o reinício das 04:00 não mudam, e a aplicação nas duas VPS e a contagem do watchdog ficam com o dono.
• 1.1013.35621 Skychat template click ignored - o leitor do Skychat segue a lista do detector do Evogo fixado no build e passa a ler o clique do template, em templateButtonReplyMessage.selectedID, ao lado do legado e do nativo no wrapper Go, lidos em sequência; o formato plano deixa de ser lido e o ButtonClick adicional continua ignorado, e o build nas duas VPS e a confirmação no aparelho ficam com o dono.
• 1.1013.28888 Skychat native click ignored - o leitor do Skychat reconhece o clique nativo com o wrapper Go serializado pelo Evogo e conserva o formato plano e o legado, recusando respostas interativas inválidas ou ambíguas antes de ler texto; o ButtonClick adicional continua ignorado, e a aplicação do build nas duas VPS e a confirmação no WhatsApp ficam com o dono.
• 1.1013.25276 Skychat real chat not on turn map - entrega o build local do Evogo 0.7.2 com o patch whatsmeow #1235 fixado e as opções de texto do mapa em respostas rápidas nativas, preservando rótulos, rodapé e referências; o Skychat lê o clique nativo e o legado sem processar o ButtonClick duplicado, e registra a recusa HTTP com status e motivo seguro; a aplicação nas duas VPS começa pelo Skychat atualizado e depois pelo build do Evogo, pelo dono, que confere a entrega no aparelho e o agendamento na conta Business e na conta comum.
• 1.1010.22635 Skychat combo not booked alone - a categoria ganha, no formulário do schedly-consumer-sky, o switch «Combo», gravado na coluna nova schedly_categories.is_combo, e o selo «Combo» na página de categorias; no Skychat, o primeiro combo, pela ordem da prioridade, abre a conversa no «O plano é agendar…?», sem o «Sim 🙂, mas quero +1 serviço», e vai sozinho no plano - com combo no plano, nenhum outro serviço entra, e com serviço avulso no plano, nenhum combo é oferecido -, e a get_schedly_chat_initial_context passa a levar o category_is_combo de cada serviço e a ordenar os serviços da maior priority à menor, o que muda a ordem das ofertas em todo place que definiu prioridade; a migration 2026-10-10-add-schedly-categories-is-combo.sql está aplicada na dev, o skychat da dev chega pelo docker compose up -d --build do dono, e a produção recebe do dono a migration, conferido o md5 da função, o build do Skychat e o «deploy all» dos apps, nessa ordem.
• 1.1008.96785 Skychat stale click unanswered - o toque num botão que não é da última oferta deixa de falhar calado no Skychat: com a conversa à espera, numa oferta com algum botão ou num ai_turn, ele recebe o «🤔 Não entendi...», cujo «Sim, quero continuar ✨» volta ao que estava à espera; sem espera - a conversa nova, a fechada, a que o relógio de 600 segundos esqueceu, a que o restart levou e a da oferta vazia -, ele recebe o nó novo stale_click_options, «Esse botão não vale mais, e o toque não foi registrado», com «Sim, quero reiniciar», que segue como o «Atendimento Automático ✨» da saudação, Prefiro aguardar o <nome>, calado como os outros dois «aguardar», e «Prefiro encerrar esta conversa», que, como o do «Não entendi», passa a responder «💬 Ok, ficamos à disposição. Até breve! 👋!»; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1007.05058 Skychat text instead of click restarts chat - o texto que o cliente manda onde o Skychat espera um clique, em qualquer oferta de botões, também na saudação, deixa de recomeçar o agendamento no «oi» e recebe «Não entendi. Quer continuar com o Atendimento Automático?», com «Sim, quero continuar ✨», que repete a pergunta interrompida com os mesmos botões, Prefiro aguardar o <nome>, com o primeiro nome do especialista, que falha o turno sem resposta como o «Aguardar» da saudação, e «Prefiro encerrar esta conversa», que responde «Conversa encerrada. Até breve! 👋» e fecha a conversa; o texto no próprio «Não entendi» o repete sem perder a pergunta de antes, o do «Qual o seu nome?» e do «Qual é o melhor horário para você?» segue como resposta, e o botão antigo, com o «Não entendi» à espera, falha como todo clique fora da última oferta; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1007.79161 Voice call fires for barber debug - o dek-voice-call da atualização n8n/updates/20261007_voice_call_barber_debug/ deixa de ligar pela Twilio para a place de slug barber-debug, qualquer que seja o chamador do webhook request-reply-whatsapp, e no lugar da ligação grava em dek_logs a linha dek-voice-call skipped place=barber-debug, com service n8n, type info e sem o telefone, e responde 204 com o error nulo, sem armar as repetições de 5 minutos; as outras places seguem recebendo a ligação, nada muda no client, e a atualização, que leva junto a troca do Gather do 20261007_voice_call_stop_on_host e entra no lugar dele ou depois dele, nunca antes, chega a cada n8n quando o dono a importa, com o dek-voice-call anterior arquivado.
• 1.1007.32872 Skychat chat sessions retained - a conversa do Skychat que fica 600 segundos sem mensagem do cliente sai da memória do processo e recomeça no «oi»: cada texto ou clique que o webhook decide responder reinicia o relógio da conversa, e o vencimento esquece a sessão, sem aviso ao cliente, e deixa a linha skychat_session_reset no stdout e em dek_logs; o botão de antes do reset falha como todo clique fora da última oferta, o áudio, a foto e a figurinha não reiniciam o relógio, e o stop do container não espera por ele; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1006.15937 Skychat services options not on turn map - o «O plano é agendar…?» do Skychat volta a oferecer, ao lado do «Sim 😁, este é todo o plano», o «Sim 🙂, mas quero +1 serviço» e o «Não 🫥, eu tenho outro plano» do chat legado: os dois abrem uma oferta de até três serviços, sem os escolhidos, os recusados e os da categoria de um escolhido, e o plano de mais de um serviço segue por «O plano é agendar A + B?» até o «Agendado!», com os dias e os horários contando a soma das durações e todos os ids no p_service_ids do create_appointment; o botão que levaria a uma oferta de serviço vazia sai da pergunta; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1006.01072 Skychat name refusal not on turn map - o «Não» do «Confirma os dados abaixo?» do Skychat deixa de falhar o turno sem resposta e pergunta de novo «💬 Qual o seu nome?»: o select_name_02 ganha no mapa o próprio next_turn, ai_turn.name_resolve, e sai da offPath do router, e o nome respondido depois toma o lugar do recusado no «Nome:» e no create_customer, quantas vezes vier; o «Aguardar» segue falhando o turno; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1006.82479 Skychat cancel or reschedule not on turn map - o Skychat pergunta ao cliente com horário marcado a partir de agora «Você já tem horário marcado. O que quer fazer?», entre o get_customer e o service_options do mapa: o «Cancelar?» cancela todos esses horários pela cancel_customer_appointments e se despede, o «Remarcar?» os cancela e segue ao serviço, e o «Outro atendimento?» segue sem cancelar; o botão do mapa ganha o próprio next_turn, e o agent_turn que fica com a oferta vazia segue calado o on_fail_turn; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1006.78690 Skychat sign up without line breaks or phone - o «Cadastro» do Skychat chega em quatro linhas, com o \n do JSON no lugar do /n no text_output do name_options, e traz depois de «Telefone:» a variável phone nova, o número de quem escreve só em dígitos, o mesmo que o «Sim» grava pelo create_customer, com 5511999990000 no rascunho; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1005.33623 Dek docs architecture map unused - o dek-docs deixa de publicar o mapa da arquitetura, vazio desde 04/10/2026: saem o architecture-map.html, a página /architecture que o sync gerava com o iframe dele, o layout, o CSS e o registro no tema, e o botão e o item da home, que fica só com o «Abrir quadro»; o pnpm format volta a sair 0, e o docs.testenv.tech só perde a página no publish.sh do dono.
• 1.1005.32016 Skychat sender phone not in dek logs - as linhas skychat_* do Skychat, no docker logs e em dek_logs, passam a levar o remetente só mascarado: o pushName com as duas primeiras letras e ***, como Fá***, e o pushPhone novo, com *** e os quatro últimos dígitos do Sender, sem o dispositivo, como ***4321, ausente quando o Sender chega em @lid; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1005.20529 Skychat real chat not on turn map - o chat real e o rascunho do Skychat passam a andar pelo turn-map.json novo, só com agent_turn, ai_turn e rpc_turn, do «oi» ao «Agendado!»: o mapa ganha os next_turn do caminho feliz, o 💬 Agendar para qual dia? e o get_customer_by_phone, os botões de dia são hoje, amanhã e depois de amanhã, só os que têm horário livre, o «Aguardar» e o «Não» falham o turno, e a imagem volta a se construir; a entrega chega ao skychat da dev pelo docker compose up -d --build do dono e não sobe na produção.
• 1.1004.37029 Skychat real chat not on turn map - o webhook do Skychat troca o hello world pelo turn-map.json, do «oi» ao «Agendado!»: lê o texto e o clique do humano, tira do contexto que o Context Guard já lê a place, o especialista, o primeiro serviço e os horários livres que o comportam, cria o cliente e o agendamento pelas RPCs get_customer_by_phone, create_customer e create_appointment e manda os botões pelo /send/button do Evogo; a falha do turno vira skychat_turn_failed, sem resposta, e só a dev roda a entrega - a produção segue no hello world até o build do dono.
• 1.1003.57078 Backlog card new format - o card passa a ter App dek ou schedly e as seções Testes já efetuados e Testes obrigatórios no lugar do Como testar e do Tested, no guarda, no README, nas skills e no quadro, que tira o selo das duas seções; os 97 cards antigos migram sem perder item nem trocar o Updated.
• 1.1003.56780 Auditor needs card in done - o backlog-auditor passa a achar o card em doing/ pelo PRD que o merge da entrega modificou, arquiva os PRDs, leva o card a done/ com a linha do changelog e só então escreve o teste do dono; o executor e o solver abrem o PR com o card em doing/, sem esperar o backlog-finish, e o hook do scribe reconhece a entrega pelo PRD modificado e manda seguir para o auditor quando não há o que documentar.
• 1.1002.85296 Skychat draft breaks on turn map - o chat de rascunho do Skychat, node src/turn-draft.ts, deixa de morrer no primeiro clique e anda o turn-map.json do «oi» ao «Agendado!» pelo nome das rotas, só na linha reta do agendamento, com o serviço Corte, dados de mentira e tudo em memória; o clique fora da última oferta e o nó sem caso no decide passam a ser erro, sem fallback.
• 1.1002.72845 Skychat not in dek logs - o Skychat passa a gravar em dek_logs, com o serviço skychat e o env do DEK_ENV que o skychat/.env ganha, cada evento skychat_* e o incoming request do webhook, com pares como messageId=<id> e reqId=<id> na message para o --search achar a conversa, e segue logando no stdout; o container da dev grava a partir do próximo build do dono, e o da produção, a partir do próximo espelho.
• 1.1002.48016 Dek docs depends on vercel - o site de docs deixa de ser publicado pela Vercel: vitepress/scripts/publish.sh o constrói no checkout principal da VPS de desenvolvimento, chamado pelo «deploy all» no lugar do deploy hook, e o Caddy de lá o serve em docs.{$DEK_DOMAIN} atrás de basic_auth, com o cookie dek_docs_auth de 400 dias, enquanto o projeto dek-docs da Vercel fica parado até o dono apagá-lo.
• 1.1001.89372 Dek monitor watchers not logged by name - o container n8n só sobe com DEK_ENV PROD ou DEV, a regra dos scripts do host: com outro valor ele sai com DEK_ENV deve ser PROD ou DEV em n8n/.env antes de o n8n subir, em vez de cada nó que lê o valor falhar no cast para dek_log_env_enum.
• 1.1001.83466 Dek monitor watchers not logged by name - a atualização 20261001_dek_monitor_logs_by_name faz os quatro schedules do dek-monitor gravarem em dek_logs com o próprio nome em service - ntfy-check, create-appointment-slots, appointment-slots-check e truncate-dek-logs -, event cron e o env do DEK_ENV, com os quatro nomes no dek_log_service_enum e no dekLogServiceEnum.
• 1.1001.79127 Truncate dek logs not in dek monitor summaries - a atualização 20261001_truncate_dek_logs_summary faz o ramo das 04:00 do dek-monitor gravar na linha do dia de dek_monitor_summaries truncate_dek_logs_success, true quando o delete de dek_logs roda sem erro e false quando falha, e a falha do delete deixa de parar a execução.
• 1.1001.70090 Appointment slots not in dek monitor summaries - a atualização 20261001_appointment_slots_summary faz o dek-monitor gravar na linha do dia de dek_monitor_summaries create_appointment_slots_success e create_appointment_slots_at no fim do ramo das 03:00 e appointment_slots_complete no fim do das 05:00, e a chamada de criação que falha vira false em vez de parar a execução.
• 1.1001.67772 Appointment slots card shows completeness - o card «Slots de Agendamentos» do Monitor fica só com «Criação de horários» e «Execução», sem a linha «Horários completos»; o model e a coluna appointment_slots_complete seguem intactos.
• 1.1001.64990 Monitor maintenance card mixed - o card «Manutenção» do Monitor vira «Backup», «Logs» e «Notificações», e o «Backup» pinta o tamanho de verde abaixo de 100 MB e de aviso no limite, acima dele ou na falha, com a linha «Limite» embaixo.
• 1.1001.64434 Done column buries untested cards - a coluna done do quadro do dek-docs abre pelos 20 cards mais recentes, com um «more» no fim da lista para os demais, e o tested: false sai em pílula de alerta, não mais no cinza do true.
• 1.1001.63501 Evogo usage limit not on monitor - o card Evogo do Monitor ganha a linha «Limite» com 70% fixo e pinta o «Pico de uso» de verde abaixo dele e de aviso no limite ou acima, como o card N8n faz com as falhas dos runners.
• 1.1001.62175 Evogo percentage unused - o model e o Monitor deixam de ler a coluna evogo_percentage de dek_monitor_summaries, que nenhum script nem workflow grava, e a migration 2026-10-01-drop-dek-monitor-summaries-evogo-percentage.sql a tira do schema, para o dono aplicar à mão.
• 1.1001.61161 Evogo auth size column unused - a coluna evogo_auth_size sai de dek_monitor_summaries, do model e da tela do dek-super.
• 1.1001.57640 Dek super home and logs - Monitor passa a abrir na página inicial do dek-super, e a antiga Home vira Logs em /logs, com o menu nessa ordem.

2026-09

• 1.930.91113 Dek backup response not recorded - o dek-backup passa a rodar às 02:30 de São Paulo e registrar a resposta da rodada em dek_logs e dek_monitor_summaries.dek_backup_size, com o tamanho dos seis pacotes enviados ou a etapa e o status da falha.

• 1.930.83835 Appointment slots not per environment - o dek-server atende /dek/production/* e /dek/development/*, cada caminho com o Supabase da sua bancada, e a atualização 20260930_appointment_slots_per_env faz o dek-monitor chamar o caminho da bancada que o dispara.

• 1.930.79171 Ntfy check not in dek monitor summaries - a atualização 20260930_ntfy_check_summary faz o ntfy-check do dek-monitor gravar em dek_monitor_summaries.ntfy_check_success, depois do Notify Affiliate, true no sucesso e false na falha do teste diário ao afiliado.

• 1.930.66252 Schedly flows not in dek monitor - a atualização 20260930_schedly_flows_in_dek_monitor leva para o dek-monitor os três schedules do schedly, a criação de slots às 03:00, a limpeza de dek_logs às 04:00 e a verificação de slots às 05:00, e a produção arquiva o schedly ao aplicá-la.

• 1.930.61455 Dek monitor summaries named watch - a tabela dek_watch_summaries passa a se chamar dek_monitor_summaries, com a migration do rename, o model dekMonitorSummarySchema e a atualização do dek-monitor, cujas duas queries gravam no nome novo.

• 1.930.33743 Evogo percentage max not in dek watch summaries - o dek-monitor ganhou o evogo-percentage-summary, um schedule diário às 06:45 que grava em dek_watch_summaries.evogo_percentage_max o maior percentual de conexões do evogo_auth das 24 horas anteriores.

• 1.929.17105 Backlog card visuals - cards do quadro com mais respiro, título em destaque e metadados discretos nos temas claro e escuro.

• 1.929.12261 N8n runners watch logged as n8n runners - o n8n-runners-watch.sh grava em dek_logs o service n8n-runners-watch, o nome do watcher, no lugar de n8n-runners, o do container, com o rótulo renomeado no dek_log_service_enum e no dekLogServiceEnum e o summary do dek-monitor contando o nome novo.

• 1.929.11082 Evogo watchdog runs not in dek logs - o evogo-watchdog.sh voltou a gravar em dek_logs toda rodada que mede as conexões do evogo_auth, info abaixo do limite e warn no limite ou acima, com o service evogo-watchdog, valor novo do dek_log_service_enum e do dekLogServiceEnum.

• 1.929.10078 Docs folders not in dek docs menu - cada subpasta de docs/ virou item do menu do dek-docs sozinha, sem lista escrita à mão: monitor e tools entraram no menu do topo, e o toPageRelativePath saiu do fluxo do site.

• 1.929.03517 Dek docs sync só em Markdown - o sync e os menus usam a mesma allowlist de docs/ e backlogs/, sem páginas de migrations SQL.

• 1.929.00679 Dek docs scope limited to docs - o sync geral de Markdown publica docs/ e mantém backlogs/ com os menus dedicados.

• 1.929.00326 Dek logs travels in snapshot - o db-snapshot-pull ganhou a quarta fase, truncate public.dek_logs depois do data.sql, para a dev recomeçar só com o que ela grava em vez de carregar as linhas de dek_logs da produção.

• 1.929.96300 Monitor docs off summary model - os sete docs de docs/monitor/ dizem, no comentário do rascunho do dono, o campo do model do resumo que o watcher escreve, com o nome camelCase de dekWatchSummarySchema.

• 1.929.95445 Dek watch summaries model - layers/dek-shared ganhou dekWatchSummarySchema, o Zod schema das 14 colunas de dek_watch_summaries, no padrão de schedlySummarySchema, para servir de contrato quando o primeiro watcher for implementado.

• 1.929.94541 Fix dek watch summaries new watcher columns - dek_watch_summaries ganhou os nomes booleanos pedidos: truncate_dek_logs_success e create_appointment_slots_success, antes text como _result, e appointment_slots_complete, antes appointment_slots_is_complete, já aplicados na instância de desenvolvimento.

• 1.929.94187 Monitor docs on revised draft - docs/monitor/ passou a seguir o draft oficial do dono, de sete watchers e dois summaries: o n8n-runners-check virou n8n-runners-watch, o nome que o script e o cron já têm no host, os dois docs watch-* saíram, e cada summary passou a ser o rascunho comentado no doc do watcher de que lê.

• 1.929.93064 Dek watch summaries new watcher columns - dek_watch_summaries ganhou seis colunas para o novo fluxo dos watchers: n8n_runners_success, evogo_percentage, evogo_percentage_max, ntfy_check_success, create_appointment_slots_result e truncate_dek_logs_result, todas anuláveis e sem default, já aplicadas na instância de desenvolvimento.

• 1.929.91366 Crons and watchers docs on first draft - docs/monitor/ passou a seguir o draft revisado do dono, de nove itens: o watch-appointment-slots-is-complete virou o cron appointment-slots-check, os rascunhos watch-dek-backup-size e watch-create-appointment-slots saíram, e os três itens sem implementação comentam o item novo.

• 1.929.83280 Crons and watchers docs scattered - os crons e watchers passaram a ter um doc cada em docs/monitor/, com o índice deles, e n8n.md, evogo.md, service-backups.md e ambientes.md ficaram com o título e o link; os cinco itens do rascunho do dono sem implementação estão comentados.

• 1.929.79212 N8n runners unchanged state not in dek logs - o watcher do n8n-runners passou a gravar em dek_logs uma linha em toda rodada, info com o container de pé e warn sem ele, com service n8n-runners e sem o marcador de estado - já na desenvolvimento, e na produção depois da migration aplicada no Supabase de lá, do deploy dos apps e do git pull do checkout.

• 1.928.28429 Evogo watchdog not in dek logs - o evogo-watchdog deixou de gravar verificações de conexão em dek_logs, sem mudar medições, agenda, registro no journal ou comportamento de reinício.

• 1.928.20166 Service backups does more than backup - o dek-backup passou a só gerar, cifrar e enviar os pacotes: cada unidade escreve só os artefatos do seu serviço, qualquer comando que falha encerra a rodada sem enviar nada, e o repositório de backups recebe, por push --force, um commit sem pai só com os sete pacotes mais novos de cada serviço, sem a linha n8n-backup em dek_logs, sem o README.md com a tabela de tamanhos, sem a trava de domínio e sem o salto 75 - na produção, depois do git pull do checkout de lá.

• 1.928.00235 Dek watch summaries not in db - o banco ganhou dek_watch_summaries, o resumo diário dos watchers, com uma linha por day_key no formato AAAA_MM_DD e as colunas n8n_runners_failed, evogo_auth_size, dek_backup_size, create_appointment_slots_at e appointment_slots_is_complete nulas até cada escritor medir, com RLS ligado e sem policy - já na instância de desenvolvimento, e na de produção depois da migration aplicada no Supabase de lá -; nada ainda lê nem grava a tabela.

• 1.928.99604 Dek logs origin reported as n8n - dek_logs ganhou em service os valores evogo, ntfy, schedly, service_backups, supabase, dek_docs e chatwoot, e em event o cron, no banco e no Zod, e cada escritor por agenda passa a gravar o serviço de que fala, com event cron - o evogo-watchdog em evogo, o dek-backup em service_backups, o n8n-runners-watch em n8n e a linha de health do schedly em schedly -, depois da migration aplicada no Supabase de produção, do deploy, do pull dos checkouts principais e da importação de n8n/updates/20260928_dek_logs_origin/; a ponte de source, cujo trigger ficou sem a coluna e fazia todo insert falhar, saiu pela contração 2026-09-28-retire-dek-logs-source-bridge.sql.

• 1.928.90932 Dek logs service named source - a coluna source de dek_logs passou a se chamar service, com o tipo dek_log_service_enum, o p_service das RPCs, o --service do leitor e o DekLogService do código, e os apps, o dek-server, os três scripts de host e os quatro workflows de produção passam a gravar e ler o nome novo depois do deploy, do pull dos checkouts principais e da importação de n8n/updates/20260928_dek_logs_service/, com a migration aplicada antes no Supabase de produção; uma coluna source espelhada por trigger e o p_source do get_dek_logs ficam de ponte até o último escritor antigo sair.

• 1.928.90160 Evogo watchdog every five minutes - o evogo-watchdog passou a verificar as conexões do evogo_auth a cada 30 minutos, em :00 e :30 UTC, e não mais a cada cinco, sem mudar o que cada rodada mede, grava ou reinicia: são 48 linhas por dia em dek_logs em cada VPS, no lugar de 288; a VPS de desenvolvimento já roda no horário novo, e a de produção passa a rodar depois que o dono trocar o crontab do production.

• 1.928.66923 Gitignore inverted format - o .gitignore da raiz passou a ser a lista do que fica fora do Git, sem as 42 entradas ! que não liberavam nada desde a saída do /* e sem o par do .vscode/settings.json, ignorando os mesmos caminhos de antes, e o comentário do list-markdown.mjs deixou de chamá-lo de whitelist.

• 1.928.63276 Evogo watchdog below threshold not in dek logs - o evogo-watchdog passou a gravar em dek_logs uma linha a cada verificação que mede as conexões remotas do evogo_auth, info abaixo de 70% do máximo e warn de 70% para cima, pela mesma comparação que decide o reinício, que não mudou; as duas VPS passam a gravá-la depois do pull do checkout principal.

• 1.928.57514 Backup sizes not in readme - o dek-backup passou a reescrever, a cada rodada que publica, o README.md da raiz do repositório de backups: uma tabela com uma linha por rodada, a mais nova embaixo, e uma coluna por serviço com o tamanho do pacote em MB, só as sete rodadas mais novas, sem derrubar a rodada quando a tabela falha; a VPS de produção passa a escrevê-la depois do pull do checkout principal.

• 1.927.44081 Evogo watchdog not in dek logs - o evogo-watchdog passou a gravar em dek_logs uma linha warn, com o prefixo evogo-watchdog e o motivo do journal, a cada verificação que acha as conexões remotas do evogo_auth em 70% do máximo ou mais, ou a recusa por saturação, sem mudar o reinício; as duas VPS passam a gravá-la depois do pull do checkout principal.

• 1.927.43575 Docs not source of truth - o repositório passou a cumprir o docs/schema.md, e um teste o confere: o README.md da raiz é só o índice das pastas, o docs/README.md aponta cada pasta e cada .md de outro caminho, a fase e o que entra no Git estão no docs/overview/projeto.md, a data saiu da prosa de docs/, e o RTK.md e o docs/flows/agent-tasks.md saíram.

• 1.927.36741 Service status on dek super - o dek-super ganhou a página Status, logo depois da Home no menu, com uma linha por source de dek_logs, as sete do enum: a linha mais nova, a warn mais nova e um chip vermelho quando a mais nova é warn, verde quando não há warn e laranja no resto, inclusive o serviço sem linha.

• 1.927.36220 Docs not source of truth - docs/ ganhou o próprio schema, em docs/schema.md: o que cada caminho dela guarda, o que fica de fora e o que vive em outro caminho com link a partir dela, em tabelas de glob que um teste confere sem dependência.

• 1.927.12711 Owner validation moves card - validar passou a ser trocar para true o ## Tested que o backlog-auditor escreve em false logo abaixo do ## Como testar, e a coluna testing/ saiu do fluxo, do guarda, do quadro e do menu: o arquivamento leva o card direto para done/, e o quadro mostra o valor num badge.

• 1.927.09271 Scribe needs merged pr - o backlog-scribe passou a aceitar, além do número de um PR mesclado, a solicitação direta do dono sobre um doc, por /backlog-scribe --request <solicitação>, resolvida sem o diff de um PR, numa branch backlog-scribe-<slug> que se mescla com a validação verde.

• 1.927.70167 N8n backup size unwatched - o dek-backup passou a gravar em dek_logs, a cada rodada e antes do push, uma linha info com o tamanho do pacote do n8n e a variação para o anterior, como n8n-backup 26/09 | 65,2 MB | −5,5, sem derrubar a rodada quando a linha falha; a VPS de produção passa a gravá-la depois do pull do checkout principal.

• 1.927.68991 Owner tests written in prds - o teste do dono saiu do PRD e passou a ser escrito no card, já em testing/, pelo backlog-auditor, que o aviso do merge pede depois do backlog-scribe; o card só aceita o ## Como testar a partir de testing/, e o template de PRD e as skills do backlog deixaram de pedi-lo.

• 1.926.66983 Docs skill named docs refresh - o docs-refresh passou a se chamar backlog-scribe, na pasta, no name:, no comando e no prefixo de branch, backlog-scribe-<n>, e o hook que o chama no merge, o backlog-create, o backlog-finish, o backlog-resolve, o executor, o solver e os dois READMEs do backlog acompanharam o nome.

• 1.926.63349 Card skill named scout - o scout voltou a se chamar backlog-create, na pasta, no name: e no prefixo de branch, backlog-create-<slug>, e o executor, o solver, o docs-refresh, o backlog-resolve e os dois READMEs do backlog acompanharam o nome.

• 1.926.59656 Agent flow waits on owner - o backlog-create virou scout, que escreve o card e entrega o trabalho ao subagente executor, que executa, arquiva e mescla o PR do card com a validação verde, ou ao solver, cujo PR espera o dono; e documentar saiu das skills para o docs-refresh, que a sessão do Claude que mesclou roda pelo aviso de um hook no gh pr merge.

• 1.926.61464 Card pr opens before finish - o executor e o solver passaram a abrir o PR do card só depois que o arquivamento do último PRD o leva para testing/; até lá, cada fecho fica no commit e no push da branch, que o relatório traz quando a parada vem antes do PR.

• 1.924.87426 Skychat strict turns - o skychat da VPS de desenvolvimento passou a começar cada resposta pelo «digitando…», por quatro segundos, e a ignorar o que a mesma conversa manda até essa resposta sair; a VPS de produção recebe a regra no próximo espelho.

• 1.924.68921 Skychat context guard - o skychat da VPS de desenvolvimento passou a responder só ao número de teste do dono, e só quando a place da instância está com o agente ligado, lido pela RPC get_schedly_chat_initial_context; qualquer outra mensagem segue o fluxo natural, sem «digitando…» nem resposta, e a VPS de produção recebe o guarda no próximo espelho.

• 1.922.11127 Skychat production mirror - o skychat passou a rodar também na VPS de produção, com o mesmo Compose, interno à rede proxy, sem porta pública e sem copiar sessão, token ou banco da VPS de desenvolvimento; nenhuma instância de produção aponta para ele ainda, e o hello world no aparelho fica para o teste do dono.

• 1.922.08074 N8n runners down unnoticed - a queda e a volta do container n8n-runners passaram a virar uma linha em dek_logs, warn na queda e info na volta, gravada por um watcher de cron que não religa o runner; por ora, instalado só na VPS de desenvolvimento.

• 1.922.96992 Skychat evogo integration - o skychat passou a atender POST /webhook/schedly-input, o caminho que o pareamento já grava no Evogo, e responde hello world no mesmo WhatsApp de quem escreveu, só na VPS de desenvolvimento, sem porta pública e sem guardar segredo.

• 1.922.87118 Skychat technical foundation - o novo serviço TypeScript ganhou imagem reproduzível e um container saudável na rede interna da VPS de desenvolvimento, sem porta pública e sem tocar o runtime legado.

• 1.920.33600 N8n workflows rebuild - a VPS de desenvolvimento ganhou uma tool e skill que só aceitam testenv.tech, validam o espelho antes de qualquer efeito, removem e recriam somente workflows inativos e conferem que as credenciais preservam IDs e quantidade.

• 1.920.21582 N8n workflow updates - nasceu o caminho de ida dos workflows do n8n, n8n/updates/AAAAMMDD_<descrição>/, no molde de db/migrations/: a skill n8n-workflow-update parte do snapshot fresco, copia apenas os workflows tocados e edita diretamente esses JSONs quando a mudança é simples e verificável; o espelho permanece imutável. O runbook do n8n ganhou a seção «Atualizações de workflows» com o lado da produção medido (import, publish, restart, nesta ordem).

• 1.920.18564 N8n workflows stuck in prod - o n8n/bin/dek-n8n-bench saiu do repositório com a pasta e com toda citação viva a ele, numa varredura só: a entrada da allowlist de stack-env-domains, a seção de 66 linhas que o runbook do n8n dedicava a ele, as duas frases do runbook do workflow snapshot, a linha da skill workflow-snapshot-pull que mandava editar workflow por ali e os comentários do cliente do snapshot e da unidade config, que ficaram com o fato e sem a comparação; nenhuma linha de código mudou, e a história - changelog, done/ e prds-archived/ - ficou intacta.

• 1.919.36709 Chatwoot email config - o Chatwoot passou a mandar e-mail transacional (convite de agente, senha, notificação) pela Umbler, com a caixa dedicada chatwoot@dekbot.com.br nas duas VPS e sem canal de e-mail por decisão: o bloco MAILER_SENDER_EMAIL + SMTP_* entrou no setup-env.sh com a senha como único campo do dono, o runbook ganhou a seção «E-mail transacional» - up -d e não restart, probe pelo rails runner, convite que carrega token de reset, só SPF no DNS -, e as duas VPS foram ligadas e provadas em 19/09/2026, com convite de agente entregue no Gmail a partir de cada uma.

• 1.919.25611 Chatwoot update - o Chatwoot foi de v4.16.1-ce para v4.17.0-ce nas duas VPS, com o pin trocado no Compose e as migrations aplicadas à parte pelo db:chatwoot_prepare, porque o entrypoint não migra - 99 para 102 tabelas em cada uma -, e o runbook ganhou o gesto de subir de versão; a conta de dono da produção continua por criar.

• 1.919.06711 Workflow snapshot on demand - a capability entregue em 18/09 como código e runbook passou a existir na VPS de produção: o usuário sem shell, o gerador e a regra de sudoers, o serviço no socket e o site mTLS em workflow-snapshot.dekbot.site foram instalados pelo runbook como está, com o CA do db-snapshot reusado por decisão, e o primeiro snapshot validado trouxe os quatro workflows de produção para n8n/backups/workflows/; o cliente da VPS de desenvolvimento deixou de atribuir todo 000 ao certificado de acesso - ele guarda a linha de erro do curl, imprime-a e a lê: internal error é o site não carregado na produção, certificate required e unknown ca são o certificado de cliente recusado, Could not resolve host é DNS, e o resto fica sem leitura de propósito -, e o runbook e a skill dizem o mesmo.

• 1.918.73231 Workflow snapshot on demand - a VPS de desenvolvimento passou a pedir os workflows do n8n de produção sem um humano do outro lado: um gerador root-owned, autorizado por sudoers sem senha e sem argumento, empacota o export:workflow num latest.tar.gz publicado por mv atômico - export vazio não se publica e o pacote anterior fica onde estava -, um serviço sem shell o entrega por uma rota só, GET /v1/workflow-snapshot, num socket Unix que o Caddy alcança em workflow-snapshot.{$DEK_DOMAIN} com mTLS e trust pool próprio, e o cliente da outra ponta confere o SHA do cabeçalho, o SHA256SUMS e o source_host antes de entregar o export à unidade config, que continua sendo a dona única da forma de n8n/backups/workflows/ - sempre uma versão, com o histórico por conta do Git.

• 1.918.69472 Backups scattered per service - os backups viraram um módulo só, service-backups/: uma trava production-only que lê o DEK_DOMAIN de caddy/.env no lugar das duas travas por serviço, um /etc/cron.d/dek-backup que não nomeia host nem usuário, e seis unidades em duas famílias - state guarda chatwoot, evogo, ntfy e supabase em /var/backups/dek/, com manifesto, SHA256SUMS, publicação atômica e retenção de sete, e config versiona os workflows do n8n e as definições do RabbitMQ em um commit por rodada; serviço que não subiu nesta máquina é salto, container parado é falha, o export do RabbitMQ não leva usuários nem password_hash para o Git, e o dump do Supabase leva o auth inteiro, que é o que o separa do db-snapshot.

• 1.918.68843 N8n workflows stuck in prod - o n8n da VPS de desenvolvimento virou bancada de edição: n8n/bin/dek-n8n-bench import traz para a instância o que o Git rastreia, já despublicado e visível ao MCP, e export devolve os arquivos com o active e a linha de MCP que eles tinham, para a volta ser um PR sobre n8n/backups/workflows/; o export da unidade config deixou de gravar os cinco campos que descreviam a instalação - e com eles o e-mail do dono -, e a trava da bancada recusa a produção com 77.

• 1.917.74177 Chatwoot on prod vps - o Chatwoot v4.16.1-ce subiu na VPS de produção, com .env gerado no próprio host e segredos que não atravessam da outra ponta, e o Caddy desta máquina passou a publicar chatwoot.dekbot.site sobre HTTPS - o registro A já apontava para cá e morria no handshake TLS; o runbook virou runbook das duas VPS e os dois índices deixaram de dar o serviço como instalação de uma ponta só - a conta de dono é o primeiro item da validação e ainda não existe.

• 1.917.72206 Chatwoot on dev vps - o Chatwoot v4.16.1-ce subiu na VPS de desenvolvimento e o Caddy passou a publicá-lo em chatwoot.{$DEK_DOMAIN}, com as 99 tabelas preparadas à parte porque o entrypoint não migra; o runbook saiu da curadoria e registra esse desvio, e o índice de serviços e o mapa de ambientes deixaram de dar o serviço como interno e sem endereço público - a conta de dono é o primeiro item da validação e ainda não existe.

• 1.917.55676 Redis on prod vps - a mesma stack Docker do Redis subiu na VPS de produção, com senha gerada no próprio host em 0600, AOF em bind mount e a 6379 só no loopback, e os três textos que a davam como serviço de uma máquina só - runbook, índice de serviços e mapa de ambientes - passaram a valer para as duas VPS.

• 1.917.45056 N8n on prod vps - o n8n 2.37.11 subiu na VPS de produção com chave e dados próprios, e o Caddy publicou n8n.dekbot.site sobre HTTPS; o runbook e o mapa de ambientes agora cobrem as duas instalações.

• 1.917.40235 N8n on dev vps - o n8n 2.37.11 subiu na VPS de desenvolvimento no lugar do Compose legado do primeiro commit, com a chave de criptografia obrigatória no .env desta máquina e o SQLite em bind mount, e o Caddy passou a publicar o editor e os webhooks em n8n.{$DEK_DOMAIN} - o runbook nasceu junto, e nesta ponta não há workflow nenhum.

• 1.917.36815 Redis on dev vps - a stack Docker do Redis subiu na VPS de desenvolvimento com senha obrigatória no Compose, AOF em bind mount e a 6379 só no loopback, e o serviço ganhou runbook próprio - nenhum cliente de produto está ligado ainda.

• 1.917.31973 Evogo on dev vps - o watchdog foi instalado na VPS de desenvolvimento com cron por host, exige DEK_DOMAIN para validar a API daquele ambiente e o dry-run confirmou que a inspeção não reinicia a API.

• 1.917.23900 Db snapshot drops auth migrations - o pacote passou a carregar auth.schema_migrations, que ficava de fora junto com o resto do dado de auth enquanto o schema.sql trazia a estrutura já migrada até o fim: o gotrue do destino encontrava o registro vazio, reaplicava as migrations da própria imagem por cima e morria em column "client_id" does not exist, deixando o supabase-auth em crash-loop a cada pull.

• 1.917.19539 Rabbitmq on dev vps - o barramento subiu na VPS de desenvolvimento com o .env desta máquina, o .env.example rastreado e runbook próprio, e o painel de management, que nasceria só por túnel SSH, acabou publicado pelo Caddy em rabbitmq.{$DEK_DOMAIN} - as duas portas do stack seguem no loopback.

• 1.916.91724 Rpc token travels in snapshot - o rpc_token das RPCs deixou de ser linha de public.dek_secrets, que o pg_dump --data-only copiava para dentro de todo .tar.gz, e virou app.settings.rpc_token, GUC da base postgres ao lado do app.settings.jwt_secret: o pacote não carrega mais o segredo, cada ambiente tem o seu e restaurar produção por cima não o sobrescreve.

• 1.916.85174 Sync supabase stage from prod - a VPS de desenvolvimento ganhou um cliente que baixa, confere e restaura o snapshot do Supabase de produção e uma skill que orienta a depuração com a cópia e o cuidado com as credenciais vivas.

• 1.916.77926 Supabase snapshot on demand - a VPS de produção passou a entregar uma cópia inteira do seu Supabase por uma rota só, POST /v1/db-snapshot sobre mTLS, sem abrir a máquina junto: um gerador root-owned que o sudoers autoriza sem senha e sem argumento - a string vazia no fim da regra é o que prende a capability a um comando só - empacota roles.sql, schema.sql, data.sql, manifesto e SHA256SUMS num .tar.gz publicado por mv atômico, um por vez pelo flock e sem substituir o último válido quando o dump falha; um serviço de biblioteca padrão escutando num socket Unix, como usuário de sistema sem shell e fora do grupo docker, traduz isso em quatro desfechos e nada mais - 200, 404 em tudo que não for a rota literal, 409 no concorrente e 500 seco que não entrega cópia velha com cara de nova -, e o Caddy publica o socket atrás de require_and_verify, com 404 na borda para todo o resto; os dados de auth ficam de fora por decisão de Fabio e o public.dek_secrets entra, então o artefato é credencial e o runbook docs/services/db-snapshot.md nasceu dono da capability - onde cada peça mora, a instalação, o health check, a ordem de subida com o 502 nomeado e as duas linhas do unit que parecem frouxas e não são.

• 1.916.63929 Supabase stack versions behind upstream - as onze imagens do Supabase self-hosted passaram a apontar para as versões de setembro de 2026, e as duas segundas fontes que carregam versão fora do Compose andaram na mesma leva: o PG17_TARGET_IMAGE de supabase/utils/upgrade-pg17.sh, que o próprio comentário manda manter em sincronia com a imagem do banco, e o literal que a diretriz do guarda de pinagem cita para justificar a régua de dois componentes; o imgproxy é a única troca de major das onze, de v3 para v4, e entrou depois de um container descartável provar que as cinco variáveis desta instalação sobrevivem ao v4 - nenhuma delas está na lista de remoções -, enquanto PG17_UPGRADE_IMAGE e PG17_SCRIPTS_REF ficaram em 17.6.1.063, porque são a glibc que o PG 15 exige para extrair os binários do upgrade e não a versão do banco de hoje.

• 1.916.51519 Self hosted supabase production - o Supabase self-hosted passou a existir também na VPS de produção, respondendo em supabase.dekbot.site: o registro A nasceu em DNS only na Cloudflare, os onze serviços subiram do mesmo supabase/ rastreado lendo o .env deste host, com as três portas no loopback e o Kong alcançado pela rede proxy, e o site foi publicado no Caddy sobre TLS emitido pelo Let's Encrypt, atrás do basic-auth do Studio, sem custar os dois sites que a máquina já servia; o produto não mudou de destino - o stack sobe vazio e o primário continua sendo quem os apps leem -, o runbook docs/services/supabase.md deixou de ser de uma VPS só e virou caso 2, sem endereço nem raiz literal de uma máquina, e o runbook do Caddy passou a exigir o registro sem o proxy do provedor, porque com ele o desafio ACME não chega e a emissão falha contra um limite que é da conta inteira.

• 1.916.17743 Self hosted supabase per vps - o Supabase self-hosted subiu pela primeira vez, e só na VPS de desenvolvimento, respondendo em supabase.testenv.tech: o registro A nasceu em DNS only na Cloudflare, o supabase/ deixou de ser cópia crua do upstream - só o kong entrou na rede proxy, o 8443 fechou, as outras três portas foram para o loopback e as URLs públicas passaram a derivar do DEK_DOMAIN do host -, um .env.example rastreado passou a dizer quais catorze chaves os utils/ preenchem por substituição, e os onze serviços subiram atrás do basic-auth do Kong com o produto ainda gravando no primário; o runbook docs/services/supabase.md nasceu do que essa instalação mediu de pé, e o índice de docs/ e overview/ambientes.md pararam de dizer que nenhuma das duas máquinas serve o subdomínio.

• 1.915.01948 Unpinned stack versions - a versão que cada stack sobe passou a vir do commit: as doze referências soltas dos nove Compose apontam para versão exata, resolvida por igualdade de digest para congelar o que já estava no ar em vez de atualizar, com @sha256: nas duas imagens da Chainguard, que não publicam tag versionada no tier público; o ferramental de host - docker, docker-compose e node - ganhou .tool-versions, sem o pnpm, que continua no packageManager onde o corepack o cobra; e um guarda novo reprova a próxima referência solta e a volta do pnpm à segunda fonte.

• 1.915.97547 As duas pendências do Caddy - o ufw passou a negar entrada por padrão, liberando SSH e HTTP/HTTPS, e o contorno HTTP/1.1 do ACME virou opção por host; nesta VPS, a rota HTTP/2 foi medida boa e o contorno foi desligado.

• 1.915.94686 Docs assume shared vps - a documentação parou de descrever a VPS única que foi desligada: docs/overview/ambientes.md nasceu com a identidade das duas máquinas e a regra de dizer de qual delas cada texto fala, o índice de docs/ trocou /home/base e os domínios fixos por dono e estado de curadoria, o índice de alertas operacionais passou a servir as duas pontas em vez de exigir PROD e tratar publicar no Caddy como alarme, o procedimento de apontar callback perdeu o host escrito à mão, e o README.md da raiz completou a estrutura e escreveu a fronteira das duas VPS.

• 1.915.82098 Um Caddyfile para os dois ambientes - o domínio saiu dos arquivos rastreados de stack para o .env de cada host, os sites viraram sites-available/ com link por VPS, a produção subiu sob esse layout servindo o ntfy e o apex, e um teste passou a reprovar o arquivo rastreado que volte a nomear um ambiente.

• 1.915.71514 Caddy reload drops every site - conf/sites-enabled/ religado com os links do apex e do ntfy e caddy/.env com o domínio deste host, para que o caddy reload sirva o que está no repositório em vez do que sobrou na memória do processo.

• 1.913.95682 Changelog locked in private docs - as entradas saíram da doc privada para changelog/CHANGELOG.md, e a página gerada delas, sem JS nem senha, está em https://changelog.dekbot.com, publicada pelo hook do «deploy all».

• 1.912.51378 Notifications silencing - o bloco do usuário na sidebar abre o modal «Meu Perfil», onde só notificationMuted se edita e «Sair» passou a morar; os workflows dek-push-notification e dek-voice-call leem o mute do destinatário em users antes de cada POST ao ntfy, publicados e conferidos no ar em 2026-09-12.