Miguel Mejía · @magomez · César Galvis · Miguel Mejía · César Galvis · Miguel Mejía
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+# 5. Buenas Prácticas en React
+
+## Componentes de Función: La preferencia del equipo
+
+No hay razón para seguir escribiendo componentes de clase, son una tecnología vieja que se evitamos en nuestras aplicaciones. Los componentes de función, junto con los _Hooks_, ofrecen una forma más simple y directa de manejar el estado, la sincronización y los efectos secundarios, lo que resulta en un código más limpio y fácil de depurar.
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+# 5. Buenas Prácticas en React
+
+## Componentes de Función: La preferencia del equipo
+
+No hay razón para seguir escribiendo componentes de clase, son una tecnología vieja que se evitamos en nuestras aplicaciones. Los componentes de función, junto con los _Hooks_, ofrecen una forma más simple y directa de manejar el estado, la sincronización y los efectos secundarios, lo que resulta en un código más limpio y fácil de depurar.
+
+## Estructura y Organización
+
+Los componentes deben tener una única responsabilidad. Los que orquestan, renderizan y hacen malabares al mismo tiempo, fácilmente se convierten en un nido de _bugs_, que fácilmente crean condiciones de carrera o bucles de renderizado.
+
+la estructura de los componentes en el archivodebe ser la siguiente:
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+
+Para mantener el código claro, un handler debe tener una sola responsabilidad, como hacer una petición a la API o actualizar un estado. Siempre los nombramos con el prefijo handle (ej., handleClick, handleSubmit). Si un handler depende del estado o de las props, lo definimos dentro del componente; si no, lo movemos fuera del componente para que sea más fácil de reutilizar y probar, si solo es usado en este componente, puede dejarse en el mismo archivo, de lo contrario, debe moverse al lugar que la arquitectura de la función haya designado para los helpers y utils.
+
+## Seguridad y Buenas Prácticas
+
+- **Sanitización de datos**: Asegúrate de que los datos externos se limpien antes de ser renderizados en JSX para prevenir ataques de _cross-site scripting_.
+
+- **Manejo seguro de dependencias del package.json**: La gestión de dependencias es un proceso delicado. Las actualizaciones automáticas solo deben aplicarse para _hotfixes_ y parches menores. Las actualizaciones de versión y los cambios importantes deben hacerse bajo supervisión al menos una vez al año.
+
+- **¡No uses `dangerouslySetInnerHTML`!**: Esta propiedad es peligrosa y debe evitarse. Si es absolutamente necesario, su uso debe estar justificado y el contenido debe ser sanitizado de antemano.
+
+## Manejo de errores
+
+### Manejo de Errores Asíncronos
+
+Cada llamada a una API o operación async debe estar envuelta en un bloque try-catch o un chaininng `.then().catch()` apropiado, y los errores deben ser manejados de manera uniforme en toda la aplicación.
--- a/docs/development-rules/sections/frontend-structure.md 0 → 100644
+++ b/docs/development-rules/sections/frontend-structure.md 0 → 100644
+# Guía de estilo para desarrollo en React con TS
+
+## TL;DR
+
+Instala ESLint y Prettier, utiliza las reglas de lint suministradas y el default de Prettier.
+
+Escribe código para humanos. La legibilidad y sostenibilidad son más importantes que la concisión pues el objetivo es que cualquier persona pueda entender el código rápidamente.
+
+Gestiona las dependencias de forma responsable y prioriza la accesibilidad partiendo de estructurar un HTML semántico. En TypeScript no des lugar a `any`; preferiere `unknown` y la validación de tipos. En React, escribe componentes de Función con una sola responsabilidad y escribe el JSX libre de lógica compleja...
+
+Maneja los errores de forma explícita para ofrecer una buena experiencia de desarrollo tus compañeros y una de usuario más robusta.
--- a/docs/development-rules/sections/frontend-structure.md 0 → 100644
+++ b/docs/development-rules/sections/frontend-structure.md 0 → 100644
+    - [Una línea, una acción](./front/3-convenciones-generales.md#una-línea-una-acción)
+    - [Nomenclatura](./front/3-convenciones-generales.md#nomenclatura)
+    - [Bibliotecas Externas](./front/3-convenciones-generales.md#bibliotecas-externas)
+    - [Accesibilidad](./front/3-convenciones-generales.md#accesibilidad)
+    - [El texto de la interfaz de usuario](./front/3-convenciones-generales.md#el-texto-de-la-interfaz-de-usuario)
+    - [Comentarios solo cuando el código no lo explica todo](./front/3-convenciones-generales.md#comentarios-solo-cuando-el-código-no-lo-explica-todo)
+    - [Aduana: Importaciones y exportaciones](./front/3-convenciones-generales.md#aduana-importaciones-y-exportaciones)
+4. [Buenas Prácticas en TypeScript](./front/4-buenas-practicas-en-typescript.md)
+    - [Explicar lo suficiente](./front/4-buenas-practicas-en-typescript.md#explicar-lo-suficiente)
+    - [Interfaces y Tipos: ¿Cuál y cuándo?](./front/4-buenas-practicas-en-typescript.md#interfaces-y-tipos-cuál-y-cuándo)
+    - [Arrays y Genéricos](./front/4-buenas-practicas-en-typescript.md#arrays-y-genéricos)
+    - [Archivos de definición de tipos](./front/4-buenas-practicas-en-typescript.md#archivos-de-definición-de-tipos)
+    - [Vamo' a calmarno'](./front/4-buenas-practicas-en-typescript.md#vamo-a-calmarno)
+    - [Constantes con enums y posibilidades con literales](./front/4-buenas-practicas-en-typescript.md#constantes-con-enums-y-posibilidades-con-literales)
+    - [`any`, `unknown` y `never`](./front/4-buenas-practicas-en-typescript.md#any-unknown-y-never)
+    - [Helpers y Tipos Utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
--- a/docs/development-rules/sections/frontend-structure.md 0 → 100644
+++ b/docs/development-rules/sections/frontend-structure.md 0 → 100644
+    - [Bibliotecas Externas](./front/3-convenciones-generales.md#bibliotecas-externas)
+    - [Accesibilidad](./front/3-convenciones-generales.md#accesibilidad)
+    - [El texto de la interfaz de usuario](./front/3-convenciones-generales.md#el-texto-de-la-interfaz-de-usuario)
+    - [Comentarios solo cuando el código no lo explica todo](./front/3-convenciones-generales.md#comentarios-solo-cuando-el-código-no-lo-explica-todo)
+    - [Aduana: Importaciones y exportaciones](./front/3-convenciones-generales.md#aduana-importaciones-y-exportaciones)
+4. [Buenas Prácticas en TypeScript](./front/4-buenas-practicas-en-typescript.md)
+    - [Explicar lo suficiente](./front/4-buenas-practicas-en-typescript.md#explicar-lo-suficiente)
+    - [Interfaces y Tipos: ¿Cuál y cuándo?](./front/4-buenas-practicas-en-typescript.md#interfaces-y-tipos-cuál-y-cuándo)
+    - [Arrays y Genéricos](./front/4-buenas-practicas-en-typescript.md#arrays-y-genéricos)
+    - [Archivos de definición de tipos](./front/4-buenas-practicas-en-typescript.md#archivos-de-definición-de-tipos)
+    - [Vamo' a calmarno'](./front/4-buenas-practicas-en-typescript.md#vamo-a-calmarno)
+    - [Constantes con enums y posibilidades con literales](./front/4-buenas-practicas-en-typescript.md#constantes-con-enums-y-posibilidades-con-literales)
+    - [`any`, `unknown` y `never`](./front/4-buenas-practicas-en-typescript.md#any-unknown-y-never)
+    - [Helpers y Tipos Utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
+5. [Buenas Prácticas en React](./front/5-buenas-practicas-en-react.md)
+    - [Componentes de Función: La preferencia del equipo](./front/5-buenas-practicas-en-react.md#componentes-de-función-la-preferencia-del-equipo)
--- a/docs/development-rules/sections/frontend-structure.md 0 → 100644
+++ b/docs/development-rules/sections/frontend-structure.md 0 → 100644
+    - [Comentarios solo cuando el código no lo explica todo](./front/3-convenciones-generales.md#comentarios-solo-cuando-el-código-no-lo-explica-todo)
+    - [Aduana: Importaciones y exportaciones](./front/3-convenciones-generales.md#aduana-importaciones-y-exportaciones)
+4. [Buenas Prácticas en TypeScript](./front/4-buenas-practicas-en-typescript.md)
+    - [Explicar lo suficiente](./front/4-buenas-practicas-en-typescript.md#explicar-lo-suficiente)
+    - [Interfaces y Tipos: ¿Cuál y cuándo?](./front/4-buenas-practicas-en-typescript.md#interfaces-y-tipos-cuál-y-cuándo)
+    - [Arrays y Genéricos](./front/4-buenas-practicas-en-typescript.md#arrays-y-genéricos)
+    - [Archivos de definición de tipos](./front/4-buenas-practicas-en-typescript.md#archivos-de-definición-de-tipos)
+    - [Vamo' a calmarno'](./front/4-buenas-practicas-en-typescript.md#vamo-a-calmarno)
+    - [Constantes con enums y posibilidades con literales](./front/4-buenas-practicas-en-typescript.md#constantes-con-enums-y-posibilidades-con-literales)
+    - [`any`, `unknown` y `never`](./front/4-buenas-practicas-en-typescript.md#any-unknown-y-never)
+    - [Helpers y Tipos Utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
+5. [Buenas Prácticas en React](./front/5-buenas-practicas-en-react.md)
+    - [Componentes de Función: La preferencia del equipo](./front/5-buenas-practicas-en-react.md#componentes-de-función-la-preferencia-del-equipo)
+    - [Estructura y Organización](./front/5-buenas-practicas-en-react.md#estructura-y-organización)
+    - [Props: Cómo pasar y gestionar propiedades](./front/5-buenas-practicas-en-react.md#props-cómo-pasar-y-gestionar-propiedades)
+    - [Manejo de Estados: Estrategias claras](./front/5-buenas-practicas-en-react.md#manejo-de-estados-estrategias-claras)
--- a/docs/development-rules/sections/frontend-structure.md 0 → 100644
+++ b/docs/development-rules/sections/frontend-structure.md 0 → 100644
+    - [Archivos de definición de tipos](./front/4-buenas-practicas-en-typescript.md#archivos-de-definición-de-tipos)
+    - [Vamo' a calmarno'](./front/4-buenas-practicas-en-typescript.md#vamo-a-calmarno)
+    - [Constantes con enums y posibilidades con literales](./front/4-buenas-practicas-en-typescript.md#constantes-con-enums-y-posibilidades-con-literales)
+    - [`any`, `unknown` y `never`](./front/4-buenas-practicas-en-typescript.md#any-unknown-y-never)
+    - [Helpers y Tipos Utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
+5. [Buenas Prácticas en React](./front/5-buenas-practicas-en-react.md)
+    - [Componentes de Función: La preferencia del equipo](./front/5-buenas-practicas-en-react.md#componentes-de-función-la-preferencia-del-equipo)
+    - [Estructura y Organización](./front/5-buenas-practicas-en-react.md#estructura-y-organización)
+    - [Props: Cómo pasar y gestionar propiedades](./front/5-buenas-practicas-en-react.md#props-cómo-pasar-y-gestionar-propiedades)
+    - [Manejo de Estados: Estrategias claras](./front/5-buenas-practicas-en-react.md#manejo-de-estados-estrategias-claras)
+    - [Sincronización (`useEffect`)](./front/5-buenas-practicas-en-react.md#sincronización-useeffect)
+    - [useMemo y useCallback](./front/5-buenas-practicas-en-react.md#usememo-y-usecallback)
+    - [Código ordenado](./front/5-buenas-practicas-en-react.md#código-ordenado)
+    - [Fragmentos y Portales](./front/5-buenas-practicas-en-react.md#fragmentos-y-portales)
+    - [Handlers (Funciones para manejar eventos de usuario)](./front/5-buenas-practicas-en-react.md#handlers-funciones-para-manejar-eventos-de-usuario)
+    - [Seguridad y Buenas Prácticas](./front/5-buenas-practicas-en-react.md#seguridad-y-buenas-prácticas)
--- a/docs/development-rules/sections/front/2-configuracion-del-entorno.md 0 → 100644
+++ b/docs/development-rules/sections/front/2-configuracion-del-entorno.md 0 → 100644
+Puedes integrarlo en tu editor con los plugins oficiales. Si no, de seguro habremos dispuesto de un script dentro del package.json para darle formato al código: usualmente `<npm/pnpm/yarn/administrador de paquetes> format` harán ese trabajo.
+
+### La seguridad antes que la policía
+
+Prettier es nuestra brújula de estilo y ESLint es quien evita que la caguemos antes de tiempo con pendejadas. Su propósito es detectar problemas de calidad, consistencia y posibles errores antes de que lleguen al código. Nuestra configuración combina las recomendaciones estándar de Airbnb, las de react y la ultima palabra la da prettier para evitar conflictos en las reglas...
+
+```typescript
+extends: [
+    "airbnb",
+    "airbnb-typescript",
+    "plugin:react-hooks/recommended",
+    "plugin:prettier/recommended",
+],
+```
+
+Pero en esta área nuestro equipo si tiene opiniones y acuerdos que modifican las reglas base y responden a el cómo vemos el código y las experiencias que hemos tenido.
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+# 3. Convenciones Generales
+
+## Orden del código
+
+**Módulos**: Siempre trabajaremos con el sistema de Módulos de ECMAScript (ESM) en nuestro código. Aunque aún existen bibliotecas en CommonJS (CJS), podemos usarlas como módulos e importarlas sin usar la sintaxis de `require`.
+
+**Evitar el entorno global**: Usemos las capacidades de los módulos para mantener nuestro entorno global limpio. No hay necesidad de declarar variables globales que ensucien todo y generar conflictos.
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+
+**Clases con propósito**: No creemos clases solo para encapsular un conjunto de variables y funciones, eso lo puede hacer mejor un módulo. Las clases deben cumplir un propósito de arquitectura, como implementar un patrón de diseño (di tu un _singleton_) o manejar un estado interno complejo y persistente.
+
+## Una línea, una acción
+
+Buscamos que cada línea de código tenga un propósito único y fácil de entender. Cuando una sola línea hace demasiadas cosas, se vuelve difícil de leer y peor de depurar. Por eso, preferimos la claridad sobre la concisión.
+
+Esto explica porqué evitamos los ternarios anidados y usamos llaves en todos nuestros bloques de control (incluso en los `if` de una sola línea), lo que hace que el código sea predecible y reduce la posibilidad de errores a largo plazo.
+
+## Nomenclatura
+
+Una de las cosas más difíciles en la programación es asignar buenos nombres de forma consistente. La razón es simple: un buen nombre reduce la necesidad de explicaciones. Buscamos nombres que le digan a cualquiera lo que están viendo sin necesidad de comentarios.
+
+- **Idioma**: Dado que los lenguajes de programación que usamos están en inglés, hemos acordado usar este idioma en nuestro código. Respetamos y nos gusta el idioma en el que hablamos pero el código en "espanglish" puede ser muy molesto y aumentar la carga cognitiva.
+
+- **Variables y funciones**: Usamos **`camelCase`**. Los nombres de variables deben ser sustantivos que describan su contenido (ej., `userId`, `userName`), y los de las funciones, verbos que indiquen lo que hacen (ej., `fetchUsers`, `calculateTotal`, `getSomeShit`)... tener cuidado con palabras genéricas como `info` o `data` y de cuando sea posible optar por algo más descriptivo de la información que contienen.
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+
+Buscamos que cada línea de código tenga un propósito único y fácil de entender. Cuando una sola línea hace demasiadas cosas, se vuelve difícil de leer y peor de depurar. Por eso, preferimos la claridad sobre la concisión.
+
+Esto explica porqué evitamos los ternarios anidados y usamos llaves en todos nuestros bloques de control (incluso en los `if` de una sola línea), lo que hace que el código sea predecible y reduce la posibilidad de errores a largo plazo.
+
+## Nomenclatura
+
+Una de las cosas más difíciles en la programación es asignar buenos nombres de forma consistente. La razón es simple: un buen nombre reduce la necesidad de explicaciones. Buscamos nombres que le digan a cualquiera lo que están viendo sin necesidad de comentarios.
+
+- **Idioma**: Dado que los lenguajes de programación que usamos están en inglés, hemos acordado usar este idioma en nuestro código. Respetamos y nos gusta el idioma en el que hablamos pero el código en "espanglish" puede ser muy molesto y aumentar la carga cognitiva.
+
+- **Variables y funciones**: Usamos **`camelCase`**. Los nombres de variables deben ser sustantivos que describan su contenido (ej., `userId`, `userName`), y los de las funciones, verbos que indiquen lo que hacen (ej., `fetchUsers`, `calculateTotal`, `getSomeShit`)... tener cuidado con palabras genéricas como `info` o `data` y de cuando sea posible optar por algo más descriptivo de la información que contienen.
+
+- **Tipos, clases y componentes**: Usamos **`PascalCase`**. Esto ayuda a diferenciarlos del resto del código (ej., `UserType`, `ProductCard`).
+
+- **Constantes de configuración**: Usamos **`SCREAMING_SNAKE_CASE`**. Son constantes que se usan para una configurar un comportamiento del código, su nombre en mayúsculas debe dejar muy claro la info que contienen (ej., `API_URL`, `MAX_RETRIES`, `I_AM_A_MAGIC_NUMBER`).
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+
+Una de las cosas más difíciles en la programación es asignar buenos nombres de forma consistente. La razón es simple: un buen nombre reduce la necesidad de explicaciones. Buscamos nombres que le digan a cualquiera lo que están viendo sin necesidad de comentarios.
+
+- **Idioma**: Dado que los lenguajes de programación que usamos están en inglés, hemos acordado usar este idioma en nuestro código. Respetamos y nos gusta el idioma en el que hablamos pero el código en "espanglish" puede ser muy molesto y aumentar la carga cognitiva.
+
+- **Variables y funciones**: Usamos **`camelCase`**. Los nombres de variables deben ser sustantivos que describan su contenido (ej., `userId`, `userName`), y los de las funciones, verbos que indiquen lo que hacen (ej., `fetchUsers`, `calculateTotal`, `getSomeShit`)... tener cuidado con palabras genéricas como `info` o `data` y de cuando sea posible optar por algo más descriptivo de la información que contienen.
+
+- **Tipos, clases y componentes**: Usamos **`PascalCase`**. Esto ayuda a diferenciarlos del resto del código (ej., `UserType`, `ProductCard`).
+
+- **Constantes de configuración**: Usamos **`SCREAMING_SNAKE_CASE`**. Son constantes que se usan para una configurar un comportamiento del código, su nombre en mayúsculas debe dejar muy claro la info que contienen (ej., `API_URL`, `MAX_RETRIES`, `I_AM_A_MAGIC_NUMBER`).
+
+## Bibliotecas Externas
+
+Importar debe suceder solo cuando algo es realmente necesario. Evitamos importar por importar y nos aseguramos de que las bibliotecas que usamos estén bien mantenidas y sean de alta calidad.
+
+Un ejemplo de lo que puede salir mal es el caso de **`left-pad`**. Una biblioteca con una función simple (no más de cinco líneas de código y bastante innecesaria si se conocen los métodos para `String`), que, al ser eliminada de NPM(Luego de eso se reforzó la política de no borrado de NPM), causó que miles de proyectos dejaran de compilar. [El chisme completo](https://en.wikipedia.org/wiki/Npm_left-pad_incident).
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+**Cada dependencia es una responsabilidad.**
+
+Por lo tanto:
+
+- Solo importamos cuando la lógica del proyecto no depende de la importación.
+- Solo importamos si hemos confirmado que no hay una forma directa o clara de realizar lo que necesitamos con nuestro propio código dentro del tiempo que disponemos.
+- Solo importamos bibliotecas que tengan soporte activo (al menos un año).
+- Solo importamos bibliotecas con tipado en TypeScript nativo para integrarlas mejor.
+
+## Accesibilidad
+
+Construir una interfaz de usuario no es solo cuestión de estética. La accesibilidad es fundamental para que nuestras aplicaciones puedan ser usadas por cualquier persona, considerando sus capacidades físicas, cognitivas, sociales, contextuales y tecnológicas.
+
+**HTML Semántico**: Usa las etiquetas correctas (`<button>`, `<nav>`, `<article>`, ... ) en lugar de `<div>` como mantequilla en restaurante francés. El HTML semántico es clave para construir aplicaciones web accesibles desde el inicio, ayudando a los lectores de pantalla a entender la estructura de la página, facilitando la navegación con tecnologías asistivas y mejorando el SEO. [Aquí hay una pequeña guía](https://webdesign.solomon.ng/html-and-css/semantic-html/semantic-html.html).
+
+**Atributos `aria-*`**: Una vez que nuestro documento está bien estructurado, los usuarios con tecnologías asistivas deben ser capaces de comprender los cambios que introducimos en el documento a través de las interacciones. Aquí es donde entra `aria-*`, que complementa lo que el HTML no cubre. Sin embargo, _no aria is better than wrong aria_(Es mejor no tener aria a tener uno mal escrito). Si no entiendes el atributo, investiga antes de usarlo. [Esta es una buena introducción a ARIA](https://accessibilityfordevelopers.com/guide-to-aria/) y [aquí está la guía de MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA), que es más amigable que las especificaciones de la W3C.
--- a/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+++ b/docs/development-rules/sections/front/3-convenciones-generales.md 0 → 100644
+Por lo tanto:
+
+- Solo importamos cuando la lógica del proyecto no depende de la importación.
+- Solo importamos si hemos confirmado que no hay una forma directa o clara de realizar lo que necesitamos con nuestro propio código dentro del tiempo que disponemos.
+- Solo importamos bibliotecas que tengan soporte activo (al menos un año).
+- Solo importamos bibliotecas con tipado en TypeScript nativo para integrarlas mejor.
+
+## Accesibilidad
+
+Construir una interfaz de usuario no es solo cuestión de estética. La accesibilidad es fundamental para que nuestras aplicaciones puedan ser usadas por cualquier persona, considerando sus capacidades físicas, cognitivas, sociales, contextuales y tecnológicas.
+
+**HTML Semántico**: Usa las etiquetas correctas (`<button>`, `<nav>`, `<article>`, ... ) en lugar de `<div>` como mantequilla en restaurante francés. El HTML semántico es clave para construir aplicaciones web accesibles desde el inicio, ayudando a los lectores de pantalla a entender la estructura de la página, facilitando la navegación con tecnologías asistivas y mejorando el SEO. [Aquí hay una pequeña guía](https://webdesign.solomon.ng/html-and-css/semantic-html/semantic-html.html).
+
+**Atributos `aria-*`**: Una vez que nuestro documento está bien estructurado, los usuarios con tecnologías asistivas deben ser capaces de comprender los cambios que introducimos en el documento a través de las interacciones. Aquí es donde entra `aria-*`, que complementa lo que el HTML no cubre. Sin embargo, _no aria is better than wrong aria_(Es mejor no tener aria a tener uno mal escrito). Si no entiendes el atributo, investiga antes de usarlo. [Esta es una buena introducción a ARIA](https://accessibilityfordevelopers.com/guide-to-aria/) y [aquí está la guía de MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA), que es más amigable que las especificaciones de la W3C.
+
+**Manejo de Foco**: Es clave que todo lo que se puede hacer con el _mouse_ también se posible hacerlo con el teclado. Asegúrate de que los elementos sean enfocables y que el orden del foco sea lógico.
--- a/docs/development-rules/sections/front/4-buenas-practicas-en-typescript.md 0 → 100644
+++ b/docs/development-rules/sections/front/4-buenas-practicas-en-typescript.md 0 → 100644
+enum Status {
+  Loading = 'LOADING',
+  Success = 'SUCCESS',
+  Error = 'ERROR',
+}
+
+const currentStatus = Status.Loading;
+```
+
+El uso de literales es recomendado para un conjunto de valores fijos y acotados. Por ejemplo: `type UserRole = 'admin' | 'guest'`.
+
+## `any`, `unknown` y `never`
+
+**`any`**: **NO USARLO NUNCA**, salvo que estemos en proceso de migrar algo de JS a TS. Es la peor práctica y anula completamente el propósito de TypeScript.
+
+**`unknown`**: Este es el tipo de dato que debes usar cuando no sabes qué tipo va a entrar. Después, usa _type narrowing_ para trabajar con el valor.
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+
+## Props: Cómo pasar y gestionar propiedades
+
+Una de las mayores ventajas de usar TypeScript es que podemos definir la "forma" de las _props_ explícitamente sin usar prop-types, lo que nos permite saber exactamente qué tipo de datos estamos recibiendo y enviando, y evitar errores en tiempo de compilación. Siempre tipamos los props. Esta práctica nos asegura que los datos que pasan entre componentes sean consistentes y predecibles.
+
+Un punto importante es evitar el uso de `React.FC` y similares que sirven para tipar componentes. Aunque parece práctico, puede causar problemas con el tipado de la propiedad `children`, siempre la convierte en opcional, sin importar que la hayamos definido como obligatoria o que el componente no la necesite... lo que podría generar confusiones y _bugs_ difíciles de rastrear.
+
+## Manejo de Estados: Estrategias claras
+
+Di no a los estados derivados; en lugar de almacenar una variable en el estado que se puede calcular a partir de otros, realizamos el cálculo directamente en el cuerpo del componente, antes del renderizado.
+
+Para manejar el estado, usamos `useState` para estados simples, como booleanos, cadenas, números, objetos, etc. Sin embargo, para estados más complejos que involucran múltiples transiciones o modificaciones, preferimos usar `useReducer`, ya que centraliza la lógica de actualización del estado y la hace más predecible y testeable.
+
+## Sincronización (`useEffect`)
+
+Dejemos de pensar en `useEffect` como una simple herramienta para efectos secundarios, tomémoslo como un mecanismo de para la sincronización del componente con sistemas externos (fetch, localstorage, etc). Como se sugiere [You might not need an effect](https://react.dev/learn/you-might-not-need-an-effect), a menudo no se necesita un efecto, por lo que es vital usarlo solo cuando es necesario y para lo que fie creado.
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+
+Para mantener el código claro, un handler debe tener una sola responsabilidad, como hacer una petición a la API o actualizar un estado. Siempre los nombramos con el prefijo handle (ej., handleClick, handleSubmit). Si un handler depende del estado o de las props, lo definimos dentro del componente; si no, lo movemos fuera del componente para que sea más fácil de reutilizar y probar, si solo es usado en este componente, puede dejarse en el mismo archivo, de lo contrario, debe moverse al lugar que la arquitectura de la función haya designado para los helpers y utils.
+
+## Seguridad y Buenas Prácticas
+
+- **Sanitización de datos**: Asegúrate de que los datos externos se limpien antes de ser renderizados en JSX para prevenir ataques de _cross-site scripting_.
+
+- **Manejo seguro de dependencias del package.json**: La gestión de dependencias es un proceso delicado. Las actualizaciones automáticas solo deben aplicarse para _hotfixes_ y parches menores. Las actualizaciones de versión y los cambios importantes deben hacerse bajo supervisión al menos una vez al año.
+
+- **¡No uses `dangerouslySetInnerHTML`!**: Esta propiedad es peligrosa y debe evitarse. Si es absolutamente necesario, su uso debe estar justificado y el contenido debe ser sanitizado de antemano.
+
+## Manejo de errores
+
+### Manejo de Errores Asíncronos
+
+Cada llamada a una API u operación async debe estar envuelta en un bloque try-catch o un chaininng `.then().catch()` apropiado, y los errores deben ser manejados de manera uniforme en toda la aplicación.
--- a/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+++ b/docs/development-rules/sections/front/5-buenas-practicas-en-react.md 0 → 100644
+
+## Seguridad y Buenas Prácticas
+
+- **Sanitización de datos**: Asegúrate de que los datos externos se limpien antes de ser renderizados en JSX para prevenir ataques de _cross-site scripting_.
+
+- **Manejo seguro de dependencias del package.json**: La gestión de dependencias es un proceso delicado. Las actualizaciones automáticas solo deben aplicarse para _hotfixes_ y parches menores. Las actualizaciones de versión y los cambios importantes deben hacerse bajo supervisión al menos una vez al año.
+
+- **¡No uses `dangerouslySetInnerHTML`!**: Esta propiedad es peligrosa y debe evitarse. Si es absolutamente necesario, su uso debe estar justificado y el contenido debe ser sanitizado de antemano.
+
+## Manejo de errores
+
+### Manejo de Errores Asíncronos
+
+Cada llamada a una API u operación async debe estar envuelta en un bloque try-catch o un chaininng `.then().catch()` apropiado, y los errores deben ser manejados de manera uniforme en toda la aplicación.
+
+Una estrategia son los estados de error en hooks personalizados permiten centralizar la lógica de manejo de errores y reutilizarla en múltiples componentes. Lo que ayuda con la consistencia en cómo se manejan los errores en toda la aplicación y facilita el mantenimiento del código.