Esta guía mapea lo que está efectivamente compilando en AgroConnect.Mobile: 46 ContentPages en .NET MAUI, dos paletas de tokens conviviendo, una tipografía Inter + Instrument sobre fondo hueso, tres roles con flujos distintos y un puñado de patrones compartidos (KPI strip, cards con eyebrow, chips de estado, listas con chevron). Todo lo de acá salió de leer los XAML, no de inventar. Las decisiones abiertas están marcadas como diagnóstico al final.
● 46 pantallas · 148 tokens de color · 2 sistemas coexistiendoLa app tiene dos paletas operando en paralelo. La primera — semántica clásica: Primary, Background, TextPrimary, Error, Warning, Info — está definida en Colors.xaml y sigue el patrón habitual de .NET MAUI con verde #1a7742 como marca. La segunda — Sunlight: SunPaper, SunInk, SunMoss, SunClay, SunBrick — es la que usan 40 de las 46 pantallas, inspirada en papel hueso + tintas de imprenta, pero no está definida en ningún archivo del repo cargado. Debe vivir en un SunlightTokens.xaml fusionado vía App.xaml. Eso es el hallazgo #1 del diagnóstico.
Definidos literalmente en el repo. Verde institucional usado como Primary. El gradiente aparece en Login clásica, hoy no visible porque el Login migró a Sun*.
La paleta dominante. Reconstruida desde los mockups (Pendientes Migracion Mobile.html, Mockups *) y confirmada por uso. Hallazgo: los tokens Sun* no están en Colors.xaml.
Un color por estado de receta. Se usan en los chips (StatusDraft · Pending · Approved · Rejected · Warning · Expired) y en pantallas como ProducerRecipeList, MiCampo, LotDetail.
Clasificación OMS/SENASA. Aparece en ExecProducts, ProducerRecipeDetail, LotDetail. Color transmite riesgo: morado más grave (Ia), verde menos grave (IV).
Set denso para mensajes info/error/warning/success. Cada familia tiene *Bg (fondo soft), *Border (stroke), *Dark (texto). Se ven en Admin, CreateJob, ProducerProfile, EditApplicator — las pantallas que todavía usan el sistema clásico.
Pares fondo-soft + texto-medio para Moss, Amber, Sky, Brick, Teal. Mismo patrón que el sistema clásico pero con paleta editorial.
La app usa Inter en 4 pesos (Inter 400, InterMedium 500, InterSemiBold 600, InterBold 700). La escala declarada en Styles.xaml ofrece 8 niveles nombrados (Xs → 4xl) más 10 tamaños intermedios numéricos. En la práctica las pantallas usan tamaños específicos (12, 13.5, 14, 15) y no los tokens — otro hallazgo del diagnóstico.
Dos mundos tipográficos: los mockups (los HTML en Mockups *) usan Instrument Serif italic para títulos editoriales. La app compilada no tiene serif — todo es Inter. Las itálicas del design system en papel quedan como aspiracional; en el XAML real el hero se resuelve con InterBold + tamaño grande + letter-spacing negativo.
Base 4px. 8 niveles nombrados (Xs → 4xl) y 3 radios (Sm 8 · Md 12 · Lg 20). Las pantallas usan tanto los tokens como números en crudo — no hay una policía de uso; CardFrame viene con CornerRadius=12 hardcoded y Border con RoundRectangle 10.
La app divide sus vistas según el rol activo. El mismo usuario puede tener más de un rol; RoleSelectionPage decide. Cada rol tiene su home, su flujo principal y sus utilitarios. Transversales (login, notificaciones, edición de perfil, cambio de contraseña) se comparten.
Flujo core en 3 actos: Plan (ver trabajos en la bolsa, postularse) → Ejecución (checklist, condiciones, productos, drone, timeline, contacto) → Cierre (firma GPS, comprobante PDF).
Centro de acción: Mi Campo. Tres formas de traer una receta: Subir PDF, Crear manual, Recibir de aplicador. Luego elige Asignar directo o Publicar como trabajo. Ve postulantes, contrata, califica.
Alcance reducido. Home distinto al del aplicador — no ve bolsa ni gestiona perfil, sólo ejecuciones que la empresa le asigna. Reusa los 5 sub-tabs de ejecución. Cuenta mínima (OperatorAccountPage).
No pertenecen a ningún flujo operativo. Son la mecánica de la app: autenticarse, recuperar credenciales, elegir rol, editar datos básicos. LoadingPage es splash.
No migrado (fuera de scope MVP): AdminHomePage y AdminStatsPage. Son dashboards de administrador de empresa aplicadora — no de usuario final. Quedan para v2 de la web o una app admin separada.
Estos son los bloques que aparecen una y otra vez en los XAML. Si algo se usa en 5+ pantallas, está acá. Los nombres no están oficializados en el código — son la convención que emergió leyendo el repo.
Tag en mayúsculas con letter-spacing abierto sobre el título editorial. Marca dónde estás sin gritar. Eyebrow en SunEyebrow (muted), título en SunInk bold.
3–4 celdas en grid. Cada una tiene label (KpiLabel, muted, caps) + valor grande + unidad pequeña. Sin bordes entre celdas, fondo SunPaper2 o SunKpiCard.
Fila con ícono o emoji a la izquierda, texto principal y › (SunClay) a la derecha. El chevron es U+203A, no un ícono vectorial — elección consistente en todo el repo.
Pill con fondo suave (*Soft) y texto del color semántico. Border-radius 10, padding 10×4, fontsize 11. Se usa el converter StatusToColor para mapear estado → color sin if en el XAML.
Eyebrow de sección + hairline (SunLine) + label + Border con RoundRectangle 10 envolviendo el Entry. Error debajo en SunBrick size 11, visible vía StringNotEmpty.
Emoji grande centrado + título bold + párrafo muted explicando qué hacer. Opcionalmente un CTA. Cuando hay error, versión gemela con "Reintentar" como secondary.
Botón primario de ancho completo (HorizontalOptions=FillAndExpand) al final del scroll. SunPrimaryButton (clay), height 52, radius 10, InterSemiBold 15. Secundario cancelable debajo, ghost.
Tira horizontal de botones tipo pill para filtrar listas por estado. El seleccionado invierte fondo/texto. Fila scrolleable en horizontal si no cabe.
Avatar/emoji circular (44×44, fondo suave) + nombre bold + rol en muted + botón ☎ clay a la derecha. Separado por hairlines.
Border dashed con StrokeDashArray=6,4, emoji grande (📤), texto principal + caption. Estado post-selección muestra chip con nombre, tamaño y botón ✕ para quitar.
Lista vertical con línea vertical 1px a la izquierda, dots en cada evento, hora en monospace, descripción bold + meta muted. Destaca inicio/fin y pausas con color.
Círculo con emoji/inicial + nombre + rol debajo. Size del círculo varía: 44 en listas, 72 en detail, 96 en perfil propio. Fondo siempre *Soft, texto *Text.
Los estados se codifican por color + etiqueta. Hay tres familias: receta (6 estados), ejecución (5 estados), y postulación/trabajo (4 estados). Cada uno tiene su converter — StatusToColor, ExecStatusColor, ExecutionStatusToColor — que evita condicionales en el XAML.
StatusDraft
StatusPending
StatusApproved
StatusWarning
StatusRejected
StatusExpired
Todas las vistas compilando en src/AgroConnect.Mobile/Views/, agrupadas por dominio. Columna sistema marca qué paleta usa: Sun = Sunlight (reconstruido), old = Colors.xaml clásico, mix = ambos.
Total MVP: 42 pantallas migradas a Sunlight · 4 pendientes (ProducerJobDetail, CreateJob, ProducerProfile, EditApplicator). Las 4 restantes son las últimas del flujo productor y la edición de perfil del aplicador. Las dos de Admin quedan afuera del MVP por acuerdo con producto.
Seis hallazgos que surgieron del cruce código ↔ mockups. Cada uno tiene severidad (alta = rompe consistencia, media = deuda manejable, baja = mejora futura) y la evidencia concreta en XAML o en los HTML de mockup. Ninguno bloquea la release, pero todos tienen que estar respondidos.
Colors.xaml define 35 tokens del sistema clásico (Primary, Background, Error*, Warning*…). Los XAML reales consumen ~113 tokens Sun* que no están declarados en ningún archivo del repo cargado. O se perdió un SunlightTokens.xaml en la migración, o está mergeado en otra branch. Cuatro pantallas siguen usando la paleta clásica (CreateJob, ProducerJobDetail, EditApplicator, ProducerProfile) — son las que van a romper primero si se toca el sistema.
Decisión pendiente: ¿se adopta Sun* como oficial y se deprecan los tokens viejos, o se consolida bajo nombres semánticos (Primary, Surface…) dejando Sun* como capa de implementación? Recomendación: lo primero, más rápido y ya es lo que el equipo está usando en la práctica.
La escala declarada tiene 8 niveles nombrados. En las pantallas aparecen tamaños en crudo (13.5, 15, 11.5) que no están en ningún token. La práctica — escribir el número y listo — convive con el sistema formal. El resultado: dos labels con el mismo rol visual terminan en 14 y 13.5 según quién escribió el XAML.
Decisión pendiente: ¿normalizar a tokens (y perder 1–2px de ajuste fino) o aceptar oficialmente los intermedios como FontSize13_5? Recomendación: normalizar, con regla lint que prohíba literales numéricos en FontSize.
Los mockups (Mockups *.html) usan Instrument Serif italic para títulos editoriales — es un gesto fuerte del lenguaje visual. La app compilada no tiene serif registrada; todo el hero se resuelve con InterBold + tamaño grande. El diseño en papel y el producto real tienen dos personalidades tipográficas.
Decisión pendiente: ¿agregar una serif al bundle (peso de 80–120kb × 2 pesos) o aceptar que los mockups están "más arriba" del producto real? Recomendación: dejarla como aspiracional de v2 — el bundle ya está justo.
Hay tokens RadiusSm · 8, RadiusMd · 12, RadiusLg · 20. Pero en los XAML aparecen CornerRadius="10", RoundRectangle CornerRadius="10" y CornerRadius="14" sin tocar los tokens. El 10 es especialmente común — es el "entre Sm y Md" implícito que se volvió estándar de facto para pills, chips e inputs.
Decisión pendiente: ¿agregar RadiusChip · 10 al sistema o unificar todo a RadiusMd · 12? Recomendación: oficializar 10 como RadiusSm, subir 12 a RadiusMd y 20 a RadiusLg — es lo que ya está en uso.
De las 42 migradas al sistema Sunlight, quedan cuatro que todavía tiran de Colors.xaml clásico: CreateJobPage, ProducerJobDetailPage, EditApplicatorPage y ProducerProfilePage. Son las últimas del flujo productor + edición de perfil del aplicador. Mientras conviven, la app tiene dos estéticas según dónde navegás — especialmente visible cuando pasás de MiCampo (Sun) a CreateJob (clásico) en el mismo click.
Decisión pendiente: ¿migrar antes de la release (estimado: 1 día por pantalla) o aceptar inconsistencia visible? Recomendación: migrar. Son cuatro archivos, ya están los patrones establecidos.
La app usa tres estrategias de ícono en paralelo: emojis Unicode (🌾 📋 ☎ 📤), caracteres tipográficos (› U+203A como chevron en vez de ícono vectorial), y PNGs del sistema (home, settings). Elegir en cuál apoyarse afecta tamaño del bundle, accesibilidad y consistencia cross-platform — Android y iOS renderizan emojis distinto.
Decisión pendiente: ¿adoptar un set de íconos vectoriales (Lucide, Phosphor) o mantener emojis? Los emojis aportan calidez editorial que alinea con el lenguaje papel hueso; una familia de íconos daría consistencia pero cambiaría el tono. Recomendación: mantener emojis, agregar sólo un set vectorial para navegación (tab bar, back, chevron) en v2.