92 lines
5.5 KiB
Markdown
92 lines
5.5 KiB
Markdown
# 🏛️ 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. |