ACCEPTANCE CRITERIA (0/13)

☐ AC1: `GET /api/crm/follow-ups` — lista paginada com filtros (assigned_to, status, follow_up_type, due_from, due_to, customer_id), campo `urgency` calculado ('overdue'|'today'|'upcoming'|'future'), campo `type_label` legivel em portugues, JOIN com customers para customer_name/business_name, ordenacao: overdue first, entao due_at ASC

☐ AC2: `POST /api/crm/follow-ups` — cria follow-up manual, valida customer_id existe, valida deal_id se fornecido, valida follow_up_type e valido, INSERT em follow_ups_crm, retorna registro criado com status 201

☐ AC3: `PATCH /api/crm/follow-ups/:id` — atualiza status ('done'|'cancelled'|'pending'), se status='done': seta completed_at=NOW() e completed_by (obrigatorio), se status='pending' (reabrir): limpa completed_at/completed_by, aceita atualizacao de due_at (adiar) e notes

☐ AC4: `GET /api/crm/dashboard/metrics` — retorna 13 metricas do Bowtie (leads_qualified_count, cr_total, avg_dt_b2b_days, avg_dt_b2c_days, orders_count, avg_ticket, overdue_deals_count, avg_nps, recompra_rate_90d, pending_follow_ups, queue_avg_wait_seconds, active_conversations, pipeline_total_value), aceita query param `period` ('7d'|'30d'|'90d', default '30d'), queries executadas em paralelo via Promise.all

☐ AC5: `GET /api/crm/dashboard/funnel` — dados do funil Bowtie por pipeline_type, para cada stage: count (deals que passaram no periodo), conversion_to_next (%), avg_days (tempo medio neste stage via deal_stage_log), requer query params pipeline_type e period

☐ AC6: `GET /api/crm/dashboard/activity` — feed das ultimas N atividades recentes (UNION ALL de 6 fontes: deal_stage_log, deals, follow_ups_crm, orders, nps_responses, attendant_notes), ordenado por timestamp DESC, aceita query param `limit` (default 20, max 50)

☐ AC7: `GET /api/crm/alerts` — alertas calculados em tempo real via 5 queries paralelas: lead_no_contact (deals B2B lead_qualificado >2h sem follow_up done, priority=critical), nps_pending (deals entregue >48h sem NPS, priority=high), customer_at_risk (B2B sem compra >60d, priority=high), deal_stalled (deals abertos acima do SLA, priority=medium), queue_long (>5 pendentes na handoff_queue, priority=medium); cada alerta com id, type, priority, title, description, customer_id, customer_name, deal_id, action_url, created_at; response inclui counts {critical, high, medium, total}

☐ AC8: `POST /api/crm/alerts/:id/dismiss` — endpoint no-op (retorna {success:true, dismissed_id}), o dismiss real e tratado no frontend via sessionStorage

☐ AC9: `GET /api/crm/attendants/me/summary` — requer query param agent_id, retorna: urgent (leads sem contato, conversas aguardando, follow-ups overdue), todays_follow_ups (follow-ups com due_at::date = CURRENT_DATE), my_pipeline (contagem por stage + total_value dos deals do atendente), queue_stats (count pendentes + avg_wait_seconds), todas as queries em paralelo

☐ AC10: `GET /api/crm/customers/:id/timeline` — timeline unificada paginada com UNION ALL de 7 fontes (messages, deal_stage_log, orders, shipments, nps_responses, follow_ups_crm, attendant_notes), cada evento com: id, type, icon, title, detail, actor, timestamp; paginacao com CTE + ROW_NUMBER; ordenacao por timestamp DESC

☐ AC11: `GET /api/crm/customers/:id/notes` — lista notas da tabela attendant_notes para o customer_id, ordenado por created_at DESC, inclui campo note_type (general/decision/alert)

☐ AC12: `POST /api/crm/customers/:id/notes` — cria nota, valida customer_id existe, valida note nao vazio, INSERT em attendant_notes com note_type (default 'general'), retorna nota criada com status 201

☐ AC13: Todos os novos routers registrados no `propek-whatsapp-bot/src/api/crm/index.ts`: follow-ups em `/follow-ups`, dashboard em `/dashboard`, alerts em `/alerts`, attendants em `/attendants`