Publica en el marketplace

Al final de este tutorial tu juego está listado en el marketplace e incrustable por cualquier usuario, por su id de juego. Publicar es deliberadamente de baja ceremonia: no hay cola de envío, ni revisión, ni subida. Etiquetas un repo público de GitHub y la plataforma lo indexa.

Esto asume que has construido un juego (Construye un juego del marketplace) y escrito su manifiesto.

1. Etiqueta el repositorio de GitHub

Añade el topic de GitHub caputchin-game a tu repositorio público (la sección About en la página del repo). El indexador consulta GitHub por este topic; esa etiqueta es todo tu opt-in.

Tu id de juego se deriva de la coordenada del repo, owner/repo (o owner/repo/<leaf-dir> para un hijo de colección). No lo eliges ni lo declaras.

2. Confirma lo esencial del manifiesto

Tres cosas condicionan la indexación; asegúrate de que tu caputchin.json raíz las tiene:

1. "terms_accepted": true (el booleano literal) confirmando los Términos de Envío del Marketplace.
2. Una license en la lista aprobada.
3. Un puntero de distribución (entry, npm, o ambos) para que el bundle resuelva.

Añade un marketplace.author.email si quieres correos de fallo de publicación (nunca se muestra públicamente, y es la única forma de recibirlos).

3. Publica o actualiza

Dos formas de aterrizar en el índice:

• El cron diario recoge los repos etiquetados automáticamente.
• El botón "Publicar o actualizar" del marketplace corre el indexador por repo de forma síncrona y te redirige a tu página de detalle, o muestra el error de validación exacto. Usa esto para un primer listado o justo después de una edición del manifiesto.

Cuando corre, el indexador descarga tu manifiesto, fija el bundle a una ref inmutable (la versión de npm publicada o el SHA de commit resuelto), computa un hash de integridad SHA-384, y guarda { url, integrity } indexado por tu id de juego. Las nuevas releases salen en vivo en la siguiente ejecución del índice, o al instante vía el botón.

4. La autocomprobación de repetición

En tiempo de indexación la plataforma corre tu artefacto run en un isolate sellado una vez con una semilla determinista:

• Pasa → tu juego es reproducible: la ronda de un jugador real se vuelve a correr en el servidor para llegar a la decisión, así que puede ejercer de gate de una clave de sitio.
• Falla (run-not-conforming) → el juego muestra No reproducible. Sigue listado e incrustable, pero solo como UX hasta que publiques una versión conforme. Los sitios que ya están en una versión reproducible anterior siguen corriendo esa instantánea exacta.

Una autocomprobación que falla es casi siempre no-determinismo en tu run; haz tu simulación determinista y vuelve a publicar. Correr primero el selfCheck del engine kit en local atrapa esto antes de que empujes.

5. Verifica el descubrimiento

Tras una publicación exitosa, la página de detalle incrusta tu juego en una vista previa en vivo con una perilla por cada preset de locale, skin, y configuración declarado. Juégalo ahí para confirmar que los presets resuelven como pretendías.

Recibe notificación cuando una publicación falla

El indexador diario vuelve a comprobar cada juego publicado. Si una reindexación topa con un problema, se te puede notificar por correo, pero solo si haces opt-in fijando marketplace.author.email en tu manifiesto. Sin correo fijado, no recibes notificaciones. No hay otro canal; esta es la única señal que de otro modo te perderías, porque la recomprobación diaria corre sin que tú la mires.

Se envían dos tipos de correo, coincidiendo con los dos desenlaces:

Detalles que importan:

• Solo la reindexación diaria te envía correo. Un fallo en el botón manual "Publicar o actualizar" se te muestra en el modal en ese momento, así que no se envía correo por él.
• Deduplicado. El mismo fallo en el mismo juego se envía por correo una vez, luego se suprime durante 30 días. Un fallo distinto (un nuevo código de error o motivo) envía correo de inmediato.
• Haz opt-out en cualquier momento quitando o cambiando marketplace.author.email. Los correos también llevan un puntero de baja de un clic a los Términos de Envío. Aquí no eres una cuenta de Caputchin, así que el campo del manifiesto es el único control.

6. Automatiza con CI

Como publicar es "etiqueta más push a una ref inmutable", puedes cablearlo en tu pipeline de release para que cada release se reindexe automáticamente. El patrón fiable:

1. Publica el bundle a una ref inmutable en CI, el publish de npm (o una release etiquetada de GitHub) contra la que resuelve el npm / entry de tu manifiesto. El indexador siempre vuelve a resolver a tu última versión publicada en su siguiente ejecución, así que un pipeline de release normal ya avanza la fijación.
2. Condiciona la release a una comprobación de determinismo local. Corre el selfCheck del engine kit (o tu propio test de repetición) como un paso de CI para que un run no determinista haga fallar el build en vez de publicarse como no reproducible.
3. Opcionalmente dispara una reindexación inmediata llamando a "Publicar o actualizar" en vez de esperar al cron diario, si quieres la nueva versión en vivo en el momento en que 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

Mantén la comprobación de determinismo antes de publicar para que un run malo nunca llegue al marketplace como un listado silenciosamente no reproducible.

Lo que nunca tienes que hacer

• Sin firma de código, sin envío a revisión, sin subida al CDN de la plataforma.
• Sin acuerdo de reparto de ingresos.
• Sin elegir id; tu coordenada de GitHub es el id.
• Sin campo de versión; el indexador fija la ref.

Si la publicación falla

Cada error del camino de publicación es algo que arreglas en tu repo y reintentas. Encuentra tu código en Arregla un fallo de publicación; la lista completa de códigos es la referencia de errores de publicación.

Véase también

• Arregla un fallo de publicación: arreglos paso a paso por código de error.
• El manifiesto caputchin.json: los campos que el indexador valida.
• El contrato de repetición: lo que la autocomprobación corre.