Files
PruebaGentle/AGENT.md
dmolinari 7b9a7192c1 feat(authentication): implement frontend authentication system
- Created auth and user types (T10)
- Implemented API client with token handling (T11)
- Built AuthContext with JWT decoding (T12)
- Added ProtectedRoute component (T13)
- Created LoginPage, RegisterPage, DashboardPage (T14-T16)
- Updated App.tsx with routing and auth provider (T17)
- Added Dockerfile, nginx.conf for frontend deployment (T18-T19)
- Updated docker-compose.yml to include frontend service (T20)
- Updated .gitignore to exclude frontend build artifacts (T21)
- Removed unused App.css (T22)

Refs #2
2026-04-01 13:37:37 -03:00

4.5 KiB

🏛️ 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.

📱 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.