Quais falhas de configuração local atingem de fato novatos e agentes de código, e quais correções eliminaram de vez uma classe de falha?

Pergunta em aberto

Todo repositório tem um caminho de configuração, e todo caminho de configuração falha para alguém. As causas candidatas são bem conhecidas: versões de toolchain diferentes das do manifesto, dependências nativas que exigem um compilador ou uma biblioteca do sistema, diferenças entre macOS, Linux e Windows, credenciais e acesso à rede que a documentação pressupõe, serviços (banco de dados, message broker) que não estão em execução ou escutam em outra porta, e estado residual de uma tentativa anterior. Os dev containers, descritos em containers.dev como uma especificação aberta para enriquecer contêineres com conteúdo e configurações específicos de desenvolvimento, prometem eliminar várias dessas classes de uma só vez, fixando o sistema operacional e a toolchain; scripts de setup com autoverificação prometem converter o restante em mensagens precisas. O que falta à wiki é um registro de quais falhas realmente ocorrem, em que proporção, e se uma determinada correção removeu uma classe ou apenas a deslocou, por exemplo de "versão errada do Python" para "Docker não está em execução" ou "bind mount lento demais". A distribuição difere entre novatos humanos e agentes de código, que não conseguem clicar em um instalador, olhar a tela de um colega nem esperar por um prompt de VPN? Repositórios com dev container têm menos problemas de setup no tracker, ou problemas diferentes? E com que frequência o caminho documentado simplesmente não é seguido, por pessoas ou por agentes, de modo que a falha não é culpa do caminho?

O que uma resposta útil contém

A stack do repositório, as plataformas suportadas e o mecanismo de setup (passos do README, script de bootstrap, dev container, workspace hospedado). Uma contagem das tentativas de setup em um período e a forma como as falhas foram registradas (label de issue, canal de chat, upload de logs pelo script de setup, transcrições de agentes). Uma classificação das falhas por causa, com as regras de classificação declaradas e, no caso de agentes, a indicação de se a falha foi um problema real de ambiente ou o agente ignorando o caminho documentado. Para cada correção introduzida (manifesto de versões, dev container, script doctor, imagem pré-construída), as contagens de falhas antes e depois e por quanto tempo cada período foi observado. Distribuições da duração do setup, se medidas, com o método. Relatos em que uma correção introduziu uma nova classe de falha são tão úteis quanto aqueles em que removeu uma; o relato de um único repositório é bem-vindo se for identificado como tal, e comparações entre repositórios com a mesma stack são mais úteis.