Crear una aplicación de Certificado de Origen.

Sigue toda esta especificación como una tarea conectada: Grill → Plan → Goal → Review. Primero lee el documento completo e inspecciona solo lo autorizado.

• Grill: pregunta únicamente por conflictos importantes o requisitos previos ausentes y resuélvelos antes del plan.
• Plan: presenta un plan completo sin editar archivos y DETENTE hasta mi aprobación explícita.
• Goal: solo después, implementa el alcance acordado en hitos verificados.
• Review: revisa cada requisito sin editar y comunica hallazgos priorizados con pruebas. Solicita autorización para corregir cuestiones fuera del alcance aprobado. Entregar una aplicación funcional nunca anula la aprobación del plan. Las instrucciones detalladas de las cuatro etapas están al final de este mismo prompt.

Son estilos de instrucciones portables, no modos universales del agente. Un prompt no cambia su modo real ni sus permisos. Selecciona por separado un modo nativo si tu agente lo ofrece.

Construye la aplicación de Certificado de Origen (COO) especificada a continuación, con persistencia operativa, migraciones, gestión de referencias, operaciones documentales protegidas, una interfaz SOKit UI completa, adjuntos protegidos, notificaciones traducidas, salida de certificado de muestra y pruebas de aceptación automatizadas. No te detengas en una maqueta, un CRUD genérico, un esqueleto o un plan. Primero presenta el plan de implementación; ejecútalo cuando lo apruebe. Considera estos requisitos el alcance acordado del ejemplo, no preguntas cuyas respuestas deba inventar la IA. Pregunta solo por conflictos reales, dependencias no disponibles o decisiones que impidan implementar.

Modela la estructura del negocio con el exportador y las demás partes, referencias separadas de solicitud y emisión, transporte y mercancías, revisión asignada, correspondencia visible para el solicitante y notas internas restringidas. Los límites, la numeración, los permisos y el ciclo simplificado siguientes son reglas deliberadas de esta aplicación formativa, no requisitos legales. Excluye pagos, cancelación, reemisión, firmas oficiales, sellos e integraciones externas de certificación. Nunca presentes la salida como un certificado jurídicamente válido.

Inspecciona primero el repositorio y sus archivos de instrucciones. Si está vacío salvo metadatos o documentación, descubre los scaffolds de aplicación compatibles y propone un monorepo con la UI, los servicios, los contratos compartidos, las pruebas y la configuración de despliegue necesarios antes de crear archivos. Si ya existe una aplicación, conserva su topología y convenciones, localiza los componentes responsables y amplíalos sin crear otra aplicación ni reemplazar la configuración raíz. Si el proyecto es incompatible, explica el motivo y pide una decisión de migración antes de reestructurar.

Usa SMART para descubrir el perfil de framework aplicable y cargar las instrucciones relevantes en la revisión devuelta. Sigue los contratos compatibles de SOKit y SOKit UI, las direcciones explícitas de dependencias del monorepo y las convenciones Quarkus del proyecto para inyección, validación, persistencia, transacciones, configuración y pruebas. Reutiliza contratos generados y herramientas de compilación con versiones fijadas; no inventes APIs, copies builds antiguos ni cambies versiones silenciosamente. Informa con precisión de las instrucciones, los accesos o las dependencias que falten. Usa datos ficticios y no incluyas secretos en los ejemplos.

En un repositorio vacío, usa el scaffold compatible para crear un único monorepo. Define responsables concretos para la UI web, el servicio documental COO, la gestión de referencias, los contratos generados compartidos, las pruebas de integración/de extremo a extremo y la configuración de despliegue local. Las capacidades pueden compartir un servicio existente cuando el scaffold elegido lo permita; no crees un microservicio por tabla. La UI depende de contratos públicos generados, los servicios dependen de sus propios componentes de dominio/persistencia y las bibliotecas compartidas no dependen de aplicaciones concretas. Los comandos raíz coordinan compilaciones y verificaciones de componentes.

En una aplicación existente, localiza y amplía esos componentes en su sitio, conservando el gestor de paquetes, el sistema de compilación, las rutas, la autenticación y los límites entre módulos. No crees otra aplicación ni reemplaces archivos raíz. En un proyecto incompatible, describe la incompatibilidad y obtén una decisión de migración antes de reestructurar. Entrega un mapa de arquitectura, esquema/migraciones, DTO y contratos generados compatibles, pantallas y operaciones implementadas, mensajes traducidos, datos de prueba, pruebas, un ejemplo de variables de entorno sin secretos, instrucciones de arranque local y una lista que relacione requisitos y pruebas. Descubre la revisión y el perfil aplicables de SMART y utiliza sus contratos vigentes de SOKit, SOKit UI y Quarkus; los nombres lógicos de este documento no son APIs de framework inventadas.

Exige autenticación en todas partes excepto en la entrada de inicio de sesión. Resuelve organización solicitante, organismo emisor y elegibilidad del personal desde la identidad y las pertenencias organizativas fiables. Nunca aceptes IDs de propietario, roles, identidad del revisor, estado, referencias de negocio o actores de auditoría desde campos editables del solicitante. La cuenta solicitante solo puede actuar por un exportador mediante un mandato verificado en el servidor; en los datos de ejemplo, la organización solicitante y el exportador son la misma.

Implementa estos permisos lógicos mediante el sistema de autorización compatible de la aplicación: el Solicitante puede crear, buscar, leer, editar y presentar registros de una organización en la que tenga pertenencia activa de solicitante. El Revisor puede leer registros asignados de su organismo emisor y devolver, aprobar o rechazar un registro SUBMITTED. El Supervisor de revisión puede ver la cola de ese emisor y asignar/reasignar revisores elegibles, con motivo obligatorio; ser supervisor no concede por sí solo autoridad para decidir. El Funcionario emisor puede emitir registros APPROVED de su organismo emisor. El Administrador de referencias puede gestionar catálogos, pero ese rol por sí solo no le concede acceso a documentos. El personal autorizado del emisor puede leer notas internas de registros dentro de su ámbito permitido; los solicitantes nunca pueden leerlas, aunque otro rol pudiera exponerlas en su propia solicitud.

Prohíbe revisar o emitir solicitudes propias: quien decide no puede ser el creador ni un miembro solicitante de la organización propietaria. El funcionario emisor también debe ser distinto de quien aprobó. Comprueba en el servidor tanto el permiso de operación como el ámbito del registro para búsquedas, lecturas, descubrimiento de acciones, modificaciones, historial, correspondencia, salida de muestra y descargas. Un revisor sin asignación no puede descubrir registros de otro revisor. Aplica consistentemente la convención de denegación de acceso de la aplicación sin revelar información. Prueba URLs directas y peticiones falsificadas; no solo botones ocultos.

Asigna cada organización solicitante a su organización emisora mediante configuración fiable del servidor; rechaza la creación sin una ruta autorizada. La elegibilidad del personal incluye pertenencia activa, permiso de operación y todas las reglas de separación de funciones. Compruébalo al resolver revisores y emisores predeterminados, además de al ejecutar la operación.

Usa la identidad versionada y el mecanismo de versión esperada del e-documento compatible. El agregado contiene: documentId inmutable; version; state; ownerOrganizationId, createdBy, createdAt y updatedAt fiables; issuingOrganizationId; assignedReviewerId; submittedAt; resubmissionCount inicialmente 0; approvedBy/approvedAt; requestReference/requestDate; issuanceReference/issuedAt; validFrom/validUntil. Almacena instantes en UTC y fechas de negocio sin hora. Usa una zona horaria de negocio configurable por emisor, UTC en la demo. Modela los campos controlados por el servidor con DTO restringidos por operación, no con un DTO de asignación masiva.

Incluye instantáneas de exportador y destinatario: identifier (1–64 caracteres), legalName (1–200), address (1–500), referencia de país, contactName (opcional, hasta 200), email (opcional, válido y hasta 254), phone (opcional, hasta 32). Ambas partes son obligatorias al presentar. Las partes adicionales forman una colección hija ordenada con ID de fila estable, rol BROKER o NOTIFY_PARTY y los mismos campos. Son opcionales, máximo 10, sin duplicados del par rol/identificador. Mantén la identidad del solicitante separada de estas instantáneas comerciales. Obtén la instantánea de identidad del organismo emisor de configuración fiable.

Campos de envío obligatorios al presentar/volver a presentar: originCountry, destinationCountry, finalDestinationCountry, transportMode, expectedExportDate, loadingLocation, unloadingLocation, finalUnloadingLocation. Los tres lugares deben pertenecer respectivamente a los países de origen, destino y destino final. Permite que destino y destino final coincidan. Para SEA exige vesselName; ROAD, vehicleRegistration; AIR, flightNumber; RAIL, trainReference; cada uno de hasta 100 caracteres. Los demás campos específicos de modo son opcionales y se omiten de la salida si están vacíos. La fecha prevista de exportación debe ser igual o posterior a la fecha de negocio de la operación de presentación o nueva presentación. No vuelvas a aplicar esa regla de fecha futura en revisión o emisión posteriores.

Implementa nueve catálogos: países; lugares con país padre; modos de transporte; tipos de embalaje; unidades suplementarias; monedas con precisión de unidad mínima; clasificaciones de mercancías; criterios de origen; tipos de adjunto. Cada registro tiene código estable (1–32), etiquetas traducidas EN/FR/ES/AR (1–200), indicador activo, fechas opcionales inclusivas validFrom/validTo y versión. Los códigos son únicos dentro de cada catálogo e inmutables tras crearlos; validTo no puede preceder a validFrom. Los registros referenciados no pueden eliminarse físicamente: desactívalos. Las nuevas presentaciones exigen referencias activas y vigentes en su fecha.

Incluye búsqueda paginada por código/etiqueta, filtros de activo/vigente, etiquetas traducidas con una alternativa documentada y pantallas de crear/editar/desactivar restringidas a administradores de referencias. Los usuarios autenticados pueden leer los catálogos aplicables. Los selectores de lugares filtran por el país elegido. Persiste instantáneas de código y etiqueta visible en las versiones documentales para que renombrar o desactivar referencias no cambie el significado histórico. Revalida solicitudes editadas o vueltas a presentar; no invalides retroactivamente un certificado emitido.

Carga países, lugares, unidades, monedas y clasificaciones claramente ficticios con prefijo DEMO para las pruebas; incluye comportamiento de modos SEA/ROAD/AIR/RAIL, tipos de adjunto INVOICE y ORIGIN_EVIDENCE y criterios ilustrativos DEMO_WHOLLY_OBTAINED y DEMO_VALUE_CONTENT. Este último exige percentageExportPrice; el primero lo prohíbe. No importes aranceles ni reglas oficiales de origen inventados. Las importaciones de catálogos reales quedan fuera de la demo hasta disponer de fuente y licencia autorizadas.

Almacena de 1 a 100 líneas de mercancías ordenadas. Cada línea tiene ID estable distinto de sequenceNumber, referencia de clasificación, commercialDescription (1–255), marksAndNumbers (1–255; usa el valor explícito NO MARKS si no hay marcas), packageType, packageCount (entero positivo), supplementaryQuantity y unidad, grossWeightKg, netWeightKg, originCriterion, percentageExportPrice opcional, invoiceReference (1–64), invoiceDate, invoiceCurrency e invoiceValue. Exige todos los campos excepto el porcentaje condicional al presentar o volver a presentar. Los números de secuencia son únicos y consecutivos; reordenar debe conservar los IDs.

Usa aritmética decimal, no coma flotante binaria. Cantidades y pesos son positivos con un máximo de tres decimales; el peso neto no supera al bruto. El valor de factura es positivo, precisión decimal 18 y escala según las 0–3 posiciones de unidad mínima de la moneda; rechaza precisión excesiva en vez de redondear silenciosamente la entrada. El porcentaje es decimal de 0 a 100 inclusive, máximo dos decimales, obligatorio solo para DEMO_VALUE_CONTENT y ausente para DEMO_WHOLLY_OBTAINED. Conserva como cero un porcentaje cero permitido. La fecha de factura no puede ser posterior a la fecha de negocio de presentación/nueva presentación ni a la fecha prevista de exportación.

Calcula totales de solo lectura por moneda sumando valores de línea; invoiceValue significa el valor asignado a esa línea, no toda la factura repetida en cada línea. Las líneas que comparten referencia/fecha de factura deben usar la misma moneda. Muestra por separado totales de bultos y pesos; nunca sumes cantidades suplementarias de unidades distintas ni conviertas monedas implícitamente. Aplica límites, tipos de campo y coherencia numérica incluso al guardar un borrador incompleto, pero reserva obligatoriedad y comprobaciones de fecha de presentación para presentar/volver a presentar. Devuelve errores traducidos específicos por línea y campo sin descartar entradas válidas.

Usa exactamente estos estados persistidos centrales: DRAFT, SUBMITTED, RETURNED, APPROVED, REJECTED, FINALIZED (mostrado como Emitido). Revisar es una actividad sobre SUBMITTED, no otro estado. Genera acciones desde los contratos compatibles de e-documentos; no expongas un campo de estado editable. Cada modificación exige el expectedVersion actual y ejecuta autorización, validación, cambio de estado e historial en una sola transacción. Para CREATE_DRAFT, usa el contrato inicial compatible en lugar de exigir una versión anterior del documento.

CREATE_DRAFT

sin registro → DRAFT; Solicitante; datos editables de partes/envío/mercancías/adjuntos, posiblemente incompletos.

SAVE_DRAFT

DRAFT → DRAFT; Solicitante propietario; mismos campos editables.

SUBMIT

DRAFT → SUBMITTED; Solicitante propietario; validación completa de obligatoriedad, catálogos y pruebas; asigna referencia/fecha de solicitud y submittedAt en la primera presentación. Resuelve el revisor predeterminado del emisor desde personal activo fiable; falla claramente sin confirmar cambios si ninguno es elegible. El solicitante no puede elegir ni suplantar a ese revisor.

RETURN

SUBMITTED → RETURNED; Revisor asignado; motivo público de 10–2000 caracteres y nota interna opcional de hasta 4000, sin editar mercancías.

SAVE_CORRECTION

RETURNED → RETURNED; Solicitante propietario; datos comerciales editables, mismas reglas relajadas de borrador.

RESUBMIT

RETURNED → SUBMITTED; Solicitante propietario; validación completa de presentación y resumen público de correcciones de 10–2000; incrementa resubmissionCount, conserva referencia/fecha de solicitud y mantiene al revisor asignado si sigue siendo elegible; en caso contrario, resuelve el predeterminado elegible configurado.

APPROVE

SUBMITTED → APPROVED; Revisor asignado; validFrom y validUntil, comentario público opcional y nota interna opcional; vuelve a comprobar campos comerciales y pruebas obligatorios, excluyendo las reglas de fecha futura exclusivas de presentación; guarda actor/hora de aprobación.

REJECT

SUBMITTED → REJECTED; Revisor asignado; motivo público obligatorio de 10–2000 y nota interna opcional.

REASSIGN

SUBMITTED → SUBMITTED; Supervisor de revisión del emisor; ID de revisor elegible y motivo interno de 10–2000; registra revisor anterior/nuevo y actor en historial restringido. No concede permiso para editar datos comerciales.

ISSUE

APPROVED → FINALIZED; Funcionario emisor que respeta la separación de funciones; sin campos comerciales editables; valida instantánea aprobada y vigencia, asigna referencia/hora de emisión e inmoviliza la instantánea emitida atómicamente. En este alcance central no se permiten devolución, edición, eliminación, cancelación ni reemisión desde APPROVED, REJECTED o FINALIZED. Conserva todas las versiones anteriores. Las operaciones repetidas o concurrentes no deben duplicar transiciones, numeración ni notificaciones: rechaza modificaciones obsoletas o repetidas con un conflicto recuperable y proporciona el estado actual autorizado. Solo una emisión concurrente puede completarse.

Asigna en el servidor referencias de solicitud COO-REQ-{year}-{six-digit-sequence} en la primera presentación correcta, únicas por organismo emisor/año. Asigna COO-ISS-{year}-{six-digit-sequence} solo al emitir correctamente, con secuencia separada y el mismo ámbito de unicidad. Usa asignación atómica en base de datos y restricciones de unicidad; nunca cuentes filas existentes ni confíes en números del cliente. Se admiten saltos. Las fechas del servidor usan la zona horaria de negocio del emisor. Las referencias de negocio no son claves primarias ni credenciales de acceso.

En esta demo, aprobar exige validFrom igual o posterior a la fecha de negocio de aprobación y validUntil = validFrom más 89 días, dando 90 días naturales inclusivos. El valor predeterminado de validFrom es la fecha de negocio de aprobación. Emitir exige que la fecha de negocio actual esté dentro del intervalo; una aprobación caducada no puede emitirse, y corregirla queda fuera de este ejemplo central. Estas reglas son formativas e ilustrativas, no una política legal de vigencia de certificados.

Entrega una vista previa accesible del certificado y un PDF de muestra con descarga protegida desde la instantánea emitida inmutable. Ambos deben mostrar visiblemente MUESTRA — NO ES UN CERTIFICADO OFICIAL, incluir referencias/fechas de solicitud y emisión, vigencia, emisor, exportador, destinatario, envío, mercancías y totales por moneda, y omitir notas internas y datos privados de contacto. Antes de emitir, muestra una vista previa de borrador claramente etiquetada y sin número de emisión; renderizarla no cambia el estado. Un fallo de renderizado tras emitir debe permitir reintento sin volver a emitir ni asignar otra referencia. Reutiliza la integración de renderizado compatible, informa explícitamente de dependencias no disponibles y no la sustituyas por un botón de descarga falso.

Almacena correspondencia pública y notas internas en modelos hijos y proyecciones de respuesta separados. Cada entrada tiene ID inmutable, asociación con documento/versión, autor/hora fiables, cuerpo de texto plano y contexto de operación. Los motivos de devolución/rechazo y resúmenes de corrección aparecen en la correspondencia visible para el solicitante. Las notas internas solo son visibles para personal autorizado del emisor dentro del ámbito del registro; quedan excluidas de DTO del solicitante, historial público, búsquedas, notificaciones, logs y salida de muestra. Las entradas solo pueden añadirse; no se editan ni eliminan silenciosamente. La UI central añade mensajes mediante las operaciones especificadas; no inventes un chat separado.

Cada fila de adjunto contiene su propio ID estable, identidad auténtica de archivo bucket, referencia de tipo de adjunto, nombre/MIME/tamaño verificados, persona/hora de carga y asociación con versión. Usa la carga bucket y el mapeo de adjuntos compatibles; distingue ID local de UI, ID persistente de fila e ID bucket. Valida en el servidor las respuestas auténticas de carga y su propiedad. Permite PDF/JPEG/PNG, hasta 10 MiB por archivo y 10 adjuntos por solicitud. Rechaza archivos vacíos y contenidos incompatibles o que no coincidan mediante validación de servidor compatible; la declaración MIME del navegador no basta. Integra el analizador exigido por la política de almacenamiento elegida e impide presentar archivos pendientes o rechazados.

Exige al menos un adjunto INVOICE y uno ORIGIN_EVIDENCE al presentar, volver a presentar y aprobar. Solo un Solicitante propietario en DRAFT o RETURNED puede añadir/eliminar adjuntos. Las descargas exigen comprobar acceso al documento/versión padre y recuperación autorizada de corta duración; nunca URLs públicas de objetos. Conserva archivos referenciados por versiones históricas. Las cargas temporales sin adjuntar caducan tras 24 horas mediante un proceso de limpieza que comprueba referencias; nunca borres un archivo referenciado por un documento actual o histórico. Muestra progreso/reintento de carga y conserva el formulario si falla la carga o el guardado.

Implementa plantillas traducidas EN/FR/ES/AR con destinatarios resueltos por el servidor y enlaces a registros que exijan autenticación. Al presentar/volver a presentar, notifica al revisor asignado. Al devolver o rechazar, notifica a la cuenta solicitante que presentó. Al aprobar, notifica al funcionario emisor elegible configurado para el organismo y comunica al solicitante Aprobado, pendiente de emisión. Al emitir, notifica al solicitante que el certificado de muestra está disponible. Al reasignar, notifica al nuevo revisor. Falla antes de confirmar la operación correspondiente si falta configuración obligatoria de personal; nunca aceptes direcciones arbitrarias de destinatarios como entrada de la operación.

Persiste una entrada de outbox de notificaciones duradera en la misma transacción de base de datos que la operación documental. Un worker entrega solo entradas confirmadas a un receptor local en desarrollo. Usa una clave única de evento compuesta por ID de documento, versión confirmada, tipo de evento y destinatario; reintenta fallos transitorios al cabo de 1, 5 y 30 minutos y después marca fallo para inspección operativa y reintento explícito. La entrega es al menos una vez, con deduplicación donde se admita, no una promesa de exactamente una vez. Un fallo de notificación no debe revertir ni describir incorrectamente la operación documental ya confirmada. Un rollback no crea ninguna notificación entregable.

Audita cada operación correcta con documento/versión, estado anterior/nuevo, actor autenticado, hora y metadatos seguros de decisión. Separa los detalles restringidos de asignación/notas internas de la cronología visible para el solicitante. Registra acciones denegadas y fallos de entrega sin contenidos de archivos, credenciales ni notas privadas. Verifica autorización para cada versión histórica y recuperación de salida, no solo para el documento actual.

Usa los componentes SOKit UI y el lenguaje visual de la aplicación. Genera un espacio del solicitante con acción Crear solicitud y tabla paginada: referencia de solicitud, exportador, destino, estado, última actualización y referencia de emisión. Filtra por texto de referencia, estado e intervalo de fechas. Ordena por actualización más reciente de forma predeterminada. Incluye estados vacío y de carga útiles, y error recuperable con reintento. En teléfonos, convierte filas en tarjetas legibles sin perder acciones ni estado.

Genera un espacio del emisor con Mis solicitudes asignadas, cola Sin asignar/asignación visible solo para supervisores y Aprobadas pendientes de emisión visible para funcionarios emisores elegibles. Las filas muestran solicitud, solicitante/exportador, fecha de presentación, estado y revisor asignado; los filtros incluyen estado, fecha y revisor cuando se autorice. Los enlaces abren el documento autorizado real. No muestres a todos los usuarios el espacio de cada rol limitándote a desactivar botones.

La cabecera documental muestra estado, referencia de solicitud, referencia de emisión si se ha emitido, versión, última actualización y solo acciones autorizadas por el servidor. Usa una barra lateral de secciones en escritorio y un selector de sección móvil para Partes, Envío, Mercancías, Pruebas, Correspondencia e Historial; muestra Notas internas solo al personal autorizado. Mantén disponibles totales contextuales y resumen de validación. Partes incluye bloques separados de exportador/destinatario y un repetidor opcional de partes adicionales. Envío utiliza selectores dependientes de país/lugar y campos por modo. Mercancías utiliza tabla resumen y editor de línea accesible con añadir/editar/eliminar/reordenar, entradas decimales y totales por moneda. Pruebas muestra tipo, tamaño, progreso de carga y acciones autorizadas de descargar/eliminar.

Guardar borrador y Presentar son acciones distintas; Devuelto muestra el motivo del revisor, correcciones editables y resumen obligatorio antes de Volver a presentar. Los diálogos Devolver/Rechazar exigen motivo público y separan claramente la entrada opcional de nota interna. Aprobar muestra resumen comercial de solo lectura, fechas de vigencia y confirmación explícita. Emitir muestra datos aprobados y vigencia con confirmación explícita; impide clics duplicados durante la espera, pero apóyate en la protección de concurrencia del servidor. Las vistas Emitido y Rechazado son de solo lectura. Advierte antes de abandonar cambios sin guardar. Ante un conflicto de versión obsoleta, conserva la entrada intentada, explica el conflicto y ofrece recarga/conciliación sin sobrescritura automática.

Proporciona etiquetas, validación, nombres de estados, UI de correspondencia y plantillas de notificación completos en EN/FR/ES/AR. Conserva sin cambios el contenido comercial introducido por usuarios. Usa el idioma preferido del destinatario en notificaciones y el elegido en la UI para formatos de fechas/números. El árabe es RTL, con identificadores LTR aislados y acciones en orden correcto. La salida de muestra utiliza el idioma elegido conservando códigos y valores comerciales almacenados.

Verifica diseños a 360, 768 y 1440 píxeles. Los formularios usan una columna en teléfonos y columnas agrupadas con sentido en escritorio; los controles nunca desbordan y los elementos adherentes nunca cubren entradas ni acciones. Asegura acceso por teclado, foco visible, etiquetas descriptivas, anuncios de validación para lectores de pantalla, foco en el resumen de errores y restauración del foco al cerrar diálogos. No comuniques el estado solo por color. Distingue fallos de permisos, red, carga y validación sin perder entradas.

Usa las instrucciones vigentes de SMART para operaciones/grupos de validación SOKit, contratos generados, seguridad por registro, referencias, mapeo bucket y notificaciones. Sigue el perfil Quarkus elegido para CDI, persistencia, responsabilidad transaccional, configuración, validación DTO y pruebas; sin desalinear versiones de plataforma, añadir dependencias sin gestionar, exponer entidades como entrada pública ni inventar nombres de API. Usa migraciones con restricciones/índices, consultas paginadas acotadas y planes de carga deliberados; evita consultas N+1. Mantén secretos fuera del control de versiones, no registres datos personales y utiliza las protecciones compatibles de autenticación/CSRF/origen adecuadas para la aplicación existente.

Crea el emisor ficticio Demo Chamber, solicitante/exportador Demo Export Ltd, destinatario Demo Import Ltd y una segunda organización solicitante independiente. Carga identidades distintas de solicitante, revisor asignado, otro revisor, supervisor, funcionario emisor y administrador de referencias mediante el mecanismo compatible de autenticación local de prueba; sin credenciales de producción. Proporciona un envío válido de dos líneas, los nueve catálogos de referencia y archivos inocuos de factura/prueba de origen. Usa un reloj de pruebas controlado para reproducir las reglas de fechas.

Automatiza este recorrido completo: crear borrador incompleto → guardar → completar partes/envío/dos líneas/pruebas → presentar y obtener una referencia de solicitud → el revisor asignado devuelve con motivo público y nota interna privada → el solicitante solo ve el motivo → corregir/guardar/volver a presentar con la misma referencia y resubmissionCount 1 → aprobar con vigencia de 90 días → otro funcionario emisor emite una única vez → recuperar un PDF de muestra con marca de agua desde la instantánea congelada. Verifica estado, versión, actor, historial, acciones permitidas y entradas de outbox en cada transición. Cubre también el recorrido terminal de rechazo.

Las pruebas negativas deben cubrir cada combinación de rol/estado de la matriz, campos de propietario/revisor falsificados, lectura/búsqueda/historial/archivos entre organizaciones, revisión sin asignación y autorrevisión, aprobación/emisión por la misma persona, filtración de notas internas, referencias inactivas, lugares de país incorrecto, campos de modo/pruebas ausentes, fechas/precisión/pesos inválidos, totales de monedas distintas, IDs de líneas cambiados/reordenados, cargas sobredimensionadas o falsificadas, fallos de carga/guardado y limpieza de archivos temporales. Prueba dos presentaciones/emisiones concurrentes, ediciones obsoletas, vigencia caducada, numeración única, salida emitida inmutable, rollback sin notificación, reintento/deduplicación de entrega, reintento de renderizado sin reemisión y acceso directo no autorizado a endpoints.

Ejecuta las compilaciones de componentes, comprobaciones de tipos, lint, pruebas backend/de integración y verificaciones UI de extremo a extremo pertinentes, incluidos los cuatro idiomas y tamaños adaptables. Entrega una matriz requisito/prueba con resultados reales, lista de componentes/archivos cambiados, comandos de arranque local, instrucciones de migración/datos de prueba y configuración operativa. Indica exactamente qué comprobaciones no se pudieron ejecutar y por qué. Un hito solo está terminado cuando funciona su conducta observable; no declares una aplicación completa si solo existen scaffolds, mocks o un plan.

Cuestiona mi especificación antes de implementarla. Identifica requisitos ausentes, contradicciones y supuestos arriesgados. Haz una pregunta concreta cada vez, explica por qué importa y ofrece alternativas útiles con una recomendación. Cubre actores y propiedad, campos, fuentes de referencias, transiciones, validación, recuperación, notificaciones, UI y aceptación. Separa decisiones confirmadas de supuestos. No escribas código ni decidas políticas de negocio silenciosamente. Termina con un registro breve de decisiones y bloqueos pendientes.

Inspecciona el repositorio y produce un plan con todas las decisiones para el alcance acordado sin modificar archivos. Mapea modelo, referencias, componentes responsables, interfaces, matriz de estados/operaciones/permisos, validación por operación, migraciones, archivos protegidos y efectos tras commit. Incluye rutas UI, accesibilidad, EN/FR/ES/AR, fallos y pruebas de aceptación. Divide en hitos revisables e identifica los puntos reales de build y comprobación. Resuelve conmigo ambigüedades importantes antes de finalizar; no comiences a implementar.

Implementa solo el objetivo y los hitos ya acordados. Si falta alcance o plan aprobado, pídelo primero. Avanza en pasos revisables: base y referencias, ciclo documental y acceso, UI, adjuntos y notificaciones, y verificación completa. Ejecuta comprobaciones relevantes tras cada cambio significativo, investiga fallos y aporta evidencia. Conserva trabajo ajeno al cambio. No amplíes a despliegue, migraciones destructivas, mensajes externos o funciones no acordadas sin autorización. Detente y explica bloqueos que necesiten decisión o acceso; no afirmes que pasó una prueba no ejecutada. Termina con archivos, resultados reales y trabajo pendiente.

Revisa la implementación frente a especificación, plan e instrucciones SMART actuales. No edites archivos. Prioriza corrección, permisos en registros/búsquedas/historial/archivos, transiciones, validación, transacciones, fallos de notificación, dependencias, configuración, pruebas, accesibilidad y cuatro idiomas. Fundamenta cada hallazgo con archivo/ubicación, desencadenante, impacto y solución recomendada. Distingue defectos de mejoras opcionales y evidencia ausente. Si no hay hallazgos accionables, dilo y explica límites de verificación; no inventes problemas.