feadulta/docs/revision-issues-live-gitea-2026-07-15.md

Segunda pasada — issues correctos en Gitea vivo (gitea.feadulta.com) — 2026-07-15

Alcance

Revisión en modo diagnóstico + preparación sobre la instancia viva:

• Repo: https://gitea.feadulta.com/rafa/feadulta
• Issues revisados: #166, #168, #170, #174, #175
• Sin cambios en producción
• Sin edición de issues

Corrección del desajuste anterior

La pasada previa consultó el Gitea local archivado (localhost:3000), que se queda en #146. La fuente correcta para el trabajo actual es gitea.feadulta.com, tal como ya reflejan:

• la skill feadulta-editorial-workflows
• feadulta/webmaster/references/environment.md

Estado por issue

#166 — Alta de autores / crear-autor

Estado funcional real: resuelto e integrado.

Verificado en el issue vivo:

• Rafa comentó que decidió la opción B (endpoint acotado).
• Rafa comentó después: "Desplegado en prod y verificado en vivo".
• Inma comentó el 14-jul que ya está integrado en Mixbot.

Verificado además en el repo local:

• existe wordpress/wp-content/mu-plugins/fea-crear-autor-api.php
• registra POST /wp-json/fea/v1/crear-autor
• fuerza rol fijo author
• es idempotente si el slug ya existe

Conclusión:

• No hay trabajo técnico pendiente aquí.
• Si queréis limpieza de tablero, este issue ya está para cerrar cuando Rafa quiera.

---

#168 — Bots en Joomla viejo / Cloudflare

Estado funcional real: resuelto lado Cloudflare, aunque el issue sigue abierto.

Verificado en el issue vivo:

• el body ya documenta la parte técnica previa (cache Joomla activada y diagnóstico del fatal)
• Inma añadió comentario 14-jul: "HECHO y verificado" ajustando una regla existente de Cloudflare por el límite de 5 custom rules del plan free

Conclusión:

• Operativamente está resuelto.
• Si no queda ningún fleco de observabilidad, este issue también está para cerrar.

---

#170 — Crawlers sociales / preview Facebook

Estado funcional real: resuelto lado Cloudflare, aunque el issue sigue abierto.

Verificado en el issue vivo:

• Inma comentó 14-jul que ya existía una regla "Permitir Facebook" y que el crawler de Facebook ya pasa con 200

Conclusión:

• Operativamente está resuelto.
• Igual que #168, parece issue de cierre administrativo, no técnico.

---

#174 — Cierre autónomo de la carta (publicar + rotar)

Estado funcional real: abierto, esperando OK de Rafa. Aquí sí hay trabajo útil preparado, pero no conviene aplicar nada aún.

Lo importante que he verificado localmente:

1) Ya existe lógica de rotación en scripts

En el repo local existe:

• scripts/rotate_cartas.php
• scripts/demote_old_cartasemana.php

rotate_cartas.php implementa esta cascada:

1. la que estaba en "semana pasada" → queda solo en "otras semanas"
2. la que estaba en "semana actual" → pasa a "semana pasada"
3. la nueva → pasa a "semana actual"

2) Pero la implementación actual rota todos los idiomas, no solo ES

Esto es importante porque en #174 justo se pregunta si:

• solo se rota ES al cerrar la carta, y
• las traducciones no se rotan hasta que estén publicadas

El script actual no sigue ese criterio: deriva y actúa sobre es/en/fr/it/pt.

3) Dry-run local ejecutado

He ejecutado rotate_cartas.php en el WordPress local Docker en modo dry-run.

Resultado:

• el script funciona como dry-run
• pero el espejo local no está alineado con el caso exacto de la carta 735 en ES (el mirror local va por otro estado / otra numeración viva en esa parte)
• por tanto, sirve para validar la mecánica del script, pero no para afirmar que ya resuelva #174 tal cual

Conclusión técnica:

• #174 no es greenfield: ya hay base.
• Pero hay que adaptar la lógica si la decisión final es "rotar solo ES y dejar derivados/traducciones para después".
• No he preparado parche porque todavía falta el OK funcional de Rafa, y sin eso sería fácil codificar la lógica equivocada.

Recomendación:

• cuando Rafa confirme la regla exacta, el siguiente paso bueno es preparar un wrapper ES-only + dry-run en local, en vez de reaprovechar rotate_cartas.php tal cual.

---

#175 — Endpoint subir-avatar

Estado funcional real: abierto, esperando OK de Rafa. También tiene muy buena base técnica ya hecha.

Lo verificado localmente:

1) El frontend ya usa foto_perfil

En wordpress/wp-content/mu-plugins/fea-homepage.php:

• el avatar del autor usa el meta de usuario foto_perfil
• ese meta guarda un attachment ID

2) Ya existen las piezas de procesamiento

En el repo hay:

• scripts/face_crop_avatar.py
• scripts/regen_avatars.php

O sea: el flujo de recorte / regeneración ya existe; faltaría encapsularlo detrás de un endpoint seguro.

3) El caso concreto mencionado en el issue existe y está sin foto en local

Verificado en el WP local:

• usuario 1112 existe
• login: silvia-mtnz
• display: Silvia Martínez Cano
• foto_perfil está vacío

Conclusión técnica:

• #175 tampoco es greenfield.
• El endpoint encaja bien como hermano de fea/v1/crear-autor (#166).
• La decisión pendiente no es "si se puede", sino qué contrato exacto quiere Rafa:
  • user_id vs slug
  • multipart vs base64
  • si el endpoint recorta o exige imagen ya preparada

Recomendación:

• en cuanto Rafa dé el OK de contrato, el trabajo lógico es clonar el patrón de fea-crear-autor-api.php y dejar un endpoint mínimo, acotado e idempotente.

Resumen ejecutivo

• #166: hecho ✅
• #168: hecho ✅ pero sigue abierto
• #170: hecho ✅ pero sigue abierto
• #174: esperando OK funcional de Rafa; hay base técnica, pero la actual rota todos los idiomas
• #175: esperando OK funcional de Rafa; hay base técnica muy clara y el caso Silvia está identificado

Qué hice en esta pasada

• Reapunté la revisión a gitea.feadulta.com
• Leí los issues correctos por API pública
• Verifiqué localmente la existencia del endpoint crear-autor
• Ejecuté un dry-run de la lógica de rotación existente
• Verifiqué en local el caso Silvia Martínez Cano / 1112 / foto_perfil vacío

Qué NO hice

• No toqué producción
• No cerré issues
• No comenté en Gitea
• No modifiqué código del repo