---
title: Publicar uma solução
description: Quem pode publicar uma solução no catálogo do Atende Direito, o ciclo de vida de uma versão e o passo a passo pelo painel de curadoria.
---

# 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](/guia/marketplace/ficha-e-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](/guia/flow-builder/portabilidade)), 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.

::: details 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](/guia/marketplace/ficha-e-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 é <code v-pre>{{...}}</code>, nunca colchetes simples.

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

## Retirar do catálogo

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

| Ação | O que acontece | Quem já instalou |
|---|---|---|
| **Retirar de circulação** uma versão | Essa versão específica some das novas instalações | Continua funcionando normalmente |
| **Tirar do catálogo** a solução inteira | A solução some da vitrine pública | Continua 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

- [A ficha e a conversa](/guia/marketplace/ficha-e-conversa) — os campos obrigatórios e por quê
- [O que é uma solução](/guia/marketplace/o-que-e) — de onde vem o conteúdo que aparece no catálogo
- [Instalar uma solução](/guia/marketplace/instalar-uma-solucao) — o outro lado do processo