Saltar a contenido

ADR-015 — Topología: monorepo con dos frontends de presupuesto distinto

  • Status: accepted (Opción B del BRIEF §3 ya decidida; estructura de repos cerrada por discovery)
  • Context: El BRIEF fija la topología de frontends (Opción B: gestor con stack WorkDone completo; landing separada y mínima) y delega en discovery la estructura de repos (mono/multi).
  • Alternatives:
  • Tres repos (backend / landing / gestor): aísla builds pero triplica gestión de versiones, PRs y puesta en marcha para un equipo chico con deadline 01/09.
  • Monorepo con tres módulos (elegida): un clone, un pipeline, versionado atómico de contratos API ↔ frontends.
  • Decision: Monorepo SistemaPremios con:
  • backend/ — M3 (API pública + API gestor + motor + DB).
  • landing/ — M4: React 18.3 + Vite + TS pelado (sin shadcn/Radix), presupuesto de carga instantánea en 3G, selects nativos, JSON snake_case mapeado en src/types/api.ts.
  • gestor/ — M5: stack WorkDone completo (React 18.3 + Vite 5 + TS 5.6 + Tailwind 3.4 + shadcn/ui new-york parcial [alert/badge/button/card/input/label/table + toast] + Radix solo label/slot/toast + lucide-react + TanStack Query v5 + axios + react-router-dom v6 + zustand v5 + react-hook-form + zod + react-konva).
  • Reglas duras de UI del BRIEF §3: sin otra librería de UI; ante faltantes, Tailwind puro antes que un primitive Radix nuevo; selects nativos con selectCls.
  • Consequences: Dos builds independientes con presupuestos de peso distintos; la landing no hereda el bundle del gestor. uscha.config.json registra los tres módulos como repos lógicos.

Implementation Plan

  • Estructura de directorios de arriba + uscha.config.json repos[] actualizado.
  • Cada frontend con su package.json y build propio; backend sirve estáticos o se publican por separado detrás del mismo subdominio (decisión operativa M6).

Nota (M6, decisión operativa cerrada): se optó por que el backend sirva los estáticos — un único jar Spring Boot empaqueta landing/dist bajo static/ y gestor/dist bajo static/gestor/ (perfil Maven full, frontend-maven-plugin), en vez de publicarlos por separado detrás de un reverse proxy. Ver SPEC.md §10 y SpaForwardController (backend).

Verification

  • [ ] landing/package.json no contiene shadcn, Radix ni librerías de UI pesadas.
  • [ ] Build de landing y gestor generan bundles separados.
  • [ ] gestor/ replica el stack WorkDone exacto (versiones mayores).

Nota (enmienda, ver ADR-019): la landing (landing/) migró su runtime de React 18.3 a Preact vía preact/compat (docs/E2E-PLAN.md A9, presupuesto de 3G) — el código fuente sigue escrito contra la API de React, solo cambia qué lo ejecuta. El gestor no se ve afectado por esta enmienda: sigue en React 18.3 tal cual queda descripto arriba.