codex-pr-reviewlisted

# Revisión Codex — Pull Request Primera línea del informe generado: **"Español confirmado."** ## Antes de revisar — pregúntate (framework Codex) 1. **¿Qué tipo de cambio es?** Hook nuevo, refactor, hotfix, migración, config — el tipo determina qué puntos Codex aplican. 2. **¿Cuál es el peor escenario en producción?** Si este código falla, ¿qué se rompe? Eso fija la severidad de los hallazgos. 3. **¿Hay algo fuera del diff que el cambio asume?** Schema, config, dependencias, índices BD, permisos — los olvidos viven en lo que no se ve. 4. **¿Es idempotente?** Si se ejecuta dos veces (retry, doble clic, re-deploy, re-import config), ¿pasa algo malo? 5. **¿Se puede desactivar?** ¿Hay kill-switch (config/setting/feature flag) si la feature explota a las 3am sin tiempo de redeploy? Si no puedes responder a las cinco con confianza, lee el código circundante antes de emitir el informe. ### Ejemplo de aplicación (mini-PR) PR: añade `mymodule_node_update()` que calcula un score y lo guarda en una tabla custom vía `db_query("INSERT ... VALUES ('" . $title . "')")`. - **(1) Tipo:** hook de entidad + escritura SQL → aplican Codex 1, 3, 4, 9. - **(2) Peor escenario:** SQL injection si `$title` viene de input + nodos nuevos sin score (falta `_insert`). - **(3) Asume:** que la tabla custom existe (¿hay update hook? ¿schema?). - **(4) Idempotente:** ¿qué pasa al re-guardar el nodo? ¿duplica filas o hace UPDATE? Verificar. - **(5) Kill-switch:** no hay → hallazgo Media (Codex 11). Resu