Name: leostera/riot
Author: Habilidades da Comunidade

Serviços Riot

Ciclo de Serviço

Use riot-contributor primeiro para fluxo de trabalho do repositório, manipulação de árvore suja e expectativas de validação.
Trabalhe a partir do diretório específico do site/serviço; cada serviço possui seu próprio package.json, bun.lock, tsconfig.json e geralmente wrangler.toml.
Use bun run <script> em vez de invocar ferramentas diretamente quando existir um script.
Preserve lockfiles por serviço. Não adicione um workspace JS na raiz do repositório a menos que seja explicitamente solicitado.
Trate deploys, migrações remotas, testes e2e ao vivo, alterações de tokens, alterações de DNS e alterações em dados de produção como operações que exigem aprovação explícita do usuário.
Prefira verificações locais e fakes primeiro; testes ao vivo são opcionais através de variáveis de ambiente específicas do serviço.

sites/api.pkgs.ml: Worker do plano de controle do registro de pacotes. Possui publicar/auth/buscar/visualizações/eventos, migrações D1, esquema Drizzle, chaves de armazenamento R2, filas, coordenação de publicação de Durable Objects e fluxo de trabalho de backup D1.
sites/cdn.pkgs.ml: Worker CDN sobre artefatos de pacotes, documentos de índice esparso, metadados binários Riot/OCaml e análises de acesso. Reutiliza tipos de registro/auxiliares de armazenamento de ../api.pkgs.ml/src.
sites/docs.pkgs.ml: serviço de documentação gerada de pacotes. Serve docs do R2, consome filas de pacotes publicados/processados, registra execuções/eventos de pipeline no D1 do registro e usa contêineres Cloudflare Sandbox para verificação de construção de docs.
sites/pkgs.ml: aplicativo web público do registro de pacotes, Astro + adaptador Cloudflare + ilhas React. Lê APIs de visualização do registro e documentos de índice esparso.
sites/riot.ml: site estático principal do Riot, Astro + Tailwind, implantação estilo Pages.
sites/get.riot.ml: Worker de redirecionamento/proxy do script de instalação.

Use Wrangler para ciclo de vida de serviços Worker/Astro: wrangler dev, wrangler deploy, wrangler d1 migrations apply, wrangler pages deploy, wrangler types e desenvolvimento local orientado por configuração.
Mantenha a dependência wrangler local do serviço atualizada e fixada pelo lockfile em vez de depender de uma instalação global.
Use a CLI unificada cf apenas para inspeção de API/recursos ou operações que ela atualmente expõe, especialmente conta, zona, DNS, API D1, API R2, API de filas, metadados da API Workers e descoberta de esquema.
Antes de usar cf para mutações reais no Cloudflare, execute npx cf auth whoami e inspecione a forma do comando com npx cf agent-context <product> ou npx cf schema <command...>.
Não substitua scripts de deploy/dev/migração do Wrangler por cf a menos que o comando específico do serviço tenha sido verificado localmente e suporte o mesmo comportamento orientado por configuração.

Mantenha wrangler.toml, interfaces TypeScript Env exportadas e ambientes fake de teste sincronizados.
Prefira interfaces Env explícitas em entrypoints de Worker e módulos compartilhados.
Coloque defaults não secretos em [vars]; mantenha segredos em .env, segredos Wrangler ou segredos gerenciados pelo Cloudflare.
Para alterações de esquema D1 em api.pkgs.ml, adicione migrações SQL em sites/api.pkgs.ml/migrations/ e atualize src/schema.ts/auxiliares DB juntos.
O acesso D1 em tempo de execução passa por auxiliares Drizzle em api.pkgs.ml/src/db.ts, metadata-db.ts, pipeline-db.ts, access-db.ts ou um arquivo irmão com nome restrito.
Os contratos de chave de objeto R2 ficam em api.pkgs.ml/src/storage.ts; atualize consumidores CDN/API/web e testes juntos ao alterar chaves.
A forma do payload de evento do registro é histórico de serviço voltado ao usuário. Adicione novos tipos de evento em api.pkgs.ml/src/types.ts, serialização DB, visualizações e testes.

Execute bun run check do serviço alterado antes de finalizar.
Execute bun run test quando o serviço definir testes locais.
Não execute bun run deploy, bun run migrate:remote ou test:e2e ao vivo a menos que explicitamente solicitado.
Para api.pkgs.ml, testes locais usam FakeR2Bucket, FakeD1Database, FakeQueue e FakeExecutionContext de tests/helpers.ts.
Para cdn.pkgs.ml, reutilize fakes de teste do registro em vez de inventar mocks do SDK Cloudflare.
Para docs.pkgs.ml, prefira executores de pipeline fake e auxiliares de drenagem de fila; afirme ordenação durável por sequência do banco de dados ao testar fluxos de eventos.
Para serviços Astro, execute bun run check; espere que Astro regenere arquivos de tipo .astro como parte da verificação.

Combine com a stack de UI existente de cada serviço. pkgs.ml usa saída de servidor Astro, ilhas React, Tailwind e adaptador Cloudflare; docs*.ml usam Starlight quando aplicável; riot.ml é um site Astro estático.
Mantenha primeiras telas como superfícies reais de produto/serviço, não placeholders de marketing.
Use componentes, layouts, tokens CSS, fontes e convenções de rota existentes antes de adicionar abstrações.
Para alterações web do registro, prefira APIs de visualização do registro em sites/pkgs.ml/src/lib/web-views.ts e auxiliares de índice esparso em package-index.ts.

Trate endpoints de produção como reais: api.pkgs.ml, registry.pkgs.ml, cdn.pkgs.ml, pkgs.ml, docs.pkgs.ml, docs.riot.ml, play.riot.ml, riot.ml e get.riot.ml.
Nunca execute restore/export/import D1 remoto, gravações DNS, gravações de rota/domínio, deploys ou operações de token sem direção explícita do usuário.
Se um teste de fumaça ao vivo for solicitado, leia o README/env gates desse serviço primeiro e indique quais variáveis de ambiente tornam o teste destrutivo ou autenticado.