Name: leostera/riot
Author: Habilidades de la comunidad

Servicios Riot

Ciclo de Servicio

Usa riot-contributor primero para el flujo de trabajo del repositorio, manejo del árbol de trabajo sucio y expectativas de validación.
Trabaja desde el directorio específico del sitio/servicio; cada servicio posee su propio package.json, bun.lock, tsconfig.json y generalmente wrangler.toml.
Usa bun run <script> en lugar de invocar herramientas directamente cuando exista un script.
Conserva los lockfiles por servicio. No agregues un espacio de trabajo JS en la raíz del repositorio a menos que se pida explícitamente.
Trata los despliegues, migraciones remotas, pruebas e2e en vivo, cambios de tokens, cambios de DNS y cambios de datos de producción como operaciones que requieren aprobación explícita del usuario.
Prefiere verificaciones locales y simulacros primero; las pruebas en vivo son optativas a través de variables de entorno específicas del servicio.

sites/api.pkgs.ml: Worker del plano de control del registro de paquetes. Posee flujos de publicación/autenticación/búsqueda/vistas/eventos, migraciones D1, esquema Drizzle, claves de almacenamiento R2, colas, coordinación de publicación con Durable Objects y flujo de trabajo de respaldo D1.
sites/cdn.pkgs.ml: Worker CDN para artefactos de paquetes, documentos de índice disperso, metadatos binarios de Riot/OCaml y análisis de acceso. Reutiliza tipos del registro y ayudantes de almacenamiento de ../api.pkgs.ml/src.
sites/docs.pkgs.ml: Servicio de documentación generada de paquetes. Sirve documentos desde R2, consume colas de paquetes publicados/procesados, registra ejecuciones de pipelines/eventos en el D1 del registro y usa contenedores Sandbox de Cloudflare para verificación de compilación de documentación.
sites/pkgs.ml: Aplicación web pública del registro de paquetes, Astro + adaptador Cloudflare + islas React. Lee APIs de vistas del registro y documentos de índice disperso.
sites/riot.ml: Sitio web estático principal de Riot, Astro + Tailwind, despliegue estilo Pages.
sites/get.riot.ml: Worker proxy/redirección del script de instalación.

Usa Wrangler para el ciclo de vida del Worker/servicio Astro: wrangler dev, wrangler deploy, wrangler d1 migrations apply, wrangler pages deploy, wrangler types y desarrollo local basado en configuración.
Mantén la dependencia local de wrangler actualizada y fijada por el lockfile, en lugar de depender de una instalación global.
Usa el CLI unificado cf solo para inspección de API/recursos u operaciones que actualmente expone, especialmente cuenta, zona, DNS, API D1, API R2, API de colas, metadatos de API de Workers y descubrimiento de esquemas.
Antes de usar cf para mutaciones reales en Cloudflare, ejecuta npx cf auth whoami e inspecciona la forma del comando con npx cf agent-context <product> o npx cf schema <comando...>.
No reemplaces los scripts de despliegue/desarrollo/migración de Wrangler con cf a menos que el comando específico del servicio se haya verificado localmente y soporte el mismo comportamiento basado en configuración.

Mantén sincronizados wrangler.toml, las interfaces TypeScript Env exportadas y los entornos falsos de prueba.
Prefiere interfaces Env explícitas en los puntos de entrada de Workers y módulos compartidos.
Coloca valores predeterminados no secretos en [vars]; mantén los secretos en .env, secretos de Wrangler o secretos gestionados por Cloudflare.
Para cambios de esquema D1 en api.pkgs.ml, agrega migraciones SQL bajo sites/api.pkgs.ml/migrations/ y actualiza src/schema.ts/ayudantes de DB juntos.
El acceso en tiempo de ejecución a D1 se realiza a través de ayudantes Drizzle en api.pkgs.ml/src/db.ts, metadata-db.ts, pipeline-db.ts, access-db.ts o un archivo hermano con nombre específico.
Los contratos de clave de objetos R2 viven en api.pkgs.ml/src/storage.ts; actualiza los consumidores de CDN/API/web y las pruebas juntos al cambiar las claves.
La forma de los eventos del registro es historial de servicio orientado al usuario. Agrega nuevos tipos de eventos a api.pkgs.ml/src/types.ts, serialización en DB, vistas y pruebas.

Ejecuta bun run check del servicio modificado antes de finalizar.
Ejecuta bun run test cuando el servicio defina pruebas locales.
No ejecutes bun run deploy, bun run migrate:remote ni pruebas en vivo test:e2e a menos que se solicite explícitamente.
Para api.pkgs.ml, las pruebas locales usan FakeR2Bucket, FakeD1Database, FakeQueue y FakeExecutionContext de tests/helpers.ts.
Para cdn.pkgs.ml, reutiliza las simulaciones falsas del registro en lugar de inventar mocks del SDK de Cloudflare.
Para docs.pkgs.ml, prefiere ejecutores de pipeline falsos y ayudantes de drenaje de cola; afirma el orden durable mediante la secuencia de la base de datos al probar flujos de eventos.
Para servicios Astro, ejecuta bun run check; espera que Astro regenere los archivos de tipo .astro como parte de la verificación.

Respeta la pila de UI existente de cada servicio. pkgs.ml usa salida de servidor Astro, islas React, Tailwind y adaptador Cloudflare; docs*.ml usan Starlight cuando corresponde; riot.ml es un sitio estático de Astro.
Mantén las primeras pantallas como superficies reales de producto/servicio, no como marcadores de marketing.
Usa componentes, diseños, tokens CSS, fuentes y convenciones de ruta existentes antes de agregar abstracciones.
Para cambios web del registro, prefiere las APIs de vista del registro en sites/pkgs.ml/src/lib/web-views.ts y los ayudantes de índice disperso en package-index.ts.

Trata los endpoints de producción como reales: api.pkgs.ml, registry.pkgs.ml, cdn.pkgs.ml, pkgs.ml, docs.pkgs.ml, docs.riot.ml, play.riot.ml, riot.ml y get.riot.ml.
Nunca ejecutes restauración/exportación/importación remota de D1, escrituras DNS, escrituras de ruta/dominio, despliegues u operaciones de token sin dirección explícita del usuario.
Si se solicita una prueba de humo en vivo, lee primero el README/puertas de entorno de ese servicio y declara qué variables de entorno hacen que la prueba sea destructiva o autenticada.