feat: Sistema de Usuarios - Backend CRUD + JWT Auth (Issue #1)
Implementación fundacional del proyecto PruebaGentle: - Arquitectura Clean/Hexagonal: Core, Infrastructure, API - 6 Stored Procedures para CRUD + autenticación - JWT authentication con BCrypt password hashing - Docker Compose (SQL Server + Backend) - Solución .NET 10 con Dapper + SqlClient Closes #1
This commit is contained in:
53
AGENT.md
Normal file
53
AGENT.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# 🏛️ 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.
|
||||
Reference in New Issue
Block a user