# 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