scoreko-dev/docs/refactor/ARCHITECTURE_RULES.md

Reglas Arquitectónicas de Implementación

Important

Estas reglas son estrictas y obligatorias. Se deben aplicar sin excepción durante toda la fase de refactorización y en el futuro desarrollo.

1. NO any, NO IGNORES

   • Prohibido el uso de any, @ts-ignore o casteos forzados ciegos (as unknown as Tipo). Todo debe tener tipado fuerte en TypeScript.

2. CERO LÓGICA DE NEGOCIO EN COMPONENTES

   • Los componentes de Vue (.vue) no deben tener llamadas fetch, lógica compleja de parseo, o cálculos pesados.
   • Su sección <script> debe limitarse exclusivamente a invocar composables o stores, y exponer datos al template.

3. COMPONENTES PEQUEÑOS Y "DUMB"

   • Si el template de un componente supera las 100 líneas, es un síntoma de que debe subdividirse.
   • Fomentar la creación de componentes presentacionales ("dumb components") que reciben datos únicamente mediante props y se comunican hacia arriba mediante emits.

4. FUNCIONES PURAS (PURE FUNCTIONS) PRIMERO

   • Cualquier transformación de datos (ej. extraer gamertags, limpiar strings, dar formato a números) debe residir en una función pura y testeable, fuera del ecosistema Vue y de NodeCG.

5. SIN WRAPPERS INÚTILES

   • Evitar crear composables simplemente por envolver una o dos líneas de código si no aportan verdadera semántica o abstracción de dominio.

6. USO DE PATRONES ESTÁNDAR VUE 3

   • Utilizar exclusivamente convenciones estándar de Vue 3: Composition API pura, <script setup> y el ecosistema reactivo estándar de Pinia.
   • Nada de patrones híbridos ni inventados.

7. BORRAR SOBRE CONSERVAR (Limpieza de AI Slop)

   • Si se detecta código redundante o inútil (ej. código "AI slop" o enormes SVGs hardcodeados en HTML para iconos simples), la prioridad es eliminarlo.
   • Sustituir por alternativas limpias y mantenibles (como usar iconos vectoriales de Quasar u hojas de estilo puras).

8. EFECTOS SECUNDARIOS (SIDE EFFECTS) CONTROLADOS

   • El uso de watch debe ser el mínimo indispensable.
   • Siempre que se deba reaccionar a un cambio, preferir flujos de datos unidireccionales (ej. variables calculadas mediante computed) en lugar de mutar un estado local desde un watcher reactivo.

9. REESCRITURA SÍ, PARCHEO NO

   • Las zonas marcadas para reescritura en el plan (ej. Players.vue y graphics/main.vue) deben ser rehechas lógicamente.
   • El objetivo es mantener el output visual o funcional intacto pero desechando la estructura legacy interna. No se aceptan "parches temporales" en estas áreas clave.