Dev Rules

Invocación

Al invocar /dev-rules, mostrar el siguiente resumen al usuario:

Dev Rules v1.0.0

Comunicación – Español, conciso, sin disculpas Estilo – Convenciones del proyecto, nombres descriptivos Documentación – Solo el “por qué”, TODOs para incompletos Git – Conventional Commits, confirmar antes de commit/push Código – SOLID, composición sobre herencia, early returns, SRP Arquitectura – Capas separadas, DTOs, inyección de dependencias Performance – Caché, lazy loading, paginación Errores – Fail fast, logs por nivel, mensajes amigables Seguridad – Sin secrets en código/logs, queries parametrizadas Testing – Solo si se solicita Deploy – No modificar sin confirmación, respetar entornos DB – Sin queries destructivas sin confirmación

Reglas por tecnología: TS/Angular – Sin any, inject(), async pipe, standalone + signals Java/Spring – Constructor injection, Transactional, records, Jakarta Flutter/Dart – const constructors, trailing commas, Bloc/Riverpod Kotlin/Compose – PascalCase Composable, Modifier en layout raíz

No agregar nada más. Solo mostrar el resumen.

Idioma y Comunicación

• Responder siempre en español.
• Ser conciso pero completo.
• No disculparse por errores; corregirlos directamente.

Formato y Estilo

• Seguir las convenciones del proyecto existente.
• Nombres descriptivos; el código debe hablar por sí mismo.
• Preferir código conciso sobre código documentado verbosamente.

Documentación

• Documentar solo decisiones técnicas importantes o lógica no obvia.
• Comentarios solo para explicar el “por qué”, nunca el “qué”.
• Usar TODO para código incompleto.

Git y Control de Versiones

• No hacer commit ni push sin confirmación explícita del usuario.
• Conventional Commits: feat, fix, docs, chore, refactor, test, ci.
• Ramas descriptivas: feature/, fix/, hotfix/, chore/.

Código Limpio

• Principios SOLID.
• Composición sobre herencia.
• Sin comentarios decorativos ni separadores visuales excesivos.
• Early returns para condiciones de error (evitar nesting profundo).
• Métodos/funciones pequeños con una sola responsabilidad.
• DRY: extraer lógica duplicada solo cuando se repite 3+ veces.

Arquitectura y Patrones

• Respetar la arquitectura existente del proyecto (microservicios, monolito, etc.).
• Separar claramente capas: controlador, servicio, repositorio/data.
• DTOs para transferencia entre capas; nunca exponer entidades directamente en APIs.
• Inyección de dependencias; evitar instanciación directa de servicios.

TypeScript/Angular

• Evitar any; usar tipos específicos o unknown.
• inject() para inyección de servicios.
• async pipe para observables en templates.
• Preferir standalone components y signals.

Java/Spring Boot

• Constructor Injection (sin Field Injection en producción).
• Transactional(readOnly = true) para lecturas, Transactional para escrituras.
• Java records para DTOs Request/Response.
• Validar inputs con Jakarta Validation.

Flutter/Dart

• Constructores const para widgets inmutables.
• Evitar el operador bang (!) a menos que el valor esté garantizado no-nulo.
• Trailing commas para mejor formateo.
• State management (Bloc/Riverpod) para apps complejas.

Kotlin/Compose

• Funciones Composable en PascalCase como sustantivos.
• Parámetros: obligatorios primero, luego Modifier, luego opcionales.
• Modifier se aplica solo al layout raíz.

Performance

• Considerar el impacto en rendimiento de cada cambio.
• Usar caché cuando sea apropiado.
• Lazy loading y paginación; evitar cargar datos innecesarios.

Manejo de Errores

• Fail fast: manejar errores al inicio de funciones.
• Logear con nivel apropiado: ERROR, WARN, INFO, DEBUG.
• Retornar mensajes amigables al usuario; detalles técnicos solo en logs.

Seguridad

• Nunca exponer secrets, API keys o credenciales en código o logs.
• Nunca logear datos sensibles (passwords, tokens, datos personales).
• Parametrizar siempre queries SQL.
• Validar y sanitizar toda entrada externa.

Testing

• No generar código de pruebas a menos que se solicite explícitamente.

Docker y Despliegue

• No modificar Dockerfiles ni pipelines CI/CD sin confirmación explícita.
• Respetar la separación de entornos (dev, cert, prod).

Base de Datos

• Nunca ejecutar queries destructivas (DROP, TRUNCATE, DELETE masivo) sin confirmación.
• Preferir migraciones versionadas sobre cambios manuales de esquema.