Files
PruebaGentle/AGENT.md

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

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