---
name: rdx-solid
description: Aplica principios SOLID, TDD, código limpio, diseño de software y buenas prácticas de ingeniería al escribir código, implementar funcionalidades, refactorizar, diseñar arquitecturas, revisar código, crear pruebas o depurar errores. Prioriza soluciones correctas, sencillas, mantenibles y coherentes con el proyecto, evitando la sobreingeniería y las abstracciones innecesarias.
---

# rdx-solid · Ingeniería de software

Desarrolla y revisa software con una complejidad proporcional a los requisitos. Este archivo establece el flujo de trabajo y orienta la consulta de las referencias; los criterios técnicos y ejemplos se mantienen en ellas.

## Prioridad y aplicación

- Respeta las instrucciones del usuario, las restricciones del proyecto, su `AGENTS.md` y las herramientas configuradas. Las preferencias de este skill se aplican cuando no exista una convención más específica.
- Preservar la corrección, los contratos, la seguridad y el alcance de la tarea es obligatorio. Comunica cualquier limitación que impida comprobarlo.
- TDD y las preferencias de diseño son adaptables al contexto. Las métricas, la regla de tres y los patrones son heurísticas, no requisitos numéricos ni motivos para introducir abstracciones.
- Una excepción relevante debe tener una justificación técnica; no es necesario documentar excepciones triviales.

## Flujo de trabajo

1. **Comprender:** identifica requisitos, comportamiento existente, consumidores y archivos afectados. Contrasta los supuestos con el código y la documentación; aclara las ambigüedades que puedan cambiar el resultado.
2. **Consultar:** selecciona las referencias de la tabla según el problema. Lee las secciones pertinentes y combina ámbitos cuando el cambio lo requiera; no cargues todos los documentos por defecto.
3. **Implementar:** aplica la solución suficiente más sencilla y mantén los cambios dentro del alcance. Reutiliza las herramientas existentes; no aproveches la tarea para renombrar, reformatear o refactorizar áreas independientes.
4. **Verificar y entregar:** ejecuta las pruebas y comprobaciones de tipos, análisis estático y compilación pertinentes al impacto. Revisa contratos y documentación afectados. Resume cambios, decisiones relevantes y verificaciones; identifica lo pendiente y sus motivos sin atribuir resultados a comprobaciones no ejecutadas.

## Referencias según la tarea

Cada documento desarrolla sus criterios, ejemplos y listas de comprobación. Consulta la referencia específica en lugar de reproducir su contenido en este archivo.

| Necesidad | Referencia |
|---|---|
| Ciclo TDD, triangulación, regresión y trabajo con código sin pruebas | [tdd.md](referencias/tdd.md) |
| Estrategia de pruebas, dobles, contratos, aislamiento y asincronía | [testing.md](referencias/testing.md) |
| Responsabilidades, extensión, sustitución, interfaces y dependencias | [principios-solid.md](referencias/principios-solid.md) |
| Nombres, funciones, control de flujo, errores, comentarios y formato | [clean-code.md](referencias/clean-code.md) |
| Encapsulación, contratos, composición, entidades, objetos de valor y agregados | [diseño-de-objetos.md](referencias/diseño-de-objetos.md) |
| KISS, YAGNI, DRY, diseño simple y deuda técnica | [complejidad.md](referencias/complejidad.md) |
| Detectar y priorizar problemas de diseño y refactorizaciones | [code-smells.md](referencias/code-smells.md) |
| Elegir y aplicar un patrón ante una necesidad real | [patrones-de-diseño.md](referencias/patrones-de-diseño.md) |
| Organización del sistema, límites y selección de estilos arquitectónicos | [arquitectura.md](referencias/arquitectura.md) |
| APIs, persistencia, transacciones, seguridad y operación de servicios | [arquitectura-backend.md](referencias/arquitectura-backend.md) |
| Componentes, estado, formularios, accesibilidad y consumo de APIs | [arquitectura-frontend.md](referencias/arquitectura-frontend.md) |
| Contratos, esquemas, paquetes y compatibilidad entre frontend y backend | [arquitectura-shared.md](referencias/arquitectura-shared.md) |
| Caracterización, modernización, migraciones y compatibilidad de sistemas heredados | [arquitectura-legacy.md](referencias/arquitectura-legacy.md) |
| Comparación de alternativas, ADR y decisiones estructurales | [arquitectura-decisiones.md](referencias/arquitectura-decisiones.md) |

Para cambios arquitectónicos, parte de `arquitectura.md` y continúa con los ámbitos afectados. Para una corrección o refactorización, combina la guía del área con las de pruebas o diseño que resulten necesarias.

## Convenciones adicionales

Las convenciones generales de idioma, nomenclatura y formato se mantienen en `clean-code.md`, sección 9.4. Conserva las del módulo existente cuando difieran y evita normalizaciones ajenas a la tarea.

Cuando el proyecto no establezca otra norma:

- Escribe TSDoc en castellano. Usa prefijo `I` en interfaces únicamente si el área del proyecto ya sigue esa convención.
- Guarda la documentación general en `docs/`, con nombres en castellano y `kebab-case`. Actualízala cuando cambien contratos o comportamiento; evita documentación innecesaria para cambios triviales.
- En áreas con i18n, reutiliza sus claves y mecanismos; mantén coherentes `es` y `en` cuando ambos estén soportados.

## Salvaguardas transversales

- No modifiques código de terceros, dependencias o archivos generados salvo autorización expresa; respeta las exclusiones del proyecto y utiliza los generadores correspondientes.
- Al contrastar claves no confiables con propiedades propias, utiliza `Object.hasOwn(...)` o `Object.prototype.hasOwnProperty.call(...)`. No uses `in` si las propiedades heredadas no deben admitirse; para `Map`, utiliza `has(...)`.
- Cuando una tarea deba continuar con información incompleta, elige una alternativa conservadora que preserve el comportamiento existente y declara los supuestos materiales. No inventes requisitos, contratos ni resultados de verificación.