Coroid utiliza um mecanismo dedicado Mecanismo de decisão para questões com um conjunto conhecido de respostas. O modelo inicial é Jev 1.13, disponibilizado via OpenRouter. Ele opera ao lado dos modelos de arquiteto, desenvolvedor, QA e revisor no seu perfil AI; não se trata de outro agente que escreve código ou invoca ferramentas.
Como funciona uma decisão
Coroid envia o estado relevante e um contrato de questão versionado. Em vez de solicitar a um modelo de chat que invente e formate uma resposta JSON, ele fornece as opções permitidas. O Jev retorna uma resposta estruturada e informações de probabilidade.
- Escolha seleciona uma opção fornecida, com distribuição de probabilidade e nível de confiança.
- Pontuação avalia os critérios ordenados fornecidos, com probabilidades e nível de confiança.
- Noul expressa um julgamento de sim/não como uma probabilidade entre zero e um.
Coroid valida a resposta conforme o contrato exato, verifica o nível de confiança e as regras do fluxo de trabalho, e só então a utiliza. Se a resposta for incerta, inválida ou indisponível, o avaliador de fluxo de trabalho existente cuida da decisão.
Onde é utilizado
| Fluxo de trabalho | Decisão | O que permanece inalterado |
|---|---|---|
| Evidência de aceitação | Classificar um critério como visual, comando, estático ou não verificável | A verificação ainda deve ser executada e gerar evidências. |
| Pré-verificação de QA | Classificar uma falha, avaliar sua capacidade de correção e identificar caminhos relevantes a partir dos logs fornecidos | Correções, testes e aprovação de QA permanecem separados. |
| Qualificação do trabalho | Avaliar a relevância para a versão atual, duplicatas, reprodutibilidade e roteamento | Uma duplicata deve referenciar um candidato fornecido; casos já corrigidos exigem evidências fornecidas. |
| Roteamento de tarefas | Classificar o tipo e a complexidade do trabalho, e selecionar habilidades compatíveis. | O tipo de trabalho explícito, substituições de modelo, orçamentos e seleção de perfil são preservados. |
O mecanismo não gera planos de implementação, patches, evidências arbitrárias, caminhos de arquivo novos ou explicações de revisor. Nós de qualificação com seleção explícita de modelo mantêm essa seleção em vez de usar o Jev.
Configure seu perfil
- Abra Configurações → AI profile e selecione um perfil adequado para novas tarefas.
- Budget, Smartest, Quick e Ludicrous incluem a atribuição do motor de decisão Jev.
- Em um perfil personalizado editável, atribua Jev 1.13 a Decision engine. Os modelos de chat são excluídos dessa função, e o Jev é excluído das funções de agente de chat.
- Certifique-se de que o OpenRouter esteja ativado e de que uma chave de provedor de plataforma ou organização elegível esteja disponível. As políticas de modelo de projeto e organização ainda se aplicam.
Não existem controles de temperatura, raciocínio ou fallback de chat para essa função. Fallback significa retornar ao avaliador existente do fluxo de trabalho, não enviar uma solicitação de decisão a um modelo de chat arbitrário.
Perfis gratuitos e com restrição de residência não têm automaticamente atribuído um modelo pagado do OpenRouter. Perfis personalizados existentes não são alterados silenciosamente. Os snapshots de execução mantêm suas atribuições originais; portanto, inicie novas tarefas após alterar um perfil para testar a nova atribuição. Veja Perfis do AI.
Ativação e fallback seguro
A ativação em tempo de execução é controlada por implantação, separadamente para cada fluxo de trabalho. No desenvolvimento local, todos os quatro fluxos de trabalho têm as decisões reais habilitadas por padrão após migrações. Outros ambientes mantêm suas configurações de lançamento até que um operador aprove as versões de contrato relevantes.
Mesmo quando habilitado, o Coroid recorre ao fallback se o perfil não tiver um modelo de decisão elegível, credenciais ou bloqueio de política de acesso, se a solicitação exceder o tamanho suportado, se o provedor estourar o tempo limite ou se uma resposta falhar na validação ou nos testes de confiança. Uma decisão não suportada ou ambígua não deve se tornar uma verificação bem-sucedida silenciosamente.
Os operadores podem usar desativado, sombra ou forçado modos. O modo sombra registra uma comparação mas mantém o resultado do avaliador existente; o modo forçado usa uma decisão validada de um contrato aprovado. Esses controles de tempo de execução não ocultam este guia nem a descrição pública do produto.
Uso e registros de auditoria
As chamadas usam a mesma seleção de chave de provedor, verificações de política de organização e contabilidade de uso que outras operações de modelo, atribuídas à função de motor de decisão. Respostas cobradas são registradas mesmo que suas respostas sejam rejeitadas. O BYOK segue os termos de cobrança do provedor; não é necessária uma chave Typesafe separada.
O registro de decisão operacional inclui o fluxo de trabalho, versão do contrato, revisão do modelo real, probabilidades, se o resultado foi aplicado, motivo do fallback, latência da decisão e correlação de uso. Ele armazena um resumo do estado de entrada, não o prompt bruto ou as credenciais. A retenção segue a política de log de agente da organização. Esse registro de auditoria é distinto de uma explicação gerada ou relatório de teste.
Testar localmente
Use uma nova tarefa com um perfil que inclua o Jev. Exercite o planejamento de aceitação, pré-verificação de QA com uma falha conhecida, qualificação do trabalho e roteamento normal de tarefas. Verifique a auditoria de decisão para obter um modo forçado e um resultado aplicado. Uma entrada de fallback explica por que o Jev não controlou essa decisão específica; isso não prova que o fluxo de trabalho falhou. Tarefas existentes podem ter um snapshot de perfil sem o Jev.