DeepSeek modificado: desenhar estados de API antes de escrever endpoints

Exemplo mínimo de API

Código Python ilustrativo, não uma resposta executada. A chave vem do ambiente e as repetições automáticas estão desativadas. Uma conexão perdida pode deixar resultado e custo desconhecidos: não repita às cegas.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-deepseek-v4-1-flash",
    max_tokens=512,
    messages=[{"role": "user", "content": "Crie uma lista de verificação para minha tarefa. Separe fatos e suposições."}],
)
print(response.choices[0].message.content)

Dê nome aos estados que o cliente precisa compreender

Um serviço de agendamento pode receber um pedido, conferir disponibilidade, confirmar uma vaga ou recusar a solicitação. Antes de escrever rotas, defina quais estados são persistentes e quais são apenas fases de apresentação. Carregando na tela não informa se a reserva existe. Uma API precisa tornar compreensível o que foi aceito e qual ação ainda depende de confirmação posterior.

Peça uma tabela com estado atual, evento, condição de entrada, efeito e próximo estado. Inclua eventos inesperados, como cancelar antes da confirmação ou receber uma confirmação atrasada. O propósito é revelar ambiguidades do contrato. Não aceite um diagrama em que toda seta seja permitida: algumas transições precisam ser rejeitadas para evitar que uma reserva cancelada volte a ocupar uma vaga sem decisão explícita.

Escreva invariantes que sobrevivam às transições

Para o agendamento, um invariante pode ser que uma vaga não tenha duas reservas confirmadas para o mesmo intervalo. Outro pode impedir que um cancelamento altere uma reserva de outra pessoa. Forneça esses compromissos na entrada e peça que a proposta aponte qual camada os garante. Um teste de tela não substitui uma restrição ou transação necessária na camada de armazenamento.

Diferencie o evento recebido do efeito já realizado. Uma solicitação de cancelamento pode estar aceita sem que todas as etapas externas tenham terminado. A resposta ao cliente deve refletir essa diferença e explicar o que ainda está pendente. É melhor manter um estado intermediário verificável do que apresentar uma conclusão otimista que depois não corresponda aos registros efetivos do serviço.

Vincule respostas HTTP ao contrato da sua aplicação

Defina para cada rota os campos de entrada, o recurso devolvido e os erros que o cliente consegue tratar. A mesma palavra erro não deve misturar validação inválida, conflito de vaga e ausência de confirmação de rede. Solicite exemplos de formatos como propostas de contrato e revise-os com os consumidores reais. Não publique esses exemplos como respostas já verificadas de uma infraestrutura em funcionamento.

Se o seu serviço precisa de idempotência, projete armazenamento, escopo e regras de repetição dele explicitamente. Um identificador enviado no cabeçalho não cria essa propriedade sozinho. Essa decisão do exemplo de aplicação não deve ser atribuída à API pública do Dikaya: este guia não inventa um suporte de idempotência para as chamadas de inferência nem recomenda repetir automaticamente operações de resultado desconhecido.

Derive testes de aceite de cada transição importante

Peça cenários com estado inicial, ação, resultado esperado e efeitos que não podem ocorrer. Inclua duas solicitações concorrentes para a mesma vaga, cancelamento repetido e resposta atrasada depois de o cliente sair da tela. Faça os testes percorrerem o comportamento público do sistema. Uma verificação que apenas confirma a chamada de uma função interna pode deixar escapar a violação da regra principal.

Execute os cenários no ambiente local e inspecione o armazenamento quando o contrato depender de persistência. O modelo pode sugerir testes e implementação, mas não possui por esse motivo execução nativa de terminal. Registre comandos realmente rodados e resultados observados. Se uma ferramenta da sua IDE executar ações, deixe claro que ela pertence à integração e depende de controles próprios, não ao nome DeepSeek.

Registre identidade, esforço e orçamento sem extrapolar

Escolha seller-deepseek-v4-1-flash explicitamente para manter a identidade modificada separada da 1017 original. Os níveis declarados low, high e max não são garantias de ausência de recusa nem classificação de qualidade. Defina o esforço e um teto de saída como controles separados. O contexto amplo declarado não elimina limites de corpo JSON, histórico do chat ou tamanho dos arquivos enviados.

As imagens desta configuração passam por uma ponte paga para descrição textual quando permitidas. Para revisar um diagrama de estados, prefira uma representação textual com eventos e condições, conferida contra o desenho. A busca explícita do chat pago pode reunir documentação, mas não constitui uma ferramenta de internet nativa de toda chamada API. O demo do Pro 2 tampouco concede acesso automático a esta identidade.

A própria integração precisa representar incerteza

Na chamada de inferência, configure max_retries=0 no SDK e diferencie respostas HTTP recebidas de erros de conexão. O Fetch também distingue uma resposta com status de erro de uma promessa rejeitada por falha de rede. Essas fontes explicam mecânicas de transporte, não o acerto financeiro de um pedido. Perder a confirmação não prova que a operação não começou ou que não haverá custo.

Mantenha o resultado como desconhecido até que haja evidência suficiente para classificá-lo. Ofereça conferência e uma decisão manual de repetição, sem transformar a ausência de texto em sucesso ou rejeição confirmada. Antes de enviar um rascunho pelo chat, confira o seletor e as permissões; um texto armazenado pode prevalecer sobre a preparação desta página. O roteiro só prepara trabalho, sem enviar nem executar o serviço proposto.

Perguntas e respostas

Esta é a mesma identidade que a versão 1017?

Não. seller-deepseek-v4-1-flash identifica a variante modificada, enquanto seller-deepseek-v4-1-flash-1017 identifica o original com Safeguards. Mantenha os identificadores completos em configurações e registros. A diferença não autoriza prometer respostas universais, ausência de recusa ou vantagem de qualidade de uma variante sobre a outra sem evidência específica.

Por que separar desconhecido de falhou?

Uma conexão interrompida pode impedir a confirmação de uma operação que já começou. Chamar esse caso de falha definitiva permite repetições indevidas e conclusões incorretas sobre efeitos ou custos. Modele o desconhecido como estado próprio, conserve os registros e procure evidências antes de decidir se uma nova tentativa é apropriada.

A proposta de idempotência vale para a API do Dikaya?

Não. Projetar idempotência para o serviço de agendamento é uma tarefa da aplicação usada como exemplo. Isso exige contrato e persistência próprios. Não equivale a documentar uma funcionalidade da API pública de inferência, e não justifica inserir um cabeçalho inventado ou repetir automaticamente uma chamada que perdeu confirmação.

Como conferir uma máquina de estados sugerida?

Revise cada transição contra os invariantes e escreva testes para eventos fora de ordem, concorrência e efeitos proibidos. Execute os testes no sistema real, inclusive na persistência quando necessário. Um diagrama coerente no papel não demonstra que a implementação bloqueia transições inválidas ou preserva o estado após uma interrupção.

Fontes

Conteúdo preparado com auxílio de IA. Os exemplos são ilustrativos, não respostas reais nem testes comparativos. As fontes externas não substituem os termos do serviço.

• Dikaya: documentação de integração e limites
  dikaya.cc
• Dikaya: identidades DeepSeek do catálogo
  dikaya.cc
• Dikaya: preços e condições de acesso
  dikaya.cc
• MDN: comportamento de erro e cancelamento no Fetch
  developer.mozilla.org
• SDK Python: erros e tentativas automáticas
  github.com