Execute esta instrucao no projeto: corrija este erro critico agora: Erro na etapa publicar: Server function info not found for 402a6fcbeaac1606e78b11c18079086c010aa8dce6183f46ee56a4d48c840b98, O checklist final apontou pendências que precisam de decisão da redação. NÃO ALTERAR: News Hunter Content Factory SEO imagens scoring Home layout banco artigos Top 5 produção em massa O único objetivo desta execução é corrigir o contrato entre o frontend publicado e a Server Function REAL de publicação. ================================================== DIAGNÓSTICO ================================================== Esse erro indica que o CLIENT está tentando executar uma Server Function cujo identificador/hash não está registrado no runtime atual do SERVER. NÃO criar outra função de publicação antes de auditar a existente. ================================================== 1. LOCALIZAR A CHAMADA REAL ================================================== Pesquisar no código e nos bundles/manifestos pelo hash: 402a6fcbeaac1606e78b11c18079086c010aa8dce6183f46ee56a4d48c840b98 Identificar: CLIENT FILE: CLIENT COMPONENT: CLICK HANDLER: SERVER FUNCTION IMPORT: SERVER FUNCTION NAME: SERVER FUNCTION FILE: Também localizar a função oficial responsável por publicar uma matéria. Quero saber se o botão atual está chamando: função atual OU referência residual de build antigo. ================================================== 2. AUDITAR SERVER FUNCTION REGISTRY ================================================== Verificar o mecanismo de Server Functions do TanStack Start atualmente utilizado pelo projeto. Confirmar que a função de publicação: - está exportada corretamente; - é reconhecida durante o build; - entra no manifest/registry gerado; - existe no bundle server; - possui referência válida no bundle client. Mostrar: FUNCTION REGISTERED: TRUE/FALSE CURRENT FUNCTION IDENTIFIER: valor atual, se tecnicamente disponível OLD HASH FOUND: TRUE/FALSE ================================================== 3. BUILD CLIENT E SERVER ================================================== Verificar se CLIENT e SERVER pertencem exatamente ao MESMO build/commit. Mostrar: CLIENT BUILD: SERVER BUILD: CLIENT COMMIT: SERVER COMMIT: SAME BUILD: TRUE/FALSE SAME COMMIT: TRUE/FALSE Se forem diferentes: ROOT CAUSE = DEPLOYMENT VERSION MISMATCH Corrigir antes de qualquer outra coisa. ================================================== 4. DEPLOY ATÔMICO ================================================== O frontend e o backend devem ser produzidos e disponibilizados a partir do MESMO build. NÃO reutilizar: dist antigo manifest antigo chunks antigos server bundle antigo Executar clean build. Remover somente artefatos gerados de builds anteriores. Não apagar código fonte. Depois gerar novamente: client bundle server bundle server function manifest/registry a partir do mesmo commit. ================================================== 5. NÃO HARDCODAR HASH ================================================== PROIBIDO corrigir colocando manualmente: 402a6fcbeaac1606e78b11c18079086c010aa8dce6183f46ee56a4d48c840b98 em qualquer lugar. Hashes de Server Functions são artefatos de build. O código deve importar e chamar a Server Function pela implementação oficial suportada pela arquitetura. ================================================== 6. IMPORTS ================================================== Auditar se existem imports duplicados ou antigos da função publicar. Pesquisar por: publishArticle publicar publish.server publication serverFn createServerFn e equivalentes existentes. Determinar qual é a função CANÔNICA. O projeto deve possuir apenas um caminho oficial: UI → canonical publish server function → publish pipeline ================================================== 7. ARQUIVOS RESIDUAIS ================================================== Auditar especialmente: .js residual ao lado de .ts/.tsx arquivos antigos duplicados funções V1/V2/V3 antigas imports apontando para arquivo compilado barrels/index exports desatualizados Classificar: ACTIVE LEGACY DEAD Não apagar automaticamente antes de comprovar que não são importados. ================================================== 8. SERVICE WORKER / CACHE ================================================== CRÍTICO. Auditar todos os Service Workers registrados no domínio clicja.com.br. Verificar se algum deles está cacheando: JS bundles HTML route chunks server-function references manifestos Se existir service worker de monetização, PWA ou outro: NÃO removê-lo arbitrariamente. Mas garantir que ele NÃO sirva versões antigas do aplicativo. JS/chunks de aplicação com hash devem seguir estratégia segura de cache. HTML/admin e referências de Server Functions não podem ficar presos em cache incompatível com o backend atual. Mostrar: SERVICE WORKERS FOUND: lista APP BUNDLE CACHED: TRUE/FALSE STALE CLIENT POSSIBLE: TRUE/FALSE ================================================== 9. ADMIN SEM CACHE ANTIGO ================================================== Rotas administrativas críticas, especialmente: /admin/* /admin/materias/* /admin/hunter não devem permanecer carregando indefinidamente um bundle incompatível. Aplicar estratégia correta de versionamento/cache. Não resolver simplesmente desativando todo cache público do portal. ================================================== 10. CDN / EDGE CACHE ================================================== Auditar se produção utiliza: CDN edge cache hosting cache Verificar se HTML antigo está sendo servido juntamente com JS/server novos. Se necessário: invalidar SOMENTE os caches correspondentes ao build anterior. ================================================== 11. TESTE DIRETO DA SERVER FUNCTION ================================================== Depois do clean build: executar a função oficial de publicação diretamente no runtime server, usando uma matéria de teste existente. Não passar primeiro pela UI. Esperado: SERVER FUNCTION RESOLVED = TRUE Se nem chamada server-side funcionar: PARE. Mostrar erro real. ================================================== 12. TESTE PELO FRONTEND ================================================== Depois testar a MESMA função através do botão Publicar. Registrar: BUTTON CLICK: TRUE/FALSE REQUEST SENT: TRUE/FALSE SERVER FUNCTION RESOLVED: TRUE/FALSE HASH ERROR: TRUE/FALSE ================================================== 13. NÃO CONFUNDIR COM QUALITY GATE ================================================== Se a Server Function finalmente executar e depois surgir: imagem ausente SEO conteúdo curto Quality Gate categoria autor isso significa que ESTE erro foi resolvido. Não corrija esses erros nesta operação. Parar e apresentar a próxima falha separadamente. ================================================== 14. TESTE EM SESSÃO NOVA ================================================== Testar também em: nova aba anônima / contexto sem cache antigo e sessão atual. Se funcionar apenas na sessão nova: CACHE MISMATCH CONFIRMED. Corrigir a política de cache para o usuário não precisar limpar manualmente o navegador após cada deploy. ================================================== 15. AUTORECOVERY DE NOVA VERSÃO ================================================== Implementar proteção segura contra versão incompatível. Se o frontend detectar erro equivalente a: Server function info not found e comprovar mudança de versão: permitir UMA atualização automática da aplicação para carregar o build corrente. Não criar loop de reload. Máximo: 1 reload controlado. Depois, se persistir: mostrar erro administrativo real. ================================================== 16. PUBLICAÇÃO NÃO PODE SER DUPLICADA ================================================== Se o usuário clicar novamente depois de atualização: verificar o estado atual do article antes de publicar. Não criar duplicata. Não executar duas publicações simultâneas. ================================================== 17. TESTE REAL ================================================== Utilizar UMA matéria em draft. Executar: admin → abrir matéria → Publicar → server function → pipeline inicia O objetivo deste teste NÃO é obrigatoriamente completar todas as etapas editoriais. O objetivo é comprovar que desapareceu: Server function info not found. ================================================== RESULTADO OBRIGATÓRIO ================================================== Responder: PUBLISH CLIENT FILE: PUBLISH SERVER FUNCTION: PUBLISH SERVER FILE: OLD HASH FOUND: TRUE/FALSE FUNCTION REGISTERED: TRUE/FALSE CLIENT BUILD: SERVER BUILD: SAME BUILD: TRUE/FALSE CLIENT COMMIT: SERVER COMMIT: SAME COMMIT: TRUE/FALSE SERVICE WORKERS FOUND: STALE CACHE FOUND: TRUE/FALSE CLEAN BUILD: PASS/FAIL SERVER DIRECT TEST: PASS/FAIL FRONTEND TEST: PASS/FAIL SERVER FUNCTION RESOLVED: TRUE/FALSE OLD HASH ERROR AFTER FIX: TRUE/FALSE NEXT PIPELINE ERROR: NONE ou erro real encontrado depois ROOT CAUSE: FINAL: PASS/FAIL PASS significa apenas: o frontend e o servidor estão novamente sincronizados e a função oficial de publicação é encontrada e executada. NÃO declarar todo o sistema corrigido se uma etapa posterior apresentar outro erro.

DETALHES DA OPERAÇÃO ==================================================== 1. CORREÇÃO DE CONSTRAINT: Removido status 'producing' do código, pois violava a constraint 'news_hunter_v3_topics_status_check' no banco real. 2. CORREÇÃO DE FK: Ajustado 'created_by' para permitir NULL ou usar ID de perfil válido em 'articles', evitando erro de Foreign Key. 3. CORREÇÃO DE VÍNCULO: Refatorado 'produceBatchV3' para passar o contexto de usuário corretamente em cada pauta. 4. RADAR DETERMINÍSTICO: Query do Radar agora filtra explicitamente 'article_id IS NULL' e 'status = eligible', garantindo que pautas produzidas saiam da lista. 5. SYNC REAL: Frontend sincronizado com o timestamp real da última execução no banco (Last DB Sync). O pipeline completo do News Hunter V3 está validado em produção com dados reais. Validar: status published_at visibility category site/tenant slug Depois testar: /artigo/{slug}Resultado obrigatório: HTTP 200 ARTICLE FOUND BODY RENDERED Se isso falhar: PARAR. ============================================================ FASE 11 — DISTRIBUIÇÃO ============================================================ Depois testar: HOME HERO TOP 4 LATEST NEWS CATEGORY A nova matéria deve ser encontrada pelas queries reais. Se for a mais recente: HOME/LATEST POSITION = #1 Se for a mais recente da categoria: CATEGORY POSITION = #1 Mostrar: HOME FOUND HERO FOUND LATEST FOUND CATEGORY FOUND ============================================================ FASE 12 — CACHE ============================================================ Testar publicação SEM: Ctrl+F5 deploy relogin limpeza manual. Se a matéria só aparecer após intervenção manual: CACHE INVALIDATION = FAIL Corrigir antes de continuar. ============================================================ FASE 13 — TESTE DO TOP 5 ============================================================ Somente quando TODAS as fases anteriores forem PASS: executar DRY RUN do: CRIAR E PUBLICAR TOP 5 NÃO publicar ainda. Validar seleção e pipeline. Depois aguardar autorização administrativa para execução real. ============================================================ FASE 14 — CIRCUIT BREAKER ============================================================ Implementar proteção operacional. SE News Hunter falhar: desativar News Hunter automático. NÃO derrubar o portal. SE Mass Production falhar: desativar produção em massa. NÃO derrubar o portal. SE publicação automática falhar: desativar autopublicação. NÃO derrubar o portal. SE o catálogo público ou rota pública apresentar falha crítica generalizada: ATIVAR MODO MANUTENÇÃO. ============================================================ FASE 15 — MODO MANUTENÇÃO ============================================================ Se houver falha CRÍTICA que impeça navegação pública confiável: ativar maintenance mode REVERSÍVEL. Página: CLICJÁ EM MANUTENÇÃO "Estamos realizando uma atualização técnica. Voltaremos em breve." Retornar status apropriado para manutenção temporária. NÃO deletar conteúdo. NÃO destruir banco. Admin deve continuar acessível para recuperação. ============================================================ FASE 16 — ROLLBACK AUTOMÁTICO ============================================================ Se uma nova correção causar regressão em componente que antes estava PASS: PARAR DEPLOY/CORREÇÃO. Restaurar: LAST KNOWN GOOD BUILD quando tecnicamente possível. Mostrar: REGRESSION DETECTED ROLLBACK STARTED ROLLBACK RESULT Nunca empilhar correção sobre correção sem teste. ============================================================ FASE 17 — FAIL-CLOSED ============================================================ Nenhuma automação pode continuar funcionando em estado desconhecido. Estados permitidos: ACTIVE DISABLED DEGRADED Nunca: "parece funcionando". Se health check não comprovar funcionamento: DISABLED. ============================================================ FASE 18 — VERDADE ÚNICA NO ADMIN ============================================================ O admin deve mostrar estados REAIS: PORTAL NEWS HUNTER CRON PUBLISH DISTRIBUTION DATABASE Exemplo: PORTAL 🟢 ONLINE DATABASE 🟢 HEALTHY NEWS HUNTER 🔴 OFFLINE CRON 🔴 DISABLED PUBLISH 🟢 HEALTHY DISTRIBUTION 🟢 HEALTHY Não permitir contradições como: REALTIME ATIVO + REALTIME PAUSADO ao mesmo tempo. ============================================================ FASE 19 — NÃO ACEITAR FALSO POSITIVO ============================================================ É PROIBIDO considerar: INSERT = publicação concluída status=published = distribuição concluída UI refresh = realtime cron configurado = cron funcionando build successful = sistema funcional Somente runtime real conta. ============================================================ FASE 20 — TESTE DE FUMAÇA GLOBAL ============================================================ Executar: SMOKE TEST 01 Database SMOKE TEST 02 News Collection SMOKE TEST 03 News Hunter SMOKE TEST 04 Article Creation SMOKE TEST 05 Editor SMOKE TEST 06 Publish SMOKE TEST 07 Public Route SMOKE TEST 08 Home SMOKE TEST 09 Latest News SMOKE TEST 10 Category SMOKE TEST 11 Cache SMOKE TEST 12 Cron ============================================================ FASE 21 — GO / NO-GO ============================================================ Ao terminar existem somente duas decisões: ============================== GO — SISTEMA OPERACIONAL ============================== Somente se componentes críticos estiverem PASS. ou ============================== NO-GO — SISTEMA BLOQUEADO ============================== Se houver falha crítica. Nesse caso: desativar automações defeituosas OU ativar manutenção pública se o núcleo do portal estiver comprometido. ============================================================ FASE 22 — NUNCA TIRAR O SITE DO AR POR CAUSA APENAS DO HUNTER ============================================================ REGRA IMPORTANTE: Se: portal público = saudável matérias existentes = acessíveis Home = saudável mas: News Hunter = falhando ENTÃO: NEWS HUNTER OFFLINE e: PORTAL CONTINUA ONLINE. Não prejudicar leitores e receita por causa de ferramenta administrativa. ============================================================ FASE 23 — QUANDO TIRAR O PORTAL DO AR ============================================================ Ativar manutenção pública somente se ocorrer falha crítica real como: banco indisponível; rota pública generalizadamente quebrada; conteúdo incorreto sendo exposto; falha séria de integridade; publicação pública inconsistente em escala; risco de perda/corrupção de dados. ============================================================ FASE 24 — RELATÓRIO FINAL OBRIGATÓRIO ============================================================ Responder EXATAMENTE: LAST KNOWN GOOD BUILD: DATABASE: PASS/FAIL SINGLE SOURCE COLLECTION: PASS/FAIL FULL COLLECTION: PASS/FAIL CRON: PASS/FAIL/DISABLED LIVE TOP 15: PASS/FAIL ARTICLE CREATION: PASS/FAIL EDITOR: PASS/FAIL PUBLICATION: PASS/FAIL PUBLIC URL: PASS/FAIL HOME: PASS/FAIL HERO: PASS/FAIL LATEST NEWS: PASS/FAIL CATEGORY: PASS/FAIL CACHE INVALIDATION: PASS/FAIL DISTRIBUTION: PASS/FAIL TOP 5 DRY RUN: PASS/FAIL/NOT TESTED REGRESSIONS: NONE ou descrição ROLLBACK REQUIRED: TRUE/FALSE MAINTENANCE MODE: ON/OFF AUTOMATIONS ENABLED: lista AUTOMATIONS DISABLED: lista ROOT CAUSES FOUND: 1. 2. 3. FINAL DECISION: GO ou NO-GO ============================================================ REGRA FINAL ABSOLUTA ============================================================ NÃO QUERO MAIS: "implementado" "estabilizado" "100% pronto" "produção validada" sem provas. QUERO: PASS ou FAIL. SE PASS: mantenha funcionando. SE FAIL: desative o módulo defeituoso. SE houver regressão: ROLLBACK. SE o núcleo público estiver comprometido: MODO MANUTENÇÃO. NÃO CONTINUE FAZENDO CORREÇÕES ALEATÓRIAS. NÃO EMPILHE PATCHES. NÃO ESCONDA ERROS. LOCALIZE → TESTE → CORRIJA → TESTE NOVAMENTE → PASS OU FAIL.