siesa-agents 2.1.96 → 2.1.98

package/bin/install.js

@@ -412,6 +412,40 @@ class SiesaBmadInstaller {
     return modifiedFiles;
   }
 
+  // Returns true if `relativePath` (relative to source root) is inside a
+  // `skills/` directory AND the skill name does NOT start with 'sa-'.
+  // The package only ships siesa-agents skills (sa-*); if a non-sa-* entry
+  // ever appears in the tarball it would shadow the engineer's own skill with
+  // the same name. This guard prevents that, and makes the intent explicit.
+  isForeignSkillPath(relativePath) {
+    const parts = relativePath.replace(/\\/g, '/').split('/');
+    const skillsIdx = parts.indexOf('skills');
+    if (skillsIdx >= 0 && parts.length > skillsIdx + 1) {
+      const skillName = parts[skillsIdx + 1];
+      return Boolean(skillName) && !skillName.startsWith('sa-');
+    }
+    return false;
+  }
+
+  // Single filter factory used in every fs.copy call.
+  // Rules (in order):
+  //   1. Never overwrite user-owned ignored files when they already exist.
+  //   2. Never copy non-sa-* skill directories from the source package —
+  //      the engineer's custom skills must survive every re-install/update.
+  makeCopyFilter(sourcePath, targetPath) {
+    return (src) => {
+      const relativePath = path.relative(sourcePath, src);
+      if (this.ignoredFiles.includes(relativePath)) {
+        const targetFile = path.join(targetPath, relativePath);
+        return !fs.existsSync(targetFile);
+      }
+      if (this.isForeignSkillPath(relativePath)) {
+        return false;
+      }
+      return true;
+    };
+  }
+
   async getAllFiles(dir) {
     const files = [];
     const stat = await fs.stat(dir);
@@ -581,15 +615,7 @@ class SiesaBmadInstaller {
       await fs.copy(sourcePath, targetPath, {
         overwrite: true,
         recursive: true,
-        filter: (src) => {
-          const relativePath = path.relative(sourcePath, src);
-          // No sobrescribir archivos ignorados si ya existen
-          if (this.ignoredFiles.includes(relativePath)) {
-            const targetFile = path.join(targetPath, relativePath);
-            return !fs.existsSync(targetFile);
-          }
-          return true;
-        }
+        filter: this.makeCopyFilter(sourcePath, targetPath)
       });
     }
 
@@ -670,15 +696,7 @@ class SiesaBmadInstaller {
         await fs.copy(sourcePath, targetPath, {
           overwrite: true,
           recursive: true,
-          filter: (src) => {
-            const relativePath = path.relative(sourcePath, src);
-            // No sobrescribir archivos ignorados si ya existen
-            if (this.ignoredFiles.includes(relativePath)) {
-              const targetFile = path.join(targetPath, relativePath);
-              return !fs.existsSync(targetFile);
-            }
-            return true;
-          }
+          filter: this.makeCopyFilter(sourcePath, targetPath)
         });
       } else {
         console.warn(`⚠️  Carpeta ${mapping.source} no encontrada en el paquete`);
@@ -787,15 +805,7 @@ class SiesaBmadInstaller {
           await fs.copy(sourcePath, stagingPath, {
             overwrite: true,
             recursive: true,
-            filter: (src) => {
-              const relativePath = path.relative(sourcePath, src);
-              // No sobrescribir archivos ignorados si ya existen en el target real.
-              if (this.ignoredFiles.includes(relativePath)) {
-                const realTargetFile = path.join(targetPath, relativePath);
-                return !fs.existsSync(realTargetFile);
-              }
-              return true;
-            }
+            filter: this.makeCopyFilter(sourcePath, targetPath)
           });
         }
         // Ocultar el staging mientras existe (cosmético, solo Windows).

package/claude/commands/sa-quick-dev.md

@@ -1,5 +1,5 @@
 ---
-description: 'Pipeline secuencial de sub-agentes por épica: crea, desarrolla y revisa TODAS las historias de una o varias épicas usando sub-agentes aislados con integración TEA completa (ATDD + Automate + Review + Test Design + Trace). Acepta una épica individual (ej: 3) o un rango (ej: 1-4).'
+description: 'Pipeline secuencial de sub-agentes por épica: crea, desarrolla y revisa TODAS las historias de una o varias épicas usando sub-agentes aislados. Acepta una épica individual (ej: 3) o un rango (ej: 1-4).'
 ---
 
 ## PASO 0 — Identificar las épicas a procesar
@@ -63,69 +63,6 @@ Con la fuente de la épica resuelta y el `sprint-status.yaml`:
 
 Informa al usuario cuántas historias se van a procesar y cuáles son, con su status actual.
 
-### 0.5 — Integración TEA
-
-El pipeline siempre ejecuta el módulo TEA completo (ATDD + Automate + Review + Test Design + Trace). No hay modos opcionales.
-
----
-
-> Los pasos 0.6 y 0.7 siempre se ejecutan.
-
-### 0.6 — Verificar Test Framework
-
-Verifica si existe `playwright.config.ts`, `playwright.config.js`, `cypress.config.ts` o `cypress.config.js` en el proyecto.
-
-- **Si existe**: el framework ya está configurado. Continúa al paso 0.7.
-- **Si NO existe**: usa el sub-agente `sa-tea-framework` para inicializarlo.
-
-```
-Proyecto: {PROJECT_NAME}
-Directorio raíz: {PROJECT_ROOT}
-```
-
-**ESPERA** a que complete antes de continuar.
-
-### 0.7 — Test Design de la épica
-
-Ejecuta el sub-agente `sa-tea-test-design` pasando:
-
-```
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
-Modo: epic-level
-```
-
-**ESPERA** a que complete antes de iniciar el loop de historias.
-
----
-
-## Reglas generales del pipeline
-
-### Regla 1 — Observabilidad obligatoria en cada sub-agente
-
-Cada sub-agente que ejecuta un workflow BMAD (`sa-create-story`, `sa-dev-story`, `sa-code-review`) **DEBE honrar las instrucciones de observabilidad** definidas en su respectivo `workflow_ext.md`. Estas instrucciones emiten eventos de telemetría (`sa-emit.js`) a GCP en momentos específicos del flujo y son la fuente de todos los reportes de métricas del equipo.
-
-**Workflows instrumentados y eventos que se deben emitir:**
-
-| Sub-agente | `workflow_ext.md` | Eventos emitidos |
-|---|---|---|
-| `sa-create-story` | `_siesa-agents/bmm/workflows/4-implementation/create-story/workflow_ext.md` | `workflow.started`, `status.changed` (backlog → ready-for-dev), `workflow.finished` |
-| `sa-dev-story` | `_siesa-agents/bmm/workflows/4-implementation/dev-story/workflow_ext.md` | `workflow.started`, `status.changed` (in-progress → review), `workflow.finished` |
-| `sa-code-review` | `_siesa-agents/bmm/workflows/4-implementation/code-review/workflow_ext.md` | `workflow.started`, `fix.started`/`fix.finished` (cuando el usuario acepta auto_fix / action_items / show_details), `status.changed` (review → done o → in-progress), `workflow.finished` |
-
-**Prohibido a cualquier sub-agente bajo este orquestador:**
-
-- ❌ Saltarse, comentar, condicionar u omitir cualquier comando `node ... sa-emit.js ...` del `workflow_ext.md` correspondiente.
-- ❌ Diferir la emisión al "final del pipeline" o agruparla en batch. Los eventos son **lifecycle markers** y solo tienen sentido en el instante exacto que el `workflow_ext.md` indica (`workflow.finished` mide `duration_ms` desde el `workflow.started` correspondiente; si lo retrasas, la métrica queda corrompida).
-
-**Manejo de errores de `sa-emit.js`:**
-
-Si la llamada a `sa-emit.js` falla (gateway caído, credenciales mal configuradas, etc.), el sub-agente debe:
-
-1. Registrar el fallo como advertencia **no-bloqueante**.
-2. **Continuar el workflow normalmente** (regla universal documentada en cada `workflow_ext.md`: *"observability must never block the workflow"*).
-3. NUNCA reemplazar la llamada por su omisión deliberada — el evento queda buffereado localmente en `~/.claude/observability/buffer/events.jsonl` y se reenvía automáticamente cuando el transporte se recupera.
-
 ---
 
 ## Reglas generales del pipeline
@@ -159,7 +96,7 @@ Si la llamada a `sa-emit.js` falla (gateway caído, credenciales mal configurada
 
 ## PASO 1 — Loop de procesamiento por historia
 
-Para CADA historia pendiente de la épica seleccionada, ejecuta secuencialmente los sub-agentes dedicados. Cada historia completa su ciclo completo antes de pasar a la siguiente.
+Para CADA historia pendiente de la épica seleccionada, ejecuta secuencialmente los 3 sub-agentes dedicados. Cada historia completa su ciclo completo (create → dev → code-review) antes de pasar a la siguiente.
 
 Los sub-agentes están definidos en `.claude/agents/` y DEBES invocarlos por nombre usando la herramienta Agent con `subagent_type`.
 
@@ -180,22 +117,6 @@ Descripción: {STORY_DESCRIPTION_FROM_EPICS_FILE}
 
 ---
 
-### SUB-AGENTE A.5 — ATDD
-
-Solo si el SUB-AGENTE A fue exitoso, usa la herramienta Agent con `subagent_type: "sa-tea-atdd"` y pasa como prompt:
-
-```
-Historia a procesar: {STORY_FILE_PATH}
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
-```
-
-**ESPERA** a que complete.
-
-> Si falla, registra el fallo como no-bloqueante y **CONTINÚA** con el SUB-AGENTE B. Los tests ATDD no son prerequisito para la implementación.
-
----
-
 ### SUB-AGENTE B — Dev Story
 
 Solo si el SUB-AGENTE A fue exitoso, usa la herramienta Agent con `subagent_type: "sa-dev-story"` y pasa como prompt:
@@ -210,71 +131,6 @@ Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
 
 ---
 
-### SUB-AGENTE B.1 — ATDD Verify (loop de corrección)
-
-Solo si el SUB-AGENTE B fue exitoso Y el SUB-AGENTE A.5 generó tests, ejecuta este loop.
-Si A.5 falló o no generó tests, omite este paso y continúa con B.5.
-
-Ejecuta hasta **3 intentos en total** (1 inicial + 2 reintentos):
-
-#### Intento N:
-
-Usa la herramienta Agent con `subagent_type: "sa-tea-atdd-run"` y pasa como prompt:
-
-```
-Historia: {STORY_FILE_PATH}
-Archivos de test ATDD: {ATDD_TEST_FILES_PATH}
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-```
-
-**ESPERA** a que complete y evalúa el resultado:
-
-- **PASS** → todos los tests en GREEN. Continúa con el SUB-AGENTE B.5.
-- **SKIP** → no se encontraron los archivos. Registra como advertencia y continúa con B.5.
-- **FAIL** (y quedan reintentos) → re-invoca el SUB-AGENTE B con contexto adicional:
-
-```
-Historia a implementar: {STORY_FILE_PATH}
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
-CORRECCIÓN REQUERIDA — Tests ATDD fallidos (intento {N}/3):
-{OUTPUT_COMPLETO_DE_ATDD_RUN con nombres de tests fallidos y mensajes de error}
-Corrige la implementación para que estos tests pasen a GREEN.
-```
-
-- **FAIL** (sin reintentos restantes, tras 3 intentos) → registra la historia como FAIL con motivo "ATDD no pasaron a GREEN tras 3 intentos" y pasa a la siguiente historia. No ejecuta B.5, B.6 ni C.
-
----
-
-### SUB-AGENTE B.5 — Test Automate
-
-Solo si el SUB-AGENTE B fue exitoso, usa la herramienta Agent con `subagent_type: "sa-tea-automate"` y pasa como prompt:
-
-```
-Historia a procesar: {STORY_FILE_PATH}
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
-Tests ATDD generados: {ATDD_TEST_FILES_PATH_OR_"ninguno si A.5 falló"}
-```
-
-**ESPERA** a que complete. Si falla, registra el fallo y continúa con el SUB-AGENTE B.6 / C.
-
----
-
-### SUB-AGENTE B.6 — Test Review
-
-Solo si el SUB-AGENTE B.5 fue exitoso, usa la herramienta Agent con `subagent_type: "sa-tea-review"` y pasa como prompt:
-
-```
-Historia revisada: {STORY_FILE_PATH}
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Directorio de tests de la historia: {STORY_TEST_DIR}
-```
-
-**ESPERA** a que complete. Si falla, registra el fallo y continúa con el SUB-AGENTE C.
-
----
-
 ### SUB-AGENTE C — Code Review
 
 Solo si el SUB-AGENTE B fue exitoso, usa la herramienta Agent con `subagent_type: "sa-code-review"` y pasa como prompt:
@@ -291,49 +147,24 @@ Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
 
 ### Feedback intermedio por historia
 
-Después de completar todos los sub-agentes para una historia, muestra al usuario un resumen breve de UNA línea.
+Después de completar los 3 sub-agentes para una historia, muestra al usuario un resumen breve de UNA línea.
 
 ```
-✅ Story {N}.{M} [{título}]: create ✅ → atdd ✅ → dev ✅ → atdd-run ✅ → automate ✅ → test-review ✅ → review ✅ (PASS)
-```
-
-Si hubo reintentos en atdd-run, indica cuántos:
-```
-✅ Story {N}.{M} [{título}]: create ✅ → atdd ✅ → dev ✅ → atdd-run ⚠️(2 intentos) → automate ✅ → test-review ✅ → review ✅ (PASS)
+✅ Story {N}.{M} [{título}]: create ✅ → dev ✅ → review ✅ (PASS)
 ```
 
 En caso de fallo:
 ```
-❌ Story {N}.{M} [{título}]: create ✅ → atdd ✅ → dev ✅ → atdd-run ❌(3/3) → (FAIL: ATDD no pasaron a GREEN)
+❌ Story {N}.{M} [{título}]: create ✅ → dev ✅ → review ❌ (FAIL: motivo breve)
 ```
 
 Luego continúa con la siguiente historia.
 
 ---
 
-## PASO 2 — Quality Gate TEA y Reporte Final
-
-### Quality Gate TEA
-
-Al completar el loop de todas las historias, ejecuta el gate de la épica.
+## PASO 2 — Reporte Final
 
-#### Gate — Traceability + Quality Gate
-
-Usa la herramienta Agent con `subagent_type: "sa-tea-trace"` y pasa como prompt:
-
-```
-Épica: {EPIC_NUMBER} - {EPIC_TITLE}
-Fuente de la épica: {EPIC_SOURCE_FILE_PATH}
-Historias procesadas: {LISTA_DE_STORY_FILE_PATHS}
-```
-
-**ESPERA** a que complete.
-
----
-
-### Reporte Final
-
-Al completar TODAS las historias y el gate TEA, genera el archivo de reporte en:
+Al completar TODAS las historias de la épica, genera el archivo de reporte en:
 
 ```
 _bmad-output/implementation-artifacts/epic-{N}-report.md
@@ -350,22 +181,14 @@ El contenido del archivo debe seguir esta estructura:
 - Historias procesadas: X/Y
 - Exitosas (full pipeline): X
 - Con fallos: X
-- Quality Gate (Cobertura): PASS / CONCERNS / FAIL
 
 ## Detalle por Historia
 
-| Historia | Create | ATDD | Dev | ATDD-Run | Automate | Test Review | Code Review | Estado |
-|----------|--------|------|-----|----------|----------|-------------|-------------|--------|
-| {N}.1    | ✅     | ✅   | ✅  | ✅ (1)   | ✅       | ✅          | ✅ PASS      | Completada |
-| {N}.2    | ✅     | ✅   | ✅  | ⚠️ (2)  | ✅       | ⏭️         | ✅ PASS      | Completada |
-| {N}.3    | ✅     | ❌   | ✅  | ⏭️      | ✅       | ✅          | ✅ PASS      | Completada |
-
-## Quality Gate
-
-| Gate | Status | Detalle |
-|------|--------|---------|
-| Coverage P0 | ✅ PASS | 100% cubierto |
-| Coverage Overall | ⚠️ CONCERNS | 78% (mínimo 80%) |
+| Historia | Create | Dev | Code Review | Estado |
+|----------|--------|-----|-------------|--------|
+| {N}.1    | ✅     | ✅  | ✅ PASS      | Completada |
+| {N}.2    | ✅     | ✅  | ⚠️ PASS c/obs | Completada |
+| {N}.3    | ✅     | ❌  | ⏭️          | Fallo en dev |
 
 ## Historias que requieren atención manual
 - [lista de historias con fallos y razón, o "Ninguna" si todas pasaron]
@@ -377,8 +200,8 @@ Una vez escrito el archivo, informa al usuario:
 Reporte guardado en: _bmad-output/implementation-artifacts/epic-{N}-report.md
 ```
 
-Si TODAS las historias pasaron y el gate TEA es PASS, confirma al usuario que la épica está completa.
-Si alguna falló o el gate está en CONCERNS/FAIL, indica cuáles requieren intervención manual y por qué.
+Si TODAS las historias pasaron, confirma al usuario que la épica está completa.
+Si alguna falló, indica cuáles requieren intervención manual y por qué.
 
 Luego **continúa con la siguiente épica de EPIC_LIST** repitiendo desde el PASO 0.2.
 
@@ -391,12 +214,12 @@ Al completar el procesamiento de TODAS las épicas de EPIC_LIST, muestra un resu
 ```
 ## Resumen del pipeline — Épicas {EPIC_LIST_START}-{EPIC_LIST_END}
 
-| Épica | Historias | Exitosas | Con fallos | Gate TEA | Reporte |
-|-------|-----------|----------|------------|----------|---------|
-| N     | X/Y       | X        | X          | PASS/CONCERNS/FAIL | epic-N-report.md |
-| ...   | ...       | ...      | ...        | ...      | ...     |
+| Épica | Historias | Exitosas | Con fallos | Reporte |
+|-------|-----------|----------|------------|---------|
+| N     | X/Y       | X        | X          | epic-N-report.md |
+| ...   | ...       | ...      | ...        | ...     |
 
 Total: X épicas procesadas. X completadas, X con atención manual requerida.
 ```
 
-Si hay épicas con fallos o gates en CONCERNS/FAIL, lista los archivos de reporte para revisión manual.
+Si hay épicas con fallos, lista los archivos de reporte para revisión manual.

package/claude/skills/sa-screen-layout-refactor/SKILL.md

@@ -58,13 +58,18 @@ nothing or to several candidates is asked about, never guessed.
 Key definitions you take from the UX spec instead of inferring:
 
 - **§2.1 Component Selection Priority** (mandatory order): 1) a siesa-ui-kit
-  molecule, 2) a **composition** of kit molecules, 3) **shadcn as the
+  molecule, 2) a **composition** of kit molecules, 3) **shadcn or Radix as the
   fallback** when neither expresses the widget — used directly, flagged in the
-  report (`⚠️ shadcn fallback: <widget>`) so the team can later decide whether
-  to promote it into the kit. Hand-rolled HTML widgets are never an option at
-  any step. A shadcn component obeys the same `rules/` as everything else:
-  design-system token classes, rem, no inline styles — restyled to the design
-  system, never left on shadcn defaults.
+  report (`⚠️ shadcn fallback: <widget>` / `⚠️ radix fallback: <widget>`) so
+  the team can later decide whether to promote it into the kit. Prefer shadcn
+  when it covers the widget; reach for Radix primitives
+  (`@radix-ui/react-dialog`, `Popover`, `Collapsible`, etc.) when the
+  interaction pattern (slide-in panels, floating overlays, controlled
+  disclosure) needs headless primitives that shadcn doesn't expose cleanly.
+  Hand-rolled HTML widgets are never an option at any step. shadcn and Radix
+  components obey the same `rules/` as everything else: design-system token
+  classes, rem, no inline styles — restyled to the design system, never left
+  on defaults.
 - **§1 Design System Foundation**: brand palette (primary `#0e79fd`), semantic
   colors, surfaces; neutrals are `slate.*`, never the secondary brand scale.
 - **§4.3 Page Structure**: the standard page scaffold (header with title +
@@ -324,8 +329,49 @@ the screen's archetype, is the screen `❌ BLOCKED: <screen> — no mockup and n
 memory precedent`. Steps 2–6 then run identically, with the synthesized plan
 standing in for the mockup.
 
+**If the target screen already uses siesa-ui-kit components** (e.g. it is
+built on `MasterCrud`, `Table`, or any other kit molecule), this is **not a
+skip condition**. The refactor goal is the *distribution* — how widgets are
+arranged, grouped, and presented — not the widget vocabulary. If the
+distribution in the mockup or the user's instruction differs from the current
+screen, proceed with the full refactor using kit compositions (more complex
+compositions are acceptable and expected). Only when no kit composition covers
+a widget should shadcn or Radix be considered.
+
 ### Step 2 — Build the homologation map
 
+#### Interaction audit (before the widget inventory)
+
+For every interactive element in the mockup (buttons, toggles, switches,
+disclosure triggers, tab groups), read the associated JS/event logic in the
+source HTML and document the full contract:
+
+| Trigger | Event | Effect | Position / layout |
+|---------|-------|--------|-------------------|
+| Filter button | click | opens filter panel | slide-in from right (Sheet / Drawer) |
+| Toggle switch | change | reveals option group | appears to the right of the switch |
+| … | … | … | … |
+
+This table is **mandatory input for the homologation map**. A widget whose
+interaction contract is not documented here cannot be mapped correctly — the
+model will default to stacking everything vertically, which is the failure
+mode. Map each effect to its kit realization:
+
+- A **slide-in panel** (sidebar, drawer) → `Sheet` (shadcn) or
+  `@radix-ui/react-dialog` in sheet mode, never a `div` below the trigger.
+- A **floating overlay / popover** → `Popover` (shadcn or Radix).
+- A **conditionally revealed section beside the trigger** → `Collapsible`
+  (`@radix-ui/react-collapsible`) with `flex-row` layout so the revealed
+  content appears to the right, not below.
+- A **tab-like switch that swaps content areas** → `Tabs` (kit) with the
+  content panel beside or below as the mockup dictates.
+
+If the source HTML has no JS for a trigger (static mockup), infer the pattern
+from the visual layout annotation (labels like "→ panel", arrows, overlapping
+layers) and record it as `inferred`. An `inferred` entry still produces a
+mapping; it is flagged `⚠️ inferred behavior` in the screen report so a
+reviewer can confirm before shipping.
+
 Inventory every widget the mockup draws — buttons, checkboxes, data grids,
 tabs, badges, dropdown menus, inputs, labels with descriptions, pagination,
 dividers, avatars — and map **each one** to its kit realization before touching
@@ -403,6 +449,24 @@ With the map in hand, audit the **current** screen and write down:
 - **Stays identical** — every field name, validation, hook call, query,
   mutation, handler, prop and type; every aria-label and accessible behavior.
 
+**Filter continuity check (MasterCrud targets only):** If the current screen
+is built on `MasterCrud`, inventory its active filter logic before doing
+anything else:
+
+```bash
+grep -rn "useFilter\|filterParams\|queryKey\|searchParams\|filterState\|onFilter" \
+  apps/Frontend/src/modules/<module-slug>/presentation/
+```
+
+Record every hook, param key, and callback that drives filtering. If the
+mockup or the user's instruction calls for a composition that does **not** use
+`MasterCrud`, these filter hooks are now orphaned — their UI trigger will
+disappear. Document them in the gap analysis as **"filter bindings requiring
+rewire"** (not as warnings to ignore) and carry them into Step 4 as a required
+output: the new composition must expose a UI element (filter button, search
+input, panel) wired to the same hook calls. No filter that worked before the
+refactor may be left unreachable after it.
+
 Two asymmetries, both flagged, never silently resolved:
 
 - A mockup element with **no counterpart in the current screen** (an extra
@@ -462,6 +526,24 @@ The hard-won mechanics, worth understanding rather than copying:
   and declares no fields. If that file ever needs a validation or an API call,
   the change stopped being layout — back to Step 3.
 
+**Filter rewiring (when leaving MasterCrud):** If Step 3 identified orphaned
+filter bindings, the new composition must reconnect them. This is strictly
+presentation-layer work — the hooks already know how to filter; they only
+need a new UI trigger:
+
+- A filter button → opens a `Sheet` (shadcn) or `Collapsible` panel; its
+  `onApply` / `onChange` calls the same hook callback that `MasterCrud`'s
+  built-in filter used.
+- A search input → bound to the same `filterParams` key, same debounce if
+  it existed.
+- Advanced vs. basic filter sections → same state split, new visual grouping
+  inside the panel.
+
+Wire each binding explicitly. Close this sub-step with a checklist: one line
+per orphaned filter binding, marked `✅ rewired` or `❌ no UI trigger found`.
+A binding left `❌` blocks the screen (`❌ BLOCKED: <screen> — filter
+binding <name> has no UI trigger in new composition`).
+
 Whichever kind: keep field `name`s/`accessorKey`s, react-hook-form
 registrations and resolvers, zod schemas, TanStack Query/Router bindings,
 `useEffect` dependencies, event handlers, i18n keys and TypeScript types
@@ -644,6 +726,10 @@ do with a blocked screen.
 - Weaken what a test verifies. Updating a structural assertion whose markup you
   replaced is legitimate (and reported); loosening a behavioral assertion to
   get green is not
+- Touch a view (create, edit, detail, list) for which the user provided **no
+  reference mockup or explicit instruction** — if only the list view was
+  referenced, the create/edit views are out of scope even if they share the
+  same module; scope is per-view, not per-module
 - Start a run without an explicit user-declared target (a module/feature name,
   or an explicit full-scope instruction) — inferring what to refactor is
   forbidden; process anything the declared scope doesn't cover

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "siesa-agents",
-  "version": "2.1.96",
+  "version": "2.1.98",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {

package/claude/agents/sa-tea-atdd-run.md

@@ -1,76 +0,0 @@
----
-name: sa-tea-atdd-run
-description: "Sub-agente TEA autónomo que ejecuta los tests ATDD generados para una historia y reporta cuántos pasaron a GREEN. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: purple
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo cuya única responsabilidad es **ejecutar los tests ATDD** de una historia y reportar si pasaron a GREEN después de la implementación.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente.
-- Ejecuta SOLO los archivos de test indicados en el prompt — no toda la suite.
-- No modifiques los tests ni el código fuente. Solo ejecuta y reporta.
-- Si no existen los archivos de test indicados, reporta SKIP con el motivo.
-
-## Ejecución
-
-### 1. Detectar el test runner
-
-Lee `package.json` del proyecto para determinar si usa Playwright o Cypress:
-- Si tiene `@playwright/test` o `playwright` → usa Playwright
-- Si tiene `cypress` → usa Cypress
-
-### 2. Construir el comando de ejecución
-
-**Playwright:**
-```
-npx playwright test {ATDD_TEST_FILES} --reporter=list
-```
-
-**Cypress:**
-```
-npx cypress run --spec "{ATDD_TEST_FILES}"
-```
-
-Donde `{ATDD_TEST_FILES}` son los archivos de test indicados en el prompt.
-
-### 3. Ejecutar los tests
-
-Corre el comando y captura la salida completa (stdout + stderr).
-
-### 4. Parsear resultados
-
-Del output extrae:
-- Total de tests ejecutados
-- Tests que pasaron (GREEN)
-- Tests que fallaron (RED) — para cada uno: nombre del test y mensaje de error
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un bloque estructurado así:
-
-```
-ATDD-RUN RESULT: PASS | FAIL | SKIP
-
-Tests ejecutados: X
-Tests GREEN: X
-Tests RED: X
-
-Tests fallidos (si los hay):
-- [nombre del test]: [mensaje de error resumido en 1 línea]
-- [nombre del test]: [mensaje de error resumido en 1 línea]
-
-Archivos ejecutados:
-- {ruta del archivo de test}
-```
-
-- **PASS**: todos los tests están en GREEN
-- **FAIL**: al menos un test sigue en RED — incluye el detalle de cada fallo
-- **SKIP**: no se encontraron los archivos de test indicados

package/claude/agents/sa-tea-atdd.md

@@ -1,40 +0,0 @@
----
-name: sa-tea-atdd
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-atdd para generar tests fallidos ANTES de la implementación (ciclo TDD red-green-refactor). Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: purple
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-atdd** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- Genera tests en estado RED (fallando) — su función es definir el comportamiento esperado ANTES de que exista implementación.
-- Sé directo, funcional y breve.
-- Implementa SOLO los tests que cubren los acceptance criteria de la historia indicada. Nada más.
-- Usa siempre el patrón Given-When-Then.
-- Usa network-first intercepts (intercepta la red antes de navegar).
-- Usa selectores `data-testid` — nunca selectores CSS frágiles.
-- No uses hard waits — solo explicit waits.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-atdd.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. La historia a procesar es la que se indica en el prompt que te invocó. No selecciones otra.
-4. NO hagas preguntas en ningún step. Si un step requiere input del usuario, dedúcelo de los artefactos del proyecto (story file, épica, arquitectura).
-5. Guarda el checklist ATDD y los archivos de test generados.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 4 líneas indicando:
-- Si se generaron los tests ATDD exitosamente o no
-- Cantidad de tests generados y niveles cubiertos (E2E / API / Component)
-- Ruta(s) de los archivos de test generados
-- Ruta del checklist ATDD generado

package/claude/agents/sa-tea-automate.md

@@ -1,39 +0,0 @@
----
-name: sa-tea-automate
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-automate en modo BMad-Integrated para expandir cobertura de tests después de la implementación. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: cyan
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-automate** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- Opera en modo **BMad-Integrated**: expande los tests ATDD existentes con edge cases, no analiza el codebase desde cero.
-- Sé directo, funcional y breve.
-- Cubre edge cases, error paths y boundary conditions que no estaban en los tests ATDD.
-- Si los tests ATDD no existen (fallaron en el sub-agente previo), analiza el código implementado directamente.
-- Máximo 3 iteraciones de auto-healing si un test falla al generarse.
-- Tests no recuperables tras 3 intentos: márcalos con `test.fixme()` con comentario explicativo.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-automate.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. La historia a procesar es la que se indica en el prompt que te invocó. No selecciones otra.
-4. NO hagas preguntas en ningún step. Deduce lo necesario de los artefactos del proyecto.
-5. Guarda el archivo `automation-summary.md` con el resumen de cobertura.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 4 líneas indicando:
-- Si se expandió la cobertura exitosamente o no
-- Cantidad de tests nuevos generados por nivel (E2E / API / Component / Unit)
-- Tests marcados como fixme (si los hay) y razón breve
-- Ruta del automation-summary.md generado

package/claude/agents/sa-tea-framework.md

@@ -1,36 +0,0 @@
----
-name: sa-tea-framework
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-framework para verificar o inicializar la arquitectura del test framework (Playwright o Cypress) en el proyecto. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: blue
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-framework** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- **Primero verifica** si ya existe un framework configurado (`playwright.config.ts`, `cypress.config.ts`, `playwright.config.js`, `cypress.config.js`). Si existe, reporta que ya está configurado y NO modifiques nada.
-- Solo inicializa el framework si no existe ninguna configuración previa.
-- Auto-detecta el framework preferido leyendo `package.json`. Si ambos están instalados o ninguno, prefiere Playwright.
-- Sé directo, funcional y breve.
-- No instales paquetes npm — solo crea los archivos de configuración y estructura de directorios.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-framework.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. NO hagas preguntas en ningún step. Auto-detecta framework y configuración del proyecto.
-4. Si el framework ya existe, detente tras reportarlo — no ejecutes el resto del workflow.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 3 líneas indicando:
-- Si el framework ya existía (no se hizo nada) o si se inicializó
-- Framework detectado/configurado (Playwright / Cypress) y versión si está disponible
-- Archivos creados (si aplica) o confirmación de que ya estaba configurado

package/claude/agents/sa-tea-nfr.md

@@ -1,40 +0,0 @@
----
-name: sa-tea-nfr
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-nfr para validar requisitos no-funcionales (performance, security, reliability, maintainability) de la épica. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: red
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-nfr** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- Evalúa las 4 categorías estándar: Performance, Security, Reliability, Maintainability.
-- Aplica reglas determinísticas estrictas por categoría:
-  - **PASS**: evidencia existe Y cumple el threshold definido
-  - **CONCERNS**: threshold desconocido O evidencia faltante/incompleta O dentro del 10% del umbral
-  - **FAIL**: evidencia existe pero NO cumple el threshold
-- Sé directo, funcional y breve.
-- No inventes evidencia. Si no existe, el resultado es CONCERNS, no PASS.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-nfr.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. La épica a evaluar es la que se indica en el prompt que te invocó.
-4. NO hagas preguntas en ningún step. Deduce lo necesario de los artefactos del proyecto (story files, acceptance criteria, tests generados, código implementado).
-5. Guarda el NFR assessment y el gate YAML.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 5 líneas indicando:
-- Gate decision por categoría: Performance / Security / Reliability / Maintainability (PASS / CONCERNS / FAIL)
-- Gate decision global de la épica
-- Quick wins identificados (si los hay, máximo 2)
-- Ruta del NFR assessment generado

package/claude/agents/sa-tea-review.md

@@ -1,44 +0,0 @@
----
-name: sa-tea-review
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-test-review para revisar la calidad de los tests generados para una historia. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: orange
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-test-review** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- El scope de revisión es los tests generados para la historia indicada en el prompt (no toda la suite).
-- Valida contra los estándares obligatorios del TEA:
-  - Estructura Given-When-Then
-  - Sin hard waits
-  - Auto-cleanup en fixtures (sin estado compartido)
-  - Selectores `data-testid`
-  - Performance: menos de 90 segundos por test
-  - Tamaño: menos de 300 líneas por archivo
-  - Una assertion principal por test (atómico)
-- Si encuentras issues auto-corregibles, corrígelos directamente sin pedir confirmación.
-- Sé directo, funcional y breve.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-test-review.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. Los tests a revisar son los de la historia indicada en el prompt. No revises tests de otras historias.
-4. NO hagas preguntas en ningún step.
-5. Guarda el reporte `test-review-{story_id}.md`.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 4 líneas indicando:
-- Veredicto: PASS / PASS CON OBSERVACIONES / FAIL
-- Issues encontrados por severidad (críticos / warnings)
-- Issues auto-corregidos (si los hay)
-- Ruta del test-review generado

package/claude/agents/sa-tea-test-design.md

@@ -1,37 +0,0 @@
----
-name: sa-tea-test-design
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-test-design en modo Epic-Level (Phase 4) para crear el plan de tests de la épica antes de iniciar el loop de historias. Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: purple
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-test-design** del módulo TEA (Test Engineering Agent) de BMAD, en modo **Epic-Level (Phase 4)**.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- Opera SIEMPRE en modo **epic-level** (Phase 4) — no en modo system-level. Si el workflow intenta auto-detectar el modo, fuerza epic-level.
-- Sé directo, funcional y breve.
-- El output es el plan de tests para la épica completa, no para una historia individual.
-- Incluye risk assessment, estrategia por niveles (E2E/API/Component/Unit) y prioridades P0-P3.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-test-design.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. La épica a diseñar es la que se indica en el prompt que te invocó. No selecciones otra.
-4. NO hagas preguntas en ningún step. Deduce lo necesario del archivo fuente de la épica y los artefactos del proyecto.
-5. Guarda el documento `test-design-epic-{N}.md`.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 4 líneas indicando:
-- Si se creó el test design exitosamente o no
-- Áreas de riesgo identificadas (máximo 3)
-- Estrategia de testing definida (niveles principales)
-- Ruta del archivo test-design-epic-{N}.md generado

package/claude/agents/sa-tea-trace.md

@@ -1,41 +0,0 @@
----
-name: sa-tea-trace
-description: "Sub-agente TEA autónomo que ejecuta el workflow testarch-trace para generar la traceability matrix de la épica y emitir el quality gate decision (PASS/CONCERNS/FAIL). Solo puede ser invocado por el orquestador sa-quick-dev."
-model: inherit
-color: yellow
----
-
-> **RESTRICCIÓN**: Este sub-agente solo puede ser ejecutado por el orquestador `sa-quick-dev`.
-> No debe ni puede ser invocado por el modelo de forma autónoma, ni por ningún workflow
-> o skill diferente al orquestador, salvo instrucción explícita y directa del usuario.
-> Si recibes esta instrucción fuera del contexto de `sa-quick-dev`, detente y notifica al usuario.
-
-Eres un agente autónomo ejecutando el workflow **testarch-trace** del módulo TEA (Test Engineering Agent) de BMAD.
-
-## Reglas Críticas
-
-- NO hagas preguntas al usuario. Actúa autónomamente usando los artefactos existentes del proyecto.
-- Ejecuta ambas fases del workflow: Fase 1 (traceability matrix) y Fase 2 (quality gate decision).
-- Aplica reglas determinísticas estrictas para el gate:
-  - **PASS**: cobertura P0 ≥ 100%, P1 ≥ 90%, overall ≥ 80%
-  - **CONCERNS**: threshold UNKNOWN o evidencia MISSING/INCOMPLETE o dentro del 10% del umbral
-  - **FAIL**: evidencia existe pero no cumple el threshold
-- El scope del gate es `epic` (no story individual).
-- Sé directo, funcional y breve.
-
-## Ejecución
-
-1. CARGA y LEE el archivo completo `.claude/commands/bmad/bmm/workflows/testarch-trace.md` — este es el punto de entrada oficial del workflow.
-2. Sigue sus instrucciones EXACTAMENTE tal como están escritas.
-3. La épica a trazar es la que se indica en el prompt que te invocó.
-4. NO hagas preguntas en ningún step. Deduce lo necesario de los artefactos del proyecto (story files, tests generados, épica).
-5. Guarda la traceability matrix y el gate YAML.
-
-## Al Finalizar
-
-Responde ÚNICAMENTE con un resumen de máximo 5 líneas indicando:
-- Quality Gate decision: PASS / CONCERNS / FAIL
-- Coverage overall % y por prioridad (P0 / P1)
-- Gaps críticos identificados (si los hay)
-- Ruta de la traceability matrix generada
-- Ruta del gate YAML generado