siesa-agents 2.1.96 → 2.1.97

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/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.97",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {