Repaso de la carpeta sql/ heredada. De sus 8 ficheros:
- forum_schema.sql y forum_views.sql: SE BORRAN. Son del foro anterior, que
af707ad reemplazó por el port de FusionCMS (web-next/sql/forum_fusion.sql).
El primero crea `forums`, tabla que ya no existe (el código usa forum_forums);
el segundo añade un contador `views` que ni existe en prod ni usa el código.
Quedan en el historial por si hicieran falta.
- achievement_points.sql, battlepay_sumup.sql, seed_news.sql y
seed_recruit_rewards.sql: siguen siendo válidos y se mueven a web-next/sql/,
que es la carpeta viva. El primero pasa a achievement_points_world.sql para no
chocar con la copia de django_wow que usa la armería; cada uno avisa del otro.
- rename_home_prefix.sql y drop_home_securitytoken_authuser_fk.sql: se quedan en
sql/ como registro de migraciones ya aplicadas.
Se añade battlepay_purchases.sql: la tabla la escribe el core y no estaba en
ningún SQL, así que no había forma de recrearla. Sus 61 filas son de pruebas
locales (2 cuentas, 127.0.0.1), sin datos de jugadores.
Verificado importando todo en BD limpias: seed_news deja 50 noticias,
seed_recruit_rewards 6, battlepay_sumup crea sus 2 tablas y
battlepay_purchases reproduce prod fila a fila con el mismo esquema.
El prefijo venía del nombre de la app Django (`home`), jubilada y borrada hoy,
así que ya no significaba nada: home_stripelog -> stripelog. La BD se sigue
llamando django_wow por historia (renombrarla es otra operación).
Comprobado antes de tocar nada: 0 colisiones con nombres existentes, 0 palabras
reservadas (contrastado contra las 260 de MySQL), sin vistas ni triggers que
dependieran de ellas. El RENAME va en una sola sentencia porque así es atómico,
y MySQL reapunta solo las 4 claves ajenas entre estas tablas.
170 referencias actualizadas en 37 ficheros. Se dejó a propósito
sql/drop_home_securitytoken_authuser_fk.sql sin tocar: es una migración ya
aplicada y reescribirla sería falsear el historial.
De paso salió un fallo previo: prices.ts consultaba `home_restoreitemprice`,
una tabla que NO existe. El try/catch de priceFrom se comía el error y devolvía
siempre el precio por defecto, así que el precio de restaurar objetos nunca fue
configurable. Se deja documentado en el código; crear la tabla es otra decisión.
Verificado tras aplicar: 0 tablas home_, las 51 siguen ahí, y el conteo exacto
de filas cuadra con el volcado previo (store_item 3068, item_data 44873,
stripelog 35, store_order 26, noticia 50). La web responde 200 en todas las
rutas y la portada carga las noticias sin errores.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Reescrita la página: box «Información» con la guía completa de Recluta a un
amigo (marca → nombre del reino) + box «Panel de Recluta a un amigo».
- Nuevo RecruitPanel: estadísticas (cuenta reclutada, amigos reclutados, amigos
al nivel 80, recompensas reclamadas X/6) + tabla de recompensas (objetivo,
objeto con icono y color de calidad, estado) con botón Reclamar para las
disponibles + sección «Recompensas disponibles». Sustituye a RecruitClaim.
- lib/recruit-claim: getRecruitStats (isRecruited + recruitedCount).
- Colores de calidad de objeto .q0-.q5 en globals.css.
- Sembradas las 6 recompensas en home_recruitreward (seed en sql/).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Inna