Registro #70: el incidente del timbrado y el cierre de la investigación — el API de BIND ni crea ni ve prefacturas; candado triple y experimento decisivo pendiente

bitacora/REGISTRO.md

@@ -1573,6 +1573,30 @@ Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear
 
 ---
 
+## 70 · Ago 26, 2026 · Incidente + investigación de cierre · IsFiscalInvoice=true TIMBRA al crear (folio 2386) — y el API de BIND ni crea ni VE prefacturas 🔥⚠️
+
+> Contexto: entre el 23 y el 25-ago se construyó el camino cotización→prefactura (`POST /api/emision/prefactura`, mismo protocolo ADR-001). Los intentos con `IsFiscalInvoice=false` produjeron los folios 1000 y 1001 **como remisiones** (confirmado por Noé por correo), así que se cambió a `true` bajo la hipótesis "true = factura sin timbrar = la prefactura del flujo" — el API no tiene operación de timbrado (130 operaciones revisadas), y de ahí se infirió que crear no podía timbrar.
+
+**El incidente:** el 26-ago, al confirmar desde el wizard (op #73, cotización 1028 / ticket FAC-108), BIND creó la venta **2386 como Factura Electrónica (CFDI) y la timbró en el acto** — UUID `aa70001d-…`, $1,160 MXN, receptor ACUNTIA. **El timbrado vive DENTRO de la creación**, no en una operación aparte; la ausencia de operación de timbrado significaba lo contrario de lo inferido. El tripwire de la plataforma (verificación por lectura post-creación, "⚠️ TIMBRADA" si UUID ≠ null) lo detectó al instante. Contención el mismo día: confirmación de prefactura **bloqueada con 409** en el endpoint (commit `c5143cf`, pusheado), API reiniciado en ReadOnly, instrucciones de cancelación SAT (motivo 02) comunicadas.
+
+**Investigación de cierre (misma fecha, SOLO GETs contra producción):**
+- **El body de `Invoices_AddInvoice` no tiene campo de tipo de documento.** Verificado contra dos fuentes primarias: el portal APIM (27 campos) y el swagger oficial del SDK de Python de BIND — coinciden campo por campo. El `UseStock` que sugieren los resúmenes de IA de Google **no existe** (respuesta fabricada; también da `UseCFDI:"G03"` como string cuando `CFDIUse` es un int interno).
+- **`false` = remisión, comprobado con la verdad impresa:** los PDFs por API (`GET /api/Invoices/{id}/pdf`) de 1000, 1001 y 2384 titulan **"Remision"**; el de 2386 titula "Factura Electrónica (CFDI)".
+- **No existe el estado intermedio:** 0 filas con `IsFiscalInvoice=true and UUID=null` en TODA la cuenta. BIND timbra al crear, siempre.
+- **Censo completo de no fiscales: 58 documentos, todos remisiones.** Únicos activos: nuestros 1000 y 1001; los otros 56, cancelados. **Ni una prefactura visible en `/api/Invoices`** — la afirmación de VALIDACION-API.md (6-jul) "false = prefactura" era una inferencia errada sobre filas que en realidad son remisiones.
+- `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).
+
+> **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.
+> - **Candado triple ya en código** (commit local `fbb31fc`): `IsFiscalInvoice=false` clavado en el builder, `permitirFiscal:false` clavado en la llamada, y el 409 en Confirmed. `EsFiscal` quedó inerte.
+> - **Experimento decisivo pendiente (riesgo cero):** que un humano cree UNA prefactura en la UI de BIND (documento no fiscal, borrable) y re-escanear el API para ver si aparece y con qué firma. Si no aparece, el flujo de plataforma debe asumir que la prefactura es invisible por API y la detección automática solo puede ocurrir al timbrado (la factura sí es visible).
+> - ⚠️ **Al 26-ago (tarde) la 2386 sigue `Activa` con UUID en BIND — la cancelación SAT no se ha ejecutado.** Y 1000/1001 siguen activas (existe `DELETE /api/Invoices/{id}` si se quiere limpiar por API, con autorización).
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam