Studio76 Development Board

Last updated: 2026-04-30 — 🧹 Cleanup KANBAN: removido item #5 (Migração Hetzner — DONE 30/04 manhã); item #4 atualizado pra refletir tamanho real do index.ts (16.156 linhas, era 11.120 no audit 8/abr — cresceu +45% em 22 dias); eliminado bloco "Blocked" (Bradesco CNAB 240 cancelado); 8 crons financeiros migrados pro cloudvero ou desativados (commit 0cdbd94 — Phase A/A.5/B + 3 obsoletos). Renumeração P1: Impulsionamento #5, Marketing #6, Recrutamento #7, Lead Bot #8, CRM Próprio #9, ERP Próprio #10. Antes (29/04 noite): 🚚 MIGRAÇÃO COMPLETA: bots no Hetzner cloudvero (CPX31 Ashburn, webhook https://studio76.duckdns.org/webhook, DuckDNS+nginx+Let's Encrypt). Auto-deploy git push preservado via cron 1min cloudvero. Audit semanal silent-on-success. studio76-server: bots stopped+disabled. Antes (28/04): 🤖 Studio Lead Bot — plano v2 congelado com Yara (item #8): wizard atual era monocaso, substituído por intent-classifier com 9 buckets cobrindo todos os cenários reais que Yara atendia manualmente (compra/aluguel/captação/placa/recrutamento/verificação corretor/reclamação/B2B/atendimento humano). Rodízio de captação backfilled da planilha Yara (38 corretores), timeout 15min, recrutamento 100% automatizado com relatório diário pra Suzana, verificação de corretor expõe nome+CRECI+telefone+pings Samuel. 5 templates HSM novos a submeter. Workflow YouTube/Fotos da captação delegado pro botjuridico — kickoff em whatsappbot/docs/planning/captacao-midia-workflow-kickoff.md. Antes (26/04): 🎯 CRM próprio (StudioImob/SmartyDeed) substituindo Pipeimob elevado a P1 estratégico (item #9) — consolida itens #28 e #32 sob direção única, meta: Mês 3 cancelar Pipeimob. 🤖 Bot pré-atendimento leads adicionado ao backlog P1 (WhatsApp +55 11 97345-7166). 📊 Operations Dashboard ao vivo em /dashboard com KPIs de pipeline, leads por portal, anúncios com melhor desempenho, tempo de resposta por corretor. 📋 KANBAN live em /kanban. Git hooks post-commit+pre-push sincronizam KANBAN.md com servidor automaticamente. Antes (25/04 noite, 2ª rodada): 🛠️ /cobrar — 3 fixes commit 324a815 (a) tag #parcela:N correto agora — parcela persistia perdida ao passar pelo seletor de pagador; (b) consolidação de transfers no webhook (debounce 30s — 1 mensagem com checklist em vez de N isoladas); (c) tabela suppliers criada no payments.db (zera 6 stacks ruidosas por /cobrar). Antes (25/04 noite, 1ª rodada): 🔌 Stark Bank webhook ressuscitado — apontava pra hostname Tailscale antigo (rab2b6aa, HTTP 000); reapontado pra tail92b8aa (HTTP 200, mesmo do Meta). Handler /webhook/starkbank completo desde antes mas nunca rodou em prod por isso. Cron monitor_split_1080_21.py (12h+18h seg 28/04) instalado como rede de proteção independente. Backlog P2 derivado: consolidar 7 msgs de transfer em 1 + corrigir tag #parcela:N. Antes (25/04 manhã): 🛠️ /cobrar — 3 fixes deploy + commit dc58545: (a) Drive duplicatas — findDealFoldersByCode plural + iter-all em ensureCCVExtractedNow (deals legados podem ter 2-3 pastas com mesmo prefixo, bot agora varre todas); (b) Extractor enriquecido — Haiku cospe endereço completo + valor de venda do imóvel, persiste em deal_property + deal_values.property_value; (c) UX pagador interativa — 2 candidatos vira 3 botões, 3-10 vira lista interativa, separador + retrocompat com ,. Validado e2e em 1079-12. Antes (24/04): 🔌 Assertiva creds plumbed + 🆕 Hetzner VPS provisionada. Antes (23/04): 🔧 Estoque Vivo — fix pré-piloto (chown logs, dedup MIN(id), HSM APPROVED). Antes (18/04): 🚀 Sprint 1+2 deployed + /dd Assertiva A+B em produção (v29).
WIP Limit: 2 (max items in "In Progress" at once)
Rule: Open this file every morning before writing code

Priority Definitions

AUDIT FINDINGS — Apr 8 2026 (server-verified)

Full repo audit: bot UX, proactivity, logs, Pipeimob sync, StudioImob, production readiness.
Server inspected via SSH — bot is UP and healthy.

Production Status (VERIFIED)

Scorecard

Issues to Address

In Progress (max 2)

[P1] Proactive Engagement System (Phase 2.5 MVP)

• Started: 2026-04-08
• Why: #1 adoption blocker. 6 active users out of 57 corretores. Without proactive "mind-reading" UX, agents default to Pipeimob.
• What:
• [ ] Post-command next-step buttons (e.g., after /checklist → [Run DD] button)
• [ ] State-transition nudges (docs complete → "Run DD?"; DD done → "Generate CCV?")
• [ ] WhatsApp list messages for multi-option selections (4+ options)
• [ ] Persist wizard sessions in SQLite (not in-memory)
• [ ] Abandoned wizard re-engagement (24h nudge)
• [ ] SDR lead follow-up scheduler (24-48h re-engagement)
• Definition of Done: After each major action, bot suggests next step with tap-to-act button. Wizard survives bot restart.
• Effort: 6-8h
• Ref: whatsappbot/docs/Fase-2.5-Engajamento-Proativo-StudioImob.pdf

[P1] QuintoAndar Tech-Match Sprint — Build Competitive Features

• Started: 2026-04-08
• Ref: operations/quintoandar-tech-competitive-analysis.md
• Why: QuintoAndar's tech features are all buildable with Claude + existing APIs. Keep full 6% commission instead of platform split.
• High-priority items:
• [ ] AI property search via WhatsApp — natural language queries using Claude + iList/iConnect data
• [ ] Digital proposal/counter-offer flow — structured WhatsApp messages with accept/reject/counter
• [ ] Visit scheduling via bot — corretor sends availability, buyer picks slot (/agendar)
• [ ] Financing simulation in bot (/financiamento [valor] [entrada] [prazo])
• [ ] Auto-generate listing descriptions from property photos (Claude Vision)
• Definition of Done: /buscar, /proposta, /agendar commands working end-to-end
• Effort: 8-12h per feature
• Key insight: Correspondente bancário revenue is royalty-free (clause 4.8) — untapped revenue

Testing (awaiting validation)

[P1] OCR Improvements (6 Phases) — CODE COMPLETE, ACTIVELY WORKING

• Started: 2026-03-29
• Status: All 6 phases deployed and running on server (v22). Matrícula extraction verified in logs:
• Apr 8 09:58: Matrícula 398.899 — 1 proprietário, 3 registros, 0 ônus (deal_id=137)
• Auto-assign: BUTTERFLY EVEN EMPREENDIMENTOS → VENDEDOR (matrícula-based)
• CrossRef alert: 1 divergência CRÍTICA automatically flagged
• Remaining: Broader e2e test with CNH + multiple doc types across more deals
• Definition of Done: Send CNH + matrícula for a deal → bot auto-detects deal, extracts data, saves with correct role

[P1] CCV Contract Auto-Revision

• Started: 2026-03-20
• Blocked by: Dr. Wilton's schedule
• Next follow-up: 2026-04-10

[P2] Halo Effect — Canal Pro algoritmo merit-based (deployed 27/04)

• Started: 2026-04-27
• Status: Em produção. Plano Grade Total ativo (4 PREMIERE_1 + 20 SUPER_PREMIUM + 76 PREMIUM + 200 STANDARD = 300). destaque.py reescrito com pesos halo effect: BELOW_MARKET 40→65, HIGH_CTR=25 (≥4%, mín 30 views), HIGH_VOLUME=10 (≥5 leads). Política por tier: PREMIERE_1 e top-16 SUPER_PREMIUM = mérito puro; bottom-4 SUPER_PREMIUM e PREMIUM = mixed (mérito + fairness). Backup: destaque.db.bak-20260427-*.
• Baseline 24/04 (algoritmo antigo): lead_rate_30d 3,28% / quality_score 9,4 / 223 ativos
• Hipótese: halo effect → CTR sobe na conta inteira (incluindo STANDARD) → lead rate sobe → quality score sobe
• Schedule de measurement:
• 04/05 — early-check 1 semana (estabilidade operacional)
• 18/05 — treatment Canal Pro 3 semanas (lead rate 30d estabilizado)
• Definition of Done: Δ lead_rate_30d ≥ +0,3pp E Δ quality_score ≥ +0,3 → halo validado, próxima iteração eleva pesos. Caso contrário: rollback ou manter + estender medição.

[P2] Halo Effect — extensão para Chaves na Mão (CnM)

• Started: 2026-04-27
• Status: Aguardando steady-state do tráfego CnM (começou efetivamente 14/04, ainda em ramp-up). PDF de 27/04: 21.134 views / 955 cliques (CTR 4,5%) / 45 contatos (contact rate 0,21%) — não é baseline limpo.
• Constraint: CnM tem apenas 1 tier binário (30 destaques de 300 anúncios) e não expõe métricas por imóvel — measurement só conta-nível agregado via PDF do dashboard.
• Schedule:
• 11/05 — baixar PDF baseline limpo + aplicar pesos merit-based no cnm_generator.py + registrar T0
• 01/06 — treatment measurement 3 semanas + cross-check com Canal Pro
• Definition of Done: Δ contact rate ≥ +0,05pp E Δ CTR ≥ +0,3pp → validar; cross-check com Canal Pro permite separar halo effect transversal vs portal-específico.

Backlog (ordered by priority — post-audit)

P1 — Critical Path (This Week)

0. Canal Pro — Integração Própria via API ⚡ PRIORIDADE MÁXIMA
   - Motivo: A integração atual via iList/iConnect NÃO permite:

   • Escolha manual dos anúncios em destaque e exclusivos
   • Edição/melhoria dos anúncios (filtros, características do imóvel)
   • Exemplo: imóvel tem Lavanderia, mas aparece apenas na descrição — não como filtro pesquisável pelo comprador
   • Decisão: Desativar integração iList/iConnect no Canal Pro e construir integração própria via API
   • Progresso (FASES COMPLETAS):
   • [x] FASE 0: Pesquisa VRSync, plano, CEO PDF
   • [x] FASE 1: MVP XML feed, 232 listings, 8.367 fotos, systemd + cron
   • [x] FASE 2: Features (2.447 tags, 150+ mappings PT→EN), Rich Descriptions
   • [x] FASE 3: Smart Destaque Rotation (SQLite, scoring, pins, 6 API endpoints)
   • [x] FASE 4: AI Descriptions (Claude Sonnet 4, 232/232 geradas, avg 2.175 chars, 0 erros)
   • [x] FASE 5: Auditoria + Monitoramento — Quality Score 93.8/100 (A+), fixed "Desconhecido" (32 agentes individuais no XML), monitor.py (scoring, image testing, history), canal_pro_scraper.py (Playwright + 2FA), pipeline Step 5 auto-monitor
   • [x] FASE 6: iList Auto-Refresh + Price Bump + Full Sync Pipeline
   • refresh_ilist_cache.py — API-based cache refresh (substituiu exportação CSV manual), 221/221 items
   • price_bump.py — rotação quinzenal +R$100 venda / +R$10 locação (refresh timestamps)
   • run-full-sync.sh — pipeline diário 6am: cache refresh → enrich → generator → cnm → restart → validate
   • WhatsApp monitoring: template alerta_sync_canal_pro 24/7 alerts on sync failure
   • Tailscale Funnel: reativado como público (estava "tailnet only")
   • Escopo restante:
   • [x] Canal Pro Auto-2FA: canal_pro_auto_login.py — login automático com Gmail API polling (código 2FA extraído em <1s)
   • [x] Integration URL reconfigurada: iList removida por Samuel (Apr 9), URL feed reconfigurada automaticamente via Playwright
   • [ ] Sync bidirecional: alterações no Canal Pro ↔ bot
   • [ ] WhatsApp bot commands: /destaque [imóvel], /anuncio [imóvel]
   • Git: 70fc0a1 (latest) | Feed: https://studio76-server.tail92b8aa.ts.net/feed/vrsync.xml
   • Audit Results (Apr 15 2026):
   • 221 anúncios ativos (cache refresh via API — contagem atualizada), 8.367+ fotos
   • 232/232 AI descriptions, avg 2.178 chars
   • 32 agentes únicos (202 com nome individual, 28 fallback escritório)
   • 0 image errors (50 amostras testadas)
   • Feed acessível local + externamente via Tailscale Funnel (público)
   • CnM painel: 232 Ativos, 30 Destaques, 2 Sem Fotos
   • Status: vrsync.xml 2.167 KB (221 anúncios) + chavesnamao.xml 2.044 KB (221 anúncios), 0 erros, serviço ativo, monitor diário + WhatsApp 24/7

1. Estoque Vivo — Manutenção Contínua do iList via WhatsApp ⚡ EM ANDAMENTO (Sprint 1+2 entregues)
   - Motivo: 85 de 215 imóveis (39%) têm validade expirada no iList; 14 com mais de 1 ano de atraso. Studio76 paga anúncios em portais para imóveis que podem não estar mais disponíveis → custo indevido + risco de propaganda enganosa.
   - Solução: loop eterno semanal de 4 fases via WhatsApp bot:

   • Fase 1 — Status (seg 09h): wizard pergunta imóvel por imóvel [ATIVO] [VENDIDO] [RETIRADO]. Não respondido em 7 dias → Studio76 muda status pra "Expirado" no iList (script autorizado). ✅ DEPLOYED 2026-04-17
   • Fase 2 — Validade (trigger após F1): renova dataValidade do contrato de exclusividade. ✅ CODADA 2026-04-18 (demo validado, deploy feito, aguardando piloto real)
   • Fase 3 — Autorização de Preço (trigger após F2): enquete se proprietário autoriza ajustes. ✅ CODADA 2026-04-18 (2 telas: conversou? → autorização? → % por texto se "pode reduzir")
   • Fase 4 — Bump (diário 06h no feed): ajusta preço dos imóveis confirmados ATIVOS + contrato expirado (Studio76 como corretor convencional). ⏳ pendente
   • Mensagem de fechamento (princípio fix-in-chat): ao final do wizard, bot envia resumo consolidado por imóvel + reforço "Tudo gravado no iList. Você não precisa abrir o sistema". Falhas no iList aparecem com ⚠️ + alerta auto pra Carine.
   • Exceção à regra iList READ-ONLY → revisada: isolamento por corretor (CLAUDE.md atualizado 2026-04-17). Estoque Vivo escreve apenas em 3 campos: status, dataValidade, valor. Captação tem whitelist própria. Outros módulos seguem ownership por agent_code.
   • Abstração: corretor para de abrir iList pra manutenção de estoque — bot vem até ele e age por ele.
   • Status atual: 31/31 testes verdes na suite do wizard (46/46 contando todos os módulos estoque-vivo). Demo Fase 1+2+3 rodado no WhatsApp do Elie (5511994955337) com 3 caminhos: vencido→renovar, vigente→pula F2, vencido→convencional.
   • Roadmap atualizado:
   • Sprint 0 (17/04): template HSM Meta + ilist-updater.service.ts + exceção em CLAUDE.md ✅
   • Sprint 1 (17/04): Fase 1 + auto-inativação + 4 alertas Carine + cron deployed ✅
   • Sprint 2 (18/04): Fase 2 (Validade) + Fase 3 (Preço) + mensagem final consolidada ✅
   • Sprint 3 (próximo): Fase 4 bump + piloto com 33 corretores + ativação cron semanal de Fase 1
   • Diagnóstico 23/04 (piloto real 20/04 NÃO disparou): cron rodou às 09:00 mas /home/egk/whatsappbot/logs/ era root:root 755 → bash não criou log → comando abortou. Zero ciclos reais no banco (só 3 demos 18/04). Corrigido: (a) sudo chown egk:egk no logs/, (b) dedup por MIN(id) em campaign-runner.ts (resolve 7 duplicatas de agent_code, incluindo 1067 Luciana≠Alex e 1068 Arnaldo≠João), (c) template HSM estoque_vivo_confirmacao_semanal confirmado APPROVED via Graph API. Dry-run pós-dedup: 33 corretores únicos, 218 imóveis, 0 erros. Próximo disparo real: segunda 27/04 09:00.
   • Decisões pendentes: política de bump %/valor, período de maturação, escalonamento piloto.
   • Ref: estoque-vivo/plano.md · whatsappbot/src/services/estoque-vivo/
   • Effort: Medium restante (Sprint 3 + piloto) | Impact: High (reduz custo de anúncios indevidos + agiliza venda de imóveis estagnados)

2. CEO Financial Dashboard via Bot
   - Cash flow view, simplified DRE, overdue accounts — delivered as /financeiro command
   - MCP servers already exist (Granatum + StarkBank) — this is mostly prompt engineering + formatting
   - CEO explicitly requested this. Highest visibility item.
   - Effort: Medium | Impact: High
   - Ref: implementation-plan-2026.md item 1.1.3

3. External Health Monitoring
   - Add Uptime Robot (or similar) hitting /health endpoint
   - WhatsApp/email alert when bot goes down
   - Effort: Low (1h) | Impact: High (prevents silent downtime)

4. Split index.ts into Handler Modules
   - Extract from 16,156-line monolith (era 11.120 no audit 8/abr — cresceu +45% em 22 dias) into: command.handler.ts, document.handler.ts, wizard-complete.handler.ts, intent.handler.ts
   - Reduces risk of regression bugs, enables parallel development
   - Effort: Medium (2 days) | Impact: High (maintainability)

5. Impulsionamento Digital — automação e tracking 🆕 P1 (24/04)
   - Auditoria de gastos com impulsionamento (Meta Ads, Google Ads, Canal Pro, OLX/Zap turbo) por imóvel/corretor
   - Reconciliação automática com Granatum (centro de custo "Impulsionamento", categoria 2535141)
   - Bot pode aceitar /impulsionar [imóvel] [budget] via WhatsApp (corretor solicita, sistema dispara)
   - Pendente: definir canais prioritários, política de subsídio Studio76 vs corretor, métricas de ROI por canal
   - Effort: TBD | Impact: High (controle de custo + atribuição de leads)

6. Marketing — estratégia e execução 🆕 P1 (24/04)
   - Plano integrado: branding Studio76 + conteúdo (Instagram, LinkedIn, blog), email marketing, eventos, SEO
   - Integração com bot: capturar leads em landing pages → roteamento automático ao corretor via WhatsApp
   - Tracking de fonte do lead até fechamento (Canal Pro/CnM/orgânico/indicação) para alocação de orçamento
   - Pendente: definir agência vs in-house, calendário editorial, ferramentas (RD Station? HubSpot? in-house?)
   - Effort: TBD | Impact: High (geração de leads + posicionamento de marca)

7. Recrutamento de Corretores — pipeline e onboarding 🆕 P1 (24/04)
   - Pipeline de captação de novos corretores (atual: 57 ativos no bot.db)
   - Diferencial Studio76 a comunicar: bot jurídico 24/7, automação financeira, dashboards, suporte técnico
   - Onboarding automatizado: /onboarding no bot → cadastro Pipeimob + iList + WhatsApp + treinamento + assinatura contrato Clicksign
   - Tracking de conversão: candidato → entrevista → contrato → primeira venda
   - Integração: site de carreiras, divulgação em RE/MAX network, indicações, eventos
   - Pendente: perfil ideal, comissionamento de indicação, material institucional
   - Effort: TBD | Impact: Very High (escalabilidade da operação depende de mais corretores produtivos)

8. Studio Lead Bot — WhatsApp +55 11 97345-7166 (PLANO V2 — intent classifier + 9 buckets) ⚡ P1 (28/04, plano congelado com Yara)
   - Número: +55 11 97345-7166 (WhatsApp Studio 76 Leads — separado do botjuridico)
   - Status atual: Cloud API liberada 27/04 (WABA 1508012434376521, phone ID 1134727406386158, CLOUD_API native). 6 templates HSM da v1 APPROVED. Bot rodando em studio76-server:4000 em modo SHADOW (Gmail watcher posta leads de chavesnamao+zap a cada 60s, bot registra mas não dispara mensagem). 22 leads no DB (5 BOT_GREETED, 14 NEW shadow, 2 QUALIFIED, 1 QUALIFYING).
   - Decisão estratégica (28/04 — Yara consultada): Wizard atual é monocaso (assume comprador querendo agendar visita). Substituir por classificador de intenção com 9 buckets cobrindo todos os cenários que a Yara atendia manualmente. Plano congelado, pronto pra codar.

### Arquitetura
- 2 entry points distintos:
- Email watcher (chavesnamao/zap/canalpro) → intent já claro = comprador de imóvel X → buyer-flow (wizard atual sobrevive)
- WhatsApp direto → intent desconhecido → intent-classifier (Claude Sonnet 4.6, system prompt com 9 buckets + few-shot da Yara) → sub-fluxo apropriado
- Suporte a mensagem livre + IMAGEM (Vision) desde o primeiro turno
- Menu fallback (list_reply Meta, até 10 itens) quando classificação ambígua

### 9 buckets de intent
1. Comprar imóvel → coleta região + valor + tipo → busca iList → roteia ao primeiro corretor ativo que aceitar
2. Alugar imóvel → idem 1
3. Anunciar/vender meu imóvel → coleta endereço + modalidade + foto → entra no rodízio de captação
4. Imóvel da placa → pede ENDEREÇO (placas Studio76 não têm código, confirmado Yara) → busca iList → se achar, roteia; se não achar, posta foto no grupo geral de corretores e escala Yara
5. Trabalhar como corretor → triagem inicial (nome, experiência, CRECI, região) → agenda entrevista com Nicolly → relatório diário pra Suzana
6. Falar com atendimento → escala Yara
7. Vendedor B2B oferecendo produto/serviço → declina educadamente
8. Verificação de corretor ("Fulano é da Studio?") → confirma nome + CRECI + telefone oficial; pinga Samuel "cliente X buscou confirmação do corretor Y"
9. Reclamação / quer falar com gerente → escala Samuel

### Rodízio de captação (bucket 3)
- Tabela captacao_rotation: 38 corretores na ordem da planilha Yara (SAMUEL → SUZANA → PAULA → NILZA → FRANCISCO → ... → EDSON), modalidade venda | locacao | ambos, cursor last_assigned_position ciclando, contador anual com backfill da planilha
- Fonte: docs.google.com/spreadsheets/d/1S9iE-AhCkJtvI4kjwPQUkXNdSiij6k8V aba "rodizio 2026" (compartilhada com eliekfouri@remax.com.br)
- Fluxo: bot identifica modalidade → próximo da fila compatível → HSM corretor_oferta_captacao com botões Aceitar/Recusar → timeout 15min sem responder = pula pro próximo → volta completa sem aceite = encerra cordial + escala Yara
- Distinção VENDA vs LOCAÇÃO: FRANCISCO/RODRIGO = ambos, KARINA = ambos+locação separada (planilha)

### Verificação de corretor (bucket 8)
- Bot busca nome no corretores.bot.db (57 ativos)
- Resposta confirma: nome + CRECI + telefone oficial. Não expõe foto/email/endereço
- Notifica Samuel via WhatsApp: "Cliente +55 XX XXXXX-XXXX buscou confirmação do corretor Fulano" (acompanhamento)
- Se nome não cadastrado → "Esse nome não está cadastrado conosco — atenção a possível golpe" + escala Samuel

### Recrutamento (bucket 5) — automação total, ZERO dependência de comando humano
- Robô faz triagem inicial e agenda entrevista com Nicolly (Nicolly continua entrevistando humanos depois)
- Confirmação automática de entrevista: bot agenda no Google Calendar da Nicolly + cria evento; depois do horário (~1h após) bot detecta status do evento (compareceu / no-show via heurística: foi confirmado, candidato respondeu lembrete prévio) — fallback: bot pinga Nicolly UMA mensagem com 2 botões (Compareceu / Não compareceu), 1 clique
- Detecção de saída da empresa: bot detecta inativação no corretores (sync diário do bot.db) — quando corretor some, conta como saída do mês
- Relatório DIÁRIO pra Suzana via WhatsApp (~18h):
- Candidatos novos hoje
- Entrevistas agendadas
- Entrevistas realizadas (compareceu)
- No-shows
- Saídas detectadas
- Template HSM: suzana_relatorio_recrutamento_diario

### Schema DB (novas tabelas)
- intent_classifications (lead_id, intent, confidence, raw_text/image_url, classified_at)
- captacao_rotation (position, corretor_id, modalidade, ativo, count_anual)
- captacao_offers (lead_id, corretor_id, status: pending/accepted/declined/timeout, offered_at, responded_at)
- recruitment_pipeline (lead_id, stage: new/triaged/interview_scheduled/attended/no_show, scheduled_with, scheduled_at, attended_at)

### Templates HSM novos a submeter (Meta, paralelo ao código)
1. corretor_oferta_captacao — UTILITY, botões Aceitar/Recusar
2. gerente_alerta_reclamacao — UTILITY
3. gerente_confirmacao_corretor — UTILITY (notificação Samuel)
4. suzana_relatorio_recrutamento_diario — UTILITY, 5 variáveis
5. corretor_lead_atribuido — UTILITY (buckets 1, 2, 4 quando bot acha corretor responsável)
6. nicolly_confirmar_entrevista — UTILITY, botões Compareceu/Não compareceu

### Sprints
- Sprint A (4-6h): classifier + buckets simples (5, 6, 7, 8, 9) + suporte a imagem (Vision) — funciona com templates v1 já aprovados
- Sprint B (4-6h): rodízio de captação (bucket 3) + buyer-flow refinado (1, 2) + bucket 4 (placa) + relatório diário Suzana — requer templates v2 aprovados (24-48h após submissão)
- Total: ~10-12h de código, 2-3 dias com aprovação de templates em paralelo

### Pendências antes de codar (resolvidas)
- ✅ Recrutamento: Nicolly continua entrevistando humanos, robô faz triagem + agendamento + relatório
- ✅ Verificação corretor: nome + CRECI + telefone OK, expõe ao cliente + ping pra Samuel
- ✅ Timeout captação: 15min
- ✅ Reclamação: escala Samuel
- ✅ Atendimento humano: escala Yara
- ✅ Especialista por região: não existe, qualquer ativo que aceitar primeiro
- ✅ Rodízio: planilha compartilhada com eliekfouri@remax.com.br

### Fora do escopo (delegado)
- Workflow YouTube/Fotos da captação (Yara processa quando corretor pega captação) → vai pro botjuridico (94728-9029) — kickoff em whatsappbot/docs/planning/captacao-midia-workflow-kickoff.md

• Effort: Medium-High (~12h código + 24-48h espera HSM) | Impact: Critical (substitui atendimento manual da Yara, libera Yara, captura 100% dos leads diretos 24/7)

9. CRM Próprio (StudioImob/SmartyDeed) substituindo Pipeimob — visão estratégica 🆕 P1 (26/04)

   • Tese: o CRM próprio Studio 76 (Laravel/Filament — smartydeed-alpha) já é robusto o suficiente para começarmos a substituir o Pipeimob como sistema central de gestão de transações imobiliárias. Esta linha amarra todas as iniciativas que hoje estão dispersas em P2 sob uma direção estratégica única: a Studio 76 vai parar de pagar e depender do Pipeimob.
   • Por que agora:
   • BUG-010 (3 ilhas de dados desconectadas) só piora à medida que corretores usam menos o Pipeimob — dados ficam fantasma, /status mente
   • API do Pipeimob é quase read-only (só /cadastrarcliente e /user_aprovacao escrevem), upload manual, lockout >30min com 15-20 chamadas rápidas — limita qualquer automação séria
   • Pagamos licença mensal de um sistema que não conseguimos integrar plenamente; com SmartyDeed temos custo marginal próximo de zero
   • Mesma lógica do C2S/Vetra (#8): sair de plataforma terceira fechada, ganhar dados próprios + integração nativa com bot, iList, Granatum, Stark Bank
   • Hierarquia decidida (memória feedback_pipeimob_fallback_only.md): iList (mãe, prevalece) > StudioImob/SmartyDeed (cérebro) > Pipeimob (espelho legado, fallback durante transição)
   • Cobrança de comissão (regra atualizada 26/04/2026): fonte de verdade passa a ser o CCV assinado, extraído pelo /cobrar (bot WhatsApp → Stark Bank PIX com split). A antiga regra "Pipeimob prevalece em comissão" foi REVOGADA — /cobrar está em produção, Gildasio usou hoje gerou PIX, validação final do split agendada para segunda 28/04. Após validação, declarar /cobrar 100% confiável e migrar todos os corretores. Memórias: feedback_cobrar_ccv_fonte_verdade.md, feedback_pipeimob_prevalece.md (atualizada), project_cobrar_autonomo.md.
   • Plano executivo já no board — esta linha consolida e eleva prioridade:
   • Item #28 "Bot SQLite como Source-of-Truth" (P2 → ler como executor de Fase 1)
   • Item #32 "Transição PipeImob → BD Próprio (Fonte Única de Verdade)" (P2 → executor de Fases 2-4, 3-4 sprints)
   • Memória project_migracao_studioimob.md — 5 fases (Sync Inteligente ✅, Bot como Entrada, Write-Back Pipeimob via Puppeteer, Espelho Funcional, Desligamento Natural)
   • Meta final (Mês 3+): corretores param de abrir Pipeimob. Bot WhatsApp + SmartyDeed Filament + iList suprem 100% das necessidades. Cancelamento da licença Pipeimob.
   • Conexão com #8 (lead-bot): o lead qualificado pelo bot vira deal automaticamente — destino do deal será SmartyDeed (CRM próprio), com Pipeimob alimentado em paralelo via write-back enquanto durar a transição. Toda nova feature de roteamento/dashboard nasce já apontada para a fonte interna, não para o Pipeimob.
   • Decisão pendente CEO: confirmar elevação dessa linha à P1 estratégica + autorizar início da Fase 2 (Bot como Entrada) com /novavenda no bot popular SmartyDeed direto.
   • Effort: Very High (3-4 sprints técnicos + 2-3 meses de operação paralela) | Impact: Critical (elimina dependência terceira mais cara da operação, unifica dados, desbloqueia automação plena)
   • Refs: itens #28, #32 do board; project_migracao_studioimob.md, plano-migracao-studioimob.md, plano-migracao-studioimob-ceo.pdf

10. ERP Próprio Studio76 — substituição progressiva do Granatum 🚧 P1 — F0 código pronto 01/05, falta executar bootstrap no cloudvero

    • Tese: o Granatum tem 4 problemas conhecidos que limitam nossa estratégia de automação — duplicatas estruturais (já forçaram o bank-statements/ paralelo), mensalidade que sobe sem entregar mais, contaminação por lançamentos de corretores, API/UI insuficientes para fluxos novos (DICT, splits, recorrências por regra, anexos Drive, dupla assinatura). Direção estratégica do CLAUDE.md raiz já prevê substituir SaaS travados (Pipeimob → SmartyDeed, C2S → bot próprio); Granatum entra na mesma lista.
    • Atores e papéis (decisão crítica 29/04):
    • Financeiro = só Elie + Samuel (Yara/Carine/Nicolly/Wilton NÃO operam — só solicitam via email)
    • Elie + Claude/agente: criam payment requests no Stark, lançam AP no ERP via WhatsApp
    • Samuel: segunda assinatura — aprova execução na web do Stark Bank (dual-sig nativo)
    • Solicitantes (Yara/Carine/Nicolly/Wilton): mandam email pra financeiro.studio76@gmail.com com cobrança/comprovante/dados PIX (recorrente Contabem + ad-hoc)
    • Princípios:
    • Dupla assinatura é nativa do Stark — usar starkbank.PaymentRequest (não replicar workflow no ERP)
    • Não-big-bang — dual-write Granatum durante 3 meses; cancelamento só após validação cruzada
    • WhatsApp-first para Elie — todas as decisões chegam via bot; painel web é só visualização/auditoria
    • Source-of-truth = bank statements — pagamento real define a verdade; lançamento contábil é consequência
    • NFS-e e Stark ficam como estão (já são próprios)
    • Contabem continua escriturando — ERP exporta SPED/CSV para ele
    • Stack proposta: PostgreSQL (sair de SQLite — multi-process write, audit trail, LGPD RLS), TypeScript em whatsappbot/src/erp/ (reuso services), painel admin Filament-PHP (mesma stack do StudioImob — coerência arquitetural), email scanner reaproveita contas-a-pagar/ MCP existente.
    • Fluxos operacionais (estado-alvo):
    • AP recorrente (Contabem/royalty REMAX/Caixa SIEMP/telecom): recurring_rules → cron diário cria draft → WhatsApp Elie aprova → PaymentRequest Stark → Samuel libera web Stark → webhook concilia
    • AP ad-hoc (Yara/Carine/Nicolly/Wilton): email financeiro.studio76@gmail.com → scanner parse → DICT validation → WhatsApp Elie aprova → PaymentRequest → Samuel libera → ERP responde solicitante por email com comprovante automático
    • AR (já 90% pronto): unificar fee_tracker.db + Stark Invoices em receivables + trigger NF
    • 7 fases (~30-35 dias dev concentrado, ou 3-4 meses em paralelo):
    • F0: Modelagem + migration cadastros Granatum (4d)
    • F1: AP recorrente próprio + dual-write Granatum (6d)
    • F2: AP ad-hoc via email scanner (5d)
    • F3: Bridge Stark PaymentRequest + webhook conciliação (4d)
    • F4: AR consolidado (5d)
    • F5: DRE/balancete v2 + plano de contas (6d)
    • F6: Auditoria + export Contabem (4d)
    • F7: Cancelar Granatum (~3 meses validação cruzada — ideal alinhar com cancelamento Pipeimob no mesmo trimestre)
    • Decisões fechadas (F0 — 01/05/2026):
      1. ✅ Postgres self-host no cloudvero (Docker, 127.0.0.1:5432, init em financial-services/erp/infra/)
      2. ✅ ORM Prisma (schema em whatsappbot/prisma/schema.prisma, npm scripts erp:import:*)
      3. ✅ Filament admin adiado pra F1.5 — F0 é só DB + import + scripts, sem UI
      4. ✅ CLAUDE.md raiz atualizado com "Granatum → ERP próprio" na lista de SaaS substituíveis
    • Decisões pendentes (não-bloqueantes — seguir Fase 1):
      1. Validar fluxo dual-sig com Samuel (UX da web Stark, frequência ~10-20 aprovações/semana)
      2. Janela de início F1 (antes/depois da migração StudioImob — capacidade de dev paralelo)
      3. Formato export Contabem (SPED ECD? CSV custom?) — resolver durante F6.
    • F0 — código pronto 01/05/2026 (commit pendente):
    • Infra Postgres: financial-services/erp/infra/{docker-compose.yml, initdb/01-extensions.sql, README.md}
    • Schema completo: whatsappbot/prisma/schema.prisma (15 modelos: AccountChart, CostCenter, Supplier, Customer, BankAccount, PaymentRequestInternal, Payable, Installment, RecurringRule, Receivable, Transaction, TransactionTag, TransactionEvent, Attachment, ImportRun)
    • 4 importers: whatsappbot/src/erp/scripts/import-granatum-{categorias,cost-centers,pessoas,lancamentos}.ts
    • Validação: whatsappbot/src/erp/scripts/validate-against-granatum.ts → gera financial-services/erp-validacao-f0-{stamp}.md
    • Helpers: prisma.service.ts, granatum-api.service.ts, import-runner.ts
    • npm scripts: erp:import:categorias|cost-centers|pessoas|lancamentos, erp:validate, prisma:migrate:*
    • F0 — execução cloudvero (próximo passo):
    • SSH cloudvero → gerar senha + /app/credentials/erp-postgres.env
    • docker compose up -d em financial-services/erp/infra/
    • DATABASE_URL no whatsappbot/.env
    • npx prisma migrate dev --name init + npx prisma generate
    • Rodar npm run erp:import:* na ordem (categorias → cost-centers → pessoas → lancamentos)
    • npm run erp:validate → conferir relatório
    • Riscos principais: webhook Stark falha silencioso (mitigação: cron reconciliação 6h/6h), 3.7k pessoas com dados sujos (mitigação: dedup CPF/CNPJ + match verified_suppliers), formato Contabem definido tarde (mitigação: SPED ECD é padrão CFC, baixo risco de rejeição).
    • Métricas: M1 100% recorrentes em dual-write; M3 divergência ERP×Granatum < 0.5%; M6 Elie não abre Granatum por 30d; M9 Granatum cancelado.
    • Effort: High (~30-35d dev) | Impact: Critical (elimina 2ª maior dependência SaaS depois do Pipeimob, desbloqueia automação financeira plena, controle total dos dados)
    • Refs: financial-services/PLANO-ERP-STUDIO76.md (plano completo), financial-services/bank-statements/ (base operacional), financial-services/CLAUDE.md (regras de pagamento), project_erp_proprio.md (memória), item #9 (CRM próprio — mesma filosofia)

11. Migração canal-pro-feed + dashboards studio76-server → cloudvero (decommission services físico) 🆕 P1 (01/05)

    • Motivo: descoberto 01/05 que /dashboard e /financeiro lêem bot.db e statements.db stale desde 30/04 (snapshots congelados na migração dos bots). Bot vivo escreve no cloudvero, dashboards no studio76 mostram dados de ontem e nunca mais atualizam. Solução é migrar canal-pro-feed/ (XMLs portais + algoritmos de melhora dos anúncios + 3 webpages) e bank-statements/ pro cloudvero, onde os dados vivos estão.
    • Estratégia URL dual (zero downtime): durante transição (~2 semanas), os 2 hostnames servem o mesmo conteúdo gerado no cloudvero. Reconfiguração de URL nos portais Canal Pro/CnM é feita um a um, sem urgência. studio76-server vira reverse proxy nginx (Opção B) apontando pro cloudvero — mantém URL antiga viva até último portal reconfigurar.
    • Hostname novo: bot.remaxstudio76.com.br (registrado GoDaddy 01/05, pending Registro.br até 7 dias). Apex livre pra futura landing page institucional.
    • Plano formal: operations/PLANO-MIGRACAO-CANAL-PRO-CLOUDVERO.md (12 fases, ~3h30 trabalho ativo, ~2 semanas wall clock).
    • Decisões finalizadas:
      1. Hostname dedicado bot.remaxstudio76.com.br (não DuckDNS)
      2. claude_cost_watchdog aposenta na Fase 9
      3. Soak Fase 6 = 72h (cobre run-full-sync + auto-login semanal + weekend)
      4. Reverse proxy Fase 7 = Opção B (nginx local no studio76, robusta)
      5. Backup off-site = Hetzner Storage Box (€3.20/mês, restic, daily 4h UTC)
    • Caminho de execução (~2 semanas):
    • Hoje–Quinta: Fases 0–5 (setup cloudvero + sync DBs + nginx + crons) usando DuckDNS como primary
    • Quando .com.br ativar (~até 7 dias): Fase 1.5 (DNS + cert SSL) + Fase 4.5 (webhooks Meta + Stark)
    • Sex–Seg: Fase 6 soak 72h
    • Semana 2: Fase 7 reverse proxy + Fase 8 reconfigurar Canal Pro
    • Semana 3: Fase 8 CnM + Fase 9 decommission + Fase 9.5 backup Storage Box
    • Fica no studio76-server (intencional): apenas sentinela-heartbeat.service (jail SmartyDeed escritório). Máquina não desliga, só sai de produção.
    • Critérios de sucesso: dashboards mostram dados frescos de hoje (não snapshot 30/04); Canal Pro + CnM continuam puxando feed normalmente após troca URL; crons rodam sem erro por 7 dias no cloudvero; git push continua atualizando ambos hostnames (auto-deploy preservado).
    • Riscos principais: Playwright/Chromium no cloudvero (~250MB install + headless); cookies Canal Pro renovam semanal via Gmail 2FA OAuth; ranking listings pode oscilar 24-48h após troca URL no portal.
    • Effort: Medium-High (~3h30 ativo) | Impact: Critical (de-risca SPOF físico + dashboards passam a mostrar realidade)

P2 — Efficiency & Automation (Next 1-2 Weeks)

3.5. Crontab cleanup pós-split deal 1080-21 ⏰ (gatilho: segunda 28/04)
- Após o monitor confirmar split funcional, remover do crontab do egk@studio76-server as 2 linhas one-shot (0 12 28 4 * e 0 18 28 4 * rodando monitor_split_1080_21.py) — senão re-disparam 28/04/2027.
- Effort: Trivial (5min) | Impact: Low (apenas higiene)

4. Contas a Pagar — End-to-end Gmail Flow
   - Connect Gmail scanner to financeiro.studio76@gmail.com
   - Test full pipeline: email → parse → supplier → Granatum entry
   - Effort: Medium | Impact: Medium
   - Ref: implementation-plan-2026.md item 1.1.6

4.1. Auto-AP via PDF no WhatsApp — classificador + OCR + preview 🆕 P2 (29/04)
- Tese: Elie/Samuel/Yara/Carine/Nicolly/Wilton mandam PDF de boleto/NF/cobrança no WhatsApp e o bot lança automaticamente em contas a pagar — sem comando, sem /. Risco zero porque Elie+Samuel aprovam pagamento real via dual-sig Stark; mandar PDF não dispara pagamento, só cria draft AP.
- Como funciona:
1. Document handler do bot intercepta PDF/imagem (já existe — usado em CCV, comprovantes, fotos)
2. Classificador zero-shot (Claude Haiku 4.5) decide tipo: {boleto, nfse, comprovante_pagamento, ccv, outro}
3. Se for boleto/NF/cobrança: roda OCR (já existe — OCR Improvements 6 Phases COMPLETE em Testing) + extrai linha digitável + valor + vencimento + CNPJ pagador
4. Lookup fornecedor (bot.db.verified_suppliers + DICT BACEN se chave PIX presente)
5. Cria draft em payment_requests_internal (ou MCP contas-a-pagar no estado-atual)
6. Devolve preview pro remetente: "Boleto Contabem R$ 1.571 vence 05/05. Confirma encaminhar pra aprovação? [Sim] [Editar valor] [Não, é outra coisa]"
7. Confirmado → entra na fila do Elie no botjuridico (mesma fila do email)
8. Confidence baixo → fallback "É boleto? [Sim] [Não]" antes de processar
- Público autorizado a mandar: Elie, Samuel, Yara, Carine, Nicolly, Wilton (lista whitelist por phone number no bot.db.users)
- Reuso: OCR pipeline existente (Testing), MCP contas-a-pagar (parsers + dedup + supplier lookup), document handler do botjuridico, DICT validation
- Diff técnico:
- Novo: classificador de tipo de documento (1 prompt Haiku)
- Novo: hook no document handler ANTES do roteamento atual (CCV/comprovante/etc)
- Novo: whitelist de remetentes em bot.db
- Novo: preview UX com botões inline
- Reuso: tudo o resto
- Encaixe estratégico: entrega antecipada da Fase 2 do ERP (#10) — começa escrevendo no MCP contas-a-pagar atual, troca destino pro Postgres novo quando ERP F2 chegar. Sem reescrever UX.
- Tradeoffs:
- ✅ Fix-in-chat puro — encaminha boleto no WhatsApp e clica Aprovar, zero email/comando
- ✅ Acelera ciclo Yara→pagamento de horas (email) pra minutos (WhatsApp)
- ⚠️ Classificador errado em PDF ambíguo → preview indevido (mitigação: confidence threshold + fallback "É boleto?")
- ⚠️ Volume alto de PDFs irrelevantes mandados por engano → ruído. Mitigação: silent-on-confidence-below-X (ignora sem responder)
- Decisões pendentes:
- Bot que recebe: botjuridico (94728-9029) ou número novo dedicado a financeiro? Recomendado botjuridico (Elie/Samuel/Wilton já usam; Yara/Carine/Nicolly entram via whitelist)
- Yara/Carine/Nicolly têm WhatsApp com botjuridico hoje? Confirmar phones em bot.db
- Roadmap:
- Fase A (~1d): classificador + hook + preview UX, escreve no MCP atual
- Fase B (~0.5d): whitelist remetentes + telemetria de classificação errada
- Fase C (junto com ERP F2): trocar destino pro payment_requests_internal Postgres
- Effort: Low-Medium (~1.5d Fase A+B) | Impact: High (substitui email pra solicitantes WhatsApp-first; alivia Yara/Carine/Nicolly/Wilton)
- Refs: item P1 #10 ERP Próprio Fase 2, MCP contas-a-pagar, whatsappbot/src/handlers/document.handler.ts

5. Granatum Categorization (100%)
   - Categorize all Granatum entries with correct cost centers
   - Effort: Medium | Impact: Medium
   - Ref: implementation-plan-2026.md item 1.1.2

6. Pipeimob → Granatum Commission Reconciliation
   - MCP tool: reconcile_pipeimob_granatum
   - Auto-compare commission data between CRM and accounting
   - Effort: Medium | Impact: Medium
   - Ref: implementation-plan-2026.md item 1.1.5

7. Bot UX Polish Sprint
   - Add typing indicators before long operations (DD, OCR, CCV)
   - Reduce message fragmentation ratio (4.1:1 → <2.5:1)
   - Add WhatsApp list messages (up to 10 options vs 3 buttons)
   - Confirmation before destructive state transitions
   - Extend conversation expiry from 2h → 4h
   - Effort: Medium | Impact: Medium

7.1. Abstrair comando /cobrar — natural language + auto-resolve (from session 2026-04-24 — Elie/Gildasio demo)
- Aceitar cobrar, cobrar comissão, cobrar parcela 2, gerar pix (sem / obrigatório) via intent classifier
- Auto-detectar parcela atual sem precisar p<N> quando há cronograma de parcelas no CCV + sync com pagamentos externos (Pipeimob legacy + Stark Bank histórico de invoices)
- Auto-resolver deal via:
(a) único deal do corretor em estado COMPLETE/SIGNING ✅ implementado 24/04
(b) extração do último deal mencionado na conversa
(c) deals com parcelas pendentes (cronograma vs invoices emitidos)
- Listar com botões interativos quando 2+ candidatos (em vez de pedir digitação)
- Validar CPF/CNPJ via DICT BACEN no momento da extração CCV → se algum não for chave PIX, perguntar chave alternativa via WhatsApp e atualizar verified_suppliers
- Backfill clicksign_document_key em deals legados via Pipeimob documentos_contrato (Pipeimob deprecation: one-shot script)
- Effort: Medium | Impact: High (Gildasio/Samuel/Carine sem precisar lembrar sintaxe)
- Ref: sessão 2026-04-24, plano project_cobrar_autonomo.md (5 fases concluídas), próximo passo refinamento UX

8. Planilha "Vendas do Mês" Auto-Alimentada (from Intake Log — Elie)
   - Sync bot deal data to Google Sheets automatically
   - Model: existing "VENDAS DO MES" + "PLANILHA UNICA COMPLETA" spreadsheet
   - Effort: Medium | Impact: High (management visibility)

P2 — Pipeimob → StudioImob Migration Enablers

9. Agent Onboarding Campaign ✅ PHASE 1 COMPLETE
   - ~~6 active users out of 57 corretores — need targeted WhatsApp outreach~~
   - Executed (Apr 10 2026):

   • [x] 33 individual audit PDFs generated (auditoria-pdfs-corretores/)
   • [x] 33/33 emails sent via Gmail API (zero errors)
   • [x] 3/3 WhatsApp PDFs sent to active brokers (Carine, Karina, Marcelo)
   • [x] Meta template auditoria_ilist_2026 created (PENDING Meta review, ID: 1502036048174090)
   • [x] /auditoria bot command deployed — brokers can request their PDF anytime
   • [x] Quick-reply handler for "Ver relatorio" / "relatorio" button clicks
   • Awaiting:
   • [ ] Meta template approval (~24-48h) → then python3 campanha_auditoria_corretores.py send-templates-prod
   • [ ] Monitor broker response rate (7-10 days)
   • [ ] Photo audit with Claude Vision after cleanup deadline (25/04/2026)
   • Effort: Low (template messages) | Impact: Critical (adoption is the bottleneck)

10. Diligência Prévia no Contrato de Gestão — com Dr. Wilton (from Intake Log — Elie)

    • Automate checklist/validation before signing new management contracts (gestões novas)
    • Similar to existing DD flow but for a different contract type (contrato de gestão)
    • Validações: matrícula, certidões negativas, situação fiscal do imóvel/proprietário
    • Parceiro jurídico: Dr. Wilton (definição dos critérios legais e checklist obrigatório)
    • Dependência: Reunião com Dr. Wilton para definir escopo de validações
    • Effort: Medium | Impact: Medium

P2 — QuintoAndar Tech-Match (from competitive analysis)

Ref: operations/quintoandar-tech-competitive-analysis.md
Strategy: Match QuintoAndar's tech so corretores have same/better tools while keeping full 6% commission.

11. AI Property Search via WhatsApp (NLP + Claude + iList/iConnect)

    • Natural language queries: "apt 2 quartos perto do metrô Vila Mariana até 600k"
    • Extends existing /ilist with semantic search layer
    • Effort: Medium | Impact: High (direct revenue)

12. Digital Proposal/Counter-Offer Flow

    • Structured WhatsApp messages: propose → counter → accept/reject
    • Buyer/seller see formatted proposal cards with buttons
    • Saves negotiation history in deal_events
    • Effort: Medium | Impact: High (competitive differentiator)

13. Visit Scheduling via Bot (/agendar)

    • Corretor sets availability windows → buyer picks slot → calendar notification
    • WhatsApp reminder 24h before + day-of
    • Effort: Low | Impact: High (lead conversion speed)

14. Financing Simulation (/financiamento [valor] [entrada] [prazo])

    • SAC + Price amortization tables, multiple bank rates
    • Instant output in WhatsApp — replaces manual bank calculator visits
    • Correspondente bancário revenue is royalty-free per RE/MAX clause 4.8!
    • Effort: Low | Impact: Medium (untapped revenue stream)

15. Automated CMA/Valuation (/avaliar [endereço]) ✅ iCONATUS INTEGRADO VIA PLAYWRIGHT

    • Comparative Market Analysis using iList + iConatus GeoAnálise + ITBI data
    • Claude-powered PDF report (baseado no template PPTX existente)
    • Plano detalhado: ACM/PLANO-AUTOMACAO-ACM.md (7 fases, ~60h, 5 semanas)
    • iConatus GeoAnálise — FUNCIONANDO:
    • ✅ ACM/src/geoanalise_client.py — cliente automatizado Playwright
    • ✅ URLs Shiny descobertas: apartamento, casa, conjunto
    • ✅ AiA (Beta) — avaliação automática por IA
    • ✅ Testado: Rua Augusta 85m² → R$574k | Alameda Lorena 120m² → R$916k
    • Não precisa de API oficial! Scraper funciona.
    • Alternativa iConatus: Seção 11 do plano — Engine interno usando:
    • iList (232 imóveis com preço/área/bairro) ✅ já temos
    • DataZAP/FipeZAP (índices públicos mensais)
    • Valor Venal Referência (Prefeitura SP via scraper)
    • Portal scraper (ZAP/VivaReal — infraestrutura Playwright existe)
    • Próximo passo: Integrar geoanalise_client.py no bot + gerar PDF
    • Effort: Medium | Impact: High (corretor productivity)
    • Dependencies: ~~iConatus API (blocker)~~ → ✅ RESOLVIDO VIA PLAYWRIGHT

16. Auto-Generate Listing Descriptions from Photos (Claude Vision)

    • Send property photos → Claude Vision identifies features → generates listing text
    • Saves to iList/portal-ready format
    • Effort: Low | Impact: Medium

17. Multi-Portal Listing Syndication (Canal Pro extraído → item #0 P1)

    • Chaves na Mão + Nonstop — remanescente após Canal Pro próprio
    • Depende de: Item #0 (Canal Pro API) concluído primeiro
    • Chaves na Mão — Progresso:
    • [x] CnM XML format reverse-engineered (docs: tecnologiacnm.github.io/cnm-xml-documentation/)
    • [x] cnm_generator.py — XML generator (221 imóveis, 2.044KB XML, 30 destaques)
    • [x] cnm_mappings.py — 20 property type maps, 70+ feature→area maps
    • [x] config.py — CNM_QUOTA_DESTAQUE=30, OUTPUT_CNM_XML_PATH
    • [x] server.py — /feed/chavesnamao.xml route + cache + status + regenerate
    • [x] Deploy no servidor + integrado no run-full-sync.sh (pipeline diário 6am)
    • [x] CnM consumindo nosso feed — Painel CnM: 232 Ativos, 30 Destaques (substituiu iConnect!)
    • [x] Tailscale Funnel público — feed acessível externamente
    • [ ] Resolver featureIds→nomes (enrichment gap: iList API retorna IDs numéricos sem nomes)
    • [ ] Habilitar AI descriptions para CnM (reusa ai_descriptions.py)
    • Feed URL: https://studio76-server.tail92b8aa.ts.net/feed/chavesnamao.xml
    • Effort: Medium | Impact: Medium (reach multiplier parcial)

18. Eliminar C2S (Contact2Sale) — Middleware CRM Interno 🔥

    • Motivo: C2S é intermediário desnecessário entre nossos portais e corretores. Paga-se por um CRM de leads que:
    • Apenas roteia leads de portais (Canal Pro, Chaves na Mão, ImovelWeb) para corretores via e-mail
    • Não tem integração com nosso bot/Pipeimob/StudioImob
    • Distribuição de leads manual e sem lógica inteligente
    • Zero analytics de conversão por corretor/portal/bairro
    • Dados ficam presos em plataforma terceira
    • Solução: Construir middleware interno que:
    • Receba leads diretamente dos portais (Canal Pro já tem lead_auditor.py, CnM tem API de leads, ImovelWeb via API)
    • Distribua automaticamente para corretores via WhatsApp bot (round-robin inteligente por especialidade/bairro/disponibilidade)
    • Registre lead no Pipeimob automaticamente (/novavenda wizard pré-preenchido)
    • Tracking completo: lead recebido → primeiro contato → visita → proposta → fechamento
    • Dashboard de conversão por corretor, portal, tipo de imóvel, bairro
    • Re-engagement automático (24h/48h/7d follow-up via bot SDR)
    • Já temos:
    • lead_auditor.py — scraper Canal Pro leads (114/121 correct routing, 94.2%)
    • c2s_scraper.py — scraper C2S (1.197 linhas, audit completo)
    • CnM leads API reverse-engineered (JWT auth, 19 leads/60 dias)
    • Bot WhatsApp com /novavenda wizard
    • Pipeimob MCP server (12 tools)
    • SDR lead follow-up scheduler (code exists)
    • Economia: ~R$ X/mês de licença C2S + controle total dos dados
    • Effort: High (2-3 sprints) | Impact: Very High (elimina dependência, dados unificados, automação completa)

P2 — AI Property Discovery (MCP Público)

31. AI Property Discovery — MCP Server Público de Imóveis 🚀 NOVO
    • Motivo: Assistentes de IA (Claude, ChatGPT, Gemini, Copilot) estão se tornando o portal central do usuário. Portais como ZAP/VivaReal usam SPAs com links instáveis e sem APIs públicas — AI agents não conseguem consumir dados de imóveis com precisão. Quem expõe dados estruturados para AI agents captura leads antes de todo mundo.
    • Tese: Studio 76 será a primeira imobiliária do Brasil (e possivelmente do mundo) a expor inventário via MCP — protocolo padrão com 83.4k stars no GitHub, suportado por Claude (350M+ usuários), ChatGPT (300M+ usuários), Copilot e Gemini.
    • Solução: MCP Server público + REST API + Schema.org — 3 canais de exposição:
    • Canal 1 (MCP): FastMCP com 4 tools: search_properties, get_property_details, list_neighborhoods, get_agency_info. Streamable HTTP via Tailscale Funnel HTTPS.
    • Canal 2 (REST API): JSON endpoints: /api/v1/properties, /api/v1/search?q=..., /api/v1/neighborhoods
    • Canal 3 (Schema.org): Páginas HTML com JSON-LD RealEstateListing + sitemap.xml
    • Já temos (80% da infra):
    • [x] 232 imóveis enriquecidos (ilist-enrichment.json)
    • [x] 232 descrições AI (ai-descriptions-cache.json)
    • [x] 8.367 fotos indexadas
    • [x] Flask server + HTTPS público (Tailscale Funnel)
    • [x] 5 MCP Servers internos em produção (FastMCP Python)
    • [x] Quality Score 93.8/100 (A+)
    • Fases:
    • [x] FASE 1 (concluída 2026-04-11): MCP Server público com 4 tools + rate limiting + PII filter — property_discovery_mcp.py (FastMCP, porta 5077, user systemd, 232 imóveis)
    • [x] FASE 2 (concluída 2026-04-11): REST API JSON (/api/v1/properties, /api/v1/search, /api/v1/neighborhoods) + proxy /mcp no Flask + /.well-known/mcp.json
    • [ ] FASE 3 (1 dia): Schema.org JSON-LD + sitemap.xml
    • [x] FASE 4 (concluída 2026-04-11): Publicado no Smithery (https://studio76--eliekfouri-g8h8.run.tools) + registro mcp.so em andamento
    • Implantado em 2026-04-11:
    • property_store.py — data layer (232 imóveis, 95 bairros, LGPD-safe)
    • property_discovery_mcp.py — FastMCP server porta 5077, systemd user service (property-discovery-mcp.service)
    • server.py atualizado — proxy /mcp → 5077, REST API /api/v1/*, /.well-known/mcp.json
    • MCP URL pública: https://studio76-server.tail92b8aa.ts.net/feed/mcp
    • Validado: initialize ✅ · list_neighborhoods (95 bairros) ✅ · search_properties ✅
    • Segurança:
    • iList READ-ONLY (regra de ouro mantida)
    • LGPD: expõe apenas dados públicos (preço, fotos, bairro, tipo). NUNCA expõe: nome/tel proprietário, CPF/CNPJ, comissões, nº exato, matrícula
    • Rate limiting: 100 req/min por IP
    • HTTPS obrigatório (Tailscale Funnel)
    • Custo infra adicional: ZERO (mesmo servidor do Canal Pro feed)
    • Ref: relatorio-ai-property-discovery-ceo.pdf, /memories/session/plan.md
    • Effort: Medium (4-6 dias total, 4 fases) | Impact: Very High (canal de leads inédito, first-mover advantage)

P2 — Captação Automatizada (/captar + Follow-Up Proativo)

30. Captação Automatizada — iList Rascunho + Follow-Up + Contrato + KPIs 🆕
    • Motivo: Corretores captam imóveis mas 60%+ das captações morrem por falta de follow-up. Não há gestão estruturada do pipeline de captação. Rascunhos ficam órfãos no iList. Sem métricas de desempenho individual.
    • Solução: Pipeline end-to-end: /captar → rascunho iList → follow-up proativo → contrato de representação auto-gerado → ClickSign → KPIs de desempenho por corretor.
    • Fases:
    • [ ] FASE 1: MVP — /captar cria rascunho iList com dados mínimos (corretor+tipo+transação), consulta GeoSampa, retorna ID + SQL + link. Tabelas captacoes + captacao_events no SQLite.
    • [ ] FASE 2: Follow-Up Proativo — CRON job cobra corretor (D+1, D+3, D+7, D+14), botões interativos, cancelamento automático D+30, escalação gestor. Comando /captacoes (painel).
    • [ ] FASE 3: Agendamento de Visitas 🔮 — Bot contata proprietário via WhatsApp, propõe horários (lê Google Calendar), confirma visita, cria evento, lembrete D-1, follow-up pós-visita.
    • [ ] FASE 4: Enriquecimento Pós-Visita 🔮 — Corretor envia fotos/dados pelo WhatsApp → bot atualiza rascunho iList, gera descrição AI, sugere ativação quando completo.
    • [ ] FASE 5: Contrato de Representação + ClickSign — Template LaTeX do contrato (reusa engine ccv-latex.service.ts), preenchimento automático, envio via ClickSign (clicksign.service.ts já em produção). Testemunhas: Wilton Lee + Elie (substitui Yara).
    • [ ] FASE 6: KPIs e Analytics — Event sourcing (captacao_events), /desempenho [corretor], /ranking, digest semanal gestor. Métricas: taxa conversão, tempo até visita, tempo até contrato, responsividade.
    • Infra existente que será reusada:
    • ccv-latex.service.ts — engine LaTeX→PDF (adaptar para Contrato de Representação)
    • clicksign.service.ts — pipeline completo de assinatura digital (produção)
    • contrato_representacao_parser.py — parser OCR de contratos existentes
    • ilist.service.ts — já tem createListing() + updateListingStatus() como base
    • Dependências: Exceção READ-ONLY para rascunhos iList (✅ aprovada 2026-04-17), GeoSampa anti-CAPTCHA
    • Ref: operations/PLANO-CONSULTA-IMOVEL-PRIMEIRO-CONTATO.md
    • Effort: High (6 fases) | Impact: Very High (pipeline captação end-to-end, KPIs de desempenho, reduz abandono 60%→10%)

P2 — Transição PipeImob → BD Próprio + Novos Módulos

32. Transição PipeImob → BD Próprio (Fonte Única de Verdade) 🔥 NOVO

    • Motivo: BUG-010 — 3 ilhas de dados desconectadas (Pipeimob, Bot SQLite, SmartyDeed MySQL). Comando /status mostra "documentos faltando" incorretamente porque cada sistema tem verdade parcial. Corretores reclamam frequentemente. À medida que corretores usam menos o Pipeimob, dados ficam cada vez mais desatualizados.
    • Solução: BD próprio (SmartyDeed MySQL) como fonte única de verdade. Pipeimob passa a ser alimentador (não mais fonte primária). Dados puxados principalmente de iList + BD próprio.
    • Componentes:
    • [ ] Sync Pipeimob → BD: Já existe cron systemd que parseia Pipeimob via API. Expandir para importar deals, documentos, status, parties → tabelas no MySQL do SmartyDeed.
    • [ ] Fallback headless browser: Quando API do Pipeimob não retorna dado, usar Playwright/Puppeteer para scraping (já temos pipeimob_statement.py como referência Bubble.io scraper).
    • [ ] Sync iList → BD: Importar dados de imóveis do iList para BD próprio (refresh_ilist_cache.py já existe como base).
    • [ ] Status unificado: Bot consulta BD próprio (não mais Pipeimob diretamente) para /status. Resolve falsos "documentos faltando".
    • [ ] Write-back opcional: Para dados que PRECISAM estar no Pipeimob (enquanto não for 100% abandonado), tentar push via API. Dificuldade conhecida com upload API — aceitar degradação graciosa.
    • [ ] Dashboard de integridade: Painel mostrando divergências entre BD próprio vs Pipeimob vs iList. Alerta quando dados desencontrados.
    • Já temos:
    • Cron systemd para parsing Pipeimob via API (externo ao repo SmartyDeed)
    • pipeimob_statement.py — Playwright scraper para Bubble.io/Pipeimob
    • Pipeimob MCP Server (12 tools) — leitura de dados CRM
    • refresh_ilist_cache.py — cache de dados iList via API
    • SmartyDeed MySQL com pipeline de import (scraped_listings → leads → studio_listings)
    • Problema conhecido: Upload para Pipeimob via API é difícil/instável — priorizar leitura e aceitar que Pipeimob fica gradualmente read-only.
    • Meta final: Corretores param de abrir Pipeimob. Bot + SmartyDeed Filament suprem 100% das necessidades.
    • Ref: BUG-010, BUG-011
    • Effort: High (3-4 sprints) | Impact: Very High (resolve problema #1 dos corretores, elimina dados fantasma)

33. Relatório de Gestão 🆕

    • Motivo: Não existe relatório consolidado de gestão da operação para o CEO/gerentes. Dados dispersos entre planilhas, bot e Pipeimob.
    • Solução: Relatório periódico (semanal/mensal) automatizado com KPIs de gestão:
    • Pipeline: deals por fase, tempo médio por fase, conversão funil
    • Corretores: produtividade individual, captações, fechamentos, tempo de resposta
    • Financeiro: comissões, inadimplência, previsão de recebimento
    • Estoque: imóveis ativos vs expirados, tempo médio no mercado
    • Delivery: PDF via WhatsApp (reusa engine LaTeX) + dashboard Filament no SmartyDeed
    • Depende de: #32 (BD Próprio) para dados unificados
    • Effort: Medium | Impact: High (visibilidade gerencial)

34. Análise de Últimos Vendidos — Planilhas ITBI da Prefeitura 🆕

    • Motivo: Dados de ITBI (Imposto de Transmissão de Bens Imóveis) da prefeitura são fonte pública de preços reais de transações, essenciais para ACM/avaliação precisa.
    • Solução:
    • [ ] Scraper de planilhas ITBI da Prefeitura de SP (dados públicos via Portal da Transparência)
    • [ ] Parser e normalização: endereço, valor transação, data, tipo imóvel, área
    • [ ] Import para BD SmartyDeed (tabela itbi_transactions ou similar)
    • [ ] Integração com ACM (#15): usar dados ITBI como comparáveis reais (vendas efetivas, não preços pedidos)
    • [ ] Comando bot: /ultimos-vendidos [bairro] ou /itbi [endereço]
    • Sinergia: Alimenta #15 (ACM) com dados de mercado real. Diferencial competitivo — poucos têm acesso estruturado a esses dados.
    • Effort: Medium | Impact: High (avaliações mais precisas, dados de mercado real)

35. Jurídico — Automação Consolidada 🆕

    • Motivo: Vários módulos jurídicos existem isolados (DD, CCV, contratos). Falta visão unificada do fluxo jurídico de um deal.
    • Componentes existentes:
    • [x] DD automática (/dd) — funcionando em produção
    • [x] CCV auto-geração (/gerarccv) — 6 templates, funcionando
    • [ ] CCV revisão automática com Dr. Wilton — BLOQUEADO (agenda Dr. Wilton)
    • [ ] Diligência prévia gestões novas (#10) — com Dr. Wilton
    • [ ] Contrato de Representação auto-gerado (#30 Fase 5) — ClickSign
    • [ ] Assertiva Integration (#20) — dados CPF/CNPJ/nascimento
    • Objetivo: Pipeline jurídico end-to-end: DD → contrato gestão → CCV → registro → escritura. Status unificado no bot e no Filament.
    • Parceiro: Dr. Wilton (validação jurídica de cada etapa)
    • Effort: High (consolidação) | Impact: High (fluxo jurídico sem gaps)

36. Jornada Diária do Corretor — Tracking de Atividades automático 🆕 P2 (28/04)

    • Motivo: RE/MAX Studio 76 distribui hoje um PDF em papel ("Tracking de Atividades — Jornada Diária") para o corretor preencher manualmente 10 métricas ao longo de 60 dias (8 semanas). Adoção é baixa, dado é perdido, e não há agregação para gestão (Roberto/Carine/Samuel). A maior parte dessas 10 métricas pode ser capturada automaticamente se o corretor usar o bot — eliminando preenchimento manual e dando visibilidade gerencial em tempo real.
    • Tese estratégica: O Tracking de Atividades vira o principal vetor de adoção do bot entre os 57 corretores. "Use o bot e seu Tracking se preenche sozinho" é mensagem direta que conecta uma prática que o corretor já conhece (a planilha do RE/MAX) ao stack interno (bot Studio76). Ao mesmo tempo coleta feedback real de uso para evoluir as funções que ainda não estão 100%.
    • As 10 métricas mapeadas para comandos do bot:
      | # | Métrica | Captura | Status do comando |
      |---|---------|---------|-------------------|
      | 1 | Prospecção | /prospectar [contato] | A criar (FASE 2) |
      | 2 | 1º Contato | bot detecta primeira mensagem trocada com lead via SDR | Parcial — depende de #8 v2 |
      | 3 | Agendamento da 1ª Visita | /agendar [imovel] | A criar (FASE 2) — reusa wizard /agendar-fotos |
      | 4 | 1ª Visita (conhecer imóvel novo) | /captar cria rascunho iList | ✅ Existe (#30 FASE 1) |
      | 5 | ACM apresentados | /avaliar [endereço] | ✅ Existe |
      | 6 | Assinatura de CR (Contrato de Representação) | ClickSign envia evento ao bot | ⏳ Depende #30 FASE 5 |
      | 7 | Visitas com clientes/parceiros | /visita [imovel] [cliente] | A criar (FASE 2) |
      | 8 | Propostas | /proposta [imovel] [valor] | A criar (FASE 1, ref. QuintoAndar Tech-Match) |
      | 9 | Assinatura do CCV | /gerarccv + ClickSign + bot detecta status SIGNED | ✅ Existe |
      | 10 | Presença Studio76 / Reuniões | check-in via WhatsApp na chegada (/cheguei) ou geofence | A criar (FASE 3) |
    • Fases:
    • [ ] FASE 1 (3-4 dias) — MVP captura passiva: schema corretor_atividades (event sourcing por corretor_id, atividade_tipo, deal_id?, occurred_at); cron noturno consolida por semana ISO; comando /jornada retorna PDF idêntico ao do RE/MAX preenchido com o que o bot já sabe (métricas 4, 5, 9 funcionam dia 1).
    • [ ] FASE 2 (3-4 dias) — Comandos novos: /prospectar, /agendar, /visita, /proposta (todos thin wrappers que só registram evento + retornam confirmação curta). UX de 1 linha: corretor manda /visita 601301080-21 João Silva e pronto.
    • [ ] FASE 3 (2 dias) — Check-in presença: botão diário 8h "Cheguei na Studio?" + /cheguei para reuniões. Roberto/Carine ganham relatório semanal de presença.
    • [ ] FASE 4 (2 dias) — Dashboard coordenação: painel /jornada-equipe para Roberto/Carine/Samuel com ranking, evolução semanal, gargalos identificados (ex: corretor X tem 50 prospecções mas 0 propostas → problema de qualificação).
    • [ ] FASE 5 (2 dias) — Loop de feedback semanal: sexta 17h o bot manda pra cada corretor um resumo da sua jornada da semana + pergunta "o que faltou capturar?" — feedback alimenta backlog de comandos novos.
    • Vetor de adoção (KEY): Esse projeto resolve BUG-006 (90% dos corretores nunca usaram o bot). Quem captar com /captar, fizer ACM com /avaliar, gerar CCV com /gerarccv etc. recebe seu Tracking preenchido. Quem não usa o bot recebe Tracking vazio — incentivo natural à adoção sem cobrança.
    • Mensagem-chave para corretores (estilo Estoque Vivo): "Você não precisa preencher PDF nenhum. Use o bot — eu preencho seu Tracking pra você. E me manda no WhatsApp o que faltou que eu aprendo."
    • Material institucional: PDF Studio76 endereçado a Roberto/Carine/Samuel + mensagem WhatsApp para o CEO divulgar (em produção).
    • Dependências: #8 (Lead Bot v2 — captura métrica 2), #30 FASE 5 (CR via ClickSign — métrica 6), #33 (Relatório de Gestão — usa mesmo schema de eventos).
    • Sinergia: alimenta #19 (Sales KPI Dashboard /funil), #30 FASE 6 (KPIs de captação), #33 (Relatório de Gestão). Todos os três consomem corretor_atividades.
    • Effort: Medium (~12-14 dias 5 fases) | Impact: Very High (vetor de adoção + dado de gestão + substitui PDF papel + feedback estruturado de uso)

37. Automação das atividades da Yara e da Nicolly — mapa para eliminar trabalho manual 🆕 P2 (28/04)

    • Motivo: Yara e Nicolly são as duas pessoas do staff fixo do escritório que mais executam tarefas repetitivas/operacionais hoje. Documento oficial das atividades da Yara (Atividades - Yara 12.2025.docx, atualizado 12/12/2025) lista 7 categorias com ~40 sub-atividades. Nicolly responde por triagem + entrevista de candidatos a corretor. A maioria dessas tarefas é candidata direta a automação via bot WhatsApp + integrações já existentes (Stark Bank, Granatum, ClickSign, Drive, iList, Pipeimob).
    • Tese: mapear cada atividade explicitamente, marcar status (já automatizada / em projeto / a planejar / não automatizável), e usar este item como índice mestre de onde cada peça do dia-a-dia delas é endereçada no resto do board. Yara fica livre para captação e atendimento qualificado; Nicolly fica focada na entrevista humana (a parte que NÃO se automatiza).

    YARA — atividades atuais e plano de automação

    Quick map atividade ↔ automação existente/em desenvolvimento:

    Atividade Yara	Automação que cobre	Status
    Calcular reembolso de fotos + repasse David	#29 /agendar-fotos Fase 5 (Invoice PIX corretor D+30) + Fase 6 (PaymentRequest fotógrafo D+7)	⏳ Em desenvolvimento (plano aprovado 18/04)
    Subir fotos/vídeos ao YouTube + compartilhar com corretores	botjuridico whatsappbot/docs/planning/captacao-midia-workflow-kickoff.md	⏳ Em desenvolvimento
    Atendimento WhatsApp/telefone + rodízio de leads + planilha de leads	#8 Studio Lead Bot v2 (WhatsApp +55 11 97345-7166, intent classifier 9 buckets)	⏳ Em codificação (shadow mode em prod, Sprint A iminente)
    Ficha de candidatos (Assertiva → planilha + agenda)	#8 bucket 5 + #20 Assertiva integration (já em produção)	✅ Em produção (#20) + ⏳ #8
    Arquivar Contrato de Representação	#30 FASE 5 (CR auto-gerado + ClickSign + Drive)	⏳ Em fila
    Confirmar Representações/Vendas/Locações com corretores	#36 Tracking de Atividades (event sourcing corretor_atividades) + #19 Sales KPI Dashboard	⏳ Em fila
    Ranking + perfil de Representações	#19 (/funil, /desempenho, /ranking) + #33 Relatório de Gestão	⏳ Em fila
    Digitalização/OCR de documentos	data-capture.service.ts (auto-OCR de fotos via WhatsApp)	✅ Em produção
    Solicitar portador (Samuel/Suzana)	/portador — a criar, item planejado dentro de #37	🆕 A criar
    Chaves de imóveis	/chave [imóvel] — a criar, item planejado dentro de #37	🆕 A criar (Low)
    Reposição suprimentos + lembretes Samuel	/suprimentos — a criar, item planejado dentro de #37	🆕 A criar (Low)
    Lembrete lixo terça/sexta	Cron WhatsApp simples — item planejado dentro de #37	🆕 A criar (Trivial)
    Placas, crachás, uniformes (confecção + cobrança)	Padrão /agendar-fotos aplicado a fornecedores externos	🆕 A planejar
    Artes de vendidos + ranking + painel (balão/termômetro/foto) + certificados	Generator Claude+Imagen+LaTeX (cluster único)	🆕 A planejar
    Café, recepção, abrir portas, cópias físicas, orçamentos diversos, cartão de visita, pastas/envelopes	—	❌ Não automatizar (físico/julgamento humano)

    Detalhe completo abaixo, por bloco do documento original (Yara 12.2025):

    1) Organização do escritório (porta/luzes/café/lixo/reposição)
    | Atividade | Plano | Status |
    |---|---|---|
    | Abrir/fechar janelas, persianas, ar condicionado, luzes | Domótica simples (smart plugs + cron + presence) — fora do bot, projeto à parte | Não planejado (P3) |
    | Fazer/organizar café (dia-a-dia + mentorias + reuniões) | Manual — não automatizável (parte do "host" do escritório) | Não automatizar |
    | Retirar lixo terças (Nilda não vem) + lembrar Samuel sexta | Cron + lembrete WhatsApp pra Samuel terça 17h e sexta 16h | A criar (Trivial, ~1h) |
    | Reposição papel higiênico/toalha/detergente/sabonete/açúcar/mexedores | /suprimentos no bot — Yara declara estoque baixo, bot abre pedido recorrente + alerta Roberto | A criar (Low, ~3h) |
    | Avisar Samuel quando acabar café/manteiga/leite | Mesma lógica acima — botão "acabou" → notifica Samuel | A criar (Trivial, ~1h, junto com /suprimentos) |

    2) Atendimento — recepção, telefone, WhatsApp, rodízio de leads
    | Atividade | Plano | Status |
    |---|---|---|
    | Recepção / abrir portas | Manual (host físico) | Não automatizar |
    | Telefone + WhatsApp + rodízio de leads (Telefone/WhatsApp/Nonstop/C2S) preencher planilha | Item #8 — Studio Lead Bot v2 cobre TODO esse bloco: classifier de intenção, rodízio de captação 38 corretores, escalação humana só onde precisa | ✅ Em produção (shadow mode), full v2 em codificação |
    | Preencher planilha de leads | Bot escreve direto em intent_classifications + captacao_offers (item #8) — planilha vira read-only espelho | ✅ Coberto por #8 |

    3) Compras (material, placas, crachás, cartão, pastas, uniformes, orçamentos)
    | Atividade | Plano | Status |
    |---|---|---|
    | Material de limpeza / higiene / descartáveis | /suprimentos (mesmo do bloco 1) | A criar |
    | Material de escritório | Idem | A criar |
    | Placas (confecção + conferência + cobrança) | Bot integra com fornecedor de placas: /placa [imóvel] cria pedido, monitora status, gera Invoice PIX cobrança ao corretor (igual ao item #29 de fotografia) | A planejar |
    | Crachás (confecção + conferência + confirmação) | Sub-fluxo do /onboarding (item #7) — bot pede foto + dados, dispara confecção, rastreia entrega | A planejar |
    | Cartão de visita do escritório | Yara concentra pedido manual — baixa frequência, manter manual | Não automatizar |
    | Pastas / envelopes | Manual (consumível baixo volume) | Não automatizar |
    | Camisetas uniforme (conferência + confirmação + cobrança) | /uniforme no bot — corretor escolhe tamanho, bot dispara pedido + Invoice PIX | A planejar |
    | Orçamentos diversos | Manual — exige julgamento humano | Não automatizar |

    4) Arquivo (Contratos, fotos, documentos cartório, chaves, ficha de candidatos)
    | Atividade | Plano | Status |
    |---|---|---|
    | Arquivar Contrato de Representação | Item #30 FASE 5 — CR auto-gerado + ClickSign + Drive | ⏳ Em fila |
    | Subir fotos/vídeos ao YouTube + compartilhar com corretores | Workflow delegado pro botjuridico (whatsappbot/docs/planning/captacao-midia-workflow-kickoff.md) — bot recebe Drive, sobe YouTube, posta link | A criar (4-6h) |
    | Documentos de cartório (organizar + pedir portador retirar/entregar) | Bot integra com Leandro (portador atual) via /portador — Yara/Samuel/Suzana abrem solicitação, bot rastreia + lembra entrega | A planejar |
    | Chaves de imóveis à venda | Tabela chaves_imoveis — quem está com a chave de qual imóvel; bot consulta /chave [imóvel] retorna paradeiro | A criar (Low, ~4h) |
    | Ficha de candidatos (após Assertiva → Planilha Geral + aniversário na agenda) | Item #8 bucket 5 (recrutamento) + Assertiva integration (#20 já em produção) — bot grava ficha em recruitment_pipeline, agenda aniversário no Google Calendar | ✅ Coberto por #8 + #20 |

    5) Apresentação de resultados (Representações, Vendas, Locações, Ranking, artes, certificados)
    | Atividade | Plano | Status |
    |---|---|---|
    | Organizar Representações do mês (criar pasta, arquivar contrato, verificar data assinatura) | #30 FASE 5 automatiza criação de pasta + ClickSign + arquivamento | ⏳ Em fila |
    | Confirmar Representações/Vendas/Locações com corretores | Bot puxa direto do corretor_atividades (item #36) + Pipeimob/SmartyDeed — Yara para de ligar pra cada corretor | ⏳ Depende de #36 |
    | Ranking Representações e Vendas | #19 Sales KPI Dashboard + #36 jornada-equipe | ⏳ Em fila |
    | Perfil das Representações (gráficos, tipo de imóvel, bairro) | Mesmo dashboard do #19 + filtros | ⏳ Em fila |
    | Artes de vendidos + ranking (post WhatsApp/Instagram) | Generator template Claude + Sora/Imagen — bot gera arte ao detectar venda fechada | A planejar (Medium) |
    | Certificados | Template LaTeX (reusa engine ccv-latex.service.ts) auto-preenchido por evento | A criar (Low, ~3h) |

    6) Fotos (cálculo de reembolso, repasse para David)
    | Atividade | Plano | Status |
    |---|---|---|
    | Calcular reembolso por imóvel + enviar David (cobrança) | Item #29 — /agendar-fotos (Fase 5) cobre 100% — Invoice PIX D+30 corretor | ⏳ Em fila (Fase 5) |
    | Passar valor total mensal para David (pagamento fotógrafo) | Item #29 Fase 6 — PaymentRequest D+7, Granatum sync automático | ⏳ Em fila (Fase 6) |

    7) Solicitação de portador + cópias + digitalização + artes painel
    | Atividade | Plano | Status |
    |---|---|---|
    | Solicitar/acompanhar portador (apenas Samuel/Suzana — outros pedem direto Leandro) | /portador (mesmo do bloco 4) com ACL Samuel/Suzana | A planejar |
    | Tirar cópias de documentos quando tem escritura | Manual (operação física) — não automatizável sem hardware | Não automatizar |
    | Digitalizar documentos | Manual (scanner físico) — bot pode receber foto via WhatsApp e fazer OCR (já existe data-capture.service.ts) | ✅ Parcialmente automatizado |
    | Artes do painel (Representações + Transações: balão, termômetro, foto) | Generator template (mesmo do bloco 5 — "artes de vendidos") | A planejar |

    NICOLLY — atividades atuais e plano de automação

    Fonte oficial (Samuel Chen, WhatsApp 28/04/2026 11:06 + 11:14) — escopo confirmado pelo CEO em duas mensagens.

    Quick map atividade ↔ automação existente/em desenvolvimento:

    Atividade Nicolly	Automação que cobre	Status
    Impulsionamento Google Ads + Meta (gestão + recrutamento)	#5 Impulsionamento Digital P1 + #6 Marketing P1	⏳ Em fila P1
    Monitoramento de campanhas + direcionamento de leads (Samuel marcou: AUTOMATIZÁVEL)	Conector Meta Ads/Google Ads API → relatório bot + leads viam #8 Lead Bot v2	🆕 A criar (depende de #5 + #8)
    Agendamento inicial com candidatos	#8 bucket 5 (Calendar Nicolly via bot)	⏳ Em fila (#8 Sprint A)
    1ª entrevista com candidato (humana)	—	❌ Não automatizar (intencional)
    Confirmar comparecimento / no-show	#8 template nicolly_confirmar_entrevista (botões 1-clique)	⏳ Em fila (#8 Sprint A)
    Solicitar documentos + checagem + contrato de novo associado	/onboarding-corretor — a criar, reusa #20 Assertiva + #30 FASE 5 ClickSign	🆕 A criar (Medium)
    Agenda de treinamento	/agendar-treinamento — a criar (Calendar coletivo + lembretes)	🆕 A criar (Low)
    Preparar material de integração (kit dia 1)	Cluster com bloco 3 da Yara (crachás+cartão+uniforme) + #7 Recrutamento P1	🆕 A planejar
    Reportar status de recrutamento pra Suzana	#8 template suzana_relatorio_recrutamento_diario (DIÁRIO 18h)	⏳ Em fila (#8 Sprint B)
    Detectar saída de corretor	#8 sync diário corretores bot.db	⏳ Em fila

    Detalhe completo abaixo, por categoria:

    A) Marketing / Mídia paga / Lead ops
    | Atividade | Plano | Status |
    |---|---|---|
    | Impulsionamento de campanhas Google Ads + Instagram (Meta) — focos: (a) imóveis de gestão (vender estoque) e (b) recrutamento de corretores | Conecta diretamente ao item #5 (Impulsionamento Digital P1) + item #6 (Marketing P1): Studio paga, Nicolly opera. Bot pode automatizar criação de criativos (Claude + Imagen), bidding sugestões, recorte de público — execução continua humana enquanto a estratégia amadurece | Em fila P1 (#5, #6) |
    | Monitoramento de campanhas + direcionamento de leads (Samuel marcou como AUTOMATIZÁVEL) | Bot agrega métricas de Meta Ads + Google Ads via API (CTR, CPL, CPC, conversões), gera relatório diário Nicolly+Samuel; leads recebidos via webhook entram no #8 Lead Bot v2 e seguem rodízio/intent classifier sem fricção humana | A criar (Medium, ~3 dias) — depende de #5 + #8 |

    B) Recrutamento de corretores
    | Atividade | Plano | Status |
    |---|---|---|
    | Agendamento inicial com candidatos | Item #8 bucket 5 — bot agenda no Google Calendar da Nicolly direto, sem Nicolly digitar | ⏳ Em fila (#8 Sprint A) |
    | Primeira entrevista inicial com candidato (humano) | Mantém — é o ponto de avaliação humana que NÃO se automatiza (decisão consciente: pessoas avaliando pessoas) | Não automatizar (intencional) |
    | Confirmar comparecimento / no-show pós-entrevista | Bot pinga template nicolly_confirmar_entrevista 1h após horário com botões Compareceu/Não compareceu | ⏳ Em fila (#8 Sprint A) |
    | Solicitar documentos do candidato + checagem + inserir no sistema (contrato de novo associado) | Sub-fluxo /onboarding-corretor: bot pede docs (RG/CPF/CRECI/comprovante endereço), valida via Assertiva (#20 já em produção), monta contrato de associação, envia ClickSign, registra no Pipeimob/SmartyDeed/corretores bot.db | A criar (Medium, ~5 dias) — reusa #20, #30 FASE 5, ClickSign service |
    | Agenda de treinamento do novo corretor | Bot orquestra: ao detectar contrato assinado → cria evento de treinamento no Calendar coletivo, convida corretor + treinadores, manda lembrete D-1, pede confirmação D-0 | A criar (Low, ~2 dias) |
    | Preparar material de integração (entrega no dia da integração) | Checklist + template no Drive: bot gera kit personalizado (crachá, cartão visita, manual onboarding, acessos a sistemas, foto de perfil pra iList) e dispara responsáveis (Yara/Roberto/Carine) automaticamente. Cobre também crachás + cartão visita do bloco 3 da Yara | A planejar (Medium) — agrupa com #7 (Recrutamento P1) + bloco 3 Yara |
    | Reportar status de recrutamento pra Suzana | Bot manda relatório DIÁRIO ~18h via template suzana_relatorio_recrutamento_diario | ⏳ Em fila (#8 Sprint B) |
    | Detectar saída de corretor da empresa | Bot detecta inativação no corretores (sync diário bot.db) | ⏳ Em fila (#8) |

    Quadro consolidado

    Status	Yara	Nicolly
    ✅ Em produção / coberto	3 (atendimento+rodízio leads, ficha candidatos, OCR documentos)	0
    ⏳ Em fila (item já no board)	7 (CR, fotos×2, ranking, perfil, fotografia ×2)	5 (impulsionamento #5/#6, agendamento candidato, confirmação, relatório Suzana, detecção saída)
    A criar (Low/Trivial/Medium)	6 (lixo lembrete, suprimentos×2, YouTube uploader, chaves, certificados)	3 (monitoramento campanhas+leads, /onboarding-corretor, agenda treinamento)
    A planejar (Medium+)	6 (placas, crachás, uniformes, portador, artes vendidos, artes painel)	1 (kit material integração — cluster com bloco 3 Yara)
    Não automatizar (físico/julgamento)	8 (porta/luz, café, recepção, cartão visita, pastas/envelopes, orçamentos, cópias físicas, entrevista N/A)	1 (entrevista humana)
    Total mapeado	30	10

    Próximos passos

    1. Confirmar mapa com a Yara e a Nicolly — validar se algum item foi mal classificado ou se faltou algo do dia-a-dia delas
    2. Promover quick-wins ao topo da fila P2: /suprimentos + /chave [imóvel] + lembrete lixo (somam ~10h, eliminam 5 atividades manuais)
    3. Acelerar #8 Sprint A (já em codificação) — destrava 100% das atividades da Nicolly
    4. Acelerar #29 Fase 5+6 (/agendar-fotos) — destrava bloco 6 da Yara (cálculo reembolso + repasse David)
    5. Cluster "artes/certificados/painel" — agrupar num único item de generator (Claude + template LaTeX/Imagen) — abre eficiência cruzada com #19 + #33 (relatório de gestão)
    • Ref: /home/egk/Downloads/WhatSie/Atividades - Yara 12.2025.docx (fonte original RH/Operações), leadbot/docs/studio-lead-bot-plano-ceo.md (Nicolly)
    • Sinergia direta: #8 (Lead Bot v2), #29 (/agendar-fotos), #30 FASE 5 (CR ClickSign), #36 (Tracking de Atividades), #19 (KPI dashboard), #33 (Relatório de Gestão)
    • Effort: Index/triagem (este item é mapa, não código) | Impact: High (visão consolidada de quanto da rotina staff cabe no bot, prioriza sprints futuros)

38. Plano 360° do Corretor — briefing matinal + saneamento + onboarding contextual 🆕 P2 (29/04)

    • Plano: operations/PLANO-360-DO-CORRETOR.md (335 linhas, draft aguardando aprovação CEO)
    • 5 fases:
    • FASE A — Saneamento: fix-corretor-phone-orphans (37 deals com corretor_phone='sync-script'). Blocker compartilhado com #36 Tracking — sem isto, nem #36 nem #38 funcionam direito.
    • FASE B — Briefing 360° matinal: mensagem diária (manhã) consolidando deals em andamento, próximas ações, leads novos, métricas pessoais
    • FASE C — Captação inline: wizard captação direto no chat sem trocar de contexto
    • FASE D — Onboarding contextual: novos corretores recebem briefing customizado por experiência/CRECI
    • FASE E — Sinergia com #36: consome eventos de corretor_atividades pra montar o briefing
    • Pré-requisito comum com #36: FASE A é blocker dos dois — fazer primeiro destrava ambos.
    • Por que P2 e não P1: depende de aprovação CEO + de #36 estar minimamente em pé pra alimentar dados.
    • Effort: Medium-High (5 fases, ~3-4 sprints) | Impact: Very High (corretor para de "esquecer" deals, visibilidade matinal)

P3 — Strategic / Future

18. ~~NFS-e Full Automation~~ → DONE 2026-04-09 — Moved to Done table
19. Sales KPI Dashboard (/funil command with pipeline visualization)
    • Ref: implementation-plan-2026.md item 1.3.4
20. Assertiva Integration — DD + Dr. Wilton (data de nascimento, CNPJ) ✅ COMPLETO 2026-04-18
    • /captar: Assertiva lookup CPF→nome do proprietário (já em produção há semanas)
    • /dd A) Enriquecimento automático ✅: due-diligence.service.ts agora chama lookupPessoaByCpf SEMPRE que CPF resolvido, grava date_of_birth, nome_mae, situacao_cpf, address, phone, email em deal_parties via COALESCE (não sobrescreve docs). Migration v29 aplicou colunas novas em produção.
    • /dd B) CPF → CNPJs vinculados ✅: novo lookupEmpresasVinculadasByCpf (tenta endpoint dedicado /localize/v3/empresas-vinculadas, fallback para campo participacoes no payload Localize padrão). CNPJs vinculados são anexados ao parties[] mid-loop e o pipeline de certidões PJ (Receita/JUCESP/protestos/processos via Plexi) roda automaticamente. Corretor recebe notificação "🏢 X aparece como sócio de N empresa(s)".
    • Integração com iConatus: vincular dados Assertiva ao fluxo de avaliação/ACM (#15) — ainda pendente
    • Ref: whatsappbot/src/services/due-diligence.service.ts:370-430 · whatsappbot/src/services/assertiva.service.ts:395-455 · Migration v29 em whatsappbot/src/db/database.ts
21. ~~iConatus API~~ → RESOLVIDO VIA PLAYWRIGHT ✅
    • API não é mais necessária — ACM/src/geoanalise_client.py funciona diretamente nos apps Shiny
    • URLs descobertas via /auth/application-preferences:
    • Apartamento: iconatus.shinyapps.io/geoanaliseStudio76_105/
    • Casa, Conjunto também funcionais
    • Item #15 desbloqueado
22. SDR Virtual (AI lead qualification + follow-up)
    • SDR code exists but needs WhatsApp template messages for 24h+ re-engagement
23. Ad Package ROI Audit (CEO requested, zero progress)
    • Ref: implementation-plan-2026.md item 1.5.x
24. SmartyDeed-Alpha → Bot Bridge + Fisgar + Checkonn 🔄 EXPANDIDO
    • Connect scraped leads from SmartyDeed MySQL to bot's SDR mode
    • Currently: SmartyDeed is isolated lead-scraping tool with zero integration
    • Fisgar: Imputar plataforma Fisgar como fonte de dados de anúncios no SmartyDeed — scraper + import pipeline (fisgar_anuncios.json já existe como formato)
    • Checkonn: Integrar Checkonn como plataforma de verificação documental — alimentar status de documentos no BD próprio, resolver "documentos faltando" falsos (BUG-010)
    • Meta: SmartyDeed se torna hub central de dados imobiliários, recebendo de Fisgar, Checkonn, portais e Pipeimob
    • Effort: High | Impact: High (elimina dados isolados, alimenta bot + admin panel)
25. Owner WhatsApp Updates — automated visit reports, interest metrics, price suggestions
26. Consórcio / Correspondente Bancário Partnerships — royalty-free revenue (clause 4.8)

27. Virtual Tours (Matterport integration) — 3D tour links in listings

28. Photo Rendering & AI Virtual Staging Evolution (/staging → /render)

    • /staging already works (Gemini 2.5 Flash) for empty room → furnished staging
    • Evolve to: exterior renders from street photos, floor plan → 3D visualization, before/after renovation concept
    • Explore Google Imagen 3 / Nano Banana API when available for higher-quality output
    • Add render gallery per deal (save generated images to Drive)
    • Effort: Low (base exists) | Impact: High (listing attractiveness, QuintoAndar differentiator)
    • Code: whatsappbot/src/services/staging.service.ts (180 lines, fully functional)

29. Sistema de Agendamento de Fotografia End-to-End — /agendar-fotos 🆕 PLANO APROVADO 18/04 (escopo completo)

    • Plano completo: /home/egk/.claude/plans/shimmying-wiggling-engelbart.md
    • Escopo: ciclo completo bot WhatsApp orquestra corretor↔fotógrafo↔Drive↔iList↔StarkBank↔Granatum. Estende escopo original (/solicitar-pagamento-fotografo) para incluir agendamento proativo, monitor de Drive, publicação automática no iList após aprovação e motor de lembretes escalonados — princípio fix-in-chat.
    • Motivo (CEO): (1) aliviar Yara, (2) forçar engajamento corretor↔bot, (3) automatizar agendamento + entrega + aprovação + pagamento em uma só conversa.
    • Fluxo (10 etapas): /agendar-fotos → wizard (fotógrafo preferido + datas) → confirmação bilateral → lembrete pré-shoot → fotógrafo informa valor + sobe Drive → monitor detecta upload → corretor aprova/rejeita → publica no iList + cria Invoice PIX corretor (D+30) para diferença → D+7 cria PaymentRequest fotógrafo (aguarda aprovação Elie web UI) → DONE. Nag automático em cada atraso.
    • Tabela de subsídio (Elie, 18/04): ≤R$600K→R$200 | R$600-800K→R$250 | R$800K-1M→R$300 | >R$1M→R$350. Seed direto.
    • Pacote é informativo (Fotos/Foto+Video/Reels+Shorts/Drone/360/Planta); valor final vem do fotógrafo pós-serviço.
    • Seed inicial: 3 fotógrafos (Leo Muniz, PhotoMasterLab, Daniel Foggiato). Corretor define preferência no primeiro uso.
    • Aprovação do corretor = gate duplo: libera pagamento E publica no iList (respeita whitelist de mídia aprovada 17/04).
    • Pagamentos: Studio paga fotógrafo D+7 via PaymentRequest (Elie aprova web UI). Corretor paga diferença via Invoice PIX D+30.
    • Novas tabelas: fotografos, corretor_fotografo_preferencia, photo_subsidy_table, photo_sessions, photo_session_events, photo_session_reminders.
    • Novos serviços: photo-session, photo-scheduling, photo-subsidy, photo-delivery-monitor, photo-payment, photo-ilist-publisher, photo-nag.
    • Novos crons: scheduling followups (30min), delivery monitor (1h), upload reminders (1h), approval nag (6h), payment scheduler (daily 8h), broker overdue (daily 9h).
    • Novas skills: /agendar-fotos, /setup-fotografos, /relatorio-fotografia [mes] (replica formato Excel atual: COD | ENDEREÇO | PACOTE | VALOR | DATA | CORRETOR | VALOR IMÓVEL | SUBSÍDIO | REEMBOLSO).
    • Reuso: WizardManager, WhatsappService.sendButtonMessage, DriveService, StarkBankService.createInvoice, starkbank-mcp create_payment_request, upsert_verified_supplier, Granatum create_transaction, iList write-path existente.
    • Fases (7, ~8 dias): (1) schema+seed (2) wizard agendamento (3) Drive monitor (4) aprovação+publicação iList (5) cobrança corretor+Granatum (6) PaymentRequest D+7 (7) nag engine + detecção automática de captação.
    • Mínimo viável após Fase 5 (pagamento fotógrafo pode ficar manual temporariamente).
    • Effort: Medium-High (~8 dias) | Impact: Very High (alivia Yara + engajamento corretor + cost control + zero retrabalho manual)

30. Rename botjuridico → studio76bot 🆕 P3 (29/04)

    • Motivo: o nome legado "botjuridico" reflete só 1 dos ~10 domínios que o bot cobre hoje (/cobrar, /captar, /dd, /avaliar, Estoque Vivo, agendamento de fotos, NFS-e, contas a pagar, CCV/Clicksign, sentinela, jurídico). Nome novo descreve o escopo real e segue padrão studio76-* já em uso (studio76-server, StudioImob, smartydeed-alpha).
    • Escopo do rename:
    • systemd: botjuridico.service → studio76bot.service no studio76-server
    • Logs: alias journalctl -u studio76bot -f
    • Meta Developers app name: "BotJuridico" → "Studio76 Bot" (UI only — Phone Number ID 1050941431433587 e WABA 1249172496869831 NÃO mudam, número +55 11 94728-9029 permanece)
    • Código: whatsappbot/src/index.ts:1254 (header X-Forwarded-By) + :11674 (mensagem de erro com instrução journalctl)
    • Memórias: reference_hsm_templates.md (título), MEMORY.md referências, reference_arquitetura_maquinas.md, reference_server_jobs.md
    • Docs: KANBAN.md, juridico/planning/*, whatsappbot/docs/
    • Diretório /home/egk/whatsappbot/ permanece (já é genérico)
    • Tailscale studio76-server.tail92b8aa.ts.net permanece
    • Verificado 29/04: nenhum template HSM tem "juridico" no nome → NÃO precisa re-submeter à Meta.
    • Janela: ~30min — fazer junto com próxima janela de manutenção. Se urgência baixa, pode aguardar.
    • Sequência segura:
      1. sudo systemctl stop botjuridico
      2. sudo systemctl disable botjuridico
      3. sudo mv /etc/systemd/system/botjuridico.service /etc/systemd/system/studio76bot.service
      4. sudo systemctl daemon-reload && sudo systemctl enable studio76bot && sudo systemctl start studio76bot
      5. Smoke test: journalctl -u studio76bot -n 50 + envia /dd ou /cobrar no chat
      6. grep/replace nos arquivos de código + memória
      7. Atualizar Meta app display name
    • Effort: Low (~30min) | Impact: Medium (clareza de escopo + branding consistente)

Done (April 2026)

Done (March 2026)

Intake Log

When someone requests a feature, add it here first. Do NOT start working on it.
Review during morning check and assign priority.

Appendix: Pipeimob Automation Opportunities

Tasks agents currently do manually in Pipeimob that the bot can automate.