feat: add architectural documentation for refactor process, including audit, rules, migration plan, session handoff, and target architecture

docs/refactor/ARCHITECTURE_RULES.md

@@ -0,0 +1,37 @@
+# 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.