Arquitectura: referencia historica y etapa B

Ver ARCHITECTURE_DECISIONS para las decisiones vigentes del repositorio, operaciones y cuotas.

Arquitectura y plan completo de implementacion

Exportacion para revision: 05/11/2026, Europe/Madrid. Contenido completo de los informes fuente, no resumen. No se alteran los originales. Los nombres personales no imprescindibles se sustituyen por etiquetas; los ejemplos tecnicos y la estructura se conservan. No se exportan credenciales ni evidencias crudas. Las conclusiones, contadores y autorizaciones de cada informe son HISTORICOS: no habilitan operaciones. El encargo actual prioriza exclusivamente enumeracion por fechas. La fecha mas reciente y el suplemento de esta revision prevalecen sobre planes anteriores.

Fuentes completas incluidas

---

Documento fuente: 01_EXECUTIVE_REPORT.md

Consolidacion: informe ejecutivo 05/11/2026

Solo auditoria y documentacion; cero llamadas GLS. Se inspecciono VM214, PostgreSQL, codigo real, configuracion, fuentes y originales. No se abrio el enlace publico, instalo servicios, cambio puertos o realizaron migraciones.

Hechos principales

1. iClientes es la integracion domestica recomendada por GLS Iberia segun la comunicacion de Juan; ShipIT no se selecciona para esta operativa. 2. Creacion/consulta SOAP demostradas; Anula aceptada con resultado 0. Extranet mostro despues anulacion y cierre, segun Juan. No nueva API hoy. 3. Falta el contrato de descubrimiento por cuenta/fecha. GetEnvios sigue candidata, no descartada por tener XML generico; no aparecio un IN/OUT extra. 4. Historico Extranet observado de noviembre 2025; API antigua aun no probada. 5. Plataforma sana en pruebas locales health/ready 200. Puerto 88 activo; 80 libre. BD local PostgreSQL 15.19, 39 tablas, 386 columnas, 59 indices, 103 restricciones y 13 migraciones. Repositorio de expediciones sin poblar. 6. Registro tecnico en ficheros mas amplio que indices SQL: 54 Markdown frente a 31 knowledge_articles/31 documents. No se sincronizaron indices SQL hoy. 7. Existe base reutilizable, no una plataforma operativa completa. La alta productiva general esta bloqueada; Anula fue auxiliar aislado, no panel.

Respuestas a los 14 criterios de cierre

Contadores reales

PRODUCCION iClientes 10; SOAP TEST 6; REST 5 registrados; global 21. Historico rotulado TEST/laboratorio 11 contiene SOAP TEST y REST, no es una cuota oficial. REST: 2 OAuth, 1 ShipIT Parcel Shops, 1 catalogo T&T, 1 dataset. SOAP registrado: 4 altas (3 aceptadas y 1 error HTTP), 9 GetExpCli, 2 recuperaciones EtiquetaEnvioV2, 1 Anula. No son 21 envios.

Riesgos y decisiones

Prioridad inmediata: contrato de listado y profundidad, restauracion de backup, scope de cuenta, integridad de la ingesta y auditoria completa de cada HTTP. No afirmar que cache significa historico, 100 es retencion o 20 es batch SOAP. Las dependencias instaladas se inventarian sin declarar revision CVE actual.

Se entregan maestro, inventarios y 14 informes/anexos vinculados desde GLS Integration Master. El contenido oficial reciente transmitido por Juan se incorpora como fuente fechada, no se fabrica un correo ni captura Extranet que no se haya recibido.

Auditoria detenida para revision/aprobacion. Ningun plan queda activado.

---

Documento fuente: 07_INFRASTRUCTURE_AUDIT.md

Auditoria de infraestructura VM214

05/11/2026. Solo VM transport-hub y lectura de su configuracion Proxmox. No otras VMs, proxy de empresa, DNS externo, impresora ni servicios GLS.

Estado observado

• Debian GNU/Linux 12, Python 3.11, 2 vCPU. Proxmox asigna 2048 MiB,

balloon 1536 MiB; guest MemTotal 1502724 kB. No son 4 GB.

• Disco 32 GB, filesystem de unos 33,6 GB, 8% usado y unos 29,9 GB

disponibles en la lectura. No prueba capacidad infinita de POD.

• IP [IP INTERNA OMITIDA], hostname transport-hub; qemu-guest-agent activo.
• transport-hub.service activo/running, usuario/grupo transport-hub,

WorkingDirectory [RUTA INTERNA OMITIDA] ExecStart [RUTA INTERNA OMITIDA]

• Restart on-failure, PrivateTmp yes, NoNewPrivileges yes,

CapabilityBoundingSet cap_net_bind_service; ProtectSystem no.

• ASGI FastAPI/Uvicorn + Jinja2 server-side; no React/Node ni contenedor

requerido por la aplicacion. Un proceso web observado, no worker dedicado.

Puertos y salud local

TCP 88 escucha en 0.0.0.0 mediante Uvicorn; 80 no esta escuchando. SSH 22 en IPv4/IPv6; PostgreSQL 5432 solo 127.0.0.1 y ::1. Resolucion local en 53 y LLMNR 5355. No listener CUPS 631 durante la auditoria.

GET local 127.0.0.1:88/health y /ready: HTTP 200. Ready confirma app, PostgreSQL, clave maestra y 13 migraciones. Se inspecciono antes su codigo: no llama GLS ni aplica migraciones en esos handlers. No se importo/inicio otra instancia de web.py, cuyo startup SI aplica migraciones y sincroniza metadata de documentos REST.

No se detecto Nginx/Apache/Caddy/HAProxy o Cloudflare Tunnel activo en VM. La publicacion externa conocida pertenece a infraestructura ajena a este alcance: no se audita ni se declara segura/rota. Bind 0.0.0.0 no demuestra por si solo exposicion Internet. nft/ufw no disponibles como comandos; no se concluye que no haya filtrado en host/router. Nada fue modificado.

Tareas y procesos

14 servicios running, incluidos PostgreSQL15, SSH, agente y sistema base. 8 timers del sistema (apt, logrotate, dpkg backup, man-db, fstrim, e2scrub, tmpfiles); ninguno de TH/GLS. crontab no instalado; no jobs TH hallados en ficheros cron inspeccionados. Sin Redis/Celery/worker ni sincronizacion periodica GLS identificada. No iniciar una tarea para probar ausencia.

Dependencias instaladas, sin revision CVE remota

FastAPI 0.92.0; Starlette 0.26.1; Uvicorn 0.17.6; Jinja2 3.1.2; cryptography 38.0.4; psycopg2 2.9.5; argon2-cffi 21.1.0; python-multipart 0.0.5; Pillow 9.4.0; PyYAML 6.0; httpx 0.23.3; pytest 7.2.1. PostgreSQL 15.19. CUPS 2.4.2 y Ghostscript instalados, no utilizados ni arrancados para esta auditoria.

pyproject sigue version 0.1.0 y descripcion fase0, sin declarar dependencias runtime completas. No es inventario reproducible de produccion. Proponer manifest/lock y revision de seguridad/compatibilidad en fase propia; no atribuir CVEs ni asegurar versiones actualizadas sin una revision autorizada.

20 ficheros de tests, 169 funciones test detectadas por AST sin errores de sintaxis. No se ejecutaron tests integrados ni se afirma que todos pasen hoy.

Secretos, logs y backups

master.key modo600 usuario servicio; UID test/production en iclientes-secrets modo600, cifrados; credenciales REST cifradas en BD. .env legacy root600. Argon2id local y cookies firmadas, HttpOnly/SameSite=Lax/8h; Secure no activado en el codigo actual por HTTP. Misma clave local para cifrado/firma requiere plan de separacion/rotacion aprobado, no cambio unilateral.

Logs en [RUTA INTERNA OMITIDA] y journal. No se replican logs completos en KB: pueden contener PII/sondas. Auditoria revisa control de redaccion y metadata; originales SOAP cifrados separan evidencia de vistas sanitizadas.

Se hallaron archivos de respaldo de documentacion/config/codigo (p.ej. pre-iclientes-uid-20261019.tar.gz) y deployment snapshots. No se localizo un pg_dump reciente/plan restaurado en las rutas inspeccionadas. archive_mode off y timers de dpkg NO son un backup de PostgreSQL/secretos/activos TH. No se auditaron posibles backups Proxmox externos ni se declara su ausencia.

Gate antes de historico: politica aprobada de BD+activos cifrados+clave/ keyring en backup seguro separado, manifiesto de hashes, consistencia y restauracion de prueba autorizada. Si se pierde master.key y no hay copia, los cifrados antiguos no son recuperables por resetear una clave.

Propuesta de despliegue, no aplicada

No aumentar recursos ahora. Medir carga de parseo/POD antes de concurrencia. Separar arranque de migraciones y runtime antes de dos interfaces; servicio operativo futuro en 80 y tecnico en 88 con nucleo/BD comunes. No dos copias de codigo, ningun puerto/proxy/firewall nuevo durante esta fase.

---

Documento fuente: 09_SYNC_AND_POD_DESIGN.md

Sincronizacion, importacion y POD: diseno sin ejecucion

Objetivo desde agosto 2025, condicionado a alcance API demostrado y contrato de descubrimiento/exportacion. Ningun job/worker/timer se instala o activa.

Una cola comun y dos pasadas

Reutilizar synchronizations para cabecera/estado/correlacion y ampliar con items/lease/checkpoint donde sea necesario. PostgreSQL puede arbitrar una primera cola de trabajo; no se presupone necesidad de Redis/Celery.

1. Descubrimiento autorizado: cuenta/entorno/rango, IDs devueltos y procedencia. Si no hay listado, una exportacion oficial o semillas acreditadas pueden alimentar candidatos. No secuencias, scraping ni codigo vacio. 2. Primera pasada: datos, contactos disponibles, servicio, condiciones comerciales, estados, TODOS los eventos/referencias y referencias documentales. Captura completa/ingesta tipada; no limitarse a la primera muestra sanitizada. 3. Segunda pasada despues de completar la primera: POD progresivos pendientes, priorizados y presupuestados. No descargar etiqueta o POD para consultar estado. 4. Sincronizacion permanente de activos, incidencias, pendientes e incompletos; terminales reducidos/suspendidos con refresh manual explicito.

Lote inicial funcional 20 expediciones, configurable. No significa GrabaServicios con 20 envios ni GetExpCli batch de 20 IDs: el lookup domestico documentado es por codigo. Hasta 20 lookups remotos mas descubrimiento/otros HTTP, no una llamada. No hay limite fisico de 20/100 en el repositorio.

Checkpoints y reanudacion

Job immutable define cuenta, conector, intervalo, filtros, version de parser, presupuesto y autorizacion. Item guarda ID externo fuerte, estado, intentos, last_error y referencia de respuesta. Lease exclusivo con expiracion para evitar que dos workers/manual consulten lo mismo simultaneamente.

Checkpoints de descubrimiento conservan cursor/pagina reales SOLO cuando el contrato GLS los defina; rango, ultimo item y cobertura. No inventar cursor ni confiar en duracion ilimitada. Si expira, reiniciar ventana con solapamiento controlado/deduplicacion y presupuesto, no saltarse silenciosamente resultados.

Commit atomico por envio: identidades, snapshot, eventos/revisiones, referencias y item procesado. Reejecutar ingesta LOCAL idempotente tras caida; evidencia ya capturada no requiere otro HTTP. Entrega de cola es at-least-once local, no promesa de exactly-once en GLS.

Errores de contrato/identidad pausan el job, no se reintentan a ciegas. Lecturas transitorias pueden tener backoff/jitter e intentos acotados cuando se apruebe; 429 respeta indicacion recibida y cuotas; 401/403 abre circuito. Creaciones/anulaciones ambiguas no se reintentan automaticamente, menos aun por otro conector. Este plan no cambia el comportamiento de pruebas actuales.

Frescura y politica de actualizacion

last_fetch_at, last_successful_sync_at, source_effective_at, ingested_at y next_sync_at son distintos. Consultar UI local no renueva last_gls_sync_at. Un error o lista vacia no sustituye un estado valido por cero/desconocido.

Activos: ventanas configurables razonables y por cuota; incidencias vigentes priorizadas, no cada incidencia historica. Incompletos: refresco con motivo, no bucle sin limite. Finalizados: disminuir hasta detener automatismo segun completitud; posteriores correcciones se incorporan en revision/manual/ventana acordada, sin perder el historico anterior.

El manual aconseja unas 4-5 consultas diarias de conocidos no definitivos; es recomendacion de uso, no cuota ni permiso para activarlas ahora. No fijar intervalos definitivos sin conocer volumen/limites. Reusar una respuesta rica para estados, eventos, contactos y referencias, no hacer una consulta por vista.

POD progresivo, privado e integro

Una referencia POD no es un binario almacenado. Modelo de item: detectado, pendiente, descargando, verificado, fallido, no_disponible o requiere_revision. Fuente/URL privada, tipo, hash, tamano y metadata, con dominio autorizado. Enlaces expirables requieren nueva consulta solo si es necesaria/autorizada.

Al descargar futuramente: validar host/protocolo/redireccion/limites MIME, timeouts/tamano, cifrar original, verificar firma de fichero/hash y metadata transaccional. Evitar SSRF, URLs con secretos en logs y descargas a terceros no declarados. Cada HTTP de descarga cuenta, aunque sea almacenamiento de documentos y no SOAP. No seguir enlaces arbitrarios dentro de respuestas.

No recuperar de nuevo documento ya verificado; una version distinta crea activo nuevo. Si falta campo POD no inventar un documento ni tratarlo como fallo definitivo. Priorizar pendientes segun antiguedad/riesgo de disponibilidad confirmado, nunca reservar toda la cuota para historico. No descarga en esta fase.

Criterios de aceptacion futuros

Job 20 sintetico/replay local con pausa a mitad y reanudacion sin duplicados; fallo BD tras captura sin segundo HTTP; dos workers sin doble claim; cuenta anterior bloqueada; terminales no consultados por defecto; originales intactos; zero POD en primera pasada; todos los HTTP contabilizados y presupuesto respetado.

---

Documento fuente: 10_API_USAGE_DESIGN.md

Gestor central de consumo: diseno

No se cambia ningun limite, cola o contador. No hay valores definitivos de frecuencia/concurrencia aprobados en esta auditoria.

Estado actual y semantica

api_requests 21, api_usage_daily 7; cuenta no es columna de esas tablas. PRODUCCION SOAP 10 = 1 alta + 8 GetExpCli + 1 Anula. TEST SOAP 6 = 3 altas (una fallo HTTP), 1 GetExpCli, 2 etiquetas. REST 5 = 2 OAuth (ShipIT/T&T), 1 Parcel Shops, 1 catalogo, 1 dataset. Historico TEST/laboratorio 11 agrega SOAP TEST y REST. No renumerar ese historial.

Hay tests anteriores al ledger y OAuth auxiliares que ciertos metodos no registran individualmente. Por tanto el contador interno no certifica todo el trafico historico ni la cuota restante oficial. La agregacion actual considera exito HTTP200 aunque pueda fallar negocio: separar success_http y success_business en la evolucion, sin reescribir evidencia antigua.

Unica politica configurada: T&T, etiqueta sandbox del laboratorio, 500/dia, reserva50 y umbrales50/75/90/100. El OpenAPI documenta 500 peticiones/dia y maximo10 IDs/referencias; el alcance/horario exacto de reset se confirma con GLS. No aplicar esa cuota a iClientes SOAP ni ShipIT. Limite desconocido != ilimitado.

Identidad de presupuesto

Proveedor + producto/API + entorno real + cuenta/identidad + periodo. Una Key compartida por apps podria consumir cuota no visible; registrar esa incertidumbre y margen, no prometer restantes exactas. OAuth se registra como HTTP propio con producto autenticacion/emisor y coste de cuota segun contrato, aunque no compute igual que tracking. TLS/DNS no son expediciones.

Extender tablas existentes con scope de cuenta y fuente de limite: oficial/configuracion_interna/estimacion/desconocido. Limite oficial nullable en el modelo futuro; schema actual limit_count NOT NULL requiere migracion expresa posterior, no usar 0 para simular ilimitado.

Prioridades y reservas

No dar a P2/P3 toda la cuota en madrugada sin considerar P0 del siguiente periodo. Reservas se calculan atomicas antes de dispatch; liberar reservas no usadas, registrar transmision real y conservar incertidumbre tras timeout. Contar 401/429/errores segun politica oficial, no solo exitos.

Planificador por zona Europe/Madrid, calendarios laborable/nocturno/fin de semana y excepciones configurables. Horarios no implican disponibilidad garantizada del carrier. Control diario + ventana por minuto + concurrencia, margen y circuit breaker independientes; el reinicio del servicio no reinicia consumo. Cambios de periodo/DST no duplican capacidad por sumar 24h sin zona.

Simulacion antes de ejecutar

Plan: candidatos -> deduplicados -> llamadas principales -> datos ya incluidos -> descargas necesarias -> coste OAuth/otros HTTP -> cuotas/reservas -> ejecucion o pausa con motivo. No contar cada exp retornado como una llamada y no asumir que un lote20 representa una sola peticion SOAP.

Si N conocidos requieren una GetExpCli cada uno, coste de lookup=N, mas descubrimiento/descargas reales; iClientes no requiere OAuth por lookup. La frecuencia del manual se somete a volumen y presupuesto acordado. Respuestas ya conservadas se reprocesan localmente con coste remoto cero.

Configuracion futura desde 88

Fuentes y ambitos de limites, ventana diaria/minuto, reservas por prioridad, margen por consumo externo, horarios/feriados/zona, maximo concurrencia, tamano de job (inicial20 propuesto), limite bytes POD, backoff e intentos de lectura, umbrales de alerta, maximo de consultas manuales y politica de terminales. Campos marcados provisional/confirmado por GLS, actor/cambio/version auditados. Cambiar configuracion no arranca sincronizacion automaticamente.

Panel: gastado/pendiente reservado/restante estimado, por API/cuenta/entorno, diario/semanal/mensual, errores HTTP vs negocio, eficiencia items/HTTP, ultima llamada y reset estimado con grado de certeza. Alertas persistentes deduplicadas y reconocibles, sin repetir ruido en cada healthcheck.

Test futuro: dos workers compiten por ultima reserva sin exceder presupuesto; P3 no bloquea P0; 429/backoff y reinicio conservan consumo; OAuth contado; cuenta/entorno aislados; no fallback de escritura entre conectores.

---

Documento fuente: 11_INTERNAL_API_DESIGN.md

API interna de intranet: contrato propuesto v1

No implementada. TH especializado en transporte; intranet mantiene clientes, pedidos/facturas y SMS. No una API limitada al SMS ni proxy SOAP arbitrario.

Base logica /internal/v1. Cuenta/tenant deriva de identidad de servicio y seleccion autorizada, no de una UID enviada por el cliente. ID TH es recurso estable; numero GLS completo campo operativo principal, CODEXP/refs conservados.

Recursos y operaciones

Modificar/anular se modelan como comandos independientes futuros con permisos, confirmacion y capacidad; no se abren por existir Anula en WSDL. Cerrar dia no forma parte del flujo normal ni del MVP de esta API.

Ficha conceptual de respuesta

{
  "id": "[ID_TH]",
  "carrier": "gls",
  "account": "[CUENTA_TH_AUTORIZADA]",
  "environment": "production",
  "shipment_number": "2004-[IDENTIFICADOR OMITIDO]",
  "identifiers": {"codexp": "[IDENTIFICADOR OMITIDO]", "guid": null, "barcode": null},
  "references": [],
  "status": {"administrative": null, "logistic": null, "lifecycle": null, "outcome": null},
  "recipient": {"name": null, "phone": null, "mobile": null, "email": null},
  "cod": {"declared_amount": null, "currency": null, "collection_status": "unknown"},
  "tracking": {"url": null, "source": null, "validation_status": "pending"},
  "data_source": "historical_repository",
  "last_carrier_sync_at": null,
  "completeness": "not_yet_imported"
}

Ejemplo de ESQUEMA, no respuesta real ni fila existente de esa expedicion. Nulls expresan datos no recuperados; los hechos de Extranet comunicados no se fabrican como nuevos resultados API. La respuesta real puede incluir datos comerciales permitidos, no solo los campos minimos del ejemplo.

Crear y vincular con la intranet

Entrada prevista: carrier/account/centro_remitente, referencia TH/caller, pedido, factura, cliente/ERP, destinatario y contactos, servicio/horario, bultos/peso, portes, reembolso/importe/moneda, observaciones y servicios adicionales explicitamente solicitados. Centro remitente resuelve direccion configurada; snapshot queda ligado al envio. Validar datos requeridos por conector/servicio sin inventar telefonos si no los envia el origen.

No recibir endpoint, SOAPAction, XML libre, UID, bearer GLS, SQL, ruta filesystem, callback o URL de descarga arbitrarios. Lista cerrada de campos y capacidades; clientes no eligen bypass de entorno o conector de respaldo.

Idempotencia por identidad de servicio + cuenta + entorno + clave y hash canonico del comando. Misma clave/datos devuelve la misma operacion; datos distintos con misma clave =409. Una referencia pedido puede tener varios envios: no es automaticamente clave idempotente universal.

Operacion duradera antes de transmitir. Mutaciones devuelven 202 y ID de operacion; estado aceptada remota con IDs no se confunde con entregada. Timeout = resultado desconocido/requiere conciliacion, no nuevo envio. No reintento automatico en otro conector ni nueva alta por expiracion del cliente HTTP. Consulta de operacion usa datos locales y conserva resultado.

Seguridad, errores y versionado

Identidades de servicio distintas de usuarios de navegador. Permisos por operacion, cuenta/entorno y datos: contactos y POD no para cualquier lector. Secretos de cliente guardados por mecanismo existente autorizado, rotables, con hashes/referencias donde corresponda; no generar credenciales ahora. Preferir TLS interno/mTLS o canal privado acordado. Bearer sobre HTTP LAN no cifra nada; necesita decision de riesgo/compensacion, no confianza solo porque el puerto80 no se publique en Internet.

Auditar actor, cuenta, correlation_id, idempotency_key referenciada, resultado y campos sensibles leidos sin copiarlos en logs. Limitar busqueda/exportacion, tamano/cursor y peticiones por servicio, ademas del presupuesto GLS. Errores de cliente 400/403/404 por ambito, 409 conflicto/capacidad, 422 validacion, 429 presupuesto, 503 dependencia; estructura estable {code,message,correlation_id, retryable}. No filtrar existencia de datos de otra cuenta, ni stack traces.

Version v1 con campos aditivos; cambios de significado requieren version. Contratos de consumidor/tests sintenticos y cuenta negativa antes de desplegar. No endpoint publica directamente datos crudos de GLS ni firmas/POD masivos.

Enlace de seguimiento y SMS

Preferencia: URL oficial devuelta por GLS y preservada con origen/version, host/protocolo validados, expiracion si existe. Hoy solo hay un ejemplo de Juan, sin plantilla universal demostrada. No se ha abierto ni validado. Plantilla configurable e inicialmente deshabilitada para casos no probados; URL-encode, host allowlist y prohibicion de secretos en query/path.

No afirmar que /e/{CODEXP}/{CP_DESTINO} sea siempre valido para internacionales o cualquier servicio. Si no esta validado, API devuelve pending/null, no URL inventada. La intranet decide y envia SMS; TH no crea automatizacion SMS.

---

Documento fuente: 12_INTERFACES_DESIGN.md

Interfaces operativa 80 y tecnica 88: diseno

No se abrio el puerto80 ni se cambio el proceso actual. Hoy todo vive en FastAPI/Uvicorn88, HTML Jinja2; no hay interfaz operativa independiente.

Topologia propuesta

Usuarios LAN -> HTTP :80 -> presentacion operativa / API de negocio autorizada
Tecnicos     -> HTTP :88 -> configuracion, KB, diagnostico, auditoria
                           |
                 mismos servicios de negocio
                 mismo repositorio PostgreSQL
                 mismos conectores y gestor de consumo

Dos apps/router roots/entrypoints de presentacion, no dos copias del dominio ni dos BD. Un segundo servicio ASGI futuro es viable en puerto libre sin proxy nuevo obligatorio; decision de despliegue se aprueba despues. No se ejecuta dos veces el startup actual que aplica migraciones. Primero extraer migracion como paso de release autorizado, y factories sin efectos al importar.

88 mantiene KB, configuracion tecnica, diagnosticos, consumo, logs/evidencias, usuarios/roles y herramientas. Ninguna ruta tecnica se monta en app80 ni se protege solo por ocultar el enlace del menu. Ambos listeners autentican y autorizan en servidor. Salud local no llama GLS.

80: LAN, HTTP segun decision del encargo, sin allowlists de IP individuales, autenticacion de usuarios y permisos. No significa publicar en Internet o dar acceso anonimo. Futuro acceso API con secretos exige TLS/canal seguro o aceptacion expresa del riesgo de HTTP; no se modifica proxy/firewall ahora.

Cookies no se aislan por puerto: nombres/paths/audiencia y politica de sesion separados para operativo/tecnico, CSRF por origen permitido y roles comunes revalidados. No poner una cookie admin valida indiscriminadamente en ambos. No usar confianza en X-Forwarded-* de cualquier cliente; proxies confiables solo tras revisar la infraestructura de empresa con permiso especifico.

Menu operativo aprobado

1. Grabar envios: formulario de negocio, centro remitente, destinatario, contactos, bultos/peso, servicio, reembolso y referencias; revision humana de produccion y confirmacion idempotente antes de crear. 2. Buscar envios: informacion del repositorio, filtros, ficha y documentos. 3. Cerrar dia: ultimo modulo, complementario y condicionado a contrato y autorizacion. No requisito para funcionamiento normal ni para desarrollo.

PC primero, adaptacion movil posterior; no implementar landing ni duplicar laboratorio. Los datos del remitente no se reenvian desde intranet si un centro ya configura lo necesario, manteniendo snapshot de lo efectivamente usado.

Buscar envios: superficie propuesta

Barra de filtros compacta: numero GLS completo prioritario, fechas, nombre parcial, referencia, CP, servicio/horario, estado, entregadas/pendientes, incidencias, anuladas, reembolso, pais, agencia y cuenta/entorno/origen. No mezclar anuladas con entregadas ni CERRADO DEFINITIVO con entrega.

Vistas rapidas: Todas, En curso, Pendientes, Incidencias, Entregadas, Anuladas. Consulta SQL parametrizada y paginada localmente; filtros remotos solo despues de tener contrato y accion explicita. Paginar, buscar o abrir ficha NO llama GLS. Los candidatos aun no confirmados se distinguen de los envios recuperados; vacio de API no crea estado pendiente ficticio.

Tabla: numero completo, fecha, destinatario/poblacion/CP, servicio/horario, bultos/peso, estado por dimensiones, reembolso, ultima consulta, procedencia y calidad. Acciones de documentos solo si permiso/disponibilidad reales.

Ficha: IDs, administrativo/logistico/ciclo/resultado, partes/contactos, servicio, bultos, peso, reembolso, referencias, timeline, delegaciones, incidencias, enlace publico, POD, etiquetas y detalles tecnicos autorizados. Codigo/literal original y fuente conservados aunque no esten en vista principal. Extranet es referencia funcional, no contrato ni obligacion de copiar su visual.

Sin conectividad GLS

Consulta local sigue disponible si app/BD funcionan. Mostrar Datos del repositorio historico, ultima sincronizacion GLS, fecha efectiva y error/ frescura; no prometer datos actuales por estar renderizados ahora. Si no hay POD local mostrar pendiente/no disponible, no hacer descarga automatica. PostgreSQL caido es fallo diferente: no hay cache magica si su BD no responde.

Actualizar manual es comando independiente con confirmacion/permisos/cuota, no efecto secundario de GET. La impresion EPL sigue manual, original inmutable, derivado S4 y resultado TRANSMITIDO distinto de verificacion fisica humana.

---

Documento fuente: 13_RISKS_AND_DECISIONS.md

Riesgos y decisiones pendientes

05/11/2026. Prioridad de proyecto, no afirmacion de vulnerabilidad explotada. Nada corregido unilateralmente en codigo/infraestructura en esta auditoria.

Decisiones adoptadas documentalmente

ADR-01: iClientes domestico principal, ShipIT investigacion archivada para esta operativa. Alternativa continuar habilitando ShipIT descartada como prioridad por recomendacion GLS; no borrar contratos/evidencia.

ADR-02: repositorio historico persistente en BD existente, no cache de 100. TTL mide frescura, no retencion. Alternativa segundo repositorio GLS rechazada.

ADR-03: numero GLS completo como identificador humano; PK TH independiente y IDs tipados scoped. Alternativa CODEXP global/PK rechazada.

ADR-04: cuatro dimensiones de estado y versiones de evento. Alternativa ultimo evento cronologico/estado unico rechazada por TH-P-001 y FACTURA posterior de historica entregada.

ADR-05: importacion datos/referencias primero, POD despues; job20 configurable, no batch SOAP20. Presupuesto central P0-P3; no valores definitivos hoy.

ADR-06: operativo80 y tecnico88 con nucleo/BD/consumo compartidos. Dos vistas no significan dos copias del negocio ni misma cookie confiada por puerto.

ADR-07: intranet integra por API versionada, mantiene SMS y autoridad comercial; no acceso directo a UID/SOAP ni automatizacion de portal.

Decisiones que requieren aprobacion

Contrato/alcance historico GLS; presupuesto de pruebas; minimo indexable PII y cifrado por campo; retencion/gobierno; mecanismo de backup/restore y RPO/RTO; topologia/TLS/canal de API; roles de lectura/contactos/POD; rol de migracion; cadencias y cuotas internas; generacion validada de enlace; reglas de eventos corregidos sin ID externo; orden de activacion de escrituras y cierre.

No quedan decisiones funcionales activadas por escribir esta lista.

---

Documento fuente: 14_IMPLEMENTATION_PLAN.md

Plan de implementacion, pendiente de aprobacion

No ejecutar al terminar la auditoria. Cada fase requiere alcance, backup, tests, documentacion, configuracion externa, rollback y criterios de salida. No nuevos transportistas, banca, facturacion o SMS en este plan inicial.

Fases 0 y preparacion de contratos/modelo pueden avanzar documentalmente en paralelo. No bloquear todo el producto esperando ShipIT: queda fuera de la ruta principal. El repositorio y la ingesta offline no inventan enumeracion; el importador historico completo necesita realmente IDs o listado oficial.

Que implementar primero, tras aprobar

Primero proteccion recuperable y diseno de identidad/estados/ingesta local, mientras se obtiene el contrato de descubrimiento. No empezar por una UI que llame GLS en cada filtro ni por descargas masivas de POD. El primer incremento operativo debe demostrar persistencia de conocidos y consumo correcto antes de automatizar historico o ampliar escrituras.

Calidad transversal

Tests sinteticos para cifrado/permisos, parser robusto/500/Fault, scope de cuenta, dedup/revisiones, referencias heredadas, estados cruzados, idempotencia, backoff/cuota, doble worker, documentos inmutables, cookies por interfaz, API consumidor y restauracion. Pruebas externas separadas y contadas.

No reutilizar UID real en unit tests ni versiones crudas de documentos con credenciales. Validar datos completos en parser privado y solo vistas sanitizadas en logs. Changelog/README y runbooks se actualizan al implementar, no mediante afirmaciones de funcionalidades aun no construidas.

Aprobaciones pendientes antes de actuar

Elegir bloque de pruebas (recomendado R1: una GetExpCli reciente), aprobar politica de datos/contactos y autenticacion intranet, contrato historico, plan backup/restore, schema y criterios de roles/puertos. Esta auditoria no autoriza esas actuaciones ni genera tareas programadas.

---

Suplemento: propuesta diaria concreta y plan de salida del bloqueo

05/11/2026. Diseno no desplegado; sin nuevos procesos, puertos, servicios ni llamadas GLS. Objetivo de uso: al abrir TH por la manana, ver los envios de ayer con entrega/transito/incidencia.

Secuencia propuesta con enumeracion validada

1. Una tarea manual/diaria autorizada determina ayer en Europe/Madrid y la cuenta activa. Descubre IDs mediante el contrato de listado, con el campo de fecha y limites acordados. No usar cierre/manifiesto de efectos desconocidos como mecanismo de importacion. 2. Conserva respuesta original cifrada y metadatos; aplica en transaccion los resultados utiles que ya contenga. Solo solicita detalle de IDs nuevos/incompletos cuando haga falta y haya presupuesto. No asumir que GetEnvios requiere siempre otra llamada o que devuelve ficha completa. 3. Refresca conocidos activos e incidencias de cualquier fecha con prioridad y ultima sync correcta; entregas recientes segun politica. No refrescar indiscriminadamente todo el historico cada dia. 4. Actualiza proyecciones de estado/eventos/datos y cobertura. Una ventana se marca completa solo tras todas las paginas validadas y deduplicadas. Ventana parcial conserva cursor/motivo. 5. El puerto 80 futuro consulta SOLO PostgreSQL: filtro por fecha operativa, cuenta, destinatario, servicio y estado; paginacion local. Abrir/buscar no llama a GLS. Puerto 88 sigue siendo tecnico. 6. La pantalla muestra ultima sincronizacion correcta, ultimo intento, cobertura del periodo, datos incompletos y errores. Permite actualizacion manual separada con alcance y coste previstos. 7. POD en segunda pasada progresiva de entregadas, solo si no existe activo verificado y con presupuesto separado. Su retraso no bloquea la busqueda ni la importacion de la ficha.

No se fija una nueva hora/frecuencia como permiso operativo. El manual aconseja 4-5 refrescos de no definitivos al dia; ajustar la futura agenda y cuota con GLS y Juan. El lote 20 del plan anterior es tamano de trabajo local, no batching SOAP ni 20 consultas gratis. Descubrimiento, detalle, eventos, descarga POD y cualquier token/HTTP auxiliar tienen coste real. No atribuir 500/dia T&T a iClientes. Limite SOAP desconocido, no ilimitado.

Sin conexion y fallos

La busqueda local sigue disponible con indicador de antiguedad; no inventar entrega/ausencia. El estado correcto de ultima sincronizacion no se reemplaza por un fallo posterior. Guardar captura para replay cuando falla parser/BD. Los reintentos de lectura futuros requieren politica/presupuesto, no se aplican a la prueba actual (cero reintentos). Nunca retries automaticos de creacion ambigua; no mezclar su idempotencia con un job de consulta.

Manual y programada usan un mismo motor con lease/lock por cuenta/tarea e idempotencia de ingesta para impedir solapamientos accidentales. Cambios tardios requieren solape o feed documentado; el cursor de una pagina no es automaticamente un cursor de cambios continuo.

Que puede hacerse sin enumeracion

Si GLS no ofrece listado, solicitar exportacion inicial y alimentacion incremental oficial acordada. No scraping, enumeracion de secuencias ni consulta ciega de codigos. Aceptar una alternativa parcial debe ser una decision visible, no esconder el bloqueo.

Plan siguiente propuesto, sin iniciar implementacion

1. Revisar el ZIP y enviar manualmente el borrador tecnico a GLS. Obtener IN/OUT con efectos, cuenta, fechas, paginas, retencion y limites. No volver a pedir alta/endpoint/UID. 2. Analizar el contrato y preparar mocks, validacion y calculo de coste. Si se acredita lectura, revisar la unica consulta reciente pendiente y su presupuesto antes de enviarla. 3. Tras resultado reciente y nueva aprobacion, probar el intervalo de los 61 y contrastar IDs/criterios con Extranet; pedir autorizacion para cualquier pagina adicional. 4. Aprobar backup/restore, modelo scoped y migraciones. Implementar primero parser/ingesta offline/replay, identidades, fechas y consultas locales; verificar sin llamadas nuevas. 5. Importar ventanas progresivas hasta agosto2025 solo con contrato/retencion/presupuesto; consolidar cobertura y conciliacion. Aislar cuentas de agencias anteriores. 6. Habilitar busqueda operativa local y sincronizacion diaria limitada; POD despues, progresivo.

Las decisiones antiguas que proponian una nueva consulta de un CODEXP historico conocido NO son la prueba prioritaria autorizada hoy. No se ha ejecutado ninguna ni iniciado el plan.

Arquitectura implementada etapa D

GLS_SENDER_INTEGRATION

Separacion de responsabilidades

OperationalService coordina el caso de uso; CreateCoordinator garantiza intento unico, evidencia y conciliacion. IClientesAdapter resuelve identidad y serializa con el contrato existente. El repositorio, diarios, documentos, centros y cuotas son entidades independientes del proveedor. Otro transportista podra aportar su adaptador sin duplicar el modelo de expediciones.

La identidad debe corresponder a la referencia de secreto del entorno y cuenta seleccionados. PRODUCCION se contrasta internamente con TEST. Nunca se incluyen credenciales en borradores, observaciones, respuestas web o mensajes de error. La peticion real se construye solo en memoria; el intento cifrado de negocio contiene XML con el secreto eliminado, no una copia del UID.

Centros remitentes

sender_centers conserva codigo, etiqueta, estado, version y direccion cifrada. carrier_account_senders permite varios centros y cuentas; un indice parcial garantiza un solo habitual por cuenta. Edicion por revision y auditoria sin direcciones. No se utiliza la tabla de destinatarios como configuracion.

Desde Administracion 88 > Transportistas > Centros remitentes se configuran nombre, direccion, poblacion, CP, pais y datos opcionales propios. Un centro inactivo deja de estar disponible para borradores nuevos sin eliminar historia. La seleccion del puerto 80 copia un snapshot al guardar el borrador, evitando volver a introducir el remitente. Cambiar despues el centro no modifica envios ni borradores existentes: debe guardarse y revisarse de nuevo explicitamente. Puede mantenerse direccion manual seleccionando esa opcion.

La fase inicial de serializacion operativa admite origen y destino Espana y los servicios localmente validados. El centro es reutilizable y no contiene UID, codigos contractuales inventados ni destinatarios de prueba.

Se ha inicializado un centro habitual con los campos exclusivos del remitente propio previamente confirmados y preservados en configuracion local cifrada. Se ha contrastado identidad de empresa, localidad, CP y pais. Asociado a TEST y PRODUCCION; no se han copiado campos del destinatario ni activado llamadas.

Creacion y etiquetas

GrabaServicios usa la cuenta revisada y la referencia inmutable del intento. Resultado 0 no acredita recogida. Se conserva CODEXP sin inventar una agencia en el numero principal; una respuesta posterior puede aportar la numeracion completa. UID de expedicion y codigo de barras son identificadores distintos del UIDCLIENTE. Las etiquetas recibidas en la misma respuesta se guardan como activos originales cifrados, con SHA-256, MIME, formato y tamano.

No se recuperan representaciones adicionales automaticamente ni se imprime. El circuito Zebra previamente validado sigue independiente e inalterado.

Activacion futura

Bloqueo de release, flag operacional global, permisos de cuenta, identidad, cuotas y confirmacion son controles acumulativos. Las politicas del servicio 80 aun impiden leer el almacen UID y conectarse a GLS. Su futura autorizacion debe ser explicita; guardar datos o abrir una pagina nunca las modifica.

Un resultado ambiguo conserva evidencia y exige conciliacion local. Si falta recibo, el plan puede proponer GetExpCli por identificador/documentacion valida, pero no lo ejecuta ni vuelve a crear la expedicion automaticamente.

HISTORICAL_IMPORT_STATUS

Flujo disponible en el puerto 88

1. Administrador selecciona cuenta y pega texto de Extranet, no se exige CSV. 2. Se reconocen numeros agencia-CODEXP y candidatos de barcode de 14 digitos. 3. Otras agencias y numeros ambiguos quedan apartados, nunca se adivinan. 4. Se deduplica el texto y se excluyen identificadores ya presentes por cuenta. 5. Se muestra estimacion de llamadas y disponibilidad de cuota con reserva. 6. El administrador revisa y confirma un maximo de 25 identificadores. 7. Se guarda payload cifrado y trabajo PAUSADO, con clave idempotente. 8. El trabajador preparado recuperara GetExpCli por conocido cuando exista autorizacion posterior, nunca al abrir la pagina o guardar el lote. 9. Se persisten identificadores, partes, acontecimientos, COD y metadatos disponibles, con deduplicacion y trazabilidad a evidencia cifrada. 10. El informe por lote muestra completos, pendientes, fallidos y ambiguos.

El texto original pegado no se guarda. El mes opcional se valida desde agosto de 2025; es procedencia administrativa, no prueba de cobertura ni filtro API. Recuperacion prevista: mes reciente a antiguo, lotes pequenos y revision humana entre ellos. No se ha ejecutado campana ni lote productivo en esta etapa.

Reanudacion y errores

Lease exclusivo, prioridad y checkpoints por elemento. Cada elemento tiene un UUID de ejecucion y una respuesta cifrada duradera antes de normalizar. Despacho sin respuesta: ambiguo, no se repite automaticamente. Respuesta preservada con fallo local: replay sin otra llamada. Recibos y reservas impiden duplicar consumo durante replay. Pausa durante una llamada conserva primero su respuesta y se detiene antes del siguiente elemento.

Un corte por maximo de elementos deja el lote pausado sin consumir el limite de reintentos por fallo. Reanudar no vuelve a consultar elementos completos, fallidos o ambiguos; estos requieren revision y una accion posterior explicita. La ausencia de datos no significa anulacion ni borra historico conocido.

Alcance del mapeo

Contrato: ES-GLS-WS_GetExp_GetExpCli.docx.pdf y ejemplo XML oficial conservado. Identificador preferente para conocidas: barcode, numero completo o CODEXP. La respuesta debe corresponder inequívocamente al identificador solicitado. Multiples expediciones o identidades conflictivas requieren revision manual.

Se conservan fechas raw si no pueden interpretarse; las fechas locales sin offset se interpretan Europe/Madrid segun el contrato existente sin TipoUTC. Estado administrativo 5 no se confunde con borrado=S; 90 no significa entrega. Un evento SOLUCION no elimina indiscriminadamente todas las incidencias. Los enlaces de digitalizaciones no se siguen y no se descarga POD.

Limitaciones pendientes

GetEnvios no tiene aun contrato de enumeracion suficientemente acreditado. Este importador NO descubre todas las expediciones por fechas ni demuestra recuperacion de las 61 expediciones del intervalo historico. Solo recupera identificadores revisados de nuestra cuenta. Los periodos, cobertura temporal, POD, cuentas anteriores y limites oficiales iClientes requieren pruebas o documentacion adicional. Nunca se presenta cobertura parcial como completa.