Casos de uso prácticos de DCP Flow
Dieciocho escenarios end-to-end que combinan Discovery, arquitectura/stack/cloud, Quality Gates, Git/multiagente, deploy/release, incidentes, upgrades y el caso website + CRM externo con EspoCRM ADOPTED como opción contextual.
Dieciocho escenarios end-to-end que combinan Discovery, arquitectura/stack/cloud, Quality Gates, Git/multiagente, deploy/release, incidentes, upgrades y el caso website + CRM externo con EspoCRM ADOPTED como opción contextual.
Los casos de uso prácticos muestran cómo varias capas de DCP Flow se combinan en situaciones reales. No son recetas rígidas: enseñan a seleccionar artefactos, gates y herramientas según el problema y el riesgo.
Escenarios end-to-end
Los dieciocho escenarios cubren discovery de nuevos productos, adopción de proyectos existentes, decisiones de hosting/cloud, trabajo multiagente, defectos de gates, cambios de permisos/datos, validación de artifacts, migraciones, incidentes y upgrades.
- Discovery y decisiones ADOPT/CONFIGURE/INTEGRATE/EXTEND/BUILD.
- Arquitectura, stack y cloud.
- QA, Git y multiagente.
- Deploy, incidentes y upgrades.
Aplicar la metodología en contexto
Otros escenarios cubren evaluación de tools/MCPs, Capability vs Authorization de Kai, transición de productos maduros hacia soporte y upgrades, promoción de aprendizajes repetidos y websites que integran un CRM externo sin convertirse ellos mismos en CRM. En ese escenario, EspoCRM es la opción CRM liviana ADOPTED, pero sigue siendo una selección contextual.
- Tool Catalog y MCP evaluation.
- Kai y Human Gates.
- Operación de productos maduros.
- Promoción de Lessons Learned.
Discovery y adopción en escenarios reales
Los casos de uso muestran cómo abordar un producto nuevo sin asumir BUILD, cómo reconstruir Project Truth en un repositorio existente y cómo elegir shared hosting, VPS o cloud separando requisitos arquitectónicos de preferencias de proveedor.
- Capability Matrix antes de construir.
- Audit antes de refactor masivo.
- Architecture requirement ≠ provider preference.
- Decisión proporcional al contexto.
Multiagente, gates y riesgo
Otros escenarios muestran cómo crear Concurrency Contracts para dos agentes, cómo clasificar Product/Gate/Harness Defect antes de cambiar una arquitectura correcta y cómo tratar cambios pequeños con alto riesgo —por ejemplo permisos o datos— según impacto y no según cantidad de líneas.
- Temporal ownership y Shared Interfaces.
- Git Conflict ≠ Functional Conflict.
- Gate defect no obliga a deformar producto.
- Change size ≠ risk level.
Artifact, release, incidentes y Kai
El Handbook aplica Artifact/Package Gate cuando el ZIP puede fallar aunque source y CI estén verdes; define Migration Ordering y recovery en releases de alto riesgo; organiza Incident Response; evalúa herramientas antes de adoptarlas; y separa capacidad de Kai de autorización cuando una acción puede ser destructiva.
- Source correct ≠ artifact correct.
- Release con backup/recovery evidence.
- Stabilize → understand → recover → verify.
- Capability ≠ Authorization.
Glosario contextual＋
Escenario práctico que muestra cuándo y cómo combinar partes de DCP Flow.
Recorrido crítico end-to-end que debe funcionar y producir evidencia verificable.
Procedimiento manual, verificable y explícito usado cuando Kai no puede ejecutar directamente una acción.
Punto de control donde la evidencia determina si el trabajo puede avanzar.