Fix some typos and syntax

docs/development-rules/sections/front/1-introduccion.md

 # 1. Introducción
 
-Partimos de una idea fundamental: escribimos código no para que una máquina haga algo, sino para que otra persona entienda que se le pidió a la máquina que hiciera.
+Partimos de una idea fundamental: escribimos código no para que una máquina haga algo, sino para que otra persona entienda qué se le pidió a la máquina.
 
 Aunque el rendimiento y la optimización son clave, la sostenibilidad del código es lo que debe guiar el cómo lo escribimos, y esta sostenibilidad está basada en la legibilidad y qué tan rápido una persona que no está familiarizada con el _codebase_ es capaz de comprenderlo. Es bonito cuando logramos algo con dos o tres líneas de código, pero si esas líneas parecen una validación de RegEx con look-ahead, nuestro momento HackerMan va a ser la miseria del equipo al mediano y largo plazo.
 
-Hay miles de formas de escribir lo mismo en JavaScript/TypeScript y React, y no siempre estaremos disponibles para explicar nuestro razonamiento. Incluso, es muy probable que en una semana olvidemos por qué escribimos X y no Y. Por eso, es esencial unificar la forma en la que nos expresamos a través del código... Además, simpre será bonito cuando reducimos la carga cognitiva de las cosas.
+Hay miles de formas de escribir lo mismo en JavaScript/TypeScript y React, y no siempre estaremos disponibles para explicar nuestro razonamiento. Incluso, es muy probable que en una semana olvidemos por qué escribimos X y no Y. Por eso, es esencial unificar la forma en la que nos expresamos a través del código... Además, reducir la carga cognitiva de las cosas es un detalle de fina coquetería.
 
 Este documento es nuestro acuerdo para hablar el mismo idioma, ayudando a que cualquier persona que lea nuestro código se sienta familiarizada y pueda contribuir sin obstáculos.
 
 ---
 [Volver al menú principal](../frontend-structure.md) | [Siguiente: Configuración del Entorno](./2-configuracion-del-entorno.md)
-

docs/development-rules/sections/front/2-configuracion-del-entorno.md

 ## 2. Configuración del Entorno
 
-**TODO LO QUE HACEMOS DEBE ESTAR EN TYPESCRIPT**
-
 ### Herramienta de Formato
 
 Para que el código de los proyectos en JS/TS/React/CualquierCompliantConEcmaScript tenga siempre el mismo formato sin importar quién lo escriba, usamos Prettier. Prettier es una herramienta opinionada, lo que significa que tiene su propio criterio para el formato del código, y como equipo, decidimos adoptarlo y respetarlo al pie de la letra
@@ -35,7 +33,7 @@ Pero en esta área nuestro equipo si tiene opiniones y acuerdos que modifican la
 
 **En React, componentes declarativos, funciones internas de flecha,** los componentes de React deben ser declaraciones de función (`function Componente() {}`), lo que ayuda a la legibilidad y la depuración. Sin embargo, para callbacks y funciones internas del componente, preferimos las funciones flecha (`() => {}`) por su sintaxis concisa y su manejo más predecible de `this`.
 
-**En TypeScript...** funciones de flecha, para evitarnos dolores de cabeza con el this, aunque sea más idiomática function.
+**En TypeScript...** funciones de flecha, para evitarnos dolores de cabeza con el this, aunque function sea más idiomática.
 
 #### Nuestro ruleset
 
@@ -144,4 +142,5 @@ Pero en esta área nuestro equipo si tiene opiniones y acuerdos que modifican la
 ```
 
 ---
-[Anterior: Introducción](./1-introduccion.md) | [Volver al menú principal](../frontend-structure.md) | [Siguiente: Convenciones Generales](./3-convenciones-generales.md)
+[Anterior: Introducción](./1-introduccion.md) | [Volver al menú principal](../frontend-structure.md) | [Siguiente: Convenciones Generales](./3-convenciones-generales.md)
\ No newline at end of file
+

docs/development-rules/sections/front/3-convenciones-generales.md

@@ -6,19 +6,19 @@
 
 **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.
 
-- **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.
+**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 los errores a largo plazo.
+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**: Aunque respetamos el idioma en el que hablamos, el "espanglish" puede ser muy molesto y aumenta la carga cognitiva. Dado que los lenguajes de programación que usamos están en inglés, hemos acordado usar este idioma en nuestro código.
+- **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 ser posible optar por algo más descriptivo de la información que contienen.
 
@@ -43,7 +43,7 @@ Por lo tanto:
 
 ## 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 diversas capacidades físicas, cognitivas, sociales, contextuales y tecnológicas.
+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).
 
@@ -59,21 +59,21 @@ Para facilitar el soporte, la internacionalización y las actualizaciones, se de
 
 Idealmente, los nombres y la estructura de nuestro código deberían ser tan claros que hagan de los comentarios algo innecesario. Sin embargo, rara vez nuestro código alcanza ese nivel de "iluminación", y necesitamos explicar el _porqué_ de una solución. Comentemos lo menos posible y, cuando lo hagamos, sigamos estos parámetros:
 
-- **Solo lo esencial**: Los comentarios deben usarse para explicar la razón de una decisión, no lo que el código está haciendo.
+**Solo lo esencial**: Los comentarios deben usarse para explicar la razón de una decisión, no lo que el código está haciendo.
 
-- **Etiquetas**: Usar etiquetas estandarizadas ayuda a que los comentarios sean fáciles de encontrar y den contexto a quien los lee en el futuro:
+**Etiquetas**: Usar etiquetas estandarizadas ayuda a que los comentarios sean fáciles de encontrar y den contexto a quien los lee en el futuro:
 
-  - **`NOTE:`**: Para dejar una nota importante.
-  - **`WARN:`**: Para advertir de un posible problema.
-  - **`HACK:`**: Para explicar soluciones temporales que deben ser atendidas pronto.
-  - **`TODO:`**: Para marcar una tarea pendiente.
-  - **`FIX:`**: Para indicar que algo está roto y necesita ser arreglado.
+- **`NOTE:`**: Para dejar una nota importante.
+- **`WARN:`**: Para advertir de un posible problema.
+- **`HACK:`**: Para explicar soluciones temporales que deben ser atendidas pronto.
+- **`TODO:`**: Para marcar una tarea pendiente.
+- **`FIX:`**: Para indicar que algo está roto y necesita ser arreglado.
 
-- **Documentación (TSDoc)**: Úsalo solo para funciones y métodos que se exportan y son usados por otros archivos. Como regla general, piensa en qué información te gustaría tener disponible en las ventanas del LSP de tu editor de texto cuando escribes código. No es necesario explicar una función que solo es usada dentro del mismo archivo.
+**Documentación (TSDoc)**: Úsalo solo para funciones y métodos que se exportan y son usados por otros archivos. Como regla general, piensa en qué información te gustaría tener disponible en las ventanas del LSP de tu editor de texto cuando escribes código. No es necesario explicar una función que solo es usada dentro del mismo archivo.
 
 ## Aduana: Importaciones y exportaciones
 
-El orden de las importaciones es crucial para la legibilidad y una estructura consistente en todo nuestro codigo, el orden acordado es, primero las **librerías externas** y dependencias de `node_modules`, como `leaflet` y `axios`, seguidas por los **módulos internos**, que son los archivos de nuestro _codebase_, lo que hay dentro de `src/`, estos últimos siempre deben ser importados con rutas absolutas o alias.
+El orden de las importaciones es crucial para la legibilidad y una estructura consistente en todo nuestro codigo, el orden acordado es, primero las **librerías externas** y dependencias de `node_modules`, como `leaflet` o `axios`, seguidas por los **módulos internos**, que son los archivos de nuestro _codebase_ (lo que hay dentro de `src/`), estos últimos siempre deben ser importados con rutas absolutas o alias.
 
 Además, como equipo, evitamos las exportaciones `default` para tener un mejor seguimiento de los elementos. Esto nos asegura que siempre importemos con el nombre exacto (`import { Button } from '...'`), o que si cambiamos el nombre, sea de forma consciente, evitando confusiones.
 
@@ -83,4 +83,3 @@ Evitamos las importaciones dinámicas (`import('someShit')`) a menos que haya un
 
 ---
 [Volver al menú principal](../frontend-structure.md) | [Siguiente: Buenas Prácticas en TypeScript](./4-buenas-practicas-en-typescript.md)
-

docs/development-rules/sections/front/4-buenas-practicas-en-typescript.md

 # 4. Buenas Prácticas en TypeScript
 
+**TODO LO QUE HACEMOS DEBE ESTAR EN TYPESCRIPT**
+
 Sí, TypeScript es un linter glorificado, pero es el que nos permite movernos de forma segura dentro del despelote que armó el uso desmedido de JavaScript en la web y las ganas de meterlo hasta en la cafetera. No es solo una barrera de seguridad, es una herramienta para construir aplicaciones más robustas y fáciles de entender.
 
 ## Explicar lo suficiente
@@ -22,7 +24,7 @@ La elección entre `interface` y `type` puede ser confusa, y cada 8 días puede
 
 ## Arrays y Genéricos
 
-**Tipado de _arrays_**: Preferimos la sintaxis `string[]` en lugar de `Array<string>`. Es más concisa, fácil de leer y la convención más común en la comunidad.
+**Tipado de _arrays_**: Preferimos la sintaxis `string[]` en lugar de `Array<string>`. Es más concisa, fácil de leer y la convención más común.
 
 **Construcción de genéricos**: Úsalos para crear componentes o funciones que pueden trabajar con una variedad de tipos de datos sin perder el tipado. Un buen genérico no solo tipa la entrada, sino que también tipa la salida, asegurando que la información que retorna la función sea del mismo tipo que recibió.
 
@@ -46,11 +48,11 @@ const aName = getItem(names, 1); // aName es de tipo string, no 'any'.
 
 Para mantener el proyecto organizado, el alcance de los tipos es crucial. Cuando un tipo tiene un alcance limitado a un solo archivo, lo declaramos en ese mismo archivo. Esto mantiene el código cohesivo.
 
-Si un tipo se usa en múltiples archivos, lo extraemos a un archivo `*.types.ts` en la carpeta más cercana que lo contenga. Esta práctica asegura que tengamos una única fuente de verdad, lo que mejora la consistencia y la sostenibilidad del código.
+Si un tipo se usa en múltiples archivos, lo extraemos a un archivo `*.types.ts` en la carpeta más cercana que contenga todos los puntos donde se usa. Esta práctica asegura que tengamos una única fuente de verdad, lo que mejora la consistencia y la sostenibilidad del código.
 
 ## Vamo' a calmarno'
 
-Typescript es un linter, no vale la pena pasar más tiempo construyendo tipos perfectos que escribiendo la lógica de lo que estamos trabajando. Si una solución simple funciona, usarla sin miedo. Las abstracciones innecesarias y la "masturbación de tipos"  solo añaden confusión y complican el código.
+Typescript es un linter, no vale la pena pasar más tiempo construyendo tipos perfectos que escribiendo la lógica de lo que estamos trabajando. Si una solución simple funciona, usarla sin miedo. Las abstracciones innecesarias y la "masturbación de tipos" solo añaden confusión y complican el código.
 
 ## Constantes con enums y posibilidades con literales
 
@@ -84,4 +86,3 @@ El uso de literales es recomendado para un conjunto de valores fijos y acotados.
 
 ---
 [Volver al menú principal](../frontend-structure.md) | [Siguiente: Buenas Prácticas en React](./5-buenas-practicas-en-react.md)
-

docs/development-rules/sections/front/5-buenas-practicas-en-react.md

@@ -6,7 +6,7 @@ No hay razón para seguir escribiendo componentes de clase, son una tecnología
 
 ## Estructura y Organización
 
-Los componentes deben tener una única responsabilidad. Los componentes que orquestan, renderizan y hacen malabares al mismo tiempo, fácilmente se convierten en nidos de _bugs_, como condiciones de carrera o bucles de renderizado.
+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:
 
@@ -78,13 +78,12 @@ El `return` debe contener únicamente:
 
 - Expresiones simples (ej., `{condición && <Componente />}`).
 - Listas (`.map()`).
-- Estructura clara del JSX.
 
 ## 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ícita,emte, 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.
+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 no la hayamos pasado... lo que podría generar confusiones y _bugs_ difíciles de rastrear.
+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
 
@@ -94,27 +93,27 @@ Para manejar el estado, usamos `useState` para estados simples, como booleanos,
 
 ## 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 para su propósito real.
+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.
 
 Para mantener la claridad y la consistencia, haz que cada `useEffect` se encargue de un solo aspecto. Si un componente necesita múltiples `useEffect`, esto podría ser un indicio de que está asumiendo demasiadas responsabilidades y que la arquitectura debe ser revisada.
 
-Y para cierre del useEffect... si un efecto crea una suscripción o un temporizador, asegúrate de retornar la función de limpieza (_cleanup_) para evitar fugas de memoria y otros chascarrillo.
+Y para cierre... del useEffect... si un efecto crea una suscripción o un temporizador, asegúrate de retornar la función de limpieza (_cleanup_) para evitar fugas de memoria y otros chascarrillos.
 
 ## useMemo y useCallback
 
-No agarrarlos por default ni meterlos hasta en la sopa. Estos hooks tienen un costo de memoria y de complejidad que no siempre vale la pena. Úsalos solo cuando sea necesario, siguiendo esta idea: empezar sin ellos y agrégalos solo cuando veas un problema de rendimiento o un re-render innecesario que impacte el performance o la UX.
+No agarrarlos por default ni meterlos hasta en la sopa. Estos hooks tienen un costo de memoria y de complejidad que no siempre vale la pena. Úsalos solo cuando sea necesario, parte de esta idea: empezar sin ellos y agrégalos solo cuando veas un problema de rendimiento o un re-render innecesario que impacte el performance o la UX.
 
 ## Código ordenado
 
 Parte de nuestra estrategia para mantener el código ordenado y fácil de depurar, echamos mano de useContext y custom hooks:
 
-**`useContext`** para evitar el "prop-drilling" y datos globales, como el tema de la aplicación, la información del usuario, el estado de autenticación o pasar un reducer para controlar el estado.
+**`useContext`** es para evitar el "prop-drilling" y contiene datos globales para todos los hijos, como el tema de la aplicación, la información del usuario, el estado de autenticación o pasar un reducer para que controla el estado del padre.
 
-**Custom Hooks** para encapsular lógica compleja y reutilizable (como un `useFetchData`), darles una sola responsabilidad, siguiendo el principio de "un solo propósito".
+**Custom Hooks** para encapsular lógica compleja y reutilizable (como un `useFetcher`), darles una sola responsabilidad, siguiendo el principio de "un solo propósito".
 
 ## Fragmentos y Portales
 
-Los **Fragmentos** son un mecanismo de React para agrupar varios elementos hijos sin la necesidad de agregar un nodo extra al DOM, porque aunque la cantidad de nodos en el html importa! y es útil para mantener una estructura semántica y ligera del documento. Usar siempre la sintaxis corta `<>/*contenido del render*/</>`.
+Los **Fragmentos** son un mecanismo de React para agrupar varios elementos hijos sin la necesidad de agregar un nodo extra al DOM, porque la cantidad de nodos en el DOM importa! y es útil para mantener una estructura semántica y ligera del documento. Usar siempre la sintaxis corta `<>{/*contenido del render*/}</>`.
 
 `createPortal` nos permiten renderizar un componente fuera del árbol DOM del componente padre. Son muy útiles para crear elementos como modales, _tooltips_ o notificaciones, que necesitan renderizarse en la parte superior del árbol DOM y nos ayudan a evitar problemas de superposición con otros elementos.
 
@@ -126,7 +125,7 @@ Para mantener el código claro, un handler debe tener una sola responsabilidad,
 
 - **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**: 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 (_breaking changes_) deben hacerse bajo supervisión y al menos una vez al año.
+- **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.
 
@@ -237,7 +236,7 @@ const UserProfile = ({ user }) => {
 };
 ```
 
-**Recuperación**: Después de un fallo, ofrecemos formas claras de recuperación. Botones de "reintentar" o instrucciones para volver a la página de inicio son un buen ejemplo de esto. También, para evitar la sensación de que la aplicación está rota, usamos _skeleton screens_ o _spinners_ para indicar los estados de carga. Esto crea una experiencia fluida y profesional.
+**Recuperación**: Después de un fallo, debemos ofrecer formas claras de recuperación. Botones de "reintentar" o instrucciones para volver a la página de inicio son un buen ejemplo de esto. También, para evitar la sensación de que la aplicación está rota, usamos _skeleton screens_ o _spinners_ para indicar los estados de carga. Esto crea una experiencia fluida y profesional.
 
 ```tsx
 // El botón permite al usuario volver a intentar la operación.
@@ -259,4 +258,3 @@ const FetchDataButton = ({ onRetry }) => {
 
 ---
 [Volver al menú principal](../frontend-structure.md)
-

docs/development-rules/sections/frontend-structure.md

@@ -2,7 +2,13 @@
 
 ## TL;DR
 
-Instale ESLint y Prettier, utilice el config y las reglas de lint suministradas y el default de Prettier.
+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.
 
 ## Índice de Contenidos
 
@@ -42,3 +48,5 @@ Instale ESLint y Prettier, utilice el config y las reglas de lint suministradas
     - [Manejo de errores](./front/5-buenas-practicas-en-react.md#manejo-de-errores)
 6. El CSS deja de ser tan feo cuando lo entiendes (guía en desarrollo)
 
+---
+[Siguiente: Introducción](./1-introduccion.md)