Atualizar a especificação da stack
Fatos (versões, datas, medições, fontes) você atualiza. Decisões você propõe ao autor e aguarda. Argumentos, se fornecidos, nomeiam as ferramentas a verificar; caso contrário, verifique todas.
1. Inventário
Do stack-spec.md, liste:
- cada linha da §2 com sua linha de versão;
- toda versão, data de lançamento ou alegação de estabilidade na §3 e §4 ("estável", "candidato a lançamento", "alfa", "experimental", um número de versão ao lado de uma ferramenta);
- cada linha de Revisit when, como uma condição a testar;
- a data de versão do cabeçalho.
2. Verificar cada uma em fontes primárias
Registro, notas de lançamento, documentação oficial. Nunca de memória.
- npm:
npm view <pkg> dist-tags time --json. Atual = lançamento mais novo com pelo menos 14 dias; liste lançamentos mais jovens como futuros. - Ferramentas nixpkgs (Node.js, Biome, nixfmt, Wrangler, Playwright browsers):
nix eval --raw nixpkgs#<pkg>.versionnonixos-unstable, mais a página de lançamento do projeto. - Recursos de plataforma (Cloudflare, suporte a navegadores): a página da documentação oficial e sua data.
Registre por ferramenta: linha de versão da especificação, versão atual e se um lançamento principal (ou um lançamento que a especificação aguarda) está entre elas.
3. Classificar cada mudança
Leia o changelog ou guia de migração de cada nova versão principal por completo, e a documentação na qual a especificação se baseia. Em seguida, classifique:
- Fato (linha de versão, data, contagem de pacotes): atualize-o.
- Razão (uma desvantagem declarada corrigida, uma nova introduzida): atualize o texto da razão; liste-a no relatório.
- Decisão (a própria escolha, uma alternativa agora melhor, um gatilho Revisit when disparado): não edite. Relate: o que mudou, fonte, opções com custos, recomendação. Aguarde.
4. Editar
- Mantenha o estilo da especificação: conciso, regra primeiro, razão depois, datas ISO; marque texto de decisão alterado como "Alterado : …".
- Novo fato → nova fonte no final da lista numerada, com "verificado ". Nunca renumerer as fontes; exclua uma apenas quando nada a citar.
- Nunca renumerer seções. Um novo tópico torna-se a próxima subseção de sua seção; pergunte ao autor se um site já usa aquele número e relate o número escolhido.
- Atualize a data de versão do cabeçalho.
- Não nomeie nenhum site, usuário ou repositório que use a especificação.
5. Verificar e confirmar
- Toda URL nova ou alterada resolve:
curl -sIL <url>. - Nenhum site, usuário ou repositório que use a especificação é nomeado.
- Jujutsu, assinado, um commit por tema (ex.: "Registrar Astro 8", "Propor TypeScript 7"), a mensagem informando o que mudou, por que e as fontes verificadas. Não envie (push) a menos que solicitado.
6. Relatório
Por ferramenta: versão da especificação → atual. Em seguida: fatos atualizados, razões alteradas, decisões propostas com recomendações, lançamentos futuros com menos de 14 dias.