System Requirements Document for space-diagramas

1. Introduction

space-diagramas es una aplicación web SPA construida con React y desplegada en Netlify que entrega un diagrama de arquitectura del Sistema de Gestión de Entregas para Estafeta. El producto no gestiona entregas: su propósito es representar visualmente, de forma clara y con flechas de flujo de datos, la arquitectura técnica del sistema de entregas, de modo que cualquier persona que abra el sitio desde un navegador web o un celular entienda de un vistazo cómo se conectan las capas del sistema.

La audiencia es el propio equipo del Sistema de Gestión de Entregas para Estafeta (y cualquier lector técnico que necesite el plano): una persona que entra al sitio servido por la CDN de Netlify y necesita leer, sin ambigüedad, qué componentes existen, cuáles son opcionales o futuros, y en qué dirección viajan los datos entre ellos.

El diagrama debe representar exactamente estos elementos:

1. Usuario (navegador web o celular).
2. Frontend: React SPA alojado en Netlify con CDN global.
3. Backend opcional: Node.js con Express (para futuras funcionalidades).
4. Base de datos: Firestore (NoSQL) o MongoDB.
5. Servicios externos: GitHub (control de versiones) y API de rastreo de Estafeta (futuro).

Y debe mostrar el flujo: el usuario entra al sitio desde su navegador, el frontend se sirve desde la CDN de Netlify, y cuando se necesita consultar datos se hace una petición al backend que a su vez consulta la base de datos.

2. System Overview

space-diagramas es una SPA React servida como sitio estático desde la CDN global de Netlify. Su contenido es un plano de arquitectura interactivo y legible del Sistema de Gestión de Entregas para Estafeta, compuesto por nodos codificados por color y conectados por líneas ortogonales con flechas que indican la dirección del flujo de datos.

Actores actuales

• Usuario del Sistema de Gestión de Entregas (persona humana, única en el catálogo activo): accede desde navegador web o celular, entra al sitio servido por la CDN de Netlify y lee el diagrama para comprender la arquitectura y el flujo de datos.

Comportamiento aceptado (resumen)

• Presentar el diagrama con los cinco grupos de componentes solicitados.
• Trazar el flujo de datos con flechas: Usuario → CDN Netlify → React SPA → (Backend opcional Node.js/Express) → Base de datos, con GitHub y la API de rastreo de Estafeta anclados como servicios externos.
• Distinguir visualmente lo opcional/futuro (backend Node.js/Express y API de rastreo de Estafeta) de lo activo (frontend React en Netlify, base de datos).
• Mantener el diagrama claro y legible en escritorio y en móvil.

Exclusiones y límites

• El backend Node.js con Express es opcional y está destinado a futuras funcionalidades; no es un componente activo del sistema actual.
• La API de rastreo de Estafeta se representa como servicio externo futuro.
• La base de datos se representa como Firestore (NoSQL) o MongoDB (alternativas), no como una elección cerrada.
• GitHub se representa únicamente como servicio externo de control de versiones.
• El producto no implementa la gestión de entregas, el rastreo real, ni el backend: solo representa su arquitectura.

2a. Product Interpretation and Delivery Boundary

Qué es este producto. space-diagramas es una herramienta de comunicación técnica: un sitio que muestra el diagrama de arquitectura del Sistema de Gestión de Entregas para Estafeta. El entregable es el plano, no el sistema representado.

Titularidad de la entrega. La aplicación es una SPA React propia, desplegada en Netlify y servida desde su CDN global. Todo el contenido del diagrama vive en el frontend; no se requiere backend propio para que el diagrama se muestre. El backend Node.js/Express aparece en el diagrama como componente opcional y futuro, no como parte desplegada de space-diagramas.

Acceso. Ambas superficies son de acceso público y anónimo: no se requiere cuenta, inicio de sesión ni identidad de aplicación para ver el diagrama. No hay estado privado por usuario que conservar, ni compromisos, decisiones o transferencias de valor que deban quedar ligados a un participante concreto; por tanto no se establece identidad de aplicación.

Frontera actual / futura.

• Actual: el sitio React en Netlify con CDN global, el diagrama con sus nodos y flechas, y la representación de la base de datos (Firestore o MongoDB) y de GitHub como servicio externo.
• Futuro / opcional (representado, no implementado): el backend Node.js con Express para futuras funcionalidades y la API de rastreo de Estafeta. Ambos se dibujan como rutas ya trazadas pero no activas.

2c. Page Content and Component Coverage

Landing

• Información y estado: portada del plano. Titular de tres líneas —«SISTEMA DE GESTIÓN / DE ENTREGAS / ESTAFETA»— con la última palabra sangrada a la derecha y subrayada por una regla roja de 6px que corre hasta el borde del viewport. Franja de metadatos en micro-mayúsculas separada por reglas verticales: «REACT SPA · NETLIFY CDN · NODE/EXPRESS (OPCIONAL) · FIRESTORE | MONGODB». El 60% inferior de la pantalla es el diagrama mismo empezando a dibujarse, con la capa USUARIO ya visible arriba.
• Acciones primarias: desplazarse hacia abajo para que el diagrama se trace (las flechas se dibujan de origen a destino al entrar en vista); abrir la página Architecture Diagram para leer el plano completo.
• Acciones de apoyo: conmutar las líneas guía de la rejilla de 12 columnas (visibles al 6% de opacidad); consultar la leyenda de señalética fija en la esquina inferior derecha.
• Entidades de dominio: nodo de arquitectura (capa, nombre de componente, tecnología, metadatos), conector de flujo (origen, destino, dirección), código de color de categoría.
• Responsabilidades de componentes:
  • Cabecera de portada: titular Archivo Black a clamp(44px, 9vw, 128px), sangrado de «ESTAFETA» y regla roja de 6px.
  • Franja de metadatos: micro-etiquetas de 11px en mayúsculas, separadas por reglas verticales de 1px.
  • Lienzo de diagrama inicial: capa USUARIO visible y primeras flechas trazándose hacia abajo.
  • Leyenda de señalética: tabla de color-código fija en la esquina inferior derecha (rojo = frontend, amarillo = backend opcional y API futura, verde = base de datos, azul = servicios externos).
  • Conmutador de rejilla: control que muestra u oculta las guías de columna.
• Estados:
  • Carga: la capa USUARIO y la franja de metadatos se pintan de inmediato; las flechas se trazan en 180ms lineales con 60ms de desfase.
  • Vacío: no aplica; la portada siempre tiene titular, metadatos y capa USUARIO.
  • Éxito: el usuario lee el titular y ve la primera capa del diagrama con sus flechas trazadas.
  • Error / recuperación: si el trazado animado no se ejecuta, el diagrama se muestra ya dibujado (estado estático completo); con prefers-reduced-motion todas las rutas aparecen ya dibujadas.
  • Continuación: desplazamiento hacia abajo o salto a Architecture Diagram.

Architecture Diagram

• Información y estado: el plano completo del Sistema de Gestión de Entregas para Estafeta. Banda central de 8 columnas con las capas apiladas verticalmente en orden de flujo: Usuario → CDN Netlify → React SPA → Backend (opcional, en banda punteada) → Base de datos, con GitHub y API de rastreo de Estafeta anclados como columnas laterales de servicio. Cada nodo es una tarjeta-rectángulo con código de color en el borde superior de 4px, nombre del componente en mayúsculas, tecnología en cuerpo menor y una fila de metadatos alineada a la derecha (puerto, protocolo, estado). Reglas horizontales de 1px separan capas y llevan un rótulo de capa a la izquierda en micro-mayúsculas. Banda punteada de «FUTURO / OPCIONAL» que atraviesa el diagrama entre el frontend y la base de datos.
• Acciones primarias: leer el diagrama y seguir las flechas de flujo de datos; pasar el cursor sobre un nodo para resaltar sus rutas conectadas.
• Acciones de apoyo: consultar la leyenda de señalética (que resalta la fila correspondiente al pasar sobre cualquier nodo); conmutar las líneas guía de la rejilla.
• Entidades de dominio: nodo de arquitectura con categoría (usuario, frontend, backend opcional, base de datos, servicio externo), conector de flujo con dirección, banda de estado futuro/opcional, fila de metadatos (tecnología / protocolo / estado).
• Responsabilidades de componentes:
  • Nodo Usuario: círculo-pictograma (navegador web o celular) como origen del flujo.
  • Nodo Frontend: React SPA alojado en Netlify con CDN global; borde superior rojo #D62828; metadatos de tecnología, protocolo y estado.
  • Nodo Backend opcional: Node.js con Express para futuras funcionalidades; borde superior amarillo #F2B705; dentro de la banda punteada «FUTURO / OPCIONAL».
  • Nodo Base de datos: Firestore (NoSQL) o MongoDB, presentados como alternativas; borde superior verde #1B7F5A; pictograma de cilindro.
  • Nodo GitHub: servicio externo de control de versiones; borde superior azul #1D4E9B; pictograma de rombo.
  • Nodo API de rastreo de Estafeta: servicio externo futuro; borde superior amarillo #F2B705; dentro de la banda punteada.
  • Conectores: líneas ortogonales con quiebres de 90° y ángulos redondeados a 6px, terminadas en flechas triangulares sólidas de 8×10px.
  • Rótulos de capa: micro-mayúsculas de 11px a la izquierda de cada regla horizontal.
  • Leyenda de señalética: tabla fija de color-código en la esquina inferior derecha.
• Estados:
  • Carga: las flechas de flujo se dibujan de origen a destino en 180ms lineales, una tras otra con 60ms de desfase (efecto de ruta trazándose).
  • Vacío: no aplica; el diagrama siempre contiene los cinco grupos de componentes solicitados.
  • Éxito: el usuario lee el flujo completo Usuario → CDN Netlify → React SPA → Backend (opcional) → Base de datos, con GitHub y API de rastreo de Estafeta como servicios externos, y distingue lo activo de lo futuro/opcional.
  • Error / recuperación: si una ruta no se anima, se muestra ya dibujada; con prefers-reduced-motion todas las rutas aparecen ya dibujadas y el resaltado es un cambio de opacidad instantáneo.
  • Continuación: el usuario vuelve a Landing o permanece en el plano para releerlo.
  • Responsive: a 375px la rejilla colapsa a una columna y el diagrama se vuelve una secuencia vertical con flechas hacia abajo, cada nodo a ancho completo y sus metadatos apilados.

3. Functional Requirements

FR-1 — Generar el diagrama de arquitectura del Sistema de Gestión de Entregas para Estafeta As a Usuario del Sistema de Gestión de Entregas, I should ver un diagrama de arquitectura del Sistema de Gestión de Entregas para Estafeta so that comprenda de un vistazo cómo está compuesto el sistema.

• Provenance: explicit.
• Trigger / input: el usuario abre el sitio desde su navegador web o celular.
• Observable result: se muestra un diagrama de arquitectura del Sistema de Gestión de Entregas para Estafeta.
• Access state: público, sin identidad de aplicación.
• Failure / recovery: si el diagrama no se renderiza, se ofrece el plano en estado estático completo.
• Continuation: el usuario lee el diagrama y navega entre sus capas.

FR-2 — Representar el Usuario (navegador web o celular) As a Usuario del Sistema de Gestión de Entregas, I should ver el nodo Usuario (navegador web o celular) en el diagrama so that identifique el punto de origen del flujo.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: el nodo Usuario aparece como origen del flujo, con pictograma de círculo.
• Access state: público.
• Failure / recovery: el nodo se muestra en estado estático si la animación no se ejecuta.
• Continuation: el usuario sigue la flecha hacia la CDN de Netlify.

FR-3 — Representar el Frontend React SPA alojado en Netlify con CDN global As a Usuario del Sistema de Gestión de Entregas, I should ver el nodo Frontend: React SPA alojado en Netlify con CDN global so that entienda dónde se sirve la aplicación.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: el nodo Frontend aparece con su tecnología (React SPA), su alojamiento (Netlify) y su CDN global, codificado en rojo #D62828.
• Access state: público.
• Failure / recovery: el nodo se muestra en estado estático si la animación no se ejecuta.
• Continuation: el usuario sigue la flecha hacia el backend opcional o hacia la base de datos.

FR-4 — Representar el Backend opcional Node.js con Express para futuras funcionalidades As a Usuario del Sistema de Gestión de Entregas, I should ver el nodo Backend opcional: Node.js con Express (para futuras funcionalidades) so that distinga que no es un componente activo del sistema actual.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: el nodo Backend aparece marcado como opcional y futuro, codificado en amarillo #F2B705 y dentro de la banda punteada «FUTURO / OPCIONAL».
• Access state: público.
• Failure / recovery: el nodo se muestra en estado estático si la animación no se ejecuta.
• Continuation: el usuario sigue la flecha hacia la base de datos.

FR-5 — Representar la Base de datos Firestore (NoSQL) o MongoDB As a Usuario del Sistema de Gestión de Entregas, I should ver el nodo Base de datos: Firestore (NoSQL) o MongoDB so that entienda qué almacenamiento consulta el sistema.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: el nodo Base de datos aparece con ambas alternativas (Firestore NoSQL / MongoDB), codificado en verde #1B7F5A.
• Access state: público.
• Failure / recovery: el nodo se muestra en estado estático si la animación no se ejecuta.
• Continuation: el usuario cierra el recorrido del flujo de datos.

FR-6 — Representar los servicios externos GitHub y API de rastreo de Estafeta As a Usuario del Sistema de Gestión de Entregas, I should ver los nodos GitHub (control de versiones) y API de rastreo de Estafeta (futuro) como servicios externos so that identifique qué depende de terceros.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: GitHub aparece como servicio externo de control de versiones (azul #1D4E9B) y la API de rastreo de Estafeta como servicio externo futuro (amarillo #F2B705, dentro de la banda punteada).
• Access state: público.
• Failure / recovery: los nodos se muestran en estado estático si la animación no se ejecuta.
• Continuation: el usuario consulta la leyenda para confirmar la categoría de cada servicio.

FR-7 — Mostrar el flujo de datos con flechas As a Usuario del Sistema de Gestión de Entregas, I should ver flechas que indiquen la dirección del flujo de datos entre los componentes so that lea el recorrido sin ambigüedad.

• Provenance: explicit.
• Trigger / input: carga del diagrama y desplazamiento del usuario.
• Observable result: flechas triangulares sólidas de 8×10px sobre líneas ortogonales con quiebres de 90° conectan los nodos en la dirección del flujo.
• Access state: público.
• Failure / recovery: con prefers-reduced-motion todas las rutas aparecen ya dibujadas.
• Continuation: el usuario sigue el recorrido completo del flujo.

FR-8 — Representar el flujo: usuario entra → frontend servido por la CDN de Netlify As a Usuario del Sistema de Gestión de Entregas, I should ver que el usuario entra al sitio desde su navegador y que el frontend se sirve desde la CDN de Netlify so that entienda el primer tramo del flujo.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: una flecha conecta el nodo Usuario con el nodo Frontend/CDN de Netlify.
• Access state: público.
• Failure / recovery: la ruta se muestra ya dibujada si la animación no se ejecuta.
• Continuation: el usuario continúa hacia el tramo de consulta de datos.

FR-9 — Representar el flujo: petición al backend que consulta la base de datos As a Usuario del Sistema de Gestión de Entregas, I should ver que, cuando se necesita consultar datos, se hace una petición al backend que a su vez consulta la base de datos so that entienda el tramo de consulta de datos.

• Provenance: explicit.
• Trigger / input: carga del diagrama.
• Observable result: una flecha conecta el frontend con el backend (opcional) y otra conecta el backend con la base de datos.
• Access state: público.
• Failure / recovery: la ruta se muestra ya dibujada si la animación no se ejecuta.
• Continuation: el usuario completa la lectura del flujo de datos.

FR-10 — Mantener el diagrama claro y legible As a Usuario del Sistema de Gestión de Entregas, I should leer el diagrama con claridad en escritorio y en móvil so that no tenga que interpretar ambigüedades.

• Provenance: explicit.
• Trigger / input: apertura del sitio en cualquier viewport.
• Observable result: nodos, rótulos de capa, metadatos y leyenda permanecen legibles; a 375px la rejilla colapsa a una columna y el diagrama se vuelve una secuencia vertical con flechas hacia abajo.
• Access state: público.
• Failure / recovery: el texto y los controles permanecen completos dentro del viewport y de su contenedor en 375px, 768px y 1280px.
• Continuation: el usuario relee el plano o vuelve a Landing.

FR-11 — Distinguir visualmente lo activo de lo opcional/futuro As a Usuario del Sistema de Gestión de Entregas, I should distinguir de un vistazo qué componentes están activos y cuáles son opcionales o futuros so that no confunda el estado real del sistema.

• Provenance: explicit (derivado de las restricciones de backend opcional y API futura).
• Trigger / input: carga del diagrama.
• Observable result: la banda punteada «FUTURO / OPCIONAL» atraviesa el diagrama entre el frontend y la base de datos, marcando el backend Node/Express y la API de rastreo de Estafeta como rutas no activas pero ya trazadas; la leyenda asigna amarillo a backend opcional y API futura.
• Access state: público.
• Failure / recovery: la banda y la leyenda se muestran en estado estático si la animación no se ejecuta.
• Continuation: el usuario consulta la leyenda para confirmar cada categoría.

FR-12 — Resaltar rutas conectadas al pasar el cursor sobre un nodo As a Usuario del Sistema de Gestión de Entregas, I should ver resaltadas las rutas conectadas a un nodo al pasar el cursor sobre él so that aísle un tramo del flujo.

• Provenance: explicit (dirección creativa).
• Trigger / input: hover sobre un nodo.
• Observable result: el borde superior de color del nodo se expande a todo el borde, las rutas conectadas se resaltan y el resto baja a 30% de opacidad; la leyenda resalta la fila correspondiente.
• Access state: público.
• Failure / recovery: con prefers-reduced-motion el resaltado es un cambio de opacidad instantáneo.
• Continuation: el usuario retira el cursor y el diagrama vuelve a su estado completo.

4. User Personas

Usuario del Sistema de Gestión de Entregas

• Contexto de producto: persona que trabaja con o sobre el Sistema de Gestión de Entregas para Estafeta y necesita comprender su arquitectura técnica. Accede desde un navegador web o un celular, entra al sitio servido por la CDN de Netlify y consulta el plano de arquitectura.
• Objetivo principal: entender de un vistazo cómo se compone el sistema y en qué dirección fluyen los datos entre el usuario, el frontend React en Netlify, el backend opcional Node.js/Express, la base de datos Firestore o MongoDB y los servicios externos GitHub y API de rastreo de Estafeta.
• Responsabilidades aceptadas: abrir el sitio desde navegador o celular; leer el diagrama y seguir las flechas de flujo de datos; distinguir los componentes activos de los opcionales/futuros; consultar la leyenda de color-código; pasar el cursor sobre un nodo para aislar sus rutas conectadas; releer el plano en móvil como secuencia vertical.
• Entradas y decisiones: decide qué tramo del flujo leer primero y si necesita aislar un nodo mediante hover; interpreta la banda punteada «FUTURO / OPCIONAL» como estado no activo.
• Interacción con otros participantes: es el único participante humano del catálogo activo. Los componentes del diagrama (frontend, backend opcional, base de datos, GitHub, API de rastreo de Estafeta) son actores no-persona representados en el plano, no contrapartes que respondan.
• Éxito observable: el usuario lee el flujo completo Usuario → CDN Netlify → React SPA → Backend (opcional) → Base de datos, con GitHub y API de rastreo de Estafeta como servicios externos, y distingue claramente lo activo de lo futuro/opcional, tanto en escritorio como en móvil.
• Restricciones de origen: el backend Node.js/Express es opcional y para futuras funcionalidades; la API de rastreo de Estafeta es un servicio externo futuro; la base de datos se representa como Firestore (NoSQL) o MongoDB.

5. Core User Flows

Flujo 1 — Leer el diagrama de arquitectura desde el navegador de escritorio

1. Contexto inicial: el Usuario del Sistema de Gestión de Entregas abre su navegador web de escritorio y navega al sitio de space-diagramas.
2. Acción: el usuario entra al sitio; el frontend React SPA se sirve desde la CDN global de Netlify.
3. Resultado observable: se muestra la página Landing con el titular «SISTEMA DE GESTIÓN / DE ENTREGAS / ESTAFETA», la franja de metadatos «REACT SPA · NETLIFY CDN · NODE/EXPRESS (OPCIONAL) · FIRESTORE | MONGODB» y la capa USUARIO ya visible.
4. Acción: el usuario se desplaza hacia abajo; las flechas de flujo se dibujan de origen a destino en 180ms lineales con 60ms de desfase.
5. Resultado observable: el diagrama se traza como un recorrido: Usuario → CDN Netlify → React SPA → Backend (opcional) → Base de datos.
6. Acción: el usuario abre la página Architecture Diagram para leer el plano completo.
7. Resultado observable: ve los nodos con código de color en el borde superior, los rótulos de capa, la fila de metadatos alineada a la derecha de cada nodo y la banda punteada «FUTURO / OPCIONAL» entre el frontend y la base de datos.
8. Acción: el usuario pasa el cursor sobre el nodo Frontend.
9. Resultado observable: el borde superior rojo se expande a todo el borde, las rutas conectadas se resaltan, el resto baja a 30% de opacidad y la leyenda resalta la fila roja (frontend).
10. Continuación: el usuario retira el cursor, el diagrama vuelve a su estado completo y relee el tramo de consulta de datos (petición al backend que consulta la base de datos).

Flujo 2 — Leer el diagrama desde el celular

1. Contexto inicial: el Usuario del Sistema de Gestión de Entregas abre el sitio desde su celular.
2. Acción: el usuario entra al sitio; el frontend React SPA se sirve desde la CDN global de Netlify.
3. Resultado observable: a 375px la rejilla colapsa a una columna y el diagrama se presenta como una secuencia vertical con flechas hacia abajo, cada nodo a ancho completo y sus metadatos apilados.
4. Acción: el usuario recorre la secuencia vertical de capas.
5. Resultado observable: lee en orden Usuario → CDN Netlify → React SPA → Backend (opcional) → Base de datos, con GitHub y API de rastreo de Estafeta como columnas de servicio.
6. Continuación: el usuario consulta la leyenda de señalética para confirmar la categoría de cada color.

Flujo 3 — Distinguir lo activo de lo opcional/futuro

1. Contexto inicial: el usuario está leyendo el plano y necesita saber qué componentes están realmente activos.
2. Acción: el usuario localiza la banda punteada «FUTURO / OPCIONAL» que atraviesa el diagrama entre el frontend y la base de datos.
3. Resultado observable: el backend Node.js/Express y la API de rastreo de Estafeta aparecen dentro de la banda punteada, con borde superior amarillo #F2B705.
4. Acción: el usuario consulta la leyenda de señalética en la esquina inferior derecha.
5. Resultado observable: la leyenda confirma rojo = frontend, amarillo = backend opcional y API futura, verde = base de datos, azul = servicios externos.
6. Continuación: el usuario concluye que solo el frontend React en Netlify, la base de datos y GitHub forman parte del estado activo representado.

Flujo 4 — Recuperación con movimiento reducido

1. Contexto inicial: el usuario tiene activada la preferencia prefers-reduced-motion en su sistema.
2. Acción: el usuario abre el sitio y navega al diagrama.
3. Resultado observable: todas las rutas aparecen ya dibujadas, sin animación de trazado.
4. Acción: el usuario pasa el cursor sobre un nodo.
5. Resultado observable: el resaltado es un cambio de opacidad instantáneo, sin transición.
6. Continuación: el usuario lee el flujo completo en estado estático.

6. Visuals Colors and Theme

Muse: Massimo Vignelli. Headline: Systematic clarity: architecture as a wayfinding diagram. El diagrama de arquitectura se trata como un plano de metro: rejilla estricta, tipografía grotesca, colores primarios como códigos de categoría. Registro preciso, legible y confiable, sin decoración que no informe.

Paleta (modo claro)

Todos los colores se aplican como relleno plano al 100% de opacidad, nunca degradado. Proporción: 70% papel, 20% blanco de nodo, 10% color-signal. Ningún color aparece sin función de categoría.

Tipografía

• Headings: Archivo — Archivo Black / Archivo 700, caja alta, tracking −0.01em, alineados a la izquierda y colgados de la rejilla.
• Body: Archivo.
• Etiquetas de nodo: Archivo 600 en mayúsculas con letter-spacing +0.08em.
• Escala modular 1.333 sobre base 16: 84 / 63 / 47 / 35 / 26 / 20 / 16 / 13.
• Titular de hero: clamp(44px, 9vw, 128px).
• Encabezado de sección: clamp(28px, 4vw, 47px).
• Etiqueta de nodo: 13px. Cuerpo: 16px con line-height 1.5. Micro-etiquetas de capa: 11px en mayúsculas.
• Cero itálicas, cero pesos ligeros: la jerarquía se construye con tamaño, peso y reglas horizontales.

Lenguaje de forma

Geometría dura y honesta: rectángulos de esquina viva (radio 0–4px), bordes de 1.5px en negro, reglas horizontales de 1px que atraviesan todo el ancho, y formas geométricas puras como contenido (círculos para el usuario, barras para capas, bandas diagonales para flujos alternos). Los conectores son líneas ortogonales con quiebres de 90° y ángulos redondeados a 6px, nunca curvas orgánicas. Las flechas son triángulos sólidos de 8×10px, no chevrons finos. Nada flota: todo se apoya en la rejilla.

Ritmo de espaciado y layout

Rejilla modular de 12 columnas visible (líneas guía al 6% de opacidad, conmutables). El diagrama vive en una banda central de 8 columnas con las capas apiladas verticalmente en orden de flujo: Usuario → CDN Netlify → React SPA → Backend (opcional, en banda punteada) → Base de datos, con GitHub y API Estafeta anclados como columnas laterales de servicio. Cada nodo es una tarjeta-rectángulo con código de color en el borde superior de 4px, nombre del componente en mayúsculas, tecnología en cuerpo menor y una fila de metadatos alineada a la derecha (puerto, protocolo, estado). Reglas horizontales separan capas y llevan un rótulo de capa a la izquierda en micro-mayúsculas. La leyenda de colores vive fija en la esquina inferior derecha como una tabla de señalética. A 375px la rejilla colapsa a una columna y el diagrama se vuelve una secuencia vertical con flechas hacia abajo, cada nodo a ancho completo y sus metadatos apilados.

Estilo de imagen

La imagen ES el diagrama: pictogramas geométricos construidos en SVG (círculo-usuario, barra-frontend, cilindro-base de datos, rombo-servicio externo), líneas de flujo ortogonales y bandas de color plano. Sin fotografía, sin ilustración decorativa, sin capturas de pantalla. Los únicos elementos gráficos permitidos son los que codifican una categoría o una dirección de flujo.

7. Signature Design Concept

Portada de plano. La primera pantalla de Landing se compone como la portada de un plano de señalética:

• En la parte superior izquierda, un titular de tres líneas en Archivo Black que ocupa 9 de las 12 columnas —«SISTEMA DE GESTIÓN / DE ENTREGAS / ESTAFETA»— a clamp(44px, 9vw, 128px), con la palabra «ESTAFETA» sangrada a la derecha y subrayada por una regla roja #D62828 de 6px que se extiende hasta el borde del viewport, partiendo la pantalla en dos alturas.
• Debajo, una franja de metadatos en micro-mayúsculas separada por reglas verticales: «REACT SPA · NETLIFY CDN · NODE/EXPRESS (OPCIONAL) · FIRESTORE | MONGODB».
• El resto de la pantalla (60%) no es un fondo decorativo: es el diagrama mismo empezando a dibujarse, con la capa USUARIO ya visible arriba y las flechas trazándose hacia abajo al hacer scroll.
• Sin botón centrado, sin subtítulo genérico, sin degradado: la composición es asimétrica, anclada a la izquierda, con el vacío de la derecha reservado para la leyenda de colores.

Movimientos de firma:

1. Titular de portada a 9 columnas con la última palabra sangrada a la derecha y una regla roja de 6px que corre hasta el borde del viewport.
2. Diagrama de arquitectura construido como plano de metro: nodos rectangulares con código de color en el borde superior, conectados por líneas ortogonales de quiebre a 90° y flechas triangulares sólidas; cada nodo lleva una fila de metadatos alineada a la derecha (tecnología / protocolo / estado).
3. Leyenda de señalética fija en la esquina inferior derecha: tabla de color-código que asigna rojo = frontend, amarillo = backend opcional y API futura, verde = base de datos, azul = servicios externos, y que resalta la fila correspondiente al pasar sobre cualquier nodo.
4. Banda punteada de «FUTURO / OPCIONAL» que atraviesa el diagrama entre el frontend y la base de datos, marcando visualmente el backend Node/Express y la API de rastreo Estafeta como rutas no activas pero ya trazadas.
5. Animación de trazado de rutas al hacer scroll: cada flecha se dibuja de origen a destino en 180ms lineales con 60ms de desfase, de modo que el flujo de datos se lee como un recorrido, no como una imagen estática.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Sujeto focal: el diagrama de arquitectura mismo, con la capa USUARIO ya visible en la parte superior y las flechas trazándose hacia abajo.
• Tesis input → transformación → outcome: al cargar la portada, las flechas de flujo se dibujan de origen a destino en 180ms lineales, una tras otra con 60ms de desfase; al hacer scroll, el recorrido continúa trazándose capa por capa, de modo que el flujo de datos se lee como un recorrido y no como una imagen estática.
• Vocabulario de movimiento: movimiento de sistema de transporte —instantáneo y preciso—. Sin rebotes, sin escalados elásticos, sin partículas.
• Primer fotograma compuesto: titular de tres líneas en Archivo Black a 9 columnas, «ESTAFETA» sangrada a la derecha con regla roja de 6px hasta el borde del viewport, franja de metadatos en micro-mayúsculas, capa USUARIO visible arriba y el vacío de la derecha reservado para la leyenda.
• Estado con movimiento reducido: todas las rutas aparecen ya dibujadas y el resaltado es un cambio de opacidad instantáneo.

9. Non-Functional Requirements

• NFR-1 — Legibilidad del diagrama. El diagrama debe ser claro y mostrar el flujo de datos mediante flechas. Provenance: explicit. Rationale: es el requisito central del usuario.
• NFR-2 — Legibilidad responsive. El texto legible y los controles permanecen completos dentro del viewport y de su contenedor en 375px, 768px y 1280px, ajustándose con clamp(...) y su tamaño móvil; ningún otro elemento los cubre. A 375px la rejilla colapsa a una columna. Provenance: explicit (dirección creativa).
• NFR-3 — Accesibilidad de movimiento. Con prefers-reduced-motion, todas las rutas aparecen ya dibujadas y el resaltado es un cambio de opacidad instantáneo. Provenance: explicit (dirección creativa).
• NFR-4 — Contraste y color con función. Ningún color aparece sin función de categoría; los colores se aplican como relleno plano al 100% de opacidad, nunca degradado. Provenance: explicit (dirección creativa).
• NFR-5 — Entrega estática. El sitio se sirve como SPA React desde la CDN global de Netlify; el diagrama no requiere backend propio para mostrarse. Provenance: explicit.
• NFR-6 — Fidelidad de la representación. El diagrama debe representar exactamente los cinco grupos de componentes y el flujo descrito, sin sustituir ni omitir elementos. Provenance: explicit.

10. Tech Stack

• Frontend: React SPA. Provenance: explicit.
• Alojamiento / entrega: Netlify con CDN global. Provenance: explicit.
• Backend (representado en el diagrama, opcional y futuro): Node.js con Express. Provenance: explicit. No forma parte desplegada de space-diagramas.
• Base de datos (representada en el diagrama): Firestore (NoSQL) o MongoDB, como alternativas. Provenance: explicit.
• Servicios externos (representados en el diagrama): GitHub (control de versiones) y API de rastreo de Estafeta (futuro). Provenance: explicit.
• Tipografía: Archivo (Archivo Black / Archivo 700 para titulares; Archivo para cuerpo). Provenance: explicit (dirección creativa).
• Gráficos: SVG para pictogramas geométricos, líneas de flujo ortogonales y bandas de color plano. Provenance: explicit (dirección creativa).

11. Assumptions and Constraints

Restricciones explícitas

• El backend Node.js con Express es opcional y está destinado a futuras funcionalidades.
• La API de rastreo de Estafeta se representa como servicio externo futuro.
• La base de datos se representa como Firestore (NoSQL) o MongoDB (alternativas).
• El diagrama debe ser claro y mostrar el flujo de datos mediante flechas.

Supuestos

• [Supuesto] El sitio es de acceso público y anónimo: no se requiere cuenta ni identidad de aplicación, ya que no hay estado privado por usuario que conservar ni compromisos que deban quedar ligados a un participante.
• [Supuesto] El contenido del diagrama es estático y vive enteramente en el frontend; no hay datos en vivo que consultar.
• [Supuesto] GitHub se representa únicamente como servicio externo de control de versiones, sin integración funcional en el sitio.

Restricciones de diseño (dirección creativa)

• Prohibido el azul corporativo o índigo tipo #2563EB/#4F46E5 sobre blanco puro, o cualquier degradado azul-violeta.
• Prohibidas las tipografías Inter, Roboto, Arial, Helvetica, Poppins o system-ui para titulares o cuerpo.
• Prohibidas las tarjetas con sombra suave flotante, esquinas muy redondeadas o efecto hover-lift genérico.
• Prohibidos los iconos de línea fina estilo librería SaaS (Lucide/Feather) sin código de color ni metadatos asociados.
• Prohibidas las ilustraciones decorativas, blobs, partículas o cualquier gráfico que no codifique una categoría o un flujo.
• Prohibidos los fondos oscuros o glassmorphism: el plano debe leerse como impreso sobre papel.
• Prohibida la fotografía de stock de personas usando laptops o camiones de reparto.
• Prohibidas las flechas curvas orgánicas o conectores diagonales sin rejilla ortogonal.
• El template genérico indigo/blue-on-white SaaS está prohibido para este proyecto.

12. Glossary

• SPA: Single Page Application; aplicación web que se carga una vez y actualiza su contenido sin recargar la página.
• CDN: Content Delivery Network; red de servidores que distribuye el contenido estático desde ubicaciones cercanas al usuario. En este proyecto, la CDN global de Netlify.
• Netlify: plataforma de alojamiento y despliegue que sirve el frontend React SPA.
• React SPA: el frontend del Sistema de Gestión de Entregas, construido con React.
• Node.js / Express: backend opcional y futuro del Sistema de Gestión de Entregas, representado en el diagrama pero no activo.
• Firestore (NoSQL): base de datos NoSQL de Google, una de las dos alternativas representadas.
• MongoDB: base de datos NoSQL, la otra alternativa representada.
• GitHub: servicio externo de control de versiones, representado en el diagrama.
• API de rastreo de Estafeta: servicio externo futuro de rastreo de entregas, representado en el diagrama pero no activo.
• Nodo de arquitectura: tarjeta-rectángulo del diagrama que representa un componente, con código de color en el borde superior, nombre en mayúsculas, tecnología y fila de metadatos.
• Conector de flujo: línea ortogonal con quiebres de 90° terminada en flecha triangular sólida que indica la dirección del flujo de datos.
• Banda «FUTURO / OPCIONAL»: banda punteada que atraviesa el diagrama entre el frontend y la base de datos, marcando los componentes no activos.
• Leyenda de señalética: tabla fija de color-código en la esquina inferior derecha que asigna cada color a una categoría de componente.
• Rótulo de capa: micro-etiqueta en mayúsculas a la izquierda de cada regla horizontal que separa capas del diagrama.