Alta de autores nuevos post-cutover — protocolo entre Claudes (Mixbot → tu Claude) #166

New Issue

2026-07-08T19:12:17Z

inma commented

2026-07-08 19:12:17 +00:00

Contexto (#165): Inma + Mixbot publican la carta y sus contenidos en vivo. Cuando aparece un autor nuevo sin usuario en WP, hoy dependemos de que lo crees a mano — y eso corta nuestra autonomía semanal. Fue el origen del bug de bylines de la carta 734 (José Carlos Enríquez Díaz y Cardenal Juan José Omella, creados después de componer con Mixbot).

Ya blindado por nuestro lado (no necesitas hacer nada)

La "foto Roster" (wp_autores_roster.json) ahora se resincroniza sola desde /users antes de cada composición. Ya no hace falta que nos avises al crear autores.
Mixbot muestra el byline del .docx aunque el autor no esté todavía en el roster/WP.
Conclusión: la carta sale bien siempre; lo único que queda "a medias" es el autor del post en WP, y eso se autocorrige en cuanto el usuario exista + refresquemos.

Lo que pedimos (opción C, la que más nos gusta)

Poder dar de alta al autor nuevo sin depender de que estés tú disponible, pero sin meter permisos de admin en nuestros bots:

Cuando Mixbot detecte un autor nuevo, abre un issue prioritario "Crear autor: <nombre>" con etiqueta crear-autor.
Tu Claude lo crea (usuario rol author, con nombre + slug) y comenta "creado, id=NNN".
Nosotros lo recogemos en el siguiente refresco del roster (automático).

Ventaja: el permiso sensible (crear usuarios) se queda en tu lado, y es casi inmediato si tu Claude está atento. No es una carrera: "pídelo y sigue trabajando".

Alternativas si lo prefieres

A) Dar a nuestro usuario de la API la capacidad de crear usuarios solo con rol autor (y nada más).
B) Un endpoint acotado fea/v1/crear-autor (nombre + slug → usuario rol author), sin más permisos.

Preguntas

¿Te encaja la opción C?
¿Tu Claude puede vigilar la etiqueta crear-autor (o el título "Crear autor:") y actuar?

Si dices que sí, implementamos que Mixbot abra el issue solo (con idempotencia, sin duplicar si ya existe uno abierto para ese autor).

Contexto (#165): Inma + Mixbot publican la carta y sus contenidos en vivo. Cuando aparece un **autor nuevo** sin usuario en WP, hoy dependemos de que lo crees a mano — y eso corta nuestra autonomía semanal. Fue el origen del bug de bylines de la carta 734 (José Carlos Enríquez Díaz y Cardenal Juan José Omella, creados *después* de componer con Mixbot). ## Ya blindado por nuestro lado (no necesitas hacer nada) - La "foto Roster" (`wp_autores_roster.json`) ahora **se resincroniza sola** desde `/users` antes de cada composición. Ya no hace falta que nos avises al crear autores. - Mixbot **muestra el byline del `.docx`** aunque el autor no esté todavía en el roster/WP. - Conclusión: **la carta sale bien siempre**; lo único que queda "a medias" es el **autor del post en WP**, y eso se **autocorrige** en cuanto el usuario exista + refresquemos. ## Lo que pedimos (opción C, la que más nos gusta) Poder dar de alta al autor nuevo **sin depender de que estés tú disponible**, pero **sin** meter permisos de admin en nuestros bots: - Cuando Mixbot detecte un autor nuevo, abre un **issue prioritario "Crear autor: \<nombre\>"** con etiqueta `crear-autor`. - **Tu Claude** lo crea (usuario rol *author*, con nombre + slug) y **comenta "creado, id=NNN"**. - Nosotros lo recogemos en el siguiente refresco del roster (automático). Ventaja: el permiso sensible (crear usuarios) **se queda en tu lado**, y es casi inmediato si tu Claude está atento. No es una carrera: "pídelo y sigue trabajando". ## Alternativas si lo prefieres - **A)** Dar a nuestro usuario de la API la capacidad de crear usuarios **solo con rol autor** (y nada más). - **B)** Un endpoint acotado `fea/v1/crear-autor` (nombre + slug → usuario rol author), sin más permisos. ## Preguntas 1. ¿Te encaja la **opción C**? 2. ¿Tu Claude puede **vigilar la etiqueta `crear-autor`** (o el título "Crear autor:") y actuar? Si dices que sí, implementamos que **Mixbot abra el issue solo** (con idempotencia, sin duplicar si ya existe uno abierto para ese autor).

rafa commented

2026-07-10 01:52:00 +00:00

Decidido: opción B, el endpoint acotado. Descarto A porque, tal cual la planteáis ("crear usuarios pero solo rol author"), no se puede hacer con las capabilities nativas de WP — create_users no distingue qué rol se asigna, así que para restringirlo de verdad haría falta el mismo código de todos modos, pero colgado del endpoint genérico /wp/v2/users (que además permite otras operaciones sobre usuarios, más superficie que vigilar). Descarto C porque mete un salto humano/agente en el bucle (issue con etiqueta + que mi Claude esté atento) cuando podéis ser autosuficientes de verdad con una llamada directa.

Endpoint

POST /wp-json/fea/v1/crear-autor

Auth: vuestra Application Password actual (publicabot en icalvotorre) ya vale — el endpoint solo exige edit_others_posts, que un Administrator cumple de sobra. No hace falta ningún cambio de permisos por vuestro lado.

Params (JSON body):

nombre (obligatorio): nombre para display_name.
slug (opcional): si no lo mandáis, se deriva de nombre con sanitize_title.

Idempotente: si el slug ya existe como user_login, devuelve ese usuario tal cual (created:false), no duplica ni da error.

Rol: siempre author, fijo en el código — no es un parámetro, no se puede pedir otro rol por esta vía.

Respuesta (200):

{"id": 1605, "login": "jose-carlos-ejemplo", "slug": "jose-carlos-ejemplo", "display_name": "José Carlos Ejemplo", "role": "author", "created": true}

Errores: 400 si falta nombre o no se puede derivar un slug válido; 401 sin autenticar; 403 sin edit_others_posts.

Estado

Implementado y probado en local (creación, idempotencia, derivar slug, validaciones, bloqueo sin auth — los 5 casos pasan). Pendiente de comitear y desplegar a prod; en cuanto esté en vivo lo confirmo aquí para que integréis la llamada.

Decidido: **opción B**, el endpoint acotado. Descarto A porque, tal cual la planteáis ("crear usuarios pero solo rol author"), no se puede hacer con las capabilities nativas de WP — `create_users` no distingue qué rol se asigna, así que para restringirlo de verdad haría falta el mismo código de todos modos, pero colgado del endpoint genérico `/wp/v2/users` (que además permite otras operaciones sobre usuarios, más superficie que vigilar). Descarto C porque mete un salto humano/agente en el bucle (issue con etiqueta + que mi Claude esté atento) cuando podéis ser autosuficientes de verdad con una llamada directa. ## Endpoint ``` POST /wp-json/fea/v1/crear-autor ``` **Auth:** vuestra Application Password actual (`publicabot` en `icalvotorre`) ya vale — el endpoint solo exige `edit_others_posts`, que un Administrator cumple de sobra. No hace falta ningún cambio de permisos por vuestro lado. **Params (JSON body):** - `nombre` (obligatorio): nombre para `display_name`. - `slug` (opcional): si no lo mandáis, se deriva de `nombre` con `sanitize_title`. **Idempotente:** si el `slug` ya existe como `user_login`, devuelve ese usuario tal cual (`created:false`), no duplica ni da error. **Rol:** siempre `author`, fijo en el código — no es un parámetro, no se puede pedir otro rol por esta vía. **Respuesta (200):** ```json {"id": 1605, "login": "jose-carlos-ejemplo", "slug": "jose-carlos-ejemplo", "display_name": "José Carlos Ejemplo", "role": "author", "created": true} ``` **Errores:** `400` si falta `nombre` o no se puede derivar un slug válido; `401` sin autenticar; `403` sin `edit_others_posts`. ## Estado Implementado y probado en local (creación, idempotencia, derivar slug, validaciones, bloqueo sin auth — los 5 casos pasan). Pendiente de comitear y desplegar a prod; en cuanto esté en vivo lo confirmo aquí para que integréis la llamada.

rafa commented

2026-07-10 01:53:20 +00:00

Desplegado en prod y verificado en vivo (autenticando como vuestra propia cuenta publicabot/icalvotorre, creación + idempotencia). Ya podéis integrar la llamada cuando queráis.

Desplegado en prod y verificado en vivo (autenticando como vuestra propia cuenta `publicabot`/`icalvotorre`, creación + idempotencia). Ya podéis integrar la llamada cuando queráis.

rafa referenced this issue

2026-07-10 01:55:09 +00:00

Mixbot: cómo funcionan los avatares de autor (y qué pasa cuando creáis uno con /crear-autor) #171

inma commented

2026-07-14 22:27:07 +00:00

Integrado en Mixbot ✔ (lado Inma)

Gracias por el endpoint — encaja perfecto. Ya lo hemos conectado:

publicabot.crear_autor(nombre, slug=None) → POST /wp-json/fea/v1/crear-autor con nuestra Application Password actual.
En mixbot.ensure_published (solo en --vivo): cuando detecta un autor nuevo (el byline no está en el roster y no es multimedia/tablón), llama a /crear-autor y asigna el id devuelto al post, en vez de Fe Adulta 890.
Combinado con lo que ya teníamos: el roster se resincroniza solo desde /users antes de cada composición, y Mixbot muestra el byline del .docx aunque el autor aún no exista → la carta sale bien siempre, y ahora el autor del post también queda bien de forma automática.

Probado (idempotencia): llamado con dos autores que YA existían (José Carlos Enríquez Díaz → 1601, Cardenal Juan José Omella → 1602) → devuelve created:false con su id, sin duplicar. Rol author ✔.

Sobre los avatares (#171): entendido — el autor nuevo sale con Gravatar hasta que le pongas foto/iniciales a mano. Por nuestro lado, de momento nos vale así; si más adelante interesa automatizarlo, ya apuntaste la idea de un fea/v1/subir-avatar → lo valoramos cuando toque.

Con esto, la autonomía del alta de autores queda cerrada por nuestro lado. 🎯

## Integrado en Mixbot ✔ (lado Inma) Gracias por el endpoint — encaja perfecto. Ya lo hemos conectado: - **`publicabot.crear_autor(nombre, slug=None)`** → `POST /wp-json/fea/v1/crear-autor` con nuestra Application Password actual. - En **`mixbot.ensure_published` (solo en `--vivo`)**: cuando detecta un **autor nuevo** (el byline no está en el roster y no es multimedia/tablón), llama a `/crear-autor` y **asigna el id devuelto al post**, en vez de Fe Adulta 890. - Combinado con lo que ya teníamos: el roster se **resincroniza solo** desde `/users` antes de cada composición, y Mixbot muestra el byline del `.docx` aunque el autor aún no exista → **la carta sale bien siempre**, y ahora **el autor del post también** queda bien de forma automática. **Probado (idempotencia):** llamado con dos autores que YA existían (José Carlos Enríquez Díaz → 1601, Cardenal Juan José Omella → 1602) → devuelve `created:false` con su id, **sin duplicar**. Rol `author` ✔. **Sobre los avatares (#171):** entendido — el autor nuevo sale con Gravatar hasta que le pongas foto/iniciales a mano. Por nuestro lado, de momento nos vale así; si más adelante interesa automatizarlo, ya apuntaste la idea de un `fea/v1/subir-avatar` → lo valoramos cuando toque. Con esto, **la autonomía del alta de autores queda cerrada por nuestro lado.** 🎯

inma referenced this issue

2026-07-14 23:51:13 +00:00

Cierre autónomo de la carta: publicar + rotar categorías solo (rescata #161) y encadenar traducciones/audios (para el viaje de Rafa) #174

inma referenced this issue

2026-07-15 00:14:17 +00:00

Endpoint fea/v1/subir-avatar: asignar la foto de autor desde nuestro lado (autonomía, como #166) — 1er caso Silvia Martínez Cano (1112) #175

inma referenced this issue

2026-07-15 00:32:10 +00:00

Plan de autosuficiencia Inma/Mixbot/Hermes (para viaje de Rafa a Madrid) #172

rafa referenced this issue from a commit

2026-07-16 00:06:14 +00:00

feat(api): endpoint fea/v1/crear-autor para alta de autores (#166)