Seguridad y confirmaciones

El flujo seguro es: leer, proponer, previsualizar, confirmar y escribir.

Kodavio esta disenado para que Codex pueda trabajar con autonomia, pero con barandillas claras. El objetivo es reducir errores humanos repetitivos sin perder aprobacion en las decisiones que pueden romper una pagina, borrar datos o cambiar el comportamiento del sitio.

Modos principales

Modo	Significado	Cuando usarlo
`dry_run=true`	Previsualiza sin guardar cambios.	Siempre al empezar una tarea nueva o delicada.
`confirm_create=true`	Autoriza crear una pagina, template o componente.	Cuando quieres un borrador real.
`confirm_write=true`	Autoriza escribir contenido o patrones.	Cuando el objetivo exacto esta claro.
`confirm_destructive=true`	Autoriza una accion destructiva.	Solo despues de backup y aprobacion explicita.

Niveles de riesgo

Riesgo	Que permite	Ejemplos
`read`	Leer estado o diagnosticos.	Listar plugins, leer pagina, ver tokens, health check.
`managed_write`	Crear o modificar con contrato controlado.	Crear pagina draft, actualizar patron, activar plugin.
`elevated_write`	Cambios operativos sensibles.	Instalar plugins, actualizar plugins, escribir `mu-plugins` o editar PHP en plugins/themes.
`destructive`	Borrar, limpiar o sustituir datos.	Borrar plugin, limpiar metadata de builder, rollback destructivo.

Las habilidades elevadas y destructivas deben activarse solo cuando realmente las necesites. El hecho de que Codex pueda pedirlas no significa que deban estar siempre disponibles.

Permisos sensibles

Kodavio separa los permisos de mayor riesgo para que no tengas que abrir todo el panel administrativo a la vez:

Permiso	Para que sirve	Recomendacion
Editar PHP avanzado	Crear, parchear o restaurar archivos PHP permitidos en plugins/themes o sandbox.	Activarlo solo durante la tarea concreta.
Editar `mu-plugins`	Crear o modificar archivos que cargan siempre en WordPress.	Usarlo con backup y revision del resultado.
Instalar y actualizar plugins	Cambiar el stack del sitio.	Probar antes en staging si afecta al frontend.
Borrados y restauraciones	Eliminar, desinstalar, limpiar o revertir.	Requiere confirmacion explicita y plan de rollback.

Estos permisos pueden convivir con modulos activos de lectura o builder. Tener un modulo detectado no significa autorizar automaticamente una operacion sensible.

Que debe devolver una operacion segura

Para una escritura real, pide que Codex te devuelva:

success: si la operacion fue aceptada y completada.
dry_run: si no se guardo nada.
changed: si hubo cambios reales.
summary: resumen legible.
warnings: riesgos o partes pendientes.
audit: ability, usuario, objeto afectado y fecha cuando aplique.
backups creados o ruta segura de restauracion si la operacion lo requiere.

Si la respuesta dice "hecho" pero no incluye evidencia, pide verificacion.

Buenas practicas

No publiques automaticamente paginas generadas.
No modifiques paginas publicadas sin crear copia o borrador.
No actives herramientas destructivas si no las necesitas.
No pegues secretos en prompts.
Pide siempre evidencia o resumen de cambios.
Revisa visualmente las paginas antes de publicar.
En conversiones, conserva origen y destino hasta terminar QA.
En formularios, revisa destinatarios, acciones, validaciones y mensajes.
En ecommerce, revisa impacto comercial antes de precios o stock.

Produccion

En produccion, cualquier escritura real deberia requerir aprobacion humana. Para pruebas, usa staging o borradores.

Redaccion de secretos

No pegues passwords, licencias, tokens API ni claves privadas en prompts. Las habilidades de settings soportados deben redactar secretos al leer, y no deberian devolver valores sensibles completos.

Si necesitas configurar una clave, lo mas seguro es:

Ponerla tu manualmente en el admin del plugin correspondiente.
Pedir a Codex que verifique solo si el campo esta configurado.
No pedir nunca que repita el secreto en la respuesta.

Backups y rollback

Para cambios con riesgo alto pide:

backup antes de escribir;
ID de backup o referencia;
plan de rollback;
dry_run de rollback si existe;
confirmacion destructiva solo al ejecutar.

En builders, rollback y limpieza son pasos separados. Primero confirma que el borrador nuevo funciona; despues decide si limpiar datos antiguos.