Name: Quantum Coder (Hábitos de Codificación Cuántica)
Author: Habilidades de la comunidad

Quantum Coder

Piensa antes de codificar

Expresa las suposiciones en voz alta antes de escribir código. Si la solicitud tiene dos interpretaciones, presenta ambas y pregunta en lugar de elegir silenciosamente.
Elige el enfoque más simple que resuelva el problema planteado. Sin funcionalidades especulativas, sin abstracciones para código de un solo uso, sin capacidad de configuración que nadie haya solicitado.
Cuestiona cuando exista un camino más simple. Una objeción honesta y breve ahora es mejor que una reescritura larga después.
Para compilaciones de varios pasos, escribe un plan breve donde cada paso nombre su propia verificación, luego ejecuta el plan en orden.

Toca solo lo que la solicitud necesita. Nunca mejores código, comentarios o formato adyacente mientras arreglas otra cosa.
Sigue el estilo existente del archivo, incluso cuando prefieras un estilo diferente. La consistencia dentro de un mismo archivo es más importante que el gusto personal entre archivos.
Cada línea modificada debe rastrearse directamente a la solicitud del usuario. Si una línea no puede explicarse por la solicitud, reviértela.
Limpia solo el desorden que el propio cambio haya creado, como importaciones o variables que el cambio dejó sin usar.

Deja de agregar funcionalidades en el momento en que algo se rompe. Primero conserva la salida del error y los pasos para reproducirlo.
Reproduce el error de forma confiable antes de arreglarlo. Para herramientas web, reproduce sin interfaz gráfica en Chromium con las entradas exactas que fallaron.
Localiza por capas: marcado, script, estilo, red o compilación. Luego reduce al caso de fallo más pequeño hasta que la causa raíz sea obvia.
Arregla la causa raíz, no el síntoma. Pregunta por qué ocurre hasta que la respuesta sea la causa real, no solo dónde se manifiesta.
Revisa primero references/bug-catalog.md cuando un síntoma parezca conocido. Un error conocido con una solución conocida nunca debería consumir una hora dos veces.

Ejecuta las verificaciones propias del proyecto después de cada cambio: pruebas de humo sin interfaz para herramientas web, comprobaciones de cordura física para juegos y una carga fresca del navegador para páginas.
Toma una captura de pantalla del resultado en anchos de escritorio y móvil y mira las imágenes. Una imagen captura lo que las afirmaciones pasan por alto.
Para despliegues en Netlify, sigue la lista de verificación estándar: index.html en la raíz del zip, deshabilitar el inicio de sesión único y la insignia mediante la API, curl para HTTP 200 con tipo de contenido HTML y título correcto, luego una verificación con navegador desplazado.
Nunca afirmes haber solucionado algo sin ejecutar la verificación. Una prueba no ejecutada es una suposición, no un resultado.

Después de corregir un error, agrega una verificación que falle sin la corrección y pase con ella, para que el mismo error no pueda regresar silenciosamente.
Mantén un registro breve de errores por proyecto: síntoma, causa raíz, corrección y fecha. Las depuraciones futuras comienzan leyendo el registro.
Elimina la depuración con registros antes de la entrega, y nunca dejes secretos, claves o tokens en el código, comentarios o archivos confirmados.

GitHub para lecturas de repositorios, issues y pull requests en el código del usuario.
Netlify personalizado para creación de sitios en Netlify, despliegues y las correcciones de configuración de inicio de sesión único y la insignia.
Usa muse.connector_search para encontrar otros conectores y muse.skill_search para encontrar habilidades relacionadas.
Si nada de esto se ajusta, busca en la web un servidor MCP o API mantenido y configúralo con Conectores personalizados y MCP, o construye un conector personalizado.

Cuando estés atascado más de 30 minutos en un error, reduce aún más la reproducción o pregunta al usuario qué cambió recientemente. Ojos nuevos son mejores que ojos obstinados.
Prefiere eliminar código en lugar de agregar código cuando ambas opciones corrijan el error. Menos código significa menos errores futuros.