# Auditoría de sistema de diseño Inventaría con qué está construida de verdad una interfaz y reporta la distancia entre eso y el sistema que dice documentar. ## Entregable Un documento Markdown, `design-system-audit.md`, con la estructura fijada en **Salida** más abajo. Se lee junto a **Auditoría de accesibilidad** y es la entrada de cualquier consolidación posterior. ## Entradas obligatorias - **Acceso a aquello con lo que está construida la interfaz** — hojas de estilo, código de componentes o los archivos de diseño de los que sale la construcción. Algo de lo que se pueda leer un valor. - **El sistema documentado, o la declaración de que no existe** — la deriva se reporta contra una referencia, y una referencia que nadie enunció no lo es. - **El límite de la auditoría** — qué producto, qué superficies y qué rama entran. Si falta el acceso, detente y repórtalo. Un inventario armado con capturas o de memoria registra impresiones, no valores. ## Entradas opcionales - Definiciones de tokens, variables o temas, estén donde estén declaradas - Datos de uso que muestren qué componentes se renderizan y con qué frecuencia - La salida de la construcción o un grafo de dependencias que muestre qué importa qué - Los temas, plataformas y densidades que el sistema debe cubrir - Auditorías anteriores y las decisiones que produjeron - Las personas que mantienen el sistema y lo que ya saben que está mal Las entradas opcionales ausentes reducen lo que la auditoría puede afirmar, no cómo reporta. Un componente cuyo uso no se puede contar se registra como `uso desconocido`, nunca como sin usar. ## Ejecución **1 — Fijar y registrar el límite.** Lista los archivos, directorios y archivos de diseño que se leyeron, y los que estaban dentro del alcance pero no se pudieron alcanzar. Todo lo que viene después es una afirmación sobre esa lista y sobre nada más ancho. **2 — Inventariar los valores.** Reúne cada valor de color, tipografía, espaciado y radio que aparezca, con el archivo en el que se encontró. Cuenta los valores distintos de cada eje. La cuenta es el hallazgo: un eje con un solo valor y un eje con muchos son problemas distintos. **3 — Separar tokens de casos sueltos.** Por cada valor: definido de forma central y referenciado, escrito a mano donde coincide con un token definido, o escrito a mano donde no coincide con nada. Lo segundo es deriva; lo tercero es una incorporación sin documentar. Registra cada sitio donde se usa. **4 — Inventariar los componentes.** Nombre, dónde se define, dónde se usa y cuántos usos tiene. Un componente sin usos está muerto. Uno con un solo uso es candidato a absorberse, y se registra así en lugar de condenarse. **5 — Encontrar los duplicados.** Componentes que hacen el mismo trabajo con nombres distintos. Por cada pareja o grupo: qué comparten, qué difiere y qué tendría que conservar de cada uno una fusión. Una diferencia que nadie sabe explicar es en sí misma un hallazgo. **6 — Comparar el sistema construido con el documentado.** Tres listas: documentado pero no construido, construido pero no documentado, y presente en ambos pero divergente. Donde divergen, el valor construido es el que recibe la gente y se etiqueta así. **7 — Ordenar las candidaturas de consolidación.** Ordénalas por cuántos sitios de uso toca el cambio, según las cuentas de los pasos 3 y 4, y declara qué rompería cada una. No recomiendes una fusión cuyo alcance no se pudo contar. ## Salida `design-system-audit.md`, en este orden: - **1. Alcance y fecha** — qué se leyó, qué estaba dentro pero fue inalcanzable, y cuándo - **2. Inventario de valores** — por eje: los valores encontrados, cuántos son distintos y el archivo del que salió cada uno - **3. Tokens y casos sueltos** — por valor: `token`, `coincidencia escrita a mano` o `sin documentar`, con cada sitio donde se usa - **4. Inventario de componentes** — nombre, dónde se define, número de usos o `uso desconocido`, y `en uso`, `uso único` o `muerto` - **5. Duplicados** — los componentes que hacen un mismo trabajo, qué difiere, qué debe conservar una fusión - **6. Deriva** — documentado pero no construido, construido pero no documentado, presente en ambos pero divergente - **7. Candidaturas de consolidación** — ordenadas por sitios de uso afectados, cada una con lo que rompería - **8. Información que falta** — qué no se pudo contar ni localizar, y quién puede aportarlo ## Validación La auditoría está lista cuando se cumple todo esto: - Cada hallazgo cita el archivo en el que se encontró - Cada valor de la sección 2 está clasificado en la sección 3 - Cada componente de la sección 4 lleva un número de usos o `uso desconocido` - Un valor o componente sin usos se reporta como muerto, no como infracción - La sección 6 nombra la referencia con la que comparó, o registra que no se aportó ninguna - La sección 1 lista lo que quedó fuera de alcance con la misma claridad que lo leído Falla la ejecución si aparece un hallazgo sin archivo detrás, o si aparece una cuenta que la lectura del material aportado no produjo. ## Gestión de fallos - **Sin acceso al código fuente** — detente. Informa de que no hay nada que inventariar y de que auditar capturas es revisar apariencias. - **Sin sistema documentado** — produce las secciones 1 a 5 y 7, y marca la sección 6 como `sin referencia aportada`. Reporta el sistema construido como la referencia de hecho y nombra a quién tendría que adoptarla. - **Los archivos de diseño y la construcción no coinciden** — registra ambos valores, nombra ambas fuentes y eleva la divergencia a la sección 8. Etiqueta el valor construido como el que recibe la gente; no los promedies. - **El uso no se puede contar** — marca el componente como `uso desconocido` y déjalo fuera de la sección 7. Un componente sin contar nunca se reporta como muerto. - **Acceso parcial** — audita lo alcanzable, marca el resto como `SIN AUDITAR — ` y declara que una superficie sin auditar no es una superficie limpia.