Documenta exigir_codigo_confirmacao na abertura de entregas

[Joao-Dutra-Gaudium]

Documenta o parâmetro exigir_codigo_confirmacao em pages/v2/openapi-entregas.json,
nos dois endpoints de criação: POST /entregas e POST /entregas/programadas.

Estratégia. O campo entra no example e no schema.properties de cada requestBody,
como boolean opcional. A descrição nomeia as duas configurações distintas do cadastro da
empresa, que são fáceis de confundir: o parâmetro atua sobre Tornar os códigos de
confirmação de entrega obrigatórios, mas a geração do código continua dependendo de
Solicitar código de confirmação de entrega dos pedidos — em paradas sem código o
parâmetro não tem efeito. Na versão de programada, acrescenta que o valor é aplicado à
solicitação gerada no disparo. A entrada de changelog segue o template da skill do repo.

O parâmetro só acrescenta exigência. A coluna que sustenta o campo é
NOT NULL DEFAULT 0 (definição fechada na revisão dos líderes técnicos do txmback3),
então 0 é indistinguível de "não informado". A documentação reflete isso de forma
explícita: enviar true exige o código; omitir o campo ou enviar false mantém o que
está configurado. false não desliga uma exigência já configurada — é um no-op, não
uma dispensa. Essa frase é o ponto mais importante do texto, porque é a leitura que um
integrador tenderia a fazer errado.

Escopo. A edição de programada (PUT /entregas/programadas/{id}) ficou de fora: ela
aceita o campo por reusar o pipeline de criação no V1, mas documentar isso criaria contrato
para um comportamento que não foi decidido pelo produto. Não é particular deste parâmetro —
aquele endpoint já aceita ~10 campos de topo por herança de pipeline e documenta 5. Sugerido
card separado para a política daquele endpoint.

Motivação. Acompanhar a entrega do parâmetro na V2 da API (PR no txmback3); sem a
documentação, quem integra não tem como descobrir o campo.

---

Ponto em aberto para a revisão. O texto afirma que pedidos do iFood continuam exigindo
o código por regra da própria integração. Os testes manuais mostraram uma exceção
pré-existente: quando o condutor tem taxista.permite_finalizacao_sem_codigo_ifood, a
entrega é concluída sem código mesmo com o parâmetro true. É um flag interno, invisível
para quem integra. Deixei a frase como está porque há um card sugerido para decidir se o
parâmetro explícito da API deveria ter precedência sobre esse flag — se a decisão for que
deve, a documentação já está correta; se for que não, cabe acrescentar a ressalva aqui.

PR relacionado: txmback3, que
implementa o parâmetro.

[gaudinho]

✅ Review postada — #36 (review)

job_id: mintlify-docs-36-1785443280586-05fa

[gaudinho]

Documentação correta e de escopo mínimo: o campo exigir_codigo_confirmacao entra como boolean opcional no example e no schema.properties dos três endpoints que abrem/reenviam entrega, o JSON continua válido e a descrição registra bem os dois limites reais (só paradas com código de confirmação; iFood não relaxa). Deixei três sugestões informativas — nenhuma bloqueia o merge.

[Joao-Dutra-Gaudium]

/gaudinho review

[gaudinho]

✅ Review postada — #36 (review)

job_id: mintlify-docs-36-1785516932769-4b02

[gaudinho]

Documentação consistente e bem executada: o parâmetro entra no example e no schema.properties dos dois endpoints de criação, com descrição que registra os dois limites reais (só vale em parada com código de confirmação e não relaxa iFood), e a entrada de changelog segue à risca a skill do repo (data em PT-BR, label Novo para mudança só added, ordem cronológica decrescente, href válido apontando para páginas existentes). JSON continua válido e o diff é mínimo, sem alteração colateral.

[Joao-Dutra-Gaudium]

/gaudinho review

[gaudinho]

✅ Review postada — #36 (review)

job_id: mintlify-docs-36-1785518870870-6bd2

[gaudinho]

Documentação sólida e bem escopada: o campo entra no example e no schema.properties dos dois endpoints de criação, o JSON continua válido, o changelog segue exatamente o padrão dos Entries existentes e a ordem cronológica, e o commit 516c59d justifica por escrito a exclusão do endpoint de edição. Sem blockers — só sugestões de clareza.

[Joao-Dutra-Gaudium]

/gaudinho review

[gaudinho]

✅ Review postada — #36 (review)

job_id: mintlify-docs-36-1785519433707-f3ad

[gaudinho]

Documentação precisa e de escopo mínimo: o campo entra só nos dois endpoints de criação, com example + schema.properties coerentes, JSON válido e changelog inserido na posição cronológica correta seguindo o template da skill do repo. O destaque é a descrição distinguir as duas configurações do cadastro (obrigatoriedade × geração do código) e registrar a exceção do iFood — evita que o integrador conclua que o parâmetro funciona sozinho.