amagnatema/ship-cloudflare-sites

Ship Cloudflare Sites v1.1

Opere a partir de evidências do repositório e do escopo solicitado pelo usuário. Uma solicitação para implantar autoriza o fluxo de trabalho de implantação comum para o ambiente nomeado; pergunte apenas quando uma mudança adicional destrutiva, irreversível ou materialmente mais ampla se tornar necessária. Nunca infira um alvo de produção a partir de um ambiente não especificado.

Descobrir o projeto

1. Leia as instruções do repositório e inspecione a árvore de trabalho atual antes de editar.
2. Execute scripts/audit-cloudflare-project.sh <project-root> e inspecione cada bloqueador relatado.
3. Resolva o framework, gerenciador de pacotes, adaptador, entrada do Worker, configuração do Wrangler, ambientes, bindings, migrações, domínios, caminho de CI e nomes de segredos a partir de arquivos — não da memória.
4. Use a CLI fixada no repositório. Verifique o comportamento mutável do Cloudflare/OpenNext localmente com --help e na documentação oficial atual antes de alterações remotas.
5. Leia apenas as referências relevantes:
   • Leia references/release-workflow.md para lançamento, rollback ou iteração de versão.
   • Leia references/cloudflare-resources.md para provisionamento ou alteração de D1, R2, segredos, domínios, cache, ambientes ou observabilidade.

Escolher o modo de operação

• Auditar/planejar: permaneça somente leitura. Retorne evidências, bloqueadores, riscos e as próximas ações exatas.
• Desenvolver/configurar: edite e verifique localmente. Crie recursos remotos apenas quando o usuário solicitou provisionamento ou a implantação os exige.
• Provisionar: confirme conta, zona, ambiente, nomes e propriedade pretendida; crie apenas recursos ausentes e persista os IDs retornados na configuração escolhida.
• Lançar: compile uma vez, depois implante esse artefato verificado. Use implantação direta para lançamentos de baixo risco quando solicitado; use upload de versão mais promoção controlada para lançamentos arriscados ou explicitamente graduais.
• Recuperar: selecione uma versão do Worker conhecidamente boa, depois trate separadamente o estado do D1 e do R2. As versões do Worker não contêm estado de armazenamento.

Aplicar salvaguardas invariantes

• Diferencie recursos locais, de preview/staging e de produção. Torne explícito o alvo de cada comando remoto.
• Mantenha valores de segredos fora da fonte, saída, capturas de tela e argumentos do shell. Relate apenas nomes e presença.
• Revise uma árvore de trabalho suja antes do lançamento. Não descarte, comite ou envie alterações de usuário não relacionadas.
• Modele alterações do D1 como migrações ordenadas e prefira expandir/preencher/contrair entre lançamentos.
• Use chaves R2 imutáveis ou versionadas para ativos com cache longo. Trate sobrescrita, exclusão, alteração de CORS e purge de cache como uma alteração coordenada.
• Trate domínios personalizados do Worker e domínios personalizados do R2 como recursos separados. Verifique apex, www, redirecionamentos canônicos, certificados e hostname de ativos independentemente.
• Não chame um upload de lançamento bem-sucedido. Verifique o hostname público, as rotas críticas, o comportamento apoiado por D1, um objeto R2 representativo e os logs pós-implantação.

Produzir um registro de lançamento

Retorne:

• ID do lançamento, commit do Git, ambiente, nomes dos recursos Worker e armazenamento;
• alterações na fonte/confirmação enviadas e alterações excluídas na árvore de trabalho;
• portões locais e seus resultados;
• migrações D1 mais bookmark/exportação de recuperação e ordem de compatibilidade;
• alterações R2/domínio/cache/segredo sem valores de segredos;
• versão do Worker/ID da implantação e percentual de tráfego quando disponível;
• URLs de smoke test e resultados;
• alvo de rollback, ressalvas de armazenamento e ações manuais restantes.

Se um portão falhar, pare antes do limite inseguro, preserve as evidências e declare o que resta. Não enfraqueça um portão silenciosamente.