Publicar no marketplace

Ao final deste tutorial seu jogo está listado no marketplace e embutível por qualquer usuário, pelo seu id de jogo. Publicar é intencionalmente de baixa cerimônia: não há fila de submissão, nem revisão, nem upload. Você marca um repositório público do GitHub com uma tag e a plataforma o indexa.

Isto assume que você construiu um jogo (Construir um jogo de marketplace) e escreveu seu manifesto.

1. Marque o repositório do GitHub com uma tag

Adicione o tópico do GitHub caputchin-game ao seu repositório público (a seção About na página do repositório). O indexador consulta o GitHub por este tópico; essa tag é toda a sua adesão.

Seu id de jogo é derivado da coordenada do repositório, owner/repo (ou owner/repo/<leaf-dir> para um filho de coleção). Você não o escolhe nem o declara.

2. Confirme os essenciais do manifesto

Três coisas gateiam a indexação; garanta que seu caputchin.json raiz as tenha:

1. "terms_accepted": true (o booleano literal) confirmando os Termos de Submissão do Marketplace.
2. Uma license na lista aprovada.
3. Um ponteiro de distribuição (entry, npm, ou ambos) para que o bundle resolva.

Adicione um marketplace.author.email se você quer os e-mails de falha de publicação (ele nunca é mostrado publicamente, e é a única forma de recebê-los).

3. Publicar ou atualizar

Duas formas de cair no índice:

• O cron diário pega repositórios marcados automaticamente.
• O botão "Publicar ou atualizar" no marketplace roda o indexador por repositório de forma síncrona e te redireciona para a sua página de detalhe, ou mostra o erro de validação exato. Use isto para uma primeira listagem ou logo após uma edição de manifesto.

Quando roda, o indexador busca seu manifesto, fixa o bundle em uma ref imutável (a versão npm publicada ou o SHA de commit resolvido), computa um hash de integridade SHA-384, e armazena { url, integrity } chaveado pelo seu id de jogo. Novos releases entram no ar na próxima execução do índice, ou na hora pelo botão.

4. A autoverificação de replay

No momento da indexação a plataforma roda seu artefato run em um isolate selado uma vez com uma semente determinística:

• Passa → seu jogo é reproduzível: a rodada de um jogador real é reexecutada no servidor para chegar à decisão, então ele pode proteger uma chave de site.
• Falha (run-not-conforming) → o jogo mostra Não reproduzível. Ele ainda é listado e embutível, mas só como UX até você publicar uma versão conforme. Sites já em uma versão reproduzível anterior continuam rodando aquele instantâneo exato.

Uma autoverificação que falha é quase sempre não determinismo no seu run; torne sua simulação determinística e republique. Rodar o selfCheck do kit de engine localmente primeiro pega isto antes de você dar push.

5. Verifique a descoberta

Após uma publicação bem-sucedida, a página de detalhe embute seu jogo em uma prévia ativa com um botão para cada preset de idioma, skin e configuração declarado. Jogue-o ali para confirmar que os presets resolvem como você pretendia.

Seja notificado quando uma publicação falha

O indexador diário recheca cada jogo publicado. Se uma reindexação bate num problema, você pode ser avisado por e-mail, mas só se você optar por isso definindo marketplace.author.email no seu manifesto. Sem e-mail definido, você não recebe notificações. Não há outro canal; este é o único sinal que você de outra forma perderia, porque a recheca diária roda sem você observando.

Dois tipos de e-mail são enviados, correspondendo aos dois resultados:

Detalhes que importam:

• Só a reindexação diária te envia e-mail. Uma falha no botão manual "Publicar ou atualizar" é mostrada a você no modal na hora, então nenhum e-mail é enviado por ela.
• Deduplicado. A mesma falha no mesmo jogo é enviada por e-mail uma vez, depois suprimida por 30 dias. Uma falha diferente (um novo código de erro ou motivo) envia e-mail na hora.
• Saia quando quiser removendo ou mudando marketplace.author.email. Os e-mails também carregam um ponteiro de cancelamento de inscrição de um clique para os Termos de Submissão. Você não é uma conta Caputchin aqui, então o campo do manifesto é o único controle.

6. Automatize com CI

Como publicar é "marcar com tag mais push para uma ref imutável", você pode conectá-lo ao seu pipeline de release para que cada release reindexe automaticamente. O padrão confiável:

1. Publique o bundle em uma ref imutável na CI, o publish do npm (ou um release do GitHub marcado com tag) contra o qual o npm / entry do seu manifesto resolve. O indexador sempre re-resolve para a sua versão publicada mais recente na sua próxima execução, então um pipeline de release normal já avança a fixação.
2. Gateie o release em uma checagem de determinismo local. Rode o selfCheck do kit de engine (ou o seu próprio teste de replay) como um passo de CI para que um run não determinístico falhe a build em vez de ser publicado como não reproduzível.
3. Opcionalmente dispare uma reindexação imediata chamando "Publicar ou atualizar" em vez de esperar pelo cron diário, se você quer a nova versão no ar no instante em que a CI termina.

# sketch: release job
- run: npm ci
- run: npm test                 # includes your replay selfCheck
- run: npm publish              # advances the immutable ref the indexer pins
# the daily indexer picks up the new version; or hit Publish or update for instant

Mantenha a checagem de determinismo antes do publish para que um run ruim nunca chegue ao marketplace como uma listagem silenciosamente não reproduzível.

O que você nunca precisa fazer

• Sem assinatura de código, sem submissão para revisão, sem upload para um CDN da plataforma.
• Sem acordo de divisão de receita.
• Sem escolha de id; sua coordenada do GitHub é o id.
• Sem campo de versão; o indexador fixa a ref.

Se a publicação falhar

Todo erro do caminho de publicação é algo que você corrige no seu repositório e tenta de novo. Ache seu código em Corrigir uma falha de publicação; a lista completa de códigos é a referência de erros de publicação.

Veja também

• Corrigir uma falha de publicação: correções passo a passo por código de erro.
• O manifesto caputchin.json: os campos que o indexador valida.
• O contrato de replay: o que a autoverificação roda.