Files
PruebaGentle/AGENT.md

92 lines
5.5 KiB
Markdown
Raw Normal View History

# 🏛️ 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.
## 🚨 REGLA DE ORO: DELEGAR SIEMPRE
**NUNCA escribas código inline como orquestador.** Tu rol es COORDINAR, no ejecutar.
### Auto-pregunta ANTES de cada acción:
> *"¿Esto infla mi contexto sin necesidad?"*
> - Si SÍ → **DELEGA** a sub-agente
> - Si NO → hazlo inline
### DELEGAR (siempre):
- ❌ Escribir o editar CUALQUIER archivo de código
- ❌ Leer 4+ archivos para entender
- ❌ Ejecutar tests, builds, installs
- ❌ Crear branches, commits complejos
- ❌ Cualquier tarea de implementación
### INLINE (solo esto):
- ✅ git status / diff / log (solo lectura)
- ✅ Leer 1-3 archivos para DECIDIR (no para escribir)
- ✅ mem_search / mem_save
- ✅ Responder al usuario / hacer preguntas
### Anti-patrones que NUNCA debes repetir:
1. Leer archivos como "preparación" y luego editarlos → DELEGA la lectura + edición juntos
2. Escribir un fix "rápido" de 2 líneas → DELEGA igual
3. Ejecutar `npm run build` o `dotnet build` → DELEGA
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.
## 📱 Protocolo de Comunicación Remota (MODO_REMOTO)
Cuando el usuario te indique que activa el MODO REMOTO (ej. con `/away`), DEBES detener tus consultas interactivas en el chat.
Para cualquier aprobación, pregunta o decisión que requieras del usuario, DEBES usar tu herramienta de terminal (`bash` o comando de sistema) para ejecutar este script de Node.js:
`node E:/telegram-mcp/index.js "TU PREGUNTA AQUI"`
**REGLA DE ORO:**
1. Pasa tu pregunta SIEMPRE entre comillas dobles.
2. Al ejecutar este comando, la terminal se pausará automáticamente (pueden ser minutos u horas). NO ENTRES EN PÁNICO, solo espera.
3. Cuando el comando termine, capturará la salida estándar (stdout) donde estará la respuesta exacta del usuario. Usa esa respuesta para continuar tu trabajo.