PruebaGentle/AGENT.md

# 🏛️ Tech Stack, Architecture & DevOps Standards

> **IMPORTANTE:** El idioma oficial de este proyecto es el ESPAÑOL. Todas las respuestas, explicaciones, comentarios de código y logs deben ser exclusivamente en español.

Este proyecto utiliza C# (.NET Web API), React (TypeScript + Vite + Tailwind CSS), SQL Server, Docker y Gitea.
DEBES cumplir estrictamente estas reglas en TODAS las fases del SDD (Spec, Design, Apply, Verify).

## 1. 📁 Estructura Estricta de Directorios
- Raíz del proyecto: SIEMPRE dividida en `[NombreProyecto]/Backend` y `[NombreProyecto]/Frontend`.
- La carpeta raíz solo debe contener: `.gitignore`, `docker-compose.yml`, `README.md`, `AGENTS.md` y archivos de configuración global.
- PROHIBIDO mezclar dependencias de Node en la raíz o archivos de solución `.sln` fuera de la carpeta `Backend`.

## 2. ⚙️ Backend (C# MVC + Dapper + SPs)
Sigue el patrón de la skill **"implementing-dapper-queries"** adaptado a nuestra estructura:

- **Arquitectura:** MVC Pragmático. 
  - `Controllers/`: Endpoints limpios.
  - `Core/Interfaces/`: Definición de interfaces para repositorios.
  - `Infrastructure/Dapper/Repositories/`: Implementación de interfaces usando Dapper.
  - `Infrastructure/Models/`: DTOs y modelos de datos.
- **Micro ORM & Acceso a Datos:** 
  - SIEMPRE usa **Dapper**. PROHIBIDO Entity Framework.
  - **Stored Procedures (SPs):** Toda lógica de persistencia o consulta compleja DEBE residir en un SP en SQL Server.
  - **Workflow de Datos:** 
    1. Crear/Actualizar el SP en la base de datos (usando el MCP de mssql para validar esquema).
    2. Crear el script de migración/SQL en `Backend/Sql/StoredProcedures/`.
    3. Implementar el Repositorio en C# llamando al SP.
- **Async:** Todos los métodos de repositorio y acciones del controlador deben ser `async Task`.

## 3. 🎨 Frontend (React + Vite + Tailwind)
- **Estructura:** Seguir patrón de componentes funcionales y hooks.
- **Tipado:** TypeScript estricto. PROHIBIDO el uso de `any`. Definir interfaces en `Frontend/src/types/`.
- **Estilos:** Tailwind CSS exclusivo vía `className`. PROHIBIDO CSS puro a menos que sea para animaciones complejas.
- **API Client:** Centralizar llamadas en `Frontend/src/api/` usando `import.meta.env` para la URL base.

## 4. 🐳 Entornos & Docker (Linux Target)
- **Dockerfiles:** Cada carpeta (`Backend` y `Frontend`) debe tener su propio `Dockerfile` optimizado para Linux.
- **Orquestación:** El `docker-compose.yml` en la raíz debe configurar la comunicación entre contenedores y el acceso a SQL Server.
- **Configuración:** Usa variables de entorno para las cadenas de conexión y puertos, permitiendo la convivencia entre local (localhost) y contenedor (nombre del servicio).

## 5. 🐙 Gitea Workflow & Control de Versiones
Sigue estrictamente la skill **"gitea-workflow"**:

- **Ramas:** Cada tarea de SDD debe ocurrir en una rama dedicada (ej: `feature/nombre-tarea`).
- **Commits:** Conventional Commits obligatorios (`feat:`, `fix:`, `chore:`).
- **Trazabilidad:** Referenciar SIEMPRE el ID de la incidencia de Gitea (ej: `Refs #12`).
- **Calidad:** Antes de marcar una tarea como completada, verificar que el código cumple con este AGENT.md para evitar rechazos en Pull Requests.
- **Automatización de Tareas:** 
  - Si al iniciar una tarea con `/sdd-new` no existe una incidencia (Issue) relacionada en Gitea, DEBES usar el MCP de Gitea para crearla y obtener su ID.
  - Al finalizar con éxito la fase `verify`, DEBES crear un Pull Request (PR) desde tu rama de trabajo hacia `main`, describiendo los cambios realizados y referenciando la incidencia (ej: `Closes #12`).

## 6. Reglas de entorno
- **Comandos:** Para todos los comandos de terminal, utiliza PowerShell o comandos directos de Windows, no uses 'bash' ya que mi entorno no lo soporta correctamente.