¿Con qué fallos de configuración local se topan en la práctica quienes se incorporan y los agentes de codificación, y qué correcciones han eliminado definitivamente alguna clase de fallo?

Pregunta abierta

Todo repositorio tiene una ruta de configuración, y toda ruta de configuración falla para alguien. Las causas candidatas son bien conocidas: versiones de toolchain que difieren del manifiesto, dependencias nativas que necesitan un compilador o una biblioteca del sistema, diferencias entre macOS, Linux y Windows, credenciales y acceso de red que la documentación da por supuestos, servicios (base de datos, broker de mensajes) que no están en ejecución o que escuchan en otro puerto, y estado obsoleto de un intento anterior. Los contenedores de desarrollo, descritos en containers.dev como una especificación abierta para enriquecer contenedores con contenido y ajustes específicos de desarrollo, prometen eliminar varias de estas clases a la vez al fijar el sistema operativo y el toolchain; los scripts de configuración con autocomprobaciones prometen convertir el resto en mensajes precisos. Lo que le falta a la wiki es un registro de qué fallos ocurren en la práctica, en qué proporción, y si una corrección determinada eliminó una clase de fallo o simplemente la desplazó, por ejemplo de «versión de Python incorrecta» a «Docker no está en ejecución» o «el bind mount es demasiado lento». ¿Difiere la distribución entre quienes se incorporan como personas y los agentes de codificación, que no pueden avanzar haciendo clic en un instalador, mirar la pantalla de un compañero o esperar un aviso de VPN? ¿Los repositorios con un contenedor de desarrollo registran menos incidencias de configuración en su rastreador, o distintas? ¿Y con qué frecuencia simplemente no se sigue la ruta documentada, ya sea por personas o por agentes, de modo que el fallo no es culpa de la ruta?

Qué contiene una respuesta útil

El stack del repositorio, las plataformas admitidas y el mecanismo de configuración (pasos del README, script de arranque, contenedor de desarrollo, espacio de trabajo alojado). Un recuento de los intentos de configuración en un período y cómo se registraron los fallos (etiqueta de issue, canal de chat, subidas de log del script de configuración, transcripciones de agentes). Una clasificación de los fallos por causa, con las reglas de clasificación indicadas, y, para los agentes, si el fallo fue un problema real de entorno o el agente ignorando la ruta documentada. Para cada corrección introducida (manifiesto de versiones, contenedor de desarrollo, script de diagnóstico, imagen preconstruida), los recuentos de fallos antes y después, y cuánto tiempo se observó cada lado. Las distribuciones de duración de la configuración, si se midieron, con el método empleado. Los informes en los que una corrección introdujo una nueva clase de fallo son tan útiles como los informes en los que eliminó una; el relato de un único repositorio es bienvenido si se etiqueta como tal, y las comparaciones entre repositorios con el mismo stack son más útiles.