Nexus - AI Task Orchestrator

31-test-gaps-analysis
Procedimiento: An├ílisis de Gaps de Tests y Creaci├│n

Calidad de Codigo
1 plugin(s)
Titulo
Descripcion
Contenido Markdown
17547 caracteres
# Procedimiento: An├ílisis de Gaps de Tests y Creaci├│n

## Metadata
- **ID**: PROC-31
- **Frecuencia**: Mensual, o al a├▒adir funcionalidad nueva
- **Duraci├│n estimada**: 2-4 horas (an├ílisis) + variable (creaci├│n)
- **Requiere**: Acceso al c├│digo, IDE, conocimiento de la soluci├│n
- **Dependencias**: PROC-04 (ejecutar tests), PROC-06 (si crea tools nuevas)
- **Bloquea**: Nada directamente (mejora calidad)

## Objetivo

Evaluar sistem├íticamente la soluci├│n para detectar tests faltantes, priorizar gaps, y crear tests siguiendo el est├índar del proyecto.

## Principios de Testing (Obligatorios)

| Principio | Descripci├│n |
|-----------|-------------|
| **Claridad sobre exhaustividad** | Un test debe explicar qu├® escenario valida y por qu├® puede fallar |
| **Escenarios, no m├®todos** | Tests como escenarios de negocio (Given/When/Then), no pruebas t├®cnicas |
| **Comportamiento realista** | Probar l├│gica real, mocks solo para dependencias externas |
| **Determinismo** | Mismo resultado siempre, sin depender de orden, hora o entorno |
| **Mockea lo que no controlas** | Mockear APIs externas, ejecutar l├│gica propia |

## Estructura de Tests del Proyecto

```
test/BigCommerceApi.Tests/
Ôö£ÔöÇÔöÇ Mcp/
Ôöé   Ôö£ÔöÇÔöÇ Catalog/                    # Tests de tools de cat├ílogo
Ôöé   Ôö£ÔöÇÔöÇ Orders/                     # Tests de tools de pedidos
Ôöé   Ôö£ÔöÇÔöÇ Pricing/                    # Tests de tools de pricing
Ôöé   Ôö£ÔöÇÔöÇ Sales/                      # Tests de modo comercial
Ôöé   Ôö£ÔöÇÔöÇ Support/                    # Tests de soporte
Ôöé   ÔööÔöÇÔöÇ McpSmokeTests.cs           # Tests de integraci├│n MCP
Ôö£ÔöÇÔöÇ Services/
Ôöé   Ôö£ÔöÇÔöÇ {ServiceName}Tests.cs
Ôö£ÔöÇÔöÇ Shared/
Ôöé   Ôö£ÔöÇÔöÇ TestUserContext.cs          # Factory de contextos
Ôöé   Ôö£ÔöÇÔöÇ TestUsers.cs                # Usuarios conocidos
Ôöé   ÔööÔöÇÔöÇ TestFixtures.cs             # Datos de prueba
ÔööÔöÇÔöÇ SupplierCatalog.Sync.Tests/
    Ôö£ÔöÇÔöÇ Icecat/                     # Tests de pipeline Icecat
    ÔööÔöÇÔöÇ Parsers/                    # Tests de parsers
```

## Checklist Ejecutable

### Fase 1: Inventariar C├│digo Testeable

#### 1.1 Listar MCP Tools

```bash
cd src

# Todas las tools MCP registradas
grep -rn "AddScoped<IMcpTool" src/src/BigCommerceApi/ | \
  sed 's/.*AddScoped<IMcpTool, \([^>]*\)>.*/\1/' | sort | uniq
```

Documentar inventario:

| Tool Class | ├ürea | Tests Existentes | Gap |
|------------|------|------------------|-----|
| ProductsSearchTool | Catalog | S├¡ / No / Parcial | |
| OrdersCreateTool | Orders | S├¡ / No / Parcial | |
| ... | | | |

- [ ] Inventario de tools completado

#### 1.2 Listar Services

```bash
# Servicios con l├│gica de negocio
find src/src/BigCommerceApi/Services -name "*.cs" -exec basename {} .cs \;

# Servicios de SupplierCatalog.Sync
find src/src/SupplierCatalog.Sync -name "*Service.cs" -exec basename {} .cs \;
```

| Service | ├ürea | Tests Existentes | Gap |
|---------|------|------------------|-----|
| OrdersService | Orders | S├¡ / No / Parcial | |
| ... | | | |

- [ ] Inventario de services completado

#### 1.3 Listar Parsers/Handlers cr├¡ticos

```bash
# Handlers, Parsers, Builders
find src/src -name "*Handler*.cs" -o -name "*Parser*.cs" -o -name "*Builder*.cs" | \
  xargs basename -a | sort | uniq
```

- [ ] Inventario de handlers/parsers completado

### Fase 2: Detectar Gaps de Cobertura

#### 2.1 Mapear tests existentes

```bash
# Tests existentes por clase
find test -name "*Tests.cs" -exec basename {} .cs \;

# Ver qu├® clases testean
grep -rn "public class.*Tests" test/ | sed 's/.*class \([^ ]*\).*/\1/'
```

#### 2.2 Identificar c├│digo sin tests

Para cada item del inventario, verificar:

```bash
# ┬┐Existe archivo de test para OrdersCreateTool?
find test -name "*OrdersCreate*Tests*.cs"

# ┬┐Qu├® tests hay para Orders?
grep -rn "OrdersCreate" test/ --include="*.cs" | head -20
```

#### 2.3 Calcular cobertura por ├írea

| ├ürea | Clases Testeables | Con Tests | Cobertura | Prioridad |
|------|-------------------|-----------|-----------|-----------|
| MCP Tools | | | ___% | |
| Orders | | | ___% | |
| Sales | | | ___% | |
| Catalog | | | ___% | |
| Icecat Pipeline | | | ___% | |
| Services | | | ___% | |

**Umbrales m├¡nimos:**
- MCP Tools: ÔëÑ 70%
- Services cr├¡ticos: ÔëÑ 60%
- Parsers: ÔëÑ 80%

- [ ] Gaps identificados
- [ ] Prioridades asignadas

### Fase 3: Priorizar Tests a Crear

#### 3.1 Matriz de priorizaci├│n

```
         Riesgo Alto          Riesgo Bajo
        ÔöîÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔö¼ÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÉ
EsfuerzoÔöé   HACER PRIMERO   Ôöé   HACER DESPU├ëS   Ôöé
Bajo    Ôöé   (Quick wins)    Ôöé                   Ôöé
        Ôö£ÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔö╝ÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöñ
EsfuerzoÔöé   PLANIFICAR      Ôöé   OPCIONAL        Ôöé
Alto    Ôöé   (En sprint)     Ôöé                   Ôöé
        ÔööÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔö┤ÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÇÔöÿ
```

#### 3.2 Factores de riesgo

| Factor | Puntos |
|--------|--------|
| Maneja dinero/pedidos | +3 |
| Expuesto a usuarios finales | +2 |
| L├│gica de negocio compleja | +2 |
| M├║ltiples code paths | +1 |
| Integraciones externas | +1 |
| C├│digo nuevo/reciente | +1 |

**Prioridad = Riesgo / Esfuerzo estimado**

#### 3.3 Top 5 tests a crear

| # | Clase | Test a crear | Riesgo | Esfuerzo | Justificaci├│n |
|---|-------|--------------|--------|----------|---------------|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
| 4 | | | | | |
| 5 | | | | | |

- [ ] Top 5 definido

### Fase 4: Crear Tests (por cada test)

#### 4.1 Estructura de archivo

```csharp
// test/BigCommerceApi.Tests/Mcp/{Area}/{ToolName}Tests.cs

namespace BigCommerceApi.Tests.Mcp.{Area};

public class {ToolName}Tests
{
    // Dependencias mockeadas
    private readonly Mock<IDependency> _dependencyMock;
    private readonly Mock<IHttpContextAccessor> _httpContextMock;

    // System Under Test
    private readonly {ToolName} _sut;

    public {ToolName}Tests()
    {
        _dependencyMock = new Mock<IDependency>();
        _httpContextMock = TestUserContext.CreateHttpContextMock(
            TestUsers.Customer.UseCode,
            TestUsers.Customer.Email
        );

        _sut = new {ToolName}(
            _dependencyMock.Object,
            _httpContextMock.Object
        );
    }

    // Tests aqu├¡...
}
```

#### 4.2 Convenci├│n de nombres (OBLIGATORIA)

```
When{Action}_{Condition}_Should{ExpectedResult}
```

**Ejemplos:**
```csharp
// Happy path
WhenCreatingOrder_WithValidData_ShouldReturnOrderId()

// Error path
WhenCreatingOrder_WithEmptyLineItems_ShouldThrow400()

// Normalization
WhenCreatingOrder_WithLegacyFieldNames_ShouldNormalize()

// Authorization
WhenCreatingOrder_WithoutRequiredScope_ShouldThrow403()
```

#### 4.3 Plantilla de test (Given/Seed/When/Then)

```csharp
[Fact]
public async Task When{Action}_{Condition}_Should{Result}()
{
    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    // GIVEN: Descripci├│n del contexto inicial
    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    var input = JsonSerializer.Deserialize<JsonElement>("""
    {
        "param1": "value1",
        "param2": 123
    }
    """);

    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    // SEED: Setup de mocks y datos
    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    CapturedRequest? captured = null;
    _serviceMock
        .Setup(x => x.DoSomethingAsync(It.IsAny<Request>(), It.IsAny<CancellationToken>()))
        .Callback<Request, CancellationToken>((req, _) => captured = req)
        .ReturnsAsync(new Result { Success = true });

    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    // WHEN: Ejecutar la acci├│n bajo test
    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    var result = await _sut.InvokeAsync("test-api-key", input, CancellationToken.None);

    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    // THEN: Verificar resultado
    // ÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉÔòÉ
    result.Should().NotBeNull();
    captured.Should().NotBeNull();
    captured!.Property.Should().Be(expectedValue);
}
```

#### 4.4 Tests m├¡nimos para MCP Tool (5 obligatorios)

```csharp
// 1. Metadata correcta
[Fact]
public void Name_ShouldBeSnakeCase()
{
    _sut.Name.Should().MatchRegex("^[a-z_]+$");
}

[Fact]
public void RequiredScope_ShouldBe{ExpectedScope}()
{
    _sut.RequiredScope.Should().Be("dmi:{area}:{read|write}");
}

// 2. Happy path
[Fact]
public async Task WhenInvoking_WithValidInput_ShouldReturnExpectedResult()
{
    // ...
}

// 3. Validaci├│n de input requerido
[Fact]
public async Task WhenInvoking_WithMissingRequiredParam_ShouldThrow400()
{
    var input = JsonSerializer.Deserialize<JsonElement>("{}");

    var ex = await Assert.ThrowsAsync<McpToolException>(
        () => _sut.InvokeAsync("key", input, CancellationToken.None));

    ex.StatusCode.Should().Be(400);
}

// 4. L├¡mites de arrays (si aplica)
[Fact]
public async Task WhenInvoking_WithTooManyItems_ShouldThrow400()
{
    var items = Enumerable.Range(0, 101).Select(i => new { id = i }).ToArray();
    var input = JsonSerializer.Deserialize<JsonElement>(
        JsonSerializer.Serialize(new { items }));

    var ex = await Assert.ThrowsAsync<McpToolException>(
        () => _sut.InvokeAsync("key", input, CancellationToken.None));

    ex.StatusCode.Should().Be(400);
    ex.Message.Should().Contain("100");
}

// 5. Error de dependencia (si aplica)
[Fact]
public async Task WhenInvoking_WhenServiceFails_ShouldThrow500()
{
    _serviceMock
        .Setup(x => x.DoSomethingAsync(It.IsAny<Request>(), It.IsAny<CancellationToken>()))
        .ThrowsAsync(new Exception("Service unavailable"));

    var ex = await Assert.ThrowsAsync<McpToolException>(
        () => _sut.InvokeAsync("key", validInput, CancellationToken.None));

    ex.StatusCode.Should().Be(500);
}
```

#### 4.5 Tests adicionales seg├║n tipo de tool

**Para tools de escritura (orders, support):**
```csharp
// Normalizaci├│n de campos legacy
[Theory]
[InlineData("lines", "lineItems")]      // Campo legacy
[InlineData("productCode", "product")]  // Campo legacy
public async Task WhenInvoking_WithLegacyFieldName_ShouldNormalize(...)

// Validaci├│n de datos de negocio
[Fact]
public async Task WhenCreatingOrder_WithInvalidQuantity_ShouldThrow400()
```

**Para tools de Sales Mode:**
```csharp
// Verificar acceso a portfolio
[Fact]
public async Task WhenSearchingCustomers_AsRegularUser_ShouldThrow403()

[Fact]
public async Task WhenSettingActiveCustomer_NotInPortfolio_ShouldThrow403()
```

**Para tools con paginaci├│n:**
```csharp
[Fact]
public async Task WhenSearching_WithPagination_ShouldRespectLimits()

[Fact]
public async Task WhenSearching_WithPageSizeOverMax_ShouldCapToMax()
```

### Fase 5: Verificar y Documentar

#### 5.1 Ejecutar tests nuevos

```bash
# Ejecutar solo los tests nuevos
dotnet test --filter "FullyQualifiedName~{ToolName}Tests"

# Verificar que todos pasan
dotnet test
```

- [ ] Tests nuevos pasan
- [ ] Tests existentes siguen pasando

#### 5.2 Verificar cobertura

```bash
# Con cobertura (si est├í configurado)
dotnet test --collect:"XPlat Code Coverage"

# Ver reporte
# reportgenerator -reports:**/coverage.cobertura.xml -targetdir:coveragereport
```

- [ ] Cobertura mejorada

#### 5.3 Actualizar documentaci├│n

Si se a├▒aden nuevos patrones o fixtures:

```bash
# Actualizar 40-testing.md si hay nuevos patrones
# A├▒adir ejemplos si hay nuevos TestUserContext helpers
```

- [ ] Documentaci├│n actualizada (si aplica)

## Reglas de Mocking

### S├ì mockear (dependencias externas)

```csharp
// Ô£à APIs externas
Mock<IAmaraFastClient>       // Amara ERP
Mock<IIcecatApiClient>       // Icecat API
Mock<IEmailService>          // Env├¡o de emails

// Ô£à Infraestructura
Mock<IHttpContextAccessor>   // HTTP context
Mock<ILogger<T>>             // Logging
```

### NO mockear (l├│gica propia)

```csharp
// ÔØî No mockear l├│gica de negocio
// En lugar de mockear, usar datos reales y verificar resultado

// ÔØî No mockear el SUT
// El System Under Test siempre debe ser la implementaci├│n real

// ÔØî No mockear DTOs/Models
// Usar instancias reales
```

## Datos de Prueba Est├índar

### TestUsers (usar siempre)

```csharp
// Cliente normal
TestUsers.Customer.UseCode    // "CT067070"
TestUsers.Customer.Email      // "ramac21@gmail.com"

// Comercial con m├║ltiples c├│digos
TestUsers.CommercialMultipleCodes.UseCode
TestUsers.CommercialMultipleCodes.Email
TestUsers.CommercialMultipleCodes.AllSalesCodes

// Comercial con un c├│digo
TestUsers.CommercialSingleCode.UseCode
TestUsers.CommercialSingleCode.Email
```

### Fixtures comunes

```csharp
// Direcci├│n v├ílida para pedidos
TestFixtures.ValidShippingAddress

// Producto v├ílido
TestFixtures.ValidProduct

// L├¡nea de pedido v├ílida
TestFixtures.ValidLineItem
```

## Anti-patrones a Evitar

| Anti-patr├│n | Por qu├® es malo | Qu├® hacer |
|-------------|-----------------|-----------|
| Test sin asserts | No valida nada | Siempre usar `.Should()` |
| Mock del SUT | No prueba nada real | Mockear solo dependencias |
| Test que depende de orden | Flaky, no determinista | Cada test independiente |
| Assert m├║ltiples sin relaci├│n | Dif├¡cil saber qu├® fall├│ | Un concepto por test |
| Nombres gen├®ricos | No explica el escenario | `When_Given_Should` |
| Datos hardcodeados | Dif├¡cil mantener | Usar TestFixtures |
| Test que llama a BD real | Lento, no determinista | Usar mocks o InMemory |

## Resultado

- **├ëxito**: Gaps identificados, tests creados, cobertura mejorada
- **Parcial**: Gaps identificados, plan de creaci├│n definido
- **Fallo**: No se pudo analizar ÔåÆ verificar acceso a c├│digo

## Checklist de PR para Tests Nuevos

Antes de hacer merge de tests nuevos:

- [ ] ┬┐Usa patr├│n Given/Seed/When/Then?
- [ ] ┬┐Nombre sigue convenci├│n `When_Condition_Should`?
- [ ] ┬┐Cubre happy path Y error paths?
- [ ] ┬┐Evita mocks innecesarios?
- [ ] ┬┐Usa TestUsers en lugar de strings hardcodeados?
- [ ] ┬┐Es determinista (no depende de hora/orden)?
- [ ] ┬┐Asserts son espec├¡ficos y claros?

## Mensaje de Finalizaci├│n

**IMPORTANTE - ACCI├ôN REQUERIDA AL FINALIZAR:**

Cuando hayas completado todos los pasos de este procedimiento, DEBES ejecutar el siguiente comando usando la herramienta Bash:

Ejecuta: `echo "====== PROCESO TERMINADO [$(date +%H%M%S)] ======" && echo "RESULTADO: X gaps tests identificados, Y tests nuevos creados"`

Sustituye X e Y por los n├║meros reales.


---

## Output Estructurado (Nexus)

Al finalizar, el agente DEBE generar un bloque JSON con el siguiente formato para que Nexus pueda procesarlo automaticamente:

```json
{
  "result": "success",
  "summary": "Ejecucion de PROC-31 completada. [Descripcion breve de resultados]",
  "metrics": {
    "issues_found": 0,
    "issues_resolved": 0,
    "tests_passed": 100, "tests_failed": 0, "coverage_percent": 78,
    "custom": {
      "procedure_specific_metric": "value"
    }
  },
  "backlog_items": [
    {
      "title": "Titulo del item de seguimiento",
      "description": "Descripcion detallada si se requiere accion futura",
      "priority": "medium",
      "type": "improvement",
      "tags": ["proc-31"]
    }
  ],
  "next_steps": [
    "Accion recomendada 1",
    "Accion recomendada 2"
  ],
  "warnings": [
    "Advertencias encontradas durante la ejecucion"
  ]
}
```

**Campos requeridos:**
- `result`: `"success"` | `"partial"` | `"failed"`
- `summary`: Resumen ejecutivo en 1-3 lineas

**Metricas especificas de este procedure:**
- methods_analyzed, methods_untested, test_gap_percent

**Criterios de resultado:**
- `success`: Procedimiento completado sin errores criticos
- `partial`: Completado con algunos problemas menores o items pendientes
- `failed`: Error critico o no se pudo completar

## Historial de Ejecuciones

| Fecha | Gaps Encontrados | Tests Creados | Cobertura Antes | Cobertura Despu├®s |
|-------|------------------|---------------|-----------------|-------------------|
| | | | | |