1) Princípios do projeto

1.1. Prioridade: API oficial antes de scraping

Para compras públicas, há caminhos oficiais bem mais sólidos do que automação de navegador:

• PNCP tem documentação e Swagger públicos para consulta de contratações, atas, etc. (PNCP)
• Compras.gov.br / dados abertos também possui documentação de API (inclusive manual recente em PDF) e Swagger. (Serviços e Informações do Brasil)

Isso reduz risco de bloqueio, melhora estabilidade e permite rodar com frequência maior.

Para marketplaces privados, o cenário varia. Em alguns, “scraping” é explicitamente vedado em termos (ex.: Mercado Livre proíbe uso de robôs/scraping nos termos de Developers). (Mercado Livre Developers)
Nesses casos, o correto é usar API oficial quando existir; se não houver, o projeto precisa operar com limites técnicos e jurídicos bem definidos.

1.2. “Robô” como produto: conectores + pipeline + painel

O robô não é um script; é um sistema com:

• conectores por site (API/HTML/Playwright),
• pipeline padronizado (normalização, dedupe, histórico),
• motor de regras + IA (score e alertas),
• painel com login para configurar tudo.

2) Arquitetura recomendada (Opção B – Profissional)

Camada A — Conectores (por origem)

Tipos de origem:

1. APIs públicas (preferência)
   • PNCP, Compras.gov, e eventualmente portais que ofereçam endpoint. (PNCP)
2. HTML estático (requests + parser)
3. Navegador controlado (Playwright) apenas quando necessário (site dinâmico/login)
   • Playwright tem boas práticas e suporte a execução em CI/Docker. (Playwright)

Observação prática: cada site vira um “conector” isolado, com contrato de dados padrão.

Camada B — Normalização e Dados

Pipeline:

• Parsing: preço/frete/data/local, padronização de moeda e unidades.
• Deduplicação: por URL + fingerprint (título normalizado + vendedor + preço).
• Histórico: registrar “snapshots” para comparar variação de preço e recorrência de vendedor.
• Banco recomendado: PostgreSQL.

Camada C — Motor de Filtros + Score (regras + IA)

1. Filtros determinísticos (o que o cliente escolhe)

• faixa de preço, UF/cidade/raio, condição, frete máximo, palavras proibidas etc.

1. Consistência / risco (o que o sistema calcula)

• outliers (ex.: z-score/IQR por categoria/região),
• campos faltantes,
• padrões suspeitos no texto (ex.: “chama no Whats”, “sem nota”, “sem documento”),
• frete incoerente (frete/valor acima de um limite relativo),
• vendedor “novo” ou com poucos sinais de confiança (quando a origem fornece isso).

1. Score final e motivos

• Score 0–100 e lista de motivos padronizados (ex.: PRECO_FORA_CURVA, FRETE_ALTO, ANUNCIO_INCOMPLETO, PALAVRA_PROIBIDA).

Camada D — Saída: planilha + alertas

• Google Sheets (API) e/ou Excel (XLSX) gerado.
• Alertas: WhatsApp/Telegram/e-mail, conforme canal escolhido.

Camada E — Painel Web (login e senha)

Funções mínimas do painel:

• cadastro de origens (site/API) e status de saúde do conector,
• cadastro de consultas (produto + filtros),
• agenda (08:00 / 18:00 etc.),
• gestão de palavras proibidas, limites de frete, parâmetros de outlier,
• visualização: “Top oportunidades”, “Suspeitos”, “Histórico”.

3) Escopo realista para 45 dias

Para cumprir prazo com qualidade, eu trataria como MVP profissional com limites claros:

MVP (entrega em 45 dias)

1. Até 3 origens prioritárias

• 1–2 portais públicos (via API) + 1 marketplace/site privado (conforme viabilidade).

1. Até 10 consultas/filtros configuráveis no painel.
2. Planilha padrão + ranking + aba suspeitos + resumo (conforme sua descrição).
3. Alertas em 1 canal (Telegram ou e-mail; WhatsApp pode exigir camada adicional).

Itens fora do MVP (podem entrar se sobrar folga)

• múltiplos logins diferentes por site,
• captcha forte / anti-bot avançado,
• enriquecimento externo de “preço de mercado” por fontes pagas.

4) Cronograma detalhado (45 dias)

Semana 1 — Descoberta e especificação fechada

• lista de sites e produtos-alvo
• definição de filtros e regras (tabeladas)
• decisão do canal de alerta
• desenho do modelo de dados e contratos dos conectores

Saída: documento de requisitos + protótipo de planilha final (colunas/abas).

Semana 2 — Base do sistema

• banco (Postgres) + estrutura de histórico
• serviço de coleta (jobs) + logs + reprocessamento
• primeiro conector (preferencialmente API pública)

Semana 3 — Motor de filtros e normalização

• normalização completa (preço, frete, local, datas)
• dedupe e histórico
• filtros configuráveis por consulta no painel

Semana 4 — Score e detecção de inconsistência

• regras de outlier e consistência
• motivos do score (auditáveis)
• geração de ranking e abas (“suspeitos”)

Semana 5 — Painel com login + integração planilhas

• autenticação (login/senha)
• CRUD de consultas/filtros
• export para Google Sheets e/ou XLSX

Semana 6 — Alertas + endurecimento

• alertas (evento: “novo top 10”, “suspeito crítico”, “queda de preço”)
• monitoramento (falha de conector, tempo de execução)
• documentação e handover

Saída: sistema rodando em servidor, com agenda diária, painel e entregáveis.

5) Critérios de aceite (para evitar ambiguidades)

1. O sistema roda em agenda (ex.: 08:00 e 18:00), registra execução e falhas.
2. Para cada consulta, gera:
   • planilha com colunas combinadas (Preço, Frete, Total, Vendedor, Cidade, Link, Score, Motivos…)
   • aba “Top oportunidades”
   • aba “Suspeitos”
   • resumo estatístico simples (média/mediana por filtro)
3. Painel permite:
   • criar/editar consultas e filtros
   • ativar/desativar consulta
   • ajustar parâmetros de score (limites, palavras proibidas)
4. Alertas disparam quando:
   • entra item no top 10
   • item marcado como “suspeito crítico”
   • queda de preço acima de X%

6) Riscos e como o projeto se protege

6.1. Termos de uso e bloqueios

• Marketplaces podem proibir robôs/scraping (há exemplos explícitos). (Mercado Livre Developers)
  Mitigação:
• priorizar API oficial
• limites de taxa (rate limiting), cache, e frequência compatível
• conformidade com regras do site e coleta mínima necessária

6.2. Portais públicos heterogêneos (prefeituras)

Cada prefeitura pode ter um portal diferente. Mitigação:

• começar com PNCP/Compras.gov (cobertura ampla via API) (PNCP)
• tratar “portais isolados” como fase 2, por conector específico.

7) Plano de execução alinhado ao comercial (R$ 3.000 + 2x R$ 2.500)

Uma divisão prática por marcos:

• Entrada (R$ 3.000): Semana 1–2 (especificação fechada + base + 1º conector funcionando)
• Parcela 1 (R$ 2.500): Semana 3–4 (normalização, filtros, score, ranking)
• Parcela 2 (R$ 2.500): Semana 5–6 (painel com login, planilhas, alertas, endurecimento e entrega)