Luzzir · Diário de Implementações

v1.0 Última atualização: PR #301 — 14/05/2026
300 PRs Deployados
76 Features
217 Bug Fixes
7 Docs
30/03/2026 → 14/05/2026 · 47 dias · produção 100% ativa
#301
fix(dry-run): resetFirst limpa luzzir:block para testes sequenciaisFIX
14/05/2026src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#300
fix(prompt): BUG-N + T116 — abertura exception + prata→Kit suggestionFIX
13/05/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#299
fix: BUG-L opt-out first-contact + BUG-M dourado keywords (T98-T100)FIX
13/05/2026src-novo/vendas/application/messaging/process-incoming-message.ts · src-novo/vendas/infra/product-catalog.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#298
fix(prompt): reclamação anterior não deve ENCERRAR (BUG-K)FIX
13/05/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#297
fix(prompt): FAQ CPF/NF-e/email/loja física (BUG-J)FIX
13/05/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#296
fix(prompt): detecta troca pix→cartão em AGUARDANDO_PAGAMENTO (BUG-I)FIX
13/05/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#295
fix(test): BUG-H dry-run seta bypass_hours pra testes fora do horárioFIX
13/05/2026src-novo/_integracoes/whatsapp/dry-run.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#294
fix(v3): BUG-G 'perola' singular como gatilho Kit PerolasFIX
13/05/2026src-novo/vendas/infra/product-catalog.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#293
fix(test): dry-run resetFirst elimina janela BUG-F cron FUFIX
13/05/2026src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#292
fix(v3): BUG-D dry-run engage:lock + BUG-E 'kit' gatilho Kit PerolasFIX
12/05/2026src-novo/_integracoes/whatsapp/dry-run.ts · src-novo/vendas/infra/product-catalog.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#291
fix(v3): canonicaliza phone route-zapi + legacy-leadFIX
12/05/2026src-novo/vendas/presentation/zapi-webhook/guards/legacy-lead.ts · src-novo/vendas/presentation/zapi-webhook/route-zapi-message.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#290
fix(v3): canonicaliza phone saveAndDedup + circuit breaker FUFIX
12/05/2026src-novo/vendas/application/fu/process-lead.ts · src-novo/vendas/presentation/zapi-webhook/dedup-history.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#289
feat(test): dry-run mode pra bateria E2E sem trafego WhatsAppFEAT
12/05/2026src-novo/_integracoes/whatsapp/dry-run.ts · src-novo/_integracoes/whatsapp/zapi.ts · src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#288
fix(test): DELETE /memory limpa buffer + lock + pendingFIX
12/05/2026src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#287
fix(v3): preservar user msg em legacy-lead + clear state V3 em DELETE /memoryFIX
12/05/2026src-novo/vendas/presentation/zapi-webhook/guards/legacy-lead.ts · src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#286
refactor(v3): N+5.5 — DELETE src/v2/ completo — V4 oficialmente concluidaFIX
12/05/2026src-novo/vendas/infra/sheet-sync.ts · src/v2/services/productCatalogService.ts · src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#285
refactor(v3): N+5.4 — wrapper V3 sheetSync + migra 13 callersFIX
12/05/2026src-novo/vendas/infra/sheet-sync.ts · src/routes/dashboardApi.ts · src/routes/kommoWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#284
refactor(v3): N+5.3 — DELETE leadStateService V2 (-353)FIX
12/05/2026src/routes/dashboardApi.ts · src/routes/mpWebhook.ts · src/routes/shopifyWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#283
fix(v3): 3 bugs caso Ana Maria (cartao trust + CEP + FU spam)FIX
12/05/2026src-novo/vendas/application/fu/process-lead.ts · src-novo/vendas/application/messaging/check-payment-mention.ts · src-novo/vendas/infra/data-extractor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#282
refactor(v3): N+5.2 — DELETE messageQueue V2 (-118)FIX
12/05/2026src-novo/vendas/infra/zapi-message-queue.ts · src/config/templates.ts · src/routes/zapiWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#281
refactor(v3): N+5.1 — DELETE metrics V2 + migrate productCatalog callersFIX
12/05/2026src/config/templates.ts · src/services/openingTrigger.ts · src/v2/services/metrics.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#280
refactor(v3): PR-J4 — DELETE webhookService V1 (-636)FIX
12/05/2026src-novo/vendas/application/messaging/process-incoming-message.ts · src/server.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#279
refactor(v3): PR-J3 final — ANTI_REPEAT+PRODUCT_SYNC+PIX_FALLBACK V3 (-59)FIX
12/05/2026src-novo/vendas/application/messaging/post-reply-helpers.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#278
refactor(v3): PR-J3 partial — buffer 30s V3 (-30)FIX
12/05/2026src-novo/vendas/application/messaging/message-buffer.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#277
refactor(v3): PR-J2 — cabear 9 modulos V3 orfaos (-602)FIX
12/05/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#276
refactor(v3): PR-J1 — migrar paymentTextChecker V1 → V3FIX
11/05/2026src-novo/vendas/application/messaging/check-payment-mention.ts · src/handlers/paymentTextChecker.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#275
fix(v3): bugs bateria T1-T6 — Unicode + state sync + FU raceFIX
11/05/2026src-novo/vendas/application/fu/process-lead.ts · src-novo/vendas/infra/product-catalog.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#274
fix(v3): BUG-T2 — enviar-media priorizar ultima msg userFIX
11/05/2026src-novo/vendas/application/actions/enviar-media.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#273
refactor(v3): N+4 PR-I — DELETE imageHandler + paymentValidator V1 (-1144)FIX
11/05/2026src-novo/vendas/presentation/zapi-webhook/route-zapi-message.ts · src/handlers/imageHandler.ts · src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#272
refactor(v3): N+4 PR-H — DELETE proactiveService V1 (-909 net)FIX
11/05/2026src/routes/adminApi.ts · src/routes/dashboardApi.ts · src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#271
refactor(v3): N+4 PR-G — DELETE espacoLuzzirBotService V1 (-352)FIX
11/05/2026src/routes/dashboardApi.ts · src/services/espacoLuzzirBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#270
refactor(v3): N+4 PR-F — DELETE Evolution webhook path (-334)FIX
11/05/2026src/controllers/webhookController.ts · src/parsers/evolutionWebhookParser.ts · src/routes/webhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#269
refactor(v3): N+4 PR-E — DELETE V2 dead code (-1863 linhas)FIX
11/05/2026src/server.ts · src/services/posVendaBotService.ts · src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#268
feat: página /pedido.html — criação manual de pedido ShopifyFEAT
11/05/2026public/bling.html · public/correios.html · public/index.html
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#267
refactor(v3): N+3 PR-D — messageRouter thin + DELETE replyGenerator (-882)FIX
10/05/2026src/handlers/messageRouter.ts · src/handlers/replyGenerator.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#266
refactor(v3): N+3 PR-C — aiService thin shell + DELETE promptBuilder (-1579)FIX
10/05/2026src/services/aiService.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#265
refactor(v3): N+3 PR-B — actionExecutor thin shell (-595 linhas)FIX
10/05/2026src/handlers/actionExecutor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#264
refactor(v3): N+3 PR-A — DELETE actionParser V1 (-307 linhas)FIX
10/05/2026src/handlers/actionParser.ts · src/server.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#263
refactor: cleanup dashboard — remove 15 endpoints orfaos + fix duplicatasFIX
10/05/2026public/index.html · src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#262
feat: D3 Dashboard CRM — drag-and-drop Kanban + ações de pedido manualFEAT
10/05/2026public/index.html · src/routes/dashboardApi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#261
fix: ABERTURA-LOCALIZACAO-1 — pergunta inicial antes da aberturaFIX
10/05/2026src-novo/_core/initial-question-detector.ts · src-novo/vendas/application/fu/process-lead.ts · src-novo/vendas/presentation/zapi-webhook/templates/abertura.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#260
feat: N+2 sendOpening V3 nativoFEAT
10/05/2026src-novo/vendas/application/fu/process-lead.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#259
chore: melhorias consolidadas — sleep helper + .gitattributes + cache invalidateFIX
10/05/2026.gitattributes · src-novo/_core/media-markers.ts · src-novo/_core/sleep.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#258
feat: CRM Luzzir B-MVP — Kanban view + ações lead drawerFEAT
10/05/2026CLAUDE.md · public/index.html · src-novo/pos-venda/application/pagamento/apply-payment-side-effects.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#257
feat: N+1 IMAGE side-effects V3 — markLeadAsWon + flagPendingOrder diretoFEAT
10/05/2026CLAUDE.md · src-novo/pos-venda/application/pagamento/apply-payment-side-effects.ts · src-novo/pos-venda/application/pagamento/confirm-payment.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#256
fix: correios bairro fallback + filter cancelled orders + bling NF manualFIX
08/05/2026public/bling.html · public/correios.html · public/index.html
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#255
feat: adiciona Luísa (553398770676) à lista de notificaçõesFEAT
08/05/2026src-novo/_core/owner-notify.ts · src-novo/perdidos/application/bots/espaco-luzzir/chip-health-check.ts · src-novo/pos-venda/application/pedidos/owner-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#254
feat: Kommo Fase 1 — IA status Redis primárioFEAT
07/05/2026src-novo/_integracoes/kommo/leads.ts · src-novo/vendas/infra/ia-status.ts · src-novo/vendas/presentation/zapi-webhook/guards/dormant-reset.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#253
feat: consistência V2/V3 — shadow guard + phoneIndex syncFEAT
07/05/2026src-novo/vendas/presentation/zapi-webhook/route-zapi-message.ts · src/v2/orchestrators/messageOrchestrator.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#252
feat: robustez — KOMMO retry + MP search cache + dormant regexFEAT
07/05/2026src-novo/_integracoes/kommo/leads.ts · src-novo/_integracoes/mercadopago/payment-search.ts · src-novo/perdidos/application/bots/espaco-luzzir/chip-health-check.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#251
feat: observabilidade — AUTOORDER-1 + HEALTH-CHECK-1 + silent catches V3FEAT
07/05/2026src-novo/perdidos/application/bots/espaco-luzzir/chip-health-check.ts · src-novo/vendas/application/actions/criar-pedido.ts · src-novo/vendas/application/actions/gerar-cartao-link.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#250
fix: kill-switch só quando TODOS chips downFIX
07/05/2026src-novo/perdidos/application/bots/espaco-luzzir/chip-health-check.ts · src-novo/perdidos/application/bots/espaco-luzzir/run-bot.ts · src-novo/perdidos/application/bots/espaco-luzzir/send-invite.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#249
feat: endurece config bot Espaço (cap hora + intervalo maior)FEAT
07/05/2026src-novo/perdidos/application/bots/espaco-luzzir/run-bot.ts · src-novo/perdidos/application/bots/espaco-luzzir/send-invite.ts · src-novo/perdidos/domain/invite-rules.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#248
feat: IMAGE flow V3 nativo via flag IMAGE_USE_V3 (opt-in)FEAT
07/05/2026src-novo/vendas/application/messaging/handle-image-message.ts · src-novo/vendas/presentation/zapi-webhook/route-zapi-message.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#247
refactor: sheet-task-updater V3 nativo (último require V2 eliminado)FIX
06/05/2026src-novo/vendas/infra/data-extractor.test.ts · src-novo/vendas/infra/data-extractor.ts · src-novo/vendas/infra/sheet-task-updater.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#246
fix: data-extractor regex false-positive em palavras comuns (EXTRACTOR-1)FIX
06/05/2026src-novo/vendas/infra/data-extractor.test.ts · src-novo/vendas/infra/data-extractor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#245
test: vitest + 58 tests pra data-extractor + media-markers V3 (TESTS-1)FIX
06/05/2026package-lock.json · package.json · src-novo/_core/media-markers.test.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#244
refactor: media markers JSON estruturado (BUSCAR-1, MEDIA-2, VIDEO-2)FIX
06/05/2026src-novo/_core/media-markers.ts · src-novo/vendas/application/actions/buscar-produtos.ts · src-novo/vendas/application/actions/enviar-media.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#243
fix: TS cast unknown em gerar-boleto.ts (hotfix #242)FIX
06/05/2026src-novo/_core/social-links.ts · src-novo/vendas/application/actions/criar-pedido.ts · src-novo/vendas/application/actions/encerrar.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#242
fix: 8 bugs UX + observabilidade (BOLETO-2, ENCERRAR/REAGENDAR/VIDEO)FIX
05/05/2026src-novo/_core/social-links.ts · src-novo/vendas/application/actions/criar-pedido.ts · src-novo/vendas/application/actions/encerrar.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#241
fix: bugs UX em criar-pedido + cartao-link + dormant-resetFIX
05/05/2026src-novo/vendas/application/actions/criar-pedido.ts · src-novo/vendas/application/actions/gerar-cartao-link.ts · src-novo/vendas/presentation/zapi-webhook/guards/dormant-reset.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#240
fix: multi-produto Douré em criar-pedido + gerar-boleto (bugs PEDIDO-1 + BOLETO-1)FIX
05/05/2026src-novo/_core/action-logger.ts · src-novo/_core/allowed-numbers.ts · src-novo/_core/human-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#239
fix: import KOMMO_PIPELINE em kommo/leads.ts (hotfix #238)FIX
05/05/2026src-novo/_core/action-logger.ts · src-novo/_core/allowed-numbers.ts · src-novo/_core/human-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#238
feat: V3 100% nativo — ZERO requires /app/dist no src-novo (-100%)FEAT
05/05/2026src-novo/_core/action-logger.ts · src-novo/_core/allowed-numbers.ts · src-novo/_core/human-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#237
fix: TS cast ExtractedLeadData → Record em data-extraction (hotfix #236)FIX
05/05/2026src-novo/_core/action-logger.ts · src-novo/_core/allowed-numbers.ts · src-novo/_core/human-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#236
feat: migração V3 Hard B+C+smalls — TODOS consumers 100% V3 (-75% acumulado)FEAT
05/05/2026src-novo/_core/action-logger.ts · src-novo/_core/allowed-numbers.ts · src-novo/_core/human-notifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#235
fix: TS cast em generateCartaoPreference (CartaoData → BoletoData)FIX
05/05/2026src-novo/vendas/application/actions/gerar-cartao-link.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#234
feat: migração V3 Hard phase A — wrapper MP + ownerNotify (-7 requires)FEAT
05/05/2026src-novo/_integracoes/mercadopago/payment-actions.ts · src-novo/vendas/application/actions/buscar-produtos.ts · src-novo/vendas/application/actions/gerar-boleto.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#233
feat: migração V3 Medium phase — wrappers nativos Kommo/ownerNotify/memory/orderQueueFEAT
05/05/2026src-novo/_core/owner-notify.ts · src-novo/_integracoes/kommo/client.ts · src-novo/_integracoes/kommo/leads.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#232
feat: protocolo anti-banimento bot Espaço (cap configurável + variantes + health check)FEAT
05/05/2026src-novo/_integracoes/whatsapp/evolution.ts · src-novo/perdidos/application/bots/espaco-luzzir/chip-health-check.ts · src-novo/perdidos/application/bots/espaco-luzzir/run-bot.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#231
feat: migração V3 fase Easy — 18 requires V2 leadStateService eliminadosFEAT
05/05/2026src-novo/vendas/application/actions/enviar-media.ts · src-novo/vendas/application/actions/gerar-cartao-link.ts · src-novo/vendas/infra/lead-state-repository.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#230
fix: cap por chip Espaço + migração V3 wrappers (2 fixes)FIX
04/05/2026src-novo/_integracoes/whatsapp/provider.ts · src-novo/_produtos/doure/media.ts · src-novo/_produtos/kit-perolas/media.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#229
feat: perdidosRoutes acessíveis no servidor legadoFEAT
03/05/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#228
fix: TS6133 chip6741 unused var em routes.tsFIX
03/05/2026src-novo/perdidos/presentation/routes.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#227
feat: PERDA → Perdidos auto-populationFEAT
03/05/2026public/index.html · src-novo/perdidos/application/bots/espaco-luzzir/run-bot.ts · src-novo/perdidos/application/bots/espaco-luzzir/send-invite.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#226
fix: Kommo sync ignorado quando leadId=0FIX
03/05/2026src/services/autoOrderService.ts · src/services/proactiveService.ts · src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#225
fix(watchdog): envio direto + vencimento imediato + limpeza Redis staleFIX
03/05/2026src/services/aguardandoAberturaWatchdog.ts · src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#224
fix(sheetSync): prefixo Vendas! em todos os ranges da API SheetsFIX
03/05/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#223
fix: syncLeadToSheet — não ignorar leads sem histórico Redis (off-hours orphan)FIX
02/05/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#222
fix(v3): require V1 absolute paths /app/dist (FATAL bug ativação Sub 4.6)FIX
01/05/2026src-novo/vendas/application/actions/buscar-produtos.ts · src-novo/vendas/application/actions/criar-pedido.ts · src-novo/vendas/application/actions/enviar-media.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#221
[WIP] Sub 4.6 Mini-sessão 1 — entry point V3 (9 blocos triviais/médios)FIX
01/05/2026src-novo/docs/Sub-4.6-PLAN.md · src-novo/vendas/infra/legacy-templates.ts · src-novo/vendas/infra/product-catalog.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#220
Sub 4.5.B — actionExecutor V3 (8 actions migradas + atomic switch)FIX
01/05/2026src-novo/_integracoes/whatsapp/evolution.ts · src-novo/_integracoes/whatsapp/provider.ts · src-novo/_integracoes/whatsapp/zapi.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#219
feat: regra dos 10 dias — reset reativo de lead dormenteFEAT
01/05/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#218
fix(v3): enviar confirmação WhatsApp ao lead após criar pedidoFIX
01/05/2026src-novo/pos-venda/application/pedidos/create-order.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#217
fix: Pix direto MEDIUM → APPROVED + re-check MP pós-CPF (Lucyene)FIX
01/05/2026src/handlers/imageHandler.ts · src/handlers/messageRouter.ts · src/services/paymentValidator.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#216
fix: 3 bugs auditoria leads 28/04 (soft refusal + método pagto + delegação humana)FIX
30/04/2026src/services/proactiveService.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#215
Sessão 29/04: V3 oficial + 12 bugs Luísa + Watchdog + DashboardFIX
29/04/2026public/index.html · scripts/run-v1-v3-batch-shadow.js · scripts/v1-v3-scenarios-100.json
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#214
fix(payment): name match permissivo + markPaymentUsed no proativo (causa dos 20 falsos positivos)FIX
28/04/2026src/adapters/mercadoPagoAdapter.ts · src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#213
feat(notifications): throttle 4h em TODAS notificações aos ownersFEAT
28/04/2026src/handlers/actionExecutor.ts · src/handlers/imageHandler.ts · src/routes/mpWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#212
fix(proactive): MP payment check exige identidade (CPF ou email)FIX
27/04/2026src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#211
fix(src-novo): V3 ENCERRAR falso positivo + actions em inglês inválidasFIX
27/04/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#210
fix(sheet-sync): queue leak em processSheetQueue + log de erros offHoursFIX
27/04/2026src/services/webhookService.ts · src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#209
fix(src-novo): aprendizados V3 dos 100 testes Cassio (RESERVAR + luto + Insta)FIX
27/04/2026src-novo/vendas/application/messaging/build-prompt.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#208
fix(src-novo): V3 segue [PLANO DO ATENDIMENTO] + temperature 0.3FIX
27/04/2026src-novo/vendas/application/messaging/build-prompt.ts · src-novo/vendas/application/messaging/generate-reply.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#207
fix(auto-order): aceita CEP 7 dígitos (padding 0) — caso AndreaFIX
27/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#206
chore(scripts): tooling pra validar V3 (shadow report + batch test)FIX
27/04/2026scripts/run-v1-v3-batch.js · scripts/shadow-report.js · scripts/v1-v3-report-latest.json
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#205
fix(src-novo): runtime paths shadow + learnings (estavam quebrados em prod)FIX
27/04/2026src-novo/vendas/application/messaging/generate-reply.ts · src/services/aiService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#204
feat(src-novo): Sub 4.5.A — parse-actions.ts puro (vendas/domain)FEAT
26/04/2026src-novo/vendas/domain/parse-actions.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#203
feat(src-novo): Sub 4.4.A — aiService V3 + shadow mode (esqueleto, sem ativação)FEAT
26/04/2026src-novo/_integracoes/gemini/chat.ts · src-novo/vendas/application/messaging/build-prompt.ts · src-novo/vendas/application/messaging/generate-reply.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#202
feat(src-novo): Sub 4.1 + 4.2 + 4.3 — vendas baseline + proativo FU + image handler (V3)FEAT
26/04/2026src-novo/_integracoes/gemini/vision-image.ts · src-novo/vendas/README.md · src-novo/vendas/application/fu/process-lead.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#201
feat(src-novo): Sub 3.3 — webhook MP + payment validator (alto risco mitigado)FEAT
26/04/2026src-novo/_integracoes/gemini/client.ts · src-novo/_integracoes/gemini/vision-payment.ts · src-novo/_integracoes/kommo/client.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#200
feat(src-novo): Sub 3.4c — Bling NF-e (emissão automática)FEAT
26/04/2026src-novo/_integracoes/bling/client.ts · src-novo/_integracoes/bling/contatos.ts · src-novo/_integracoes/bling/nfe.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#199
feat(src-novo): Sub 3.4b — Shopify fulfillment + notify owners (fecha gap rastreio)FEAT
26/04/2026src-novo/_integracoes/shopify/fulfillment.ts · src-novo/pos-venda/application/fulfillment/generate-label.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#198
feat(src-novo): Sub 3.4a — Correios labels (geração de etiquetas)FEAT
26/04/2026src-novo/_core/env.ts · src-novo/_integracoes/correios/client.ts · src-novo/_integracoes/correios/prepostagem.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#197
feat(src-novo): Sub 3.1 + 3.2 — BOT Clube Luzzir + Auto-order ShopifyFEAT
26/04/2026src-novo/_integracoes/shopify/client.ts · src-novo/_integracoes/shopify/customer.ts · src-novo/_integracoes/shopify/order.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#196
feat(src-novo): Sessão 2 — migração BOT Espaço Luzzir + 2 chipsFEAT
26/04/2026Dockerfile · package-lock.json · package.json
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#195
chore(src-novo): scaffold inicial - strangler patternFIX
26/04/2026package.json · src-novo/README.md · src-novo/_core/README.md
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#194
feat: Espaço grupo sync 5x/diaFEAT
26/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#193
fix: rastreio não setar tag se WhatsApp falhar + regex /bots/statusFIX
25/04/2026src/routes/dashboardApi.ts · src/routes/shopifyWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#192
fix: 3 bugs do caso Diarlete (mídia repetida, IA pula etapa, Vision não descreve)FIX
25/04/2026src/handlers/actionExecutor.ts · src/handlers/imageHandler.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#191
fix: extrator endereço separa campos em 1 linhaFIX
25/04/2026src/services/dataExtractor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#190
fix: restringe desconto Pix (caso Cleide)FIX
25/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#189
fix: regex nome rejeita primeira palavra stopwordFIX
25/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#188
fix: nome auto-order usa fullName V2 quando regex divergeFIX
25/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#187
test 5FIX
25/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#186
chore: validar autodeploy pós-tokenFIX
25/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#185
chore: validar autodeploy pós-swapFIX
25/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#184
chore: re-test autodeployFIX
25/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#183
chore: validar autodeploy EasyPanelFIX
25/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#182
feat: regra dos 10 dias — reset automático de leads dormentesFEAT
25/04/2026src/handlers/messageRouter.ts · src/v2/services/leadStateService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#181
feat: fase 1 Espaço Luzzir — MAX=25/dia + kill-switch RedisFEAT
24/04/2026src/services/espacoLuzzirBotService.ts · src/services/posVendaBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#180
feat: CLUBE grupo sync 5x/dia (antes 2x)FEAT
24/04/2026src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#179
fix: avaliação Google nunca disparava no BOT pós-vendaFIX
24/04/2026src/services/posVendaBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#178
feat: bots Clube/Espaço rastreáveis + endpoint statusFEAT
24/04/2026src/routes/dashboardApi.ts · src/services/espacoLuzzirBotService.ts · src/services/posVendaBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#177
feat: IA responde pérolas sintéticas com framing positivoFEAT
24/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#176
feat: IA responde sobre material (Douré = aço inox)FEAT
23/04/2026src/services/promptBuilder.ts · src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#175
fix: cartão trust usa flagPendingOrder (padronizado)FIX
23/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#174
fix: proativo pula FU em stage pós-pagamento + nome curto rejeitadoFIX
23/04/2026src/services/proactiveService.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#173
fix: payment prioriza evidência de envio sobre menção do leadFIX
23/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#172
fix: boleto resiliente + notifica owners se falharFIX
23/04/2026src/handlers/actionExecutor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#171
fix: detectPaymentSent não regride stage quando IA cita CNPJ em objeçãoFIX
23/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#170
fix: payment ignora menção negada (nem Pix/não sei usar)FIX
23/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#169
fix: pix false positive quando IA cita CNPJ em objeçãoFIX
23/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#168
fix: neighborhood não captura nome de produto como bairroFIX
23/04/2026src/services/dataExtractor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#167
fix: JSON truncado/malformado não vaza pro leadFIX
23/04/2026src/services/aiService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#166
fix: regra prata + fallback robusto de produto no mediaFIX
23/04/2026src/handlers/actionExecutor.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#165
fix: regex Douré cobre é agudo + 'peças douradas'FIX
23/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#164
fix: sheetSync prioriza keyword exclusiva Douré sobre KitFIX
23/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#162
fix: sheetSync detecta Douré via productCatalogServiceFIX
22/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#161
fix: desambiguação respeita produto mencionado em msg préviaFIX
22/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#160
fix: auto-order recupera CEP malformado via ViaCEP truncationsFIX
22/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#159
fix: alternativa avulso Douré usa peças douradas (não Choker Pérolas)FIX
22/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#158
feat: parametriza preços das objeções + regra avulso multi-produtoFEAT
22/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#157
fix: disambiguation sem requisito hasIntentFIX
22/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#156
feat: multi-produto — 4 fixes ambiguidade + troca contextoFEAT
22/04/2026src/services/aiService.ts · src/services/promptBuilder.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#155
fix: actionExecutor.sendMediaForReply mídia por produtoFIX
22/04/2026src/handlers/actionExecutor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#154
fix: produto via histórico (fallback quando state null)FIX
22/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#153
fix: Douré nome 'Conjunto Luzzir Douré'FIX
22/04/2026src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#152
feat: Douré nome comercial 'Conjunto Douré'FEAT
22/04/2026src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#151
fix: abertura cria state V2 antes de persistir produtoFIX
22/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#150
URGENTE: fix URLs fotos Kit Pérolas (regressão prod)FIX
22/04/2026src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#149
fix: URLs mídia Kit Pérolas (regressão catálogo)FIX
22/04/2026src/services/webhookService.ts · src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#148
fix: offer template dedup agnóstico a produtoFIX
22/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#147
feat: mídia override por produto em sendOfferMedia/sendProductKitFEAT
22/04/2026src/adapters/whatsappProvider.ts · src/adapters/zapiAdapter.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#146
feat: Luzzir Douré ativo:true (teste E2E Cássio)FEAT
22/04/2026src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#145
feat: multi-produto C-lite D3 — templates parametrizadosFEAT
21/04/2026src/config/templates.ts · src/services/autoOrderService.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#144
fix: TS — productDetectedBy aceita 'history'FIX
21/04/2026src/v2/types/state.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#143
feat: multi-produto C-lite D1+D2 — catálogo + detecçãoFEAT
21/04/2026src/handlers/actionExecutor.ts · src/services/webhookService.ts · src/v2/services/productCatalogService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#142
feat: catálogo de produtos (C-lite D1) + Luzzir Douré inativoFEAT
21/04/2026src/v2/services/productCatalogService.ts · src/v2/types/state.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#141
feat: guards pré-IA (CEP inválido, status inquiry) + alerta staleFEAT
21/04/2026src/services/autoOrderService.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#140
fix: regex endereço autoOrder casa em palavra-interna e bloqueia pedidoFIX
21/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#139
feat: Espaço BOT tolera falha no sync + endpoint admin runFEAT
20/04/2026src/routes/dashboardApi.ts · src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#138
fix: detecta REAGENDAR no lead quando IA silenciaFIX
20/04/2026src/handlers/actionParser.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#137
fix: legacy lead em Perdidos reativa jornada ao retornarFIX
20/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#136
fix: oferta determinística não dispara para produto inexistenteFIX
19/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#135
fix: lead retorna de PERDA mas fica bloqueado (FU7 sem state V2)FIX
19/04/2026src/handlers/messageRouter.ts · src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#134
fix: cross-validate qty vs valor pago + unblock buildFIX
19/04/2026src/handlers/messageRouter.ts · src/handlers/paymentTextChecker.ts · src/routes/mpWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#133
fix: autoOrder — detecta quantidade > 1 da confirmação da IAFIX
19/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#132
fix: proactive — bloqueia FU quando lead tem pedido não atendidoFIX
19/04/2026src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#131
fix: PLANNER JSON truncation — bumpar maxTokens 2048→4096FIX
19/04/2026src/v2/agents/planner.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#130
fix: auto-order dados corrompidos + Correios token 403FIX
18/04/2026CLAUDE.md · src/adapters/correiosAdapter.ts · src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#129
fix: remover CDEX, corrigir para SEDEXFIX
16/04/2026src/services/aiService.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#128
fix: prazo entrega 7-10 dias úteis (SEDEX mantém 2-5)FIX
16/04/2026src/routes/shopifyWebhook.ts · src/services/aiService.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#127
fix: BOT pós-venda parado + Rastreio API mortaFIX
16/04/2026src/services/posVendaBotService.ts · src/services/rastreioService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#126
feat: NF-e entrada (XML upload) + cancelamento + navegação pós-venda unificadaFEAT
14/04/2026CLAUDE.md · package-lock.json · package.json
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#125
docs: atualiza CLAUDE.md — sessão integração CorreiosDOCS
14/04/2026CLAUDE.md
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#124
feat: dashboard etiquetas + escolha serviço + regerar + gerar do ShopifyFEAT
14/04/2026public/correios.html · public/index.html · src/adapters/blingAdapter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#123
feat: integração Bling API v3 para emissão automática de NF-eFEAT
13/04/2026public/bling.html · src/adapters/blingAdapter.ts · src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#122
feat: integração Correios API — etiquetas automáticasFEAT
13/04/2026CLAUDE.md · src/adapters/correiosAdapter.ts · src/config/env.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#121
fix: agendamento — fim do mês, dia X, quando sair pagamentoFIX
13/04/2026src/handlers/actionParser.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#120
fix: oferta dupla — flag persistente + double-checkFIX
13/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#119
feat: notificação WhatsApp para Luísa + Cássio em atendimento humanoFEAT
11/04/2026src/handlers/messageRouter.ts · src/services/humanNotifier.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#118
feat: desativar IA do Pós-Venda 100% (temporário)FEAT
11/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#117
fix: brinco avulso + AGUARDANDO_PAGAMENTO desistenciaFIX
10/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#116
feat: admin API proactive/run endpointFEAT
10/04/2026CLAUDE.md · src/routes/adminApi.ts · src/server.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#115
fix: normalização telefone 12 dígitos — Fase 1 (código)FIX
09/04/2026src/handlers/messageRouter.ts · src/services/posVendaBotService.ts · src/services/proactiveService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#114
rename: aba Página1 → VendasFIX
09/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#113
fix: parcelamento = interesse ativo (caso Wanderleia)FIX
09/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#112
fix: mutex Redis para oferta dupla (race condition)FIX
09/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#111
fix: limite histórico Redis 40 → 100 msgsFIX
09/04/2026src/memory/memoryService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#110
fix: NAME_BLACKLIST expandida (caso Lila)FIX
09/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#109
fix: aguardando_atendimento só no Pós-VendaFIX
09/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#108
fix: crons só em horário comercial (08-18h BRT)FIX
09/04/2026src/server.ts · src/services/rastreioService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#107
fix: 4 bugs jornada Sonia Xavier (boleto #1224)FIX
09/04/2026src/handlers/messageRouter.ts · src/services/autoOrderService.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#106
feat: webhook Shopify preenche rastreio na Pos-VendaFEAT
09/04/2026src/routes/shopifyWebhook.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#105
fix: TS error orderId scopeFIX
09/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#104
feat: migracao Pos-Venda auto + rastreio CorreiosFEAT
09/04/2026src/server.ts · src/services/rastreioService.ts · src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#103
fix: legacy >30d skip satisfacao, direto ao convite grupoFIX
09/04/2026src/services/posVendaBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#102
feat: BOT pos-venda — satisfacao + avaliacao Google + convite grupoFEAT
09/04/2026src/server.ts · src/services/posVendaBotService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#101
feat: Aguardando Atendimento + aba Pós-VendaFEAT
09/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#100
feat: pagamento dinamico — produto e valor variavel no MPFEAT
09/04/2026src/adapters/mercadoPagoAdapter.ts · src/handlers/actionExecutor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#99
feat: catalogo completo Shopify no promptFEAT
08/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#98
fix: TS error productInfo scopeFIX
08/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#97
feat: auto_order detecta produto do historicoFEAT
08/04/2026src/handlers/messageRouter.ts · src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#96
fix: regex ENCERRAR aceita 'agradeço sua atenção'FIX
08/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#95
fix: imagem casual em payment stage nao notifica ownersFIX
08/04/2026src/handlers/imageHandler.ts · src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#94
fix: CARTAO_TRUST exige link MP gerado antes de confiarFIX
07/04/2026src/handlers/paymentTextChecker.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#93
fix: regex endereco prioriza keywords fortes de ruaFIX
07/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#92
feat: anti-repeticao deterministico no webhookServiceFEAT
07/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#91
fix: executeBoleto salva CPF/email no CollectedDataFIX
07/04/2026src/handlers/actionExecutor.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#90
fix: TS error leadMsgs scope no ViaCEP addressFIX
06/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#89
feat: ViaCEP enriquece endereco quando regex falhaFEAT
06/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#88
fix: regex endereco fallback sem keyword Rua/AvFIX
06/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#87
fix: handler pos-venda anti-alucinacao pedido/rastreioFIX
06/04/2026src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#86
fix: auto_order cria customer Shopify explicitamenteFIX
06/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#85
fix: nota pedido Shopify usa nome completoFIX
06/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#84
feat: templates deterministicos fase 2, 3 e parte da 4FEAT
05/04/2026src/config/templates.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#83
fix: REAGENDADO preserva stage anterior real do V2 stateFIX
05/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#82
fix: template oferta dispara para 'nunca usei/primeira vez'FIX
05/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#81
feat: oferta como template deterministico com empatiaFEAT
05/04/2026src/config/templates.ts · src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#80
fix: RESERVADO transitava quando IA perguntava (nao quando lead aceitava)FIX
05/04/2026src/services/webhookService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#79
fix: limpa flag payment:pending em imagem casualFIX
05/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#78
fix: dashboard statusId usa coluna G (respeita PR #13)FIX
05/04/2026src/handlers/messageRouter.ts · src/routes/dashboardApi.ts · src/services/stateHealthCheck.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#77
fix: autoOrder usa CollectedData.fullName como prioridadeFIX
05/04/2026src/services/autoOrderService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#76
fix: 3 bugs do caso Vilma (comprovante, IA mentindo, pedido alucinado)FIX
05/04/2026src/handlers/messageRouter.ts · src/services/promptBuilder.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#75
fix: prompt IA conflitava regras de !!, FIX
05/04/2026src/services/aiService.ts
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#74
docs: diário atualizado até PR #73 + script de auto-updateDOCS
05/04/2026public/diario.html · scripts/update-diario.mjs
❌ Como era antes
Comportamento anterior ao fix (ver descrição do PR no GitHub).
✅ Como deve ser agora
Comportamento esperado após o fix.
#73
fix: boleto dedup + feedback quando dados incompletosFIX
05/04/2026src/handlers/actionExecutor.ts · src/services/aiService.ts
❌ Como era antes
Boleto podia ser gerado em duplicidade se lead confirmasse duas vezes. IA não avisava quando faltavam dados para prosseguir.
✅ Como deve ser agora
Dedup de boleto por lead + feedback explícito pedindo apenas os dados que ainda faltam + log detalhado.
#72
fix: webhook fulfillment sincroniza planilha após transiçãoFIX
04/04/2026src/routes/shopifyWebhook.ts
❌ Como era antes
Webhook de fulfillment transicionava stage no Redis mas não sincronizava a planilha — dashboard ficava desatualizado.
✅ Como deve ser agora
Após transição para PEDIDO_ENVIADO, chama syncLeadToSheet garantindo que planilha reflita o novo stage.
#71
fix: blacklist palavras comuns na extração de nomeFIX
04/04/2026src/services/dataExtractor.ts
❌ Como era antes
Extrator de nome capturava palavras comuns ("boa", "tarde", "obrigada") como nome do lead.
✅ Como deve ser agora
Blacklist de palavras comuns ignora extrações falsas e só aceita nomes próprios reais.
#70
fix: Tintim confirmação + CEP prefixo + dados faltantesFIX
04/04/2026src/services/aiService.ts · src/services/dataExtractor.ts
❌ Como era antes
Tintim não aparecia na mensagem de confirmação, CEP extraído com prefixo errado, dados do lead não pedidos novamente quando faltantes.
✅ Como deve ser agora
Tintim obrigatório na confirmação, CEP limpo de prefixos e IA pede novamente os dados que faltarem.
#69
fix: auto_order usa nome completo do leadFIX
04/04/2026src/services/autoOrderService.ts
❌ Como era antes
Pedido Shopify era criado com primeiro nome apenas — customer name incompleto.
✅ Como deve ser agora
Usa nome completo (fullName do CollectedData) ao criar pedido no Shopify.
#68
fix: regressão stage + CEP underscore + MP webhook leadIdFIX
04/04/2026src/v2/services/leadStateService.ts · src/routes/mpWebhook.ts
❌ Como era antes
Stage regredia em certas condições, CEP com underscore era rejeitado, webhook MP não conseguia associar leadId.
✅ Como deve ser agora
Bloqueio de regressão reforçado, CEP normalizado sem separadores e webhook MP resolve leadId via external_reference.
#67
fix: bloqueia mídia de oferta em stages pós-pagamentoFIX
04/04/2026src/handlers/actionExecutor.ts
❌ Como era antes
IA reenviava fotos do kit para leads que já tinham pagado — comportamento fora de contexto.
✅ Como deve ser agora
Ações de envio de mídia de oferta são bloqueadas quando stage é PAGAMENTO_CONFIRMADO ou posterior.
#66
fix: remover regex global que forçava TINTIM em toda mensagemFIX
04/04/2026src/services/aiService.ts
❌ Como era antes
Regex global adicionava TINTIM em toda mensagem de saída, gerando "!!," fora de contexto.
✅ Como deve ser agora
TINTIM aplicado só em mensagens de avanço para Quase Fechando (via tag explícita).
#65
fix: proativo abertura genérica para leads Kommo fallbackFIX
04/04/2026src/services/proactiveService.ts
❌ Como era antes
Leads vindos do Kommo fallback (sem histórico Z-API) não recebiam abertura proativa.
✅ Como deve ser agora
Proativo envia abertura genérica para leads Kommo que ainda não tiveram conversa registrada.
#64
feat: webhook Kommo — abertura genérica para leads sem Z-APIFEAT
04/04/2026src/routes/kommoWebhook.ts
❌ Como era antes
Leads criados diretamente no Kommo (sem passar pela Z-API) ficavam parados no funil sem abertura.
✅ Como deve ser agora
Webhook Kommo dispara abertura genérica automaticamente para leads novos sem histórico Z-API.
#63
fix: pós-venda usa callGemini diretoFIX
04/04/2026src/handlers/messageRouter.ts
❌ Como era antes
Pós-venda passava pelo fluxo de vendas normal, carregando prompts e lógica irrelevantes.
✅ Como deve ser agora
Pós-venda chama callGemini direto com prompt específico, mais rápido e sem interferência do fluxo de vendas.
#62
feat: pós-venda responde rastreio/prazo sem venderFEAT
04/04/2026src/handlers/messageRouter.ts · src/services/aiService.ts
❌ Como era antes
Lead em pós-venda que perguntava sobre rastreio recebia resposta do fluxo de vendas (tentando vender de novo).
✅ Como deve ser agora
Prompt dedicado de pós-venda responde dúvidas de rastreio/prazo/entrega sem tentar vender novamente.
#61
fix: valor só preenchido com pagamento definidoFIX
04/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Coluna Valor da planilha era preenchida com R$ 159 logo no início da conversa, antes do lead escolher pagamento.
✅ Como deve ser agora
Valor só é preenchido quando payment é definido (pix/cartão/boleto) — antes fica em branco.
#60
fix: valor R$119 falso por 'choker' no texto da IAFIX
04/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Quando IA mencionava "choker" em explicação, extractor marcava valor como R$ 119 mesmo sendo kit.
✅ Como deve ser agora
Detecção de choker isolada exige ausência explícita de "kit" em todo o texto.
#59
fix: pausa temporária inclui delegação (filha/marido/filho)FIX
04/04/2026src/services/aiService.ts
❌ Como era antes
Lead dizia "vou falar com minha filha" — IA não pausava e continuava insistindo.
✅ Como deve ser agora
Padrões de delegação (filha, marido, filho, esposa) disparam pausa temporária aguardando retorno.
#58
fix: webhook MP match por external_reference com phoneFIX
04/04/2026src/routes/mpWebhook.ts
❌ Como era antes
Webhook MP não conseguia associar pagamento ao lead por falta de identificador confiável.
✅ Como deve ser agora
Preferences API injeta phone no external_reference — webhook usa isso para match direto com o lead.
#57
fix: erros TypeScript no webhook MP e proativoFIX
04/04/2026src/routes/mpWebhook.ts · src/services/proactiveService.ts
❌ Como era antes
Build falhava por erros de tipagem em webhookMp e proactiveService após mudanças do PR #55.
✅ Como deve ser agora
Tipos corrigidos, build verde, deploy viável.
#56
fix: regex CPF no sheetSync também aceita espaçosFIX
04/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
CPF digitado com espaços ("123 456 789 00") não era capturado no extractor do sheetSync.
✅ Como deve ser agora
Regex atualizada aceita CPF com espaços, pontos, traços ou contínuo.
#55
feat: webhook MP fase 2 — confirmação automática de pagamentoFEAT
04/04/2026src/routes/mpWebhook.ts · src/services/paymentValidator.ts
❌ Como era antes
Pagamento via MP exigia detecção por texto do comprovante ou confirmação manual.
✅ Como deve ser agora
Webhook MP recebe evento payment.updated, confirma pagamento automaticamente e dispara criação do pedido Shopify.
#54
fix: telefone sem dígito 9 + IA pedia comprovante no cartãoFIX
04/04/2026src/utils/phoneUtils.ts · src/services/aiService.ts
❌ Como era antes
Telefone de 12 dígitos (sem 9) não era normalizado. IA pedia comprovante mesmo quando lead pagou via cartão MP.
✅ Como deve ser agora
canonicalizePhone adiciona 9 para 12 dígitos. IA não pede comprovante para pagamento cartão (MP notifica).
#53
fix: regex CPF aceita espaços entre dígitosFIX
04/04/2026src/services/dataExtractor.ts
❌ Como era antes
Regex CPF exigia formato limpo — CPFs com espaços dispersos não eram capturados.
✅ Como deve ser agora
Regex tolerante aceita qualquer separador (espaço, ponto, traço) entre os dígitos.
#52
fix: dedup mídia — não reenvia fotos/áudio já enviadosFIX
04/04/2026src/handlers/actionExecutor.ts
❌ Como era antes
IA reenviava fotos/áudio do kit múltiplas vezes na mesma conversa.
✅ Como deve ser agora
Detecção de mídia já enviada no histórico bloqueia reenvio, mantendo conversa limpa.
#51
fix: detecção de pagamento marcava boleto indevidoFIX
04/04/2026src/v2/services/sheetSync.ts
❌ Como era antes
Qualquer menção a "boleto" marcava payment=boleto, mesmo que lead estivesse só perguntando.
✅ Como deve ser agora
Detecção exige palavra de escolha explícita (prefiro/quero/gerar) junto com "boleto".
#50
fix: proativo não chamava flagPendingOrder após confirmar pagamentoFIX
03/04/2026src/services/proactiveService.ts
❌ Como era antes
Quando proativo confirmava pagamento, pedido Shopify não era criado automaticamente.
✅ Como deve ser agora
Proativo chama flagPendingOrder após confirmar pagamento, disparando criação do pedido.
#49
fix: padronizar mensagem Tintim pagamento confirmadoFIX
03/04/2026src/config/templates.ts
❌ Como era antes
Mensagem de pagamento confirmado variava entre templates, atrapalhando tracking de conversão.
✅ Como deve ser agora
Template único padronizado para todas as confirmações de pagamento.
#48
fix: remover TINTIM da confirmação de pagamentoFIX
03/04/2026src/config/templates.ts
❌ Como era antes
TINTIM ("!!,") aparecia na confirmação de pagamento — já tinha sido contado anteriormente em QF.
✅ Como deve ser agora
Confirmação de pagamento sem TINTIM, evitando dupla contagem na métrica.
#47
fix: proativo pagamento confirmado revertia stage AGUARDANDO_PAGAMENTOFIX
03/04/2026src/services/proactiveService.ts
❌ Como era antes
Proativo rodava sobre lead em PAGAMENTO_CONFIRMADO e transicionava de volta para AGUARDANDO_PAGAMENTO.
✅ Como deve ser agora
Proativo skip stages pós-pagamento — não intervém em leads já confirmados.
#46
fix: pausa temporária não gera REAGENDAR + capitalizar nomeFIX
03/04/2026src/services/aiService.ts · src/services/dataExtractor.ts
❌ Como era antes
Pausa temporária ("daqui 1h") gerava REAGENDAR indevidamente. Nomes eram salvos em caixa baixa.
✅ Como deve ser agora
Pausa temporária tratada separadamente de REAGENDAR. Nomes capitalizados antes de salvar.
#45
fix: V2 orchestrator sobrescrevia taskOverride do REAGENDARFIX
03/04/2026src/v2/orchestrators/messageOrchestrator.ts
❌ Como era antes
Orchestrator V2 sobrescrevia taskOverride quando REAGENDAR estava ativo, perdendo data agendada.
✅ Como deve ser agora
taskOverride do REAGENDAR preservado — data agendada mantida através do fluxo V2.
#44
fix: métricas do dia sempre atualizadas no dashboard FIX
03/04/2026 public/index.html · src/routes/dashboardApi.ts
O que estava errado
  • Data padrão = ontem: toggleMetricas() setava a data como d.getDate() - 1, então ao abrir o painel sempre carregava o dia anterior, não o dia atual.
  • Sem auto-refresh: o ciclo automático de 300s chamava refresh(), refreshActionLog() e refreshPipeline(), mas nunca loadMetricas() — mesmo com o painel aberto os dados ficavam estáticos.
  • Sem cache server-side: cada clique em "Buscar" disparava uma nova requisição ao Google OAuth + Sheets completo (A:Z), tornando o endpoint lento e com risco de rate-limit.
❌ Como era antes
Abrir o painel de métricas sempre mostrava os dados de ontem. Clicar "Buscar" duas vezes fazia duas chamadas ao Google Sheets. Deixar o dashboard aberto o dia todo não atualizava os números.
✅ Como deve ser agora
Ao abrir o painel, a data já está em hoje e os dados carregam automaticamente. Botões "Hoje" e "Ontem" permitem troca rápida. O refresh de 300s atualiza as métricas junto com os leads. Chamadas repetidas em 5 min usam cache em memória.
O que foi feito
  • Front end — data padrão: toggleMetricas() agora seta new Date().toISOString().split('T')[0] (hoje) na primeira abertura.
  • Front end — botões atalho: adicionados botões "Hoje" (vinho) e "Ontem" (cinza) ao lado do date picker com função setMetricasDate(offsetDays).
  • Front end — auto-refresh: ao final de refresh(), se metricasOpen e a data estiver preenchida, chama loadMetricas() automaticamente.
  • Backend — cache: adicionado metricsCache (Map em memória) com TTL de 5 minutos por data no endpoint GET /api/metrics/daily.
#43
fix: cartão — blocos separados igual ao PIX FIX
03/04/2026 src/handlers/actionExecutor.ts
❌ Como era antes
Link do cartão e instrução enviados numa mensagem só, dificultando cópia do link.
✅ Como deve ser agora
Link do cartão enviado em mensagem separada (igual ao bloco do PIX), facilitando cópia.
#42
feat: link cartão personalizado com CPF via MP Preferences API FEAT
03/04/2026 src/adapters/mercadoPagoAdapter.ts · src/handlers/actionExecutor.ts
❌ Como era antes
Link de cartão era fixo (mpago.la/...) — não identificava o lead, dificultando reconciliação de pagamentos.
✅ Como deve ser agora
Link gerado via MP Preferences API com CPF do lead pré-preenchido, identificando o pagador automaticamente.
#41
fix: confirmação de pagamento determinística — bypass IA+Guardian FIX
03/04/2026 src/services/webhookService.ts · src/handlers/actionExecutor.ts
❌ Como era antes
Confirmação de pagamento passava pelo fluxo normal IA+Guardian, podendo ser bloqueada ou atrasada.
✅ Como deve ser agora
Detecção de comprovante válido executa confirmação diretamente, sem passar por IA ou Guardian.
#40
fix: Guardian não bloqueia aprovação válida de Pix direto FIX
02/04/2026 src/v2/services/guardian.ts
❌ Como era antes
Guardian bloqueava a transição COMPROVANTE_RECEBIDO → PAGAMENTO_CONFIRMADO mesmo quando Pix direto (CNPJ Luzzir) estava confirmado.
✅ Como deve ser agora
Guardian aprova aprovação de Pix direto confirmado, sem interferir no fluxo determinístico de pagamento.
#39
feat: salva resultado Gemini Vision no Redis para auditoria FEAT
02/04/2026 src/services/paymentValidator.ts · src/memory/memoryService.ts
❌ Como era antes
Análise do comprovante pelo Gemini Vision era descartada após o retorno — sem rastro para debug ou auditoria.
✅ Como deve ser agora
Resultado da análise (válido/inválido, valor, recebedor) salvo no Redis com TTL para consulta no dashboard e auditoria.
#38
fix: auto-aprovação Pix direto quando recebedor Luzzir confirmado FIX
02/04/2026 src/services/paymentValidator.ts
❌ Como era antes
Pix direto (CNPJ 51763279000104) exigia confirmação manual mesmo com recebedor identificado.
✅ Como deve ser agora
Quando Gemini Vision confirma recebedor = Luzzir, aprovação é automática sem intervenção humana.
#37
fix: stage AGUARDANDO_PAGAMENTO quando PIX enviado em msg separada FIX
02/04/2026 src/services/webhookService.ts
❌ Como era antes
Se lead enviava a chave PIX em mensagem separada (sem texto junto), o stage não avançava para AGUARDANDO_PAGAMENTO.
✅ Como deve ser agora
Detecção de chave PIX em qualquer mensagem (só chave ou com texto) avança corretamente para AGUARDANDO_PAGAMENTO.
#36
fix: reset-lead deleta linha da planilha (lead novo do zero) FIX
02/04/2026 src/v2/services/sheetSync.ts · src/routes/dashboardApi.ts
❌ Como era antes
Reset-lead limpava Redis e Redis block, mas mantinha a linha na planilha — no próximo sync, dados antigos voltavam.
✅ Como deve ser agora
Reset completo deleta a linha da planilha + Redis + flags. Lead começa do zero como novo.
#35
fix: reset-lead limpa coluna W Bloqueado FIX
02/04/2026 src/v2/services/sheetSync.ts
❌ Como era antes
Reset-lead não limpava a coluna W (Bloqueado) da planilha — lead resetado continuava aparecendo como bloqueado.
✅ Como deve ser agora
Reset limpa coluna W junto com as demais, garantindo que IA Status volte a ON corretamente.
#34
fix: reset-lead PUT no Sheets API FIX
02/04/2026 src/v2/services/sheetSync.ts
❌ Como era antes
Reset usava método errado na Sheets API, causando erro 400 ao tentar limpar a linha.
✅ Como deve ser agora
Usa PUT com body correto para limpar colunas — sem erro de API.
#33
feat: admin reset-lead — reset completo para testes FEAT
02/04/2026 src/routes/dashboardApi.ts · src/v2/services/sheetSync.ts
❌ Como era antes
Resetar um lead para testes exigia limpar Redis manualmente via admin + editar planilha manualmente.
✅ Como deve ser agora
Endpoint POST /admin/reset-lead reseta Redis, flags, linha da planilha e estado v2 em um único comando.
#32
feat: admin endpoint fix-lead-state para correções manuais de stage FEAT
02/04/2026 src/routes/dashboardApi.ts · src/v2/services/leadStateService.ts
❌ Como era antes
Corrigir stage errado de um lead exigia acessar Redis direto ou editar a planilha manualmente.
✅ Como deve ser agora
POST /admin/fix-lead-state corrige o stage no Redis e planilha com um único endpoint, sem acesso ao servidor.
#31
fix: flagPendingOrder quando MP confirma pagamento via texto FIX
02/04/2026 src/services/webhookService.ts · src/handlers/actionExecutor.ts
❌ Como era antes
Confirmação de pagamento via texto do MP (sem webhook) não disparava criação do pedido Shopify.
✅ Como deve ser agora
Detecção de confirmação MP via texto seta flag pendingOrder, que aciona criação automática do pedido Shopify.
#30
fix: remove espaços do código de rastreio FIX
02/04/2026 src/adapters/shopifyAdapter.ts · src/services/shopifyFulfillmentService.ts
❌ Como era antes
Código de rastreio com espaços gerava URL quebrada ao lead tentar acompanhar o pedido.
✅ Como deve ser agora
Espaços removidos com trim + replace antes de montar a URL de rastreio.
#29
fix: dedup webhook mutex Redis + URL encode rastreio FIX
02/04/2026 src/controllers/webhookController.ts · src/services/shopifyFulfillmentService.ts
❌ Como era antes
Webhooks duplicados do Shopify processavam rastreio mais de uma vez, enviando múltiplas mensagens ao lead. URL de rastreio sem encode quebrava em caracteres especiais.
✅ Como deve ser agora
Mutex Redis com TTL bloqueia processamento duplicado. URL de rastreio com encodeURIComponent.
#28
fix: bloqueia regressão de stage pós-pagamento FIX
02/04/2026 leadStateService.ts
O que estava errado
  • Causa raiz: detectPaymentSent() no webhookService dispara markAsAguardandoPagamento() quando o nextTask do Operator contém palavras como "comprovante" ou "pagamento" — sem checar o stage atual.
  • leadStateService fail-open: transições inválidas eram permitidas com apenas um warning no log.
  • Caso real — Lead Leda (557192727720): pagamento confirmado às 14:34 → stage PAGAMENTO_CONFIRMADO. Aos 14:35, Operator nextTask com "comprovante" forçou regressão para AGUARDANDO_PAGAMENTO. Pedido #1202 criado às 15:35 de um stage errado e sem endereço completo.
❌ Como era antes
Política fail-open universal: qualquer transição inválida era permitida com warning. PAGAMENTO_CONFIRMADO podia regredir para AGUARDANDO_PAGAMENTO via trigger automático.
✅ Como deve ser agora
Fail-CLOSED para POST_PAYMENT_STAGES (PAGAMENTO_CONFIRMADO, PEDIDO_CRIADO, PEDIDO_ENVIADO, PEDIDO_ENTREGUE): transições inválidas retornam erro e são bloqueadas. Fail-open mantido para stages anteriores.
Arquivos
src/v2/services/leadStateService.ts
#27
docs: atualiza CLAUDE.md sessão 2026-04-02 DOCS
02/04/2026 CLAUDE.md
O que foi feito
  • Atualização do CLAUDE.md com contexto da sessão, decisões e estado atual do projeto em 02/04/2026.
#26
fix: transitionByPhone PEDIDO_ENVIADO no webhook fulfillment FIX
02/04/2026 src/routes/shopifyWebhook.ts · src/v2/services/leadStateService.ts
❌ Como era antes
Webhook de fulfillment do Shopify não atualizava o stage do lead para PEDIDO_ENVIADO — rastreio era enviado mas o funil ficava desatualizado.
✅ Como deve ser agora
transitionByPhone chamado corretamente ao receber fulfillment, avançando o stage para PEDIDO_ENVIADO no Redis e na planilha.
#25
docs: antes/agora em todos os PRs do diário DOCS
02/04/2026 public/diario.html
O que foi feito
  • Adicionados blocos "Como era antes" e "Como deve ser agora" em todos os cards do diário, seguindo a nova regra obrigatória do SKILL.md.
#24
feat: mensagens de rastreio no tom da Luisa FEAT
02/04/2026 src/services/shopifyFulfillmentService.ts · src/config/templates.ts
❌ Como era antes
Mensagem de rastreio enviada em tom genérico/técnico: "Seu pedido foi enviado. Código: BR123..."
✅ Como deve ser agora
Mensagem no tom da Luisa, afetivo e consultivo, com emoji e link de rastreio formatado para fácil clique.
#23
fix: rastreio não chegava ao lead após despacho FIX
02/04/2026 src/services/shopifyFulfillmentService.ts · src/adapters/zapiAdapter.ts
❌ Como era antes
Webhook de fulfillment processava corretamente mas a mensagem de rastreio não era enviada ao lead via WhatsApp.
✅ Como deve ser agora
Após fulfillment, rastreio é enviado automaticamente ao lead com link clicável para acompanhar entrega.
#22
fix: city/state via ViaCEP no auto-order FIX
02/04/2026 src/services/autoOrderService.ts
❌ Como era antes
Criação automática do pedido Shopify falhava quando lead não fornecia cidade/estado — campos obrigatórios ficavam vazios.
✅ Como deve ser agora
CEP é consultado na API ViaCEP para preencher cidade e estado automaticamente, sem depender do lead informar.
#21
docs: diário de PRs + links cruzados entre páginas DOCS
02/04/2026 diario.html · arquitetura.html · fluxo.html
O que foi feito
  • diario.html (este arquivo): timeline completa de todos os PRs com causa raiz, casos reais, filtros FEAT/FIX/DOCS e seções "Como era antes / Como deve ser agora"
  • Links cruzados entre arquitetura, fluxo e diário em todas as páginas
  • Regra adicionada à skill: atualizar diário a cada novo PR deployado
❌ Como era antes
Não havia registro centralizado do que cada PR mudou. Para investigar uma regressão, era necessário ir no GitHub ler cada commit individualmente. Difícil saber o que estava em produção.
✅ Como deve ser agora
diario.html centraliza todos os PRs com causa raiz, casos reais e critérios de aceitação. Qualquer regressão pode ser rastreada consultando o PR correspondente nesta página.
Arquivos
public/diario.html public/arquitetura.html public/fluxo.html
#20
docs: arquitetura v2.1 com PR badges + página de fluxo N8N DOCS
02/04/2026 arquitetura.html · fluxo.html
O que foi feito
  • arquitetura.html v2.1: seção Changelog com todos os PRs, badges PR# inline em componentes afetados, link para fluxo
  • fluxo.html (novo): diagrama visual estilo N8N com nós posicionados, setas SVG bezier, tooltips por nó, badges de PR
❌ Como era antes
Documentação visual desatualizada (v2.0, antes dos PRs de fix). Não havia diagrama de fluxo interativo — o processo era descrito só em texto no CLAUDE.md.
✅ Como deve ser agora
arquitetura.html v2.1 com changelog de todos os PRs e badges por componente. fluxo.html com diagrama N8N-style, setas SVG, tooltips e badges de PR em cada nó do fluxo.
Arquivos
public/arquitetura.html public/fluxo.html
#19
feat: badge LEGACY no dashboard + migração em lote FEAT
02/04/2026 messageRouter.ts · dashboardApi.ts · index.html · migrate_legacy_flags.js
Caso real
Leads R539 e R574 ficaram sem resposta por horas após enviar mensagem. O webhook recebia a mensagem, mas silenciosamente ignorava e não respondia.
Causa raiz
Legacy check no messageRouter fazia skip hard (descartava o lead completamente). O proativo, porém, NÃO tinha legacy check — mandava FU1/FU2 normalmente. O lead respondia ao FU, e o webhook ignorava tudo de novo. Loop infinito de silêncio.
O que foi feito
  • messageRouter: em vez de skip hard → smart routing: se IA respondeu nos últimos 7 dias, continua; senão, limpa histórico quebrado e faz fresh start
  • Redis flag luzzir:legacy:{phone} (TTL 30d) setado ao detectar legacy
  • dashboardApi: batch mget para todos os telefones → isLegacy: boolean em cada lead
  • index.html: badge roxo LEGACY no card do lead no dashboard
  • Script migrate_legacy_flags.js: marcou 59 leads legados existentes em lote
❌ Como era antes
Lead R539 mandava mensagem → webhook recebia → silêncio. Proativo depois mandava FU1/FU2. Lead respondia ao FU → webhook ignorava de novo. Nenhum badge no dashboard indicava o problema. Impossível identificar quais dos 59 leads estavam nessa situação.
✅ Como deve ser agora
Lead R539 manda mensagem → webhook detecta legacy → smart routing: se IA respondeu nos últimos 7 dias, continua; senão, faz fresh start. Badge roxo LEGACY aparece no card do dashboard para identificação visual imediata.
Arquivos
src/handlers/messageRouter.ts src/routes/dashboardApi.ts public/index.html migrate_legacy_flags.js
#18
fix: 3 bugs de progressão de funil FIX
02/04/2026 actionParser.ts · webhookService.ts
3 bugs corrigidos
  • REAGENDADO incorreto: certas frases temporais ("te mando amanhã", "semana que vem pago") eram marcadas como REAGENDAR mesmo após o lead já ter aceito a reserva
  • Frases temporais pós-pagamento: "vou pagar amanhã" após aceitar reserva deveria manter AGUARDANDO_PAGAMENTO, não ir para REAGENDADO
  • Oferta duplicada: em alguns casos o Operator enviava a oferta duas vezes para o mesmo lead
Correção
Melhor detecção de contexto no actionParser — frases temporais só geram REAGENDADO se o lead não tiver ainda entrado no funil de pagamento. Proteção anti-duplicação de oferta adicionada no webhookService.
❌ Como era antes
Rita disse "te mando na semana que vem" após aceitar reserva → REAGENDADO sobrescrevia tarefa de FU ativo. Cacilda e IRACEMA: "eu entro em contato" → ENCERRAR/PERDA indevido. Gil recebeu 3 imagens + áudio da oferta duas vezes na mesma conversa.
✅ Como deve ser agora
REAGENDADO sem tag Redis escreve "Retomar contato" +7 dias sem sobrescrever FU ativo. "eu entro em contato"/"por enquanto" → REAGENDAR:7, não ENCERRAR. Oferta enviada uma vez; pergunta de preço pós-oferta retorna só texto com preço.
Arquivos
src/parsers/actionParser.ts src/services/webhookService.ts
#17
fix: MP fallback rejeita XXXXXXXXXXX e verifica nome conflitante FIX
02/04/2026 mercadoPagoAdapter.ts
O que estava errado
MercadoPago retorna email "XXXXXXXXXXX" (mascarado/anonimizado pelo MP) como dado válido — o sistema tratava esse email como real e confirmava pagamento falso. Além disso, quando um pagamento tinha nome diferente do lead, era aceito sem verificação de similaridade.
Correção
  • Rejeita email que seja composição de "X" repetidos (regex /^X+$/i)
  • Verifica similaridade de nome antes de confirmar quando o email é mascarado
❌ Como era antes
Vanda (551183906287) aguardava pagamento. MP retornou email "XXXXXXXXXXX" (placeholder anônimo) de outra pessoa → sistema aceitou como identidade válida → pagamento anônimo de R$159 de terceiro confirmado como sendo da Vanda. Pedido criado indevidamente.
✅ Como deve ser agora
Vanda manda comprovante → MP retorna email "XXXXXXXXXXX" → sistema rejeita (padrão "X" repetido não é identidade válida). Fallback por valor+dia também verifica se o nome do pagador é compatível com o nome da Vanda antes de confirmar.
Arquivos
src/adapters/mercadoPagoAdapter.ts
#16
fix: MP name match exige valor quando sem CPF/email FIX
01/04/2026 mercadoPagoAdapter.ts
O que estava errado
MercadoPago fallback por nome encontrava pagamentos de terceiros com nome parecido (ex: "Maria da Silva" de outra "Maria"), confirmando pagamento falso sem verificação adicional.
Correção
Quando a busca é por nome (sem CPF/email disponível), o sistema agora exige também que o valor do pagamento bata (±R$5). Sem CPF ou email, nome sozinho não é suficiente para confirmar.
❌ Como era antes
Sandra (559180345084) não tinha CPF/email no histórico. MP encontrou pagamento de outra "Sandra" no mesmo dia com valor diferente → confirmou pagamento falso. Pedido criado indevidamente para a Sandra errada.
✅ Como deve ser agora
Sandra manda comprovante → MP não acha CPF/email → tenta por nome → encontra outra "Sandra" com valor diferente → rejeita (valor não bate dentro de ±R$5). Só confirma quando nome + valor coincidem.
Arquivos
src/adapters/mercadoPagoAdapter.ts
#15
fix: COMPROVANTE_RECEBIDO só transita com comprovante válido FIX
01/04/2026 messageRouter.ts · actionExecutor.ts
O que estava errado
O stage COMPROVANTE_RECEBIDO era definido ao receber qualquer imagem, antes mesmo da validação do Gemini Vision e do MercadoPago. Se a validação falhasse, o lead ficava preso em stage errado.
Correção
Stage só transita para COMPROVANTE_RECEBIDO após confirmação de comprovante válido: Gemini Vision VALIDO:SIM + MercadoPago confirma. Antes disso, o stage permanece como estava.
❌ Como era antes
Sandra (559180345084) enviou imagem inválida (não era comprovante). Sistema transitou imediatamente para COMPROVANTE_RECEBIDO antes mesmo do Gemini analisar. Quando Gemini retornou "inválido", o stage já estava errado e o lead ficou em posição inconsistente.
✅ Como deve ser agora
Sandra envia imagem → stage permanece AGUARDANDO_PAGAMENTO → Gemini analisa → retorna VALIDO:NÃO → sistema pede comprovante correto. Stage só muda para COMPROVANTE_RECEBIDO após confirmação dupla: Gemini VALIDO:SIM + MP confirma pagamento.
Arquivos
src/handlers/messageRouter.ts src/v2/services/actionExecutor.ts
#14
fix: ENCERRAR bloqueado em AGUARDANDO_PAGAMENTO FIX
01/04/2026 actionExecutor.ts
O que estava errado
O actionExecutor não permitia transição para ENCERRAR ou PERDA quando o lead estava em AGUARDANDO_PAGAMENTO — mesmo se o lead desistisse explicitamente ("não vou mais comprar", "deixa pra lá"). O lead ficava preso no stage sem saída.
Correção
ENCERRAR e PERDA adicionados como transições válidas a partir de AGUARDANDO_PAGAMENTO na máquina de estados do actionExecutor.
❌ Como era antes
Vania (554891297177) estava em AGUARDANDO_PAGAMENTO e disse "obrigada, boas vendas" (desistência clara). IA tentou emitir ENCERRAR → actionExecutor rejeitou a transição → lead ficava preso em AGUARDANDO_PAGAMENTO sem saída possível.
✅ Como deve ser agora
Vania diz "obrigada, boas vendas" → IA emite ENCERRAR → actionExecutor aceita a transição → lead encerrado normalmente com resposta de despedida. ENCERRAR e PERDA são transições válidas de AGUARDANDO_PAGAMENTO.
Arquivos
src/v2/services/actionExecutor.ts
#13
fix: REAGENDADO preserva Status Kommo existente na coluna G FIX
31/03/2026 sheetSync.ts
O que estava errado
Quando um lead ia para REAGENDADO, a coluna G (Status Kommo) da planilha era sobrescrita com "Reagendado". Porém REAGENDADO não existe como stage no Kommo — ao sincronizar, o lead perdia o status real que tinha antes (ex: "Quase Fechando").
Correção
syncLeadToSheet preserva o valor atual da coluna G quando o novo stage é REAGENDADO. A coluna não é sobrescrita — o status Kommo real é mantido intacto.
❌ Como era antes
Lead em "Quase Fechando" no Kommo dizia "te mando amanhã" → stage ia para REAGENDADO → coluna G sobrescrita com "Reagendado" → Kommo sync movia lead de volta para "Em Conversa". Lead perdia a posição no funil de vendas.
✅ Como deve ser agora
Lead em "Quase Fechando" diz "te mando amanhã" → stage vai para REAGENDADO → coluna G preserva "Quase Fechando" → Kommo não é movido. Lead continua em "Quase Fechando" no CRM enquanto aguarda o pagamento.
Arquivos
src/v2/services/sheetSync.ts
#12
fix: 'vou pensar' → REAGENDAR:1 pergunta melhor dia FIX
31/03/2026 actionParser.ts
O que estava errado
"Vou pensar" era tratado como REAGENDAR:7 (7 dias de espera) e a IA não perguntava o melhor dia para retomar contato — perdendo a oportunidade de engajar o lead enquanto ainda estava quente.
Correção
"Vou pensar" agora gera REAGENDAR:1 (amanhã) com a pergunta: "Qual o melhor horário pra eu te mandar uma mensagem amanhã?" — mantendo o lead engajado e com data de retorno definida.
❌ Como era antes
Rita disse "vou pensar" → REAGENDAR:7. Recebeu mensagem de follow-up 7 dias depois sem que a IA tivesse perguntado o melhor dia, perdendo o momento de engajamento enquanto o assunto ainda estava fresco.
✅ Como deve ser agora
Rita diz "vou pensar" → REAGENDAR:1 + IA pergunta "Qual o melhor horário pra eu te mandar uma mensagem amanhã?" → Rita responde com horário → retorno no dia seguinte no horário certo, com muito mais chance de resposta.
Arquivos
src/parsers/actionParser.ts
#11
fix: detect future intent before triggering RESERVAR FIX
30/03/2026 actionParser.ts
O que estava errado
Quando o lead dizia "vou comprar semana que vem" ou "preciso ver com meu marido primeiro", o parser detectava intenção de compra e disparava RESERVAR imediatamente — pulando o agendamento e pressionando o lead antes da hora.
Correção
Detecção de intenção futura tem prioridade sobre RESERVAR. Se a frase contém marcador temporal futuro ("semana que vem", "depois", "precisar verificar") antes da intenção de compra, vai para REAGENDADO em vez de RESERVAR.
❌ Como era antes
Graça (551497326011) disse "me espera até amanhã, aí pesso um" → actionParser detectou intenção de compra ("pesso um") → disparou fluxo de pagamento (RESERVAR) imediatamente. Graça ficou confusa recebendo link de pagamento antes de confirmar.
✅ Como deve ser agora
Graça diz "me espera até amanhã, aí pesso um" → marcador temporal futuro ("espera até amanhã") tem prioridade → REAGENDAR:1. IA responde combinando o retorno para amanhã. Graça só recebe o fluxo de pagamento quando confirmar na volta.
Arquivos
src/parsers/actionParser.ts
#10
fix: add 'próxima semana' to SCHEDULING_PATTERNS FIX
30/03/2026 actionParser.ts
O que estava errado
"Próxima semana" não era reconhecido como intenção de agendamento nos SCHEDULING_PATTERNS, então o lead não ia para REAGENDADO quando dizia isso — continuava no fluxo normal como se nada tivesse dito.
Correção
"Próxima semana" e variações ortográficas adicionadas aos SCHEDULING_PATTERNS do actionParser.
❌ Como era antes
IA respondia "Te chamo na próxima semana então 😊" mas actionParser não reconhecia "próxima semana" → REAGENDAR nunca disparava como fallback. Suely Duarte, Elisabete, Nice, Edleuza e Valdirene ficaram sem tarefa de retorno — ninguém retornou o contato.
✅ Como deve ser agora
IA responde "Te chamo na próxima semana então 😊" → actionParser detecta "próxima semana" → REAGENDAR:7 dispara → tarefa "Retomar contato" criada para daqui 7 dias. Lead recebe o retorno combinado.
Arquivos
src/parsers/actionParser.ts
#9
fix: despedida educada → ENCERRAR em vez de REAGENDAR FIX
30/03/2026 actionParser.ts
O que estava errado
Quando o lead dizia "obrigada", "tá bom", "até logo" etc., o actionParser interpretava como "não há urgência" e gerava REAGENDAR — agendando follow-up para um lead que simplesmente estava se despedindo.
Correção
Padrões de despedida educada mapeados explicitamente para ENCERRAR com graceful exit, em vez de REAGENDAR.
❌ Como era antes
Sônia Machado (551199072562) disse "agradeço sua atenção, mas não tenho interesse no momento" → actionParser detectou hesitação → REAGENDAR:7. Sônia recebeu follow-up uma semana depois mesmo tendo dito não claramente.
✅ Como deve ser agora
Sônia diz "agradeço sua atenção, mas não tenho interesse" → ENCERRAR com resposta "Tudo bem Sônia! Se mudar de ideia, estarei aqui 🤍". Hesitação sem despedida ("vou pensar") → REAGENDAR:7. Sônia não recebe mais follow-up indesejado.
Arquivos
src/parsers/actionParser.ts
#8
fix: FU1 dedup avança para FU2 quando lead já respondeu FIX
30/03/2026 proactiveService.ts
O que estava errado
Quando o lead respondia ao FU1, o proativo ainda enviava FU1 novamente porque a deduplicação era feita apenas por conteúdo fixo ("Nome?") — sem verificar se o lead já havia respondido ao FU1 anterior.
Correção
Dedup de FU1 agora verifica se existe resposta do lead após o FU1 no histórico. Se sim, avança direto para FU2 — evitando repetir a mesma pergunta para quem já respondeu.
❌ Como era antes
Sonia Braga (552175178125) respondeu ao FU1. Na próxima vez que o cron rodou, dedup detectou que FU1 já existia no histórico e simplesmente encerrou — sem criar FU2. Lead ficou em limbo sem próxima tarefa de retorno.
✅ Como deve ser agora
Sonia Braga responde ao FU1 → cron roda → dedup detecta FU1 no histórico E resposta do lead depois → avança e cria FU2 (4h) em vez de encerrar. Lead continua no fluxo de follow-up corretamente.
Arquivos
src/services/proactiveService.ts
#7
docs: update CLAUDE.md session context DOCS
30/03/2026 CLAUDE.md
O que foi feito
Atualização do arquivo de contexto de sessão CLAUDE.md com o resumo das correções e decisões técnicas das sessões anteriores. Sem mudanças de código — apenas documentação interna do agente.
❌ Como era antes
CLAUDE.md estava desatualizado após os fixes 25 (REAGENDADO smart check) e 26 (proativo respeita planilha). Contexto de sessão incorreto podia levar o agente a tomar decisões baseadas em comportamento já corrigido.
✅ Como deve ser agora
CLAUDE.md reflete as correções dos fixes 25 e 26 — o agente tem contexto correto sobre como REAGENDADO smart check funciona e como o proativo respeita a planilha antes de enviar FUs.
Arquivos
CLAUDE.md
#6
fix: proativo respeita REAGENDADO da planilha FIX
30/03/2026 proactiveService.ts
Caso real — Vanda
Vanda foi reagendada (stage REAGENDADO na planilha), mas o histórico Redis não tinha a tag [REAGENDAR:]. Como o proativo só checava a tag Redis, enviou FU1, FU2 e FU3 indevidamente — ignorando o reagendamento combinado.
Correção
Proativo agora checa sl.stageV2 === 'REAGENDADO' direto na planilha antes de enviar qualquer FU. Re-engajamento só é permitido se a tarefa "Retomar contato" estiver vencida.
❌ Como era antes
Vanda foi reagendada (coluna E = REAGENDADO na planilha), mas histórico Redis não tinha tag [REAGENDAR:]. Proativo ignorou o stage da planilha e enviou FU1, FU2 e FU3 — interrompendo um reagendamento combinado com a cliente.
✅ Como deve ser agora
Vanda está REAGENDADO na planilha → proativo verifica stageV2 diretamente → skip (não envia FU). Só re-engaja quando a tarefa "Retomar contato" estiver vencida, respeitando o acordo combinado com a Vanda.
Arquivos
src/services/proactiveService.ts
#5
fix: REAGENDADO smart check — emoji/ok não cancela agendamento FIX
30/03/2026 messageRouter.ts
Caso real — Maria de Lourdes
Maria de Lourdes mandou uma rosa 🌹 após ser reagendada. O messageRouter interpretou a mensagem como "lead voltou" e tirou ela do REAGENDADO — voltando para EM_CONVERSA como se fosse um lead novo. A IA voltou a vender do zero.
Correção
messageRouter avalia o conteúdo da mensagem antes de transitar de REAGENDADO:
Casual (emoji, "ok", "obrigada", ≤3 chars) → mantém REAGENDADO
Real (perguntas, interesse, texto substantivo) → volta para EM_CONVERSA
❌ Como era antes
Maria de Lourdes estava reagendada para semana seguinte. Mandou emoji 🌹 por engano → messageRouter interpretou como "lead voltou" → REAGENDADO cancelado → IA voltou ao funil de vendas e mandou oferta novamente.
✅ Como deve ser agora
Maria de Lourdes manda 🌹 enquanto está REAGENDADO → messageRouter detecta mensagem casual (emoji, ≤3 chars) → comportamento ignorado, lead permanece REAGENDADO. IA não processa, não responde com oferta.
Arquivos
src/handlers/messageRouter.ts
#4
fix: legacy check + AGUARDANDO_PAGAMENTO + métricas vendas + Kommo webhook nome FIX
30/03/2026 messageRouter.ts · dashboardApi.ts · kommoAdapter.ts
4 fixes em um PR
  • Legacy lead check: leads criados no Kommo mais de 24h antes da primeira mensagem Redis eram ignorados silenciosamente — sem retorno para o lead. Corrigido para detectar e não responder (comportamento correto para legados reais)
  • AGUARDANDO_PAGAMENTO: transições inválidas removidas — REAGENDADO e EM_CONVERSA não podiam mais regredir de volta a partir deste stage
  • Métricas de vendas: 3 novos cards no dashboard (Vendas, Taxa Leads→Vendas, Taxa QF→Vendas)
  • Kommo webhook nome: getLeadById não retornava contatos embedded → lead aparecia como "Eii Lead!!" em vez do nome real. Fix: parâmetro ?with=contacts + busca nome via API
❌ Como era antes
Lead criado no Kommo em janeiro mandava mensagem em março → IA respondia como se fosse lead novo, mandava abertura. Lead Deuzelena (15/02) recebeu FU1 "Oi tá aí?" sem abertura. Lead em AGUARDANDO_PAGAMENTO podia regredir para REAGENDADO se mandasse "te mando amanhã". Lead aparecia como "Eii Lead!!" sem nome real.
✅ Como deve ser agora
Gap Kommo >24h antes do Redis → lead detectado como legacy → skip (sem resposta). AGUARDANDO_PAGAMENTO não aceita transições para REAGENDADO nem EM_CONVERSA. Nome real do contato buscado via ?with=contacts — lead recebe "Eii Deuzelena!!" com nome correto.
Arquivos
src/handlers/messageRouter.ts src/routes/dashboardApi.ts src/adapters/kommoAdapter.ts
#3
fix: reagendado indevido + proativo FU step correto FIX
30/03/2026 actionParser.ts · proactiveService.ts
2 bugs corrigidos
  • Bug 1 — Reagendado indevido (caso Elizete): o actionParser interpretava o campo nextTaskDays do Operator como REAGENDAR mesmo sem uma ação explícita de reagendamento. Qualquer tarefa com prazo virava REAGENDADO erroneamente. Fix: nextTaskDays só gera REAGENDAR se o Operator incluir ação REAGENDAR explícita no array de actions.
  • Bug 2 — Proativo FU step errado: o proativo assumia FU2 hardcoded em vez de ler o FU step real da planilha. Fix: proativo lê a coluna FU Step da planilha para saber em qual passo está.
❌ Como era antes
Elizete recebia nextTaskDays: 7 no JSON do Operator → IA marcava automaticamente como REAGENDADO mesmo sem intenção de agendar. Proativo enviava sempre FU2, ignorando o FU step real da planilha — lead em FU3 recebia FU2 duplicado.
✅ Como deve ser agora
nextTaskDays só gera REAGENDAR se actions[] contiver explicitamente "REAGENDAR". Proativo lê a coluna FU Step da planilha antes de enviar — lead em FU3 recebe FU3, não FU2.
Arquivos
src/parsers/actionParser.ts src/services/proactiveService.ts
#2
fix: exclui leads teste das métricas diárias FIX
30/03/2026 dashboardApi.ts
O que estava errado
Leads de teste (Thiago — final 4124 e Cassio — final 0808) apareciam nas métricas diárias do dashboard e distorciam os números reais de performance.
Correção
Filtro por sufixo de telefone adicionado no endpoint /api/metrics/daily. Telefones terminados em 4124 e 0808 são excluídos das contagens.
❌ Como era antes
Thiago (4124) e Cassio (0808) apareciam nas métricas diárias. Um teste feito por Cassio contava como "venda do dia". Impossível saber se os números de conversão eram reais ou inflados por testes.
✅ Como deve ser agora
Thiago (4124) e Cassio (0808) fazem testes → leads de teste são excluídos de todas as métricas. Dashboard mostra apenas leads reais — vendas do dia, taxa de conversão e Quase Fechando refletem performance real.
Arquivos
src/routes/dashboardApi.ts
#1
feat: painel de métricas diárias no dashboard FEAT
30/03/2026 public/index.html · dashboardApi.ts
Contexto
PR do Cassio. O dashboard só mostrava uma lista de leads — sem nenhuma visão de performance diária. Impossível saber como o dia estava indo sem contar na mão.
O que foi adicionado
  • Leads Novos do dia — total de leads que entraram hoje
  • Quase Fechando — leads em stage RESERVADO ou AGUARDANDO_PAGAMENTO
  • Vendas — leads em PAGAMENTO_CONFIRMADO ou além
  • Taxa Leads → Vendas — percentual de conversão geral
  • Taxa QF → Vendas — percentual de conversão de "quase fechando" para venda
Novo endpoint criado
Endpoint GET /api/metrics/daily criado em dashboardApi.ts agregando os dados da planilha em tempo real.
❌ Como era antes
Dashboard só listava leads individualmente. Para saber quantas pessoas compraram hoje era necessário contar manualmente na planilha. Impossível ter visão de performance do dia em tempo real.
✅ Como deve ser agora
Dashboard exibe cards automáticos: Leads Novos do dia, Quase Fechando, Vendas, Taxa L→V e Taxa QF→V — atualizados a cada refresh. Cassio e Thiago veem a performance do dia sem precisar abrir a planilha.
Arquivos
public/index.html src/routes/dashboardApi.ts
Nenhum PR encontrado para este filtro.