# PROBLEMA: Defaults Hardcodeados en Algoritmo de Modularización

**Fecha:** 2025-01-13
**Estado:** 🔴 EN INVESTIGACIÓN
**Prioridad:** ALTA

---

## 📋 CONTEXTO

### Situación Actual

El tema WordPress tiene valores hardcodeados en múltiples archivos:
```
wp-content/themes/apus-theme/
├── *.php      → Valores hardcodeados
├── *.html     → Valores hardcodeados
├── assets/
    ├── css/   → Valores hardcodeados
    └── js/    → Valores hardcodeados
```

### Objetivo del Sistema

El **Admin Panel** debe permitir personalizar la mayoría de valores que actualmente están hardcodeados.

### Sistema de Persistencia Disponible

**✅ Ya existe tabla personalizada:** `wp_apus_theme_components`

**Ubicación:** Base de datos WordPress
**Documentación:** Ver `ANALISIS-ESTRUCTURA-ADMIN.md`

**Estructura:**
```sql
CREATE TABLE wp_apus_theme_components (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    component_name VARCHAR(50) NOT NULL,      -- 'topbar', 'navbar', 'hero', etc.
    config_key VARCHAR(100) NOT NULL,         -- 'message_text', 'bg_color', etc.
    config_value TEXT NOT NULL,               -- Valor del campo
    data_type ENUM('string','integer','boolean','array','json'),
    version VARCHAR(20),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY unique_config (component_name, config_key)
)
```

---

## 🔴 PROBLEMA IDENTIFICADO

### Descripción

El algoritmo de modularización ubicado en:
```
_planeacion/apus-theme/admin-panel-theme/100-modularizacion-admin/00-algoritmo/
```

**❌ PROBLEMA CRÍTICO ENCONTRADO EN PASO 12:**
- El algoritmo instruye crear un objeto `DEFAULT_CONFIG` en JavaScript con TODOS los valores por defecto hardcodeados
- Esto viola el principio de Single Source of Truth
- Los defaults deberían venir de PHP (Settings Manager) vía AJAX, NO estar duplicados en JavaScript

### Evidencia del Problema

**Ubicación:** `00-algoritmo/12-F03-IMPLEMENTACION-IMPLEMENTAR-ADMIN-JS.md`

**Líneas 43-51 y 169-177:**
```javascript
const DEFAULT_CONFIG = {
    enabled: true,
    campo1: 'valor default',
    custom_styles: {
        background_color: '#0E2337',
        // ... todos los campos del PASO 6
    }
};
```

**Líneas 117-129 (método render()):**
```javascript
document.getElementById('topBarIconClass').value = config.icon_class || '';
document.getElementById('topBarShowLink').checked = config.show_link || false;
const bgColorInput = document.getElementById('topBarBgColor');
bgColorInput.value = config.custom_styles?.bg_color || '#000000';  // ← Fallback hardcodeado
```

### Por Qué es un Problema

1. **Duplicación de defaults:**
   - PHP Settings Manager tiene defaults
   - JavaScript TAMBIÉN tiene defaults (duplicado)
   - Tabla DB puede tener defaults (triplicado si se hace seed)

2. **Violación de Single Source of Truth:**
   - Cambiar un default requiere editar JavaScript Y PHP
   - Alto riesgo de inconsistencias

3. **Arquitectura incorrecta:**
   - JavaScript NO debería tener fallbacks porque `get_settings()` de PHP ya hace merge con defaults
   - AJAX siempre retorna datos completos (DB + defaults merged)

---

## ❓ PREGUNTAS PARA INVESTIGACIÓN

### PREGUNTA 1: Ubicación del Problema ✅ RESPONDIDA
**¿En cuál(es) paso(s) del algoritmo se guardan valores en archivos JS?**

- [ ] PASO 1: Crear issue
- [ ] PASO 2: Análisis con Serena
- [ ] PASO 3: Crear estructura de documentación
- [ ] PASO 4: Documentar código real
- [ ] PASO 5: Documentar campos configurables
- [ ] PASO 6: Estructura JSON
- [ ] PASO 7: Documentar código configurable
- [ ] PASO 8: Referencia AJAX
- [ ] PASO 9: Plantilla estructura HTML
- [ ] PASO 10: Ejemplos componentes
- [ ] PASO 11: Ensamblar admin HTML
- [X] **PASO 12: Implementar admin JS** ← ❌ AQUÍ ESTÁ EL PROBLEMA
- [ ] PASO 13: CSS admin panel
- [ ] PASO 14: Git commits
- [ ] PASO 15: Testing
- [ ] PASO 16: Cerrar issue

**✅ Respuesta encontrada:**
- **PASO 12** instruye crear objeto `DEFAULT_CONFIG` en JavaScript con todos los defaults hardcodeados
- **Líneas problemáticas:** 43-51, 169-177, 117-129, 223-229
- **Archivos afectados:** `component-[nombre].js` (uno por cada componente)

---

### PREGUNTA 2: Archivos JS Afectados ✅ RESPONDIDA
**¿Qué archivos JavaScript están siendo modificados con valores hardcodeados?**

Opciones probables:
- [X] `admin/assets/js/admin-app.js` ← Fallbacks en método `render()`
- [X] `admin/assets/js/component-navbar.js` ← Si se siguió PASO 12
- [X] `admin/assets/js/component-*.js` (otros componentes) ← Si se siguió PASO 12
- [ ] Archivos JS del tema (fuera de admin)
- [ ] Otro: _______________

**✅ Respuesta encontrada:**
- **Patrón del algoritmo:** CADA componente debe tener su propio archivo `component-[nombre].js`
- **Cada archivo debe tener:** Objeto `DEFAULT_CONFIG` con todos los defaults
- **Ubicación:** `admin/assets/js/component-*.js`
- **Comprobación en código actual:** `admin-app.js:357` tiene fallback hardcodeado para Top Bar

---

### PREGUNTA 3: Tipo de Valores ✅ RESPONDIDA
**¿Qué tipo de valores por defecto se están guardando en JS?**

Opciones:
- [X] Textos (ej: "Accede a más de 200,000...")
- [X] URLs (ej: "/catalogo")
- [X] Colores (ej: "#0E2337")
- [X] Iconos (ej: "bi bi-megaphone-fill")
- [X] Configuraciones booleanas (ej: enabled: true)
- [X] **Todos los anteriores** ← CORRECTO
- [ ] Otro: _______________

**✅ Respuesta encontrada:**
- Según PASO 12 líneas 169-177, el objeto `DEFAULT_CONFIG` debe contener **TODOS** los campos del PASO 6
- Esto incluye: strings, booleans, URLs, colores (custom_styles), números, selects
- **Ejemplo real encontrado:** `admin-app.js:357` tiene `'Accede a más de 200,000...'` hardcodeado

---

### PREGUNTA 4: Propósito de los Valores en JS ✅ RESPONDIDA
**¿Para qué se usan esos valores hardcodeados en JavaScript?**

Opciones:
- [X] **Fallbacks cuando AJAX no retorna datos** ← USO PRINCIPAL
- [X] Valores iniciales al renderizar formulario
- [ ] Placeholders de campos de formulario
- [ ] Valores de preview/demo
- [ ] No estoy seguro
- [X] **Botón "Reset to Defaults"** ← USO SECUNDARIO

**✅ Respuesta encontrada:**
- **Uso 1 (líneas 117-129):** Fallbacks en método `render()` → `config.field || 'default'`
- **Uso 2 (líneas 196-204):** Botón reset llama `loadConfig(DEFAULT_CONFIG)`
- **Problema:** ❌ Los fallbacks son INNECESARIOS porque Settings Manager ya hace merge con defaults

---

### PREGUNTA 5: Comportamiento Esperado ✅ RESPONDIDA
**¿Cómo DEBERÍAN manejarse los valores por defecto?**

Tu visión:
- [X] Guardar en tabla `wp_apus_theme_components_defaults` (NUEVA tabla, NO la misma)
- [X] Formato: Normalizado - un INSERT por campo (Opción A)
- [X] JavaScript NUNCA debe tener defaults hardcodeados
- [X] JavaScript debe leer defaults vía AJAX desde PHP
- [X] PHP lee de tabla de defaults, NO tiene `get_defaults()` hardcodeado

**✅ Respuesta del usuario:** "opocion A, no debe ser en la msima tabla personalizada wp_apus_theme_components, debe ser en wp_apus_theme_components_defaults"

**Arquitectura definida:**
1. Algoritmo extrae valores hardcodeados → Son los defaults
2. Se insertan en tabla `wp_apus_theme_components_defaults` (un row por campo)
3. Settings Manager lee de tabla de defaults
4. JavaScript NO tiene `DEFAULT_CONFIG`
5. JavaScript lee vía AJAX desde PHP

---

### PREGUNTA 6: Comparación con Sistema Actual ✅ RESPONDIDA
**¿El componente Top Bar (que ya está implementado) tiene este problema?**

Verificación necesaria:
```javascript
// ¿Existe esto en admin-app.js?
topBar.message_text || 'Accede a más de 200,000...'
```

- [X] **SÍ - Top Bar tiene defaults hardcodeados en JS** ← CONFIRMADO
- [ ] NO - Top Bar lee defaults correctamente de PHP
- [ ] NO ESTOY SEGURO

**✅ Respuesta encontrada:**
```javascript
// admin-app.js:357
document.getElementById('topBarMessageText').value = topBar.message_text || 'Accede a más de 200,000...';
```

**Archivos con defaults de Top Bar:**
1. `admin/includes/sanitizers/class-topbar-sanitizer.php` (línea 37)
2. `admin/includes/class-settings-manager.php` (línea 84)
3. `admin/assets/js/admin-app.js` (línea 357)
4. `admin/pages/main.php` (líneas 243-244, 495)
5. `admin/components/component-top-bar.php` (línea 190, 2 veces)
6. `header.php` (línea 34)

**Total:** ❌ 7 lugares con el MISMO valor hardcodeado

---

### PREGUNTA 7: Alcance del Problema ✅ RESPONDIDA
**¿Cuántos componentes están afectados?**

- [X] **Todos los componentes futuros que se modularicen** ← PREOCUPACIÓN PRINCIPAL

**✅ Respuesta:**
- **Actual:** Código existente está MAL implementado - se debe eliminar y rehacer
- **Futuro:** TODOS los componentes que se procesen con el algoritmo PASO 12/14 tendrán el mismo problema
- **Crítico:** Si no se corrige el algoritmo PRIMERO, cada nuevo componente duplicará defaults en JS y PHP

**Acción requerida:**
1. ❌ NO usar código actual como referencia (está mal hecho)
2. ✅ Corregir algoritmo PRIMERO
3. ✅ Limpiar panel de administración (eliminar rastros de componentes mal implementados)
4. ✅ Limpiar tema (eliminar código duplicado)
5. ✅ LUEGO ejecutar algoritmo corregido para cada componente

---

### PREGUNTA 8: Dónde Debe Estar la Única Fuente de Verdad ✅ RESPONDIDA
**¿Dónde deben definirse los defaults UNA SOLA VEZ?**

Tu preferencia:
- [X] **Tabla personalizada `wp_apus_theme_components_defaults`** ← ÚNICA FUENTE DE VERDAD
- [X] Formato normalizado: un row por campo
- [X] Se pobla mediante algoritmo al procesar cada componente
- [ ] ❌ NO en `Settings Manager::get_defaults()` (eliminar método hardcodeado)
- [ ] ❌ NO en JavaScript `DEFAULT_CONFIG` (eliminar objeto hardcodeado)

**✅ Respuesta del usuario:** Nueva tabla `wp_apus_theme_components_defaults` con estructura normalizada

**Flujo correcto:**
```
Algoritmo PASO 2-4
      ↓
Extrae valores hardcodeados del tema
      ↓
INSERT INTO wp_apus_theme_components_defaults
      ↓
Settings Manager lee de tabla
      ↓
JavaScript lee vía AJAX (sin fallbacks)
```

---

## 🎯 OBJETIVO DE LA SOLUCIÓN

Una vez respondidas las preguntas, definiremos:

1. **Modificaciones al algoritmo** - Qué pasos cambiar
2. **Nueva arquitectura de defaults** - Dónde y cómo guardarlos
3. **Plan de migración** - Cómo corregir código existente
4. **Validación** - Cómo verificar que la solución funciona

---

## 📝 CÓMO EL ALGORITMO EXTRAE DEFAULTS (REVISIÓN COMPLETA)

### Flujo Documentado en el Algoritmo

**PASO 2-4: Extraer valores hardcodeados del tema actual**
- Usa Serena MCP para analizar archivos PHP/CSS/JS del tema
- Identifica valores hardcodeados (textos, URLs, colores, iconos)
- Documenta estos valores en `01-DOCUMENTACION-ANALISIS-CODIGO-REAL.md`

**PASO 6: Definir estructura JSON con defaults**
- Toma los valores extraídos en PASO 2-4
- Los define como valores por defecto en estructura JSON
- Colores se extraen del CSS: `background-color: #0E2337` → `custom_styles.background_color: '#0E2337'`

**PASO 14 (Líneas 88-123): Implementar defaults en Settings Manager**
```php
public function get_defaults() {
    return array(
        'version' => APUS_ADMIN_PANEL_VERSION,
        'components' => array(
            'component_name' => array(
                'enabled' => true,
                'field1' => 'Valor por defecto',  // ← Del código hardcodeado actual
                'custom_styles' => array(
                    'background_color' => '#0E2337',  // ← Del CSS original
                    'text_color' => '#ffffff'          // ← Del CSS original
                )
            )
        )
    );
}
```

### ❌ PROBLEMA: Defaults NO se insertan en tabla

**Lo que el algoritmo NO tiene:**
- ❌ Script de inicialización que inserte defaults en `wp_apus_theme_components`
- ❌ Paso que ejecute INSERT en la tabla al activar tema
- ❌ Migrador que convierta defaults de PHP a DB

**Lo que el algoritmo SÍ tiene:**
- ✅ Defaults en PHP (Settings Manager)
- ✅ Settings Manager hace merge: `wp_parse_args($db_data, $defaults)`
- ✅ Cuando tabla está vacía, usa defaults de PHP como fallback

### ✅ ENTENDIMIENTO CORRECTO DEL FLUJO:

**El algoritmo se ejecuta MANUALMENTE componente por componente:**

1. **Ejecutar algoritmo para "Top Bar":**
   - PASO 2-4: Extrae valores hardcodeados actuales de header.php, CSS, JS
   - Estos valores SON los defaults del Top Bar
   - PASO 14: ❌ Los pone en Settings Manager (PHP hardcodeado)
   - PASO 12: ❌ Los pone en JavaScript (DEFAULT_CONFIG hardcodeado)
   - ✅ DEBERÍA: Insertarlos en tabla `wp_apus_theme_components`

2. **Ejecutar algoritmo para "Navbar":**
   - PASO 2-4: Extrae valores hardcodeados actuales del navbar
   - Estos valores SON los defaults del Navbar
   - ✅ DEBERÍA: Insertarlos en tabla `wp_apus_theme_components`

3. **Y así con cada componente...**

### ❌ LO QUE ESTÁ MAL EN EL ALGORITMO:

**PASO 12:** Pone defaults en JavaScript
**PASO 14:** Pone defaults en PHP Settings Manager

**✅ LO QUE DEBERÍA HACER:**

Agregar un NUEVO PASO (o modificar PASO 14) que:
1. Tome los valores extraídos en PASO 2-4
2. Los inserte en `wp_apus_theme_components` con INSERT INTO
3. JavaScript NO tiene defaults hardcodeados
4. PHP lee de tabla, NO tiene `get_defaults()` hardcodeado

## 📝 NOTAS ADICIONALES

_[Espacio para el usuario agregar información adicional]_

---

---

## 📊 RESUMEN EJECUTIVO DE HALLAZGOS

### ✅ Preguntas Respondidas (8 de 8) - INVESTIGACIÓN COMPLETA

| # | Pregunta | Respuesta |
|---|----------|-----------|
| 1 | ¿Dónde está el problema? | **PASO 12 y PASO 14** del algoritmo |
| 2 | ¿Qué archivos JS afectados? | `component-*.js` (uno por componente) |
| 3 | ¿Qué tipo de valores? | **TODOS** (strings, booleans, URLs, colores, etc.) |
| 4 | ¿Para qué se usan? | Fallbacks + Botón Reset |
| 5 | ¿Cómo DEBERÍAN manejarse? | Tabla `wp_apus_theme_components_defaults` normalizada |
| 6 | ¿Top Bar tiene el problema? | **SÍ** - 7 lugares con mismo default |
| 7 | ¿Cuántos componentes afectados? | Top Bar actual + TODOS los futuros |
| 8 | ¿Única fuente de verdad? | Nueva tabla `wp_apus_theme_components_defaults` |

### 🎯 Decisión Arquitectónica Final

**ÚNICA FUENTE DE VERDAD:**
- Tabla: `wp_apus_theme_components_defaults` (nueva)
- Formato: Normalizado (un row por campo)
- Poblamiento: Vía algoritmo al procesar cada componente
- ❌ Eliminar: `DEFAULT_CONFIG` en JavaScript
- ❌ Modificar: `get_defaults()` en PHP para leer de DB

---

## 🗄️ ESTRUCTURA DE NUEVA TABLA DE DEFAULTS

### Tabla: `wp_apus_theme_components_defaults`

**Propósito:** Almacenar valores por defecto extraídos del tema mediante el algoritmo de modularización

**Características:**
- ✅ Estructura normalizada (un row por campo)
- ✅ Misma estructura que `wp_apus_theme_components` para consistencia
- ✅ Se pobla automáticamente al ejecutar algoritmo para cada componente
- ✅ Single source of truth para todos los defaults del sistema

### SQL Schema

```sql
CREATE TABLE IF NOT EXISTS wp_apus_theme_components_defaults (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    component_name VARCHAR(50) NOT NULL COMMENT 'Nombre del componente (top_bar, navbar, hero, etc.)',
    config_key VARCHAR(100) NOT NULL COMMENT 'Clave de configuración (message_text, bg_color, etc.)',
    config_value TEXT NOT NULL COMMENT 'Valor por defecto extraído del tema',
    data_type ENUM('string','integer','boolean','array','json') NOT NULL COMMENT 'Tipo de dato del valor',
    version VARCHAR(20) DEFAULT NULL COMMENT 'Versión del tema cuando se insertó el default',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 'Fecha de creación del registro',
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Última actualización',

    UNIQUE KEY unique_default_config (component_name, config_key),
    INDEX idx_component_name (component_name),
    INDEX idx_config_key (config_key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='Valores por defecto de componentes del tema';
```

### Estructura Genérica de Datos

```sql
-- Estructura GENÉRICA para insertar defaults de CUALQUIER componente
-- Se puebla al ejecutar algoritmo para cada componente

INSERT INTO wp_apus_theme_components_defaults
(component_name, config_key, config_value, data_type, version)
VALUES
-- Campos booleanos
('[component_name]', 'enabled', '[1|0]', 'boolean', '[version]'),
('[component_name]', '[boolean_field]', '[1|0]', 'boolean', '[version]'),

-- Campos de texto (extraídos del código hardcodeado)
('[component_name]', '[text_field]', '[valor_extraído_del_código]', 'string', '[version]'),

-- Campos numéricos
('[component_name]', '[number_field]', '[valor_numérico]', 'integer', '[version]'),

-- Custom styles (extraídos del CSS del componente)
('[component_name]', 'custom_styles.[propiedad_css]', '[valor_del_css]', 'string', '[version]');
```

**Notas:**
- `[component_name]`: Nombre del componente (ej: 'navbar', 'hero', 'footer')
- `[config_key]`: Clave del campo según PASO 6 del algoritmo
- `[config_value]`: Valor extraído del código/CSS actual del tema
- `[data_type]`: Tipo según el campo (string, integer, boolean, array, json)
- `[version]`: Versión del tema al momento de extraer defaults

### Propósito de Cada Tabla

**`wp_apus_theme_components`** (configuraciones personalizadas)
- Se guardan cuando el usuario modifica valores en el Admin Panel
- Si existe config personalizada, se usa esta

**`wp_apus_theme_components_defaults`** (valores por defecto)
- Se pueblan al ejecutar el algoritmo para cada componente
- Se usan SOLO cuando NO existe config personalizada
- Son los valores extraídos del tema actual (hardcodeados)

**Ambas tablas tienen la MISMA estructura** - la diferencia es solo su propósito.

---

## 🔄 FLUJO DE LECTURA DE DATOS

### ¿Por qué se necesitan Settings Manager (PHP) Y JavaScript?

**NO están duplicados - tienen propósitos diferentes:**

#### Settings Manager (PHP)
**Propósito:** Para que archivos PHP del tema lean configuraciones

**Uso:**
```php
// En header.php, footer.php, etc.
$settings_manager = new APUS_Settings_Manager();
$navbar_config = $settings_manager->get_component_config('navbar');

// Usar $navbar_config en el HTML del tema
echo $navbar_config['logo_url'];
```

**Lee de:**
1. Tabla `wp_apus_theme_components` (config personalizada) - PRIORIDAD ALTA
2. Si no existe → Tabla `wp_apus_theme_components_defaults` (defaults)

#### JavaScript + AJAX
**Propósito:** Para que el Admin Panel (interfaz de administración) lea/guarde configuraciones

**Uso:**
```javascript
// En admin-app.js
// Leer configuración vía AJAX
axios.get(ajaxUrl + '?action=get_component_config&component=navbar')
    .then(response => {
        // Renderizar formulario con los datos
        renderForm(response.data);
    });

// Guardar configuración vía AJAX
axios.post(ajaxUrl, formData)
    .then(response => {
        // Mostrar mensaje de éxito
    });
```

**Lee/Escribe vía AJAX a:**
- Endpoint PHP que usa Settings Manager
- Guarda en tabla `wp_apus_theme_components`

### Flujo Completo

```
FRONTEND (tema):
header.php → Settings Manager (PHP) → Lee de DB → Muestra en tema

ADMIN PANEL:
JavaScript → AJAX → Endpoint PHP → Settings Manager → Lee/Escribe DB → Respuesta JSON
```

**Conclusión:** Se necesitan AMBOS porque sirven a partes diferentes del sistema (frontend vs admin).

---

## 🎯 PRÓXIMOS PASOS

### ✅ INVESTIGACIÓN COMPLETA - 8/8 preguntas respondidas

**ORDEN CORRECTO DE IMPLEMENTACIÓN:**

### FASE 1: LIMPIAR CÓDIGO ACTUAL (PRIMERO)

**El código actual está MAL implementado y debe eliminarse ANTES de corregir el algoritmo**

#### 1.1. Limpiar Panel de Administración
**Eliminar completamente cualquier rastro de componentes mal implementados:**
- Eliminar archivos JS de componentes: `admin/assets/js/component-*.js`
- Eliminar archivos CSS de componentes: `admin/assets/css/component-*.css`
- Eliminar archivos PHP de componentes: `admin/components/component-*.php`
- Eliminar sanitizers de componentes: `admin/includes/sanitizers/class-*-sanitizer.php`
- Limpiar `admin/pages/main.php` de secciones de componentes
- Limpiar `admin/includes/class-admin-menu.php` de encolamiento de componentes

#### 1.2. Limpiar Tema
**Eliminar valores hardcodeados duplicados:**
- Revisar `header.php` y eliminar valores duplicados
- Revisar otros archivos del tema con valores hardcodeados
- Dejar SOLO el código original del tema (antes de modularización)

#### 1.3. Limpiar Base de Datos
**Eliminar datos de componentes mal implementados:**
- Vaciar tabla `wp_apus_theme_components` o eliminar componentes específicos
- Preparar para empezar desde cero

---

### FASE 2: CREAR TABLA DE DEFAULTS

#### 2.1. Crear Tabla `wp_apus_theme_components_defaults`
- Ejecutar SQL CREATE TABLE (ver estructura arriba)
- Verificar que tabla existe y tiene estructura correcta

---

### FASE 3: CORREGIR ALGORITMO (DESPUÉS DE LIMPIAR)

#### 3.1. PASO 12: Implementar Admin JS (CORREGIR)
**Archivo:** `00-algoritmo/12-F03-IMPLEMENTACION-IMPLEMENTAR-ADMIN-JS.md`

**Cambios:**
- ❌ **ELIMINAR:** Objeto `DEFAULT_CONFIG` (líneas 43-51, 169-177)
- ❌ **ELIMINAR:** Fallbacks en método `render()` (líneas 117-129)
- ✅ **MODIFICAR:** Botón reset debe llamar endpoint AJAX para leer defaults de DB
- ✅ JavaScript NUNCA tiene valores hardcodeados

#### 3.2. PASO 14: Settings Manager (CORREGIR)
**Archivo:** `00-algoritmo/14-F04-CIERRE-GIT-COMMITS.md`

**Cambios:**
- ❌ **ELIMINAR:** Método `get_defaults()` con array hardcodeado (líneas 88-123)
- ✅ **MODIFICAR:** DB Manager para leer de tabla `_defaults`

#### 3.3. NUEVO PASO: Poblar Tabla de Defaults
**Ubicación:** Después de PASO 7

**Contenido:**
1. Leer valores extraídos en PASO 6 (estructura JSON)
2. Generar script SQL con INSERTs para tabla `wp_apus_theme_components_defaults`
3. Ejecutar script SQL
4. Verificar que defaults están en DB

---

### FASE 4: USAR ALGORITMO CORREGIDO PARA DOCUMENTAR COMPONENTES

**El algoritmo NO implementa código - solo DOCUMENTA**

Una vez el algoritmo esté corregido:

#### 4.1. Ejecutar Algoritmo Completo (16 pasos) para UN Componente
**Ejemplo:** Navbar

**Pasos 1-13: DOCUMENTACIÓN (genera 7 archivos MD)**
- PASO 1: Crear issue en GitHub
- PASO 2-4: Analizar código actual del Navbar (Serena MCP)
- PASO 5-8: Diseñar campos configurables y estructura JSON
- PASO 9-13: Documentar cómo implementar (plantillas, ejemplos, HTML, JS, CSS)

**OUTPUT:** Carpeta `navbar/` con 7 archivos MD de documentación

#### 4.2. PASO 14: Implementar Código Real
**AQUÍ es cuando se modifica código PHP/JS/CSS del tema/admin**

⚠️ **NOTA IMPORTANTE:** El PASO 14 actual del algoritmo tiene el problema que identificamos:
- Instruye crear método `get_defaults()` con array hardcodeado en Settings Manager (líneas 88-123)
- Esto es lo que necesitamos CORREGIR en FASE 3

**Con el algoritmo CORREGIDO**, el PASO 14 debe hacer:

Usando la documentación generada en pasos 1-13:
1. Modificar PHP del tema (ej: `header.php`) según `04-IMPLEMENTACION-COMPONENTE-NAVBAR.md`
2. Agregar HTML admin en `admin/pages/main.php` según `05-IMPLEMENTACION-ADMIN-HTML-NAVBAR.md`
3. Agregar JavaScript en `admin/assets/js/admin-app.js` según `07-IMPLEMENTACION-JS-ESPECIFICO.md`
4. **MODIFICAR DB Manager:** Agregar método para insertar/leer defaults de tabla `wp_apus_theme_components_defaults`
5. **MODIFICAR Settings Manager:** Leer de tabla defaults (NO array hardcodeado)
6. **INSERTAR defaults en DB:** Ejecutar script SQL con valores extraídos en PASO 4
7. Commits por cada archivo modificado

#### 4.3. PASO 15-16: Testing y Cierre
- Testing post-implementación
- Cerrar issue en GitHub

#### 4.4. Repetir para Cada Componente
Una vez completado Navbar (pasos 1-16):
1. Ejecutar algoritmo para siguiente componente (ej: Hero)
2. Generar documentación (pasos 1-13)
3. Implementar código real (paso 14)
4. Testing y cierre (pasos 15-16)

**Componentes del tema a procesar:**
- Navbar
- Hero Section
- Footer
- etc.

---

**Última actualización:** 2025-01-13 - INVESTIGACIÓN COMPLETA - 8/8 preguntas respondidas
**Estado:** 🟢 LISTO PARA IMPLEMENTACIÓN