feat: [TESIS-144] take the product detail status and units in flight from the API

[LauAubert]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-144

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/002.md.

---

Descripción

El detalle de producto (S12) calculaba el badge con umbrales propios del front (LOW_STOCK_UNITS = 500, CRITICAL_STOCK_UNITS = 200) y un cuarto nivel «Crítico» que el backend no tiene. El catálogo usa el stock_status de la API (umbral 100), así que NOR-003 (130 unidades) salía «Disponible» en el catálogo y «Crítico» en el detalle. Este PR hace que el encabezado y cada fila de la distribución muestren el estado que manda el backend, con el mismo mapeo que el catálogo, y borra la regla duplicada.

De paso muestra lo que la API ya enviaba y la pantalla descartaba: la categoría, el total calculado por la API y las unidades en tránsito.

Depende de proyecto-api#99 (card 001): ahí se agregan stock_status al detalle, stocks[].stock_status e in_transit_by_warehouse. Mergear la API primero.

Decisiones que conviene mirar:

El en tránsito no es una porción del total. El diseño reparte el total en tres cubetas que suman el on hand. En el modelo real las unidades en tránsito ya salieron del depósito de origen y no llegaron al destino, así que la API las deja fuera de total_stock. La cubeta «En tránsito» muestra inTransitQuantity como un número aparte y el pie del Stock maestro lo dice. Comprometido y disponible para prometer siguen en —.

Depósitos que sólo esperan unidades. El destino de una transferencia puede no tener fila en stocks hasta recibirla. Se lista al final de la tabla con 0 en depósito y sus entrantes. El estado que se le muestra es out_of_stock: es lo único que el backend puede responder para cero unidades, no una regla nueva del front (está escrito en distributionPositions). El pie cuenta «depósitos con stock o en camino».

El resalte de fila sigue al catálogo (stockRowTone: sólo out_of_stock). Antes se resaltaban también las filas «Crítico» del umbral propio.

• Agrega a ApiProduct/Product category, totalStock, stockStatus, inTransitQuantity e inTransitByWarehouse, y a ApiStock/ProductStock stockStatus; los mapea toProduct.
• Reemplaza en ProductDetailPage el badge calculado por stockLabel/stockVariant del stockStatus de la API (encabezado y filas).
• Agrega distributionPositions en utils/stock.ts, que une las filas de stock con sus entrantes y suma los depósitos sólo-entrantes.
• Elimina LOW_STOCK_UNITS, CRITICAL_STOCK_UNITS, stockLevel, StockLevel, STOCK_LEVEL_STATUS, totalOnHand y detail.status de content.ts.
• Muestra la categoría en Especificaciones (o — si no tiene) y toma el total del Stock maestro de totalStock.
• Corrige comentarios y copy que decían que la categoría y el en tránsito no existían en la API.
• Actualiza los fixtures de Product en los tests de EditProductModal, conflict y payload.

---

Evidencia visual

Pendiente de captura con la API de proyecto-api#99 levantada (los datos de la pantalla dependen de ese contrato). El comportamiento está cubierto por los tests de ProductDetailPage.

---

Cómo probar

Precondición: API con proyecto-api#99, bin/rails db:seed, login con un usuario de Norte.

1. Abrir /inventory y buscar NOR-003 → «Disponible».
2. Entrar al detalle → el badge del encabezado dice «Disponible» (antes «Crítico»). Las filas Central (100) y Satélite (30) dicen «Stock bajo».
3. La celda Categoría muestra Electronics.
4. Crear una transferencia de NOR-003 hacia un depósito sin stock de ese producto → la cubeta «En tránsito» muestra las unidades, el total no cambia por la transferencia más allá del descuento del origen, y el depósito destino aparece al final de la tabla con 0 en depósito y sus unidades en «En tránsito».

Verificación: npm run test (679 tests, 0 fallas), npm run lint, prettier --check y npm run build limpios.

---

Impacto y consideraciones

¿Introduce breaking changes?
No para el usuario. Requiere el contrato de proyecto-api#99: contra una API sin esos campos, el badge del detalle quedaría sin estado.

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No. Reutiliza utils/stockStatus.ts, que ya era el lugar del mapeo de estados del catálogo.

Posible conflicto: TESIS-139-shopify-integration también toca ProductDetailPage.tsx, api.ts y types.ts (agrega la card de canales de venta). Son zonas distintas del archivo.

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. Lo veo bien para implementar.

Arregla un bug que se ve en la demo: NOR-003 sale «Disponible» en el catálogo y «Crítico» en el detalle del mismo producto, porque el front tenía umbrales propios (LOW_STOCK_UNITS = 500, CRITICAL_STOCK_UNITS = 200) y un cuarto nivel «Crítico» que el backend no tiene, mientras la API usa LOW_STOCK_THRESHOLD = 100. Dos badges que se contradicen entre dos pantallas es de lo peor que te pueden encontrar mirando por encima del hombro.

Lo que verifiqué

• La dirección del fix es la correcta: se borran los umbrales del front y el estado pasa a venir del backend, en vez de copiar el 100 en el cliente. Copiarlo habría arreglado el síntoma y dejado la misma trampa para la próxima vez que cambie el umbral.
• El comentario de cabecera de utils/stock.ts queda actualizado y, en particular, corrige la afirmación sobre el desglose de S12: el en tránsito está fuera del total, no adentro, porque salió del origen y no llegó al destino. Que eso quede escrito donde estaba la versión equivocada vale más que el fix en sí.
• Comprometido y disponible-para-prometer se siguen mostrando sin dato en vez de en cero. Mismo criterio que ya usaba el dashboard y es el correcto: un 0 ahí afirma «no hay nada reservado» cuando la verdad es «el modelo no lo registra».

Antes de mergear

Depende de proyecto-api#99, que expone stock_status y in_transit_by_warehouse. Ese va primero.

[TomasMartin2004]

Revisión del diff completo. El código es idéntico al que leí cuando los PRs estaban en draft —ningún commit nuevo—, así que lo que sigue es el veredicto formal.

✅ Aprobado

Arregla un bug que se ve en la demo: NOR-003 sale «Disponible» en el catálogo y «Crítico» en el detalle del mismo producto, porque el front tenía umbrales propios (LOW_STOCK_UNITS = 500, CRITICAL_STOCK_UNITS = 200) y un cuarto nivel que el backend no tiene, mientras la API usa LOW_STOCK_THRESHOLD = 100.

Lo que verifiqué

• La dirección del fix es la correcta: se borran los umbrales del front y el estado pasa a venir del backend, en vez de copiar el 100 en el cliente. Copiarlo habría arreglado el síntoma y dejado la misma trampa para la próxima vez.
• El comentario de cabecera de utils/stock.ts queda actualizado y corrige la afirmación sobre el desglose de S12: el en tránsito está fuera del total, no adentro. Que eso quede escrito donde estaba la versión equivocada vale más que el fix en sí.
• Comprometido y disponible-para-prometer se siguen mostrando sin dato en vez de en cero. Mismo criterio que el dashboard y correcto en el momento en que se escribió.

⚠️ Antes de mergear

1. Depende de proyecto-api#99, que va primero.
2. Choca con mi proyecto-web#79 (TESIS-163), que hace que esos dos números dejen de ser «—» y pasen a traer dato real desde la API (proyecto-api#115 los modela). No se contradicen —acá «sin dato» era la verdad; allá deja de serlo— pero tocan el mismo archivo. Sugiero mergear éste primero: el mío se apoya en que el stock_status ya venga del backend.