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/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.