Actualizar README.md

README.md

@@ -1,6 +1,38 @@
 # ZC_ESTANDAR_ALIMENTACION
 ---
 
+## Codigos para commits:
+
+- **refactor**: Cambios en el código que no añaden funciones ni arreglan fallos, sino que mejoran su estructura interna.
+    - Ej: refactor: reescribe los cálculos de PID en SCL para simplificar el bloque
+
+- **perf**: (Performance) Modificaciones enfocadas exclusivamente en mejorar el rendimiento.
+    - Ej: perf: optimiza las llamadas en el OB1 para reducir el tiempo de ciclo
+
+- **docs**: Cambios únicamente en documentación (archivos Markdown, manuales, comentarios extensos).
+    - Ej: docs: actualiza las tablas de memoria Modbus en la Wiki
+
+- **test**: Añadir o corregir código destinado exclusivamente a pruebas.
+    - Ej: test: añade DBs y funciones de simulación analógica para las pruebas FAT
+
+- **chore**: (Mantenimiento rutinario) Limpieza general, actualizaciones de variables internas o de herramientas que no afectan al código que corre en producción.
+    - Ej: chore: limpia marcas de memoria sin utilizar en la tabla de variables
+
+- **build**: / ci: Cambios en los archivos de configuración externos o de automatización.
+    - Ej: ci: modifica el archivo YAML para compilar ejecutables de Python
+ 
+El modificador crítico: Las paradas de planta (Breaking Changes)
+En automatización industrial, hay modificaciones que son delicadas porque rompen la retrocompatibilidad: cambiar la estructura de un bloque de datos (DB) que obliga a reiniciarlo, alterar los pines de entrada/salida de un FB maestro, o modificar el hardware.
+
+En Conventional Commits, esto se marca añadiendo un signo de exclamación ! justo antes de los dos puntos:
+
+- feat!: modifica el DB de interfaz principal con el SCADA
+
+- refactor!: cambia el tipo de dato de INT a REAL en la entrada del motor
+
+
+---
+
 # Índice del análisis TIA Portal
 
 - [Mapa de dependencias](00_Mapa_Dependencias.md)
@@ -579,31 +611,3 @@ flowchart LR
 
 ---
 
-## Codigos para commits:
-
-- **refactor**: Cambios en el código que no añaden funciones ni arreglan fallos, sino que mejoran su estructura interna.
-    - Ej: refactor: reescribe los cálculos de PID en SCL para simplificar el bloque
-
-- **perf**: (Performance) Modificaciones enfocadas exclusivamente en mejorar el rendimiento.
-    - Ej: perf: optimiza las llamadas en el OB1 para reducir el tiempo de ciclo
-
-- **docs**: Cambios únicamente en documentación (archivos Markdown, manuales, comentarios extensos).
-    - Ej: docs: actualiza las tablas de memoria Modbus en la Wiki
-
-- **test**: Añadir o corregir código destinado exclusivamente a pruebas.
-    - Ej: test: añade DBs y funciones de simulación analógica para las pruebas FAT
-
-- **chore**: (Mantenimiento rutinario) Limpieza general, actualizaciones de variables internas o de herramientas que no afectan al código que corre en producción.
-    - Ej: chore: limpia marcas de memoria sin utilizar en la tabla de variables
-
-- **build**: / ci: Cambios en los archivos de configuración externos o de automatización.
-    - Ej: ci: modifica el archivo YAML para compilar ejecutables de Python
- 
-El modificador crítico: Las paradas de planta (Breaking Changes)
-En automatización industrial, hay modificaciones que son delicadas porque rompen la retrocompatibilidad: cambiar la estructura de un bloque de datos (DB) que obliga a reiniciarlo, alterar los pines de entrada/salida de un FB maestro, o modificar el hardware.
-
-En Conventional Commits, esto se marca añadiendo un signo de exclamación ! justo antes de los dos puntos:
-
-- feat!: modifica el DB de interfaz principal con el SCADA
-
-- refactor!: cambia el tipo de dato de INT a REAL en la entrada del motor