Atende Direito · Docs

Tema

Publicar uma solução ​

Publicar uma solução é o trabalho de quem cura o catálogo, não de quem desenvolve o produto. O objetivo desta página é que você consiga levar uma solução nova do rascunho até o catálogo sem precisar pedir ajuda a um desenvolvedor.

Quem pode publicar ​

Só entra em /admin/solucoes quem tem o papel de super-admin, system-admin, ou a permissão específica marketplace publish. Se você não vê o item "Soluções (curadoria)" no menu, é porque sua conta não tem nenhuma dessas três coisas — peça a um administrador.

Como funciona o ciclo de uma versão ​

Uma versão de solução passa por três estados, e o caminho é de mão única — não existe voltar um estado:

rascunho ──publicar──> publicada ──retirar de circulação──> retirada
  • Rascunho: você pode editar a ficha, a conversa e o formulário de instalação quantas vezes quiser. Nada nesse estado aparece no catálogo.
  • Publicada: assim que uma versão é publicada, ela fica imutável. Não existe "editar a versão 1.0.0 publicada" — para corrigir algo, você cria uma versão nova (1.0.1, por exemplo) a partir do mesmo fluxo ou de um fluxo atualizado, e publica essa.
  • Retirada: tira uma versão específica de circulação. Quem já instalou continua com a solução funcionando; tentativas novas de instalar essa versão passam a ser recusadas.

Isso é diferente de retirar a solução inteira do catálogo — ver a seção "Retirar do catálogo" mais abaixo.

Passo a passo pelo painel ​

  1. Em /admin/solucoes, clique em Nova solução. Preencha identificador (a URL amigável, só letras minúsculas, números e hífen), nome, área e, opcionalmente, tagline e descrição. A solução nasce em rascunho — sem nenhuma versão ainda.
  2. Abra a solução criada e adicione uma versão, escolhendo a origem (ver as duas seções seguintes).
  3. Preencha a ficha editorial e a conversa de demonstração — ver A ficha e a conversa para o que cada campo significa e por que algumas coisas são obrigatórias.
  4. Clique em Publicar. Se algum requisito faltar, o painel mostra exatamente o que corrigir (ver "Quando a publicação é recusada").

Criar uma versão a partir de um fluxo existente ​

Essa é a forma normal de criar uma versão: você aponta para um fluxo já publicado no seu escritório e o sistema empacota tudo o que ele precisa para funcionar em qualquer conta — o fluxo, o atendente (agent) que conversa, o funil (pipeline) que organiza os casos e, se você escolher, os grupos de lembrete (follow-up) que cobram quem sumiu.

No formulário, você informa:

  • O fluxo de origem e se quer usar a versão publicada ou o rascunho mais recente dele.
  • O rótulo da versão da solução (ex.: 1.0.0) — não confundir com a versão do fluxo.
  • O formulário de instalação: os campos que quem instalar vai precisar preencher (nome do negócio, canal, credenciais etc.).
  • Opcionalmente, o funil e os grupos de follow-up a incluir.

A versão nasce em rascunho. Você pode voltar e editar a ficha, a conversa e o formulário de instalação quantas vezes quiser antes de publicar.

Subir um pacote .adflow pronto ​

Se você já tem um pacote .adflow exportado de outro ambiente (ver Exportar e importar fluxos), pode subir esse arquivo diretamente em vez de apontar para um fluxo do seu escritório. Você informa o arquivo, a senha de abertura do pacote, o rótulo da versão e o formulário de instalação. O resultado é o mesmo: uma versão nova em rascunho, pronta para receber ficha e conversa.

Publicar por linha de comando (uso de desenvolvedor)

Esse caminho é para quem tem acesso técnico ao servidor — por exemplo, ao migrar um ambiente de testes para produção. Se você é curador e não tem esse acesso, use o painel normalmente; o resultado é o mesmo.

bash
php artisan marketplace:publish-from-flow {flow} \
  --slug=aposentadoria-especial \
  --name="Aposentadoria especial — Atendimento geral" \
  --category=previdenciario \
  --recipe-version=1.0.0 \
  --editorial=storage/app/editorial-aposentadoria-especial.json \
  --publish

Atenção: a opção correta é --recipe-version, não --version — esse nome diferente existe para não colidir com um comando padrão do sistema que já usa --version para outra coisa.

Sem --publish, o comando só cria o rascunho — você ainda precisa escrever a ficha e a conversa pelo painel (ou apontar --editorial para um arquivo já pronto com o conteúdo da ficha e da conversa) antes de publicar. A opção --dump grava uma cópia completa da versão em disco, útil para quem versiona o conteúdo de soluções internas.

O que a publicação exige ​

Ao clicar em Publicar, o sistema roda três checagens bloqueantes, nesta ordem. Se qualquer uma falhar, nada é salvo — a versão continua em rascunho exatamente como estava.

  1. Formulário de instalação válido — os campos que quem instalar vai precisar preencher batem com o que o fluxo realmente usa.
  2. Ficha editorial completa — ver A ficha e a conversa.
  3. Conversa de demonstração válida — inclui o teste de procedência de cada fala e o teto de duração.
  4. Nenhum dado de um cliente específico — ver "Quando a publicação é recusada" abaixo.

Quando a publicação é recusada ​

As mensagens de erro são escritas para quem cura, não para quem programa — elas dizem exatamente o que falta e onde. Alguns exemplos do que reprova uma publicação:

  • Ficha sem limite ou sem "o que não faz": "Ficha inválida: limit é obrigatório." O chip de limite e a lista de restrições existem para vender a limitação da solução junto com a capacidade — publicar sem isso deixaria a expectativa do cliente maior do que a solução realmente entrega.
  • Conversa sem recusa: "Conversa inválida: falta o momento em que a assistente diz o que NÃO faz." Toda demonstração precisa mostrar a assistente recusando alguma coisa — é o momento em que ela diz que a análise é do advogado.
  • Fala sem procedência: "source é obrigatório para a assistente." Toda fala da assistente precisa declarar se veio de um texto fixo do fluxo ou se é gerada em tempo real pelo agente.
  • Recusa sem âncora: "a recusa precisa citar, em groundedInDoesNot, um dos limites declarados em 'o que não faz'." Uma recusa gerada pelo agente não pode ser texto livre — ela tem que apontar para um limite que já está na ficha.
  • Conversa longa demais: "a demonstração dura X ms e o teto é 22000 ms."
  • Dado de cliente: e-mail, telefone, CPF, CNPJ, tratamento pessoal (Dr./Dra.) ou texto entre colchetes não preenchido ([nome do escritório]) em qualquer campo — do fluxo, da ficha ou da conversa. O formato de variável do produto é {{...}}, nunca colchetes simples.

Todas essas mensagens aparecem no painel assim que a publicação é recusada — não é preciso olhar log nenhum.

Existem dois níveis de retirada, e eles não são a mesma coisa:

AçãoO que aconteceQuem já instalou
Retirar de circulação uma versãoEssa versão específica some das novas instalaçõesContinua funcionando normalmente
Tirar do catálogo a solução inteiraA solução some da vitrine públicaContinua funcionando normalmente

Retirar de circulação a última versão publicada de uma solução tira a solução inteira da vitrine automaticamente (não sobra versão publicada para mostrar) — mas o histórico e as instalações existentes não são apagados. Para publicar de novo, basta publicar uma versão nova.

Saiba mais ​