diff --git a/bitacora/PENDIENTES.md b/bitacora/PENDIENTES.md
index 3a1f7f6..902eec1 100644
--- a/bitacora/PENDIENTES.md
+++ b/bitacora/PENDIENTES.md
@@ -7,7 +7,7 @@ _Última actualización: **2026-09-29** — plan del webhook Jira FAC → vista
 ## ⭐ 29-sep — webhook Jira FAC → vista previa de cotización ([REGISTRO #71](REGISTRO.md), [plan](../planeacion/Plan-Webhook-Jira-2026-09-29.md))
 
 - [ ] 📄 **Archivar en `fuentes/` la autorización escrita de Pedro** para crear el webhook/regla en Jira; anotar su alcance (¿incluye crear un ticket de prueba en FAC?).
-- [ ] 🔎 **Fase 1 (solo GET):** `myself` + `mypermissions` (ADMINISTER / ADMINISTER_PROJECTS en FAC) + inventario de webhooks → decide Vía A (webhook de sistema) o Vía B (regla de Automation).
+- [x] ~~🔎 **Fase 1 (solo GET):** `myself` + `mypermissions` (ADMINISTER / ADMINISTER_PROJECTS en FAC) + inventario de webhooks → decide Vía A (webhook de sistema) o Vía B (regla de Automation).~~ → **HECHO (29-sep):** `ADMINISTER`=true, 0 webhooks de sitio, API de Automation accesible (50+ reglas). Vía A y Vía B disponibles.
 - [ ] 🔴 **Decidir el evento:** creación del ticket, transición a *En proceso de facturación* (dura ~3 min), o ambos.
 - [ ] 🔧 **Fase 2:** `POST /api/jira/webhook` con secreto, relectura del ticket, idempotencia y solo dry-run; pruebas con `FakeHandler`. Poller de respaldo.
 - [ ] 🌐 **Fase 3:** ngrok con traffic policy de una sola ruta; API en ReadOnly mientras el túnel esté abierto.
diff --git a/bitacora/REGISTRO.md b/bitacora/REGISTRO.md
index cfff676..bc883d5 100644
--- a/bitacora/REGISTRO.md
+++ b/bitacora/REGISTRO.md
@@ -1628,6 +1628,8 @@ Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear
 **4. Webhook / Jira Automation — qué se necesita.** URL pública (ngrok ya instalado en la máquina de Johann; productivo = Azure o dominio fijo), endpoint nuestro `POST /api/jira/webhook` (no existe aún), y el disparador en Jira. Con el token actual: construir el endpoint sí (no requiere permisos de Jira); crear el webhook/regla en Jira solo si el usuario de Pedro es admin **y** con autorización expresa, porque es escribir en la configuración del Jira productivo a su nombre.
 - **Johann confirma que existe autorización escrita de Pedro** para hacerlo. ⚠️ Aún no archivada en `fuentes/`.
 
+**Fase 1 del plan — ejecutada el mismo 29-sep (solo GET, nada creado ni ejecutado):** `myself` 200 → Pedro Alberto Ayala Elizondo, activo · `mypermissions` en FAC: **`ADMINISTER` = true** (admin de Jira), `ADMINISTER_PROJECTS` = true, `CREATE_ISSUES` = true, `SYSTEM_ADMIN` = false (no se necesita) · `GET /rest/webhooks/1.0/webhook` 200 → **0 webhooks de sitio** (el endpoint exige admin: acceso confirmado) · API de Automation (`api.atlassian.com/automation/public/jira/{cloudId}/rest/v1/rule/summary`) 200 con el mismo token → **50+ reglas visibles** (primera página), casi todas de alcance sitio; relevantes para FAC: *Confirmación ticket creado - FACT*, *Factura por soporte técnico*, *Facturación Anticipada*. **Conclusión: el token de Pedro puede crear tanto el webhook de sitio (Vía A) como reglas de Automation (Vía B).** Queda archivar la autorización y decidir el evento.
+
 **Resultado:** plan en [`../planeacion/Plan-Webhook-Jira-2026-09-29.md`](../planeacion/Plan-Webhook-Jira-2026-09-29.md): 5 fases (verificar permisos por GET → endpoint con secreto/idempotencia/relectura → ngrok con traffic policy de una sola ruta → una escritura auditada en Jira, preferentemente webhook de sistema → ticket de prueba y reversa).
 
 **5. Hallazgos del mismo día hechos en la OTRA sesión de Claude Code** (fuente: `balam-plataforma/CLAUDE.md`, §Puente a la UI; no verificados en esta sesión):