├── ejemplo ├── .gitignore ├── docs │ ├── specs │ │ ├── 05-notifications.md │ │ ├── 04-collaboration.md │ │ ├── 03-task-management.md │ │ ├── 02-project-management.md │ │ └── 01-auth-system.md │ ├── ticket-template.md │ └── plan.md ├── tickets │ ├── fase5-0020-backend-collaboration.md │ ├── fase5-0021-backend-notifications.md │ ├── fase6-0023-expand-test-coverage.md │ ├── fase6-0024-setup-cicd-pipeline.md │ ├── fase6-0025-prepare-for-production.md │ ├── fase0-0001-init-git-repo.md │ ├── fase0-0004-init-react-frontend.md │ ├── fase5-0022-frontend-collaboration.md │ ├── fase0-0003-init-django-backend.md │ ├── fase2-0013-write-project-tests.md │ ├── fase1-0006-extend-user-model.md │ ├── fase3-0014-create-task-model.md │ ├── fase0-0005-setup-linters.md │ ├── fase1-0009-write-auth-tests.md │ ├── fase1-0008-implement-user-endpoints.md │ ├── fase2-0010-create-project-models.md │ ├── fase2-0011-implement-project-serializers.md │ ├── fase4-0017-setup-frontend-routing-state.md │ ├── fase3-0016-write-task-tests.md │ ├── fase1-0007-setup-djoser-jwt.md │ ├── fase0-0002-docker-setup.md │ ├── fase4-0018-create-auth-views.md │ ├── fase3-0015-implement-task-views.md │ ├── fase2-0012-implement-project-views.md │ ├── fase4-0019-create-project-task-views.md │ └── 0000-index.md ├── backend │ ├── requirements.txt │ └── Dockerfile ├── frontend │ └── Dockerfile ├── docker-compose.yml └── prompts │ ├── ticket-template.md │ ├── guidelines.md │ └── instructions.md ├── images ├── image_01.png └── linus_john_heroes.md ├── prompts ├── instructions.md ├── ticket-template.md └── guidelines.md └── README.md /ejemplo/.gitignore: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/docs/specs/05-notifications.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase5-0020-backend-collaboration.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase5-0021-backend-notifications.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase6-0023-expand-test-coverage.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase6-0024-setup-cicd-pipeline.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase6-0025-prepare-for-production.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/image_01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/barbaritalaram/AIxDev/HEAD/images/image_01.png -------------------------------------------------------------------------------- /ejemplo/backend/requirements.txt: -------------------------------------------------------------------------------- 1 | django 2 | djangorestframework 3 | psycopg2-binary 4 | python-decouple 5 | djoser 6 | djangorestframework-simplejwt 7 | gunicorn -------------------------------------------------------------------------------- /ejemplo/frontend/Dockerfile: -------------------------------------------------------------------------------- 1 | # Usa una imagen oficial de Node.js 2 | FROM node:18-alpine 3 | 4 | # Establece el directorio de trabajo en /app 5 | WORKDIR /app 6 | 7 | # Copia package.json y package-lock.json 8 | # (Estos archivos serán creados en un ticket posterior) 9 | COPY package*.json ./ 10 | 11 | # Instala las dependencias 12 | RUN npm install 13 | 14 | # Copia el resto del código de la aplicación 15 | COPY . . 16 | 17 | # Expone el puerto 3000 para la aplicación de React 18 | EXPOSE 3000 19 | 20 | # Comando para iniciar la aplicación 21 | CMD ["npm", "start"] -------------------------------------------------------------------------------- /images/linus_john_heroes.md: -------------------------------------------------------------------------------- 1 | # Linus Torvalds & John Carmack - Los Maestros del Código 2 | 3 | Esta imagen muestra las ilustraciones de nuestros mentores legendarios: 4 | 5 | 🐧 **Linus Torvalds** (izquierda) 6 | - Creador de Linux y Git 7 | - Filosofía: Código limpio, simple y que funcione 8 | - Enfoque pragmático y directo 9 | 10 | 🎮 **John Carmack** (derecha) 11 | - Pionero de los gráficos 3D 12 | - Genio de la optimización 13 | - Perfección técnica e innovación 14 | 15 | Juntos representan el equilibrio perfecto entre funcionalidad práctica y excelencia técnica que guía este framework. -------------------------------------------------------------------------------- /ejemplo/backend/Dockerfile: -------------------------------------------------------------------------------- 1 | # Usa una imagen oficial de Python. 2 | FROM python:3.11-slim 3 | 4 | # Evita que Python escriba archivos .pyc 5 | ENV PYTHONDONTWRITEBYTECODE 1 6 | # Asegura que la salida de Python no se almacene en búfer 7 | ENV PYTHONUNBUFFERED 1 8 | 9 | # Establece el directorio de trabajo en /app 10 | WORKDIR /app 11 | 12 | # Instala las dependencias 13 | COPY requirements.txt /app/ 14 | RUN pip install --no-cache-dir -r requirements.txt 15 | 16 | # Copia el resto del código de la aplicación 17 | COPY . /app/ 18 | 19 | # Expone el puerto 8000 para que Django pueda ser accesible 20 | EXPOSE 8000 21 | 22 | # El comando para correr la aplicación será manejado por docker-compose o un script de entrada. 23 | # Por ejemplo: CMD ["gunicorn", "core.wsgi:application", "--bind", "0.0.0.0:8000"] -------------------------------------------------------------------------------- /ejemplo/docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: '3.8' 2 | 3 | services: 4 | backend: 5 | build: ./backend 6 | ports: 7 | - "8000:8000" 8 | volumes: 9 | - ./backend:/app 10 | environment: 11 | - DB_NAME=project_db 12 | - DB_USER=project_user 13 | - DB_PASSWORD=project_password 14 | - DB_HOST=db 15 | - DB_PORT=5432 16 | depends_on: 17 | - db 18 | 19 | frontend: 20 | build: ./frontend 21 | ports: 22 | - "3000:3000" 23 | volumes: 24 | - ./frontend:/app 25 | - /app/node_modules 26 | stdin_open: true 27 | tty: true 28 | 29 | db: 30 | image: postgres:15-alpine 31 | volumes: 32 | - postgres_data:/var/lib/postgresql/data/ 33 | environment: 34 | - POSTGRES_DB=project_db 35 | - POSTGRES_USER=project_user 36 | - POSTGRES_PASSWORD=project_password 37 | 38 | volumes: 39 | postgres_data: -------------------------------------------------------------------------------- /ejemplo/tickets/fase0-0001-init-git-repo.md: -------------------------------------------------------------------------------- 1 | # Ticket: Inicializar Repositorio Git 2 | 3 | - **ID del Ticket:** `fase0-0001` 4 | - **Fase:** Fase 0: Configuración del Proyecto y Cimientos 5 | - **Estado:** En Progreso 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Configurar el repositorio de Git para el control de versiones del proyecto. Esto incluye la inicialización del repositorio y la creación de un archivo `.gitignore` apropiado para un proyecto con Python/Django y Node/React para evitar que archivos innecesarios (dependencias, archivos de entorno, etc.) sean versionados. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [x] El repositorio de Git está inicializado en la raíz del proyecto. 19 | - [ ] Existe un archivo `.gitignore` en la raíz del proyecto. 20 | - [ ] El `.gitignore` contiene las reglas estándar para Python, Django, Node, y archivos de entorno comunes (`.env`, `__pycache__`, `node_modules`, etc.). -------------------------------------------------------------------------------- /ejemplo/tickets/fase0-0004-init-react-frontend.md: -------------------------------------------------------------------------------- 1 | # Ticket: Inicializar Frontend (React) 2 | 3 | - **ID del Ticket:** `fase0-0004` 4 | - **Fase:** Fase 0: Configuración del Proyecto y Cimientos 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear la estructura inicial de la aplicación de React, que servirá como la interfaz de usuario para la plataforma. Esto incluye la configuración básica y la definición de una estructura de directorios escalable. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una aplicación de React (con `Vite` o `Create React App`) dentro de un directorio `frontend`. 19 | - [ ] Se ha definido una estructura de carpetas inicial (ej. `/src/components`, `/src/pages`, `/src/services`, `/src/hooks`). 20 | - [ ] La aplicación de React se inicia correctamente dentro de su contenedor de Docker. 21 | 22 | --- 23 | 24 | ## Dependencias 25 | 26 | - **Bloqueado por:** `fase0-0002-docker-setup.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase5-0022-frontend-collaboration.md: -------------------------------------------------------------------------------- 1 | # Ticket: Frontend de Colaboración y Notificaciones 2 | 3 | - **ID del Ticket:** `fase5-0022` 4 | - **Fase:** Fase 5: Funcionalidades de Colaboración y Notificaciones 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Integrar las funcionalidades de colaboración (comentarios, adjuntos) y notificaciones en la interfaz de usuario de React. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] En la vista de detalle de una tarea, hay una sección para ver y añadir comentarios. 19 | - [ ] En la vista de detalle de una tarea, hay una sección para ver y subir archivos adjuntos. 20 | - [ ] Hay un componente en la barra de navegación o en un lugar visible que muestra el número de notificaciones no leídas. 21 | - [ ] Al hacer clic en el componente de notificaciones, se muestra una lista de las notificaciones del usuario. 22 | - [ ] La interfaz permite marcar las notificaciones como leídas. 23 | 24 | --- 25 | 26 | ## Dependencias 27 | 28 | -------------------------------------------------------------------------------- /ejemplo/tickets/fase0-0003-init-django-backend.md: -------------------------------------------------------------------------------- 1 | # Ticket: Inicializar Backend (Django) 2 | 3 | - **ID del Ticket:** `fase0-0003` 4 | - **Fase:** Fase 0: Configuración del Proyecto y Cimientos 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear la estructura inicial del proyecto de Django, incluyendo la configuración básica, la creación de la primera app `core`, y la conexión con la base de datos PostgreSQL que se ejecuta en Docker. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado un proyecto de Django dentro de un directorio `backend`. 19 | - [ ] Se ha creado una app de Django llamada `core`. 20 | - [ ] La configuración de Django (`settings.py`) está preparada para usar variables de entorno para los valores sensibles (ej. `SECRET_KEY`, credenciales de la BD). 21 | - [ ] El proyecto se conecta exitosamente a la base de datos PostgreSQL del servicio de Docker. 22 | - [ ] Se pueden ejecutar las migraciones iniciales de Django (`manage.py migrate`). 23 | 24 | --- 25 | 26 | ## Dependencias 27 | 28 | - **Bloqueado por:** `fase0-0002-docker-setup.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase2-0013-write-project-tests.md: -------------------------------------------------------------------------------- 1 | # Ticket: Escribir Pruebas de Proyectos 2 | 3 | - **ID del Ticket:** `fase2-0013` 4 | - **Fase:** Fase 2: Gestión de Proyectos (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear pruebas de integración para el sistema de gestión de proyectos para asegurar que todos los endpoints de la API y la lógica de permisos funcionen correctamente. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Hay pruebas que verifican la creación de un proyecto por un usuario autenticado. 19 | - [ ] Hay pruebas que verifican que un usuario solo puede listar los proyectos de los que es miembro. 20 | - [ ] Hay pruebas que verifican que solo el dueño de un proyecto puede actualizarlo o eliminarlo. 21 | - [ ] Hay pruebas que verifican que un usuario no miembro no puede acceder a los detalles de un proyecto privado. 22 | - [ ] Hay pruebas para el flujo de añadir y eliminar miembros de un proyecto, incluyendo los casos de permisos (solo el dueño puede hacerlo). 23 | 24 | --- 25 | 26 | ## Dependencias 27 | 28 | - **Bloqueado por:** `fase2-0012-implement-project-views.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase1-0006-extend-user-model.md: -------------------------------------------------------------------------------- 1 | # Ticket: Extender Modelo de Usuario 2 | 3 | - **ID del Ticket:** `fase1-0006` 4 | - **Fase:** Fase 1: Sistema de Autenticación y Usuarios (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Extender el modelo de usuario abstracto de Django para incluir campos personalizados, como el campo `role`, según lo definido en la especificación. Este modelo de usuario será la base para el sistema de permisos de la aplicación. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una nueva app de Django, por ejemplo `users`. 19 | - [ ] Se ha creado un modelo `User` que hereda de `AbstractUser`. 20 | - [ ] El modelo `User` incluye el campo `role` con las opciones `ADMIN` y `MEMBER`. 21 | - [ ] El nuevo modelo de usuario está correctamente configurado en `settings.py` a través de `AUTH_USER_MODEL`. 22 | - [ ] Se han creado y aplicado las migraciones correspondientes. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/01-auth-system.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase0-0003-init-django-backend.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase3-0014-create-task-model.md: -------------------------------------------------------------------------------- 1 | # Ticket: Crear Modelo de Tarea 2 | 3 | - **ID del Ticket:** `fase3-0014` 4 | - **Fase:** Fase 3: Gestión de Tareas (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Implementar el modelo de base de datos para `Task`, que es la entidad central de la aplicación. El modelo incluirá todos los atributos definidos en la especificación, como estado, prioridad y asignaciones. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una nueva app de Django, `tasks`. 19 | - [ ] Se ha implementado el modelo `Task` con todos sus campos: `project`, `title`, `description`, `status`, `priority`, `assignee`, `reporter`, `due_date`, etc. 20 | - [ ] Las relaciones `ForeignKey` (`project`, `assignee`, `reporter`) apuntan a los modelos correctos. 21 | - [ ] Se han definido los `choices` para los campos `status` y `priority`. 22 | - [ ] Se han creado y aplicado las migraciones correspondientes. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/03-task-management.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase2-0010-create-project-models.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase0-0005-setup-linters.md: -------------------------------------------------------------------------------- 1 | # Ticket: Configurar Linters y Formateadores 2 | 3 | - **ID del Ticket:** `fase0-0005` 4 | - **Fase:** Fase 0: Configuración del Proyecto y Cimientos 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Configurar herramientas de linting y formateo de código para los proyectos de backend y frontend. Esto es crucial para mantener un estilo de código consistente y limpio, y para detectar errores potenciales de forma temprana. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] El backend de Django está configurado para usar `Black` como formateador y `Flake8` como linter. 19 | - [ ] El frontend de React está configurado para usar `Prettier` como formateador y `ESLint` como linter. 20 | - [ ] Se han añadido scripts en los `package.json` y/o `Makefile` para ejecutar fácilmente las herramientas (ej. `npm run lint`, `make format`). 21 | - [ ] (Opcional) Se ha configurado un hook de pre-commit (ej. con `Husky` o `pre-commit`) para ejecutar estas herramientas antes de cada commit. 22 | 23 | --- 24 | 25 | ## Dependencias 26 | 27 | - **Bloqueado por:** `fase0-0003-init-django-backend.md`, `fase0-0004-init-react-frontend.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase1-0009-write-auth-tests.md: -------------------------------------------------------------------------------- 1 | # Ticket: Escribir Pruebas de Autenticación 2 | 3 | - **ID del Ticket:** `fase1-0009` 4 | - **Fase:** Fase 1: Sistema de Autenticación y Usuarios (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear un conjunto inicial de pruebas unitarias y de integración para el sistema de autenticación y usuarios. Las pruebas son fundamentales para garantizar que la lógica de negocio funciona como se espera y para prevenir regresiones futuras. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha configurado `pytest` y `pytest-django` en el proyecto. 19 | - [ ] Hay pruebas que verifican el proceso de creación de un nuevo usuario. 20 | - [ ] Hay pruebas que verifican el proceso de login con credenciales correctas e incorrectas. 21 | - [ ] Hay pruebas que verifican que el endpoint `/api/auth/users/me/` devuelve los datos del usuario autenticado. 22 | - [ ] Hay pruebas que verifican que los endpoints de gestión de usuarios (`/api/users/`) están correctamente protegidos por el rol de administrador. 23 | 24 | --- 25 | 26 | ## Dependencias 27 | 28 | - **Bloqueado por:** `fase1-0008-implement-user-endpoints.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase1-0008-implement-user-endpoints.md: -------------------------------------------------------------------------------- 1 | # Ticket: Implementar Endpoints de Usuario 2 | 3 | - **ID del Ticket:** `fase1-0008` 4 | - **Fase:** Fase 1: Sistema de Autenticación y Usuarios (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear los endpoints de la API necesarios para que los administradores puedan gestionar usuarios (listar, ver detalles, actualizar, eliminar), como se describe en la especificación. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado un `UserSerializer` que no expone información sensible como el hash de la contraseña. 19 | - [ ] Se ha creado un `ViewSet` para el modelo `User`. 20 | - [ ] El `ViewSet` está protegido y solo es accesible por usuarios con el rol `ADMIN`. 21 | - [ ] Se ha implementado el endpoint `GET /api/users/` para listar todos los usuarios. 22 | - [ ] Se han implementado los endpoints `GET`, `PUT`, `PATCH`, `DELETE` en `/api/users/{id}/` para gestionar un usuario específico. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/01-auth-system.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase1-0007-setup-djoser-jwt.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase2-0010-create-project-models.md: -------------------------------------------------------------------------------- 1 | # Ticket: Crear Modelos de Proyecto 2 | 3 | - **ID del Ticket:** `fase2-0010` 4 | - **Fase:** Fase 2: Gestión de Proyectos (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Implementar los modelos de base de datos para `Project` y la tabla intermedia para `ProjectMember`, de acuerdo con la especificación. Estos modelos definirán la estructura de cómo se almacenan los proyectos y sus miembros. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una nueva app de Django, `projects`. 19 | - [ ] Se ha implementado el modelo `Project` con los campos `name`, `description`, `owner` y `created_at`/`updated_at`. 20 | - [ ] El modelo `Project` tiene una relación `ManyToManyField` con el modelo `User` para gestionar los miembros, utilizando una tabla intermedia explícita si es necesario para campos adicionales como `date_joined`. 21 | - [ ] Se han creado y aplicado las migraciones correspondientes. 22 | 23 | --- 24 | 25 | ## Especificaciones Relacionadas 26 | 27 | - `docs/specs/02-project-management.md` 28 | 29 | --- 30 | 31 | ## Dependencias 32 | 33 | - **Bloqueado por:** `fase1-0006-extend-user-model.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase2-0011-implement-project-serializers.md: -------------------------------------------------------------------------------- 1 | # Ticket: Implementar Serializers de Proyecto 2 | 3 | - **ID del Ticket:** `fase2-0011` 4 | - **Fase:** Fase 2: Gestión de Proyectos (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear los `ModelSerializers` de Django REST Framework para los modelos de `Project` y `ProjectMember`. Estos serializers se encargarán de convertir los objetos del modelo a formato JSON para la API, y viceversa. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado un `ProjectSerializer` para el modelo `Project`. 19 | - [ ] El `ProjectSerializer` muestra los detalles del `owner` y una lista de los `members`. 20 | - [ ] Se ha creado un `ProjectMemberSerializer` o se ha anidado la información del miembro dentro del `ProjectSerializer` para mostrar los detalles de los miembros del proyecto. 21 | - [ ] Los serializers gestionan correctamente las operaciones de creación y actualización (ej. campos de solo lectura como `created_at`). 22 | 23 | --- 24 | 25 | ## Especificaciones Relacionadas 26 | 27 | - `docs/specs/02-project-management.md` 28 | 29 | --- 30 | 31 | ## Dependencias 32 | 33 | - **Bloqueado por:** `fase2-0010-create-project-models.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase4-0017-setup-frontend-routing-state.md: -------------------------------------------------------------------------------- 1 | # Ticket: Configurar Enrutamiento y Gestión de Estado en Frontend 2 | 3 | - **ID del Ticket:** `fase4-0017` 4 | - **Fase:** Fase 4: Implementación del Frontend (Core) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Establecer las bases de la aplicación de React, incluyendo la configuración del enrutador para manejar las diferentes páginas y la implementación de un sistema de gestión de estado global para manejar datos como la información del usuario autenticado. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha instalado y configurado `React Router DOM`. 19 | - [ ] Se han definido las rutas principales de la aplicación (ej. `/login`, `/register`, `/dashboard`, `/projects/{id}`). 20 | - [ ] Se ha implementado un componente de "Ruta Privada" que redirige a los usuarios no autenticados a la página de login. 21 | - [ ] Se ha elegido e implementado una solución de gestión de estado (React Context API con `useReducer`, Redux Toolkit, Zustand, etc.). 22 | - [ ] El estado de autenticación del usuario (incluyendo el token JWT) se gestiona globalmente. 23 | 24 | --- 25 | 26 | ## Dependencias 27 | 28 | - **Bloqueado por:** `fase0-0004-init-react-frontend.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase3-0016-write-task-tests.md: -------------------------------------------------------------------------------- 1 | # Ticket: Escribir Pruebas de Tareas 2 | 3 | - **ID del Ticket:** `fase3-0016` 4 | - **Fase:** Fase 3: Gestión de Tareas (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Media 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear pruebas de integración para el sistema de gestión de tareas. Las pruebas deben cubrir el CRUD completo de tareas y validar la lógica de negocio y los permisos asociados. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Hay pruebas que verifican la creación de una tarea dentro de un proyecto por un miembro del proyecto. 19 | - [ ] Hay pruebas que verifican que un usuario que no es miembro no puede crear ni ver tareas en un proyecto. 20 | - [ ] Hay pruebas que validan la actualización de una tarea (cambio de estado, asignación, etc.). 21 | - [ ] Hay pruebas para la lógica de permisos de eliminación (solo el reportero o el dueño del proyecto pueden eliminar). 22 | - [ ] Hay pruebas que validan que el endpoint de listado de tareas (`/api/projects/{project_id}/tasks/`) solo devuelve tareas del proyecto correcto. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/03-task-management.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase3-0015-implement-task-views.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase1-0007-setup-djoser-jwt.md: -------------------------------------------------------------------------------- 1 | # Ticket: Configurar Djoser y Simple JWT 2 | 3 | - **ID del Ticket:** `fase1-0007` 4 | - **Fase:** Fase 1: Sistema de Autenticación y Usuarios (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Instalar y configurar las librerías `Djoser` y `djangorestframework-simplejwt` para manejar la mayor parte de la lógica de autenticación (registro, login, logout, etc.) a través de endpoints de API basados en JSON Web Tokens. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Las librerías `djoser` y `djangorestframework-simplejwt` están añadidas a las dependencias del backend. 19 | - [ ] Django REST Framework está configurado para usar `Simple JWT` como su sistema de autenticación por defecto. 20 | - [ ] `Djoser` está configurado para usar `Simple JWT`. 21 | - [ ] Las rutas de la API para `Djoser` (ej. `/api/auth/`) están incluidas en el `urls.py` principal. 22 | - [ ] La configuración de `Djoser` está ajustada para funcionar con el modelo de usuario personalizado y usar el `email` como campo de login. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/01-auth-system.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase1-0006-extend-user-model.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase0-0002-docker-setup.md: -------------------------------------------------------------------------------- 1 | # Ticket: Configuración de Docker 2 | 3 | - **ID del Ticket:** `fase0-0002` 4 | - **Fase:** Fase 0: Configuración del Proyecto y Cimientos 5 | - **Estado:** Completado 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear la configuración de Docker para orquestar los diferentes servicios de la aplicación (backend, frontend, base de datos). Esto permitirá un entorno de desarrollo consistente y reproducible para todos los colaboradores. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [x] Existe un archivo `docker-compose.yml` en la raíz del proyecto. 19 | - [x] El `docker-compose.yml` define tres servicios: `backend`, `frontend`, y `db`. 20 | - [x] El servicio `db` utiliza la imagen oficial de PostgreSQL y configura un volumen persistente para los datos. 21 | - [x] Existe un `Dockerfile` en el directorio del backend para construir la imagen del servicio de Django. 22 | - [x] Existe un `Dockerfile` en el directorio del frontend para construir la imagen del servicio de React. 23 | - [x] Los servicios pueden iniciarse correctamente ejecutando `docker-compose up`. (Nota: los servicios de app fallarán hasta que se inicialicen en los tickets 0003 y 0004, pero la configuración está lista). 24 | 25 | --- 26 | 27 | ## Dependencias 28 | 29 | - **Bloqueado por:** `fase0-0001-init-git-repo.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase4-0018-create-auth-views.md: -------------------------------------------------------------------------------- 1 | # Ticket: Crear Vistas de Autenticación en Frontend 2 | 3 | - **ID del Ticket:** `fase4-0018` 4 | - **Fase:** Fase 4: Implementación del Frontend (Core) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Desarrollar los componentes y la lógica de la interfaz de usuario para que los usuarios puedan registrarse e iniciar sesión en la aplicación, interactuando con los endpoints de la API de autenticación del backend. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una página de `Login` con un formulario para email y contraseña. 19 | - [ ] La página de `Login` llama al endpoint `/api/auth/jwt/create/` y, en caso de éxito, guarda los tokens y redirige al dashboard. 20 | - [ ] Se ha creado una página de `Registro` con un formulario para los datos del nuevo usuario. 21 | - [ ] La página de `Registro` llama al endpoint `/api/auth/users/` y, en caso de éxito, redirige a la página de login. 22 | - [ ] Se manejan y muestran adecuadamente los errores de la API (ej. "credenciales inválidas", "el email ya existe"). 23 | - [ ] Existe una función de `logout` que borra los tokens de autenticación y redirige a la página de login. 24 | 25 | --- 26 | 27 | ## Dependencias 28 | 29 | - **Bloqueado por:** `fase1-0007-setup-djoser-jwt.md`, `fase4-0017-setup-frontend-routing-state.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase3-0015-implement-task-views.md: -------------------------------------------------------------------------------- 1 | # Ticket: Implementar Serializers y Vistas de Tarea 2 | 3 | - **ID del Ticket:** `fase3-0015` 4 | - **Fase:** Fase 3: Gestión de Tareas (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Crear los `Serializers` y `ViewSets` para el modelo `Task`. La implementación debe incluir rutas anidadas bajo los proyectos para reflejar la relación jerárquica y simplificar la lógica de permisos. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado un `TaskSerializer` para el modelo `Task`, mostrando información relevante de los campos `ForeignKey` (como el nombre del `assignee`). 19 | - [ ] Se ha creado un `TaskViewSet`. 20 | - [ ] Se ha configurado el enrutamiento para que los endpoints de tareas sean anidados bajo proyectos (ej. `/api/projects/{project_id}/tasks/`). La librería `drf-nested-routers` puede ser útil aquí. 21 | - [ ] El `ViewSet` filtra automáticamente las tareas para que solo pertenezcan al proyecto especificado en la URL. 22 | - [ ] Se han implementado los permisos para asegurar que solo los miembros del proyecto puedan interactuar con sus tareas. 23 | 24 | --- 25 | 26 | ## Especificaciones Relacionadas 27 | 28 | - `docs/specs/03-task-management.md` 29 | 30 | --- 31 | 32 | ## Dependencias 33 | 34 | - **Bloqueado por:** `fase3-0014-create-task-model.md` 35 | - **Bloquea:** `fase3-0016-write-task-tests.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase2-0012-implement-project-views.md: -------------------------------------------------------------------------------- 1 | # Ticket: Implementar Vistas y Permisos de Proyecto 2 | 3 | - **ID del Ticket:** `fase2-0012` 4 | - **Fase:** Fase 2: Gestión de Proyectos (Backend) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Implementar los `ViewSet` de la API para gestionar los proyectos y sus miembros. Esto incluye la creación de las clases de permisos personalizadas para asegurar que solo los usuarios autorizados (dueños, miembros) puedan realizar ciertas acciones. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado un `ProjectViewSet` para el modelo `Project`. 19 | - [ ] La acción de `list` solo devuelve los proyectos de los que el usuario autenticado es miembro. 20 | - [ ] La acción de `create` establece automáticamente al usuario autenticado como `owner` del proyecto. 21 | - [ ] Se ha creado una clase de permiso personalizada `IsOwnerOrReadOnly` (o similar) para restringir la actualización y eliminación de proyectos solo a sus dueños. 22 | - [ ] Se han implementado las acciones personalizadas (`@action`) en el `ViewSet` para añadir y eliminar miembros del proyecto (`/api/projects/{id}/members/`). 23 | - [ ] Los permisos para añadir/eliminar miembros están restringidos al `owner` del proyecto. 24 | 25 | --- 26 | 27 | ## Especificaciones Relacionadas 28 | 29 | - `docs/specs/02-project-management.md` 30 | 31 | --- 32 | 33 | ## Dependencias 34 | 35 | - **Bloqueado por:** `fase2-0011-implement-project-serializers.md` -------------------------------------------------------------------------------- /ejemplo/tickets/fase4-0019-create-project-task-views.md: -------------------------------------------------------------------------------- 1 | # Ticket: Crear Vistas de Proyectos y Tareas en Frontend 2 | 3 | - **ID del Ticket:** `fase4-0019` 4 | - **Fase:** Fase 4: Implementación del Frontend (Core) 5 | - **Estado:** Abierto 6 | - **Prioridad:** Alta 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | Desarrollar la interfaz de usuario principal donde los usuarios pueden ver sus proyectos y, al seleccionar uno, ver y gestionar las tareas asociadas. Esto incluye la creación de un dashboard de proyectos y una vista de tablero de tareas. 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] Se ha creado una página de "Dashboard" o "/projects" que lista los proyectos del usuario autenticado, llamando al endpoint `GET /api/projects/`. 19 | - [ ] La página de listado de proyectos permite crear un nuevo proyecto a través de un formulario/modal. 20 | - [ ] Al hacer clic en un proyecto, el usuario es redirigido a la página del tablero de ese proyecto (`/projects/{id}`). 21 | - [ ] La página del tablero de proyecto llama al endpoint `GET /api/projects/{project_id}/tasks/` para obtener y mostrar las tareas. 22 | - [ ] Las tareas se muestran en un formato de tablero (ej. columnas "Pendiente", "En Progreso", "Completado"). 23 | - [ ] Existe funcionalidad para crear una nueva tarea dentro del proyecto. 24 | - [ ] (Opcional) El usuario puede arrastrar y soltar tareas entre las columnas para actualizar su estado. 25 | 26 | --- 27 | 28 | ## Dependencias 29 | 30 | - **Bloqueado por:** `fase2-0012-implement-project-views.md`, `fase3-0015-implement-task-views.md`, `fase4-0018-create-auth-views.md` -------------------------------------------------------------------------------- /prompts/instructions.md: -------------------------------------------------------------------------------- 1 | # Instrucciones de Documentación 2 | 3 | 4 | ## Persona y Objetivo 5 | 6 | Eres Linus Torvalds y John Carmack, ingenieros de software legendarios encargados de discutir y acordar la hoja de ruta de implementación para mi proyecto y documentarla. 7 | 8 | 9 | ## Proyecto 10 | /*** ADVERTENCIA: CAMBIAR ESTO DEPENDIENDO DEL PROYECTO ***/ 11 | 12 | 13 | ## Stack Tecnológico 14 | /*** ADVERTENCIA: CAMBIAR ESTO DEPENDIENDO DEL PROYECTO ***/ 15 | - Elige lo mejor 16 | 17 | ## Documentación 18 | 19 | 20 | ### 1. Especificaciones 21 | 22 | Define la arquitectura apropiada según las directrices generales en `/docs/guidelines.md` y desarrolla las especificaciones completas, describe cada sistema necesario y cómo operan juntos, escribe cada especificación en su propio archivo. Esta es una documentación fundamental que será referenciada intensamente, así que hazla valer. Usa el directorio `/docs/specs`. 23 | 24 | 25 | ### 2. Plan 26 | 27 | Describe un enfoque paso a paso para lograr este proyecto haciendo referencia a tus especificaciones. Ten en cuenta los requisitos de capas para construir gradualmente el proyecto. Agrupa funcionalidad relacionada o pasos en fases. Este es un documento único con la hoja de ruta general de un vistazo. Guarda esta salida en el archivo `/docs/plan.md`. 28 | 29 | 30 | ### 3. Tickets 31 | 32 | Usa el `/docs/ticket-template.md` disponible. 33 | 34 | Basado en `/docs/plan.md` y `/docs/specs.md`, crea cada ticket dentro del directorio `/tickets`, usa `/tickets/0000-index.md` como una lista de verificación general para hacer seguimiento del progreso general. 35 | 36 | Cada ticket debe: 37 | - tener un ID único (incremental) y pertenecer a una fase 38 | - abordar una unidad única de trabajo 39 | - puede tener más de una tarea para completar los criterios de aceptación 40 | - referenciar las especificaciones correctas para el alcance del ticket actual 41 | - puede referenciar otros tickets según sea necesario -------------------------------------------------------------------------------- /prompts/ticket-template.md: -------------------------------------------------------------------------------- 1 | # Ticket: [Título del Ticket] 2 | 3 | - **ID del Ticket:** `[fase-XXXX]` (ej., `fase1-0001`, `auth-refactor-0003`) 4 | - **Fase:** `[Nombre de la fase de docs/plan.md]` 5 | - **Estado:** `Abierto | En Progreso | En Revisión | Completado | Bloqueado` 6 | - **Prioridad:** `Alta | Media | Baja` 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | [Proporciona una descripción clara y concisa de la tarea o problema. ¿Qué necesita hacerse? ¿Por qué es importante? ¿Cuál es el resultado esperado?] 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] [Criterio 1: Define claramente qué debe ser verdadero para que este ticket se considere completo.] 19 | - [ ] [Criterio 2: Agrega más criterios según sea necesario.] 20 | - [ ] [Criterio 3: Asegúrate de que los criterios sean comprobables/verificables.] 21 | 22 | --- 23 | 24 | ## Detalles Técnicos y Notas de Implementación (Opcional) 25 | 26 | [Incluye cualquier guía técnica específica, sugerencias o restricciones relevantes para implementar este ticket. Esto podría incluir fragmentos de código, enlaces a documentación externa, o consideraciones arquitectónicas.] 27 | 28 | --- 29 | 30 | ## Especificaciones Relacionadas 31 | 32 | - `[Enlace a documento(s) de especificación relevante en /docs/specs/ (ej., /docs/specs/auth-system.md)]` 33 | - `[Agrega más enlaces según sea necesario]` 34 | 35 | --- 36 | 37 | ## Dependencias 38 | 39 | - **Bloquea:** `[Enlace a cualquier ticket que este ticket bloquee (ej., /tickets/Fase1-002-tarea-dependiente.md)]` 40 | - **Bloqueado por:** `[Enlace a cualquier ticket que bloquee este ticket (ej., /tickets/Fase0-005-tarea-prerequisito.md)]` 41 | 42 | --- 43 | 44 | ## Sub-Tareas (Opcional) 45 | 46 | - [ ] [Sub-tarea 1] 47 | - [ ] [Sub-tarea 2] 48 | 49 | --- 50 | 51 | ## Comentarios y Discusión 52 | 53 | [Espacio para discusión continua, preguntas y actualizaciones relacionadas con este ticket.] -------------------------------------------------------------------------------- /ejemplo/docs/ticket-template.md: -------------------------------------------------------------------------------- 1 | # Ticket: [Título del Ticket] 2 | 3 | - **ID del Ticket:** `[fase-XXXX]` (ej., `fase1-0001`, `auth-refactor-0003`) 4 | - **Fase:** `[Nombre de la fase de docs/plan.md]` 5 | - **Estado:** `Abierto | En Progreso | En Revisión | Completado | Bloqueado` 6 | - **Prioridad:** `Alta | Media | Baja` 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | [Proporciona una descripción clara y concisa de la tarea o problema. ¿Qué necesita hacerse? ¿Por qué es importante? ¿Cuál es el resultado esperado?] 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] [Criterio 1: Define claramente qué debe ser verdadero para que este ticket se considere completo.] 19 | - [ ] [Criterio 2: Agrega más criterios según sea necesario.] 20 | - [ ] [Criterio 3: Asegúrate de que los criterios sean comprobables/verificables.] 21 | 22 | --- 23 | 24 | ## Detalles Técnicos y Notas de Implementación (Opcional) 25 | 26 | [Incluye cualquier guía técnica específica, sugerencias o restricciones relevantes para implementar este ticket. Esto podría incluir fragmentos de código, enlaces a documentación externa, o consideraciones arquitectónicas.] 27 | 28 | --- 29 | 30 | ## Especificaciones Relacionadas 31 | 32 | - `[Enlace a documento(s) de especificación relevante en /docs/specs/ (ej., /docs/specs/auth-system.md)]` 33 | - `[Agrega más enlaces según sea necesario]` 34 | 35 | --- 36 | 37 | ## Dependencias 38 | 39 | - **Bloquea:** `[Enlace a cualquier ticket que este ticket bloquee (ej., /tickets/Fase1-002-tarea-dependiente.md)]` 40 | - **Bloqueado por:** `[Enlace a cualquier ticket que bloquee este ticket (ej., /tickets/Fase0-005-tarea-prerequisito.md)]` 41 | 42 | --- 43 | 44 | ## Sub-Tareas (Opcional) 45 | 46 | - [ ] [Sub-tarea 1] 47 | - [ ] [Sub-tarea 2] 48 | 49 | --- 50 | 51 | ## Comentarios y Discusión 52 | 53 | [Espacio para discusión continua, preguntas y actualizaciones relacionadas con este ticket.] -------------------------------------------------------------------------------- /ejemplo/prompts/ticket-template.md: -------------------------------------------------------------------------------- 1 | # Ticket: [Título del Ticket] 2 | 3 | - **ID del Ticket:** `[fase-XXXX]` (ej., `fase1-0001`, `auth-refactor-0003`) 4 | - **Fase:** `[Nombre de la fase de docs/plan.md]` 5 | - **Estado:** `Abierto | En Progreso | En Revisión | Completado | Bloqueado` 6 | - **Prioridad:** `Alta | Media | Baja` 7 | 8 | --- 9 | 10 | ## Descripción 11 | 12 | [Proporciona una descripción clara y concisa de la tarea o problema. ¿Qué necesita hacerse? ¿Por qué es importante? ¿Cuál es el resultado esperado?] 13 | 14 | --- 15 | 16 | ## Criterios de Aceptación 17 | 18 | - [ ] [Criterio 1: Define claramente qué debe ser verdadero para que este ticket se considere completo.] 19 | - [ ] [Criterio 2: Agrega más criterios según sea necesario.] 20 | - [ ] [Criterio 3: Asegúrate de que los criterios sean comprobables/verificables.] 21 | 22 | --- 23 | 24 | ## Detalles Técnicos y Notas de Implementación (Opcional) 25 | 26 | [Incluye cualquier guía técnica específica, sugerencias o restricciones relevantes para implementar este ticket. Esto podría incluir fragmentos de código, enlaces a documentación externa, o consideraciones arquitectónicas.] 27 | 28 | --- 29 | 30 | ## Especificaciones Relacionadas 31 | 32 | - `[Enlace a documento(s) de especificación relevante en /docs/specs/ (ej., /docs/specs/auth-system.md)]` 33 | - `[Agrega más enlaces según sea necesario]` 34 | 35 | --- 36 | 37 | ## Dependencias 38 | 39 | - **Bloquea:** `[Enlace a cualquier ticket que este ticket bloquee (ej., /tickets/Fase1-002-tarea-dependiente.md)]` 40 | - **Bloqueado por:** `[Enlace a cualquier ticket que bloquee este ticket (ej., /tickets/Fase0-005-tarea-prerequisito.md)]` 41 | 42 | --- 43 | 44 | ## Sub-Tareas (Opcional) 45 | 46 | - [ ] [Sub-tarea 1] 47 | - [ ] [Sub-tarea 2] 48 | 49 | --- 50 | 51 | ## Comentarios y Discusión 52 | 53 | [Espacio para discusión continua, preguntas y actualizaciones relacionadas con este ticket.] -------------------------------------------------------------------------------- /ejemplo/tickets/0000-index.md: -------------------------------------------------------------------------------- 1 | # Índice General de Tickets 2 | 3 | Este documento sirve como una lista de verificación central para seguir el progreso de todas las fases y tickets del proyecto. 4 | 5 | --- 6 | 7 | ## Fase 0: Configuración del Proyecto y Cimientos 8 | - [ ] `fase0-0001` - Inicializar Repositorio Git 9 | - [ ] `fase0-0002` - Configuración de Docker 10 | - [ ] `fase0-0003` - Inicializar Backend (Django) 11 | - [ ] `fase0-0004` - Inicializar Frontend (React) 12 | - [ ] `fase0-0005` - Configurar Linters y Formateadores 13 | 14 | ## Fase 1: Sistema de Autenticación y Usuarios (Backend) 15 | - [ ] `fase1-0006` - Extender Modelo de Usuario 16 | - [ ] `fase1-0007` - Configurar Djoser y Simple JWT 17 | - [ ] `fase1-0008` - Implementar Endpoints de Usuario 18 | - [ ] `fase1-0009` - Escribir Pruebas de Autenticación 19 | 20 | ## Fase 2: Gestión de Proyectos (Backend) 21 | - [ ] `fase2-0010` - Crear Modelos de Proyecto 22 | - [ ] `fase2-0011` - Implementar Serializers de Proyecto 23 | - [ ] `fase2-0012` - Implementar Vistas y Permisos de Proyecto 24 | - [ ] `fase2-0013` - Escribir Pruebas de Proyectos 25 | 26 | ## Fase 3: Gestión de Tareas (Backend) 27 | - [ ] `fase3-0014` - Crear Modelo de Tarea 28 | - [ ] `fase3-0015` - Implementar Serializers y Vistas de Tarea 29 | - [ ] `fase3-0016` - Escribir Pruebas de Tareas 30 | 31 | ## Fase 4: Implementación del Frontend (Core) 32 | - [ ] `fase4-0017` - Configurar Enrutamiento y Gestión de Estado en Frontend 33 | - [ ] `fase4-0018` - Crear Vistas de Autenticación en Frontend 34 | - [ ] `fase4-0019` - Crear Vistas de Proyectos y Tareas en Frontend 35 | 36 | ## Fase 5: Funcionalidades de Colaboración y Notificaciones 37 | - [ ] `fase5-0020` - Backend de Colaboración (Comentarios y Adjuntos) 38 | - [ ] `fase5-0021` - Backend de Notificaciones 39 | - [ ] `fase5-0022` - Frontend de Colaboración y Notificaciones 40 | 41 | ## Fase 6: Pruebas, CI/CD y Despliegue 42 | - [ ] `fase6-0023` - Expandir Cobertura de Pruebas 43 | - [ ] `fase6-0024` - Configurar Pipeline de CI/CD 44 | - [ ] `fase6-0025` - Preparar para Despliegue en Producción 45 | 46 | --- 47 | *Actualiza este índice a medida que se completan los tickets.* -------------------------------------------------------------------------------- /prompts/guidelines.md: -------------------------------------------------------------------------------- 1 | # Persona 2 | 3 | Eres reflexivo, das respuestas matizadas, y eres brillante en el razonamiento, pensando extra duro para proporcionar respuestas precisas y factuales. 4 | 5 | # Convenciones de Código 6 | 7 | ## Mejores prácticas 8 | 9 | - Razona y comunícate con precisión militar. 10 | - Realiza actualizaciones quirúrgicas de código para lograr la solicitud del usuario (mínimamente invasivo, preciso y altamente efectivo). 11 | - Sigue los requisitos del usuario y los cambios solicitados cuidadosa y literalmente. 12 | - Primero piensa paso a paso y describe tu plan de lo que vas a construir escrito en gran detalle. 13 | - Revisa y confirma que tu enfoque es correcto, ¡luego escribe código! 14 | - Si no conoces la respuesta correcta, en lugar de adivinar, pide aclaración y busca una solución con el usuario. 15 | - Siempre escribe código correcto, de mejores prácticas, principio DRY (No Te Repitas), libre de errores, completamente funcional y que funcione. 16 | - Enfócate en soluciones simples y fáciles de leer. Mantén la base de código muy limpia y organizada. 17 | - Implementa completamente toda la funcionalidad solicitada. 18 | - NO dejes TODO's, marcadores de posición o piezas faltantes. 19 | - Incluye todas las importaciones requeridas, y asegura el nombrado apropiado de componentes clave. 20 | - ¡Asegúrate de que el código esté completo! Verifica exhaustivamente hasta finalizar. 21 | - Al arreglar un problema o error, no introduzcas un nuevo patrón o tecnología sin primero agotar todas las opciones para la implementación existente. Y si finalmente haces esto, refactoriza la implementación antigua para que no tengamos lógica duplicada. 22 | - Evita escribir scripts en archivos si es posible, especialmente si es probable que el script solo se ejecute una vez. 23 | - Evita tener archivos de más de 200 líneas de código. Refactoriza en ese punto. 24 | - Los datos simulados solo son necesarios para pruebas. 25 | - Nunca agregues patrones de stubbing o datos falsos al código que afecte los entornos de dev, stage o prod. 26 | - Nunca sobrescribas mi archivo .env sin primero preguntar y confirmar. 27 | - Usa retornos tempranos siempre que sea posible para hacer el código más legible. 28 | - Usa nombres significativos para variables, funciones, etc. Los nombres deben revelar intención. 29 | - **Solo usa comentarios cuando sea estrictamente necesario**. Porque tu código limpio es principalmente autoexplicativo, no necesitas agregar un comentario al final de una línea. 30 | - Cuando se usen comentarios, deben agregar información útil que no sea fácilmente aparente del código mismo. 31 | - Maneja apropiadamente errores y excepciones para asegurar la robustez del software. 32 | - Usa excepciones en lugar de códigos de error para manejar errores. 33 | - Considera las implicaciones de seguridad del código. Implementa mejores prácticas de seguridad para proteger contra vulnerabilidades y ataques. 34 | - Adhiérete a estos 4 principios de Programación Funcional: 35 | i. Funciones Puras 36 | ii. Inmutabilidad 37 | iii. Composición de Funciones 38 | iv. Código Declarativo -------------------------------------------------------------------------------- /ejemplo/prompts/guidelines.md: -------------------------------------------------------------------------------- 1 | # Persona 2 | 3 | Eres reflexivo, das respuestas matizadas, y eres brillante en el razonamiento, pensando extra duro para proporcionar respuestas precisas y factuales. 4 | 5 | # Convenciones de Código 6 | 7 | ## Mejores prácticas 8 | 9 | - Razona y comunícate con precisión militar. 10 | - Realiza actualizaciones quirúrgicas de código para lograr la solicitud del usuario (mínimamente invasivo, preciso y altamente efectivo). 11 | - Sigue los requisitos del usuario y los cambios solicitados cuidadosa y literalmente. 12 | - Primero piensa paso a paso y describe tu plan de lo que vas a construir escrito en gran detalle. 13 | - Revisa y confirma que tu enfoque es correcto, ¡luego escribe código! 14 | - Si no conoces la respuesta correcta, en lugar de adivinar, pide aclaración y busca una solución con el usuario. 15 | - Siempre escribe código correcto, de mejores prácticas, principio DRY (No Te Repitas), libre de errores, completamente funcional y que funcione. 16 | - Enfócate en soluciones simples y fáciles de leer. Mantén la base de código muy limpia y organizada. 17 | - Implementa completamente toda la funcionalidad solicitada. 18 | - NO dejes TODO's, marcadores de posición o piezas faltantes. 19 | - Incluye todas las importaciones requeridas, y asegura el nombrado apropiado de componentes clave. 20 | - ¡Asegúrate de que el código esté completo! Verifica exhaustivamente hasta finalizar. 21 | - Al arreglar un problema o error, no introduzcas un nuevo patrón o tecnología sin primero agotar todas las opciones para la implementación existente. Y si finalmente haces esto, refactoriza la implementación antigua para que no tengamos lógica duplicada. 22 | - Evita escribir scripts en archivos si es posible, especialmente si es probable que el script solo se ejecute una vez. 23 | - Evita tener archivos de más de 200 líneas de código. Refactoriza en ese punto. 24 | - Los datos simulados solo son necesarios para pruebas. 25 | - Nunca agregues patrones de stubbing o datos falsos al código que afecte los entornos de dev, stage o prod. 26 | - Nunca sobrescribas mi archivo .env sin primero preguntar y confirmar. 27 | - Usa retornos tempranos siempre que sea posible para hacer el código más legible. 28 | - Usa nombres significativos para variables, funciones, etc. Los nombres deben revelar intención. 29 | - **Solo usa comentarios cuando sea estrictamente necesario**. Porque tu código limpio es principalmente autoexplicativo, no necesitas agregar un comentario al final de una línea. 30 | - Cuando se usen comentarios, deben agregar información útil que no sea fácilmente aparente del código mismo. 31 | - Maneja apropiadamente errores y excepciones para asegurar la robustez del software. 32 | - Usa excepciones en lugar de códigos de error para manejar errores. 33 | - Considera las implicaciones de seguridad del código. Implementa mejores prácticas de seguridad para proteger contra vulnerabilidades y ataques. 34 | - Adhiérete a estos 4 principios de Programación Funcional: 35 | i. Funciones Puras 36 | ii. Inmutabilidad 37 | iii. Composición de Funciones 38 | iv. Código Declarativo -------------------------------------------------------------------------------- /ejemplo/prompts/instructions.md: -------------------------------------------------------------------------------- 1 | # Instrucciones de Documentación 2 | 3 | 4 | ## Persona y Objetivo 5 | 6 | Eres Linus Torvalds y John Carmack, ingenieros de software legendarios encargados de discutir y acordar la hoja de ruta de implementación para mi proyecto y documentarla. 7 | 8 | 9 | ## Proyecto 10 | 11 | Aplicación web para la gestión eficiente de tareas. 12 | 13 | ### Características Principales 14 | 15 | * **Gestión de Tareas:** 16 | * CRUD completo (Crear, Leer, Actualizar, Eliminar) para tareas. 17 | * Atributos de tarea: Título, descripción, responsable, fecha de vencimiento, prioridad (Baja, Media, Alta), estado (Pendiente, En Progreso, Completada). 18 | * **Usuarios y Autenticación:** 19 | * Registro y login de usuarios. 20 | * Autenticación basada en JWT. 21 | * Roles de usuario (Administrador, Miembro) con diferentes permisos. 22 | * **Organización:** 23 | * Capacidad para agrupar tareas en `Proyectos` o `Tableros`. 24 | * **Colaboración:** 25 | * Sistema de comentarios en cada tarea. 26 | * Posibilidad de adjuntar archivos a las tareas. 27 | * **Notificaciones:** 28 | * Notificaciones en tiempo real dentro de la aplicación para menciones o cambios de estado relevantes. 29 | 30 | 31 | ## Stack Tecnológico 32 | 33 | - **Frontend:** React.js 34 | - **Backend:** Django, Django REST Framework 35 | - **Base de Datos:** PostgreSQL 36 | - **Autenticación:** JWT (via Djoser o Simple JWT) 37 | - **Contenerización:** Docker 38 | 39 | *Nota de Arquitectura: Se ha seleccionado PostgreSQL en lugar de MongoDB. El ORM de Django está optimizado para bases de datos relacionales SQL, y PostgreSQL ofrece una integración nativa, robusta y de alto rendimiento, eliminando la necesidad de capas de compatibilidad de terceros como Djongo y simplificando el desarrollo y mantenimiento.* 40 | 41 | 42 | ## Documentación 43 | 44 | El proceso de desarrollo seguirá un flujo disciplinado: Especificaciones -> Plan -> Tickets. 45 | 46 | ### 1. Especificaciones 47 | 48 | Define la arquitectura detallada del sistema. Cada componente principal debe tener su propio archivo de especificación en el directorio `/docs/specs`. 49 | 50 | **Estructura de cada Especificación:** 51 | - **Resumen:** Descripción de alto nivel del componente y su propósito. 52 | - **Modelo de Datos:** Esquema de la base de datos (tablas, columnas, relaciones). 53 | - **API Endpoints:** Contrato de la API (Ruta, Método HTTP, Payload esperado, Respuestas). 54 | - **Flujos de Usuario:** Descripción de las interacciones clave del usuario. 55 | - **(Opcional) Diagramas:** Diagramas de arquitectura o secuencia para ilustrar lógicas complejas. 56 | 57 | Se deben crear las especificaciones necesarias basadas en las características del proyecto. 58 | 59 | 60 | ### 2. Plan de Ejecución 61 | 62 | Describe el enfoque de implementación paso a paso en un único archivo: `/docs/plan.md`. El plan debe agrupar las tareas en fases lógicas, construyendo el proyecto de manera incremental y haciendo referencia a las especificaciones correspondientes. 63 | 64 | 65 | ### 3. Tickets 66 | 67 | Usa el `/prompts/ticket-template.md` disponible. 68 | 69 | Basado en `/docs/plan.md` y los archivos de especificaciones, crea cada ticket dentro del directorio `/tickets`, usa `/tickets/0000-index.md` como una lista de verificación general para hacer seguimiento del progreso general. 70 | 71 | Cada ticket debe: 72 | - tener un ID único (incremental) y pertenecer a una fase 73 | - abordar una unidad única de trabajo 74 | - puede tener más de una tarea para completar los criterios de aceptación 75 | - referenciar las especificaciones correctas para el alcance del ticket actual 76 | - puede referenciar otros tickets según sea necesario 77 | 78 | 79 | ## Requisitos Adicionales Críticos 80 | 81 | ### 1. Estrategia de Pruebas (Testing) 82 | 83 | El software debe ser probado rigurosamente. 84 | - **Backend (Django):** Pruebas unitarias y de integración con `pytest`. Cobertura mínima del 80%. 85 | - **Frontend (React):** Pruebas de componentes con `React Testing Library` y `Jest`. 86 | - **End-to-End (E2E):** Pruebas de flujo de usuario con `Cypress` o `Playwright` para los casos de uso críticos. 87 | 88 | ### 2. CI/CD (Integración y Despliegue Continuo) 89 | 90 | Se configurará un pipeline de CI/CD (ej. GitHub Actions) para automatizar: 91 | - Ejecución de linters (Black, Flake8, Prettier). 92 | - Ejecución de la suite de pruebas completa. 93 | - Construcción y publicación de imágenes Docker en un registro (ej. Docker Hub, GitHub Container Registry). 94 | 95 | ### 3. Requisitos No Funcionales 96 | 97 | - **Seguridad:** Implementar prácticas estándar de seguridad, incluyendo protección contra XSS, CSRF e inyección SQL. Utilizar `django-cors-headers` para la política de CORS. 98 | - **Rendimiento:** Las respuestas de la API para operaciones de lectura comunes deben promediar menos de 200ms. 99 | - **Escalabilidad:** La arquitectura debe estar diseñada para escalar horizontalmente mediante la adición de más contenedores de aplicación. -------------------------------------------------------------------------------- /ejemplo/docs/specs/04-collaboration.md: -------------------------------------------------------------------------------- 1 | # Especificación del Sistema: Colaboración (Comentarios y Adjuntos) 2 | 3 | - **ID:** `SPEC-004` 4 | - **Componente:** `Collaboration Features` 5 | - **Estado:** `Borrador` 6 | - **Depende de:** `SPEC-003` 7 | 8 | --- 9 | 10 | ## 1. Resumen 11 | 12 | Este documento describe las funcionalidades que permiten la colaboración dentro de una tarea: la capacidad de dejar comentarios y de adjuntar archivos. Estos sistemas enriquecen la comunicación y centralizan la información relevante para cada tarea. 13 | 14 | ## 2. Modelo de Datos 15 | 16 | ### Tabla: `tasks_comment` 17 | 18 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 19 | | ----------------- | ------------------ | --------------------------------------------------------- | 20 | | `id` | UUID | Llave primaria, autogenerada. | 21 | | `task` | ForeignKey(`Task`) | **Requerido**. La tarea a la que pertenece el comentario. | 22 | | `author` | ForeignKey(`User`) | **Requerido**. El usuario que escribió el comentario. | 23 | | `body` | TEXT | **Requerido**. El contenido del comentario. | 24 | | `created_at` | DATETIME | Fecha de creación, autogestionada. | 25 | | `updated_at` | DATETIME | Fecha de última actualización, autogestionada. | 26 | 27 | ### Tabla: `tasks_attachment` 28 | 29 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 30 | | ----------------- | ------------------ | --------------------------------------------------------- | 31 | | `id` | UUID | Llave primaria, autogenerada. | 32 | | `task` | ForeignKey(`Task`) | **Requerido**. La tarea a la que pertenece el adjunto. | 33 | | `owner` | ForeignKey(`User`) | **Requerido**. El usuario que subió el archivo. | 34 | | `file` | FileField | **Requerido**. Referencia al archivo almacenado (ej. en S3). | 35 | | `filename` | VARCHAR(255) | Nombre del archivo. | 36 | | `created_at` | DATETIME | Fecha de subida, autogestionada. | 37 | 38 | *Nota sobre Almacenamiento:* Los archivos no se guardarán en la base de datos, sino en un servicio de almacenamiento de objetos como AWS S3, Google Cloud Storage, o en el sistema de archivos local para desarrollo. El campo `file` solo contendrá la ruta o URL al archivo. 39 | 40 | ## 3. Permisos 41 | 42 | | Acción | ¿Quién puede realizarla? | 43 | | ------------------------ | -------------------------------------------------------------- | 44 | | **Crear Comentario** | Cualquier miembro del proyecto al que pertenece la tarea. | 45 | | **Leer Comentarios** | Cualquier miembro del proyecto al que pertenece la tarea. | 46 | | **Actualizar Comentario**| Solo el `author` del comentario. | 47 | | **Eliminar Comentario** | El `author` del comentario o el `Owner` del proyecto. | 48 | | **Subir Adjunto** | Cualquier miembro del proyecto al que pertenece la tarea. | 49 | | **Leer/Descargar Adjunto** | Cualquier miembro del proyecto al que pertenece la tarea. | 50 | | **Eliminar Adjunto** | El `owner` del adjunto o el `Owner` del proyecto. | 51 | 52 | ## 4. API Endpoints 53 | 54 | Las rutas estarán anidadas bajo las tareas. 55 | 56 | ### Comentarios 57 | 58 | | Funcionalidad | Método HTTP | Ruta de API | Permisos Requeridos | Payload de Petición (JSON) | Respuesta Exitosa (2xx) | 59 | | ------------------------- | ----------- | ------------------------------------------------- | ------------------------- | -------------------------- | --------------------------------------- | 60 | | **Añadir Comentario** | `POST` | `/api/projects/{proj_id}/tasks/{task_id}/comments/` | Sí (Miembro del proyecto) | `{ "body": "texto" }` | `201 Created` - `{ comment_object }` | 61 | | **Listar Comentarios** | `GET` | `/api/projects/{proj_id}/tasks/{task_id}/comments/` | Sí (Miembro del proyecto) | N/A | `200 OK` - `[ { comment_object } ]` | 62 | | **Actualizar Comentario** | `PUT/PATCH` | `/api/comments/{id}/` | Sí (Autor del comentario) | `{ "body": "nuevo texto" }`| `200 OK` - `{ comment_object }` | 63 | | **Eliminar Comentario** | `DELETE` | `/api/comments/{id}/` | Sí (Autor o Proy. Owner) | N/A | `204 No Content` | 64 | 65 | ### Archivos Adjuntos 66 | 67 | | Funcionalidad | Método HTTP | Ruta de API | Permisos Requeridos | Payload de Petición (form-data) | Respuesta Exitosa (2xx) | 68 | | ---------------------- | ----------- | ----------------------------------------------------- | ------------------------- | ------------------------------- | ---------------------------------------- | 69 | | **Subir Adjunto** | `POST` | `/api/projects/{proj_id}/tasks/{task_id}/attachments/` | Sí (Miembro del proyecto) | `file` (el archivo binario) | `201 Created` - `{ attachment_object }` | 70 | | **Listar Adjuntos** | `GET` | `/api/projects/{proj_id}/tasks/{task_id}/attachments/` | Sí (Miembro del proyecto) | N/A | `200 OK` - `[ { attachment_object } ]` | 71 | | **Eliminar Adjunto** | `DELETE` | `/api/attachments/{id}/` | Sí (Owner o Proy. Owner) | N/A | `204 No Content` | 72 | 73 | --- 74 | Fin del Documento -------------------------------------------------------------------------------- /ejemplo/docs/specs/03-task-management.md: -------------------------------------------------------------------------------- 1 | # Especificación del Sistema: Gestión de Tareas 2 | 3 | - **ID:** `SPEC-003` 4 | - **Componente:** `Task Management` 5 | - **Estado:** `Borrador` 6 | - **Depende de:** `SPEC-001`, `SPEC-002` 7 | 8 | --- 9 | 10 | ## 1. Resumen 11 | 12 | Este documento detalla el sistema para la gestión de tareas, que es la unidad de trabajo fundamental en la aplicación. Define el ciclo de vida de una tarea, sus atributos, y cómo los usuarios interactúan con ella dentro de un proyecto. 13 | 14 | ## 2. Modelo de Datos 15 | 16 | ### Tabla: `tasks_task` 17 | 18 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 19 | | ----------------- | -------------------- | ----------------------------------------------------------- | 20 | | `id` | UUID | Llave primaria, autogenerada. | 21 | | `project` | ForeignKey(`Project`)| **Requerido**. El proyecto al que pertenece la tarea. | 22 | | `title` | VARCHAR(255) | **Requerido**. Título conciso de la tarea. | 23 | | `description` | TEXT | Opcional. Descripción detallada de la tarea. | 24 | | `status` | VARCHAR(50) | **Requerido**. Opciones: `PENDING`, `IN_PROGRESS`, `COMPLETED`. Default: `PENDING`. | 25 | | `priority` | VARCHAR(50) | **Requerido**. Opciones: `LOW`, `MEDIUM`, `HIGH`. Default: `MEDIUM`. | 26 | | `assignee` | ForeignKey(`User`) | Opcional. Usuario asignado para completar la tarea. Debe ser miembro del proyecto. | 27 | | `reporter` | ForeignKey(`User`) | **Requerido**. El usuario que creó la tarea. | 28 | | `due_date` | DATE | Opcional. Fecha de vencimiento para la tarea. | 29 | | `created_at` | DATETIME | Fecha de creación, autogestionada. | 30 | | `updated_at` | DATETIME | Fecha de última actualización, autogestionada. | 31 | 32 | ## 3. Roles y Permisos a Nivel de Tarea 33 | 34 | Los permisos se basan en la membresía del proyecto (`SPEC-002`). 35 | 36 | | Acción | ¿Quién puede realizarla? | 37 | | ---------------------- | -------------------------------------------------------------- | 38 | | **Crear Tarea** | Cualquier miembro (`Member` o `Owner`) del proyecto. | 39 | | **Leer Tareas** | Cualquier miembro del proyecto. | 40 | | **Actualizar Tarea** | Cualquier miembro del proyecto. | 41 | | **Eliminar Tarea** | El `reporter` de la tarea o el `Owner` del proyecto. | 42 | | **Asignar Tarea** | Cualquier miembro del proyecto puede asignar la tarea a otro miembro del mismo proyecto. | 43 | 44 | ## 4. API Endpoints 45 | 46 | Las rutas de la API para tareas estarán anidadas bajo los proyectos para reflejar la estructura de los datos. 47 | 48 | | Funcionalidad | Método HTTP | Ruta de API | Autenticación / Permisos Requeridos | Payload de Petición (JSON) | Respuesta Exitosa (2xx) | 49 | | ------------------------- | ----------- | ----------------------------------------- | -------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------- | 50 | | **Crear Tarea** | `POST` | `/api/projects/{project_id}/tasks/` | Sí (Miembro del proyecto) | `{ "title", "description"?, "assignee_id"?, "due_date"? }` | `201 Created` - `{ task_object }` | 51 | | **Listar Tareas de Proy.**| `GET` | `/api/projects/{project_id}/tasks/` | Sí (Miembro del proyecto) | N/A (con filtros opcionales por `status`, `assignee`, etc.) | `200 OK` - `[ { task_object }, ... ]` | 52 | | **Obtener Detalles Tarea**| `GET` | `/api/projects/{project_id}/tasks/{id}/` | Sí (Miembro del proyecto) | N/A | `200 OK` - `{ task_object_with_details }` | 53 | | **Actualizar Tarea** | `PUT/PATCH` | `/api/projects/{project_id}/tasks/{id}/` | Sí (Miembro del proyecto) | `{ "title"?, "description"?, "status"?, "priority"?, "assignee_id"?, "due_date"? }` | `200 OK` - `{ task_object }` | 54 | | **Eliminar Tarea** | `DELETE` | `/api/projects/{project_id}/tasks/{id}/` | Sí (Reporter de la tarea o Owner del proy.) | N/A | `204 No Content` | 55 | 56 | ## 5. Flujos de Usuario 57 | 58 | ### 5.1. Creación de una Tarea 59 | 1. Un miembro del proyecto, viendo el tablero o la lista de tareas, hace clic en "Crear Tarea". 60 | 2. El frontend envía una petición `POST /api/projects/{project_id}/tasks/` con al menos el `title`. Puede incluir opcionalmente una descripción, un responsable (`assignee_id`), etc. El `reporter` se establece automáticamente en el backend como el usuario que realiza la petición. 61 | 3. El sistema valida que el usuario es miembro del proyecto. 62 | 4. Si se proporciona un `assignee_id`, el sistema valida que ese usuario también es miembro del proyecto. 63 | 5. Se crea la tarea con estado `PENDING` y se devuelve el objeto de la tarea. 64 | 65 | ### 5.2. Actualización del Estado de una Tarea 66 | 1. Un miembro del proyecto (normalmente el `assignee`) arrastra la tarea de una columna (ej. "Pendiente") a otra (ej. "En Progreso") en un tablero Kanban, o la actualiza desde un formulario. 67 | 2. El frontend envía una petición `PATCH /api/projects/{project_id}/tasks/{id}/` con el payload `{ "status": "IN_PROGRESS" }`. 68 | 3. El backend actualiza el estado de la tarea y devuelve el objeto actualizado. 69 | 4. (Opcional) El sistema podría generar notificaciones para los usuarios relevantes (reporter, assignee). 70 | 71 | --- 72 | Fin del Documento -------------------------------------------------------------------------------- /ejemplo/docs/specs/02-project-management.md: -------------------------------------------------------------------------------- 1 | # Especificación del Sistema: Gestión de Proyectos 2 | 3 | - **ID:** `SPEC-002` 4 | - **Componente:** `Project Management` 5 | - **Estado:** `Borrador` 6 | - **Depende de:** `SPEC-001` (Autenticación y Gestión de Usuarios) 7 | 8 | --- 9 | 10 | ## 1. Resumen 11 | 12 | Este documento define la arquitectura para la gestión de Proyectos (o Tableros). Los proyectos son el contenedor principal para las tareas y el espacio de colaboración para los usuarios. El sistema permitirá a los usuarios crear proyectos, gestionarlos y añadir a otros usuarios como miembros para colaborar. 13 | 14 | ## 2. Modelo de Datos 15 | 16 | ### Tabla: `projects_project` 17 | 18 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 19 | | ----------------- | -------------------- | ----------------------------------------------------------- | 20 | | `id` | UUID | Llave primaria, autogenerada. | 21 | | `name` | VARCHAR(255) | **Requerido**. Nombre del proyecto. | 22 | | `description` | TEXT | Opcional. Descripción detallada del proyecto. | 23 | | `owner` | ForeignKey(`User`) | **Requerido**. El creador del proyecto. Si el owner se elimina, el proyecto también. | 24 | | `created_at` | DATETIME | Fecha de creación, autogestionada. | 25 | | `updated_at` | DATETIME | Fecha de última actualización, autogestionada. | 26 | 27 | ### Tabla: `projects_project_members` (Tabla intermedia Many-to-Many) 28 | 29 | Esta tabla asocia usuarios a los proyectos. 30 | 31 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 32 | | ----------------- | -------------------- | ----------------------------------------- | 33 | | `id` | AUTOINCREMENT | Llave primaria. | 34 | | `project_id` | ForeignKey(`Project`)| Enlace al proyecto. | 35 | | `user_id` | ForeignKey(`User`) | Enlace al usuario miembro. | 36 | | `date_joined` | DATETIME | Fecha en que el usuario se unió al proyecto. | 37 | 38 | ## 3. Roles y Permisos a Nivel de Proyecto 39 | 40 | | Rol | Descripción | 41 | | ----------- | -------------------------------------------------------------------------------------------------------------------------- | 42 | | **Owner** | El creador del proyecto. Tiene permisos CRUD completos sobre el proyecto (editar nombre/descripción, eliminar proyecto) y puede gestionar sus miembros (añadir/eliminar). | 43 | | **Member** | Un usuario que ha sido añadido al proyecto. Puede ver los detalles del proyecto y gestionar tareas dentro de él (los permisos específicos de tareas se definirán en `SPEC-003`). Puede abandonar el proyecto. | 44 | 45 | ## 4. API Endpoints 46 | 47 | | Funcionalidad | Método HTTP | Ruta de API | Autenticación / Permisos Requeridos | Payload de Petición (JSON) | Respuesta Exitosa (2xx) | 48 | | ----------------------------- | ----------- | ----------------------------------------- | ------------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------- | 49 | | **Crear Proyecto** | `POST` | `/api/projects/` | Sí (Cualquier usuario logueado) | `{ "name", "description"? }` | `201 Created` - `{ project_object }` | 50 | | **Listar mis Proyectos** | `GET` | `/api/projects/` | Sí (Cualquier usuario logueado) | N/A | `200 OK` - `[ { project_object }, ... ]` | 51 | | **Obtener Detalles Proyecto** | `GET` | `/api/projects/{id}/` | Sí (Miembro del proyecto) | N/A | `200 OK` - `{ project_object_with_members }` | 52 | | **Actualizar Proyecto** | `PUT/PATCH` | `/api/projects/{id}/` | Sí (Owner del proyecto) | `{ "name"?, "description"? }` | `200 OK` - `{ project_object }` | 53 | | **Eliminar Proyecto** | `DELETE` | `/api/projects/{id}/` | Sí (Owner del proyecto) | N/A | `204 No Content` | 54 | | **Añadir Miembro** | `POST` | `/api/projects/{id}/members/` | Sí (Owner del proyecto) | `{ "email": "user@example.com" }` | `201 Created` - `{ "message": "User added" }` | 55 | | **Eliminar Miembro** | `DELETE` | `/api/projects/{id}/members/{user_id}/` | Sí (Owner del proyecto, o el propio usuario a eliminar) | N/A | `204 No Content` | 56 | 57 | ## 5. Flujos de Usuario 58 | 59 | ### 5.1. Creación de un Proyecto 60 | 1. Un usuario logueado envía una petición `POST /api/projects/` con el nombre y, opcionalmente, una descripción. 61 | 2. El sistema crea una nueva instancia de `Project`, asignando al usuario peticionario como `owner`. 62 | 3. El sistema crea una entrada en la tabla `projects_project_members` que asocia al `owner` como el primer miembro del proyecto. 63 | 4. Se devuelve el objeto del proyecto recién creado. 64 | 65 | ### 5.2. Añadir un Miembro a un Proyecto 66 | 1. El `owner` del proyecto, desde la interfaz de gestión de miembros, introduce el email de otro usuario registrado. 67 | 2. El frontend envía una petición `POST /api/projects/{id}/members/` con el email del usuario a añadir. 68 | 3. El backend busca al usuario por su email. Si existe y no es ya miembro, lo añade a la tabla `projects_project_members` para ese proyecto. 69 | 4. Se devuelve un mensaje de éxito. (Opcional: se podría enviar una notificación al usuario añadido). 70 | 71 | ### 5.3. Abandonar un Proyecto 72 | 1. Un `member` de un proyecto decide abandonarlo. 73 | 2. El frontend envía una petición `DELETE /api/projects/{id}/members/{user_id}/` donde `{user_id}` es el ID del propio usuario. 74 | 3. El backend verifica que el usuario que realiza la petición es el mismo que se quiere eliminar (o es el owner), y elimina la entrada correspondiente en la tabla `projects_project_members`. 75 | 4. Se devuelve una respuesta `204 No Content`. 76 | 77 | --- 78 | Fin del Documento -------------------------------------------------------------------------------- /ejemplo/docs/plan.md: -------------------------------------------------------------------------------- 1 | # Plan de Ejecución del Proyecto 2 | 3 | Este documento describe la hoja de ruta para el desarrollo de la aplicación de gestión de tareas. El proyecto se divide en fases lógicas para asegurar una construcción incremental y ordenada. 4 | 5 | --- 6 | 7 | ## Fase 0: Configuración del Proyecto y Cimientos 8 | 9 | **Objetivo:** Preparar el entorno de desarrollo, la estructura del proyecto y las herramientas básicas. 10 | 11 | - **Pasos:** 12 | 1. **Inicializar Repositorio Git:** Configurar el repositorio con un `.gitignore` adecuado para Python/Django y Node/React. 13 | 2. **Configuración de Docker:** 14 | - Crear `docker-compose.yml` para orquestar los servicios de `backend` (Django), `frontend` (React) y `db` (PostgreSQL). 15 | - Crear `Dockerfile` para el servicio de backend. 16 | - Crear `Dockerfile` para el servicio de frontend. 17 | 3. **Inicializar Backend (Django):** 18 | - Crear el proyecto Django y la app principal de `core`. 19 | - Configurar variables de entorno (ej. `python-decouple`). 20 | - Establecer la conexión a la base de datos PostgreSQL. 21 | 4. **Inicializar Frontend (React):** 22 | - Crear la aplicación React usando `create-react-app` o `Vite`. 23 | - Configurar la estructura de carpetas inicial (componentes, servicios, etc.). 24 | 5. **Configurar Linters y Formateadores:** Integrar `Black`, `Flake8` para el backend y `Prettier`, `ESLint` para el frontend. 25 | 26 | --- 27 | 28 | ## Fase 1: Sistema de Autenticación y Usuarios (Backend) 29 | 30 | **Objetivo:** Implementar la lógica de negocio y los endpoints de la API para la gestión de usuarios. 31 | **Referencia:** `docs/specs/01-auth-system.md` 32 | 33 | - **Pasos:** 34 | 1. **Extender Modelo de Usuario:** Implementar el modelo `User` personalizado con el campo `role`. 35 | 2. **Configurar `Djoser` y `Simple JWT`:** Instalar y configurar las librerías para manejar los flujos de autenticación. 36 | 3. **Implementar Endpoints de Usuario:** 37 | - Asegurar que los endpoints de `Djoser` para registro, login, etc., funcionen correctamente. 38 | - Crear los endpoints para la gestión de usuarios por parte de los administradores (`/api/users/`). 39 | 4. **Escribir Pruebas:** Crear pruebas unitarias y de integración para los flujos de registro, login y obtención de perfil. 40 | 41 | --- 42 | 43 | ## Fase 2: Gestión de Proyectos (Backend) 44 | 45 | **Objetivo:** Implementar la lógica para crear y gestionar proyectos. 46 | **Referencia:** `docs/specs/02-project-management.md` 47 | 48 | - **Pasos:** 49 | 1. **Crear Modelos de Proyecto:** Implementar los modelos `Project` y `ProjectMember`. 50 | 2. **Implementar Serializers:** Crear los `serializers` de Django REST Framework para los modelos de proyecto. 51 | 3. **Implementar Vistas y Permisos:** Crear los `ViewSets` para los endpoints de la API de proyectos y configurar los permisos personalizados (Owner, Member). 52 | 4. **Escribir Pruebas:** Probar la creación, actualización, eliminación y listado de proyectos, así como la gestión de miembros. 53 | 54 | --- 55 | 56 | ## Fase 3: Gestión de Tareas (Backend) 57 | 58 | **Objetivo:** Implementar la funcionalidad principal de la aplicación: las tareas. 59 | **Referencia:** `docs/specs/03-task-management.md` 60 | 61 | - **Pasos:** 62 | 1. **Crear Modelo de Tarea:** Implementar el modelo `Task` con todos sus atributos. 63 | 2. **Implementar Serializers:** Crear `serializers` para el modelo `Task`. 64 | 3. **Implementar Vistas y Rutas Anidadas:** Crear los `ViewSets` para las tareas, asegurando que las rutas estén anidadas bajo proyectos (`/api/projects/{project_id}/tasks/`). 65 | 4. **Implementar Lógica de Negocio:** Asegurar que las validaciones y permisos a nivel de tarea funcionen correctamente. 66 | 5. **Escribir Pruebas:** Probar el CRUD completo de tareas y los filtros de listado. 67 | 68 | --- 69 | 70 | ## Fase 4: Implementación del Frontend (Core) 71 | 72 | **Objetivo:** Construir la interfaz de usuario para las funcionalidades básicas desarrolladas en las fases 1-3. 73 | 74 | - **Pasos:** 75 | 1. **Configurar Enrutamiento (React Router):** Definir las rutas públicas (login, registro) y privadas (dashboard). 76 | 2. **Gestión de Estado (Context API / Redux):** Implementar una solución para manejar el estado global (ej. estado de autenticación del usuario). 77 | 3. **Crear Vistas de Autenticación:** Desarrollar los formularios y la lógica para el registro y el login. 78 | 4. **Crear Vista de Proyectos:** Desarrollar la interfaz para listar, crear y ver proyectos. 79 | 5. **Crear Vista de Tablero de Tareas:** Implementar la vista principal donde los usuarios pueden ver y gestionar las tareas de un proyecto (ej. un tablero Kanban). 80 | 81 | --- 82 | 83 | ## Fase 5: Funcionalidades de Colaboración y Notificaciones (Backend y Frontend) 84 | 85 | **Objetivo:** Añadir las características que enriquecen la interacción del usuario. 86 | **Referencias:** `docs/specs/04-collaboration.md`, `docs/specs/05-notifications.md` 87 | 88 | - **Pasos:** 89 | 1. **Backend - Comentarios y Adjuntos:** 90 | - Implementar los modelos, serializers y vistas para comentarios y adjuntos. 91 | - Configurar el almacenamiento de archivos (ej. S3). 92 | - Escribir pruebas. 93 | 2. **Backend - Notificaciones:** 94 | - Implementar el modelo de `Notification`. 95 | - Usar señales de Django (`post_save`) para generar notificaciones automáticamente según los eventos definidos. 96 | - Crear los endpoints de la API y escribir pruebas. 97 | 3. **Frontend - Integración:** 98 | - Integrar la sección de comentarios y adjuntos en la vista de detalle de la tarea. 99 | - Añadir un componente de notificaciones en la UI para mostrar las alertas al usuario. 100 | 101 | --- 102 | 103 | ## Fase 6: Pruebas, CI/CD y Despliegue 104 | 105 | **Objetivo:** Asegurar la calidad del software, automatizar el flujo de trabajo y preparar para el lanzamiento. 106 | **Referencia:** Requisitos de `prompts/instructions.md` 107 | 108 | - **Pasos:** 109 | 1. **Expandir Cobertura de Pruebas:** Aumentar la cobertura de pruebas del backend y frontend a los niveles deseados. 110 | 2. **Configurar Pipeline de CI/CD:** 111 | - Crear un workflow de GitHub Actions que ejecute linters y pruebas en cada `push`. 112 | - Añadir un paso para construir y publicar las imágenes de Docker a un registro (ej. Docker Hub). 113 | 3. **Preparar para Producción:** 114 | - Crear una configuración de Docker y Django específica para producción (Gunicorn, Whitenoise, etc.). 115 | - Configurar un servidor o servicio en la nube (ej. AWS, DigitalOcean) para el despliegue. 116 | 4. **Despliegue Inicial.** 117 | 118 | --- 119 | Fin del Documento -------------------------------------------------------------------------------- /ejemplo/docs/specs/01-auth-system.md: -------------------------------------------------------------------------------- 1 | # Especificación del Sistema: Autenticación y Gestión de Usuarios 2 | 3 | - **ID:** `SPEC-001` 4 | - **Componente:** `Auth & User Management` 5 | - **Estado:** `Borrador` 6 | 7 | --- 8 | 9 | ## 1. Resumen 10 | 11 | Este documento describe el sistema responsable del registro, autenticación y gestión de usuarios en la plataforma. Este sistema es la base para el control de acceso y la personalización de la experiencia del usuario. Utilizará tokens JWT (JSON Web Tokens) para la autenticación de la API y la librería `Djoser` para gestionar los flujos de autenticación estándar. 12 | 13 | ## 2. Modelo de Datos 14 | 15 | ### Tabla: `users_user` 16 | 17 | Se extenderá el modelo de usuario abstracto de Django. 18 | 19 | | Nombre de Columna | Tipo de Dato | Restricciones / Notas | 20 | | ----------------- | ------------------ | ---------------------------------------------------- | 21 | | `id` | UUID | Llave primaria, autogenerada. | 22 | | `password` | VARCHAR(128) | Hasheada por Django. | 23 | | `last_login` | DATETIME | Fecha del último inicio de sesión. | 24 | | `is_superuser` | BOOLEAN | Designa si el usuario tiene todos los permisos. | 25 | | `email` | VARCHAR(254) | **Requerido**, Único. Usado para el login. | 26 | | `first_name` | VARCHAR(150) | Opcional. | 27 | | `last_name` | VARCHAR(150) | Opcional. | 28 | | `is_staff` | BOOLEAN | Designa si el usuario puede acceder al admin site. | 29 | | `is_active` | BOOLEAN | Designa si la cuenta está activa. Default: `True`. | 30 | | `date_joined` | DATETIME | Fecha de creación de la cuenta. | 31 | | `role` | VARCHAR(50) | Rol del usuario. Opciones: `ADMIN`, `MEMBER`. Default: `MEMBER`. | 32 | 33 | 34 | ## 3. Roles y Permisos 35 | 36 | | Rol | Descripción | 37 | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------- | 38 | | `ADMIN` | Tiene acceso completo a todas las funcionalidades. Puede gestionar usuarios (CRUD), proyectos (CRUD) y tareas (CRUD) en todo el sistema. | 39 | | `MEMBER` | Rol estándar. Puede crear proyectos, gestionar las tareas de los proyectos a los que pertenece y ver otros usuarios y proyectos. | 40 | 41 | ## 4. API Endpoints 42 | 43 | Los siguientes endpoints serán proporcionados principalmente por `Djoser` y `Simple JWT`. 44 | 45 | | Funcionalidad | Método HTTP | Ruta de API | Autenticación Requerida | Payload de Petición (JSON) | Respuesta Exitosa (2xx) | 46 | | ------------------------- | ----------- | ---------------------------- | ----------------------- | --------------------------------------------------------- | --------------------------------------------------------------------- | 47 | | **Registro de Usuario** | `POST` | `/api/auth/users/` | No | `{ "email", "password", "first_name", "last_name" }` | `201 Created` - `{ "id", "email", "first_name", "last_name" }` | 48 | | **Login (Crear Token)** | `POST` | `/api/auth/jwt/create/` | No | `{ "email", "password" }` | `200 OK` - `{ "access", "refresh" }` (tokens JWT) | 49 | | **Refrescar Token** | `POST` | `/api/auth/jwt/refresh/` | No | `{ "refresh": "token_value" }` | `200 OK` - `{ "access": "new_token" }` | 50 | | **Verificar Token** | `POST` | `/api/auth/jwt/verify/` | No | `{ "token": "token_value" }` | `200 OK` (sin cuerpo) | 51 | | **Obtener Perfil Propio** | `GET` | `/api/auth/users/me/` | Sí (Access Token) | N/A | `200 OK` - `{ "id", "email", "first_name", "last_name", "role" }` | 52 | | **Actualizar Perfil** | `PUT/PATCH` | `/api/auth/users/me/` | Sí (Access Token) | `{ "first_name", "last_name" }` (u otros campos) | `200 OK` - `{ "id", "email", "first_name", "last_name", "role" }` | 53 | | **Solicitar Reseteo Pwd** | `POST` | `/api/auth/users/reset_password/` | No | `{ "email": "user@example.com" }` | `204 No Content` | 54 | | **Confirmar Reseteo Pwd** | `POST` | `/api/auth/users/reset_password_confirm/` | No | `{ "uid", "token", "new_password" }` | `204 No Content` | 55 | | **Listar Usuarios** | `GET` | `/api/users/` | Sí (Admin) | N/A | `200 OK` - `[ {user_object}, ... ]` | 56 | | **Gestionar Usuario** | `GET/PUT/DELETE` | `/api/users/{id}/` | Sí (Admin) | N/A para GET/DELETE, `{user_data}` para PUT | `200 OK`, `204 No Content` | 57 | 58 | 59 | ## 5. Flujos de Usuario 60 | 61 | ### 5.1. Registro y Primer Login 62 | 1. Un nuevo usuario visita la aplicación y accede a la página de registro. 63 | 2. Envía su `email`, `password`, `first_name` y `last_name` a través del endpoint `POST /api/auth/users/`. 64 | 3. El sistema crea una nueva cuenta de usuario con el rol `MEMBER` por defecto y devuelve un `201 Created`. 65 | 4. El usuario es redirigido a la página de login. 66 | 5. Introduce su `email` y `password` en el endpoint `POST /api/auth/jwt/create/`. 67 | 6. El sistema valida las credenciales y devuelve un token de `access` y uno de `refresh`. 68 | 7. El frontend almacena estos tokens de forma segura (el `access` token en memoria, el `refresh` token en una cookie HttpOnly). 69 | 8. El usuario es redirigido al dashboard principal de la aplicación. 70 | 71 | ### 5.2. Petición Autenticada 72 | 1. Para acceder a un recurso protegido (ej. `GET /api/tasks/`), el frontend incluye el `access` token en la cabecera `Authorization: Bearer `. 73 | 2. El backend valida el token. Si es válido, procesa la petición y devuelve los datos. 74 | 3. Si el `access` token ha expirado, el backend devuelve un `401 Unauthorized`. 75 | 4. El frontend intercepta el `401`, usa el `refresh` token para solicitar un nuevo `access` token al endpoint `/api/auth/jwt/refresh/`. 76 | 5. Con el nuevo token, el frontend reintenta la petición original. 77 | 78 | --- 79 | Fin del Documento -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 🚀 AIxDev: Build Better with AI 2 | 💡 Idea → 🧾 Instrucciones → 📋 PRD → 🗺️ Plan → 🎫 Tickets → 💻 Implementación → ✅ Validación 3 | 4 | 5 | ## 📋 Tabla de Contenidos 6 | - [🎯 ¿Qué es AIxDev?](#-qué-es-aixdev) 7 | - [✨ Características Principales](#-características-principales) 8 | - [🤖 Integración con LLMs](#-integración-con-llms) 9 | - [🗂️ Estructura del Proyecto](#️-estructura-del-proyecto) 10 | - [⚙️ Configuración de Cursor](#️-configuración-de-cursor) 11 | - [📚 Guía Paso a Paso](#-guía-paso-a-paso) 12 | - [Fase 1: Refinamiento de Instrucciones](#fase-1-refinamiento-de-instrucciones) 13 | - [Fase 2: Documentación del Proyecto](#fase-2-documentación-del-proyecto) 14 | - [Fase 3: Implementación](#fase-3-implementación) 15 | - [💡 Consejos y Mejores Prácticas](#-consejos-y-mejores-prácticas) 16 | - [❓ Preguntas Frecuentes](#-preguntas-frecuentes) 17 | - [🔧 Solución de Problemas](#-solución-de-problemas) 18 | - [📖 Glosario de Términos](#-glosario-de-términos) 19 | 20 | --- 21 | 22 | ## 🎯 ¿Qué es AIxDev? 23 | 24 | 25 | **AIxDev: Build Better with AI** es un framework de desarrollo de software potenciado por Inteligencia Artificial que te ayuda a estructurar, documentar e implementar proyectos de manera eficiente y con la sabiduría de los mejores ingenieros del mundo. 26 | 27 | Este framework está diseñado para: 28 | - 📖 **Documentar** proyectos de software de manera sistemática 29 | - 🎯 **Planificar** desarrollo con metodología clara 30 | - 🎫 **Gestionar** tareas mediante un sistema de tickets 31 | - 🤝 **Colaborar** efectivamente en equipo 32 | 33 | --- 34 | 35 | ## ✨ Características Principales 36 | 37 | - 🔄 **Proceso Iterativo**: Refinamiento continuo de instrucciones y documentación 38 | - 📝 **Documentación Estructurada**: Especificaciones, planes y tickets organizados 39 | - 🎯 **Enfoque por Fases**: Desarrollo gradual y sistemático 40 | - 🎫 **Sistema de Tickets**: Gestión granular de tareas 41 | - 🔍 **Criterios de Aceptación**: Definición clara de completitud 42 | 43 | --- 44 | 45 | ## 🤖 Integración con LLMs 46 | 47 | > 🚀 **AIxDev** está diseñado para maximizar el potencial de los **Modelos de Lenguaje Grande (LLMs)** como Claude, GPT, Cursor AI, y otros. 48 | 49 | ### 🎭 Los Maestros: Linus Torvalds & John Carmack 50 | 51 | **¿Por qué elegimos estas figuras legendarias como referencia?** 52 | ![Linus Torvalds y John Carmack - Los Maestros del Código](images/image_01.png) 53 | 54 | #### 🐧 **Linus Torvalds** 55 | - **Creador de Linux**: El sistema operativo más usado en servidores del mundo 56 | - **Inventor de Git**: El sistema de control de versiones más popular 57 | - **Filosofía**: Código limpio, simple y que funcione 58 | - **Enfoque**: Pragmático, directo, sin complicaciones innecesarias 59 | - **Aporte**: Gestión de proyectos masivos con miles de colaboradores 60 | 61 | #### 🎮 **John Carmack** 62 | - **Pionero de los gráficos 3D**: Creador de Doom, Quake, motores gráficos revolucionarios 63 | - **Genio de la optimización**: Código altamente eficiente y elegante 64 | - **Filosofía**: Perfección técnica, innovación constante 65 | - **Enfoque**: Analítico, meticuloso, orientado a resultados 66 | - **Aporte**: Arquitecturas de software innovadoras y escalables 67 | 68 | ### 🎯 **¿Cómo los LLMs Potencian el Sistema?** 69 | 70 | #### 🧠 **En la Fase de Refinamiento** 71 | Los LLMs actúan como **consultores expertos** que: 72 | - Analizan instrucciones con la mentalidad de Linus y Carmack 73 | - Identifican puntos ciegos en los requisitos 74 | - Sugieren mejores prácticas basadas en décadas de experiencia 75 | - Optimizan el flujo de trabajo del proyecto 76 | 77 | #### 📝 **En la Documentación** 78 | Los LLMs funcionan como **arquitectos de software** que: 79 | - Crean especificaciones técnicas detalladas 80 | - Diseñan arquitecturas escalables y mantenibles 81 | - Documentan con la claridad de Linus y la precisión de Carmack 82 | - Estructuran información de manera coherente 83 | 84 | #### 🛠️ **En la Implementación** 85 | Los LLMs se convierten en **pair programmers expertos** que: 86 | - Escriben código siguiendo las mejores prácticas 87 | - Aplican principios de programación funcional 88 | - Optimizan rendimiento y legibilidad 89 | - Siguen la filosofía DRY (Don't Repeat Yourself) 90 | 91 | ### 🎪 **Ventajas del Enfoque con LLMs** 92 | 93 | #### ✅ **Consistencia de Calidad** 94 | - Cada decisión pasa por el "filtro" de dos genios legendarios 95 | - Mantiene estándares altos en todo el proyecto 96 | - Reduce la variabilidad en la calidad del código 97 | 98 | #### ✅ **Experiencia Acumulada** 99 | - Acceso a décadas de experiencia en desarrollo 100 | - Mejores prácticas probadas en proyectos masivos 101 | - Conocimiento de patrones que funcionan 102 | 103 | #### ✅ **Eficiencia Multiplicada** 104 | - Menos tiempo en debates sobre arquitectura 105 | - Decisiones más rápidas y fundamentadas 106 | - Menor curva de aprendizaje para nuevos desarrolladores 107 | 108 | #### ✅ **Escalabilidad** 109 | - Procesos que funcionan desde proyectos pequeños hasta masivos 110 | - Metodología probada en entornos de alta complejidad 111 | - Gestión eficiente de equipos de cualquier tamaño 112 | --- 113 | 114 | ## 🗂️ Estructura del Proyecto 115 | 116 | ``` 117 | AIxDev/ 118 | ├── 📁 prompts/ # Plantillas y guías 119 | │ ├── instructions.md # Instrucciones principales 120 | │ ├── guidelines.md # Guías de código (para Cursor) 121 | │ └── ticket-template.md # Plantilla para tickets 122 | ├── 📁 docs/ # Documentación del proyecto 123 | │ ├── specs/ # Especificaciones técnicas 124 | │ └── plan.md # Plan de desarrollo 125 | ├── 📁 tickets/ # Gestión de tareas 126 | │ └── 0000-index.md # Índice de tickets 127 | └── README.md # Esta guía 128 | ``` 129 | 130 | --- 131 | 132 | ## ⚙️ Configuración de Cursor 133 | 134 | > 🚨 **IMPORTANTE**: Antes de empezar, configura las reglas de Cursor para obtener la mejor experiencia de desarrollo. 135 | 136 | ### 📋 Paso a Paso: Configurar Guidelines en Cursor 137 | 138 | #### 🎯 **Paso 1: Acceder a la Configuración de Cursor** 139 | 140 | 1. **Abre Cursor** 141 | 2. **Ve a Configuración**: 142 | - **Windows/Linux**: `Ctrl + ,` o `File > Preferences > Settings` 143 | - **Mac**: `Cmd + ,` o `Cursor > Preferences > Settings` 144 | 145 | #### 🎯 **Paso 2: Configurar Cursor Rules** 146 | 147 | 1. **Busca "Cursor Rules"** en la barra de búsqueda de configuración 148 | 2. **Encuentra la opción**: `Cursor Rules: Rules for AI` 149 | 3. **Haz clic en "Edit in settings.json"** 150 | 151 | #### 🎯 **Paso 3: Agregar las Guidelines** 152 | 153 | 1. **Copia todo el contenido** del archivo `prompts/guidelines.md` 154 | 2. **Pega el contenido** en el campo `cursor.rules` 155 | 156 | **Ejemplo de configuración:** 157 | 158 | ```json 159 | { 160 | "cursor.rules": [ 161 | "# Persona\n\nEres reflexivo, das respuestas matizadas, y eres brillante en el razonamiento, pensando extra duro para proporcionar respuestas precisas y factuales.\n\n# Convenciones de Código\n\n## Mejores prácticas\n\n- Razona y comunícate con precisión militar.\n- Realiza actualizaciones quirúrgicas de código para lograr la solicitud del usuario (mínimamente invasivo, preciso y altamente efectivo).\n[...resto del contenido de guidelines.md...]" 162 | ] 163 | } 164 | ``` 165 | 166 | #### 🎯 **Paso 4: Alternativa Usando .cursorrules (Recomendado)** 167 | 168 | **Opción más fácil**: Crear un archivo `.cursorrules` en la raíz del proyecto: 169 | 170 | 1. **Crea un archivo** llamado `.cursorrules` en la raíz de tu proyecto 171 | 2. **Copia y pega** todo el contenido de `prompts/guidelines.md` en este archivo 172 | 3. **Guarda el archivo** 173 | 174 | ```bash 175 | # En la raíz del proyecto 176 | touch .cursorrules 177 | # Luego copia el contenido de prompts/guidelines.md a .cursorrules 178 | ``` 179 | 180 | ### ✅ **Verificación de Configuración** 181 | 182 | Para confirmar que la configuración funciona: 183 | 184 | 1. **Reinicia Cursor** después de hacer los cambios 185 | 2. **Abre una conversación con el AI** 186 | 3. **Haz una pregunta de prueba** sobre código 187 | 4. **Verifica** que el AI sigue las guías establecidas (precisión militar, principio DRY, etc.) 188 | 189 | ### 🔄 **Mantener las Guidelines Actualizadas** 190 | 191 | - **Cuando modifiques** `prompts/guidelines.md`, actualiza también tu configuración de Cursor 192 | - **Si usas** `.cursorrules`, simplemente copia el nuevo contenido 193 | - **Si usas** `settings.json`, actualiza el campo `cursor.rules` 194 | 195 | ### 🎯 **Consejos Pro** 196 | 197 | - ✅ **Usa .cursorrules**: Es más fácil de mantener y versionar 198 | - ✅ **Commítelo al repositorio**: Para que todo el equipo use las mismas reglas 199 | - ✅ **Revisa periódicamente**: Mantén las guidelines actualizadas con mejores prácticas 200 | 201 | --- 202 | 203 | ## 📚 Guía Paso a Paso 204 | 205 | ### Fase 1: Refinamiento de Instrucciones 206 | 207 | > 🎯 **Objetivo**: Optimizar las instrucciones principales del proyecto 208 | 209 | #### 📋 ¿Qué hacer? 210 | 211 | 1. **Revisa las instrucciones actuales** 212 | - Analiza las instrucciones en `prompts/instructions.md` 213 | - Identifica puntos ciegos y áreas de mejora 214 | 215 | 2. **Refina y optimiza** 216 | ``` 217 | ayúdame a refinar las instrucciones principales, revísalas y mejóralas, 218 | discute los puntos ciegos y actualízalas para alinearlas con el objetivo general. 219 | Esta es la tarea más importante ahora mismo, hay una gran recompensa si lo haces bien. 220 | Piensa extremadamente duro, toma todo el tiempo que necesites y asegúrate de 221 | que las instrucciones principales sean óptimas. 222 | ``` 223 | 224 | 3. **Valida los cambios** 225 | - Asegúrate de que las instrucciones sean claras 226 | - Verifica que estén alineadas con los objetivos del proyecto 227 | 228 | --- 229 | 230 | ### Fase 2: Documentación del Proyecto 231 | 232 | > 📝 **Objetivo**: Crear documentación completa y estructurada 233 | 234 | #### Paso 2.1: Especificaciones PRD 📋 235 | 236 | > **¿Qué es un PRD?** 237 | > 238 | > **PRD** significa **Product Requirements Document** (Documento de Requisitos del Producto). Es un documento fundamental que define: 239 | > - **QUÉ** se va a construir (funcionalidades y características) 240 | > - **POR QUÉ** se necesita (objetivos de negocio y usuario) 241 | > - **PARA QUIÉN** es el producto (usuarios objetivo) 242 | > - **CÓMO** debe comportarse (casos de uso y flujos) 243 | > 244 | > En AIxDev, el PRD sirve como la **base técnica** que guiará todo el desarrollo. 245 | 246 | ``` 247 | Sigue las instrucciones y escribe el paso 1 de documentación, Especificaciones PRD. 248 | Pregunta al usuario por cualquier cosa que necesites aclarar. 249 | Guárdalas y para cuando termines. 250 | ``` 251 | 252 | **✅ Criterios de éxito:** 253 | - [ ] Especificaciones técnicas completas 254 | - [ ] Arquitectura del sistema definida 255 | - [ ] Documentos guardados en `docs/specs/` 256 | 257 | #### Paso 2.2: Plan de Desarrollo 📈 258 | 259 | ``` 260 | Sigue las instrucciones y escribe el paso 2 de documentación, Plan. 261 | Guárdalo y para cuando termines. 262 | ``` 263 | 264 | **✅ Criterios de éxito:** 265 | - [ ] Hoja de ruta clara y detallada 266 | - [ ] Fases de desarrollo definidas 267 | - [ ] Plan guardado en `docs/plan.md` 268 | 269 | #### Paso 2.3: Creación de Tickets 🎫 270 | 271 | ``` 272 | Sigue las instrucciones y escribe cada ticket para el paso 3. 273 | Guárdalos y para cuando termines. 274 | ``` 275 | 276 | **✅ Criterios de éxito:** 277 | - [ ] Tickets individuales creados 278 | - [ ] Criterios de aceptación definidos 279 | - [ ] Tickets guardados en `tickets/` 280 | - [ ] Índice actualizado en `tickets/0000-index.md` 281 | 282 | --- 283 | 284 | ### Fase 3: Implementación 285 | 286 | > 🛠️ **Objetivo**: Ejecutar el desarrollo siguiendo los tickets 287 | 288 | #### 🎯 Flujo de Trabajo 289 | 290 | ``` 291 | trabaja en completar el ticket 0001, **solo completa un elemento individual 292 | (el siguiente disponible)**, asegúrate de que los criterios de aceptación se hayan 293 | cumplido para marcar la tarea como completada cuando progreses. Puedes referirte 294 | a las especificaciones correspondientes como referencia y guía. Cuando termines, 295 | actualiza el estado del ticket y cualquier archivo requerido. 296 | ``` 297 | 298 | #### 📝 Proceso de Implementación 299 | 300 | 1. **Selecciona el siguiente ticket disponible** 301 | - Revisa `tickets/0000-index.md` para ver el estado 302 | - Toma el primer ticket con estado "Abierto" 303 | 304 | 2. **Trabaja en el ticket** 305 | - Lee los criterios de aceptación 306 | - Consulta las especificaciones relacionadas 307 | - Implementa la funcionalidad requerida 308 | 309 | 3. **Valida y cierra** 310 | - Verifica que todos los criterios se cumplan 311 | - Actualiza el estado del ticket a "Completado" 312 | - Actualiza el índice de tickets 313 | 314 | --- 315 | 316 | ## 💡 Consejos y Mejores Prácticas 317 | 318 | ### 🎯 Para Documentación 319 | - **Sé específico**: Usa criterios de aceptación medibles 320 | - **Mantén coherencia**: Sigue las plantillas establecidas 321 | - **Documenta decisiones**: Explica el "por qué" de las decisiones técnicas 322 | 323 | ### 🛠️ Para Implementación 324 | - **Un ticket a la vez**: No trabajes en múltiples tickets simultáneamente 325 | - **Valida continuamente**: Revisa los criterios antes de marcar como completo 326 | - **Actualiza estados**: Mantén el índice de tickets actualizado 327 | 328 | ### 🤝 Para Colaboración 329 | - **Comunica cambios**: Documenta modificaciones importantes 330 | - **Pide clarificación**: No asumas, pregunta cuando tengas dudas 331 | - **Comparte contexto**: Proporciona información suficiente en los tickets 332 | 333 | ### 🤖 Para usar LLMs 334 | - **Contextualiza siempre**: Menciona que eres Linus y Carmack 335 | - **Pide múltiples perspectivas**: Combina pragmatismo y perfección técnica 336 | - **Itera constantemente**: Refina las respuestas hasta lograr excelencia 337 | 338 | --- 339 | 340 | ## ❓ Preguntas Frecuentes 341 | 342 | **P: ¿Qué hago si un ticket está bloqueado?** 343 | R: Marca el ticket como "Bloqueado" y documenta la razón. Trabaja en el siguiente ticket disponible. 344 | 345 | **P: ¿Puedo modificar un ticket existente?** 346 | R: Sí, pero documenta los cambios y las razones en la sección de comentarios del ticket. 347 | 348 | **P: ¿Cómo manejo dependencias entre tickets?** 349 | R: Usa las secciones "Bloquea" y "Bloqueado por" en cada ticket para gestionar dependencias. 350 | 351 | **P: ¿Por qué es importante configurar las guidelines en Cursor?** 352 | R: Las guidelines aseguran que el AI de Cursor siga las mejores prácticas de desarrollo, mantenga consistencia en el código y respete las convenciones del proyecto. 353 | 354 | **P: ¿Por qué Linus Torvalds y John Carmack específicamente?** 355 | R: Linus aporta pragmatismo, simplicidad y experiencia en gestión de proyectos masivos. Carmack aporta precisión técnica, optimización y arquitecturas innovadoras. Juntos representan el equilibrio perfecto entre funcionalidad y excelencia técnica. 356 | 357 | **P: ¿Cómo sé si el LLM está aplicando correctamente las personalidades?** 358 | R: Busca respuestas que combinen simplicidad práctica (Linus) con perfección técnica (Carmack), código limpio, decisiones fundamentadas y explicaciones claras del "por qué". 359 | 360 | --- 361 | 362 | ## 🔧 Solución de Problemas 363 | 364 | ### Problema: No sé por dónde empezar 365 | **Solución**: Comienza siempre con la Fase 1 (Refinamiento de Instrucciones) y sigue el orden secuencial. 366 | 367 | ### Problema: Los criterios de aceptación no están claros 368 | **Solución**: Regresa a la documentación de especificaciones o solicita clarificación antes de continuar. 369 | 370 | ### Problema: Un ticket parece demasiado grande 371 | **Solución**: Considera dividirlo en sub-tareas más pequeñas dentro del mismo ticket. 372 | 373 | ### Problema: Cursor no sigue las guidelines 374 | **Solución**: Verifica que hayas configurado correctamente el archivo `.cursorrules` o las reglas en settings.json. 375 | 376 | ### Problema: El LLM no actúa como Linus/Carmack 377 | **Solución**: Refuerza el contexto en cada consulta: "Eres Linus Torvalds y John Carmack, necesito que..." 378 | 379 | --- 380 | 381 | ## 🎉 ¡Empezar es Fácil! 382 | 383 | 1. **📋 Configura Cursor** con las guidelines del proyecto 384 | 2. **📖 Lee esta guía completa** 385 | 3. **🤖 Familiarízate** con el uso de LLMs y las personalidades de Linus/Carmack 386 | 4. **🚀 Comienza con la Fase 1** (Refinamiento de Instrucciones) 387 | 5. **📝 Sigue el proceso paso a paso** 388 | 6. **🔄 Mantén la documentación actualizada** 389 | 390 | > 💡 **Recuerda**: AIxDev es un proceso iterativo potenciado por LLMs. Cada ciclo te ayudará a mejorar la calidad y eficiencia de tus proyectos, combinando la sabiduría de dos genios legendarios del desarrollo de software. 391 | 392 | --- 393 | 394 | ## 📖 Glosario de Términos 395 | 396 | ### 🔤 **Términos Técnicos** 397 | 398 | **PRD** - *Product Requirements Document* 399 | > Documento de Requisitos del Producto que define QUÉ, POR QUÉ, PARA QUIÉN y CÓMO del proyecto. 400 | 401 | **LLM** - *Large Language Model* 402 | > Modelos de Lenguaje Grande como Claude, GPT, etc. que potencian AIxDev. 403 | 404 | **DRY** - *Don't Repeat Yourself* 405 | > Principio de programación que evita la duplicación de código y lógica. 406 | 407 | **Cursor Rules** - *Reglas de Cursor* 408 | > Configuración que define cómo debe comportarse el AI de Cursor en tu proyecto. 409 | 410 | ### 🎭 **Personalidades Legendarias** 411 | 412 | **Linus Torvalds** 413 | > Creador de Linux y Git. Aporta pragmatismo, simplicidad y gestión de proyectos masivos. 414 | 415 | **John Carmack** 416 | > Pionero de gráficos 3D. Aporta precisión técnica, optimización y arquitecturas innovadoras. 417 | 418 | ### 📋 **Metodología AIxDev** 419 | 420 | **Tickets** 421 | > Unidades individuales de trabajo con criterios de aceptación específicos. 422 | 423 | **Criterios de Aceptación** 424 | > Condiciones específicas que deben cumplirse para considerar un ticket como completado. 425 | 426 | **Specs** - *Specifications* 427 | > Especificaciones técnicas detalladas que definen la arquitectura del sistema. 428 | 429 | **Pair Programming** 430 | > Técnica de desarrollo donde dos personas trabajan juntas en el mismo código (en nuestro caso, humano + LLM). 431 | 432 | ### 🔧 **Herramientas** 433 | 434 | **Cursor AI** 435 | > Editor de código potenciado por AI que puede seguir reglas específicas del proyecto. 436 | 437 | **GitHub Copilot** 438 | > Asistente de código de GitHub que sugiere código en tiempo real. 439 | 440 | **Claude/GPT** 441 | > Modelos de lenguaje para consultas complejas y planificación arquitectónica. 442 | 443 | --- 444 | 445 | **¿Listo para construir algo increíble juntos con la ayuda de los maestros? ¡Empecemos! 🚀** 446 | --------------------------------------------------------------------------------