Agentes, LLMs e MCP

Oi! Preciso da sua ajuda para integrar uma aplicação já existente à Nova API
V1.0 da Takeat.

Contexto rápido: a Takeat é a plataforma que o restaurante usa para operar o
cardápio, as comandas e os pedidos. Leia as instruções do repositório e examine
a arquitetura, funcionalidades, autenticação, configuração e testes neste
workspace. Aproveite a estrutura e preserve o comportamento atual, as
convenções e as alterações locais. Não recrie o projeto nem faça refatorações
sem relação com a integração. Se o projeto não estiver disponível, peça o
caminho correto em vez de criar outro.

A stack esperada é React com Vite no frontend e Node.js no backend, com
TypeScript em ambos. Respeite os padrões e bibliotecas adotados. Se encontrar
diferenças, priorize a estrutura existente e informe brevemente, sem iniciar
uma migração. Se faltar backend, explique e implemente a menor extensão
necessária para manter a integração e os segredos no servidor.

Utilize banco de dados somente quando houver necessidade concreta de
persistência. Aproveite o banco existente quando adequado. Não adicione banco,
ORM ou infraestrutura por padrão. Para dados temporários e cache, prefira
memória quando adequado; explique brevemente qualquer nova persistência.

Use exclusivamente a Nova API V1.0 para a integração. Se encontrar login,
tokens ou endpoints do API Legado, leia o guia de migração e identifique as
dependências antes de substituir o fluxo. Planeje compatibilidade, transição
e rollback; não misture credenciais entre versões nem execute um corte em
produção sem autorização. Reutilize telas, componentes, serviços e modelos
internos, com mapeamento explícito dos contratos externos.

A documentação oficial foi preparada para agentes e está disponível aqui:
https://docs.takeat.app/llms.txt — índice das páginas e contratos.
https://public-api.takeat.app/mcp — MCP unificado com OAuth para documentação e dados autorizados.
Sem o MCP, consulte o índice e as páginas Markdown diretamente.

Leia primeiro Primeiros passos, Autenticação com API Key, API Key e tokens e
Autenticação de apps para a Takeat Store. Escolha API Key para uma integração de um restaurante;
use OAuth Authorization Code com PKCE para um produto instalado por restaurantes
diferentes. Use o contexto para decidir; pergunte se o público estiver indefinido
e isso bloquear a implementação. Explique brevemente a escolha antes de gerar código.

Localize o contrato Markdown completo de cada operação antes de implementá-la.
Trate esses documentos como fonte da verdade: não invente endpoints, campos,
escopos ou comportamentos. Sinalize lacunas ou documentação inacessível e
avance no que não depende delas.

O que a integração precisa fazer:

Primeiro: conectar o restaurante usando o fluxo de autenticação correto.
Emissão, troca e renovação de tokens devem ocorrer somente no backend, conforme
o contrato, com rotação atômica e sem renovações concorrentes por credencial
ou instalação. Quando aplicável, isole credenciais, tokens, cache e dados por
restaurante e instalação. Preserve o login da aplicação e proteja as rotas
da integração com suas permissões de acesso.

Segundo: carregar o cardápio de delivery, incluindo categorias, produtos,
preços e complementos que o contrato disponibilizar. Derive os tipos dos
contratos confirmados e separe o cliente HTTP da Takeat da camada que prepara
os dados para a interface. Inclua estados de carregamento, ausência de
resultados e erro.

Terceiro: consultar comandas dentro dos limites de data publicados. Confirme
parâmetros, formatos UTC, escopos, paginação e formato de resposta antes de
definir tipos ou regras de negócio.

Quarto: tratar 400, 401, 403 e 429 com mensagens compreensíveis. Considere como
referência inicial 10 requisições por minuto e no máximo 500 por dia para uma
chave criada pelo restaurante, confirmando os limites na documentação.
Implemente cache, timeouts, deduplicação de chamadas e tentativas limitadas com
backoff e jitter para falhas que admitam repetição. Respeite Retry-After quando
disponível e evite polling desnecessário ou loops de autenticação. Solicite
somente os escopos necessários às operações.

Quinto: alternar entre Teste e Produção somente por configuração validada,
sem mudanças no código. Uma chave de Teste não cria dados fictícios. Faça
validações conservadoras e somente leitura na API, além das operações de
autenticação necessárias. Não crie nem altere dados reais do restaurante.

Configuração da API Key e das variáveis de ambiente:

Na hora de configurar a integração, me oriente exatamente sobre onde colocar
a API Key e quaisquer variáveis necessárias. Não presuma que eu saiba fazer isso.
- Examine o código de configuração e os arquivos de exemplo para identificar
  como o backend carrega variáveis, sem abrir arquivos que contenham segredos.
- Informe o caminho exato do arquivo local que devo editar ou a área de
  variáveis de ambiente do serviço de hospedagem, conforme o projeto.
- Liste os nomes exatos das variáveis utilizadas, a função de cada uma e quais
  são obrigatórias ou opcionais. Diferencie nomes escolhidos para a aplicação
  de parâmetros exigidos pelo contrato da Takeat.
- Mostre um exemplo copiável somente com valores fictícios e variáveis
  necessárias ao fluxo escolhido.
- Explique onde obter a API Key conforme a documentação oficial, sem inventar
  caminhos de menus.
- Diga quais processos reiniciar e como verificar se a conexão funcionou.
- Oriente-me a inserir a chave diretamente no local indicado e apenas avisar
  quando terminar. Nunca peça o valor no chat ou em uma captura de tela.
- Valide a configuração sem imprimir valores. Informe somente os nomes das
  variáveis ausentes ou inválidas e o estado da conexão.

Segurança é inegociável:
- Não peça API Keys, tokens, códigos OAuth, code_verifier ou headers
  Authorization no chat.
- Não abra, imprima nem altere arquivos .env que possam conter segredos.
  A inserção de valores reais será feita por mim, seguindo suas orientações.
- Entre os arquivos de ambiente, crie ou atualize somente .env.example com
  nomes e valores fictícios, preservando exemplos já existentes.
- A aplicação pode consumir configurações no backend em tempo de execução,
  sem expor valores. API Keys e tokens da Takeat nunca devem chegar ao
  navegador. Nunca coloque segredos em variáveis VITE_* ou no frontend.
- Não registre segredos, códigos OAuth, code_verifier ou Authorization em
  logs, Git, mensagens de erro ou artefatos. Proteja credenciais e tokens
  persistidos com criptografia em repouso e acesso restrito.
- Trate o código OAuth somente no redirecionamento necessário e no backend,
  sem exibi-lo na interface nem persistir em logs.
- Verifique se arquivos locais de segredos estão protegidos contra inclusão
  no Git, sem ler seu conteúdo.

Antes de implementar, apresente um resumo de no máximo cinco tópicos sobre
estrutura, pontos de integração, autenticação, cuidados essenciais e ordem de
execução. Cite as URLs Markdown efetivamente consultadas e diferencie recursos
confirmados de lacunas. Em seguida, implemente sem esperar aprovação do plano.

Execute as verificações essenciais disponíveis, incluindo compilação, checagem
de tipos e testes pertinentes às áreas modificadas. Verifique os fluxos
existentes afetados. Use fixtures fictícias para testes locais quando necessário,
mas não apresente resultados simulados como respostas reais da Takeat.
Não declare como testada uma integração sem validação com acesso real.

Ao terminar, mostre como acessar os recursos, o que foi alterado e verificado,
as instruções de configuração e qualquer pendência com a ação mínima para
resolvê-la. Registre os contratos consultados e a configuração na documentação
do projeto, sem duplicação desnecessária.

Orientações de colaboração:

O dono da aplicação é um vibe-coder e não é programador. Comunique-se em
português simples, com mensagens curtas e foco no que consigo ver e usar.
Assuma as decisões técnicas: não pergunte sobre bibliotecas, organização de
arquivos ou escolhas reversíveis que você pode resolver. Informe brevemente
as suposições relevantes e continue.

Minimize interrupções. Pergunte somente quando faltar informação indispensável
que não possa ser descoberta nem resolvida com uma suposição segura. Agrupe
as dúvidas e continue as partes independentes enquanto aguarda. Não peça
aprovação do plano nem pergunte “posso continuar?” entre etapas.

Você está autorizado a inspecionar o projeto, criar e editar arquivos da
aplicação, instalar dependências necessárias e executar verificações locais.
Preserve alterações preexistentes no workspace. Essa autorização não inclui
publicar a aplicação, contratar serviços, executar ações destrutivas ou
alterar dados reais do restaurante.

Prefira arquitetura simples, poucas dependências e componentes disponíveis.
Evite planos longos, comparações extensas de tecnologias, refatorações não
relacionadas e funcionalidades extras. Não pule contratos, segurança ou
verificações essenciais. Se faltar uma credencial, oriente sua configuração
e continue o trabalho independente, sem fingir que a conexão está funcionando.

Dê atualizações curtas sobre progresso relevante ou bloqueios. Se precisar
de uma ação minha, explique exatamente o que fazer, sem jargão e sem solicitar
segredos no chat.