# 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.