Cómo pruebo y reviso las guías

Este cuaderno mezcla experiencia profesional, laboratorio doméstico y documentación técnica. Para que una guía sea útil, separo lo que observé de lo que debería ocurrir según la documentación.

Cómo preparo una guía

1. Defino el escenario. Sistema, versión, proveedor y objetivo concreto.
2. Identifico el riesgo. Antes de cambiar datos, red o arranque, preparo una salida y describo cómo usarla.
3. Ejecuto por etapas. Un cambio pequeño produce una señal más fácil de interpretar.
4. Verifico. Incluyo comandos, respuestas esperadas o comprobaciones desde otro punto de vista.
5. Reviso con fuentes primarias. Enlazo documentación del fabricante o del proyecto cuando existe.

Qué significa cada estado

Probado: ejecuté el procedimiento completo en el entorno que indica la guía y comprobé el resultado.

Revisado: contrasté comandos, versiones y enlaces con la documentación actual, aunque no repetí toda la instalación.

Histórico: el artículo describe una versión o entorno sin soporte. Se conserva como referencia y no como receta vigente.

Qué significan las fechas

La fecha de publicación cuenta cuándo nació la nota. “Revisado” indica una pasada editorial o técnica posterior; no garantiza que todas las versiones futuras se comporten igual. Si una entrada es demasiado breve o ha quedado ligada a un momento concreto, pasa al archivo personal y deja de aparecer como guía.

Límites honestos

No ejecuto en producción un comando solo porque funcione en un laboratorio. Una controladora, una versión de PHP o una política del proveedor pueden cambiar el resultado. Por eso indico las suposiciones y prefiero que el lector comprenda la comprobación antes que copie una solución a ciegas.

Cuando detectes una versión obsoleta o un paso ambiguo, puedes enviarme el entorno exacto y el resultado. Esa información permite corregir la guía de forma reproducible.