Backlog v3.3

Derivado de 63 fricciones registradas al construir 6 pantallas reales (CRM, ajustes, checkout, ERP denso, formulario móvil, dashboard del cluster) consumiendo el sistema como un adoptante. Origen: stress sintético (agentes, no usuarios humanos) — pero los huecos hallados son reales. Detalle por pantalla en docs/fricciones-stress/*.md.

Hallazgo central

El sistema está más especificado que implementado: el catálogo §8 describe 20 componentes, pero @meridiano/componentes empaqueta 8. Cada pantalla tuvo que reconstruir a mano lo que el documento ya promete. La brecha no es de diseño — es de implementación. Cerrarla sube D3 (componentes) de forma decisiva.

Convergencia (fricciones que aparecieron en 2+ pantallas)

Fricciones de documentación (no de código)

• Token terciario como texto pequeño: 3 pantallas (CRM, checkout, móvil) lo eligieron y falló APCA. El sistema ya lo dice (§7.1: "solo texto grande o decorativo") pero no es evidente desde el nombre. → Añadir aviso en la doc del token y, mejor, exponer texto-terciario con scope restringido.
• Objetivo táctil 44px vs --control 40px: en móvil los componentes quedan bajo el mínimo WCAG 2.5.8. → Regla: en móvil forzar densidad espaciosa o min-height: 44px en los componentes interactivos.

Lo que funcionó sin fricción (madurez confirmada)

• Tokens y tema oscuro: re-mapeo semántico impecable en las 6 pantallas.
• m-boton con estado cargando/aria-busy: encajó directo en "Procesando pago…".
• m-modal: foco atrapado, Escape y retorno verificados en CRM, checkout y ajustes.
• m-toast con "Deshacer", m-badge (APCA validado), m-switch (evento cambio = guardado inmediato).
• La regla global :focus-visible de los tokens cubrió incluso los controles improvisados.
• axe: 0 violaciones serias/críticas en las 6 pantallas, en claro y oscuro — los contrastes que aparecieron eran del consumidor eligiendo mal el token, no del sistema.

Plan de cierre (próxima versión)

1. v3.3 — Implementar la brecha §8: ✅ HECHO — m-tabla, m-select, m-radio, m-checkbox, m-tabs, m-pasos, m-banner, m-progreso implementados con pruebas axe en verde (@meridiano/componentes@0.2.0).
2. v3.3 — Componentes de layout: ✅ HECHO — m-barra-lateral, m-barra-superior, m-fab (§12, §8.18).
3. v3.2.x — Endurecer lo existente: pendiente — densidad real en componentes, min-height táctil en móvil, API de validación de m-campo, ancho de modal por variante.
4. Doc: pendiente — aviso en token terciario; regla táctil móvil en §15.

Estado tras v3.3

De los 12 huecos convergentes de alta/media severidad, 10 quedan cubiertos por los nuevos componentes. Restan los de endurecimiento (punto 3) y documentación (punto 4) para una v3.3.x. La brecha "especificado vs implementado" pasó de 8/20 a 19/20 componentes del §8 empaquetados.

Control de cambios