Processo de revisão: contas de teste, observações e iterações

1. Visão de alto nível do processo de revisão

A publicação de um ChatGPT App na Store — não é “subiu o link e esqueceu”, e sim um ciclo vivo. Em uma versão simplificada, funciona assim: você prepara o App, envia para revisão, os revisores o testam com seus check‑lists, você recebe observações, faz ajustes e envia novamente. E assim por algumas rodadas, até que tudo fique aceitável para todos.

O mais conveniente é encarar isso como um pequeno fluxo de trabalho (workflow):

flowchart TD
  A[Dev Mode / Internal beta] --> B[Submit to Store]
  B --> C[Under review]
  C -->|Approved| D[Published]
  C -->|Changes requested| E[Fixes & Iteration]
  E --> B
  D --> F[Updates]
  F --> C
  D --> G[Paused / Unpublished]

Nas etapas iniciais (Dev Mode, beta interno) você captura problemas técnicos e de UX. Quando clica em “Submit to Store”, começa uma revisão mais formal: analisam a conformidade com a política de conteúdo, as permissões, a estabilidade e o que está escrito na listagem e nos documentos jurídicos.

É útil adotar desde cedo a filosofia de que a revisão — não é um exame em que você “passa” e nunca mais volta, ou “reprova”. É um canal contínuo de feedback entre você e a plataforma. A Store quer que seu App seja seguro, claro e estável; você quer ser liberado para os usuários e não ser removido uma semana depois. Surpresa: os interesses de vocês, na verdade, coincidem.

2. O que você envia para a revisão

Antes que alguém do lado da plataforma abra seu App, você preenche um conjunto bem comum de itens:

1. Metadados do App: nome, subtítulo, categoria, ícone.
2. Descrição da listagem: descrição curta e completa, exemplos de cenários.
3. Links para Privacy Policy, Terms, Support/Contact.
4. Configurações de permissões: quais acessos o App solicita (por exemplo, OAuth, APIs externas, modos de pagamento etc.).
5. Às vezes — a descrição de cenários de teste e contas para o revisor.
6. O próprio App: servidor MCP, bundle de UI, system‑prompt e descrições de tools que a plataforma já conhece pelo Dev Mode/production‑URL.

Tecnicamente, nessa altura você já faz o deploy da versão de produção (geralmente na Vercel ou similar), para a qual a Store fará as requisições. Ou seja, o botão “Submit” — não é sobre fazer deploy do código, mas sobre mudar o status: “este código já está no seu ambiente de produção; agora, por favor, revisem e liberem para os usuários”.

Para amarrar todas as partes, costuma ser útil ter um pequeno config no repositório, onde você registra explicitamente o que entra na versão “candidata à revisão”. Por exemplo, uma estrutura simples em TypeScript:

// config/release-candidate.ts
export const releaseCandidate = {
  version: "1.0.0",
  apiBaseUrl: process.env.API_BASE_URL,
  enableCommerce: true,
  privacyPolicyUrl: "https://example.com/legal/privacy",
  termsUrl: "https://example.com/legal/terms",
  supportUrl: "https://example.com/support",
};

Esse arquivo não substitui o formulário da própria Store, mas ajuda sua equipe a entender o que exatamente você está “entregando” aos revisores e aos usuários.

3. Como os revisores avaliam seu App

Você preencheu os formulários, preparou os links e clicou em Submit. O que acontece do outro lado da Store? Imagine que você é o próprio revisor. Você não viu seu código, não conhece o histórico do projeto, mas tem um check‑list e tempo limitado. Normalmente, o App é visto sob alguns ângulos.

Primeiro, observam a conformidade com a política de conteúdo e com a marca. Não é permitido oferecer categorias proibidas, violar regras de medicina, direito ou finanças sem os devidos disclaimers e “human in the loop”. Não se pode fingir ser a OpenAI nem usar a marca deles como se fosse um produto oficial.

Em segundo lugar, analisam as permissões. Se você pede acesso a algo sensível (perfis de usuário, pagamentos, conta de terceiros via OAuth), vão perguntar: isso é realmente necessário? E é claro para o usuário pela descrição e pelo comportamento do App? O ideal é que as permissões sejam mínimas e estejam alinhadas com os cenários descritos.

Em terceiro, avaliam o UX e a estabilidade. O App não deve tomar a tela inteira do ChatGPT: se ele abre fullscreen o tempo todo sem motivo, sem explicação clara, isso conta negativamente. Se o backend lança erros com frequência e as ferramentas quebram de vez em quando, também não inspira confiança.

Por fim, verificam a honestidade da listagem: o que você descreve sobre o App bate com o que o revisor realmente vê no chat? Se você promete “seleção relâmpago do presente perfeito e checkout instantâneo”, mas na prática o App falha três vezes na busca e não consegue fechar pedidos, a revisão termina rápido e de forma desagradável.

Para facilitar o trabalho dos revisores, faz sentido preparar um “roteiro”: uma lista de passos a tentar e os resultados esperados. Isso também será útil para a sua própria regressão.

Um exemplo simples desse tipo de descrição em código é uma estrutura com cenários de revisão, à qual você pode se referir na documentação interna:

// test/review-scenarios.ts
export const reviewScenarios = [
  {
    id: "gift-basic",
    title: "Seleção de presente sem compra",
    steps: [
      "Peça: Sugira um presente para um amigo que gosta de jogos de tabuleiro, orçamento de US$ 50",
      "Verifique se o App propõe opções e não exige login",
    ],
  },
  {
    id: "gift-checkout",
    title: "Seleção de presente com checkout de teste",
    steps: [
      "Escolha qualquer presente da lista",
      "Avance para a finalização usando um cartão de teste",
    ],
  },
];

Essa estrutura não vai direto para a Store, mas disciplina sua equipe e depois ajuda a atualizar a descrição para revisores e para o suporte técnico.

4. Contas e dados de teste: sem eles, a revisão não decola

Assim que entram dinheiro, dados pessoais ou contas externas, os revisores esperam que você forneça uma forma segura de percorrer todo o cenário sem usar o cartão real deles, o e‑mail pessoal ou um Slack/Google/qualquer‑coisa reais.

De modo geral, há dois grandes tipos de entidades de teste.

O primeiro tipo — usuários/organizações de teste no seu sistema. Por exemplo, para o GiftGenius você pode criar uma “organização de revisão” especial com um catálogo demo pré‑preparado e métodos de pagamento de teste vinculados ao modo sandbox do provedor de pagamentos. É importante que o revisor não passe por um onboarding complicado: idealmente, ele deve receber um login/senha ou um link mágico e cair direto em um ambiente de testes pronto.

O segundo tipo — dados de teste de provedores externos. Pagamentos, em geral, têm modo sandbox (test cards, test accounts). Se seu App delega o pagamento via ACP/Instant Checkout, você deve se certificar de que ele usa o ambiente de teste durante a revisão e ninguém paga com dinheiro real. Isso já toca a arquitetura da parte de commerce, mas a ideia é simples: adicionar no backend uma flag “review/test mode”.

Em termos de código, isso pode parecer uma simples flag de ambiente e um config:

// config/env.ts
export const env = {
  nodeEnv: process.env.NODE_ENV,
  reviewMode: process.env.REVIEW_MODE === "true",
  paymentProviderEnv: process.env.REVIEW_MODE === "true" ? "sandbox" : "production",
};

E no ponto onde você inicializa o cliente do sistema de pagamentos:

// lib/payments/client.ts
import { env } from "@/config/env";

export const paymentClient = createPaymentClient({
  environment: env.paymentProviderEnv, // "sandbox" ou "production"
  apiKey: process.env.PAYMENT_API_KEY!,
});

Esse detalhe facilita muito a vida: você pode executar o App em um modo o mais parecido possível com produção, mas sem que os revisores mexam com dinheiro de verdade.

Também vale planejar cenários de teste para integrações como Gmail, Slack, Notion etc. Onde se usa OAuth, a revisão costuma esperar ou uma conta demo compartilhada, ou um passo a passo muito simples para criar um workspace de teste. Procure evitar cenários do tipo “escreva para o suporte que ativamos algo manualmente” — a revisão geralmente é automatizada e tem tempo limitado, e ninguém vai ficar esperando seu e‑mail.

5. Observações típicas de revisão e como responder a elas

Agora, talvez, uma notícia não muito agradável: a chance de que sua primeira passagem na revisão seja perfeita é parecida com a chance de um programador escrever código sem bugs de primeira. Ou seja, perto de zero. E tudo bem.

As observações geralmente caem em algumas categorias previsíveis.

A primeira categoria — permissões e privacidade. Por exemplo, você solicita acesso ao e‑mail do usuário, mas a listagem não explica para quê. Ou na Privacy Policy está escrito que você “não armazena dados do chat”, mas os logs do servidor MCP gravam toda a requisição com PII. O revisor pode pedir para esclarecer os documentos, alterar o comportamento do App ou ambos.

A segunda categoria — UX e comportamento no chat. O App pode “dominar” o diálogo: abrir fullscreen de forma agressiva onde poderia ser inline, não deixar um resumo de texto após as ações, não dar ao usuário uma forma clara de “voltar ao chat”. Nesses casos, provavelmente vão pedir que você simplifique o UX e respeite a interface de diálogo principal do ChatGPT.

A terceira categoria — estabilidade e erros. Se em cenários comuns o App frequentemente exibe “Error talking to app” ou erros internos 500, a revisão pode parar até que você mostre que é um caso isolado, e não a regra. Espera‑se de você não só a correção dos bugs, mas também um mínimo de observabilidade: logs, health checks, timeouts razoáveis.

A quarta categoria — honestidade da listagem e promessas de marketing. Se na descrição você promete mais do que realmente entrega, os revisores costumam notar rapidamente, especialmente se você promete “resultados garantidos” em domínios sensíveis. A correção aqui tem dois passos: ou reduz as promessas, ou aumenta a implementação (geralmente o primeiro).

Como responder adequadamente às observações? A regra principal é encarar a revisão como uma parceria, e não como “moderadores malvados”. Na resposta, é útil:

1. Reconhecer claramente o problema: “Sim, na versão atual o App faz X, mas na descrição está Y”.
2. Descrever o que você já alterou: “Ajustamos a listagem e atualizamos a Privacy Policy, esclarecendo que…”.
3. Se possível, incluir uma breve descrição do cenário de teste em que o revisor verá a correção.

Se você não entende claramente por que veio a observação, é melhor fazer uma pergunta de esclarecimento do que tentar adivinhar. Por exemplo: “Entendemos corretamente que o principal problema é o App abrir fullscreen automaticamente sem solicitar ao usuário?”.

6. Checklist interno antes de enviar para revisão

Para reduzir o número de iterações, é útil ter um “checklist de pre‑flight” próprio, inspirado nos módulos 7, 15–17. Não é uma lista “para marcar”, e sim algo prático que você realmente percorre antes de cada submissão.

Tecnicamente, você pode até codificar esse checklist no repositório como um pequeno módulo JSON/TS e executá‑lo no README ou no pipeline.

Uma opção simples em TypeScript pode ser assim:

// tools/review-checklist.ts
export interface ChecklistItem {
  id: string;
  description: string;
  done: boolean;
}

export const reviewChecklist: ChecklistItem[] = [
  {
    id: "ux-inline-first",
    description: "Os cenários principais do App funcionam no modo inline; fullscreen apenas quando realmente justificável.",
    done: false,
  },
  {
    id: "privacy-links",
    description: "Os links para Privacy Policy, Terms e Support são válidos e abrem sem autenticação.",
    done: false,
  },
  {
    id: "permissions-minimal",
    description: "Somente as permissões minimamente necessárias são solicitadas; cada uma está descrita na listagem.",
    done: false,
  },
];

E em alguma ferramenta interna ou mesmo no console você pode exibir essa lista e marcar o progresso. Não é automação obrigatória, mas desenvolvedores geralmente se dão melhor com código do que com Google Docs, então por que não usar a ferramenta habitual.

7. Iterações e versionamento: a vida após a primeira publicação

Surpresa número dois: mesmo depois que seu App passa na revisão e fica disponível para os usuários, o processo não termina. Qualquer atualização relevante pode acionar uma nova verificação, especialmente se você mudar permissões, adicionar novos cenários sensíveis ou redesenhar o UX radicalmente.

Por isso, trate o ChatGPT App como um produto vivo com um processo de release normal, e não como um “tiro único”.

O mínimo razoável costuma ser: ter uma versão no código (semver), um registro de mudanças (changelog) e clareza sobre quais releases exigem revisão novamente e quais não. Por exemplo, corrigir erros de digitação no UI, sem afetar o comportamento do App e as permissões, pode passar em silêncio; já mudar de “apenas recomendações” para “checkout completo com pagamento” certamente exigirá nova atenção.

No código, isso pode aparecer como uma constante simples e um objeto com mudanças:

// config/app-version.ts
export const appVersion = "1.1.0";

export const appChangelog = {
  "1.1.0": [
    "Adicionado checkout em sandbox para usuários de teste",
    "Ajustada a descrição das permissões na listagem",
  ],
  "1.0.0": ["Primeira versão pública do GiftGenius sem pagamento"],
};

E sim, é ótimo se você sincronizar essas notas com o que escreve nas release notes da Store. Assim fica mais fácil para revisores e usuários entenderem o que aconteceu.

8. Comunicação com a plataforma: como não brigar com os revisores

Talvez a habilidade mais subestimada seja conversar direito com os revisores. Em geral, o feedback vem como um conjunto de pontos: o que está errado, em quais itens da política você esbarrou, quais partes do UX levantam dúvidas. Uma boa resposta não é “Vocês não entendem nada”, e sim uma mensagem calma e objetiva.

Vale manter alguns princípios simples em mente.

Em primeiro lugar, clareza. Não escreva textos quilométricos sobre como é a arquitetura interna do seu servidor MCP e por que ele é tão bonito. O que interessa ao revisor é, antes de tudo, a experiência do usuário e a conformidade com a política. Basta descrever brevemente o que você mudou e como agora isso pode ser verificado.

Em segundo lugar, transparência. Se o problema é mais complexo do que “corrigimos o texto” e exige mudanças significativas, é mais honesto escrever: “Esta observação afeta uma parte chave do nosso fluxo de checkout; precisamos de 1–2 semanas para corrigir adequadamente. Enviaremos a versão atualizada assim que estiver pronta”.

Em terceiro lugar, memória. As observações da revisão devem ser registradas não só no e‑mail ou no rastreador interno, mas também como uma pequena “decisão” na documentação: o que exatamente era proibido e por quê. Isso ajuda novos desenvolvedores e o produto a não repetirem os mesmos erros. Aqui pode ajudar uma nota interna simples na documentação ou até uma seção README do tipo “Store Review Decisions”.

9. Relação com a arquitetura e com os módulos anteriores

É útil enxergar o processo de revisão como uma “prova integradora” de tudo o que você fez nos módulos anteriores.

Sem os módulos de segurança e permissões (7, 15), você provavelmente terá dúvidas sobre acessos, trabalho com PII, OAuth e ações destrutivas.

Sem os módulos de estabilidade e observabilidade (16, 17), você não conseguirá explicar por que o App às vezes cai e às vezes não, nem como você monitora isso. Métricas e SLO deixam de ser teoria e viram argumentos: “vemos p95 < 2 segundos para a ferramenta principal e error rate < 1 % nos últimos N dias”.

Sem os módulos de UX (8, 11), o App pode simplesmente “quebrar” o chat: fullscreen onde não é necessário, transições confusas entre modos, ausência de um resumo em texto. Os revisores percebem essas coisas mais rápido do que você, porque testam muitos Apps diferentes e sentem bem quando alguém “exagera”.

E, por fim, sem o entendimento do processo de revisão de hoje, você corre o risco de ficar emperrado na fase “enviamos, devolveram, ficamos chateados”. O correto é encarar isso como mais um ciclo de iterações, muito parecido com a sua regressão interna, só que com mais um participante interessado — a plataforma.

No fim, se você tem um checklist razoável, contas de teste e modo sandbox, observabilidade básica e uma comunicação normal com os revisores, o processo de revisão deixa de ser uma loteria. É apenas mais um ciclo iterativo em torno do seu ChatGPT App — tão natural quanto a regressão antes do release ou o code review dentro da equipe.

10. Erros comuns ao passar pela revisão

Erro nº 1: Enviar o App “como está” sem um checklist interno.
Muitas equipes clicam em “Submit” logo após o App “rodar” no Dev Mode. Como resultado, aparecem coisas básicas na revisão: links quebrados para Privacy/Terms, cenários que não funcionam, falta de contas de teste. Resolve‑se com um checklist interno simples, que você realmente percorre antes de cada submissão (links válidos, permissões mínimas, cenários chave funcionando) — um exemplo desse checklist foi mostrado acima na seção “Checklist interno antes de enviar para revisão”.

Erro nº 2: Ignorar contas de teste e modos sandbox.
Enviar para revisão um App que exige o cartão bancário real do revisor — é uma má ideia. É igualmente ruim se o checkout existe “no papel”, mas o revisor não consegue testá‑lo de forma alguma. É preciso planejar com antecedência organizações/usuários de teste no seu sistema e o modo sandbox do provedor de pagamentos, vinculado à flag REVIEW_MODE ou similar.

Erro nº 3: Tentar “negociar” exceções em vez de corrigir o problema.
Às vezes os desenvolvedores começam a discutir com o revisor: “mas o concorrente faz igual” ou “isso é limitação da plataforma, não é culpa nossa”. Esse estilo raramente ajuda. Muito mais eficaz é reformular o cenário, simplificar o UX, reduzir permissões e ajustar a listagem para refletir honestamente o comportamento do App.

Erro nº 4: Não documentar as observações e as decisões.
Se você recebeu um comentário da revisão e apenas “corrigiu o bug no código”, sem registrar o que exatamente era proibido, em seis meses alguém na equipe fará a mesma coisa de novo. É melhor manter um pequeno registro de decisões da revisão: “Não abrir fullscreen automaticamente sem ação explícita do usuário”, “não armazenar textos completos de chats por mais de N dias sem indicação explícita na Policy” etc.

Erro nº 5: “Grandes releases” sem uma estratégia em etapas.
Tentar, em um só release, adicionar pagamentos, novas permissões, novo UX e backend refeito — é uma receita para longas iterações de revisão. Muito mais tranquilo é lançar em passos pequenos: primeiro recomendações sem pagamento, depois — checkout em sandbox, depois — fluxo de pagamento completo. Assim você reduz riscos e dá menos margem para questionamentos na revisão.

Erro nº 6: Depender da aceitação da Store em vez do seu próprio QA e observabilidade.
Às vezes a equipe, sem perceber, espera que os revisores “testem por eles”. O resultado é que a revisão vira um QA gratuito, mas atrasa o lançamento por semanas. É bem mais saudável encarar a revisão como a verificação final de sanidade de um produto já bastante maduro, que tem seus próprios testes, logs, métricas e cenários claros.