Proyecto 03 · Metodología original
SDD × Power Platform Framework
Microsoft define Spec-Driven Development como la metodología recomendada para desarrollo enterprise asistido por IA. Este framework adapta ese ciclo validado al ecosistema Power Platform: Canvas Apps, Power Automate, Dataverse y ALM con pac cli.
// el problema
El problema estructural de Power Platform
Power Platform tiene un problema de vibe coding estructural. El umbral de entrada es bajo, y eso hace que la gente construya sin especificar. Un Maker abre Power Apps Studio y empieza a arrastrar controles sin haber definido el modelo de datos. Un Flow se construye iterando directamente en producción porque "es más rápido así". Nadie documentó qué conectores se usan ni por qué — hasta que DLP rompe el flow seis meses después.
SDD (Spec-Driven Development) es la metodología que Microsoft recomienda para desarrollo enterprise asistido por IA. Su módulo oficial cubre el ciclo Specify → Plan → Tasks → Implement para software tradicional con GitHub Copilot y VS Code. No cubre Power Platform. Este framework cierra ese gap.
// el gap
Qué agrega este framework al módulo de Microsoft
| Dimensión | Módulo Microsoft SDD | Este framework |
|---|---|---|
| Toolchain de IA | GitHub Copilot + VS Code | Power Platform CLI (pac) |
| Tipo de spec | Clases, funciones, APIs | Canvas Apps, Flows, Dataverse schemas |
| Constitution | Estándares de ingeniería | DLP policy + naming + environment strategy |
| Decisión de tipo | Lenguaje (TS, Python, C#) | Canvas vs. Model-Driven |
| ALM | git + GitHub Actions | pac solution export/import + Solution Checker |
| Testing | Unit tests | Test Studio alineado a criterios EARS |
| CI/CD | GitHub Actions | Power Platform Pipelines |
// el framework
El ciclo SDD adaptado a Power Platform
Capturar la intención de negocio antes de abrir Studio. Criterios de aceptación en notación EARS. El stakeholder firma antes de que empiece el desarrollo.
Traducir el spec a decisiones técnicas: schema Dataverse, tipo de app, arquitectura del Flow, conectores, modelo de seguridad. Verificar cada conector contra DLP antes de hacer commit.
Descomponer el plan en tareas atómicas. Una componente = una tarea. Cada tarea referencia la sección del spec que la originó y tiene criterio de verificación claro.
Implementar dentro de los límites del spec y el plan. Tests de Test Studio escritos contra criterios EARS. Constitution check antes de cualquier PR.
// notación EARS
Criterios de aceptación en lenguaje que negocio y técnica entienden
EARS (Easy Approach to Requirements Syntax) hace que los criterios de aceptación sean inequívocos y testeables. Aplicado a Power Platform, cada criterio mapea directamente a un test en Test Studio.
| Patrón | Cuándo usarlo | Ejemplo en Power Platform |
|---|---|---|
| WHEN...SHALL | Acciones de usuario, triggers de Flow | WHEN user submits form THE app SHALL validate RUT before saving. |
| IF...THEN SHALL | Manejo de errores, condiciones límite | IF Outlook connector fails THEN THE flow SHALL retry 3 times and notify admin. |
| WHILE...SHALL | Estados de app o registro | WHILE request is In Review THE form SHALL disable all fields for the requestor. |
| THE [sys] SHALL | Reglas siempre verdaderas → constitution | THE solution SHALL never store credentials in flow variables. |
| WHERE...SHALL | Funcionalidad condicional por rol | WHERE user has Approver role THE app SHALL show the decision history panel. |
// preguntas honestas
Las preguntas que alguien siempre hace
No. Waterfall congela el spec al inicio y penaliza el cambio. SDD versiona el spec junto al código y lo actualiza cuando los requerimientos cambian. Cuando el negocio cambia de opinión — y siempre lo hace — actualizas spec.md, revisas el plan, y ajustas desde un lugar de intención clara, no de deuda técnica acumulada.
Copilot para Power Apps genera apps de la misma forma que vibe coding genera código: rápido para demos, frágil para producción. Sin un spec que defina el modelo de datos, los roles de seguridad y los edge cases, Copilot produce exactamente el problema que SDD resuelve. El spec es el prompt que hace que Copilot genere algo útil.
Un spec bien escrito toma 2–4 horas. Un bug de seguridad por column-level security mal configurado, o un Flow en loop infinito por falta de condición de idempotencia, toma días. La pregunta correcta no es "tenemos tiempo para SDD" sino "tenemos tiempo para no tenerlo".
El ciclo SDD está validado por Microsoft para desarrollo enterprise. Su módulo oficial cubre software tradicional — no Power Platform. Este framework toma esa metodología validada y la adapta al ecosistema específico de Power Platform, donde las restricciones de DLP, la gobernanza de conectores, los límites de delegación y el ALM con pac cli hacen que la metodología no sea trivial de aplicar sin adaptación. La metodología es de Microsoft. La adaptación a Power Platform es la contribución de este framework.
Framework completo — por email
El framework completo con templates anotados y ejemplos está disponible por email. Déjame tu nombre y correo y te lo envío.
Gracias — te llega en minutos.