Bitácora: correo de Noé pide salvaguardas sobre el token (posible reemplazo por usuario solo-lectura)

bitacora/PENDIENTES.md

@@ -11,6 +11,8 @@ _Última actualización: 2026-07-06 (Discovery realizado: proceso mapeado, lista
 - [ ] 🎨 **Trabajar el prototipo (Etapa 0)** reflejando el flujo real levantado el 6-jul: Jira (disparador) → cotización BIND → prefactura → validación humana → CFDI → envío. Incluir las validaciones de oro: **PPD default** (PUE consciente — ya les costó un requerimiento del SAT), **IVA 16% MXN / 0% extranjero** (BIND no lo automatiza), prefactura siempre antes de timbrar, alta de cliente como flujo aparte. Ver [REGISTRO #27](REGISTRO.md).
 - [x] ~~📅 **Proponer a Erika usar la sesión del martes 7-jul para COBRANZA**~~ → **Propuesto (6-jul, 3:01 pm):** Erika revisa la agenda con los involucrados y confirma. Ideal que ocurra antes del viernes 10 (validación del prototipo). Ver [REGISTRO #30](REGISTRO.md).
 - [x] ~~📧 **Responder el correo de Pedro**~~ → **Enviado (6-jul, ~3:28 pm):** acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver [REGISTRO #29](REGISTRO.md).
+- [ ] 📧⚠️ **Responder el correo de Noé (importancia alta, 4:33 pm)** describiendo las **salvaguardas** ya operando: solo-lectura bloqueado en código, consultas acotadas, token en gestor de secretos fuera del repo, sin datos reales en documentos, escritura solo con autorización + candados de la propuesta. Borrador listo. Ver [REGISTRO #31](REGISTRO.md).
+- [ ] ⚠️ **No atar nada al token actual:** Pedro está revisando permisos y puede **reemplazarlo** por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver [REGISTRO #31](REGISTRO.md).
 - [ ] 🔑 **Validar la API de BIND con el token real** (mar 7 – mié 8 del plan; puede adelantarse) — guardar el token en **gestor de secretos** (no dejarlo en el correo/.txt), correr el sandbox (`bind-api-sandbox/`) contra `api.bind.com.mx` en **solo lectura**, documentar cobertura de endpoints (facturas, clientes, pagos, cotizaciones) y confirmar si caduca. Entregar resumen de hallazgos. Ver [REGISTRO #28](REGISTRO.md).
 - [ ] ⚠️ **Aclarar expectativa de recordatorios a clientes:** lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos **a clientes**, que están **diferidos al Anexo B** (el MVP trae alertas *internas*). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de **agentes observando Jira** (Nivel 3, fase posterior) y el deseo **multi-empresa** (Regiotour, Elmstone). Ver [REGISTRO #27](REGISTRO.md).
 - [x] ~~**Ajustar la propuesta** (30 h explícitas, sin "Etapa 0", términos comerciales en una sección)~~ → **Hecho (1-jul):** propuesta **v1.2** — se agregó el concepto **"Facturación inicial: 30 h / $18,000 + IVA"** (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó **§3.3 Condiciones comerciales**. Fuente MD actualizada; **falta regenerar el PDF** (lo hace el agente de PDF de Johann con el mismo cambio).

bitacora/REGISTRO.md

@@ -602,6 +602,24 @@ Johann plantea a Erika que la sesión de hoy solo alcanzó para **facturación y
 
 ---
 
+## 31 · Jul 6, 2026 — 4:33 PM · Correo · Noé → Johann, Pedro (CC Erika) · salvaguardas sobre el token ⚠️
+
+> **Importancia alta.** Evidencia: `../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md` (respuesta de Noé en el hilo).
+
+Noé responde al hilo de la entrega del token con dos instrucciones:
+
+1. **A Johann:** mientras Pedro revisa si el acceso es de lectura o también de **escritura**, aplicar *"las salvaguardas necesarias para evitar alguna afectación operativa"*.
+2. **A Pedro:** si es necesario, **crear un usuario específico de solo lectura** en BIND para esta etapa de exploración — *"la cuenta de Arturo tiene algunos privilegios elevados que creo que no serían necesarios en este momento"*.
+
+**Implicación:** el token de Arturo **podría ser reemplazado** por uno de un usuario nuevo de solo lectura.
+
+> **Lectura estratégica:**
+> - La preocupación de Noé es **exactamente el diseño ya construido**: el sandbox opera en modo solo-lectura por defecto con bloqueo de escrituras en código, dry-run, cuota vigilada y token fuera del repo (`.gitignore` ya cubre `bind_token_api.txt` y `*.env`). Responder describiendo esas salvaguardas convierte un correo de riesgo en una oportunidad de confianza con el CTO.
+> - Ojo operativo: si Pedro crea un usuario nuevo, **el token cambiará** — no invertir esfuerzo en atar nada al token actual; el cliente ya está parametrizado por variable de entorno, el cambio es trivial.
+> - Coherente con la estrategia "lectura primero" de la propuesta: nadie está pidiendo frenar la validación, solo asegurar el perímetro.
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam

fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md

@@ -30,6 +30,16 @@
 
 ---
 
+**Respuesta de Noé (4:33 PM, a Johann y Pedro, CC Erika — ⚠️ importancia alta):**
+
+> Buenas tardes Johan,
+>
+> Pedro va a revisar si el acceso es de lectura o también de escritura, por lo que te pido mientras tanto **las salvaguardas necesarias para evitar alguna afectación operativa**.
+>
+> @Pedro Alberto Ayala Elizondo, si es necesario crea un usuario específico de solo lectura en Bind para esta etapa de exploración, si la única forma de dar lectura es crear un nuevo usuario y token adelante; la cuenta de Arturo tiene algunos privilegios elevados que creo que no serían necesario en este momento.
+>
+> Saludos.
+
 **Notas:**
 - Confirma que el token salió del **usuario de Arturo Rosas** — conforme al acuerdo del kickoff (token de Arturo para desarrollo; el de Ara para Power BI). Cierra el pendiente de documentar cuál llave es para qué.
 - El token viaja en `.txt` adjunto al correo → pasarlo a **gestor de secretos** y no conservarlo en el buzón/descargas.