Sync: guardar en el historial el trabajo de las ultimas semanas que solo vivia en el disco

Este repo local tenia origin apuntando al Gitea local (localhost:3000), que Rafa
declaro archivado el 2026-06-28 (commit 962f33a, desarrollo movido a
gitea.feadulta.com). Ese memo nunca llego a este checkout: main quedo congelado
y todo el trabajo real de las ultimas 3+ semanas se fue commiteando solo en la
rama fix/multiidioma-portada-132 (ya fusionada a main sin perdida, commit
2504666), mientras que ademas se acumulaban 78 cambios sin commitear en el
working tree que nunca llegaron a NINGUN historial de git.

Este commit consolida esos cambios sueltos: TTS multi-voz (tts_*.py), scripts
de traduccion (translate_haiku.py, pretranslate_en_haiku.py, sync_translations_to_prod.py),
mu-plugins nuevos desplegados a prod (fea-beta-feedback, fea-cloudflare-realip,
fea-legacy-redirect, fea-gsc-verification, fea-support-campaign, fea-ui, etc.),
scripts de mantenimiento de enlaces/cartas, capturas E2E (tools/e2e/shot_*.cjs)
y documentacion de sesiones recientes.

Excluido deliberadamente (no es codigo versionable): tts-voices/ (3.3GB de
muestras de audio para clonacion de voz, anadido a .gitignore), logs/ (logs de
ejecucion, anadido a .gitignore), y 2 ficheros vacios accidentales + 2 copias
duplicadas sueltas en la raiz que ya existen en su ubicacion correcta.

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

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