@tacuchi/agent-workflow-cli 11.0.1 → 12.0.0

package/skills/agent-workflow/standards/testing-strategy/references/test-levels.md

@@ -1,255 +0,0 @@
-# Niveles de test — Referencia completa
-
-## Backend (Spring Boot / Java)
-
-### Nivel a) Unitarios — Ejemplo completo
-
-```java
-@ExtendWith(MockitoExtension.class)
-class NotificacionServiceTest {
-
-    @Mock
-    private EmailProvider emailProvider;
-
-    @Mock
-    private NotificacionRepository repository;
-
-    private NotificacionService service;
-
-    @BeforeEach
-    void setUp() {
-        // Constructor Injection (mismo patrón que producción)
-        service = new NotificacionService(emailProvider, repository);
-    }
-
-    @Test
-    void enviar_conEmailValido_retornaExito() {
-        // Arrange — record como DTO
-        var request = new NotificacionRequest("user@example.com", "Aprobación", "aprobacion", Map.of());
-        when(emailProvider.send(any())).thenReturn(true);
-
-        // Act
-        var resultado = service.enviar(request);
-
-        // Assert
-        assertThat(resultado).isTrue();
-        verify(emailProvider).send(any());
-    }
-
-    @Test
-    void enviar_sinDestinatario_lanzaBadRequest() {
-        var request = new NotificacionRequest(null, "Asunto", "template", Map.of());
-
-        assertThatThrownBy(() -> service.enviar(request))
-            .isInstanceOf(BadRequestException.class)
-            .hasMessageContaining("destinatario");
-    }
-
-    @Test
-    void enviar_proveedorFalla_registraError() {
-        var request = new NotificacionRequest("user@example.com", "Asunto", "template", Map.of());
-        when(emailProvider.send(any())).thenThrow(new RuntimeException("SMTP error"));
-
-        var resultado = service.enviar(request);
-
-        assertThat(resultado).isFalse();
-        verify(repository).guardarLog(any());
-    }
-}
-```
-
-Ejecutar con: `./mvnw test -Dtest=NotificacionServiceTest` (Windows: `mvnw.cmd test`)
-
-### Nivel b) Unitarios + API — Ejemplo MockMvc
-
-```java
-@WebMvcTest(NotificacionController.class)
-class NotificacionControllerTest {
-
-    @Autowired
-    private MockMvc mockMvc;
-
-    @MockBean
-    private NotificacionService service;
-
-    @Test
-    void enviar_conDatosValidos_retorna200() throws Exception {
-        when(service.enviar(any())).thenReturn(true);
-
-        // Request body usa record NotificacionRequest
-        mockMvc.perform(post("/api/v1/notificaciones/enviar")
-                .contentType(MediaType.APPLICATION_JSON)
-                .content("{\"destinatario\":\"user@example.com\",\"asunto\":\"Test\",\"templateId\":\"aprobacion\"}"))
-            .andExpect(status().isOk());
-    }
-
-    @Test
-    void enviar_sinBody_retorna400() throws Exception {
-        mockMvc.perform(post("/api/v1/notificaciones/enviar")
-                .contentType(MediaType.APPLICATION_JSON))
-            .andExpect(status().isBadRequest());
-    }
-}
-```
-
-Ejecutar con: `./mvnw test`
-
-### Nivel c) Completo — Ejemplo @SpringBootTest
-
-```java
-@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
-@AutoConfigureMockMvc
-@Transactional
-class NotificacionIntegrationTest {
-
-    @Autowired
-    private MockMvc mockMvc;
-
-    @Autowired
-    private NotificacionRepository repository;
-
-    @Test
-    void flujoCompleto_enviarYRegistrar_persisteLog() throws Exception {
-        mockMvc.perform(post("/api/v1/notificaciones/enviar")
-                .contentType(MediaType.APPLICATION_JSON)
-                .content("{\"destinatario\":\"user@example.com\",\"asunto\":\"Test\"}"))
-            .andExpect(status().isOk());
-
-        var logs = repository.findByDestinatario("user@example.com");
-        assertThat(logs).isNotEmpty();
-    }
-}
-```
-
-Ejecutar con: `./mvnw verify`
-
-## Frontend (Angular)
-
-### Nivel a) Unitarios — Service aislado
-
-```typescript
-describe('AuthService', () => {
-  let service: AuthService;
-  let httpMock: HttpTestingController;
-
-  beforeEach(() => {
-    TestBed.configureTestingModule({
-      imports: [HttpClientTestingModule],
-      providers: [AuthService]
-    });
-    service = TestBed.inject(AuthService);
-    httpMock = TestBed.inject(HttpTestingController);
-  });
-
-  afterEach(() => httpMock.verify());
-
-  it('should return token on login', () => {
-    service.login('admin', 'pass').subscribe(res => {
-      expect(res.token).toBeTruthy();
-    });
-
-    const req = httpMock.expectOne('/api/auth/login');
-    req.flush({ token: 'abc123' });
-  });
-
-  it('should handle login error', () => {
-    service.login('bad', 'creds').subscribe({
-      error: err => expect(err.status).toBe(401)
-    });
-
-    const req = httpMock.expectOne('/api/auth/login');
-    req.flush('Unauthorized', { status: 401, statusText: 'Unauthorized' });
-  });
-});
-```
-
-Ejecutar con: `ng test --watch=false`
-
-### Nivel b) Unitarios + Componentes — TestBed
-
-```typescript
-describe('FiltrosComponent', () => {
-  let component: FiltrosComponent;
-  let fixture: ComponentFixture<FiltrosComponent>;
-
-  beforeEach(async () => {
-    await TestBed.configureTestingModule({
-      imports: [FiltrosComponent, NoopAnimationsModule]
-    }).compileComponents();
-    fixture = TestBed.createComponent(FiltrosComponent);
-    component = fixture.componentInstance;
-    fixture.detectChanges();
-  });
-
-  it('should create', () => {
-    expect(component).toBeTruthy();
-  });
-
-  it('should render date inputs', () => {
-    const compiled = fixture.nativeElement;
-    expect(compiled.querySelector('input[type="date"]')).toBeTruthy();
-  });
-
-  it('should emit on filter apply', () => {
-    spyOn(component.filtroChanged, 'emit');
-    component.filtroForm.patchValue({ estado: 'ACTIVO' });
-    component.aplicarFiltro();
-    expect(component.filtroChanged.emit).toHaveBeenCalledWith(
-      jasmine.objectContaining({ estado: 'ACTIVO' })
-    );
-  });
-});
-```
-
-## TestBuilder — Patrón (Java)
-
-```java
-public class NotificacionTestBuilder {
-    private Long id = 1L;
-    private String destinatario = "test@example.com";
-    private String asunto = "Test";
-    private String estado = "PENDIENTE";
-    private LocalDateTime fechaCreacion = LocalDateTime.now();
-
-    public static NotificacionTestBuilder builder() {
-        return new NotificacionTestBuilder();
-    }
-
-    public NotificacionTestBuilder destinatario(String val) {
-        this.destinatario = val;
-        return this;
-    }
-
-    public NotificacionTestBuilder estado(String val) {
-        this.estado = val;
-        return this;
-    }
-
-    public Notificacion build() {
-        var entity = new Notificacion();
-        entity.setId(id);
-        entity.setDestinatario(destinatario);
-        entity.setAsunto(asunto);
-        entity.setEstado(estado);
-        entity.setFechaCreacion(fechaCreacion);
-        return entity;
-    }
-}
-```
-
-## Resumen de comandos por stack
-
-### Spring Boot (Maven wrapper)
-- Nivel a: `./mvnw test -Dtest=ClaseTest`
-- Nivel b: `./mvnw test`
-- Nivel c: `./mvnw verify`
-- Windows: usar `mvnw.cmd` en lugar de `./mvnw`
-
-### Angular
-- Nivel a/b: `ng test --watch=false`
-- Nivel c: `npm run e2e` (si configurado)
-
-### Gradle
-- Nivel a: `./gradlew test --tests ClaseTest`
-- Nivel b: `./gradlew test`
-- Nivel c: `./gradlew integrationTest` (o `check`)

package/skills/agent-workflow/workflows/README.md

@@ -1,12 +0,0 @@
-# workflows/
-
-Flows del lifecycle: cómo se mueve una sesión por sus fases.
-
-Contenido esperado (T2 PR2):
-
-- `dev-workflow.md` — planning → execution → validation → closure; M1 ask antes de commit; gates por fase.
-- `design-workflow.md` — discovery → design → spec → closure; produce DELIVERY.md graduable.
-- `analyze-workflow.md` — discovery → evidence → findings → conclusions; produce CONCLUSIONS.md.
-- `core-workflow.md` — sub-flow agnóstico embebido en los 3 anteriores (artefactos comunes).
-
-Cada workflow declara: phases, artefactos requeridos, prompts (M1/M10/S2/S3/S6/S7) y transitions válidas.

package/skills/agent-workflow/workflows/analyze-workflow/SKILL.md

@@ -1,94 +0,0 @@
----
-name: analyze-workflow
-description: Workflow especializado analyze (especialidad investigación read-only), antes en qtc-analyze. Consumido por /agent-workflow:session cuando flow=analyze para orquestar el lifecycle universal con composición analyze-específica según modalidad.
-version: 2.2.0
-flow: analyze
-workflow_schema: 1.0
----
-
-# Analyze Workflow
-
-Workflow declarativo del flow=analyze. Define dos modos:
-
-- **Standalone** (`/agent-workflow:use`): investigación puntual sin sesión.
-- **Orchestrated** (consumido por `/agent-workflow:session` con flow=analyze): orquesta investigación + síntesis + recomendación según modalidad.
-
-## Brief
-
-**flow=analyze** es la especialidad de investigación **read-only** del plugin qtc. No edita código ni muta BD. Produce `CONCLUSIONS.md` consumible por flow=dev vía handoff.
-
-**Política de commits**: ver `agent-workflow:commits-policy` (canónico). El flow=analyze es read-only por construcción; cuando el usuario solicita un commit (típicamente al cierre, pero puede ser en otra fase si edita artefactos), aplica Regla 3 propose-then-execute universal con M1.
-
-**Política sin fallback al CLI (transversal al flow=analyze)**: si `agent-workflow <subcmd>` falla (no está en PATH, comando no reconocido, exit code != 0), **cortá la acción y reportá al usuario**: pedile que verifique `npm install -g @tacuchi/agent-workflow-cli`. No hay flujo alternativo Python.
-
-### Rama base (canon v3.5+)
-
-Las sesiones `flow=analyze` resuelven la rama esperada de cada fuente como `main_branch` (default `certificacion`) cuando NO se declaran branches en la sesión. Razón: el análisis necesita reflejar producción, no una rama de feature.
-
-- Si el repo de la fuente está en otra rama, el lifecycle dispara el flujo proactivo de verificación (Caso A o B según `dirty`) y bloquea avance hasta resolver.
-- Si durante la investigación el usuario decide **editar** código, se aplica **Caso C** (`agent-workflow/skills/session/references/branch-verification.md`): preguntar nombre de la rama de trabajo, ofrecer `checkout` (existe) o `checkout -b` desde `main_branch` (no existe), y registrar en AW-PROJECT.Status. El skill `analyze-workflow` no edita por sí mismo; la decisión de editar implica un handoff o cambio de flow.
-- Override explícito al crear la sesión: `--branches alias:rama` declarado gana sobre el default `main_branch`. Útil cuando se quiere analizar contra una rama puntual (ej. una feature en validación).
-
-Skills disponibles:
-- **analyze-synthesize**: estructura información en plan/hallazgos (exportada cross-flow, **clave** invocada por agent-workflow:session en planning).
-- **analyze-investigate**: recolección de evidencia divergente con cost guard (exportada).
-- **analyze-conclude**: cierre del análisis con `CONCLUSIONS.md` modulado por `## Modality` (technical/incident/data). Una sola skill, una sola estructura.
-
-Diferencia clave de **modalidad** (embebida como `## Modality` en CONCLUSIONS.md):
-- `technical` (legacy: `tecnica`): pregunta arquitectónica/diseño → cuerpo modulado como propuesta (opciones consideradas + decisión recomendada). **Solo cuando hay una decisión genuina que el stakeholder planteó**; si el scope es claro sobre un stack maduro, una recomendación acotada basta (ver "Moderación" abajo).
-- `data` (legacy: `datos`): análisis cuantitativo → cuerpo modulado como informe (hallazgos numéricos + interpretación + acciones sugeridas).
-- `incident` (legacy: `incidente`): post-mortem retrospectivo → cuerpo modulado con timeline + causa raíz + impacto + acciones preventivas.
-
-CONCLUSIONS.md vive en la sesión por default. Gradúa opt-in con `kind=conclusion` a `docs/conclusiones/`.
-
-## Moderación — anti sobre-análisis (hub maduro / requerimiento simple)
-
-Regla transversal del flow=analyze, crítica en `modality=technical` sobre hubs con stack ya provisionado (GCP, colas, motores de decisión, generación/envío de documentos, auth). Un análisis de calidad **no** equivale a un documento extenso: equivale a uno **proporcional al scope que el stakeholder pidió**. El output debe escalar con el requerimiento, no con la madurez del hub.
-
-- **No inventes decisiones ni riesgos**. Antes de listar una "decisión a tomar" o un "riesgo cross-repo", validá contra `OBJECTIVE.question` literal y el material adjunto. Si el stakeholder no lo planteó y no bloquea el dev, **omitilo**. Detalle operativo en `analyze-conclude` (modality=technical → "Moderación primero").
-- **Hub maduro ≠ greenfield**. Si la infraestructura ya existe en el repo, asumila disponible y describí cómo el dev **compone** sobre lo existente. No re-decidas piezas ya provistas como si arrancaran de cero.
-- **Agencia ≠ completitud**. Cuando el usuario delega ("según lo veas conveniente"), eso habilita pasar **directo** a una sesión dev si el scope es claro — no obliga a producir un análisis robusto. La opción más liviana que cubre el requerimiento gana.
-- **Máximo 1 sesión dev derivada** por default. Proponé varias solo si el stakeholder lo pidió explícitamente o hay una dependencia técnica dura que las separa (declarala).
-- **Artefactos canónicos únicos**: el flow=analyze produce `EVIDENCE.md` → `FINDINGS.md` → `CONCLUSIONS.md` (+ `queries/` si aplica). Los mapeos por-repo (despacho de subagentes en hub mode) son **evidencia** y viven como tal. No eleves un `CONSOLIDADO.md`/`MAPEO-*.md` inventado al rango de artefacto canónico ni dupliques en él lo que ya va en FINDINGS/CONCLUSIONS. La consolidación cross-repo vive en `FINDINGS.md` (Patterns) y cierra en una `CONCLUSIONS.md` acotada (≤1 página si el scope es simple).
-
-## Standalone (use) — DEPRECADO (session096)
-
-> `/agent-workflow:use` nunca se materializó como comando. Para investigación read-only con trazabilidad usá `/agent-workflow:session --flow analyze`. El micro-lifecycle `/agent-workflow:patch` es para tareas dev con cambio (no aplica a investigación). Esta sección queda como histórico read-only; no describe un comando activo.
-
-## Session integration
-
-Cuando agent-workflow:session consume este workflow durante `/agent-workflow:session create` con flow=analyze:
-
-### Args al crear sesión
-
-- modality: technical|data|incident (obligatorio; determina graduación + template). Legacy ES `tecnica|datos|incidente` se acepta y normaliza.
-
-### Artefactos por fase
-
-- planning: OBJECTIVE.md, TASKS.md
-- execution: EVIDENCE.md, FINDINGS.md, queries/, CONCLUSIONS.md
-- validation: review de CONCLUSIONS
-- closure: opt-in graduación de CONCLUSIONS.md a `docs/conclusiones/` (default: queda en sesión)
-
-### Skills por fase
-
-- planning: analyze-synthesize (estructurar plan)
-- execution: analyze-investigate (recolectar evidencia), analyze-synthesize (sintetizar findings)
-- closure: analyze-conclude (produce CONCLUSIONS.md modulado por modalidad)
-
-### Refs HISTORY
-
-- conclusion: docs/conclusiones/{val}.md (cuando se gradúa opt-in)
-
-### Conteos resume
-
-- evidence: EVIDENCE.md presente
-- findings: FINDINGS.md presente
-- conclusions: CONCLUSIONS.md presente
-- queries: queries/*.sql count
-
-## Sandbox read-only
-
-Standalone: en plan mode describir modalidad, scope, paths sugeridos. No ejecutar queries ni leer BD.
-
-Orchestrated: ver `agent-workflow:session` plan mode rules.

package/skills/agent-workflow/workflows/design-workflow/SKILL.md

@@ -1,79 +0,0 @@
----
-name: design-workflow
-description: Workflow especializado design (especialidad UX/UI spec-only), antes en qtc-design. Consumido por /agent-workflow:session cuando flow=design para orquestar el lifecycle universal con composición design-específica (Double Diamond → 4 fases v4.0).
-version: 2.2.0
-flow: design
-workflow_schema: 1.0
----
-
-# Design Workflow
-
-Workflow declarativo del flow=design. Define dos modos:
-
-- **Standalone** (`/agent-workflow:use`): produce specs UI puntuales sin sesión.
-- **Orchestrated** (consumido por `/agent-workflow:session` con flow=design): orquesta Double Diamond → 4 fases v4.0.
-
-## Brief
-
-**flow=design** es la especialidad UX/UI **spec-only** del plugin qtc. No edita código de framework; produce specs (`DELIVERY.md`) consumibles por flow=dev vía handoff.
-
-**Política de commits**: ver `agent-workflow:commits-policy` (canónico). Cualquier commit que el usuario solicite — closure auto-disparado o solicitud explícita — pasa por el flujo M1 propose-then-execute (Regla 3 universal).
-
-**Política sin fallback al CLI (transversal al flow=design)**: si `agent-workflow <subcmd>` falla (no está en PATH, comando no reconocido, exit code != 0), **cortá la acción y reportá al usuario**: pedile que verifique `npm install -g @tacuchi/agent-workflow-cli`. No hay flujo alternativo Python.
-
-Skills disponibles:
-- **design-brief**: captura contexto y restricciones del diseño.
-- **design-discover**: exploración visual + research.
-- **design-develop**: iteración de propuestas.
-- **design-deliver**: spec final DELIVERY.md (type: project | system).
-- **frontend-design**: patterns UX agnósticos (single-slot, máster-slave, validación inline) — exportada cross-flow.
-
-Diferencia clave de **type** (metadato interno del documento — la carpeta destino NO depende del type):
-- `project` (legacy: `proyecto`): pantalla/feature concreta. Spec DELIVERY.md describe la pantalla.
-- `system` (legacy: `sistema`): tokens, componentes, design system. Spec DELIVERY.md describe los CAMBIOS al DS (delta + migration).
-
-**Ambos types gradúan a `docs/especificaciones/NNN-<slug>/`** (kind=`especificacion`, modelo nuevo DEC-003). El `## Type` queda como metadato dentro del archivo, no afecta el routing.
-
-## Standalone (use) — DEPRECADO (session096)
-
-> `/agent-workflow:use` nunca se materializó como comando. Para diseño con trazabilidad usá `/agent-workflow:session --flow design`. El micro-lifecycle `/agent-workflow:patch` es para tareas dev con cambio (no aplica a diseño). Esta sección queda como histórico read-only; no describe un comando activo.
-
-## Session integration
-
-Cuando agent-workflow:session consume este workflow durante `/agent-workflow:session create` con flow=design:
-
-### Args al crear sesión
-
-- type: project|system (obligatorio; queda como metadato `## Type` interno del documento; **no** determina graduación — todo va a `docs/especificaciones/`). Legacy ES `proyecto|sistema` aceptado.
-
-### Artefactos por fase
-
-- planning: OBJECTIVE.md, BRIEF.md, TASKS.md
-- execution: DISCOVERY.md, PROBLEM.md, IDEAS.md, DELIVERY.md, opcional lectura de `<workspace-root>/docs/referencias/` (carpeta transversal, material del usuario)
-- validation: feedback en TASKS, marcado de criterios
-- closure: graduación a `docs/especificaciones/` (kind=`especificacion`)
-
-### Skills por fase
-
-- planning: design-brief, analyze-synthesize (cross-flow, sugerir)
-- execution: design-discover, design-develop, design-deliver, frontend-design
-- validation: design-deliver (review final)
-- closure: graduate `--kind especificacion` (a `docs/especificaciones/NNN-<slug>/`)
-
-### Refs HISTORY
-
-- especificacion: docs/especificaciones/{val}/
-
-### Conteos resume
-
-- discovery: DISCOVERY.md presente
-- problem: PROBLEM.md presente
-- ideas: IDEAS.md presente
-- delivery: DELIVERY.md presente
-- referencias: docs/referencias/ count (carpeta transversal manual del usuario, lazy — DEC-004 v2)
-
-## Sandbox read-only
-
-Standalone: en plan mode describir qué type se elegiría, qué artefactos se sugieren, qué paths. No escribir.
-
-Orchestrated: ver `agent-workflow:session` plan mode rules.

package/skills/agent-workflow/workflows/dev-workflow/SKILL.md

@@ -1,172 +0,0 @@
----
-name: dev-workflow
-description: "Workflow especializado dev (especialidad construcción de código), antes en qtc-dev. Consumido por /agent-workflow:session cuando flow=dev para orquestar el lifecycle universal con composición dev-específica. v2.7+ adopta modelo phased extendido (Phase 0-5 = Mapeo+Contrato → Lecturas → Escritura → Validaciones → Seguridad placeholder → Optimizaciones opt-in) y bugfix doctrina con superpowers:systematic-debugging."
-version: 2.2.1
-flow: dev
-workflow_schema: 1.0
----
-
-# Dev Workflow
-
-Workflow declarativo del flow=dev. Define cómo se comporta la especialidad en dos modos:
-
-- **Standalone** (`/agent-workflow:use`): activa la especialidad sin sesión, en cualquier workspace.
-- **Orchestrated** (consumido por `/agent-workflow:session` cuando flow=dev): describe args, artefactos, skills y graduación que agent-workflow:session orquesta.
-
-## Brief
-
-**flow=dev** es la especialidad de construcción de código del plugin qtc. Aplica:
-
-- **coding-standards**: fail-fast, logging por nivel apropiado, naming descriptivo, parametrización SQL, no exposición de secrets, reglas FE-BE (Sparse DTO + PATCH + sin fallbacks ocultos).
-- **implement**: loop de tareas con flat mode o phased mode v2.7+ (Phase 0 Mapeo+Contrato con routing → Phase 1 Lecturas → Phase 2 Escritura → Phase 3 Validaciones → Phase 4 Seguridad placeholder → Phase 5 Optimizaciones opt-in; gate M6 entre phases). v2.8+ retira M9; el design review se materializa via DESIGN.md + S7 disparado desde `skills/session/SKILL.md` durante planning closure, antes de Phase 0. Bugfix doctrina v2.7+ compone con `superpowers:systematic-debugging` + test de regresión.
-- **refactor**: análisis legacy + Strangler Fig (rename `<feature>-legacy/` + rebuild paralelo en Phase 0-5 + cleanup) cuando `## Type: refactor` (alias legacy `## Tipo`).
-- **sql-script-organizer**: categoriza scripts SQL (DDL / migración / inserts) y aplica estilo del proyecto.
-- **sql-rollback-generator**: pares forward/rollback para migraciones reversibles.
-- **testing-strategy**: define alcance y tipo de tests según el cambio.
-- **frontend-design**: patterns UX agnósticos (single-slot, máster-slave, validación inline).
-- **release / release-scripts**: consolidación de cambios + bundle SQL para release (excepciones session-aware — ver §"Excepciones session-aware").
-
-**Política BD (transversal al flow=dev)**: las mutaciones a BD se materializan exclusivamente como scripts SQL versionados bajo `docs/scripts/` del workspace de la fuente. **flow=dev nunca ejecuta DML/DDL** contra `<mcp-cert>`/`<mcp-prod>` ni ningún otro destino — el usuario es quien aplica los scripts manualmente y confirma. Aplica a todas las skills del flow (`implement`, `sql-script-organizer`, `sql-rollback-generator`, `release`, `release-scripts`).
-
-**Política de commits**: ver `agent-workflow:commits-policy` (canónico). Cualquier commit que el usuario solicite — durante execution, en closure auto, o sin sesión activa — pasa por el flujo M1 propose-then-execute con `AskUserQuestion` (Regla 3 universal). Bypass por mensaje literal vía Regla 5.
-
-**Política sin fallback al CLI (transversal al flow=dev)**: si `agent-workflow <subcmd>` falla (no está en PATH, comando no reconocido, exit code != 0), **cortá la acción y reportá al usuario**: pedile que verifique `npm install -g @tacuchi/agent-workflow-cli`. No hay flujo alternativo Python.
-
-## Standalone (use) — DEPRECADO (session096)
-
-> `/agent-workflow:use` nunca se materializó como comando (no está en los commands canónicos ni en el marketplace). Para una tarea dev pequeña con trazabilidad mínima usá **`/agent-workflow:patch`** (micro-lifecycle, modo `--lite` de flow=dev — ver `session/SKILL.md` §"Modo lite (/patch)"). Para trabajo largo, `/agent-workflow:session`. Esta sección queda como histórico read-only; no describe un comando activo.
-
-## Excepciones session-aware (v2.1+)
-
-En flow=dev v2.0+ la regla general es "comandos standalone vía /agent-workflow:use". Las **únicas excepciones** son:
-
-- `/agent-workflow:release` — consolida N sesiones cerradas en un paquete de paso a producción (informe + bundle SQL + escaneo + acciones manuales). Renombrado desde `release-report` en v2.1.0.
-- `/agent-workflow:release-scripts` — vista alternativa por tema del bundle SQL del release.
-
-Estos NO crean ni modifican sesiones (siguen siendo read-only del lifecycle), pero **dependen de su existencia**. Si el workspace no tiene sesiones, abortan con mensaje sugiriendo `/agent-workflow:session create` primero.
-
-Ambos consumen el CLI `agent-workflow` (no leen paths hardcodeados):
-- `agent-workflow release-data [--since sessionNNN] [--source alias] [--include-graduated]`
-- `agent-workflow session-artifacts --code <NNN>` — lee OBJECTIVE/TASKS/DECISIONS de una sesión (con fallback bilingual a OBJETIVO/TASKS/DECISIONES legacy).
-- Resolución hub-aware de `docs/<source>/` y `release/<source>/` la maneja el CLI internamente.
-
-**Formato requerido**: solo sesiones v0.9+ (OBJECTIVE.md / OBJETIVO.md legacy ES). Sesiones legacy con REQUIREMENTS.md deben migrarse con `/agent-workflow:migrate --upgrade-topology` antes de usar release.
-
-## Session integration
-
-Cuando agent-workflow:session consume este workflow durante `/agent-workflow:session create` con flow=dev:
-
-### Args al crear sesión
-
-(ninguno extra para dev — solo los comunes: `--name`, `--objetivo`, `--branches`, `--from`)
-
-### Convención `## Type` en OBJECTIVE.md — alias legacy `## Tipo` (v2.8+)
-
-Toda sesión `flow=dev` declara `## Type` justo después del título (o después de `## Origin` si existe). Determina si la sesión sigue el flujo **phased** y si activa el skill `refactor`. Los **valores** son slugs `feature|refactor|bugfix|chore` (EN, no requieren traducción).
-
-**Rename v2.8+**: el header canónico es `## Type` (EN, alineado con i18n scope memory `feedback_i18n_scope_runtime_only` y harmonizado con `flow=design` que ya usa `## Type` para S1). `## Tipo` queda como alias legacy ES read-only — el parser bilingüe `parseTypeFromObjetivo()` en `agent-workflow-cli` acepta ambas formas y normaliza a EN. Sesiones cerradas con `## Tipo` legacy siguen siendo legibles sin migración forzada.
-
-| Type | Phased? | Skill `refactor` activo? | Artefactos extra | Ejemplo de Brief |
-|---|---|---|---|---|
-| `feature` | sí (default-on) | no | DESIGN.md + S7 gate | "agregar mantenimiento de categorías con CRUD" |
-| `refactor` | sí (default-on) | sí | DESIGN.md + S7 gate; REFACTOR.md (vive en sesión; **no se gradúa con kind dedicado** — DEC-003) | "rebuild de mantenimiento de categorías al estándar nuevo" |
-| `bugfix` | no | no | — (no DESIGN.md, no S7) | "fix de validación en formulario de usuarios" |
-| `chore` | no | no | — (no DESIGN.md, no S7) | "bump de dependencias, limpieza de imports" |
-
-### Resolución del `## Type` — defensa en profundidad (v2.8+)
-
-Tres capas garantizan que `## Type` nunca esté ausente:
-
-**Capa 1 — CLI template (Mit-A)**: `agent-workflow session-create --flow dev` inyecta `## Type: <valor>` en el OBJECTIVE.md template materializado. Posición canónica: línea 3 si no hay `## Origin`, después de `## Origin` si existe.
-
-**Capa 2 — Heurística (Mit-C)**: el CLI analiza `--objetivo` con tabla de keywords y elige tipo + confianza. Flag `--type <valor>` opcional para override explícito.
-
-- Brief contiene `refactor`/`rebuild`/`migrar`/`mover a nuevo`/`reescribir`/`legacy` → `refactor` (alta confianza).
-- Brief contiene `agregar`/`nueva pantalla`/`crear endpoint`/`nuevo módulo`/`feature de` → `feature` (alta confianza).
-- Brief contiene `fix`/`arreglar`/`corregir`/`error en` con scope ≤1 archivo → `bugfix` (media confianza).
-- Brief contiene `bump`/`actualizar dependencia`/`limpiar imports`/`formato`/`tipos` → `chore` (alta confianza).
-- Sin match claro → `feature` (fallback). Emitir log: `[session-create] Type inferido como 'feature' por baja confianza heurística (brief no matchea keywords). Pasá --type <valor> para override.`
-
-**Capa 3 — Default-on en lectura**: `implement` y otras skills que lean OBJECTIVE.md aplican fallback `feature` con log informativo si `## Type` está ausente (sesiones legacy, migradas, o con borrado manual). Detalles en `skills/implement/SKILL.md` §"Resolución del `## Type`".
-
-**Promoción mid-session**: el usuario puede editar `## Type` en OBJECTIVE.md (o `## Tipo` legacy) sin re-crear la sesión. `implement` re-lee al iniciar cada loop. Si `Type` cambia de `bugfix` → `feature`, el siguiente cambio dispara comportamiento phased; tareas previas no se reescriben.
-
-**Refs HISTORY**: el flow=dev añade tag `type:<feature|refactor|bugfix|chore>` cuando aplica para que `release` y `release-scripts` puedan filtrar. Alias legacy `tipo:` también legible.
-
-### Flujo phased en execution (v2.7+)
-
-Cuando `Tipo: feature|refactor`, TASKS.md se organiza en hasta 6 secciones canónicas:
-
-```markdown
-## Phase 0 — Mapeo + Contrato
-- [ ] interfaces/DTOs/endpoints stub que devuelven mocks
-- [ ] routing FE conectado a BE (FE consume mock; navegación e2e funciona)…
-
-## Phase 1 — Lecturas
-- [ ] consultas, combos, filtros, listados con datos reales…
-
-## Phase 2 — Escritura
-- [ ] create/update/delete funcionales (sin Bean Validation aún)…
-
-## Phase 3 — Validaciones / Correcciones
-- [ ] Bean Validation con groups, handler global 400 estructurado, reglas de negocio, cleanup smells…
-
-## Phase 4 — Seguridad   <!-- placeholder; pendiente-spec; skip silencioso si vacía -->
-
-## Phase 5 — Optimizaciones   <!-- opt-in; skip silencioso si no se declara -->
-- [ ] EXPLAIN sobre queries, índices, async, caching…
-```
-
-`implement` lee las secciones y dispara M6 (phase-gate) entre cada par phase → phase. Phase 4 placeholder y Phase 5 opt-in se saltan silenciosamente si están vacías o no declaradas. Si TASKS.md no tiene `## Phase X — Y`, `implement` cae a flat mode (compat hacia atrás 100%). **DESIGN.md + S7 design-review** se producen y disparan ANTES de Phase 0 desde `skills/session/SKILL.md` durante planning closure (v2.8+ — reemplazo de M9 retirado).
-
-#### Routing dentro de Phase 0
-
-El cableado FE↔BE↔DB de Phase 0 incluye **navegación e2e con datos hardcoded**: si la feature involucra un login, en Phase 0 click "Ingresar" debe llevar al home; si home muestra una tabla, esa tabla ya consume el endpoint BE responding mock. El cableado y routing ya fueron declarados en `DESIGN.md` §"Wiring" + §"Target state" y revisados via S7 antes de Phase 0 (v2.8+) — Phase 0 implementa el spec, no lo re-define.
-
-Sin separar Phase 0a (mocks) y Phase 0b (routing): mocks sin routing son inútiles porque no se prueban e2e; routing sin mocks no funciona. Van juntos en Phase 0 como sub-checklist.
-
-**Reglas FE-BE aplicadas** en Phase 0 (Sparse DTO unificado + PATCH + sin fallbacks ocultos + DB stub-first): ver canónico `coding-standards/references/fe-be-integration.md` (R1-R6).
-
-### Bugfix doctrina (flat mode v2.7+)
-
-Cuando `## Type: bugfix` (alias legacy `## Tipo`), TASKS.md sigue flat (sin `## Phase X — Y`). Doctrina nueva en 3 pasos canónicos:
-
-1. **Reproducir + diagnosticar**: el AI compone `superpowers:systematic-debugging` (root-cause analysis sistemático). Output: 1 DEC mínima en DECISIONS.md con causa raíz o hipótesis a validar.
-2. **Aplicar fix mínimo**: loop flat normal, 1-3 tareas como mucho, sin gates.
-3. **Verificación específica**: `testing-strategy` exige test de regresión que reproduce el bug original (rompe antes / pasa después).
-
-**Skip permitido del paso 1** si el bug es trivialmente obvio (1 line con justificación inline en DECISIONS, ej. "typo en regex que rompía parsing — sin causa raíz adicional").
-
-**Fallback si `superpowers:systematic-debugging` no está instalado**: aplicar guideline textual de root-cause: "¿qué pasó? ¿qué cambió? ¿cuál es el error exacto? ¿se reproduce?" antes de fix. Sin nuevo `## Type: hotfix`; la urgencia se expresa en el OBJECTIVE.
-
-### Artefactos por fase
-
-- planning: OBJECTIVE.md, TASKS.md
-- execution: DECISIONS.md, scripts/, DEPENDENCIES.md
-- validation: tests, logs en TASKS marcados
-- closure: docs/decisiones/ (kind=`decision`); SQL bundles vía `/agent-workflow:release` en `docs/scripts/` (kind=`script`)
-
-### Skills por fase
-
-- planning: analyze-synthesize (cross-flow, sugerir al usuario)
-- execution: implement, coding-standards, sql-script-organizer, sql-rollback-generator
-- validation: testing-strategy, coding-standards
-- closure: graduate `--kind decision` (DEC-NNN graduadas a `docs/decisiones/`); para SQL ver `/agent-workflow:release`
-
-### Refs HISTORY
-
-- dec: docs/decisiones/{val}.md
-- sql: docs/scripts/{val}/ (vía `/agent-workflow:release`)
-
-### Conteos resume
-
-- tasks: TASKS.md (counts pendientes/en_progreso/completadas)
-- decisions: DECISIONS.md (count DEC-NNN headers)
-- dependencies: DEPENDENCIES.md (rows post-header)
-- scripts: scripts/*.sql + scripts/bundle/ check
-
-## Sandbox read-only
-
-Standalone: en plan mode, solo describir qué skills se cargarían, qué stack se detectaría, qué paths se sugerirían. No tocar archivos.
-
-Orchestrated: ver `agent-workflow:session` plan mode rules.