siesa-agents 2.1.53 → 2.1.55

package/bmad/bmm/data/git-flow-siesa.md

@@ -0,0 +1,50 @@
+# Protocolo de Git: Creación de Ramas y Commits - SiesaTeams
+
+Este documento establece el flujo obligatorio para la creación de ramas y el estándar de mensajes de commit para asegurar el cumplimiento de la gobernanza.
+
+---
+
+## 1. Validación de Rama Padre (Feature)
+Para cualquier desarrollo de funcionalidad (**feature**), la rama de origen debe ser estrictamente `develop`.
+
+**Procedimiento del Agente:**
+1. Validar que se encuentra en: `develop`.
+2. Ejecutar: `git checkout develop && git pull origin develop`.
+3. Confirmar que no hay cambios pendientes antes de ramificar.
+
+---
+
+## 2. Nomenclatura de la Rama
+La estructura del nombre debe seguir el formato:
+`rama-padre-team-owner-rq-descripcion`.
+
+**Parámetros Sugeridos:**
+* **Rama Padre:** `develop`.
+* **Team:** (Debe coincidir con un prefijo válido, ej: `legacy-erp-nomina`).
+* **Owner:** `gaduranb` (Basado en el correo corporativo gaduranb@siesa.com).
+* **RQ:** Número de requerimiento asignado.
+* **Descripción:** Breve, en minúsculas y con guiones.
+
+**Ejemplo de comando:**
+`git checkout -b develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz`.
+
+---
+
+## 3. Estándar de Mensajes de Commit
+Se adopta el formato de **Conventional Commits** para mejorar la legibilidad y automatización.
+
+| Tipo | Formato del Mensaje | Uso |
+| :--- | :--- | :--- |
+| **Feature** | `feat: descripción clara del cambio` | Nuevas funcionalidades. |
+| **Fix** | `fix: descripción del error corregido` | Corrección de errores (bugs). |
+
+**Ejemplos:**
+* `git commit -m "feat: implementar validación de identidad mediante SSO"`.
+* `git commit -m "fix: corregir cálculo de nómina en rama legacy"`.
+
+---
+
+## 4. Reglas de Oro de Gobernanza
+* **Todo en Minúsculas:** Los nombres de ramas y repositorios no deben contener mayúsculas.
+* **Protección de Ramas:** `main` y `develop` están protegidas; el push directo está prohibido.
+* **Nota:** Esta automatización solo podrá crear las ramas como se indica y realizar push a las mismas en caso de ser necesario.

package/bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/architecture-patterns.md

@@ -131,9 +131,14 @@ Use MCP to install Shadcn components instead of creating manually.
 
 **Default**: Always use Vite + TanStack Router with TypeScript.
 
-**Microfrontends**: Use Vite + Module Federation for distributed architecture.
-
-**Reasoning**: Vite provides faster builds, TanStack Router offers type-safe routing, and the combination is prepared for microfrontends with Module Federation.
+**Microfrontends**:
+- **DEFAULT**: Vite + Single-SPA (`vite-plugin-single-spa` + `single-spa-react`) para todos los módulos de negocio
+- **EXCEPCIÓN**: Vite + Module Federation SOLO para módulos transversales/compartidos explícitamente marcados por el ingeniero
+
+**Reasoning**:
+- Single-SPA proporciona aislamiento completo (CSS, JS, lifecycle), mejor hot reload, y error boundaries built-in
+- Module Federation solo se usa cuando hay necesidad explícita de compartir código entre MFEs
+- Ver `vite-config-standard.md` para configuración detallada
 
 ## Backend Architecture
 

package/bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/frontend-standards.md

@@ -92,7 +92,32 @@ Este documento define los estándares de desarrollo frontend para aplicaciones e
 | Escenario | Framework | Razón |
 |-----------|-----------|-------|
 | **Default** | Vite + TanStack Router | Mejor DX, type-safety, preparado para microfrontends |
-| **Microfrontends** | Vite + Module Federation | Arquitectura distribuida |
+| **MFE (Default)** | Vite + Single-SPA | Aislamiento completo, CSS lifecycle, error boundaries built-in |
+| **Módulo Federable** | Vite + Module Federation | SOLO para módulos transversales explícitamente marcados |
+
+### 2.3 Regla Crítica: Single-SPA vs Module Federation
+
+> ⚠️ **IMPORTANTE**: Por defecto, todos los microfrontends usan **Single-SPA**. Module Federation se usa **SOLO** cuando el ingeniero define explícitamente que un módulo debe ser compartido/federable.
+
+| Tipo | Tecnología | Uso |
+|------|------------|-----|
+| **MFE de Negocio** | `vite-plugin-single-spa` + `single-spa-react` | ✅ DEFAULT - finance, hr, inventory, etc. |
+| **Módulo Compartido** | `@module-federation/vite` | ⚠️ SOLO cuando explícitamente requerido |
+
+**Dependencias Single-SPA (DEFAULT):**
+```bash
+npm install single-spa-react
+npm install vite-plugin-single-spa --save-dev
+```
+
+**Beneficios de Single-SPA:**
+- CSS isolation automático via `cssLifecycleFactory`
+- Error boundaries built-in
+- Lifecycle completo (bootstrap, mount, unmount)
+- Mejor hot reload
+- Menor complejidad de configuración
+
+Ver `vite-config-standard.md` para configuración detallada.
 
 ### 2.3 Herramientas de Desarrollo
 

package/bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/vite-config-standard.md

@@ -0,0 +1,535 @@
+# Vite Config - Estándar Microfrontends
+
+Guía de configuración estándar para microfrontends usando Single-SPA (default) y Module Federation (solo módulos compartidos).
+
+---
+
+## REGLA CRÍTICA: Single-SPA vs Module Federation
+
+| Tipo de Módulo | Tecnología | Cuándo Usar |
+|----------------|------------|-------------|
+| **MFE Estándar** | **Single-SPA** | ✅ DEFAULT - Todos los módulos de negocio (finance, hr, inventory, etc.) |
+| **Módulo Transversal** | **Module Federation** | ⚠️ SOLO cuando el ingeniero define explícitamente que debe ser compartido |
+
+### ¿Cuándo usar Module Federation?
+
+Module Federation **SOLO** se usa para módulos que:
+1. Son **transversales** (usados por múltiples MFEs)
+2. El ingeniero los marca **explícitamente** como "federable"
+3. Ejemplos: Componentes compartidos, utilidades comunes, design system
+
+### ¿Cuándo usar Single-SPA?
+
+Single-SPA es el **DEFAULT** para:
+1. Todos los módulos de negocio (finance, hr, inventory, sales, etc.)
+2. Cualquier MFE que no sea explícitamente marcado como federable
+3. Widgets independientes
+
+---
+
+## Dependencias Requeridas
+
+### Para MFE Single-SPA (DEFAULT)
+
+```bash
+# Core Single-SPA
+npm install single-spa-react
+
+# Vite Plugin (configura automáticamente entry points, externals, CSS)
+npm install vite-plugin-single-spa --save-dev
+
+# React (obligatorio)
+npm install react react-dom
+npm install @types/react @types/react-dom --save-dev
+
+# Común
+npm install @vitejs/plugin-react --save-dev
+```
+
+### Para Módulo Federable (SOLO si explícitamente requerido)
+
+```bash
+# Module Federation
+npm install @module-federation/vite --save-dev
+
+# TanStack Router (si aplica)
+npm install @tanstack/react-router
+
+# Común
+npm install @vitejs/plugin-react --save-dev
+```
+
+---
+
+## 1. Single-SPA (DEFAULT para todos los MFEs)
+
+### 1.1 Configuración Vite (vite.config.ts)
+
+```typescript
+// modules/{module-name}/vite.config.ts
+import { defineConfig } from 'vite';
+import react from '@vitejs/plugin-react';
+import vitePluginSingleSpa from 'vite-plugin-single-spa';
+
+export default defineConfig({
+  plugins: [
+    react(),
+    vitePluginSingleSpa({
+      serverPort: 3001,                    // Puerto único por módulo
+      spaEntryPoints: 'src/spa.tsx',       // Entry point Single-SPA
+      cssStrategy: 'singleMife',           // CSS se inyecta/remueve en mount/unmount
+      projectId: '{module-name}-module',   // ID único del proyecto
+    }),
+  ],
+  server: {
+    port: 3001,
+    cors: true,
+  },
+  base: '/{module-name}/',                 // Prefijo de rutas
+});
+```
+
+### 1.2 Entry Point Single-SPA (src/spa.tsx)
+
+```typescript
+// modules/{module-name}/src/spa.tsx
+import React from 'react';
+import ReactDOMClient from 'react-dom/client';
+import singleSpaReact from 'single-spa-react';
+import { cssLifecycleFactory } from 'vite-plugin-single-spa/ex';
+import App from './App';
+
+// Props que el App Shell puede pasar al MFE
+export interface CustomProps {
+  i18n?: unknown;
+  eventBus?: unknown;
+  authContext?: unknown;
+}
+
+// Error boundary para errores en el MFE
+function ErrorFallback({ error }: { error: Error }) {
+  return (
+    <div className="flex items-center justify-center min-h-screen bg-red-50">
+      <div className="max-w-md p-6 bg-white rounded-lg shadow-lg">
+        <h2 className="text-xl font-semibold text-red-600 mb-2">
+          Error en módulo
+        </h2>
+        <p className="text-gray-600 mb-4">{error.message}</p>
+        <button
+          onClick={() => window.location.reload()}
+          className="px-4 py-2 bg-red-600 text-white rounded hover:bg-red-700"
+        >
+          Recargar
+        </button>
+      </div>
+    </div>
+  );
+}
+
+// Crear lifecycles con single-spa-react
+const lifecycles = singleSpaReact({
+  React,
+  ReactDOMClient,
+  rootComponent: App,
+  errorBoundary: (err: Error) => <ErrorFallback error={err} />,
+  // CRÍTICO: Especificar el contenedor del App Shell donde se montará el MFE
+  domElementGetter: () => document.getElementById('single-spa-application')!,
+});
+
+// CSS lifecycle - inyecta CSS al montar, lo remueve al desmontar
+const cssLc = cssLifecycleFactory('spa');
+
+// ⚠️ REGLA CRÍTICA: domElementGetter
+// -------------------------------------
+// El App Shell de Siesa provee un contenedor específico donde se montan los MFEs:
+//   <div id="single-spa-application">
+//
+// Sin domElementGetter:
+//   - single-spa-react crea un <div> nuevo al final del <body>
+//   - El MFE se renderiza FUERA del layout del App Shell
+//   - El usuario NO verá el MFE aunque esté montado correctamente
+//
+// Con domElementGetter:
+//   - El MFE se monta dentro del contenedor del App Shell
+//   - Se integra correctamente con el layout (navegación, estilos)
+//   - El usuario ve el MFE en la ubicación correcta
+//
+// TODOS los MFEs Single-SPA deben incluir esta configuración.
+
+// Exportar lifecycles combinados (CSS + React)
+export const bootstrap = [cssLc.bootstrap, lifecycles.bootstrap];
+export const mount = [cssLc.mount, lifecycles.mount];
+export const unmount = [cssLc.unmount, lifecycles.unmount];
+```
+
+### 1.3 Standalone Development (src/main.tsx)
+
+```typescript
+// modules/{module-name}/src/main.tsx
+// Para desarrollo standalone (sin App Shell)
+import React from 'react';
+import ReactDOM from 'react-dom/client';
+import App from './App';
+import './index.css';
+
+ReactDOM.createRoot(document.getElementById('root')!).render(
+  <React.StrictMode>
+    <App />
+  </React.StrictMode>
+);
+```
+
+### 1.4 App Shell - Registro de MFEs Single-SPA
+
+```typescript
+// app-shell/src/microfrontends/register.ts
+import { registerApplication, start } from 'single-spa';
+
+// Registrar cada MFE
+registerApplication({
+  name: 'finance',
+  app: () => System.import('http://localhost:3001/finance/spa.js'),
+  activeWhen: ['/finance'],
+  customProps: {
+    i18n: i18nInstance,
+    eventBus: eventBus,
+    authContext: authStore.getState(),
+  },
+});
+
+registerApplication({
+  name: 'inventory',
+  app: () => System.import('http://localhost:3002/inventory/spa.js'),
+  activeWhen: ['/inventory'],
+  customProps: {
+    i18n: i18nInstance,
+    eventBus: eventBus,
+    authContext: authStore.getState(),
+  },
+});
+
+registerApplication({
+  name: 'hr',
+  app: () => System.import('http://localhost:3003/hr/spa.js'),
+  activeWhen: ['/hr'],
+  customProps: {
+    i18n: i18nInstance,
+    eventBus: eventBus,
+    authContext: authStore.getState(),
+  },
+});
+
+// Iniciar Single-SPA
+start();
+```
+
+### 1.5 Import Map (index.html del App Shell)
+
+```html
+<!-- app-shell/index.html -->
+<script type="systemjs-importmap">
+{
+  "imports": {
+    "react": "https://cdn.jsdelivr.net/npm/react@18/umd/react.production.min.js",
+    "react-dom": "https://cdn.jsdelivr.net/npm/react-dom@18/umd/react-dom.production.min.js",
+    "single-spa": "https://cdn.jsdelivr.net/npm/single-spa@6/lib/system/single-spa.min.js"
+  }
+}
+</script>
+<script src="https://cdn.jsdelivr.net/npm/systemjs@6/dist/system.min.js"></script>
+```
+
+---
+
+## 2. Module Federation (SOLO para módulos transversales explícitos)
+
+> ⚠️ **IMPORTANTE**: Solo usar Module Federation cuando el ingeniero defina explícitamente que un módulo debe ser compartido/federable.
+
+### 2.1 Exponer un Módulo Federable (Remote)
+
+```typescript
+// shared-components/vite.config.ts
+import { defineConfig } from 'vite';
+import react from '@vitejs/plugin-react';
+import { federation } from '@module-federation/vite';
+
+export default defineConfig({
+  plugins: [
+    react(),
+    federation({
+      name: 'sharedComponents',            // Nombre único del módulo federable
+      filename: 'remoteEntry.js',
+      exposes: {
+        './Button': './src/components/Button.tsx',
+        './Modal': './src/components/Modal.tsx',
+        './DataTable': './src/components/DataTable.tsx',
+      },
+      shared: {
+        react: { singleton: true, requiredVersion: '^18.3.1' },
+        'react-dom': { singleton: true, requiredVersion: '^18.3.1' },
+        'siesa-ui-kit': { singleton: true },
+      },
+    }),
+  ],
+  server: {
+    port: 3010,
+    strictPort: true,
+    cors: true,
+  },
+  build: {
+    modulePreload: false,
+    target: 'esnext',
+    minify: false,
+    cssCodeSplit: false,
+  },
+});
+```
+
+### 2.2 Consumir Módulo Federable desde un MFE
+
+```typescript
+// modules/finance/vite.config.ts (MFE que consume módulos federables)
+import { defineConfig } from 'vite';
+import react from '@vitejs/plugin-react';
+import vitePluginSingleSpa from 'vite-plugin-single-spa';
+import { federation } from '@module-federation/vite';
+
+export default defineConfig({
+  plugins: [
+    react(),
+    vitePluginSingleSpa({
+      serverPort: 3001,
+      spaEntryPoints: 'src/spa.tsx',
+      cssStrategy: 'singleMife',
+      projectId: 'finance-module',
+    }),
+    // Solo agregar federation si necesita consumir módulos compartidos
+    federation({
+      name: 'finance',
+      remotes: {
+        sharedComponents: {
+          type: 'module',
+          name: 'sharedComponents',
+          entry: 'http://localhost:3010/remoteEntry.js',
+          entryGlobalName: 'sharedComponents',
+        },
+      },
+      shared: {
+        react: { singleton: true, requiredVersion: '^18.3.1' },
+        'react-dom': { singleton: true, requiredVersion: '^18.3.1' },
+      },
+    }),
+  ],
+  server: {
+    port: 3001,
+    cors: true,
+  },
+  base: '/finance/',
+});
+```
+
+### 2.3 Tipos para Módulos Federables
+
+```typescript
+// types/remotes.d.ts
+declare module 'sharedComponents/Button' {
+  const Button: React.ComponentType<ButtonProps>;
+  export default Button;
+}
+
+declare module 'sharedComponents/Modal' {
+  const Modal: React.ComponentType<ModalProps>;
+  export default Modal;
+}
+
+declare module 'sharedComponents/DataTable' {
+  const DataTable: React.ComponentType<DataTableProps>;
+  export default DataTable;
+}
+```
+
+---
+
+## 3. Convención de Puertos
+
+| Módulo | Puerto | Tipo | Descripción |
+|--------|--------|------|-------------|
+| app-shell | 3000 | Host | Orquestador Single-SPA |
+| finance | 3001 | Single-SPA | Módulo Finanzas |
+| inventory | 3002 | Single-SPA | Módulo Inventario |
+| hr | 3003 | Single-SPA | Módulo RRHH |
+| crm | 3004 | Single-SPA | Módulo CRM |
+| pos | 3005 | Single-SPA | Módulo POS |
+| shared-components | 3010 | Federation | Componentes compartidos (federable) |
+| shared-utils | 3011 | Federation | Utilidades compartidas (federable) |
+
+---
+
+## 4. Routing con TanStack Router
+
+### 4.1 Router del MFE (Single-SPA)
+
+> ⚠️ **IMPORTANTE:** Todas las rutas deben tener prefijo único que coincida con `base` en vite.config.ts
+
+```typescript
+// modules/finance/src/router.tsx
+import {
+  createRouter,
+  createRootRoute,
+  createRoute,
+  redirect,
+} from '@tanstack/react-router';
+import { MainLayout } from './components/layout/MainLayout';
+import Dashboard from './routes/dashboard';
+import AccountsIndex from './routes/accounts.index';
+import AccountDetail from './routes/accounts.$id';
+
+// Root route con layout
+const rootRoute = createRootRoute({
+  component: MainLayout,
+});
+
+// Ruta índice - redirige al dashboard
+const indexRoute = createRoute({
+  getParentRoute: () => rootRoute,
+  path: '/',
+  beforeLoad: () => {
+    throw redirect({ to: '/finance/dashboard' });
+  },
+});
+
+// Dashboard
+const dashboardRoute = createRoute({
+  getParentRoute: () => rootRoute,
+  path: '/finance/dashboard',
+  component: Dashboard,
+});
+
+// Cuentas - listado
+const accountsRoute = createRoute({
+  getParentRoute: () => rootRoute,
+  path: '/finance/accounts',
+  component: AccountsIndex,
+});
+
+// Cuentas - detalle
+const accountDetailRoute = createRoute({
+  getParentRoute: () => rootRoute,
+  path: '/finance/accounts/$id',
+  component: AccountDetail,
+});
+
+const routeTree = rootRoute.addChildren([
+  indexRoute,
+  dashboardRoute,
+  accountsRoute,
+  accountDetailRoute,
+]);
+
+export const router = createRouter({ routeTree });
+
+declare module '@tanstack/react-router' {
+  interface Register {
+    router: typeof router;
+  }
+}
+```
+
+### 4.2 Convención de Prefijos de Rutas
+
+| Módulo | Puerto | Base (vite.config) | Prefijo Rutas |
+|--------|--------|---------------------|---------------|
+| app-shell | 3000 | `/` | `/` |
+| finance | 3001 | `/finance/` | `/finance/*` |
+| inventory | 3002 | `/inventory/` | `/inventory/*` |
+| hr | 3003 | `/hr/` | `/hr/*` |
+
+---
+
+## 5. Shared Dependencies (para ambos)
+
+```typescript
+shared: {
+  // SIEMPRE singleton para React
+  react: { singleton: true, requiredVersion: '^18.3.1' },
+  'react-dom': { singleton: true, requiredVersion: '^18.3.1' },
+
+  // UI Kit compartido
+  'siesa-ui-kit': { singleton: true },
+
+  // Router y Query
+  '@tanstack/react-router': { singleton: true },
+  '@tanstack/react-query': { singleton: true },
+
+  // State management
+  'zustand': { singleton: true },
+
+  // i18n
+  'react-i18next': { singleton: true },
+  'i18next': { singleton: true },
+}
+```
+
+---
+
+## 6. Checklist de Configuración
+
+### MFE Single-SPA (DEFAULT)
+
+- [ ] `vite-plugin-single-spa` instalado y configurado
+- [ ] `single-spa-react` instalado
+- [ ] `src/spa.tsx` con lifecycles exportados
+- [ ] `cssLifecycleFactory` configurado para CSS isolation
+- [ ] `errorBoundary` implementado
+- [ ] **`domElementGetter` apuntando a `#single-spa-application`** ⚠️ CRÍTICO
+- [ ] Puerto único configurado
+- [ ] `base` configurado con prefijo (ej: `/finance/`)
+- [ ] Todas las rutas usan el prefijo
+- [ ] `cors: true` en server
+- [ ] `src/main.tsx` para desarrollo standalone
+
+### Módulo Federable (SOLO si explícitamente requerido)
+
+- [ ] `@module-federation/vite` instalado
+- [ ] `name` único en federation config
+- [ ] `filename: 'remoteEntry.js'`
+- [ ] `exposes` con componentes/utilidades a compartir
+- [ ] `shared` con React y dependencias como singleton
+- [ ] Puerto único (rango 3010+)
+- [ ] `cors: true` en server
+- [ ] `modulePreload: false` en build
+- [ ] `cssCodeSplit: false` en build
+- [ ] Tipos declarados en consumidores
+
+### App Shell
+
+- [ ] `single-spa` instalado
+- [ ] Import map con React y dependencias compartidas
+- [ ] `registerApplication` para cada MFE
+- [ ] `start()` llamado después de registrar
+- [ ] `customProps` con contexto compartido (i18n, auth, eventBus)
+- [ ] **Contenedor `<div id="single-spa-application">` en el layout** ⚠️ CRÍTICO para MFEs
+
+---
+
+## 7. Beneficios de Single-SPA como Default
+
+| Aspecto | Single-SPA | Module Federation |
+|---------|------------|-------------------|
+| **Aislamiento** | ✅ Completo (CSS, JS, lifecycle) | ⚠️ Parcial |
+| **Hot Reload** | ✅ Funciona bien | ⚠️ Problemas conocidos |
+| **CSS Isolation** | ✅ `cssLifecycleFactory` automático | ⚠️ Manual |
+| **Error Boundaries** | ✅ Built-in | ⚠️ Manual |
+| **Mount/Unmount** | ✅ Lifecycle completo | ⚠️ Solo lazy load |
+| **Complejidad** | ✅ Baja | ⚠️ Alta |
+| **Sharing código** | ⚠️ Via import maps | ✅ Nativo |
+
+---
+
+## 8. Referencias
+
+- [Single-SPA Documentation](https://single-spa.js.org/)
+- [single-spa-react](https://single-spa.js.org/docs/ecosystem-react/)
+- [vite-plugin-single-spa](https://github.com/nickt/vite-plugin-single-spa)
+- [Module Federation](https://module-federation.io/)
+- [Vite Documentation](https://vitejs.dev/)

package/bmad/bmm/workflows/4-implementation/code-review/steps/step-07-commit-push.md

@@ -1,6 +1,6 @@
 ---
 name: 'step-07-commit-push'
-description: 'Safely commit and push verified code to the repository'
+description: 'Safely commit and push verified code following centralized GitFlow guidelines'
 
 # Path Definitions
 workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/code-review'
@@ -12,24 +12,38 @@ outputFile: '{output_folder}/review-{story_key}.md'
 
 # Data References
 sprint_status_file: '{implementation_artifacts}/sprint-status.yaml'
-epicsFile: '{output_folder}/planning-artifacts/epics.md'
+
+# Centralized GitFlow Guidelines
+gitFlowGuide: '{project-root}/_bmad/bmm/data/git-flow-siesa.md'
 ---
 
 # Step 7: Commit & Push
 
 ## STEP GOAL:
-To securely persist the verified and approved code changes to the repository by validating the development branch and performing a git commit and push operation.
+
+To securely persist the verified and approved code changes to the repository following the **centralized GitFlow guidelines** defined in `{gitFlowGuide}`.
 
 ## MANDATORY EXECUTION RULES:
+
+- 📖 **LOAD AND READ** `{gitFlowGuide}` before any Git operation
 - 🛑 ONLY execute if the story status is explicitly 'done' or 'completed'
-- 🌳 Ensure development is on the correct `Feature/{Epic_Name}` branch
-- 📝 Commit messages must follow the standard format: "feat: implementation for story {{story_key}}"
+- 🌳 Ensure development branch follows the naming convention from the centralized guide
+- 📝 Commit messages must follow the standard from `{gitFlowGuide}` (Conventional Commits)
 
 ## Sequence of Instructions
 
-### 1. Verification of Status
+### 1. Load GitFlow Guidelines
+
+<action>
+1. Load and read the entire file at `{gitFlowGuide}`.
+2. Extract and apply:
+   - **Commit Message Format**: From Section 3 (Conventional Commits)
+   - **Governance Rules**: From Section 4 (lowercase, protected branches)
+</action>
 
-**Goal**: ensure we are authorized to push code.
+### 2. Verification of Status
+
+**Goal**: Ensure we are authorized to push code.
 
 <action>
 1. Load `{sprint_status_file}`.
@@ -45,58 +59,56 @@ To securely persist the verified and approved code changes to the repository by
   <action>STOP execution. Do NOT run git commands.</action>
 </check>
 
-### 2. Branch Validation
+### 3. Branch Validation
 
-**Goal**: Ensure code is committed to the correct Epic feature branch.
+**Goal**: Ensure code is committed to the correct branch per GitFlow guidelines.
 
 <check if="status == 'done' OR status == 'completed'">
 
   <action>
-  1. Extract **Epic ID** from `{{story_key}}` (first number, e.g., '1' from '1-2-user-auth').
-  2. Load and read `{epicsFile}`.
-  3. Find the header matching `### Epic {Epic_ID}:`.
-  4. Extract the Epic Name (e.g., "Project Foundation").
-  5. Sanitize Epic Name (Pascal/Kebab case, replacing spaces with dashes: "Project-Foundation").
-  6. Construct `target_branch` = `Feature/{Sanitized_Epic_Name}`.
+  1. Run `git branch --show-current` to get `current_branch`.
+  2. Validate the branch follows the naming convention from `{gitFlowGuide}`:
+     - Pattern: `{parent}-{team}-{owner}-{rq}-{description}`
+     - Must be lowercase
+     - Must NOT be `main` or `develop` (protected branches)
   </action>
 
-  <action>Run command `git branch --show-current` to get `current_branch`.</action>
-
-  <check if="current_branch != target_branch">
-      <output>🔄 Switching branches (Current: {{current_branch}} -> Target: {{target_branch}})...</output>
-
-      <action>Check if target branch exists: `git branch --list {{target_branch}}`.</action>
-
-      <if condition="branch exists">
-          <action>Run `git checkout {{target_branch}}`.</action>
-          <output>✅ Switched to existing branch: {{target_branch}}</output>
-      </if>
-
-      <if condition="branch does NOT exist">
-          <action>Run `git checkout -b {{target_branch}}`.</action>
-          <output>✨ Created and switched to new branch: {{target_branch}}</output>
-      </if>
+  <check if="current_branch == 'main' OR current_branch == 'develop'">
+      <output>
+      🛑 **COMMIT BLOCKED**: Cannot commit directly to protected branch '{{current_branch}}'.
+      Per GitFlow guidelines, please switch to your feature branch first.
+      </output>
+      <action>STOP execution.</action>
   </check>
 
-  <check if="current_branch == target_branch">
-      <output>✅ Already on correct branch: {{target_branch}}</output>
+  <check if="branch naming is valid">
+      <output>✅ Branch '{{current_branch}}' follows GitFlow naming convention.</output>
   </check>
 
 </check>
 
-### 3. Git Operations
+### 4. Git Operations
 
-**Goal**: Persist changes.
+**Goal**: Persist changes following commit standards from `{gitFlowGuide}`.
 
 <check if="status == 'done' OR status == 'completed'">
 
   1. **Stage Changes**:
      <action>Run command `git add .`</action>
 
-  2. **User Confirmation**:
+  2. **Construct Commit Message**:
+     <action>
+     Per Section 3 of `{gitFlowGuide}`, use Conventional Commits format:
+     - For features: `feat: {description}`
+     - For fixes: `fix: {description}`
+
+     Derive type from story context and construct message.
+     </action>
+
+  3. **User Confirmation**:
      <output>
      READY TO COMMIT:
-     - Branch: {{target_branch}}
+     - Branch: {{current_branch}}
      - Message: "feat: implementation for story {{story_key}}"
 
      Do you want to proceed with the commit and push?
@@ -116,43 +128,45 @@ To securely persist the verified and approved code changes to the repository by
        </if>
      </logic>
 
-  3. **Commit Changes**:
+  4. **Commit Changes**:
      <action>Run command `git commit -m "feat: implementation for story {{story_key}}"`</action>
      <check if="Commit failed (no changes?)">
         <output>ℹ️ No changes to commit.</output>
      </check>
 
-  4. **Push to Remote**:
+  5. **Push to Remote**:
      <action>
-     1. Identify current branch (should be {{target_branch}} now): `git branch --show-current`
-     2. Push: `git push origin {{target_branch}}`
+     1. Get current branch: `git branch --show-current`
+     2. Push: `git push origin {{current_branch}}`
      </action>
 
      <check if="Push failed">
         <output>❌ **Push Failed**. Please check your network or permissions and try pushing manually.</output>
      </check>
      <check if="Push success">
-        <output>✅ **Success**: Code pushed to origin.</output>
+        <output>✅ **Success**: Code pushed to origin/{{current_branch}}.</output>
      </check>
 
 </check>
 
-### 4. Final Logging
+### 5. Final Logging
 
 <action>Append to `{outputFile}`:</action>
 <template-output>
 ## Repository Sync
-- **Branch**: {{target_branch}}
+- **Branch**: {{current_branch}}
 - **Commit**: [Performed/Skipped]
 - **Push**: [Performed/Skipped]
+- **GitFlow Compliance**: ✅ Verified against `{gitFlowGuide}`
 - **Status**: Workflow Completed Successfully
 </template-output>
 
-### 5. Workflow Completion
+### 6. Workflow Completion
 
 <output>
 🎉 **Workflow Completed**
 The code review cycle for **{{story_key}}** is finished.
+All Git operations followed the centralized GitFlow guidelines.
 </output>
 
 <action>Update frontmatter of `{outputFile}`: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`</action>

package/bmad/bmm/workflows/4-implementation/dev-story/steps/step-02-check-branch.md

@@ -1,6 +1,6 @@
 ---
 name: 'step-02-check-branch'
-description: 'Validate and enforce Git branch naming convention'
+description: 'Validate and enforce Git branch naming convention per centralized GitFlow guidelines'
 
 # Path Definitions
 workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/dev-story'
@@ -8,67 +8,101 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/dev-story'
 # File References
 thisStepFile: '{workflow_path}/steps/step-02-check-branch.md'
 nextStepFile: '{workflow_path}/steps/step-03-load-context.md'
-epicsFile: '{output_folder}/planning-artifacts/epics.md'
+
+# Centralized GitFlow Guidelines
+gitFlowGuide: '{project-root}/_bmad/bmm/data/git-flow-siesa.md'
 ---
 
 # Step 2: Git Branch Validation
 
 ## STEP GOAL:
 
-Ensure development occurs on the correct feature branch (`Feature/{Epic_Name}`) corresponding to the selected story's Epic.
+Ensure development occurs on the correct feature branch following the **centralized GitFlow guidelines** defined in `{gitFlowGuide}`.
 
 ## MANDATORY EXECUTION RULES:
 
+- 📖 **LOAD AND READ** `{gitFlowGuide}` before any Git operation
 - 🛑 NEVER start development on `main` or `develop` directly
-- 📖 Read `epics.md` to resolve Epic names
-- 🔄 Create or checkout the branch automatically
+- 🔄 Follow the branch naming convention from the centralized guide
 
 ## EXECUTION PROTOCOLS:
 
-### 1. Identify Epic
+### 1. Load GitFlow Guidelines
+
+<action>
+1. Load and read the entire file at `{gitFlowGuide}`.
+2. Extract and store the following rules:
+   - **Parent Branch**: The required source branch for features (Section 1)
+   - **Branch Naming Format**: The naming convention pattern (Section 2)
+   - **Commit Standards**: The message format requirements (Section 3)
+   - **Governance Rules**: Protection and naming constraints (Section 4)
+</action>
+
+### 2. Validate Parent Branch
+
+<action>
+1. Run `git branch --show-current` to get `current_branch`.
+2. Per the GitFlow guide, validate that you are on or can branch from `develop`.
+3. If not on `develop`:
+   - Run `git checkout develop && git pull origin develop`
+   - Confirm no pending changes before branching
+</action>
+
+### 3. Gather Branch Parameters
+
+<action>
+Per the naming format in `{gitFlowGuide}` (`rama-padre-team-owner-rq-descripcion`), gather:
+
+1. **Parent Branch**: `develop` (fixed per guidelines)
+2. **Team**: Ask user or derive from project context
+3. **Owner**: Ask user or derive from git config (`git config user.email`)
+4. **RQ**: Extract from story metadata or ask user for requirement number
+5. **Description**: Derive from story name, sanitized (lowercase, hyphens)
+</action>
 
-Using the `story_key` identified in Step 1 (e.g., `1-2-user-auth`):
+<output>
+To create the branch, I need the following information per GitFlow guidelines:
+- **Team prefix**: (e.g., `legacy-erp-nomina`, `platform`, etc.)
+- **RQ number**: (requirement/ticket number)
 
-1.  Extract the **Epic ID** (the first number).
-    *   Example: `1-2-user-auth` -> Epic ID = `1`.
-2.  Load and read `{epicsFile}`.
-3.  Find the Epic section matching this ID (e.g., `### Epic 1: Project Foundation & Configuration`).
-4.  Extract the **Epic Name** (e.g., `Project Foundation & Configuration`).
+The owner will be derived from your git config, and the description from the story.
+</output>
 
-### 2. Construct Branch Name
+### 4. Construct Branch Name
 
-1.  Sanitize the Epic Name to create a valid Git branch name:
-    *   Replace spaces with dashes `-`.
-    *   Remove special characters.
-    *   Use PascalCase or Kebab-Case as per project standard (Default to `Feature/Epic-Name-Sanitized`).
-    *   Example: `Feature/Project-Foundation-Configuration`.
+<action>
+1. Build branch name following the pattern from `{gitFlowGuide}`:
+   `{parent}-{team}-{owner}-{rq}-{description}`
 
-### 3. Check Current Branch
+2. Apply governance rules from Section 4:
+   - All lowercase
+   - No special characters
+   - Hyphens as separators
 
-1.  Run `git branch --show-current`.
-2.  Compare current branch with constructed `target_branch`.
+Example: `develop-legacy-erp-nomina-gaduranb-rq1234-nueva-interfaz`
+</action>
 
-### 4. Enforce Branch
+### 5. Check and Create/Switch Branch
 
 **IF Current Branch == Target Branch:**
--   Output: `✅ Already on correct branch: {{target_branch}}`
--   Proceed to Next Step.
+- Output: `✅ Already on correct branch: {{target_branch}}`
+- Proceed to Next Step.
 
 **IF Current Branch != Target Branch:**
-1.  Check if `target_branch` exists: `git branch --list {{target_branch}}`.
-2.  **IF Exists:**
-    *   Run `git checkout {{target_branch}}`.
-    *   Output: `🔄 Switched to existing branch: {{target_branch}}`.
-3.  **IF Not Exists:**
-    *   Run `git checkout -b {{target_branch}}`.
-    *   Output: `✨ Created and switched to new branch: {{target_branch}}`.
+1. Check if `target_branch` exists: `git branch --list {{target_branch}}`.
+2. **IF Exists:**
+   - Run `git checkout {{target_branch}}`.
+   - Output: `🔄 Switched to existing branch: {{target_branch}}`.
+3. **IF Not Exists:**
+   - Run `git checkout -b {{target_branch}}`.
+   - Output: `✨ Created and switched to new branch: {{target_branch}}`.
 
-### 5. Validation Fallback
+### 6. Store Branch Context
 
-If `epics.md` is missing or Epic cannot be identified:
-1.  Ask user: "Could not detect Epic name for Story {{story_key}}. Please provide the target branch name or Epic name."
-2.  Wait for input and create/switch manually.
+<action>
+Store `target_branch` in workflow context for use in subsequent steps (commit, push).
+</action>
 
-### 6. Next Step
+### 7. Next Step
 
 Load, read entire file, then execute `{nextStepFile}` (`step-03-load-context.md`).

package/bmad/bmm/workflows/generate-project-context/steps/step-01-discover.md

@@ -65,6 +65,7 @@ Check for and load company-specific technology standards:
 - `frontend-standards.md` - Frontend development patterns
 - `architecture-patterns.md` - Architectural decision patterns
 - `technical-preferences-ux.md` - UX/UI preferences
+- `vite-config-standard.md` - Vite Config Standard
 
 **Priority Rules:**
 
@@ -79,7 +80,7 @@ When loading company standards, specifically look for and highlight:
 - 🔴 **siesa-ui-kit requirement** - Must check siesa-ui-kit before creating components
 - 🔴 **Spanish UI text** - All user-facing text must be in Spanish
 - 🔴 **DateTimeOffset** - Use DateTimeOffset not DateTime for PostgreSQL
-- Technology stack versions (.NET 10, Vite 6+, etc.)
+- Technology stack versions (.NET 10, Vite 7+, etc.)
 
 Report: "✅ Estándares corporativos cargados: {count} archivos con {rules_count} reglas críticas"
 

package/package.json

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