@saulwade/swl-ses 1.0.0

package/habilidades/build-errors-cpp/SKILL.md

@@ -0,0 +1,270 @@
+---
+name: build-errors-cpp
+description: >
+  Resolución de errores de compilación C++: g++/clang++, CMake, linker y
+  templates. Incluye errores de ODR, ABI compatibility, headers no encontrados
+  y mensajes de instanciación de templates.
+  Cargar cuando un build C++ falle o haya errores de compilación o linkeo.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep]
+exclusiones:
+  - "No cargar para errores de runtime C++ (segfaults, memory leaks detectados en ejecución) — esos requieren herramientas como Valgrind, AddressSanitizer o GDB; no son errores de compilación."
+  - "No cargar para diseñar la arquitectura del sistema de build CMake desde cero — si la pregunta es cómo estructurar un proyecto C++ multi-módulo con CMake, eso es diseño de proyecto, no diagnóstico de error."
+  - "No cargar para errores de tests unitarios C++ (GoogleTest, Catch2 fallando) cuando el código ya compila — si `cmake --build` pasa pero los tests fallan en lógica, es un error de lógica, no de build."
+  - "No cargar para configurar cross-compilation desde cero — elegir el toolchain file de CMake para ARM/WASM es configuración de entorno, no diagnóstico de error de compilación."
+evolvable: true  # default para skill estandar
+---
+# Build Errors C++ — Diagnóstico y Solución
+
+## Cuándo NO cargar
+
+- El programa compila pero falla en ejecución (segfault, UB, leak) — esos son errores de runtime; usar Valgrind, ASAN o GDB.
+- La pregunta es cómo estructurar un proyecto CMake con múltiples módulos — eso es diseño de proyecto, no diagnóstico.
+- Los tests fallan en lógica (assertion failure) aunque el build pasa — no es un error de compilación.
+
+## Cuándo cargar
+
+- `g++`, `clang++` o `cmake --build` falla con errores del compilador
+- Errores de linker (`undefined reference`, `multiple definition`)
+- Mensajes de error de instanciación de templates (ilegibles por defecto)
+- CMake no encuentra paquetes (`find_package` falla) o targets
+- Errores de ODR (One Definition Rule) o incompatibilidad de ABI
+- Headers no encontrados (`No such file or directory`)
+
+---
+
+## Compilador — Errores Más Frecuentes
+
+### `undefined reference to X` (linker, no compilador)
+
+**Causa**: el símbolo existe en la declaración (header) pero no se linka la librería
+que contiene la implementación.
+
+```cmake
+# MAL — compilar sin linkear la libreria
+add_executable(mi_app main.cpp)
+# Si main.cpp usa pthread, math.h, etc.: falta linkear
+
+# BIEN — linkear las librerias necesarias
+add_executable(mi_app main.cpp)
+target_link_libraries(mi_app PRIVATE pthread m)
+
+# Para librerias del sistema encontradas con find_package:
+find_package(OpenSSL REQUIRED)
+target_link_libraries(mi_app PRIVATE OpenSSL::SSL OpenSSL::Crypto)
+```
+
+### `no matching function for call to X`
+
+**Causa**: no existe ninguna sobrecarga de la función que coincida con los argumentos.
+
+```cpp
+// MAL
+void procesar(int valor) { }
+void procesar(std::string texto) { }
+
+procesar(3.14);  // error: double no convierte a int ni string sin conversión explícita
+
+// BIEN — conversión explícita o nueva sobrecarga
+procesar(static_cast<int>(3.14));
+procesar(std::to_string(3.14));
+
+// MAL — pasar const ref donde se espera referencia mutable
+void modificar(std::vector<int>& v) { v.push_back(1); }
+const std::vector<int> datos = {1, 2, 3};
+modificar(datos);  // error: no puede pasar const como non-const ref
+
+// BIEN — revisar si la función debe ser const o los datos no deben serlo
+void modificar(const std::vector<int>& v);  // si no modifica
+```
+
+### `use of undeclared identifier X`
+
+**Causa**: header no incluido, nombre en namespace no calificado, o error tipográfico.
+
+```cpp
+// MAL
+int main() {
+    cout << "hola" << endl;  // error: cout no declarado sin using o std::
+    vector<int> v;            // error: vector no declarado
+}
+
+// BIEN
+#include <iostream>
+#include <vector>
+
+int main() {
+    std::cout << "hola" << std::endl;
+    std::vector<int> v;
+}
+```
+
+---
+
+## Templates — Descifrar Mensajes de Error
+
+Los errores de templates son notorios por su verbosidad. Estrategia de lectura:
+
+```
+Regla: leer el ULTIMO bloque del error, no el primero.
+El primer bloque es la cadena de instanciacion.
+El ultimo bloque es el error real.
+```
+
+```cpp
+// MAL — pasar tipo incorrecto a template con requisito implicito
+template<typename T>
+void ordenar(T& contenedor) {
+    std::sort(contenedor.begin(), contenedor.end());
+}
+
+std::list<int> lista = {3, 1, 2};
+ordenar(lista);  // error gigante: list no tiene random access iterators
+
+// BIEN — agregar concepto/constraint en C++20
+#include <concepts>
+template<std::ranges::random_access_range T>
+void ordenar(T& contenedor) {
+    std::sort(contenedor.begin(), contenedor.end());
+}
+// Ahora el error es claro: "std::list does not satisfy random_access_range"
+```
+
+### Errores de implementación de templates en headers
+
+```cpp
+// MAL — implementación de template en .cpp (no se instancia en otros .cpp)
+// mi_template.h
+template<typename T>
+class Contenedor {
+    T valor;
+public:
+    T obtener();
+};
+
+// mi_template.cpp — PROBLEMA: nadie mas puede instanciar esto
+template<typename T>
+T Contenedor<T>::obtener() { return valor; }
+
+// BIEN — implementación de templates SIEMPRE en el header o en .hpp incluido al final
+// mi_template.h
+template<typename T>
+class Contenedor {
+    T valor;
+public:
+    T obtener() { return valor; }  // definicion en el header
+};
+```
+
+---
+
+## CMake — Errores de Configuración
+
+### `find_package(X REQUIRED) could not find X`
+
+**Causa**: la librería no está instalada o CMake no sabe dónde buscarla.
+
+```cmake
+# Diagnostico: agregar HINTS o CMAKE_PREFIX_PATH
+find_package(Boost REQUIRED COMPONENTS filesystem)
+# Si falla, buscar con:
+# cmake --find-package -DNAME=Boost -DCOMPILER_ID=GNU -DLANGUAGE=CXX -DMODE=EXIST
+
+# SOLUCION: indicar el prefijo de instalacion
+cmake -DCMAKE_PREFIX_PATH=/usr/local/boost ..
+
+# O en CMakeLists.txt para librerias no estandar:
+list(APPEND CMAKE_PREFIX_PATH "/opt/custom_lib")
+find_package(CustomLib REQUIRED)
+```
+
+### `target X not found`
+
+**Causa**: `target_link_libraries` referencia un target que no existe con ese nombre exacto.
+
+```cmake
+# MAL — nombre de target incorrecto
+find_package(OpenCV REQUIRED)
+target_link_libraries(mi_app PRIVATE opencv)         # no existe
+target_link_libraries(mi_app PRIVATE OpenCV)         # no existe
+target_link_libraries(mi_app PRIVATE OpenCV_LIBS)    # no existe
+
+# BIEN — usar el target namespace correcto del paquete
+target_link_libraries(mi_app PRIVATE ${OpenCV_LIBS})
+# O con targets modernos de CMake:
+target_link_libraries(mi_app PRIVATE opencv_core opencv_imgproc)
+
+# Para ver los targets disponibles de un paquete:
+# cmake --find-package -DNAME=OpenCV -DMODE=COMPILE -DLANGUAGE=CXX -DCOMPILER_ID=GNU
+```
+
+---
+
+## Linker — Errores Avanzados
+
+### `multiple definition of X`
+
+**Causa**: ODR violation — un símbolo definido en un header incluido en múltiples .cpp.
+
+```cpp
+// MAL — definición (no solo declaración) en header incluido en múltiples TUs
+// utils.h
+int calcular(int x) { return x * 2; }  // DEFINICION en header
+
+// BIEN — opción 1: declarar en header, definir en .cpp
+// utils.h
+int calcular(int x);  // solo declaración
+
+// utils.cpp
+int calcular(int x) { return x * 2; }
+
+// BIEN — opción 2: inline para definiciones en headers
+// utils.h
+inline int calcular(int x) { return x * 2; }
+
+// BIEN — opción 3: static para limitar a la TU (si es intencional)
+// utils.h
+static int calcular(int x) { return x * 2; }
+```
+
+### ABI incompatibility — símbolos raros en errores de linker
+
+```bash
+# Sintoma: undefined reference con nombres mangleados como:
+# _ZN3Foo3barEv  (C++ mangled name)
+# vs
+# _foo_bar       (C mangled name)
+
+# Causa: mezclar C y C++ sin extern "C"
+# En el header de la libreria C:
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+void funcion_c(int param);
+
+#ifdef __cplusplus
+}
+#endif
+```
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **El último bloque del error de template es lo relevante, pero los desarrolladores leen el primero**: con errores de instanciación de templates, g++ imprime una cadena de "required from" de decenas de líneas antes del error real. Causa: el error real está al final de la cadena de instanciación. Solución: ir directamente al último bloque del output del compilador — es el lugar exacto donde el constraint se viola, no las invocaciones intermedias.
+- **`-fsanitize=address` no detecta la corrupción de memoria que rompe el build en CI**: el sanitizer detecta la corrupción en runtime pero el bug es un ODR que solo aparece al linkear múltiples TUs. Causa: `nm -C archivo.o | grep símbolo` en dos objetos muestra la misma función definida en ambos, causando `multiple definition`. Solución: compilar con `g++ -fsanitize=address` + `-fsanitize=undefined` en modo debug y buscar el símbolo duplicado con `nm`; la solución es `inline` o mover la implementación al .cpp.
+- **`target_link_libraries(mi_app OpenCV)` falla pero el nombre del paquete es correcto**: CMake exporta targets con namespace (ej: `opencv_core`, no `OpenCV`). Causa: los paquetes modernos de CMake exportan targets como `PkgName::Component`, no el nombre del paquete en mayúsculas. Solución: después de `find_package(OpenCV REQUIRED)` ejecutar `cmake --find-package -DNAME=OpenCV -DMODE=COMPILE -DLANGUAGE=CXX -DCOMPILER_ID=GNU` para ver los targets reales exportados.
+- **Headers en subdirectorio incluidos con path relativo compilan localmente pero fallan en CI**: el CI construye desde un directorio diferente y el path relativo en `#include "../../utils/helper.h"` apunta a otro lugar. Causa: paths relativos en `#include` dependen del directorio de trabajo y de la estructura de `include_directories`. Solución: usar `target_include_directories(mi_app PRIVATE ${CMAKE_SOURCE_DIR}/utils)` y en el .cpp incluir con `#include "helper.h"` sin paths relativos.
+
+## Checklist de Diagnóstico
+
+- [ ] Separar errores del compilador de errores del linker: compilador = fase de traducción, linker = fase de enlace.
+- [ ] Para templates: leer el último bloque del error, ignorar la cadena de instanciación inicial.
+- [ ] `g++ -v` o `clang++ -v` para ver flags exactos que se pasan al compilador.
+- [ ] `nm -C archivo.o | grep simbolo` para verificar si un símbolo está en el objeto.
+- [ ] `cmake --build . --verbose` para ver los comandos exactos de compilación.
+- [ ] Usar `-fdiagnostics-color=always` para mensajes de error más legibles.
+- [ ] Para ODR: compilar con `-fsanitize=address` y `-fno-inline` puede revelar violaciones.
+- [ ] `c++filt _ZN3Foo3barEv` para demanglear símbolos de C++ en errores de linker.
+- [ ] Verificar que todos los .cpp del proyecto están incluidos en `CMakeLists.txt`.

package/habilidades/build-errors-csharp/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: build-errors-csharp
+description: >
+  Resolución de errores de compilación C#: dotnet build, MSBuild, NuGet y
+  Roslyn. Cubre errores CS comunes, conflictos de versiones NuGet, nullable
+  reference types y errores de publicación.
+  Cargar cuando un build .NET falle o haya errores de compilación C#.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep]
+exclusiones:
+  - "No cargar para errores de ASP.NET Core en runtime (middleware, DI, startup) cuando el build compila — si `dotnet build` pasa pero `dotnet run` falla con excepciones de DI, es un error de configuración de la aplicación."
+  - "No cargar para fallos de tests MSTest/NUnit/xUnit en assertions aunque el build compile — si el build pasa pero los tests fallan por valores incorrectos, es un error de lógica de tests."
+  - "No cargar para diseñar la estructura de solución .NET multi-proyecto desde cero — si la pregunta es cómo organizar proyectos, capas y referencias en una solución, cargar `csharp-patrones` o `csharp-experto`."
+  - "No cargar para warnings de analyzer que son informativos y no bloquean el build — solo cargar cuando CS#### o NETSDK#### bloquea la compilación."
+evolvable: true  # default para skill estandar
+---
+# Build Errors C# — Diagnóstico y Solución
+
+## Cuándo NO cargar
+
+- `dotnet build` pasa pero `dotnet run` lanza excepciones de DI o startup — es un error de configuración de la aplicación, no de compilación.
+- Los tests xUnit/NUnit fallan en assertions aunque compilan — es un error de lógica de tests.
+- La pregunta es cómo organizar solución y proyectos — para diseño de solución cargar `csharp-patrones`.
+
+## Cuándo cargar
+
+- `dotnet build` o `dotnet publish` falla con errores CS o MSBuild
+- Conflictos de versión de paquetes NuGet (NU1605, NU1701)
+- Errores de nullable reference types (CS8600, CS8602, CS8603)
+- Errores de restauración de paquetes en CI
+- Problemas de multi-targeting o framework compatibility
+- Warnings de Roslyn analyzers que bloquean el build
+
+---
+
+## Errores CS Frecuentes del Compilador Roslyn
+
+### CS0103 — El nombre no existe en el contexto actual
+
+**Causa**: variable, tipo o namespace no importado o mal escrito.
+
+```csharp
+// MAL
+var lista = new List<string>();
+lista.Add("uno");
+Console.WriteLine(lista.Count());  // error: Count() no existe sin using System.Linq
+
+// BIEN — agregar el using necesario
+using System.Linq;
+// ...
+Console.WriteLine(lista.Count);   // propiedad, no método, para ICollection
+```
+
+### CS0029 — No se puede convertir implícitamente
+
+**Causa**: asignación entre tipos incompatibles sin cast explícito.
+
+```csharp
+// MAL
+int numero = "42";        // string no convierte a int implicitamente
+double precio = 9.99m;   // decimal no convierte a double implicitamente
+
+// BIEN
+int numero = int.Parse("42");          // conversión explícita
+int numero2 = Convert.ToInt32("42");   // alternativa con manejo de null
+double precio = (double)9.99m;         // cast explícito decimal -> double
+```
+
+### CS1061 — El tipo no contiene una definición para el miembro
+
+**Causa**: el tipo no tiene esa propiedad o método, o falta un using de extensión.
+
+```csharp
+// MAL — falta using para metodos de extension LINQ
+List<int> nums = new() { 1, 2, 3 };
+var max = nums.Max();  // error CS1061 si falta using System.Linq
+
+// MAL — typo en nombre de propiedad
+var persona = new Persona();
+Console.WriteLine(persona.Nombr);  // error: debe ser Nombre
+
+// BIEN
+using System.Linq;
+var max = nums.Max();
+```
+
+---
+
+## Nullable Reference Types (C# 8+)
+
+### CS8600 — Asignando null a variable non-nullable
+
+```csharp
+// Habilitado en .csproj: <Nullable>enable</Nullable>
+
+// MAL
+string nombre = GetNombre();  // error si GetNombre() puede retornar null
+
+// BIEN — opcion 1: declarar como nullable
+string? nombre = GetNombre();
+
+// BIEN — opción 2: garantizar no-null con operador de supresión (solo si se está seguro)
+string nombre = GetNombre()!;
+
+// BIEN — opción 3: valor por defecto
+string nombre = GetNombre() ?? string.Empty;
+```
+
+### CS8602 — Dereference posible null
+
+```csharp
+// MAL
+string? texto = ObtenerTexto();
+int longitud = texto.Length;  // error: texto puede ser null
+
+// BIEN — null check antes de acceder
+if (texto is not null)
+{
+    int longitud = texto.Length;
+}
+
+// BIEN — operador null-conditional
+int? longitud = texto?.Length;
+```
+
+### CS8603 — Retorno posible null desde función non-nullable
+
+```csharp
+// MAL
+public string ObtenerNombre(int id)
+{
+    return _db.Usuarios.Find(id)?.Nombre;  // error: puede ser null
+}
+
+// BIEN
+public string? ObtenerNombre(int id)
+{
+    return _db.Usuarios.Find(id)?.Nombre;
+}
+```
+
+---
+
+## MSBuild — Errores NETSDK y de Proyecto
+
+### NETSDK1045 — Target framework no soportado
+
+**Causa**: el SDK instalado no soporta el TFM especificado en el proyecto.
+
+```xml
+<!-- Diagnóstico: dotnet --list-sdks -->
+
+<!-- MAL — usar net9.0 con SDK 6 instalado -->
+<TargetFramework>net9.0</TargetFramework>
+
+<!-- BIEN — usar el TFM soportado por el SDK instalado, o actualizar el SDK -->
+<TargetFramework>net8.0</TargetFramework>
+
+<!-- Para multi-targeting -->
+<TargetFrameworks>net8.0;net6.0</TargetFrameworks>
+```
+
+### NETSDK1138 — Paquete no compatible con target framework
+
+```xml
+<!-- Agregar supresión documentada si la compatibilidad es conocida -->
+<PackageReference Include="SomeLegacyPackage" Version="1.0.0">
+  <NoWarn>NU1701</NoWarn>
+</PackageReference>
+```
+
+---
+
+## NuGet — Conflictos y Restauración
+
+### NU1605 — Paquete degradado por transitive dependency
+
+**Causa**: dos dependencias requieren versiones incompatibles del mismo paquete.
+
+```xml
+<!-- Diagnóstico: dotnet list package --include-transitive -->
+
+<!-- SOLUCIÓN: pinear la versión ganadora explícitamente en el proyecto -->
+<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
+
+<!-- Si el conflicto es entre proyectos de la solución, agregar en Directory.Build.props -->
+<Project>
+  <ItemGroup>
+    <PackageReference Update="Newtonsoft.Json" Version="13.0.3" />
+  </ItemGroup>
+</Project>
+```
+
+### Fallo de restauración en CI — paquetes no encontrados
+
+```bash
+# Causas comunes y diagnostico
+dotnet restore --verbosity detailed 2>&1 | grep -i "error\|not found"
+
+# Si el feed privado falla: verificar NuGet.Config con credenciales
+# Nunca commitear credenciales en NuGet.Config — usar variables de entorno
+dotnet restore --configfile ./NuGet.Config
+
+# Forzar restauracion limpia
+rm -rf ~/.nuget/packages  # Linux/Mac
+dotnet nuget locals all --clear
+dotnet restore
+```
+
+---
+
+## Roslyn Analyzers — Warnings como Errores
+
+### Configuración correcta de TreatWarningsAsErrors
+
+```xml
+<!-- MAL: silenciar todos los warnings en lugar de resolver -->
+<NoWarn>CS8600;CS8602;CS8603</NoWarn>
+
+<!-- BIEN: resolver los warnings o suprimirlos con justificación -->
+<!-- En el código, con razón documentada -->
+#pragma warning disable CS8602 // El null check ocurre en el middleware anterior
+var resultado = _servicio.Procesar();
+#pragma warning restore CS8602
+
+<!-- BIEN en .editorconfig para reglas de estilo (no de correctitud) -->
+dotnet_diagnostic.IDE0028.severity = suggestion  # coleccion init simplificable
+```
+
+---
+
+## Errores de Publicación
+
+### Error al publicar self-contained (RID no encontrado)
+
+```bash
+# MAL — publicar sin especificar RID para self-contained
+dotnet publish -c Release --self-contained
+
+# BIEN — especificar el RID objetivo
+dotnet publish -c Release -r linux-x64 --self-contained true
+dotnet publish -c Release -r win-x64 --self-contained false  # framework-dependent
+
+# RIDs comunes: win-x64, win-x86, linux-x64, linux-arm64, osx-x64, osx-arm64
+```
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **`<Nullable>enable</Nullable>` activado en el proyecto produce 300+ warnings que bloquean CI con TreatWarningsAsErrors**: la migración a nullable contexts no es atómica — activar `enable` en un codebase sin anotaciones existentes genera warnings masivos que se convierten en errores. Causa: C# 8+ nullable analysis requiere que todas las referencias que pueden ser null sean explícitamente anotadas como `T?`. Solución: activar `enable` progresivamente usando `#nullable enable` solo en archivos nuevos o migrados, y `#nullable disable` en archivos legados — no activar en todo el proyecto de golpe.
+- **Conflicto NuGet NU1605 resuelto con `BindingRedirect` que no tiene efecto en .NET Core/5+**: las redirecciones de binding son una característica de .NET Framework; en .NET Core y superiores no aplican. Causa: el desarrollador copió la solución de StackOverflow para .NET Framework y la aplicó a un proyecto .NET 6. Solución: en .NET Core+, usar `<PackageReference Include="X" Version="Y" />` directo con la versión unificada en `Directory.Build.props`, o agregar `<VersionOverride>` en el proyecto hijo.
+- **`dotnet restore` falla en CI con "Unable to load the service index for source"** pero funciona localmente: la URL del NuGet feed privado o el token de autenticación no están configurados en el entorno CI. Causa: localmente hay una credencial almacenada en `~/.nuget/NuGet/NuGet.Config` que no existe en el agente CI. Solución: configurar el feed en `nuget.config` del proyecto con la URL y usar `NUGET_PACKAGES` + credenciales como variables de entorno del CI — no almacenar credenciales en el archivo de config.
+- **Roslyn analyzer genera error CA1416 (platform compatibility) para código que solo corre en Windows pero el target framework es `net8.0`**: sin `[SupportedOSPlatform("windows")]` en el método o clase que llama a la API, el analyzer reporta el error aunque el código esté en un `#if WINDOWS` block. Causa: el analyzer analiza el código sin evaluar las directivas de pre-procesador. Solución: anotar el método con `[SupportedOSPlatform("windows")]` o usar target framework específico de plataforma `net8.0-windows` para el proyecto que contiene ese código.
+
+## Checklist de Diagnóstico
+
+- [ ] Leer el código de error completo (CS#### o NETSDK####) antes de buscar solución.
+- [ ] `dotnet build --verbosity diagnostic` para log completo de MSBuild.
+- [ ] `dotnet list package --outdated` para identificar paquetes desactualizados.
+- [ ] `dotnet list package --include-transitive` para ver árbol de dependencias.
+- [ ] Verificar que `<Nullable>enable</Nullable>` es intencional y el código lo maneja.
+- [ ] En CI: asegurar que la versión del SDK coincide con `global.json` del proyecto.
+- [ ] Para conflictos NuGet: usar `Directory.Build.props` en la raíz de la solución.
+- [ ] `dotnet nuget locals all --clear` si la caché local está corrompida.