Adenda al #70: el folio 2384 ES prefactura (confirmado en UI) — prefacturas visibles por API, status 2 = facturada, y el discriminador es la secuencia de folios

bitacora/PENDIENTES.md

@@ -8,8 +8,9 @@ _Última actualización: **2026-08-21, mediodía** — ⭐ primera cotización r
 
 - [ ] 🔥🔴 **CANCELAR EL CFDI 2386 EN BIND** (motivo SAT 02 "sin relación"). ⚠️ **Al 26-ago tarde sigue `Activa` con UUID** — verificado por API. Receptor ACUNTIA (RFC genérico extranjero, $1,160 MXN). Confirmar además que BIND no le haya enviado el correo automático al cliente.
 - [ ] 📧 **Avisar a Noé/Arturo del incidente con transparencia** (qué pasó, por qué, contención aplicada, CFDI cancelado). La plataforma tiene la auditoría completa en `WriteOperations` #73.
-- [ ] 🧪 **Experimento decisivo (riesgo cero): crear UNA prefactura a mano en la UI de BIND** (Generar Venta → Prefactura, cliente de prueba; documento no fiscal y borrable) y avisar a Johann el folio → re-escanear el API para ver si aparece y con qué firma. De esto depende si la plataforma puede siquiera DETECTAR prefacturas, o solo el timbrado posterior.
-- [ ] 📧 **Preguntar a Pedro / soporte BIND:** "¿cómo se crea una venta de tipo *Prefactura* por API? `Invoices_AddInvoice` solo distingue `IsFiscalInvoice` (false=remisión, true=factura timbrada al crear)". Adjuntar la evidencia del #70.
+- [x] ~~🧪 **Experimento decisivo: crear UNA prefactura a mano en la UI**~~ → **RESUELTO sin crear nada: el folio 2384 (Araceli, 19-ago) ES una prefactura** — confirmado en UI por Johann. Prefacturas = filas `false`+UUID null; `Status=2` = facturada (parió a la 2385 timbrada). Ver adenda del [#70](REGISTRO.md). **La detección/vinculación automática de prefacturas ya es construible sin escribir.**
+- [ ] 🧪 **Experimento seguro pendiente de go-ahead: POST `false` apuntando a la secuencia de folios compartida** (`Number` explícito + espejo de 2384: `CFDIUse=23`, `ShowIEPS=true`, plazo) para ver si la UI lo etiqueta Prefactura. Riesgo máximo: documento no fiscal borrable con folio raro. Requiere `Bind:Mode=Write` en sesión y autorización expresa.
+- [ ] 📧 **Preguntar a Pedro / soporte BIND:** "¿cómo se crea una venta de tipo *Prefactura* por API? Con `IsFiscalInvoice=false` cae como Remisión (secuencia 1000) y con `true` se timbra al crear; el diff contra una prefactura real no muestra ningún campo de tipo". Adjuntar la evidencia del #70.
 - [ ] 🧹 **Borrar las remisiones 1000 y 1001** (siguen `Activas`). En la UI, o por API (`DELETE /api/Invoices/{id}`) con autorización expresa.
 
 ## ✅ 21-ago — la cotización ya se emite; lo que deja la sesión ([REGISTRO #69](REGISTRO.md))

bitacora/REGISTRO.md

@@ -1587,7 +1587,13 @@ Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear
 - `Orders` tampoco: 1 pedido (2024, cancelado). El detalle de venta no expone claves ocultas que discriminen tipo.
 - ⚠️ Efecto colateral del API detectado: la **lista** reporta `Status=2` en filas cuyo **detalle** dice `Activa` (1000/1001), y `Number` no es único entre series — la búsqueda por número es ambigua. Confiar solo en detalle por GUID.
 
-**Conclusión:** la "Prefactura" del combo de la UI de BIND **no es expresable ni observable por su API pública** con lo documentado. Queda una incógnita: dónde queda almacenada una prefactura creada por la UI (en esta cuenta nunca ha existido una, así que no hay espécimen que leer).
+**Conclusión (revisada el mismo día — ver adenda):** la "Prefactura" del combo de la UI de BIND **no es expresable por su API pública** con lo documentado. Queda una incógnita: dónde queda almacenada una prefactura creada por la UI (en esta cuenta nunca ha existido una, así que no hay espécimen que leer).
+
+**ADENDA (26-ago, tarde) — apareció el espécimen y reescribe medio registro.** El folio **2384** (VictTec, $1,650 USD, 19-ago, creado por Araceli) **SÍ es una Prefactura — confirmado por Johann en la UI**. Con eso:
+- **Las prefacturas SÍ son visibles por API** (VALIDACION-API.md tenía razón a medias): son filas `IsFiscalInvoice=false`+`UUID=null`. Lo errado era leer `Status=2` como "cancelada": en el precursor significa **consumida/facturada** — la 2384 parió a la **2385** (misma fecha, mismo total, timbrada) y quedó en 2. Las 56 "canceladas" del censo son los precursores históricos del flujo real de Balam (el PDF por API las titula "Remision" aunque sean prefacturas: la plantilla no distingue).
+- **Diff campo por campo prefactura 2384 vs remisión 1000: NO existe campo de tipo.** Diferencias completas: `CFDIUse` 23 vs 3, `ShowIEPS` true vs false, `PaymentTerms` 30 vs 0, `CFDIPaymentTerm` con valor vs vacío — todo son valores del payload, nada discrimina el tipo.
+- ⭐ **El discriminador observable es la SECUENCIA DE FOLIOS:** las prefacturas de la UI comparten numeración con las facturas (2384 → 2385 → 2386 fue nuestro incidente); nuestros `false` por API caen en la secuencia de remisiones (arrancó en 1000, virgen porque Balam no usa remisiones). Hipótesis operativa: la UI etiqueta por secuencia/typo interno; el body de `Invoices_AddInvoice` trae `Number` y `Serie` — **candidato a experimento seguro**: POST con `false` + `Number` apuntando a la secuencia compartida (+ espejo exacto de 2384: `CFDIUse=23`, `ShowIEPS=true`, plazo), verificar en UI cómo cae, y borrar si cae mal. Riesgo máximo: un documento no fiscal borrable con folio raro. Solo con go-ahead explícito y `Bind:Mode=Write` en sesión.
+- **Detección construible YA sin tocar nada:** prefactura de UI = fila `false` nueva (ligable a cotización/ticket por cliente+monto+fecha) y su facturación = fila pasa a 2 + gemela `true` timbrada. El flujo "plataforma cotiza → Araceli genera prefactura en BIND → plataforma detecta, liga y avisa el timbrado" funciona con el API actual, sin escribir.
 
 > **Lectura estratégica:**
 > - **La salvaguarda que funcionó fue la de diseño, no la de inferencia:** dry-run + confirmación humana + verificación por lectura acotaron el daño a un folio cancelable. La lección: contra un API sin sandbox, ninguna inferencia negativa ("no hay operación X ⇒ X no puede pasar") es válida sin prueba positiva.