Skip to content

PENDING.md

Latest commit

 

History

History
98 lines (80 loc) · 4.22 KB

PENDING.md

File metadata and controls

98 lines (80 loc) · 4.22 KB

⏳ Pending

Captura trabajo conocido pero aún sin fecha — el "lo haremos algún día pero no ahora".

🎯 Aquí entra: deuda detectada, follow-ups de incidentes, feedback accionable, "esto hay que hacerlo pero no hemos decidido cuándo". 🚫 Aquí NO entra: trabajo ya agendado a un milestone (eso va a Linear).

🪄 Promoción: ponerle un milestone a un pending lo convierte en task Linear BEE-XXXX y se elimina automáticamente de este fichero.

📋 Cómo añadir un pending

Usa el skill /pending (recomendado). O copia este bloque al final del fichero:

### ⏳ pending-NNN — [Título corto]

- 📅 **Fecha añadida**: YYYY-MM-DD
- 🏷️ **Tipo**: feat | fix | docs | refactor | chore | infra | security | test
- 🧭 **Trigger**: por qué se añadió (incidente, feedback, deuda)
- ⚙️ **Acción requerida**: qué hay que hacer concretamente
- 🚧 **Bloqueado por**: (si aplica) algo o alguien que retrasa
- 🚦 **Estado**: 🆕 Nuevo

🏷️ Tipos disponibles

Tipo Cuándo usarlo
feat Funcionalidad nueva
fix Bug fix
docs Solo documentación
refactor Refactor sin cambio de comportamiento
chore Mantenimiento, deps, config
infra Infraestructura, CI/CD
security Cuestiones de seguridad
test Solo tests

🚦 Estados posibles

Iconito Estado Significado
🆕 Nuevo Recién capturado, sin triage
🔍 En triage Decidiendo prioridad / scope
📋 Promovido Ya es task Linear (BEE-XXXX) — debería haberse eliminado de aquí
🚧 Bloqueado Esperando algo externo (especificar)
❌ No procede Decidido no avanzar (apuntar el porqué)

🗂️ Pendientes registrados

⏳ pending-001 — Validar 1 consumidor externo integrando @beeping/react-native en producción

  • 📅 Fecha añadida: 2026-05-12
  • 🏷️ Tipo: feat
  • 🧭 Trigger: durante /worktree-init de beeping-react-native se evaluó como objetivo medible secundario alternativo a la métrica principal de Phase 12 (sample app Expo enviando+recibiendo en iOS+Android sin crashes). La métrica de "publicar en npm + 1 consumidor externo integrado" se capturó aquí porque no es un cierre de Phase 12 — es un objetivo post-publish que requiere outreach + soporte a un early adopter externo.
  • ⚙️ Acción requerida: tras cerrar Phase 12 (BEE-121 publica @beeping/react-native@0.x en npm con provenance), buscar 1 desarrollador externo dispuesto a integrar el SDK en una app RN real. Ofrecerle soporte directo durante la integración, capturar los pain points en docs/IDEAS.md o nuevos pending, y validar que la API es consumible sin lectura de código fuente. Salida: un caso de uso real documentado + lista de fixes/improvements derivados.
  • 🚧 Bloqueado por: cierre de Phase 12 (@beeping/react-native@0.x publicado en npm) — actualmente bloqueado por BEE-121.
  • 🚦 Estado: 🚧 Bloqueado

⏳ pending-002 — Validar paridad API 100% con beeping_flutter

  • 📅 Fecha añadida: 2026-05-12
  • 🏷️ Tipo: test
  • 🧭 Trigger: durante /worktree-init de beeping-react-native se evaluó como objetivo medible secundario alternativo a la métrica principal de Phase 12. La paridad API con beeping_flutter (mismo BeepingClient, mismas opciones, mismos errores, misma superficie pública conceptual) es un objetivo de ecosistema que cruza dos repos y no puede cerrarse dentro de Phase 12 — depende del estado actual de beeping_flutter (Phase 10) y de un test cross-SDK.
  • ⚙️ Acción requerida: una vez Phase 10 (beeping_flutter) y Phase 12 (beeping-react-native) cierren, escribir una suite de paridad que: (a) liste la superficie pública de ambos SDKs en un fichero compartido YAML/JSON; (b) genere un test que falle si hay drift; (c) viva en beeping-meta o en un nuevo repo beeping-api-contract. Incluir validación de nombres de métodos, signaturas conceptuales, error codes comunes, opciones de BeepingClient.
  • 🚧 Bloqueado por: cierre de Phase 10 (beeping_flutter) y Phase 12 (beeping-react-native).
  • 🚦 Estado: 🚧 Bloqueado