@tacuchi/agent-workflow-cli 12.9.0 → 13.0.0

package/skills/w/roles/tools/SKILL.md

@@ -21,7 +21,7 @@ Dar al `plan-exec-loop` la capacidad de crear herramientas y utilidades auxiliar
 
 | Tipo | Rol | ¿Quién lo maneja? |
 |---|---|---|
-| Código de producto (services, controllers, components) | cambio en el repo fuente | `plan-exec-loop` + `coding-standards` |
+| Código de producto (services, controllers, components) | cambio en el repo fuente | `plan-exec-loop` (estilo: convenciones ambientes del host) |
 | Tool / utilidad auxiliar creada por el plan | herramienta de soporte | esta skill (`tools`) |
 | Script SQL de migración | dato persistente | `sql` + `export-scripts` |
 
@@ -120,7 +120,7 @@ Si la tool genera o manipula SQL:
 
 ### Code quality baseline
 
-Al autorar el código de la tool, aplicar lo que la capacidad `coding-standards` del workspace establezca. Si `coding-standards` está `off` o no está configurada, usar los estándares del lenguaje detectado:
+Al autorar el código de la tool, seguir las convenciones de código **ambientes** del host (auto-descubiertas por su `description`; no es un rol del workflow ni se bindea). Si no hay una skill de estándares aplicable, usar los estándares del lenguaje detectado:
 - **Shell**: shellcheck-compatible, variables entre comillas, `set -euo pipefail`.
 - **Node/TS**: tipado explícito, sin `any` salvo justificación, error handling explícito.
 - **Python**: type hints, docstring en funciones públicas, manejo de excepciones específico.

package/skills/w/roles/coding-standards/SKILL.md

@@ -1,82 +0,0 @@
----
-name: coding-standards
-description: >-
-  Coding standards capability — built-in default for the `coding-standards` role.
-  Stack-agnostic principles (SOLID, fail-fast, descriptive names, small methods,
-  reuse over duplication) plus per-stack conventions (Java/Spring, Angular/TypeScript,
-  Node), security (no secrets in code or logs, parametrized SQL, DB read-only via MCP),
-  HTTP error handling (never silence errors), logging levels, and FE-BE integration
-  rules (unified sparse DTO, PATCH for edit, no hidden fallbacks). Use when a loop
-  implements, reviews or refactors code.
----
-
-# coding-standards — Coding standards capability
-
-## Role
-
-`coding-standards` — built-in default. Rebindable in `.workflow/skills.toml` (third-party skill or `off`).
-
-## Purpose
-
-Aportar los estándares de código que la IA aplica al **implementar, revisar o refactorizar**. Read-only por diseño: carga reglas, no edita ni ejecuta nada por sí misma — el loop consumidor materializa el código.
-
-## Composed by
-
-- **`plan-exec-loop`** — al implementar/refactorizar las tasks del plan.
-- **`quick-loop`** — al implementar el atajo liviano.
-
-## Knowledge
-
-### Principios generales
-
-- **SOLID** — Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Inversion.
-- **Fail fast** — validar y retornar al inicio del método (early returns, evitar nesting).
-- **Nombres descriptivos** — el código habla por sí mismo; comentarios solo para el "por qué".
-- **Métodos pequeños** — una sola responsabilidad por función.
-- **Composición sobre herencia**.
-- **Reutilización antes que duplicación (DRY)** — antes de crear componente/función/clase, revisar si ya existe en `shared/` (frontend) o `common/`/`util/` (backend). Si un patrón aparece 2-3 veces, proponer extracción.
-
-### Estándares por stack
-
-- **Java / Spring Boot**: Constructor Injection (sin Field Injection), `@Transactional(readOnly=true)` para lecturas, Java records para DTOs Request/Response, Jakarta Validation para inputs.
-- **Angular / TypeScript**: constructor injection, `async` pipe en templates, evitar `any`, FormBuilder reactivo sobre `ngModel` directo, arquitectura `@data`/`@presentation`, normalización de tipos.
-- **Node / otros**: mismos principios generales; aplicar las convenciones idiomáticas del proyecto detectado.
-
-### Integración FE-BE (cuando el cambio cruza frontend y backend)
-
-- **R1 — Sparse DTO unificado**: mismo DTO `<Feature>SaveRequest` para create + edit, todos los campos nullable. `null` = "no tocar".
-- **R2 — PATCH para edit**: `@PatchMapping` en BE, `http.patch()` en FE. POST solo para create. PUT solo si replace total justificado.
-- **R3 — FE envía solo cambios**: payload diff entre `formValue` y entidad original.
-- **R4 — Sin fallbacks que oculten errores**: prohibido `catchError(() => of([]))` en FE; prohibido try/catch con fallback al método legacy en BE durante migraciones. Usar feature flags explícitas para rollout gradual.
-- **R5 — Validación BE con Bean Validation + groups**: `@NotNull(groups = OnCreate.class)` para distinguir reglas POST vs PATCH cuando comparten DTO.
-- **R6 — DB stub-first**: funciones/SP nuevas arrancan devolviendo mock (`RETURN '[]'::jsonb`); implementación real en una fase posterior.
-
-### Seguridad
-
-- **Nunca** exponer secrets, API keys ni credenciales en código.
-- **Nunca** logear datos sensibles (contraseñas, tokens, datos personales).
-- **Siempre** parametrizar queries SQL (nunca concatenar strings).
-- **BD vía MCP es READONLY**. Modificaciones a BD solo como scripts SQL versionados (ver rol `sql`); las aplica el **usuario**, nunca la IA — ni por MCP, ni `Bash`, ni `psql`, ni driver. (Invariante 4.)
-
-### Manejo de errores HTTP
-
-- **Nunca** silenciar errores HTTP con `catchError(() => of([]))` ni equivalentes. Los errores del backend se propagan al usuario (toast/mensaje) para detectar regresiones en guardado/sincronización/creación. Para reintentos usar operadores explícitos (`retry`, `retryWhen`), no silenciar.
-
-### Logging
-
-- `ERROR` — fallos que requieren atención inmediata.
-- `WARN` — situaciones inesperadas pero manejadas.
-- `INFO` — eventos de negocio relevantes (inicio/fin de procesos).
-- `DEBUG` — detalle técnico para diagnóstico.
-
-### Convenciones de BD (nomenclatura)
-
-Esquemas `esq_`, tablas `tb_`, sequences `seq_`, funciones `fn_`/procedimientos `sp_`, patrón maestra-detalle, auditoría en `esq_audit`. Para autoría de scripts SQL (estilo, header, categorías, rollback) usar el rol **`sql`**.
-
-## Output
-
-Ninguno propio. La skill aporta reglas; el código lo escribe el loop. Cuando el cambio toca BD, delega la autoría de scripts al rol `sql`. Nunca exporta a `docs/` (invariante 1).
-
-## Source
-
-Reciclada de `standards/coding-standards/` (SKILL.md + references Java/Spring, Angular/TypeScript, fe-be-integration, database-conventions, frontend-structure, project-structure). Los principios UX de mantenimientos CRUD (formularios, listados, modales) viven en el rol `ui-spec`/`ui-design`; la autoría de scripts SQL en el rol `sql`. Se descarta la dependencia de `profile.json` y de comandos CLI de la doctrina vieja.

package/skills/w/roles/testing/SKILL.md

@@ -1,180 +0,0 @@
----
-name: testing
-description: >
-  Estrategia y ejecución de pruebas: selecciona niveles (unit / integration / e2e),
-  resuelve comandos por stack detectado, guía la convención de nombres y estructura de tests.
-  Pregunta al humano antes de ejecutar; nunca lanza el test runner sin confirmación explícita.
-  Compuesta por plan-exec-loop y quick-loop durante la fase de validación de cambios.
----
-
-# testing — Test strategy and execution capability
-
-## Role
-
-`testing` — implementación built-in por defecto. Rebindeable a otra skill (de tercero o `off`) en `.workflow/skills.toml`.
-
-## Purpose
-
-Dar a los loops la capacidad de razonar sobre tests: qué nivel aplicar, con qué comando, con qué convención. **No ejecuta tests de forma autónoma** — primero pregunta al humano si quiere que el loop los corra, o si los correrá manualmente, o si no hacen falta en esta sesión.
-
-## Composed by
-
-| Loop | Cuándo la compone |
-|---|---|
-| `plan-exec-loop` | durante validation de cada task ejecutada |
-| `quick-loop` | cuando el cambio quick requiere verificación |
-
-## Knowledge
-
-### Execution rule
-
-Por defecto, **no ejecutar pruebas automáticamente**. Antes de correr cualquier test runner, preguntar al humano vía *structured-choice* (capacidad del arnés — ver `../../harness/SKILL.md`). En **Claude Code** es `AskUserQuestion` (máx 4 preguntas/llamada → **≤3 preguntas de contenido + 1 control `flow`**); en un arnés sin elección estructurada, degrada a **markdown numerado**.
-
-```
-structured-choice:
-  "¿Correr los tests?"
-  [a] Sí, el loop los ejecuta
-  [b] Los corro yo manualmente
-  [c] No hace falta en esta sesión
-```
-
-Solo saltear la pregunta si el workspace declara `Validation mode: auto` en `.workflow/config.toml`.
-
-### Test levels
-
-Tres niveles universales (adaptados al stack detectado):
-
-| Nivel | Alcance | Cuándo usarlo |
-|---|---|---|
-| **a) Unit** | Lógica aislada (servicios, utils, mappers) | Fix puntual, lógica sin dependencias externas |
-| **b) Integration** | Unit + capa de API/controladores | Endpoint nuevo o modificado |
-| **c) Full** | Integration + contexto completo + e2e | Feature completa, flujo crítico, integración entre capas |
-
-### Stack resolution
-
-El stack se detecta por archivos de manifest presentes en el workspace. Precedencia: si el bloque `WORKSPACE → Stack` declara override de build/wrapper, usarlo.
-
-#### Spring Boot (Maven)
-
-| Nivel | Framework | Comando |
-|---|---|---|
-| a) Unit | JUnit 5 + Mockito | `./mvnw test -Dtest=ClaseTest` |
-| b) Integration | + MockMvc | `./mvnw test` |
-| c) Full | + @SpringBootTest | `./mvnw verify` |
-
-> Windows: `mvnw.cmd` en lugar de `./mvnw`.
-
-#### Spring Boot (Gradle)
-
-| Nivel | Comando |
-|---|---|
-| a) Unit | `./gradlew test --tests ClaseTest` |
-| b) Integration | `./gradlew test` |
-| c) Full | `./gradlew integrationTest` (o `check`) |
-
-#### Angular
-
-| Nivel | Framework | Comando |
-|---|---|---|
-| a) Unit | Jasmine + Karma (o Jest) | `ng test --watch=false` |
-| b) Integration | + TestBed + ComponentFixture | `ng test --watch=false` |
-| c) Full | + Cypress/Playwright si configurado | `npm run e2e` |
-
-#### Node / TypeScript genérico
-
-| Nivel | Comando |
-|---|---|
-| a) Unit | `npm test` (script `test` en `package.json`) |
-| b) Integration | `npm test` con suites de integración |
-| c) Full | `npm run test:e2e` o según config |
-
-#### Resolución automática
-
-1. `mvnw` / `mvnw.cmd` → Maven wrapper.
-2. `gradlew` → Gradle wrapper.
-3. `angular.json` → `ng test`.
-4. `package.json` con script `test` → `npm test`.
-5. Si hay override en `WORKSPACE → Stack` → usarlo.
-
-### Naming conventions
-
-**Java:** clase `[Objetivo]Test.java`, método `[metodo]_[escenario]_[resultado]`. Estructura Arrange-Act-Assert.
-
-```java
-@Test
-void enviar_conEmailValido_retornaExito() {
-    // Arrange
-    var request = new NotificacionRequest("user@example.com", "Asunto", "template", Map.of());
-    when(emailProvider.send(any())).thenReturn(true);
-    // Act
-    var resultado = service.enviar(request);
-    // Assert
-    assertThat(resultado).isTrue();
-}
-```
-
-**Angular / TypeScript:** archivo `[nombre].spec.ts`, bloques `describe` / `it`. Usar `TestBed` para componentes.
-
-```typescript
-describe('AuthService', () => {
-  it('should return token on login', () => {
-    // ...
-  });
-});
-```
-
-### Level selection prompt (to show the human)
-
-Adaptar al stack resuelto. Ejemplo para Spring Boot:
-
-```
-¿Qué nivel de pruebas aplicamos?
-  a) Unitarios       — JUnit 5 + Mockito (rápido, aislado)
-  b) Integración     — + MockMvc controllers
-  c) Completo        — + @SpringBootTest (contexto Spring completo)
-```
-
-El humano puede cambiar de nivel en cualquier momento o decidir no ejecutar desde el loop.
-
-### Execution and logging
-
-1. Confirmar que el humano quiere ejecución desde el loop (ver "Execution rule").
-2. Ejecutar el comando resuelto según stack y nivel.
-3. Registrar resultado en `TEST_LOG.md` **solo si** el humano pidió registro formal o la ejecución fue desde el loop.
-4. Si el humano ya validó manualmente, no repetir; anotar una línea breve si aporta trazabilidad.
-5. Si hay fallos y el humano quiere continuar: corregir y re-ejecutar.
-
-### TestBuilder pattern (Java)
-
-Para construir fixtures reutilizables sin acoplar los tests al constructor de producción:
-
-```java
-public class NotificacionTestBuilder {
-    private String destinatario = "test@example.com";
-    private String estado = "PENDIENTE";
-
-    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 e = new Notificacion();
-        e.setDestinatario(destinatario);
-        e.setEstado(estado);
-        return e;
-    }
-}
-```
-
-## Output
-
-No produce artefactos de forma autónoma. Cuando el humano confirma ejecución:
-- Corre el comando resuelto y reporta el resultado inline.
-- Escribe `TEST_LOG.md` en la sesión activa solo si fue pedido explícitamente.
-
-No gradua a `docs/` (invariant #1).
-
-## Source
-
-Reciclado de `agent-workflow/standards/testing-strategy/` del bundle viejo (v0.1.0). Se conserva: los tres niveles (a/b/c), la regla de confirmación antes de ejecutar, la resolución de stack por manifest, los naming conventions, la tabla de comandos por framework. Se descarta: la referencia al bloque `AW-PROJECT → Stack` (reemplazado por `WORKSPACE → Stack`), el `TEST_LOG.md` obligatorio, el sandbox-readonly-rules legacy, referencias a `plan mode` del sistema anterior.

package/skills/w/roles/writing/SKILL.md

@@ -1,90 +0,0 @@
----
-name: writing
-description: >-
-  Clear technical writing capability — built-in default for the `writing` role. Rules
-  for any prose the AI produces in agent-workflow context: spec/plan/session artifacts,
-  commit messages, PR descriptions, export deliverables (manuals/reports). Short
-  sentences, lists over prose, one idea per line, "what + why" on one line, no jargon,
-  no filler. Use across all loops and in export-manuals / export-reports.
----
-
-# writing — Clear technical writing
-
-## Role
-
-`writing` — built-in default. Rebindable in `.workflow/skills.toml` (third-party skill or `off`). The most broadly composed role.
-
-## Purpose
-
-Reglas de estilo y formato para **toda la prosa** que la IA produce en contexto agent-workflow. Read-only por diseño: carga reglas; el `.md` lo materializa el consumidor (loop o export).
-
-## Composed by
-
-- **Todos los loops** — al escribir specs, planes, artefactos de sesión, mensajes de commit, descripciones de PR.
-- **`export-manuals`** — al redactar manuales técnicos (`docs/manuals`).
-- **`export-reports`** — al redactar informes ejecutivos (`docs/reports`).
-
-(También aplica a respuestas en chat sobre temas agent-workflow.)
-
-## Knowledge
-
-### Las 6 reglas
-
-1. **Frases cortas**: máximo ~15 palabras. Si pasa de 20, partir en dos.
-2. **Listas sobre prosa**: 3+ ideas paralelas van en bullets. Prosa solo para narrar.
-3. **Una idea por línea**: si el bullet usa "y" o ";" para meter una segunda idea, separar.
-4. **"Qué + por qué" en una línea**: formato `<qué>: <por qué corto>`. Sin párrafo aparte para el "por qué".
-5. **Sin jerga ni abreviaturas raras**: palabras comunes. Términos técnicos (MCP, C4) OK; abreviaturas inventadas (ej. "TLDR del CTX") no.
-6. **Sin relleno**: borrar "es importante notar que…", "cabe destacar…", "como se mencionó…", "en conclusión…". La idea va directo.
-
-### Palabras a evitar / preferir
-
-| Evitar | Preferir |
-|---|---|
-| "es importante notar que" / "cabe destacar" | (borrar, empezar con la idea) |
-| "en otras palabras" / "asimismo" | (borrar) / "también" |
-| "se procede a" / "llevar a cabo" | verbo directo / "hacer" |
-| "implementar la funcionalidad de X" | "implementar X" |
-| "realizar la validación de" | "validar" |
-| "a los efectos de" / "en el marco de" | "para" / "en" |
-| "no obstante" / "previamente mencionado" | "pero" / "antes" |
-| "TLDR", "FYI", "WIP" | escribir la palabra completa |
-
-### Ejemplo antes / después
-
-Antes:
-> Es importante notar que cada llamada implica un round-trip al servidor MCP además del consumo de tokens correspondiente al JSON de respuesta.
-
-Después (-50%):
-> Cada llamada MCP cuesta un round-trip y los tokens del JSON.
-
-Decisión densa, antes:
-> Se decidió, luego de analizar las alternativas, implementar la validación de roles solo en el frontend, dado que el backend no requiere la lógica y evita duplicar la regla.
-
-Después:
-> **Decisión**: validar permisos solo en el frontend.
-> **Por qué**: el backend no necesita la lógica; evita duplicar la regla.
-
-### Cuándo SÍ se permite prosa larga
-
-- Resúmenes ejecutivos donde la decisión necesita 4-6 oraciones para sostenerse.
-- Cadena causal de un incidente (causa raíz puede requerir un párrafo).
-- Tradeoffs de UX que necesitan explicación.
-
-Aún ahí: oraciones simples encadenadas, no oraciones largas.
-
-### Aplicación a los documentos del modelo nuevo
-
-- **spec** (`docs/specs`): brief y criterios de aceptación claros; la sección `## UI spec` la formatea el rol `ui-design`.
-- **plan** (`docs/plans`): resumen + fases + tasks con dependencias; tasks sin código inline (el código va en evidencia y se referencia).
-- **decisiones**: `**Decisión**:` + `**Por qué**:`, 3-6 líneas; si es obvia, no se registra.
-- **commit messages / PR**: mismas reglas (frases cortas, sin jerga, sin relleno). Formato canónico del mensaje en el rol `git`.
-- **export manuals/reports**: audiencia operadores/gerencia; bullets sobre prosa, sin relleno corporativo.
-
-## Output
-
-Ninguno propio. La skill aporta reglas; el `.md` lo escribe el consumidor (loop o export). Cuando escribe a `docs/`, lo hace solo el export que la compone (invariante 1) y solo en su carpeta (invariante 2).
-
-## Source
-
-Reciclada de `standards/redaccion-simple/` (las 6 reglas, tabla evitar/preferir, ejemplos, cuándo permitir prosa larga). Se descarta el catálogo de estructuras por artefacto del modelo viejo (OBJETIVO/DECISIONES/etc.); los documentos del modelo nuevo son spec/plan + artefactos de sesión, y su estructura la definen los loops y exports.