Pular para o conteúdo principal

Pedir ajuda, e onde falar

Antes de perguntar​

Quase tudo o que dá errado na primeira semana está em Solução de problemas, e a resposta para o meu provedor é suportado? está em Provedores.

Se o agente fala mas nunca toca nos seus arquivos, isso quase sempre é o modelo e não a instalação — teste-o antes de gastar uma noite em configuração.

Onde perguntar​

GitHub Issues — bugs, e qualquer coisa que se comportou diferente do que a documentação diz.

GitHub Discussions — perguntas, ideias e «isto deveria funcionar assim?».

Ainda não há servidor de chat. Vai haver quando houver gente suficiente para valer a pena ficar nele; uma sala vazia não ajuda ninguém.

O que torna um relato fácil de atender​

Quatro linhas, e a maioria dos relatos não as tem:

  1. O modelo e o provedor, com o nome exato — qwen3-coder:30b no Ollama, não «um modelo local».
  2. O que você pediu a ele, literalmente.
  3. O que aconteceu, e o que você esperava no lugar.
  4. As últimas cinquenta linhas de ~/.opencli/log em volta da falha.

Confira se há chaves nessas linhas antes de colar.

O que mais ajuda​

Uma linha na tabela de modelos. Testar um modelo é uma tarefa fixa e uns cinco minutos. A tabela é curta porque só contém o que foi executado, e um resultado negativo vale tanto quanto um positivo — ninguém publica sobre o modelo que não funcionou, então todo mundo redescobre.

Uma tradução, ou uma correção em uma delas. Vêm dez. Qualquer uma pode ser corrigida linha a linha sem tocar no resto — veja Idiomas.

Contar para a gente o que você realmente tentou fazer. Os departamentos e fluxos que já vêm foram escritos a partir de palpites sobre o que as pessoas precisam. O que você procurou e não achou é a coisa mais útil que você pode dizer.

Contribuir com código​

Contribuir tem a preparação do ambiente e o processo de pull request.