Glosario de términos y entidades

Esta página se importa íntegra desde la fuente de verdad técnica: yms-docs/00-vision-general/glosario.md — cualquier corrección debe hacerse allí. Versión: 1.5 Última actualización: 13 de mayo de 2026 Cambios desde versión anterior: depuración del alcance tras 8ª validación (ADRs 038-040). Slot eliminado del modelo (Zone es unidad operativa mínima). Agregadas entidades ShipmentDocument, TrailerSeal y 5 catálogos (Carrier, Line, TripType, ContentType, Origin/Destination). MovementEvent y Anomaly con tipos nuevos.

Este documento define quién interactúa con el sistema YMS (actores) y qué información maneja (entidades), de forma simple y directa. Sirve de referencia rápida para entender la terminología usada en todo el proyecto y evitar ambigüedades cuando se discute el sistema con cliente, equipo o stakeholders.

Actores: personas que interactúan con el sistema

Personas que SÍ usan el sistema

Personal de patio

También llamado: patiero, yardista, Operator (rol técnico).

Quién es: empleado del cliente que opera el patio, ya sea en caseta de entrada/salida (con PC o smartphone) o caminando por el patio (smartphone/tablet). Es quien registra las entradas y salidas — la fuente de verdad operativa del sistema.

Qué hace en el sistema:

Registra entradas escaneando el QR de la “carta de instrucciones / hoja de salida” del transportista, o capturando manualmente los campos mínimos cuando no hay QR.
Selecciona la zona del patio donde el trailer quedó.
Registra salidas, verificando que los sellos coincidan con los capturados al entrar.
Hace rondines por el patio para confirmar o corregir la zona reportada por GPS de cada trailer.
Registra trailers visitantes sin GPS (mismo flujo, con confirmación obligatoria de zona en rondín).
Reporta anomalías que detecta visualmente (trailer dañado, sellos rotos, posición incorrecta, etc.).

Apps que usa: principalmente yms-mobile (PWA en celular) en campo. Ocasionalmente yms-web cuando trabaja desde caseta u oficina.

Cuántos hay típicamente: 4-8 miembros del personal de patio rotando turnos en un patio mediano (24/7).

Jefe de patio

También llamado: coordinador de patio, supervisor de patio, YardManager (rol técnico).

Quién es: persona responsable de supervisar la operación completa del patio. No camina constantemente por el patio; su trabajo principal es supervisar desde oficina/caseta y resolver excepciones.

Qué hace en el sistema:

Ve el dashboard del patio en tiempo real con KPIs (ocupación, anomalías, rotación).
Resuelve anomalías que el sistema detectó automáticamente.
Fuerza el cierre de registros de entrada cuando hay errores (acción especial).
Cambia la zona de un trailer sin esperar al rondín del personal de patio (acción especial).
Consulta la bitácora de operaciones de cada miembro del personal de patio del turno.
Edita el layout del patio cuando hay cambios físicos (redibujar zonas, expandir perímetro).

Apps que usa: principalmente yms-web (PC en oficina). Ocasionalmente yms-mobile para acciones puntuales.

Cuántos hay típicamente: 1 por patio, posiblemente con un suplente que rota turno.

Personal de caseta de vigilancia

Quién es: personal que controla el acceso físico al patio en la puerta principal. Vigila las entradas y salidas de trailers durante todo el horario operativo.

Qué hace en el sistema:

Usa la “Vista de caseta” en yms-web para ver:
- Trailers aproximándose al patio (detectados antes de cruzar el geofence).
- Trailers que acaban de cruzar entrando.
- Trailers que acaban de cruzar saliendo (con alerta si no fueron liberados en sistema).
Registra trailers visitantes a su llegada física al patio.
Notifica al personal de patio si detecta que un trailer entró sin registrarse en el sistema.

Rol técnico: Operator (con acceso a la vista especializada de caseta).

Apps que usa: yms-web desde una PC fija en la caseta.

Cuántos hay típicamente: 1 por turno en la caseta.

Administrador del sistema

Quién es: persona del lado del cliente (usualmente del equipo de TI) responsable de configurar el sistema inicialmente y mantenerlo en el tiempo.

Qué hace en el sistema:

Crea y configura yards.
Gestiona usuarios y sus permisos por yard.
Configura integraciones (Samsara API, webhooks salientes).
Mantiene los catálogos operativos (Carrier, Line, TripType, ContentType, Origin, Destination).
Configura settings globales del sistema (umbrales de anomalías, tolerancias GPS, retención de fotos, etc.).
Audita el uso del sistema cuando es necesario.

Rol técnico: Admin.

Apps que usa: yms-web exclusivamente.

Cuántos hay típicamente: 1-2 por cliente.

Personal administrativo de consulta

Quién es: personal de oficina que necesita consultar información del patio sin modificar nada (gerencia, atención al cliente, contabilidad, etc.).

Qué hace en el sistema:

Ve el tablero del yard en modo solo-lectura.
Consulta el histórico de un trailer cuando un cliente pregunta dónde está su unidad.
Genera reportes de operación (entradas/salidas del día, ocupación, etc.).
Sin permisos para registrar entradas/salidas, confirmar/corregir zonas, ni modificar nada.

Rol técnico: Viewer.

Apps que usa: yms-web.

Cuántos hay típicamente: variable según el tamaño de la operación administrativa.

Personas que NO usan el sistema

Nota terminológica importante: en la operación de Hg Transportaciones la palabra “operador” se reserva para referirse al chofer del tractor (la persona que conduce el tracto que mueve el remolque). El personal interno que opera el sistema YMS se denomina “personal de patio”, “patiero” o “yardista” (rol técnico Operator en el sistema). Esta documentación sigue esta convención: cuando dice “personal de patio” se refiere al usuario interno del sistema; cuando dice “chofer del tractor” se refiere al “operador” en el sentido del cliente.

Estas personas son parte de la operación de transporte pero no interactúan directamente con el sistema YMS.

Chofer del tracto / camión (= “operador” en la jerga del cliente)

Quién es: persona que conduce el tracto que jala el remolque hasta el patio.

Por qué NO usa el sistema: su única función es física: estacionar el remolque en el patio y retirarse. El sistema lo detecta automáticamente vía GPS del trailer, sin que el chofer haga ninguna acción digital.

Conductor de ruta / tramo / local

Quién es: persona que opera vehículos de transporte de mercancía entre puntos. Distinto del chofer del tracto en términos de tipo de operación.

Por qué NO usa el sistema: solo transporta. No interactúa con el patio más que para entregar o recoger trailers.

Cliente del transporte

Quién es: la empresa o persona que contrata el servicio de transporte (dueño de la carga, dueño del trailer, etc.).

Por qué NO usa el sistema directamente: si necesita información sobre dónde está su trailer, lo solicita al personal administrativo del personal de patio del patio (Hg Transportaciones), quien consulta el sistema y le responde.

En el futuro, si se desarrolla un portal de cliente o integración con TMS del cliente, esta persona podría consultar información del sistema indirectamente. Esto es post-MVP.

Entidades: información que maneja el sistema

Entidades operativas (las que cambian en el día a día)

Trailer (Remolque)

Qué es: un remolque/caja que entra al patio. Puede ser propio (con GPS Samsara instalado) o visitante (sin GPS, registrado manualmente por el personal de patio).

Información que tiene:

Número del trailer (ej. “ABC-1234”).
ID del dispositivo Samsara (si aplica).
IsGpsCapable (bool): true si tiene Samsara funcional, false si depende de captura manual exclusivamente.
Tipo (caja seca, refrigerado, plataforma, tanque, otro).
Ownership (propio, de proveedor, visitante).
Estado actual (en patio, fuera, en mantenimiento, inactivo).
Última posición GPS conocida y timestamp (si IsGpsCapable).
CurrentZoneId (zona actual según GPS o última corrección manual).
ManualZoneConfirmedAt (timestamp de la última confirmación de zona por personal de patio en rondín).

Cómo se crea en el sistema:

Sync masivo inicial desde Samsara (la mayoría de trailers propios).
Sync diario continuo desde Samsara (nuevos que aparecen).
Registro manual por el personal de patio cuando entra un visitante sin GPS (vía QR de hoja de salida o captura manual).

Quién interactúa con esta entidad: el personal de patio la consulta en cada registro y en cada rondín; el jefe de patio la consulta para histórico y disputas; el sistema la actualiza con confirmaciones GPS y correcciones del personal de patio.

ShipmentDocument (Hoja de salida / Carta de instrucciones)

Qué es: el documento físico que el transportista entrega al llegar al patio. Tiene un QR escaneable que pre-llena ~90% de los campos del registro de entrada. Es el reemplazo digital de la captura manual de ~20 campos del sistema actual del cliente.

Información que tiene:

Folio (identificador único del viaje, ej. “2026-001234”).
QrCode (token raw o firmado contenido en el QR).
IssuedAt (cuándo se emitió el documento).
DeclaredOrigin / DeclaredDestination (ciudades o puntos declarados).
CarrierId → FK al catálogo Carrier.
LineId → FK al catálogo Line (HG, CH, RL, LD, etc.).
BoxNumber (número de caja, complementa a Trailer.Number).
TripTypeId → FK al catálogo TripType (Local, Carretera, Importación, Exportación, Doméstico).
ContentTypeId → FK al catálogo ContentType (Empty, Loaded, ReturnableNacional, ReturnableExport).
DriverName, DriverLicense.
TrailerId (resuelto al escanear, FK).
MovementEventId (evento de entrada/salida que originó el escaneo).

Cómo se crea en el sistema:

Al escanear el QR (preferido): si el folio no existe, se crea con datos del QR; si existe, se enlaza al movimiento.
Captura manual (fallback): el personal de patio llena los campos críticos cuando no hay QR.

Quién interactúa con esta entidad: el personal de patio al escanear/capturar; el jefe de patio al consultar histórico de viajes y disputas; el sistema verifica sellos al salir.

TrailerSeal (Sellos del remolque)

Qué es: los sellos físicos del remolque (sello1, sello2, sello3) que aseguran su carga. Cadena de custodia aduanal y de seguridad.

Información que tiene:

TrailerId (FK).
Position (1, 2 o 3).
Number (número del sello).
AppliedInDocumentId (FK a ShipmentDocument donde se aplicó).
AppliedAt / RemovedAt (timestamps).
RemovalPhotoId (FK a foto si el sello se retiró).

Cómo se crea en el sistema:

Al registrar la entrada: el personal de patio captura los sellos del trailer.
Verificación al registrar la salida: si los sellos no coinciden → anomalía SealMismatch (High).

Quién interactúa con esta entidad: el personal de patio captura/verifica; el jefe de patio investiga discrepancias.

Assignment (Registro de presencia en zona)

Qué es: el registro de que un trailer está actualmente presente en una zona específica de un yard. Tras la depuración (ADR-038), Assignment ya no apunta a un slot sino a una Zone. Es la unidad central de presencia en el patio.

Información que tiene:

Trailer.
ZoneId (FK — sin slot intermedio).
YardId (FK).
Estado (Confirmed, Released, ForceClosed).
Timestamp de creación (entrada registrada) y de cierre (salida registrada).
Usuario que la creó.
Source (cómo se creó: ShipmentDocumentScan, ManualEntry, ManagerAction).
Razón de cierre (si aplica — sólo para ForceClosed o salidas con razón explícita como “TrailerDamaged”).
ShipmentDocumentId (FK al documento de entrada).
GpsConfirmedAt (cuándo el GPS confirmó la entrada, nullable).

Cómo se crea en el sistema:

Personal de patio desde móvil al registrar entrada (escaneo QR de hoja de salida o captura manual).
Jefe de patio con acciones administrativas (corrección, forzar cierre).

Reglas duras:

Un trailer solo puede tener UNA asignación activa por yard.
Múltiples trailers pueden estar simultáneamente en la misma zona (no hay capacidad por zona explícita — la restricción es operativa, no técnica).

Quién interactúa con esta entidad: el personal de patio la crea (al registrar entrada) y la cierra (al registrar salida) diariamente; el jefe de patio la corrige cuando hay errores; el sistema la confirma con GPS y la valida en rondines.

MovementEvent (Evento de movimiento)

Qué es: registro inmutable de cada movimiento relevante en el sistema. Es la base del histórico completo.

Información que tiene:

Tipo de evento:
- EntryRegistered — entrada capturada por el personal de patio (Source = Manual o ShipmentDocumentScan).
- ExitRegistered — salida capturada por el personal de patio.
- OperatorZoneConfirmed — personal de patio confirmó zona en rondín.
- OperatorZoneCorrected — personal de patio cambió zona reportada por GPS.
- GpsConfirmedEntry / GpsConfirmedExit — confirmación automática de un evento manual por GPS.
- InternalMove — cambio de zona dentro del patio.
Trailer relacionado.
Yard y ZoneId (no slot — eliminado por ADR-038).
Timestamp de ocurrencia.
Posición GPS al momento del evento (si aplica).
Source (ShipmentDocumentScan, ManualEntry, Samsara, OperatorRound, ManagerAction).
Layout version vigente al momento del evento.
RegisteredByUserId (quién capturó manualmente, o null si Samsara).
GpsConfirmedAt (timestamp de confirmación GPS, nullable).
ShipmentDocumentId (si el evento se originó de un escaneo de hoja de salida).

Cómo se crea en el sistema:

Cuando un integrante del personal de patio registra entrada/salida.
Cuando un integrante del personal de patio confirma o corrige zona en rondín.
Automáticamente cuando GPS confirma un evento manual previo (actualiza GpsConfirmedAt).
Cuando el jefe de patio fuerza una acción correctiva.

Reglas duras:

Append-only: nunca se editan ni borran. Lo escrito queda permanentemente.

Quién interactúa con esta entidad: nadie la edita directamente. Se consulta para histórico, auditoría y resolución de disputas.

Anomaly (Anomalía)

Qué es: una situación detectada por el sistema (o reportada manualmente) que requiere atención humana.

Información que tiene:

Tipo de anomalía:
- ManualEntryNeedsGpsConfirmation — entrada manual sin confirmación GPS en >15 min (trailer con Samsara).
- VisitorZoneUnconfirmed — trailer sin Samsara con zona pendiente de confirmar en rondín (>4h).
- OperatorCorrectedGpsZone — personal de patio corrigió zona reportada por GPS (informativa, Low).
- UnexpectedManualGap — GPS reporta evento (entrada/salida) sin contraparte manual.
- SealMismatch — sellos al salir no coinciden con los del entrar (High).
- GpsZoneMismatch — reformulado: GPS reporta una zona distinta a la confirmada por el personal de patio en rondín.
- NoGpsSignal / GpsLost — trailer con Samsara que no reporta en >2-4h.
- LongDwell — trailer en patio más tiempo del normal.
- ManualReport — reportada por personal de patio con foto.
- TrailerNotFoundOnRound — personal de patio buscó el trailer en rondín y no estaba físicamente.
Severidad (Low, Medium, High, Critical).
Trailer y ZoneId / yard relacionados.
Estado del workflow (Open, InResolution, Resolved, Discarded).
Razón de resolución (cuando se cierra).
Foto adjunta (si fue reportada manualmente con evidencia).

Cómo se crea en el sistema:

Automáticamente por el sistema cuando detecta inconsistencias entre captura manual y GPS, o cuando se cumplen umbrales temporales.
Manualmente por el personal de patio cuando reporta un problema visualmente (trailer dañado, sellos rotos, etc.).

Quién interactúa con esta entidad: el personal de patio la reporta; el jefe de patio la resuelve; el sistema las genera automáticamente.

Entidades de configuración (las que se definen una vez y rara vez cambian)

Yard (Patio)

Qué es: un patio físico completo donde se reciben y gestionan trailers. Un cliente puede tener varios yards en distintas ubicaciones.

Información que tiene:

Nombre y código (ej. “Dulces Nombres” / “DN”).
Ubicación geográfica (dirección, coordenadas).
Polígono perimetral (geocerca del patio).
Bounding box (rectángulo simplificado para procesamiento eficiente).
Versión de layout activa.
Estado (activo/inactivo).

Cómo se crea en el sistema:

Por el Admin durante la configuración inicial.

Quién interactúa con esta entidad: el Admin la configura una vez; el jefe de patio la consulta para conocer el contexto; el sistema la usa constantemente para procesar GPS.

Zone (Zona)

Qué es: subdivisión interna del patio (ej. “Zona Norte”, “Zona Refrigerados”, “Bodegas”). Unidad operativa mínima donde se ubica un trailer. Tras ADR-038, sustituye al concepto de slot.

Información que tiene:

Nombre y código.
Polígono geométrico que delimita la zona.
Yard al que pertenece.
Layout version vigente.

Cómo se crea en el sistema:

Por el jefe de patio (o Admin) al modelar el layout inicial.
Posteriormente al editar el layout cuando se reorganiza el patio.

Quién interactúa con esta entidad: el jefe de patio la edita en el editor visual; el personal de patio la ve como contexto al asignar; el sistema la usa para reportes por zona.

Catálogos operativos (Carrier, Line, TripType, ContentType, Origin, Destination)

Qué son: catálogos cerrados administrados por el Admin global. Sustituyen los campos abiertos del sistema actual del cliente para evitar “dato sucio”.

Catálogo	Ejemplos	Usado en
`Carrier`	”DEXO”, “Hg Logística”, “Fletes del Norte”	`ShipmentDocument.CarrierId`
`Line`	HG, CH, RL, LD	`ShipmentDocument.LineId`
`TripType`	Local, Carretera, Importación, Exportación, Doméstico	`ShipmentDocument.TripTypeId`
`ContentType`	Empty, Loaded, ReturnableNacional, ReturnableExport	`ShipmentDocument.ContentTypeId`
`Origin` / `Destination`	”Saltillo”, “Apodaca”, “SISAMEX”	`ShipmentDocument.DeclaredOrigin/Destination`

Información común:

Id, Name (o Code + Name cuando aplique).
IsActive (soft delete).

Cómo se crean:

Por el Admin durante la configuración inicial.
Posteriormente al agregar nuevas líneas/carriers/destinos según la operación.

Quién interactúa con esta entidad: el Admin la mantiene; el personal de patio la consume al capturar entradas (dropdown); el sistema la valida.

LayoutVersion (Versión de layout)

Qué es: una “fotografía” del diseño del patio en un momento del tiempo. Cada vez que se modifica el patio (agregar/redibujar zonas, expandir el polígono), se crea una nueva versión sin perder la anterior. Tras ADR-038, versiona zonas únicamente (slots eliminados del modelo).

Información que tiene:

Yard al que pertenece.
Estado (Draft, Published, Superseded).
Fechas de vigencia (EffectiveFrom, EffectiveTo).
Conjunto de zonas con sus polígonos.
Notas del cambio.
Versión padre (en caso de evolución).

Por qué existe: permite que los movimientos históricos sigan siendo consultables aunque las zonas del patio cambien. Un registro de marzo del año pasado se entiende correctamente con la geometría de zonas de ese momento.

Cómo se crea en el sistema:

La primera al modelar el patio inicial.
Cada cambio sustancial a las zonas crea una nueva (al publicar el cambio).

Quién interactúa con esta entidad: el jefe de patio publica nuevas versiones; el sistema referencia la versión correcta al consultar histórico.

User (Usuario)

Qué es: persona registrada en el sistema con credenciales para acceder.

Información que tiene:

Email (identificador único).
Nombre y datos personales.
Rol global (Admin) o rol por yard (YardManager, Operator, Viewer).
Estado (activo/inactivo).
Hash de contraseña (nunca la contraseña en texto plano).

Cómo se crea en el sistema:

Por el Admin al dar de alta personal del cliente.
El primer Admin se crea como seed inicial al desplegar el sistema.

Quién interactúa con esta entidad: el Admin gestiona altas/bajas; los usuarios se autentican con sus credenciales.

UserYardAccess (Acceso de usuario a yard)

Qué es: define qué rol tiene un usuario específico en un yard específico. Permite que un mismo usuario sea YardManager en un patio y solo Viewer en otro, por ejemplo.

Información que tiene:

Usuario.
Yard.
Rol asignado (YardManager, Operator, Viewer).
Estado (activo/inactivo).
Fechas de vigencia.

Cómo se crea en el sistema:

Por el Admin o el YardManager del yard correspondiente.

Quién interactúa con esta entidad: el Admin la configura; el sistema la consulta en cada acción para validar permisos.

Entidades de integración (las que conectan con sistemas externos)

IntegrationCredential (Credencial de integración)

Qué es: credenciales para conectarse a sistemas externos como Samsara, TMS o WMS del cliente. Almacenadas cifradas.

Información que tiene:

Sistema objetivo (Samsara, TMS, WMS, etc.).
Configuración cifrada (API tokens, secretos, URLs).
Estado (habilitada/deshabilitada).

Cómo se crea en el sistema:

Por el Admin durante la configuración inicial de integraciones.

Quién interactúa con esta entidad: solo el Admin la configura; el sistema la usa internamente para autenticarse contra sistemas externos.

WebhookSubscription (Suscripción de webhook)

Qué es: configuración para enviar eventos del sistema YMS a sistemas externos del cliente (TMS, WMS, ERP) cuando ocurren acciones relevantes.

Información que tiene:

URL del receptor.
Eventos suscritos (entradas registradas, salidas registradas, anomalías, confirmaciones GPS).
Secreto para firmar HMAC.
Estado.

Cómo se crea en el sistema:

Por el Admin al configurar integración saliente con el cliente.

Quién interactúa con esta entidad: solo el Admin la configura; el sistema la usa internamente para enviar eventos.

Nota: para Hg Transportaciones inicialmente, esta capacidad queda preparada técnicamente pero sin destinatario activo (su TMS actual no tiene integraciones disponibles).

SamsaraIngestionQueue (Cola de ingesta de Samsara)

Qué es: cola interna del sistema donde se acumulan las posiciones GPS recibidas de Samsara antes de procesarse. Permite que el sistema responda rápido a webhooks y procese de forma asíncrona.

Información que tiene:

Posición GPS recibida (latitud, longitud, timestamp).
Estado de procesamiento.
Source (vino por webhook o por polling).

Cómo se crea en el sistema:

Automáticamente cada vez que llega una posición de Samsara.

Quién interactúa con esta entidad: nadie directamente. El sistema la consume internamente.

Entidades de auditoría y soporte

AuditLog (Bitácora de auditoría)

Qué es: registro inmutable de cada acción de usuario relevante en el sistema (login, edición de layout, gestión de usuarios, acciones administrativas).

Información que tiene:

Usuario que realizó la acción.
Tipo de acción.
Entidad afectada.
Timestamp.
Razón documentada (cuando aplica).

Por qué existe: soporte para auditoría interna del cliente, investigación de errores, prueba en disputas.

Quién interactúa con esta entidad: nadie la edita; el Admin y el YardManager la consultan cuando es necesario.

Photo (Foto)

Qué es: imagen adjunta a anomalías o a registros de entrada/salida cuando el personal de patio documenta evidencia visual (trailer dañado, sellos rotos, situación inusual).

Información que tiene:

URL del archivo (almacenado en blob storage).
Entidad relacionada (anomaly, assignment).
Timestamp y usuario que la subió.
Tamaño y metadata.

Cómo se crea en el sistema:

Por el personal de patio cuando reporta anomalías o cuando registra una salida con razón “TrailerDamaged”.
Por el personal de patio al capturar sellos o al detectar discrepancias de sellos al salir.

Quién interactúa con esta entidad: el personal de patio la sube desde la app; el jefe de patio la consulta al resolver anomalías.

Resumen rápido: quién hace qué

Persona	Acción principal	App que usa
Personal de patio	Registra entradas/salidas (QR de hoja de salida o manual) y confirma zonas en rondín	yms-mobile (principal)
Jefe de patio	Supervisa, resuelve excepciones y administra el layout de zonas	yms-web
Personal de caseta	Registra entradas/salidas desde caseta y vigila el flujo	yms-web (vista caseta)
Administrador	Configura el sistema (yards, usuarios, catálogos, integraciones)	yms-web
Personal administrativo	Consulta información en solo lectura	yms-web

Entidad	Cambia con frecuencia	Quién la modifica
Trailer	Sí (estados, posiciones, confirmaciones)	Personal de patio (rondín) + Sistema (Samsara)
ShipmentDocument	Sí (cada entrada/salida)	Personal de patio (escaneo o manual)
TrailerSeal	Sí (cada entrada)	Personal de patio
Assignment	Sí (todo el día)	Personal de patio + Jefe de patio
MovementEvent	Sí (cada operación)	Personal de patio (registros y rondín) + Sistema (confirmación GPS) — append-only
Anomaly	Sí (varias por día)	Sistema (auto) + Personal de patio
Yard	No (configuración)	Admin (una vez)
Zone	Raro (re-zonificación)	Jefe de patio en editor de zonas
Catálogos (Carrier/Line/TripType/ContentType/Origin/Destination)	Raro (altas puntuales)	Admin
LayoutVersion	No (configuración)	Jefe de patio al cambiar zonas
User / UserYardAccess	Raro (altas/bajas)	Admin / YardManager

Documentos relacionados

00-vision-general/funcionalidad.md — visión general del sistema
00-vision-general/roles-permisos.md — capacidades de cada actor
yms-indice.md — mapa completo de la documentación

Para mapa completo de la documentación, ver yms-indice.md.

Glosario YMS — referencia de terminología.