apps/web/src/global.css

@@ -12,7 +12,6 @@ body {
 :root {
   --desk-app-background: #000;
   --desk-content-background: #f7f9fb;
-  --desk-header-background: #fff;
   --desk-sidebar-background: #0e282c;
   --desk-sidebar-top: #0c252a;
   --desk-sidebar-bottom: #102c30;
@@ -28,8 +27,6 @@ body {
   --desk-radius-md: 10px;
   --desk-radius-shell: 20px;
   --desk-sidebar-width: 228px;
-  --desk-sidebar-inset: 20px;
-  --desk-sidebar-collapsed-width: 72px;
   --desk-header-height: 88px;
   --desk-search-height: 41px;
   --desk-nav-height: 48px;
@@ -62,12 +59,9 @@ body:has(.desk-workspace) {
   background: var(--desk-app-background);
 }
 .desk-sidebar {
-  display: flex;
-  flex-direction: column;
-  min-height: 0;
   width: var(--desk-sidebar-width);
   flex: 0 0 var(--desk-sidebar-width);
-  overflow: hidden;
+  overflow-y: auto;
   background: linear-gradient(
     180deg,
     var(--desk-sidebar-top),
@@ -77,7 +71,6 @@ body:has(.desk-workspace) {
   color: var(--desk-sidebar-text);
 }
 .desk-brand {
-  flex-shrink: 0;
   display: flex;
   align-items: center;
   gap: 13px;
@@ -95,13 +88,10 @@ body:has(.desk-workspace) {
   flex-shrink: 0;
 }
 .desk-company-rail {
-  flex: 1;
-  min-height: 0;
-  overflow-y: auto;
   display: flex;
   flex-direction: column;
   gap: 2px;
-  padding: 28px var(--desk-sidebar-inset) 24px;
+  padding: 28px 13px 24px 26px;
 }
 .desk-space-button {
   width: 100%;
@@ -147,7 +137,7 @@ body:has(.desk-workspace) {
 .desk-rail-separator {
   height: 1px;
   background: rgb(255 255 255 / 12%);
-  margin: 26px 0 25px;
+  margin: 26px -3px 25px -5px;
   flex-shrink: 0;
 }
 .desk-catalog-navigation {
@@ -166,58 +156,6 @@ body:has(.desk-workspace) {
   background: rgb(255 255 255 / 8%);
   color: white;
 }
-.desk-sidebar-footer {
-  flex-shrink: 0;
-  display: grid;
-  gap: 2px;
-  padding: 12px var(--desk-sidebar-inset) 20px;
-  border-top: 1px solid rgb(255 255 255 / 12%);
-}
-.desk-sidebar-toggle[aria-expanded="true"] > svg {
-  transform: rotate(180deg);
-}
-.desk-catalog-navigation > button {
-  gap: 10px;
-}
-.desk-catalog-navigation > button > svg {
-  width: 18px;
-  height: 18px;
-  flex-shrink: 0;
-}
-@media (min-width: 768px) {
-  .desk-sidebar[data-collapsed="true"] {
-    width: var(--desk-sidebar-collapsed-width);
-    flex-basis: var(--desk-sidebar-collapsed-width);
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-brand {
-    justify-content: center;
-    padding-left: 0;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-brand > span,
-  .desk-sidebar[data-collapsed="true"] .desk-space-button > span,
-  .desk-sidebar[data-collapsed="true"] .desk-nav-chevron,
-  .desk-sidebar[data-collapsed="true"] .desk-catalog-navigation > button > span {
-    display: none;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-company-rail {
-    padding: 28px 12px 12px;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-sidebar-footer {
-    padding: 12px 12px 20px;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-space-button {
-    justify-content: center;
-    gap: 0;
-    padding: 0;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-catalog-navigation {
-    padding-left: 0;
-  }
-  .desk-sidebar[data-collapsed="true"] .desk-catalog-navigation > button {
-    justify-content: center;
-    padding-inline: 0;
-  }
-}
 .desk-workspace-content {
   flex: 1;
   min-width: 0;
@@ -229,9 +167,7 @@ body:has(.desk-workspace) {
   align-items: center;
   gap: 28px;
   min-height: var(--desk-header-height);
-  padding: 15px 30px 15px 17px;
+  padding: 31px 30px 16px 17px;
-  background: var(--desk-header-background);
-  border-bottom: 1px solid var(--desk-border);
   color: var(--desk-navy);
 }
 .desk-search {
@@ -625,7 +561,7 @@ body:has(.desk-workspace) {
     flex-basis: auto;
   }
   .desk-brand {
-    padding: 2px;
+    padding: 20px;
   }
   .desk-company-rail {
     flex-direction: row;
@@ -709,16 +645,3 @@ body:has(.desk-workspace) {
     padding: 12px;
   }
 }
-
-@media (max-width: 767px) {
-  .desk-company-rail {
-    flex: none;
-    overflow-y: visible;
-  }
-  .desk-sidebar-footer {
-    padding: 10px 16px;
-  }
-  .desk-sidebar-toggle {
-    display: none;
-  }
-}

docs/componentes-de-interfaz.md

@@ -155,13 +155,3 @@ servicio de notificaciones. El perfil usa disclosure nativo con foco visible y
 conserva las acciones de identidad y selección de idioma. No hay primitives Avatar
 ni DropdownMenu instalados; el avatar muestra iniciales del usuario real, sin
 inventar foto ni cargo. Configuración abre un FormDialog con las acciones existentes.
-
-La sidebar global permite contraerse en escritorio de 228px a 72px mediante
-«Contraer menú» / «Expandir menú». Conserva iconos, nombres accesibles y títulos
-de ayuda también para compañías y subcatálogos. La navegación se desplaza por
-separado, manteniendo Configuración y el control de anchura en el pie visible.
-En móvil se conserva la navegación horizontal existente.
-
-El menú expandido y su pie comparten márgenes horizontales de 20px mediante
-`--desk-sidebar-inset`. El header global usa `--desk-header-background` (#FFFFFF),
-con un borde inferior de 1px en `--desk-border`, sobre el contenido #F7F9FB.

docs/prompts/prompt-refactorizacion-general.md

@@ -1,719 +0,0 @@
-# Refactorización general del repositorio
-
-Revisa y refactoriza de forma sistemática todo el código propio del repositorio para que cumpla las buenas prácticas, convenciones, arquitectura y reglas definidas en `AGENTS.md`.
-
-`AGENTS.md` es la referencia normativa principal para esta tarea.
-
-Antes de modificar código:
-
-1. Lee `AGENTS.md` completo.
-2. Lee la documentación de arquitectura y estándares a la que haga referencia.
-3. Comprueba el entorno y estado del repositorio conforme a las instrucciones de `AGENTS.md`.
-4. Realiza una inspección suficientemente amplia del repositorio antes de empezar a modificar archivos.
-5. Identifica la estructura general, paquetes, módulos, dependencias internas, patrones existentes y áreas principales.
-6. Establece un orden razonable de revisión y refactorización.
-
-No empieces a corregir el primer problema que encuentres sin conocer antes suficientemente el contexto general del repositorio.
-
-## Objetivo
-
-El objetivo no es reescribir el proyecto desde cero.
-
-Debes:
-
-- identificar incumplimientos reales de `AGENTS.md`;
-- corregirlos cuando pueda hacerse de forma segura;
-- mejorar claridad, mantenibilidad, tipado, separación de responsabilidades y coherencia;
-- mantener la arquitectura existente;
-- conservar el comportamiento funcional salvo que detectes claramente un bug;
-- evitar cambios puramente cosméticos sin beneficio real;
-- evitar introducir nuevas abstracciones innecesarias.
-
-La tarea consiste en revisar TODO el código propio relevante del repositorio, no únicamente los archivos modificados recientemente.
-
-No te limites a generar un informe de problemas: corrige los problemas que puedan resolverse de forma segura.
-
-No te detengas después de revisar o corregir una única área. Continúa de forma progresiva hasta completar la revisión del código propio relevante del repositorio, salvo que exista un bloqueo real que requiera una decisión del usuario.
-
----
-
-## Código excluido
-
-No revisar, refactorizar, reformatear, reorganizar ni modificar código perteneciente a terceros, código vendor o paquetes que hayan sido incorporados al repositorio como biblioteca externa.
-
-Queda expresamente excluido:
-
-- `packages/shadcn-ui`
-
-Considera `packages/shadcn-ui` código de terceros/vendor aunque forme parte físicamente del monorepo.
-
-No apliques sobre este paquete las reglas de estilo, estructura, TypeScript, React, nombres de fichero, separación de componentes ni ninguna otra refactorización definida en `AGENTS.md`.
-
-No modifiques archivos dentro de `packages/shadcn-ui`, ni siquiera para:
-
-- corregir lint;
-- corregir formato;
-- reducir warnings;
-- cambiar tipos;
-- separar componentes;
-- reorganizar archivos;
-- cambiar imports;
-- eliminar código aparentemente no utilizado;
-- homogeneizarlo con el resto del proyecto.
-
-Puedes consultar únicamente su API pública, exports, componentes y contratos cuando sea necesario para utilizarlo correctamente desde código propio.
-
-Si una validación global falla exclusivamente por código existente dentro de `packages/shadcn-ui`, indícalo claramente en el informe final y no modifiques ese paquete para hacer pasar la validación.
-
-Si durante la revisión aparecen otros directorios claramente correspondientes a código generado, dependencias externas o vendor, no los refactorices salvo que `AGENTS.md` indique expresamente lo contrario.
-
----
-
-## Estrategia de trabajo
-
-Trabaja progresivamente por paquetes, módulos o áreas funcionales coherentes.
-
-Antes de modificar cada área:
-
-1. Examina su estructura.
-2. Identifica sus dependencias y consumidores.
-3. Busca implementaciones equivalentes dentro del repositorio.
-4. Consulta la documentación normativa aplicable.
-5. Identifica los incumplimientos de `AGENTS.md`.
-6. Distingue entre problemas reales y simples preferencias estilísticas.
-7. Determina la solución más pequeña y segura que respete la arquitectura existente.
-
-Después realiza las refactorizaciones necesarias.
-
-No hagas una refactorización masiva sin control.
-
-Después de cada conjunto coherente de cambios:
-
-- revisa el diff;
-- comprueba imports y referencias;
-- comprueba que no has ampliado innecesariamente el alcance;
-- ejecuta las validaciones dirigidas apropiadas;
-- corrige cualquier regresión introducida antes de continuar.
-
-Cuando completes un módulo o área importante, ejecuta las pruebas, typecheck y lint correspondientes cuando resulte razonable.
-
----
-
-# TypeScript
-
-Revisa especialmente:
-
-- usos de `any`;
-- assertions innecesarias;
-- non-null assertions;
-- tipos excesivamente débiles;
-- duplicación de tipos;
-- tipos que puedan derivarse de schemas existentes;
-- uso incorrecto de `Partial`;
-- opcionalidad mal representada;
-- discriminated unions incompletas;
-- `switch` no exhaustivos cuando deberían serlo;
-- casts usados como sustituto de validación;
-- datos externos tratados como confiables sin validación;
-- imports de tipos incorrectos;
-- genéricos innecesarios;
-- aliases sin semántica;
-- estructuras mutables cuando no deberían serlo.
-
-Prioriza:
-
-- `unknown` frente a `any` para datos todavía no validados;
-- narrowing frente a casts;
-- `import type`;
-- discriminated unions;
-- exhaustividad;
-- inferencia cuando sea clara;
-- contratos explícitos cuando formen parte de APIs internas o públicas;
-- schemas como fuente normativa cuando corresponda.
-
-No debilites TypeScript para conseguir que el código compile.
-
-Corrige el origen del problema de tipos siempre que sea posible.
-
----
-
-# Asincronía
-
-Revisa:
-
-- promesas flotantes;
-- `void` usado para descartar promesas;
-- `catch` que ocultan errores;
-- callbacks convertidos incorrectamente a `async`;
-- operaciones asíncronas no esperadas;
-- errores asíncronos ignorados;
-- flujos donde una operación debería devolverse, esperarse o manejar explícitamente su error.
-
-Toda promesa debe:
-
-- esperarse;
-- devolverse;
-- o tener su error gestionado explícitamente.
-
-No ocultes errores para conseguir que el flujo continúe artificialmente.
-
----
-
-# Node.js
-
-Revisa especialmente:
-
-- I/O síncrono dentro del flujo normal del servidor;
-- accesos dispersos a `process.env`;
-- configuración sin validar;
-- recursos externos sin timeout;
-- operaciones cancelables sin mecanismo de cancelación cuando corresponda;
-- estado mutable global dependiente de peticiones;
-- errores de infraestructura silenciados;
-- cierre incorrecto de recursos;
-- responsabilidades mezcladas.
-
-La configuración debe cargarse, validarse y normalizarse en los puntos definidos por la arquitectura.
-
-No disperses lecturas directas de `process.env` por la aplicación.
-
-No bloquees el event loop innecesariamente.
-
----
-
-# Express
-
-Revisa especialmente:
-
-- routers con demasiada lógica;
-- controladores demasiado grandes;
-- lógica de negocio dentro de controladores;
-- acceso directo al ORM desde capas HTTP cuando contradiga la arquitectura;
-- validación insuficiente de `params`, `query`, `headers` y `body`;
-- manejo repetitivo o incorrecto de errores;
-- exposición de información interna;
-- middleware demasiado genérico;
-- middleware con varias responsabilidades;
-- ramas que puedan producir más de una respuesta HTTP;
-- código HTTP mezclado con dominio o persistencia.
-
-Los controladores deben actuar principalmente como adaptadores entre HTTP y la aplicación.
-
-La lógica de negocio debe permanecer en las capas definidas por la arquitectura.
-
-Centraliza el tratamiento de errores según los patrones existentes.
-
-No expongas:
-
-- stack traces;
-- SQL;
-- secretos;
-- credenciales;
-- detalles internos innecesarios.
-
----
-
-# React 19
-
-Revisa todo el código React propio.
-
-Comprueba especialmente:
-
-- componentes demasiado grandes;
-- varios componentes relevantes agrupados en un único fichero;
-- responsabilidades mezcladas;
-- efectos innecesarios;
-- estado redundante;
-- valores derivados almacenados en estado;
-- props copiadas a estado sin necesidad;
-- acceso a datos mezclado con presentación;
-- custom hooks innecesarios;
-- hooks con responsabilidades ambiguas;
-- `useMemo` o `useCallback` utilizados preventivamente;
-- incumplimientos de las Rules of Hooks;
-- efectos secundarios durante render;
-- mutación de props o estado;
-- duplicación de estado remoto gestionado por TanStack Query;
-- carga remota implementada mediante `useEffect`;
-- patrones visuales repetidos que deberían reutilizar componentes existentes.
-
-## Organización de componentes React
-
-Como norma general:
-
-- un fichero `.tsx` debe contener un único componente React principal;
-- no agrupes varios componentes React relevantes en un mismo fichero por comodidad.
-
-Extrae un componente a su propio fichero cuando tenga alguna de estas características:
-
-- props propias;
-- estado;
-- hooks;
-- lógica de interacción;
-- lógica de renderizado significativa;
-- responsabilidad semántica identificable;
-- posibilidad razonable de reutilización;
-- tamaño suficiente para dificultar la lectura del componente principal.
-
-Un subcomponente puede permanecer en el mismo fichero únicamente cuando sea:
-
-- pequeño;
-- puramente presentacional;
-- estrechamente ligado al componente principal;
-- sin lógica relevante;
-- sin estado;
-- sin hooks significativos;
-- y su extracción no mejore realmente la comprensión.
-
-Si un fichero contiene varios subcomponentes privados con responsabilidad propia, reconsidera la estructura y extráelos.
-
-No fragmentes JSX trivial en componentes artificiales simplemente para reducir el número de líneas.
-
-La separación debe basarse en responsabilidades, semántica y mantenibilidad.
-
----
-
-# Diálogos, modales y ventanas emergentes
-
-Durante la revisión identifica todas las ventanas modales, cuadros de diálogo, formularios modales, paneles emergentes y componentes equivalentes.
-
-No te limites a buscar componentes llamados `Dialog` o `FormDialog`.
-
-Revisa especialmente implementaciones construidas mediante:
-
-- `Dialog`;
-- `AlertDialog`;
-- `Sheet`;
-- `Drawer`;
-- `FormDialog`;
-- wrappers propios;
-- cualquier otra primitiva que represente una interacción modal o superpuesta.
-
-Toda ventana modal o cuadro de diálogo con contenido y responsabilidad propios debe extraerse a un componente React independiente y vivir en su propio fichero `.tsx`.
-
-Considera especialmente como componentes independientes los diálogos de:
-
-- alta;
-- edición;
-- eliminación;
-- confirmación;
-- selección;
-- cambio de estado;
-- detalle;
-- ayuda;
-- configuración;
-- asignación;
-- acciones que requieran interacción adicional.
-
-Como norma general, una página o listado no debe contener internamente grandes bloques de JSX correspondientes a diálogos funcionales.
-
-El componente padre debe coordinar:
-
-- apertura;
-- cierre;
-- datos necesarios;
-- callbacks;
-- acciones posteriores.
-
-El componente del diálogo debe encapsular:
-
-- su estructura visual;
-- contenido;
-- formulario cuando corresponda;
-- lógica de interacción propia;
-- estados locales propios.
-
-No mantengas formularios completos ni bloques grandes de `DialogContent` dentro de páginas o listados cuando representen una unidad funcional reconocible.
-
-Un formulario utilizado dentro de un diálogo puede separarse además en otro componente cuando tenga suficiente complejidad, reutilización o responsabilidad propia.
-
-No extraigas mecánicamente un diálogo trivial compuesto únicamente por unas pocas líneas de contenido estático sin lógica, estado, formulario ni responsabilidad propia.
-
----
-
-# Estado y efectos React
-
-Mantén el estado mínimo necesario.
-
-No almacenes en estado valores que puedan calcularse correctamente durante render a partir de:
-
-- props;
-- otro estado;
-- resultados de consultas;
-- constantes;
-- datos derivados.
-
-No utilices `useEffect` para sincronizar estado React con otro estado React cuando el valor pueda derivarse.
-
-No utilices `useEffect` para reaccionar a una acción directa del usuario cuando esa lógica deba ejecutarse desde el event handler correspondiente.
-
-Utiliza efectos para sincronización real con:
-
-- sistemas externos;
-- APIs imperativas;
-- suscripciones;
-- listeners;
-- timers;
-- recursos externos.
-
-Todo efecto que cree recursos debe realizar el cleanup correspondiente.
-
-No introduzcas `useMemo` ni `useCallback` preventivamente.
-
-Úsalos solo cuando exista una necesidad concreta:
-
-- rendimiento demostrado;
-- profiling;
-- estabilidad referencial exigida por un contrato;
-- comportamiento de una dependencia que lo requiera.
-
----
-
-# TanStack Query y acceso a datos
-
-Revisa:
-
-- query keys dispersas;
-- duplicación de estado remoto;
-- invalidaciones excesivamente amplias;
-- `fetch` directo desde componentes cuando exista una capa apropiada;
-- carga remota mediante `useEffect`;
-- funciones de API dependientes de React;
-- mutaciones que no actualicen correctamente la caché;
-- errores de carga no representados;
-- ausencia de estados de carga o vacío.
-
-Mantén las query keys centralizadas conforme a los patrones del proyecto.
-
-Después de una mutación, invalida o actualiza únicamente aquello que realmente se vea afectado.
-
-No invalide indiscriminadamente toda la caché para evitar razonar sobre dependencias.
-
----
-
-# Formularios
-
-Revisa:
-
-- duplicación de validación;
-- estado duplicado;
-- formularios demasiado acoplados a páginas;
-- formularios modales incluidos directamente dentro de grandes componentes;
-- errores de campos mal representados;
-- errores globales mezclados con errores de validación;
-- envíos duplicados;
-- cierres del diálogo antes de confirmar éxito.
-
-Utiliza React Hook Form y Zod conforme a los patrones definidos en el proyecto.
-
-Mantén una única fuente normativa de validación cuando sea posible.
-
-No cierres ni limpies un formulario hasta confirmar correctamente la operación que lo requiera.
-
----
-
-# Componentes visuales y reutilización
-
-Antes de crear un componente nuevo:
-
-1. Busca si ya existe uno equivalente.
-2. Comprueba `@repo/shadcn-ui`.
-3. Revisa componentes compartidos del proyecto.
-4. Busca patrones equivalentes en otras pantallas.
-
-No dupliques estructura, comportamiento ni patrones visuales existentes.
-
-Extrae componentes comunes únicamente cuando exista repetición real o una responsabilidad compartida clara.
-
-Mantén los componentes genéricos independientes de:
-
-- DTO específicos;
-- endpoints;
-- Sequelize;
-- lógica de dominio concreta;
-- detalles internos de Metis Desk,
-
-si esa dependencia no es necesaria para cumplir su función.
-
----
-
-# Estructura de archivos
-
-Revisa:
-
-- archivos excesivamente grandes;
-- archivos con varias responsabilidades;
-- `utils.ts`;
-- `helpers.ts`;
-- `types.ts`;
-- `common.ts`;
-- `constants.ts`;
-
-cuando se hayan convertido en cajones de sastre.
-
-Mantén tipos, constantes y utilidades cerca del dominio o funcionalidad a la que pertenecen.
-
-Muévelos a ubicaciones compartidas únicamente cuando existan consumidores reales en diferentes áreas.
-
-No crees barrels `index.ts` indiscriminadamente.
-
-Evita barrels que:
-
-- oculten dependencias;
-- provoquen ciclos;
-- hagan difícil localizar el origen de un símbolo.
-
-No reorganices directorios únicamente por preferencias personales.
-
----
-
-# Abstracciones
-
-Revisa y evita abstracciones innecesarias como:
-
-- `BaseService`;
-- `BaseRepository`;
-- repositorios genéricos;
-- factories genéricas;
-- wrappers sin valor semántico;
-- clases abstractas sin necesidad;
-- eventos internos sin consumidores reales;
-- contenedores DI innecesarios;
-- genéricos anticipatorios;
-- configuraciones altamente parametrizables sin consumidores reales.
-
-No introduzcas extensibilidad hipotética.
-
-Aplica YAGNI.
-
-Las abstracciones deben aparecer porque exista una necesidad real, no porque puedan resultar útiles en el futuro.
-
----
-
-# Duplicación
-
-Busca duplicación real de:
-
-- lógica;
-- validaciones;
-- transformaciones;
-- componentes;
-- estructuras de formularios;
-- patrones de interacción;
-- consultas;
-- tratamiento de errores.
-
-No elimines duplicación de manera mecánica.
-
-Dos bloques similares no requieren necesariamente una abstracción común si representan conceptos diferentes o evolucionarán de manera independiente.
-
-Extrae únicamente cuando exista una responsabilidad compartida real.
-
----
-
-# Código muerto
-
-Identifica:
-
-- funciones sin uso;
-- componentes sin consumidores;
-- exports innecesarios;
-- tipos obsoletos;
-- código comentado;
-- compatibilidad interna que ya no tenga consumidores;
-- implementaciones duplicadas antiguas.
-
-Antes de eliminar código:
-
-1. busca todas sus referencias en el monorepo;
-2. identifica posibles usos dinámicos;
-3. comprueba tests y documentación;
-4. confirma que no forme parte de un contrato público.
-
-No elimines legado basándote únicamente en una búsqueda superficial.
-
----
-
-# Dependencias
-
-No añadas una dependencia nueva salvo que exista una necesidad clara.
-
-Antes de hacerlo:
-
-1. comprueba APIs nativas;
-2. comprueba dependencias ya instaladas;
-3. comprueba utilidades existentes;
-4. justifica la incorporación.
-
-No reemplaces una dependencia establecida por otra equivalente únicamente por preferencia.
-
-No actualices versiones de dependencias salvo que sea necesario para esta tarea o exista instrucción expresa.
-
----
-
-# Seguridad
-
-Durante la refactorización conserva y mejora cuando corresponda:
-
-- validación de entrada;
-- autenticación;
-- autorización;
-- aislamiento de clientes;
-- consultas parametrizadas;
-- transacciones;
-- restricciones de base de datos;
-- protección de secretos;
-- privacidad de logs;
-- idempotencia.
-
-No confíes en identificadores enviados por el navegador para determinar permisos o pertenencia.
-
-No introduzcas regresiones de seguridad en nombre de simplificar código.
-
----
-
-# Tests
-
-Revisa los tests relacionados con el código refactorizado.
-
-Prioriza tests de comportamiento observable.
-
-No escribas tests únicamente para aumentar cobertura.
-
-Evita tests excesivamente acoplados a detalles internos.
-
-Cuando corrijas un bug reproducible, considera añadir una prueba que:
-
-1. falle con el comportamiento anterior;
-2. pase con la corrección.
-
-Los tests deben ser deterministas.
-
-No introduzcas:
-
-- esperas arbitrarias;
-- sleeps;
-- retries para ocultar inestabilidad;
-- desactivaciones de tests para conseguir que la suite pase.
-
----
-
-# Cambios fuera de alcance
-
-No amplíes una refactorización para corregir indiscriminadamente cualquier problema que encuentres.
-
-Si detectas un problema no relacionado con el área que estás trabajando:
-
-- corrígelo únicamente si es trivial, seguro y necesario para completar correctamente el cambio actual;
-- en caso contrario, déjalo documentado como pendiente.
-
-No hagas reformateos globales ni renombres masivos sin necesidad.
-
-No cambies APIs públicas, contratos HTTP, schemas, persistencia o comportamiento funcional salvo que sea necesario para resolver un problema real.
-
-Si un cambio afecta contratos compartidos:
-
-1. identifica todos los consumidores;
-2. actualízalos conjuntamente;
-3. valida el comportamiento completo.
-
-No mantengas compatibilidad artificial con APIs internas antiguas cuando todos los consumidores puedan actualizarse de forma segura dentro del mismo cambio.
-
----
-
-# Criterios para detener una refactorización concreta
-
-No improvises cuando la corrección requiera:
-
-- una decisión funcional;
-- una decisión arquitectónica significativa;
-- cambios de negocio no documentados;
-- una migración de datos con implicaciones desconocidas;
-- modificar contratos públicos sin poder determinar los consumidores;
-- asumir comportamiento no verificable.
-
-En estos casos deja el problema claramente identificado como pendiente indicando:
-
-- fichero o área;
-- problema encontrado;
-- impacto;
-- motivo por el que no debe corregirse automáticamente;
-- solución recomendada.
-
-Esto no implica detener la revisión completa del repositorio si puedes continuar con otras áreas independientes.
-
----
-
-# Validación
-
-Después de cada conjunto coherente de cambios ejecuta las comprobaciones dirigidas apropiadas.
-
-Al finalizar la refactorización completa ejecuta, como mínimo, las validaciones globales definidas en `AGENTS.md`.
-
-Salvo que `AGENTS.md` indique otra cosa, incluye:
-
-- `pnpm typecheck`
-- `pnpm lint`
-- `pnpm test`
-- `pnpm check`
-- `pnpm build`
-
-No afirmes que una validación ha pasado si no la has ejecutado.
-
-Si una comprobación falla:
-
-1. determina si el fallo ha sido introducido por la refactorización;
-2. corrígelo si es responsabilidad del código propio;
-3. vuelve a ejecutar la comprobación;
-4. si corresponde a código excluido o a un problema previo no relacionado, documenta claramente la causa.
-
----
-
-# Revisión final
-
-Antes de dar la tarea por terminada:
-
-1. Revisa el diff completo.
-2. Comprueba que no se hayan modificado áreas excluidas.
-3. Busca imports no utilizados.
-4. Busca casts añadidos innecesariamente.
-5. Busca supresiones nuevas de TypeScript, lint o Biome.
-6. Comprueba que no haya promesas flotantes.
-7. Comprueba que no hayas añadido `useEffect`, `useMemo` o `useCallback` innecesarios.
-8. Revisa los archivos `.tsx` modificados para detectar varios componentes relevantes en el mismo fichero.
-9. Comprueba que los diálogos funcionales hayan sido extraídos cuando corresponda.
-10. Comprueba que no hayas creado abstracciones sin consumidores reales.
-11. Comprueba que no hayas duplicado tipos, schemas o lógica.
-12. Comprueba que no quede código temporal, comentado o de depuración.
-13. Ejecuta las validaciones finales.
-
----
-
-# Informe final
-
-Al finalizar proporciona un resumen estructurado y concreto indicando:
-
-- áreas y módulos revisados;
-- áreas expresamente excluidas;
-- principales incumplimientos encontrados;
-- principales refactorizaciones realizadas;
-- componentes React extraídos;
-- diálogos o formularios modales extraídos;
-- mejoras relevantes de TypeScript;
-- mejoras de Node.js/Express;
-- duplicaciones eliminadas;
-- código muerto eliminado;
-- archivos o módulos especialmente modificados;
-- tests añadidos o modificados;
-- comandos ejecutados;
-- resultado de cada validación;
-- problemas detectados que hayan quedado pendientes;
-- decisiones que requieran revisión humana.
-
-No afirmes:
-
-- haber revisado un área que no hayas inspeccionado;
-- haber corregido un problema que siga presente;
-- haber ejecutado una comprobación que no hayas ejecutado.
-
-El resultado debe dejar el código propio del repositorio progresivamente alineado con `AGENTS.md`, manteniendo el comportamiento existente y evitando refactorizaciones especulativas.

modules/companies/src/web/components/workspace-sidebar.tsx

@@ -1,19 +1,14 @@
 import { Button } from "@repo/shadcn-ui/components/button";
 import {
-  BoxIcon,
   Building2Icon,
   ChevronRightIcon,
   DatabaseIcon,
   HomeIcon,
-  KeyRoundIcon,
-  LayersIcon,
-  LayoutTemplateIcon,
   SettingsIcon,
   TicketIcon,
   WrenchIcon,
 } from "@repo/shadcn-ui/lib/icons";
 import type { ComponentProps } from "react";
-import { useState } from "react";
 import { useTranslation } from "react-i18next";
 
 import type { WorkspaceContent } from "./workspace-content";
@@ -40,10 +35,9 @@ export function WorkspaceSidebar({
   const { t: resourceTranslation } = useTranslation("resources");
   const { t: assetTranslation } = useTranslation("assets");
   const { t: accessTranslation } = useTranslation("access");
-  const [collapsed, setCollapsed] = useState(false);
   return (
-    <aside className="desk-sidebar" data-collapsed={collapsed}>
+    <aside className="desk-sidebar">
-      <div aria-label="Metis Desk" className="desk-brand" role="img">
+      <div className="desk-brand">
         <svg aria-hidden="true" viewBox="0 0 36 30">
           <path
             d="M5 24 13 7l9 17 9-18"
@@ -72,7 +66,6 @@ export function WorkspaceSidebar({
             className="desk-space-button"
             key={area}
             onClick={() => onNavigate({ area })}
-            title={t(label)}
             variant="ghost"
           >
             <Icon aria-hidden="true" />
@@ -86,58 +79,47 @@ export function WorkspaceSidebar({
           <nav aria-label={t("globalCatalogs")} className="desk-catalog-navigation">
             <>
               <Button
-                aria-label={accessTranslation("catalogTitle")}
                 aria-pressed={catalog === "access"}
                 onClick={() => onSelectCatalog("access")}
-                title={accessTranslation("catalogTitle")}
                 variant="ghost"
               >
-                <KeyRoundIcon aria-hidden="true" />
+                {accessTranslation("catalogTitle")}
-                <span>{accessTranslation("catalogTitle")}</span>
               </Button>
               <Button
-                aria-label={assetTranslation("title")}
                 aria-pressed={catalog === "assets"}
                 onClick={() => onSelectCatalog("assets")}
-                title={assetTranslation("title")}
                 variant="ghost"
               >
-                <BoxIcon aria-hidden="true" />
+                {assetTranslation("title")}
-                <span>{assetTranslation("title")}</span>
               </Button>
               <Button
-                aria-label={t("interventionTemplates.title")}
                 aria-pressed={catalog === "intervention-templates"}
                 onClick={() => onSelectCatalog("intervention-templates")}
-                title={t("interventionTemplates.title")}
                 variant="ghost"
               >
-                <LayoutTemplateIcon aria-hidden="true" />
+                {t("interventionTemplates.title")}
-                <span>{t("interventionTemplates.title")}</span>
               </Button>
               <Button
-                aria-label={assetTranslation("brands.title")}
                 aria-pressed={catalog === "brands"}
                 onClick={() => onSelectCatalog("brands")}
-                title={assetTranslation("brands.title")}
                 variant="ghost"
               >
-                <LayersIcon aria-hidden="true" />
+                {assetTranslation("brands.title")}
-                <span>{assetTranslation("brands.title")}</span>
               </Button>
               <Button
-                aria-label={resourceTranslation("title")}
                 aria-pressed={catalog === "resources"}
                 onClick={() => onSelectCatalog("resources")}
-                title={resourceTranslation("title")}
                 variant="ghost"
               >
-                <DatabaseIcon aria-hidden="true" />
+                {resourceTranslation("title")}
-                <span>{resourceTranslation("title")}</span>
               </Button>
             </>
           </nav>
         )}
+        <Button className="desk-space-button" onClick={onSettings} variant="ghost">
+          <SettingsIcon aria-hidden="true" />
+          <span>{coreTranslation("shell.settings")}</span>
+        </Button>
         <div className="desk-rail-separator" />
         {companies.map((company) => (
           <Button
@@ -154,29 +136,6 @@ export function WorkspaceSidebar({
           </Button>
         ))}
       </nav>
-      <footer className="desk-sidebar-footer">
-        <Button
-          aria-label={coreTranslation("shell.settings")}
-          className="desk-space-button"
-          onClick={onSettings}
-          title={coreTranslation("shell.settings")}
-          variant="ghost"
-        >
-          <SettingsIcon aria-hidden="true" />
-          <span>{coreTranslation("shell.settings")}</span>
-        </Button>
-        <Button
-          aria-expanded={!collapsed}
-          aria-label={coreTranslation(collapsed ? "shell.expandSidebar" : "shell.collapseSidebar")}
-          className="desk-space-button desk-sidebar-toggle"
-          onClick={() => setCollapsed((value) => !value)}
-          title={coreTranslation(collapsed ? "shell.expandSidebar" : "shell.collapseSidebar")}
-          variant="ghost"
-        >
-          <ChevronRightIcon aria-hidden="true" />
-          <span>{coreTranslation("shell.collapseSidebar")}</span>
-        </Button>
-      </footer>
     </aside>
   );
 }

modules/core/src/common/locales/en.json

@@ -24,8 +24,6 @@
     "searchScope": "Search available companies and sections.",
     "notificationsUnavailable": "Notifications: service not yet available",
     "profile": "User menu",
-    "supportWorkspace": "Support workspace",
+    "supportWorkspace": "Support workspace"
-    "collapseSidebar": "Collapse menu",
-    "expandSidebar": "Expand menu"
   }
 }

modules/core/src/common/locales/es.json

@@ -24,8 +24,6 @@
     "searchScope": "Buscar en compañías y secciones disponibles.",
     "notificationsUnavailable": "Notificaciones: servicio todavía no disponible",
     "profile": "Menú de usuario",
-    "supportWorkspace": "Espacio de soporte",
+    "supportWorkspace": "Espacio de soporte"
-    "collapseSidebar": "Contraer menú",
-    "expandSidebar": "Expandir menú"
   }
 }