El FCL v1 (PRs #618 a #624) hizo bien una cosa: un contenedor exclusivo por flete, con reserva, sello, VGM y evidencias. Lo que no puede decir es cuántos son. Freight.containerId apunta a uno; requestedEquipmentType es un solo valor; la naviera es un campo de texto en el contenedor; la orden no sabe quién la despacha.

Copy tomado de apps/admin/lib/i18n/locales/es.json: freights.fields.equipment, freights.create.fcl.containerCode*, containers.detail.context.carrier*, containers.reservation.*. Los bloques son freight-cargo-block.tsx, fcl-equipment-picker.tsx y container-context-block.tsx.

Samuel escribe 8x40HQ en WhatsApp. El campo Equipo acepta exactamente eso, y también 6x40HQ + 2x20; debajo aparece lo que entendió, como chips con stepper, y el resumen en vivo. Los números de contenedor se pegan como llegan en el correo de la naviera: uno por línea, con comas o con espacios. Cada fila se valida sola; una inválida no frena a las otras siete.

Un solo POST con Idempotency-Key: flete + cotización + 8 reservas + BL (booking) + carga + outbox. Todo o nada. La respuesta trae containers: [{ id, reservationReference, code, requestedEquipmentType, status, version }]. Tope propuesto por alta: 60 contenedores (pregunta 10).

Los contadores van en la cabecera, antes del estado y de la tarifa, porque son la pregunta que se hace primero. Proveedores se cuenta por orden (distintos supplierId) o se lee de la declaración cuando la carga es DECLARED. Contenedores es el mismo número en ambas fuentes, con el desglose que operaciones necesita: identificados, reservas pendientes, y por equipo. Cuando no se sabe, se muestra —: nunca un cero inventado.

Los mismos dos números se repiten en /freights como columnas «Prov.» y «Cont.», en el PDF del flete («Proveedores declarados: 3» · tabla «Contenedores (8)») y en el resumen del cliente («8 contenedores · 5 identificados»).

Una fila por contenedor. La referencia siempre existe; el número aparece cuando la naviera lo asigna. Equipo solicitado y confirmado van juntos porque la regla de v1 sigue: la solicitud nunca se copia como confirmación. Desde aquí se pegan números (mismo componente que el alta) y se añade una reserva más, siempre antes de LOADING y con revalidación de tarifa.

En /containers/[id] no hay rediseño: se añade el bloque «Flete y BL» (flete vinculado · contenedor 3 de 8 · BL y naviera) y «Equipo solicitado» de solo lectura junto al confirmado. Identificar equipo, sello, VGM, evidencias, escalas y cierre ya son por contenedor.

La suma de los CBM de las órdenes que van dentro de un contenedor es su presupuesto de volumen. En vez de una cifra, la caja se dibuja de lado y se llena desde el piso con cada orden asignada. Cuatro estados, siempre con la cifra al lado: vacío, en curso, casi lleno a partir del 85 % y sobre capacidad cuando el sobrante asoma por encima del techo. La capacidad es la útil de planificación por equipo (28 · 58 · 68 m³); la nominal queda en el tooltip.

Vista lateral: puertas a la derecha, corrugado vertical, el nivel marcado con la cifra en marino. El relleno es una altura en porcentaje (--h); el sobrante es un bloque rayado en rojo que asoma por encima del techo. Sin JavaScript: los estados son CSS.

El BL nace como booking cuando se elige la naviera y se completa con su número al zarpar: es el mismo registro. Ampara 1..N contenedores del mismo flete; un contenedor solo puede estar en un BL. La naviera del BL se espeja a Container.carrier para que la búsqueda global y el índice trigram sigan funcionando. La factura comercial es una sola para el flete y vive donde ya vivía: Freight.invoiceFiles.

Es la pieza más pequeña y la primera: Order.supplierId opcional, y la ficha del proveedor gana ubicación propia (ciudad, provincia, dirección, lat/long). No pasa por Address, que exige la geografía venezolana sembrada. El combobox ya existe (supplier-combobox.tsx) y hoy solo lo usan cotizaciones y búsquedas. Aplica a LCL y AIR también: responde la misma pregunta en todos los modos.

Las métricas del proveedor (getMetrics) hoy solo cuentan opciones de sourcing; pasan a sumar órdenes. La asignación orden ↔ contenedor (qué proveedor va en qué caja) queda para la fase 4, si la pregunta 4 lo pide.

En /freights, «Prov.» y «Cont.» para filas FCL; LCL y AIR muestran «—» en Cont. y el filtro por naviera aplica a todos. En /containers, las filas FCL dicen a qué flete pertenecen y en qué posición («3/8»), con la naviera y el filtro por BL.

Búsqueda global: el número de BL y el nombre de la naviera entran en SearchService. La naviera ya está indexada en containers.carrier; por eso se espeja en vez de moverse.

Nada de esto se construye hasta que las preguntas tengan respuesta. La fase 1 es aditiva y responde ya la pregunta de los proveedores: se propone arrancarla mientras se decide el resto.

1. ¿Un flete puede repartir contenedores en varios zarpes / BL? Este diseño lo permite. Si siempre es un zarpe, el BL cuelga del flete.
2. ¿Vínculo en el contenedor (C) o tabla de unión (B)?recomendado C
3. Estado del flete con N contenedores: ¿el menos avanzado? ¿DELIVERED exige todos?recomendado mínimo
4. ¿Hace falta saber qué proveedor va en qué caja o bastan los dos conteos?
5. Lista inicial de navieras y quién puede crear una desde el combobox.
6. ¿Solo MBL o también HBL? ¿El booking se captura en el mismo registro?
7. Factura única: ¿en Freight.invoiceFiles con órdenes opcionales, o una orden por proveedor?
8. Alias de notación además de 40HQ (40HC, 40'HC, 20GP, 40DV). ¿Reefer y open top se rechazan con mensaje?
9. Proveedores en DECLARED: ¿basta el conteo o hay que nombrarlos?
10. Tope por alta: propuesta 60. ¿Casos reales por encima?
11. Ubicación del proveedor: ¿pin manual, geocodificación automática o solo texto? ¿Para qué se usará lat/long?
12. Visibilidad al cliente: ¿ve BL, naviera, buque y estado por contenedor? ¿Ve el nombre de sus proveedores?
13. Reutilización de un número físico en un viaje nuevo: v1 lo prohíbe. ¿Se reabre?
14. Tarifa: ¿una fila base por tipo con cantidad, o una sola fila con importe total?recomendado por tipo
15. ¿Autorizas arrancar la fase 1 mientras se deciden las demás?
16. CBM autoritativo: ¿Order.cbm medido manda y enteredCbm solo estima, o al revés hasta que la orden llegue al almacén? ¿Y una orden sin ninguno?recomendado cbm
17. Tabla de capacidades: ¿valen 28 · 58 · 68 m³ útiles (nominal 33,2 · 67,7 · 76,4) o operaciones planifica con otras? ¿Override por contenedor?
18. Umbral de «casi lleno»: ¿85 % o 90 %? ¿Distinto para el 20'?recomendado 85
19. Sobre capacidad: aviso blando con motivo obligatorio, sin bloqueo; el rojo se queda hasta que la asignación cambie.decidida · 22 sep
20. Reparto de una orden entre contenedores: ¿entera por defecto con reparto opcional por m³, o siempre entera? ¿El «sin asignar» lo ve el cliente?

• Lo que no se propone — conversión FCL↔LCL, equipos especiales (reefer, open top, flat rack), mercancía peligrosa, demoras automáticas, integración API con navieras, cambios estructurales a QuotationLineItem. Todo sigue fuera de alcance como en v1.
• Lo que se conserva de v1 — idempotencia, outbox, versiones optimistas, pricingState, evidencias por contenedor, FCL_PENDING. Se reutiliza por contenedor sin tocarlo.