# Análise Nicho 22 — Agente Autônomo de Viagens Corporativas & Monitor Preditivo de Manejo Agroindustrial

## Veredito

**Este nicho não deve existir e não rende aplicação nenhuma.** O próprio título admite o problema: viagens corporativas e cultivo de camarão não compartilham usuário, dado, canal, jornada ou critério de sucesso — o regex costurou dois assuntos porque ambos apareceram como "operação especializada". A promessa da solução original ("Agente Autônomo de Operações Especializadas — Travel & AgroTech", com API de OBT e modelo de correlação de água/ração no mesmo produto) é a prova do agrupamento ruim: são duas empresas, dois roadmaps e zero código em comum.

Desmembrando: o canvas de Business Travel ([2]) é atendimento omnichannel com execução transacional, ou seja, nicho 2 — cliente pede cotação, cancelamento e reembolso por e-mail, telefone e WhatsApp, exatamente o que os apps `atendente-rag-externo` e `agendamento-selfservice` já cobrem; construir um "agente de viagens" separado seria refazer o mesmo produto para um vertical. E os canvases de carcinicultura ([0] e [1]) são o mesmo canvas duplicado de uma única empresa, pedindo um estudo de correlação sobre histórico de ciclos — trabalho analítico de consultoria, não produto replicável.

## Contagens

| Categoria | Qtd | Índices |
|---|---|---|
| FIT | 0 | — |
| ADJACENTE | 0 | — |
| OUTRO_NICHO | 1 | [2] → nicho 2 |
| RUIDO | 2 | [0], [1] |
| EXCLUIR | 0 | — |

Apps derivados: **nenhum**.

Duplicatas: [0] e [1] são o mesmo canvas de Pionerpaulo com projectIds diferentes → 1 empresa. Empresas únicas no grupo: 2.

---

## Canvas [2] — Business Travel (Rubens) → nicho 2

A dor é boa e detalhada: volume alto de tarefas repetitivas no atendimento (cotação, cancelamento, reembolso, dúvida sobre viagem), entrada por e-mail, telefone, WhatsApp e Teams, margem baixa, e o pedaço "offline" feito 100% por consultor humano enquanto o "online" já escala. Isso é literalmente o problema que o nicho 2 resolve, e o próprio autor descreve a solução como agentes conectados aos canais de atendimento com as ferramentas que o consultor usa.

Onde ele cai no nicho 2:
- Dúvida sobre política, regra de tarifa e status de viagem → `atendente-rag-externo` (RAG sobre política de viagem do cliente corporativo, resposta com citação).
- Cotação, remarcação, cancelamento e reembolso → `agendamento-selfservice`, que é slot-filling com escrita em sistema externo e human-in-the-loop para o que tem custo. A particularidade aqui é a integração com OBT/GDS, que é um conector, não um produto.
- Autorizador aprovando a viagem e consultor assumindo o caso complexo → `handoff-event` para o `cockpit-atendente-360`.

Não há nada nesse canvas que justifique produto próprio. O que ele traz de específico — API de OBT (Travellink), regra de fare rule, alçada de autorizador — é configuração e conector de um vertical, e cabe registrar como o primeiro caso de uso de "self-service transacional em sistema com alçada".

## Canvases [0] e [1] — Carcinicultura (Pionerpaulo): dor real, produto inexistente

Preciso ser explícito para não parecer descarte preguiçoso: **a dor é legítima e bem descrita** — viveiros da mesma fazenda, com a mesma densidade e a mesma gramatura-alvo, dão resultados extremos, e os ruins derrubam a média da fazenda. O que não existe é produto.

Três razões para não abrir app:
1. **Evidência mínima:** um canvas duplicado, uma empresa, um COO. Nenhum sinal de que o problema se repete em outro cliente da base.
2. **O entregável é um estudo, não um software:** o que o autor pede é cruzar ≥6 ciclos por viveiro (90 dias cada) e descobrir quais variáveis se correlacionam com sucesso e insucesso. Isso se responde uma vez, com análise de dados, e a resposta não precisa virar SaaS — vira decisão de manejo.
3. **O dado provavelmente não existe em forma utilizável:** parâmetros de água, ração, biometria e mortalidade em fazenda de camarão costumam estar em caderno de campo e planilha por viveiro, sem padrão entre ciclos. Antes de qualquer modelo, o projeto é de coleta e padronização — o que consome todo o orçamento de um MVP sem entregar IA nenhuma.

Se ainda assim o cliente quiser tocar, o escopo honesto é um piloto pago de análise, não um produto: padronizar a planilha de ciclo, consolidar os 6+ ciclos por viveiro num Postgres, produzir um painel comparativo entre viveiros com ranking de variáveis correlacionadas, e só depois — se o padrão se confirmar — discutir alerta de manejo quando uma variável sai da faixa dos ciclos bem-sucedidos. Nada disso deve entrar no portfólio de aplicações do programa.

Registro-os em `ruido` no JSON por ausência de campo melhor no schema: leia como "sem app derivado", não como "dor inválida".

## Recomendação de agrupamento

Dissolver o nicho 22. O canvas de travel vai para o nicho 2 e os de carcinicultura saem do escopo de produto. Nenhuma verba de construção deve ser alocada a este nicho.

---

## RESUMO JSON

```json
{
  "group_ids": [22],
  "apps": [],
  "reclassificacoes": [
    {"indices": [2], "destino_nicho": 2}
  ],
  "ruido": [0, 1],
  "excluir": []
}
```