apply suggested changes

docs/development-rules/README.md

@@ -16,4 +16,7 @@
 - [Estilo del código](sections/code-style.md) 🎨 - ¡Asegúrate de que tu código sea legible y consistente! 🤓 Este documento te dará las pautas para escribir código limpio y fácil de entender.
 - [Registro de eventos (logs)](sections/logs.md) 🪵 - ¡Registra los eventos importantes para facilitar la depuración y el monitoreo!
 - [Desarrollo seguro](sections/security.md) 🛡️ - ¡Protege tu aplicación contra vulnerabilidades y ataques!
-- [Bases de datos relacionales](sections/relational-dbs.md) 📊 - ¡Asegúrate de que tus bases de datos sean ordenadas, eficientes y seguras!
+- [Bases de datos relacionales](sections/relational-dbs.md) 📊 - ¡Asegúrate de que tus bases de datos sean ordenadas, eficientes y seguras!
\ No newline at end of file
+
+---
+* volver al [inicio](/README.md)

docs/development-rules/sections/code-versioning.md

@@ -85,13 +85,13 @@ Adicionalmente están las ramas *release*, que por lo regular tendrán una tarea
 
 A continuación se presenta una guía del flujo de una rama tipo *feature*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer la tarea, como para los revisores.
 
-![Manejo de ramas tipo "feature"](/resources/diagrams/git-flow/branches-feature.drawio.png)[^1]
+![Manejo de ramas tipo "feature"](/resources/diagrams/git-flow/branches-feature.drawio.png)
 
 #### Rama *Release*
 
 A continuación se presenta una guía del flujo de una rama tipo *release*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el lanzamiento, como para los revisores.
 
-![Manejo de ramas tipo "release"](/resources/diagrams/git-flow/branches-release.drawio.png)[^2]
+![Manejo de ramas tipo "release"](/resources/diagrams/git-flow/branches-release.drawio.png)
 
 #### Rama *Hotfix*
 
@@ -99,7 +99,7 @@ Las tareas de estas ramas son para corregir algo urgente que no da tiempo de esp
 
 A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el ajuste, como para los revisores.
 
-![Manejo de ramas tipo "hotfix"](../../../resources/diagrams/git-flow/branches-hotfix.drawio.svg)[^3]
+![Manejo de ramas tipo "hotfix"](../../../resources/diagrams/git-flow/branches-hotfix.drawio.svg)
 
 ### Lanzamientos y etiquetas (Releases, tags)
 
@@ -112,12 +112,6 @@ Al crear un lanzamiento, se debe tener en cuenta lo siguiente:
    1. No especificar cada commit ni cada tarea, solo los cambios en funcionalidades completas.
    2. No detallar cambios técnicos. Por ejemplo, solo “*dependency update*” en lugar de listar todas las dependencias que se cambiaron
 
-
-[^1]: [Editable para el diagrama de las ramas feature](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
-[^2]: [Editable para el diagrama de las ramas release](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
-[^3]: [Editable para el diagrama de las ramas release](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
-[^volver]: volver al [inicio](/README.md)
-
 ---
 * volver al [inicio](/README.md)
 * volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/semantic-versioning.md

@@ -11,7 +11,7 @@ Para el versionamiento de proyectos de software, seguimos las especificaciones d
 * En el formato **X.Y.Z**:
     * El número **X** indicará un número de versión mayor, corresponde a cambios que no tienen compatibilidad con versiones anteriores (por ejemplo, un cambio completo de una API)
     * El número **Y** indicará un número de versión menor, indica cambios compatible con versiones anteriores (por ejemplo, nuevas características o ajustes de bugs no prioritarios)
-    * El número **Z** indicará un número de parche, lo que se denomita un `hotfix` en inglés.
+    * El número **Z** indicará un número de parche, lo que se denomina un `hotfix` en inglés.
 * Nunca se deberá modificar el contenido de una versión existente. En caso necesario se debe crear una nueva versión.
 * Al realizar un lanzamiento nuevo en *GitHub* (*[Release](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)*), el título deberá ser el número del lanzamiento (por ejemplo, *1.2.0*)
 * Todo lanzamiento de una nueva versión deberá tener una descripción detallada de los cambios en la misma.

docs/development-rules/sections/tools-and-frameworks.md

@@ -2,11 +2,13 @@
 
 El uso de diferentes herramientas y frameworks será determinado para cada proyecto, en conjunto con los miembros del equipo, a continuación se presentan algunas recomendaciones generales.
 
+### Recomendaciones generales
+* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
+
 ## Back end
 
 Un proyecto de back end debe:
 
-* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
 * Utilizar transacciones en servicios que almacenen datos en 2 o más tablas de una base de datos *SQL* de manera simultánea.
 
 ## Front end