Fuente: refinamiento de las 63 historias de usuario y de sus criterios de aceptación. Formato: RF-XXX — El sistema debe <capacidad> con trazabilidad a las historias que lo originan.
Los requerimientos funcionales describen qué debe hacer el sistema para que las historias de usuario sean satisfechas. Cada requerimiento es verificable mediante observación externa o inspección de artefactos concretos; ninguno describe cómo se implementa.
El sistema debe mantener un archivo único de persona del agente como fuente de verdad de su nombre, tono, registro, idioma y políticas conversacionales.
US-053
🟡
RF-002
El sistema debe inyectar el contenido vigente del archivo de persona en el system prompt de cada invocación al modelo del agente.
US-053
🟡
RF-003
El sistema debe registrar, por conversación, la versión del archivo de persona vigente al momento de la interacción, para auditoría y trazabilidad.
US-053
🟡
RF-004
El sistema debe incluir el nombre del agente en el saludo inicial, en los mensajes de handoff (saliente y de retorno) y en las plantillas proactivas de Meta.
US-053
🟡
RF-005
El sistema debe responder al cliente en el mismo idioma (español o inglés) detectado en su último mensaje, manteniendo el cambio dentro de la conversación.
US-053
🟡
RF-006
El sistema debe tratar al cliente de "usted" por defecto y pasar a "tú" sólo cuando el propio cliente lo tutea dentro de la conversación, revirtiendo al formal en la siguiente.
US-053
🟡
RF-007
El sistema debe usar emojis de forma parca y contextual, nunca decorativa ni repetida.
US-053
🟡
RF-008
El sistema debe reconocer al cliente por su número entrante y cargar su contexto histórico al iniciar una sesión nueva.
US-002, US-054
🟡
RF-009
El sistema debe mantener la transcripción completa de las conversaciones del cliente durante los últimos seis meses y, para conversaciones más antiguas, un resumen persistente con atributos relevantes.
US-054
🟡
RF-010
El sistema debe poder referenciar cotizaciones, embarques y preferencias declaradas del mismo cliente sin horizonte de expiración del dato operativo.
US-054
🟡
RF-011
El sistema debe usar un resumen automático de mensajes antiguos combinado con los mensajes recientes en detalle cuando una misma conversación se extiende más allá del contexto útil del modelo.
US-054
🟡
RF-012
El sistema debe aislar la memoria por cliente y nunca revelar datos de otro cliente bajo ninguna consulta.
US-054, US-003
🟡
RF-013
El sistema debe declarar no tener el dato cuando el cliente solicita una cita textual de una conversación antigua fuera del horizonte de transcripción, ofreciendo el resumen disponible.
El sistema debe emitir al primer contacto de un número desconocido un único mensaje que integra saludo, presentación de capacidades, enlace a la política de privacidad y solicitud de aceptación explícita del consentimiento.
US-051, US-063
🟡
RF-015
El sistema debe registrar el consentimiento aceptado con timestamp, versión de la política vigente, canal, identificador del agente u operador y texto exacto del mensaje mostrado.
US-063
🟡
RF-016
El sistema debe solicitar reconfirmación explícita ante respuestas ambiguas del cliente (emoji aislado, "ok" sin contexto) antes de considerar el consentimiento válido.
US-063
🟡
RF-017
El sistema debe ofrecer el menú de capacidades a demanda cuando el cliente lo solicite ("¿qué puedes hacer?", "ayuda"), sin cancelar el flujo en curso.
US-052
🟡
RF-018
El sistema debe requerir, al dar de alta un cliente desde el backoffice, los campos de consentimiento (canal, fecha, operador que lo recibió y observación opcional) como obligatorios, sin los cuales no persiste el cliente.
US-005, US-063
🟡
RF-019
El sistema debe solicitar re-consentimiento al próximo contacto del cliente cuando publique una versión sustancialmente distinta de la política de privacidad, preservando el registro del consentimiento anterior.
El sistema debe crear una cuenta nueva con los datos mínimos recolectados por el agente (nombre, correo y número), dejándola en estado pendiente de verificación.
US-001
🟡
RF-021
El sistema debe permitir al operador dar de alta clientes desde el backoffice con los mismos datos mínimos y los campos de consentimiento off-WhatsApp.
US-005
🟡
RF-022
El sistema debe rechazar el alta cuando el correo propuesto ya existe en otra cuenta, ofreciendo asociación en lugar de creación.
US-001, US-005
🟡
RF-023
El sistema debe emitir un enlace único al correo verificado del titular para verificar cada número asociado a su cuenta, con vigencia de 2 horas y hasta cinco reenvíos en 24 horas.
US-003, US-004
🟡
RF-024
El sistema debe mantener el número asociado en estado pendiente hasta que el titular haga click en el enlace de autorización; los números pendientes no emiten cotizaciones ni inician embarques.
US-003, US-004
🟡
RF-025
El sistema debe registrar un nombre de contacto por cada número asociado y usarlo al saludar al cliente, en lugar del nombre del titular.
US-003
🟡
RF-026
El sistema debe restringir el acceso del colaborador a sus propias conversaciones y operaciones, y permitir al titular consultar la actividad de cualquier colaborador de su cuenta.
US-003
🟡
RF-027
El sistema debe declinar cortésmente y remitir al titular cuando un colaborador consulta información perteneciente al titular o a otro colaborador.
US-003
🟡
RF-028
El sistema debe permitir al cliente o al operador editar los datos personales del cliente (nombre, correo, números) desde los canales autorizados, registrando cada cambio en audit log y notificando al cliente.
US-006
🟡
RF-029
El sistema debe invalidar las verificaciones pendientes cuando cambia el correo del cliente, emitiendo nuevas si corresponde.
US-006
🟡
RF-030
El sistema debe preguntar explícitamente en cuál cuenta operar cuando el número del contacto pertenece a más de una cuenta (titular de una, colaborador de otra) y el código referenciado sea ambiguo.
El sistema debe extraer de un mensaje en lenguaje natural los parámetros de cotización disponibles (origen, destino, modalidad, tipo de operación, Incoterm, peso, volumen y tipo de carga) tolerando errores de tipeo, abreviaciones y ausencia de acentos.
US-007
🟡
RF-032
El sistema debe mostrar al cliente lo que entendió de su solicitud antes de pedir datos faltantes, permitiendo correcciones.
US-007
🟡
RF-033
El sistema debe preguntar al cliente ante dato ambiguo o faltante, nunca asumir para avanzar más rápido.
US-007, US-008
🟡
RF-034
El sistema debe reconocer cuando una combinación de modalidad, Incoterm o ruta no existe en el catálogo y ofrecer handoff con consentimiento explícito.
US-007, US-033
🟡
RF-035
El sistema debe guiar al cliente en orden natural (ruta, modalidad, carga, Incoterm) solicitando sólo los campos obligatorios para la combinación elegida.
US-008
🟡
RF-036
El sistema debe recalcular el conjunto de campos requeridos cuando el cliente cambia modalidad o Incoterm a mitad del flujo, conservando los datos ya válidos.
US-008
🟡
RF-037
El sistema debe presentar al cliente la lista de servicios opcionales aplicables según la combinación elegida, distinguiendo los fijos de los opcionales, y permitir selección por número o por nombre.
US-009
🟡
RF-038
El sistema debe indicar para cada servicio opcional si su precio es fijo o "a calcular" y nunca incluir un servicio fuera del catálogo vigente.
El sistema debe calcular el precio total de la cotización consultando siempre el catálogo vigente, sin estimar ni aproximar; si no hay tarifa para la combinación, debe declararlo en lugar de inventar.
US-010, US-059
🟡
RF-040
El sistema debe entregar la cotización con desglose obligatorio línea a línea en dólares estadounidenses, formato con dos decimales y separadores de miles.
US-010
🟡
RF-041
El sistema debe asignar a cada cotización un código externo corto CNNN único por cuenta del cliente y un código interno largo único globalmente, ambos no reutilizables.
US-010
🟡
RF-042
El sistema debe normalizar las variantes de escritura del código de cotización (mayúsculas/minúsculas, espacios, artículo inicial) dentro del alcance de la cuenta.
US-010
🟡
RF-043
El sistema debe comunicar al cliente un tiempo de tránsito estimado basado en el catálogo; cuando el dato no exista en catálogo, debe indicar "sujeto a confirmación" en lugar de inventar valor.
US-011
🟡
RF-044
El sistema debe permitir a los clientes con nivel corporativo activo solicitar re-cotización rápida a partir de sus últimos embarques y aplicar los precios vigentes del nivel en ese momento.
US-013, US-038
🟡
RF-045
El sistema debe declarar una vigencia explícita para cada cotización emitida, con default configurable (sugerido 7 días corridos).
US-014
🟡
RF-046
El sistema debe rechazar la aprobación de una cotización vencida y ofrecer re-cotización con precios vigentes.
El sistema debe implementar el flujo de aprobación formal en tres pasos sobre dos canales: intención por WhatsApp, envío del formulario de datos operativos y click en el enlace de aprobación del correo.
US-012
🟡
RF-048
El sistema debe generar una reserva preliminar al recibir la intención de aprobación por WhatsApp y mantenerla vigente mientras la cotización no haya expirado.
US-012
🟡
RF-049
El sistema debe enviar al correo verificado del contacto que aprueba un mensaje con el enlace al formulario operativo y, posteriormente, el correo de instrucciones con el enlace de aprobación formal.
US-012
🟡
RF-050
El sistema debe presentar una página intermedia al hacer click en el enlace de aprobación formal, mostrar el resumen completo de la operación y exigir un segundo click explícito para formalizar.
US-012
🟡
RF-051
El sistema debe enviar una notificación inmediata por WhatsApp al titular tras consumirse la aprobación formal, incluyendo el código del embarque, el monto y la indicación de cómo proceder si la aprobación no fuera suya.
US-012
🟡
RF-052
El sistema debe marcar la cotización aprobada como inmutable y bloquear re-aprobaciones o modificaciones posteriores vía agente; cambios requieren handoff con operador.
US-012
🟡
RF-053
El sistema debe invalidar todo enlace de un solo uso ante un reenvío (solo el más reciente es válido).
El sistema debe exponer el formulario de datos operativos como página pública sin login, accesible únicamente mediante el enlace firmado del correo.
US-015
🟡
RF-055
El sistema debe validar en cada acceso y envío del formulario que la cotización asociada está vigente; caso contrario rechaza con mensaje claro.
US-015
🟡
RF-056
El sistema debe determinar los campos obligatorios del formulario según la modalidad y los servicios contratados en la cotización.
US-015
🟡
RF-057
El sistema debe preservar un borrador local del formulario mientras el enlace esté vigente, descartándolo al vencer o invalidarse el enlace.
US-015
🟡
RF-058
El sistema debe invalidar el enlace del formulario ante la cancelación de la cotización, la emisión del embarque por otra vía o una solicitud válida de eliminación de datos del titular.
US-015
🟡
RF-059
El sistema debe enviar un recordatorio automático al cliente cuando su cotización se aproxima a la fecha de vencimiento (umbral configurable, default 4 horas antes) en forma de plantilla Meta aprobada, con un solo recordatorio por ciclo de vigencia.
El sistema debe emitir, al consumarse la aprobación formal, un código externo ENNN único por cuenta y un código interno global único para el embarque.
US-018
🟡
RF-061
El sistema debe componer al momento de la emisión la secuencia de estatus del embarque según los servicios contratados y congelarla inmutable para ese embarque.
US-027
🟡
RF-062
El sistema debe generar al momento de la emisión los tres PDF de instructivos (proveedor del cliente, operador logístico externo, personal interno de FleteChat) con el branding vigente de FleteChat.
US-019, US-020, US-021
🟡
RF-063
El sistema debe distinguir el contenido comercial y operativo entre los tres instructivos: el del proveedor no expone información del operador logístico, el del operador logístico no expone información comercial, y el interno contiene la información completa.
US-019, US-020, US-021
🟡
RF-064
El sistema debe disparar al evento de emisión (shipment_ready) la distribución automática e idempotente de los PDF a los canales correspondientes: correo al proveedor, correo al operador logístico, y almacenamiento en backoffice para el personal interno.
US-022
🟡
RF-065
El sistema debe aplicar política de reintentos con backoff ante fallos transitorios de envío (tres intentos: 1 min, 5 min, 30 min); si persiste, marca el embarque en distribución incompleta y alerta al operador.
US-022
🟡
RF-066
El sistema debe permitir al operador reenviar manualmente cualquiera de los instructivos a los destinatarios originales, con registro en audit log.
US-022
🟡
RF-067
El sistema debe regenerar los PDF ante una modificación operativa formal del embarque, invalidando las versiones previas y actualizando a los destinatarios.
El sistema debe responder a la consulta conversacional de estatus con el código del embarque, el resumen (ruta, modalidad), el estatus actual y la fecha/hora del último cambio.
US-023
🟡
RF-069
El sistema debe resolver la consulta de estatus estrictamente dentro del alcance de la cuenta del contacto; ante un código ajeno, responde idénticamente que ante un código inexistente.
US-023
🟡
RF-070
El sistema debe limitar las consultas de estatus a un máximo configurable por minuto por número (default 10), respondiendo con mensaje de espera al superarlo.
US-023
🟡
RF-071
El sistema debe desambiguar ante una consulta que admite más de un embarque presentando una lista corta de candidatos para que el cliente elija.
US-023
🟡
RF-072
El sistema debe mantener un historial cronológico ascendente de cambios de estatus por embarque, accesible al titular y al contacto aprobante con los comentarios externos, y al operador con los comentarios internos.
US-024
🟡
RF-073
El sistema debe permitir al operador actualizar manualmente el estatus de un embarque validando la transición contra la secuencia dinámica del embarque; toda reversión se registra como nueva entrada sin eliminar la anterior.
US-025
🟡
RF-074
El sistema debe enviar una notificación proactiva al aprobante del embarque y al titular de la cuenta cuando el estatus cambia; si son la misma persona, se envía una sola vez.
US-026
🟡
RF-075
El sistema debe reintentar las notificaciones proactivas fallidas con backoff y registrar los resultados en audit log; un fallo de notificación nunca revierte el cambio de estatus.
US-026
🟡
RF-076
El sistema debe respetar el opt-out del cliente al enviar notificaciones no críticas; las notificaciones clasificadas como críticas se envían con independencia del opt-out.
El sistema debe atender consultas conversacionales agregadas sobre embarques y cotizaciones del cliente, extrayendo filtros en lenguaje natural (fechas, origen, destino, modalidad, estatus).
US-028
🟡
RF-078
El sistema debe responder resultados pequeños inline por WhatsApp y, cuando el volumen supere un umbral configurable, derivar a una vista web con enlace firmado y OTP.
US-028, US-030
🟡
RF-079
El sistema debe combinar filtros libres con operador lógico AND por defecto, acumular filtros dentro de la conversación activa y confirmar al cliente cómo interpretó los filtros.
US-029
🟡
RF-080
El sistema debe generar enlaces a la vista web con vigencia de 1 hora y un código OTP corto (10 min por defecto, 3 intentos y 3 reenvíos máximos) enviados ambos por WhatsApp.
US-030
🟡
RF-081
El sistema debe permitir export CSV de la vista web con codificación UTF-8 con BOM y sanitización contra inyección de fórmulas (celdas que comienzan con =, +, @, -, \t).
US-030
🟡
RF-082
El sistema debe ofrecer un reporte de cotizaciones no aprobadas filtrable y exportable con las categorías de no-aprobación (vencida, cancelada, abandonada), accesible a los roles admin y operator.
US-031
🟡
RF-083
El sistema debe ofrecer reportes agregados de embarques por cuatro dimensiones (cliente, origen, destino, modalidad) con drill-down al detalle y sin export a Excel en v1.0.
El sistema debe detectar tres disparadores de handoff: criterio del agente ante combinación no soportada, pedido explícito del cliente, o detección de intención crítica.
US-033, US-058
🟡
RF-085
El sistema debe pedir consentimiento explícito del cliente antes de transferir a operador, salvo cuando el propio cliente lo haya solicitado activamente.
US-033, US-058
🟡
RF-086
El sistema debe transicionar la conversación al estado pending_handoff y detener las respuestas automáticas del agente durante ese estado.
US-033
🟡
RF-087
El sistema debe detectar intents críticos del cliente durante pending_handoff (cancelación del handoff, opt-out, emergencia) y actuar sobre ellos sin esperar al operador.
US-033
🟡
RF-088
El sistema debe notificar a los operadores disponibles cuando se abre un handoff, implementando bloqueo atómico para que sólo uno tome la conversación.
US-034
🟡
RF-089
El sistema debe aplicar un timeout configurable (default 15 minutos) al operador inactivo, devolviendo automáticamente la conversación al agente.
US-034, US-036
🟡
RF-090
El sistema debe proveer un chat en tiempo real en el backoffice con el historial completo de la conversación, con exclusividad del operador asignado.
US-035
🟡
RF-091
El sistema debe devolver la conversación al agente por tres caminos: cierre explícito por caso resuelto, cierre explícito por falta de respuesta del cliente, y cierre automático por desconexión del operador.
US-036
🟡
RF-092
El sistema debe enviar al cliente una notificación proactiva en toda devolución al agente (plantilla Meta aprobada si la ventana de 24 h está cerrada); ninguna devolución ocurre en silencio.
El sistema debe mantener un catálogo de niveles corporativos gestionado exclusivamente por el rol admin, con soft delete y referencia a una lista de precios.
US-037
🟡
RF-094
El sistema debe permitir al admin asignar un nivel corporativo a un cliente con fecha de inicio y vencimiento, garantizando a lo sumo un nivel activo por cliente en cualquier fecha dada.
US-038
🟡
RF-095
El sistema debe capturar el nivel corporativo vigente al emitir cada cotización como snapshot inmutable; el cambio posterior del nivel no afecta cotizaciones ya emitidas.
US-038, US-012
🟡
RF-096
El sistema debe sugerir parámetros frecuentes al cliente corporativo usando estadística de frecuencia sobre los últimos embarques (top-N configurable), sin usar técnicas de machine learning en v1.0.
US-039
🟡
RF-097
El sistema debe detectar mediante un job diario las asignaciones corporativas que entran en la ventana de aviso y emitir una alerta interna al grupo destinatario configurado, con flag antiduplicado por ciclo.
US-040
🟡
RF-098
El sistema debe enviar una notificación proactiva al cliente corporativo cuando su asignación entra en la ventana de aviso y el día del vencimiento efectivo; la notificación es crítica y se envía con independencia del opt-out.
El sistema debe proveer scripts de carga inicial de datos (L1..L6) idempotentes con opción --dry-run que muestre el resumen de cambios sin tocar la base de datos.
US-041
🟡
RF-100
El sistema debe reportar fila por fila los errores de la carga inicial sin abortar el resto, permitiendo al admin corregir el archivo y re-ejecutar.
US-041
🟡
RF-101
El sistema debe mantener el catálogo de servicios logísticos gestionado exclusivamente por admin, con aplicabilidad declarativa por combinación de modalidad/Incoterm/tipo, soft delete y composición de la secuencia de estatus.
US-042
🟡
RF-102
El sistema debe mantener los catálogos de modalidades, Incoterms y tipos de operación gestionados exclusivamente por admin con soft delete que preserva referencias históricas.
US-043
🟡
RF-103
El sistema debe permitir al price_manager y al admin editar listas de precios manualmente con tarifas fijas o variables y costo mínimo, alertando ante deltas porcentuales altos.
US-044
🟡
RF-104
El sistema debe ofrecer un export de plantilla Excel con todas las combinaciones válidas según la configuración actual, en dos modos: vacía y con precios actuales.
US-045
🟡
RF-105
El sistema debe procesar imports de precios desde Excel con preview obligatorio antes de aplicar, transaccionalidad atómica y sanitización contra inyección de fórmulas.
US-045
🟡
RF-106
El sistema debe permitir al admin gestionar los parámetros globales (vigencias, umbrales, ventanas, plazos, retenciones, matrices de clasificación y eventos auditables) agrupados por dominio, con audit log inmutable de cambios.
El sistema debe aplicar control de acceso por tres roles fijos (admin, operator, price_manager) tanto en UI como en API, con permisos no granulares y cambio de rol efectivo al siguiente login.
US-047
🟡
RF-108
El sistema debe ofrecer login email + password sobre HTTPS con política de contraseña declarada (mínimo 10 caracteres con mezcla obligatoria), bloqueo por intentos fallidos y recuperación por enlace de un solo uso.
US-048
🟡
RF-109
El sistema debe expirar la sesión del backoffice por inactividad con default configurable (sugerido 30 minutos).
US-048
🟡
RF-110
El sistema debe permitir al admin dar de alta, editar, desactivar y reactivar usuarios del backoffice, impidiendo dejar cero admins activos y bloqueando la auto-desactivación del admin que ejecuta la acción.
US-049
🟡
RF-111
El sistema debe ofrecer al admin la opción de forzar el cierre inmediato de las sesiones activas del usuario al cambiar su rol o desactivarlo, marcada por defecto para desactivaciones y degradaciones.
US-049
🟡
RF-112
El sistema debe registrar en un audit log inmutable las acciones declaradas en la matriz de eventos auditables y hacerlo consultable desde el backoffice por el rol admin con filtros combinables.
US-050
🟡
RF-113
El sistema debe conservar el audit log por un mínimo configurable (default 24 meses) y registrar cada purga automática como evento en el propio audit log.
US-050
🟡
RF-114
El sistema debe permitir exportar a CSV el resultado de una búsqueda en el audit log con los filtros aplicados.
US-050
🟡
RF-115
El sistema debe aplicar defensa contra prompt injection a través de un system prompt gestionado por FleteChat que no puede ser sobreescrito por el input del cliente; los intentos sospechosos se registran y no se ejecutan.
El sistema debe permitir al cliente solicitar por WhatsApp el ejercicio de sus derechos Ley 81 (acceso/portabilidad, eliminación), registrándolo en una bandeja del backoffice accesible al admin.
US-061
🟡
RF-117
El sistema debe procesar manualmente cada solicitud Ley 81 con verificación de identidad del solicitante por parte del operador antes de ejecutar la acción.
US-061
🟡
RF-118
El sistema debe generar para las solicitudes de acceso/portabilidad un paquete ZIP estandarizado (JSON estructurado + PDFs operativos + README explicativo) con la totalidad de los datos del titular.
US-061
🟡
RF-119
El sistema debe entregar el paquete Ley 81 por canales separados: enlace firmado al correo verificado del titular y OTP por WhatsApp al número verificado; la descarga es de un solo uso y el enlace expira en 24 horas configurables.
US-061
🟡
RF-120
El sistema debe responder a cada solicitud Ley 81 dentro del plazo legal aplicable (default 15 días hábiles, configurable por jurisdicción) y alertar al admin con anticipación configurable antes del vencimiento.
US-061
🟡
RF-121
El sistema debe preservar la contactabilidad del titular (número de WhatsApp y correo verificado) mientras una solicitud Ley 81 está en trámite, ejecutando la eliminación sólo al cierre del trámite.
US-061
🟡
RF-122
El sistema debe entregar la política de privacidad al cliente cuando la solicite por cualquier expresión conversacional o comando reconocido, apuntando a la URL oficial y a la versión vigente.
US-062
🟡
RF-123
El sistema debe registrar como evento del propio audit log la anonimización de PII en entradas históricas ejecutada al cumplir una solicitud válida de eliminación, con identificación de la solicitud que la disparó.
US-050, US-061
🟡
RF-124
El sistema debe permitir al cliente activar y desactivar opt-out sobre comunicaciones proactivas de forma granular (total o por categoría); los mensajes críticos no son opt-out-ables.
US-064
🟡
RF-125
El sistema debe clasificar cada notificación proactiva como crítica o no crítica según la matriz parametrizable y aplicar esa clasificación en horario y opt-out.
US-057, US-064
🟡
RF-126
El sistema debe encolar los mensajes no críticos disparados fuera de la ventana horaria configurada (default 08:00–22:00 America/Panama) y enviarlos al inicio de la siguiente ventana.
El sistema debe detectar la intención de cancelar o reiniciar el flujo en curso y confirmar con el cliente antes de ejecutar la acción; "cancelar" cierra el flujo y "reiniciar" cierra e inicia uno nuevo del mismo tipo.
US-055
🟡
RF-128
El sistema debe preservar los datos recolectados durante un error del sistema para que el cliente pueda retomar la operación sin reingresar información.
US-060
🟡
RF-129
El sistema debe declarar transparentemente ante el cliente los fallos técnicos que afectan la conversación (sin exponer detalles técnicos ni códigos internos) y escalar automáticamente a handoff si el fallo persiste tras los reintentos definidos.
US-060
🟡
RF-130
El sistema debe permitir al cliente mantener más de un contexto activo simultáneamente (default dos, configurable) sin mezclar datos entre contextos distintos.
US-056
🟡
RF-131
El sistema debe rechazar sin ambigüedad el consumo posterior de un enlace de aprobación formal ya formalizado; cualquier cambio requiere handoff con operador.
US-012
🟡
RF-132
El sistema debe declinar cortésmente y orientar al cliente hacia la historia de edición de datos cuando solicite rectificación de su información personal (el flujo es distinto al de eliminación).
Cada requerimiento comienza con "El sistema debe…".
El requerimiento se enuncia en términos de comportamiento observable, no de tecnología.
Cuando un requerimiento fija un valor numérico (timeout, tamaño máximo), ese valor se declara aquí y se referencia desde la historia.
Requerimientos transversales (logging, auditoría, idiomas) que aplican a todo el sistema se emiten una sola vez y se referencian desde cada historia afectada.
Los NFRs (tiempo de respuesta, retención, disponibilidad, seguridad) viven en v1.0-non-functional-requirements.md y no se repiten aquí.