trackops 1.0.0

package/templates/opera/references/opera-cycle.md

@@ -0,0 +1,193 @@
+# El Ciclo O.P.E.R.A. — Referencia Completa
+
+Este documento detalla cada fase del ciclo con sus reglas, procedimientos y Definitions of Done.
+
+---
+
+## 1️⃣ O — Orquestar (Visión y Lógica)
+
+### Descubrimiento
+
+Haz al usuario las 5 preguntas clave:
+
+1. **Directriz Principal**: ¿Cuál es el resultado singular deseado?
+2. **Integraciones**: ¿Qué servicios externos necesitamos? ¿Están listas las claves?
+3. **Fuente de la Verdad**: ¿Dónde viven los datos primarios?
+4. **Carga Útil (Payload)**: ¿Cómo y dónde debe entregarse el resultado final?
+5. **Reglas de Comportamiento**: Restricciones o tono específico.
+
+### Regla "Datos-Primero"
+
+Antes de pasar a la siguiente fase, DEBES definir el **Esquema de Datos JSON** (Input/Output) en `genesis.md`.
+
+Ejemplo de schema en genesis.md:
+
+```json
+{
+  "input": {
+    "source": "API externa",
+    "schema": {
+      "id": "string (UUID)",
+      "timestamp": "ISO 8601",
+      "data": "object"
+    }
+  },
+  "output": {
+    "destination": "webhook POST",
+    "schema": {
+      "processed_id": "string (UUID)",
+      "result": "object",
+      "status": "enum: success|error"
+    }
+  }
+}
+```
+
+### Definition of Done — Fase O
+
+- [ ] Las 5 preguntas de descubrimiento están respondidas.
+- [ ] Esquema JSON de Input/Output definido en `genesis.md`.
+- [ ] Reglas de comportamiento documentadas en `genesis.md`.
+- [ ] `task_plan.md` tiene plano aprobado por el usuario.
+
+---
+
+## 2️⃣ P — Probar (Conectividad)
+
+Verifica las tuberías antes de pasar el agua. El objetivo es confirmar que todos los servicios externos responden y devuelven datos con la forma esperada.
+
+### Procedimiento
+
+1. **Verificación de credenciales**: Lee `.env` y confirma que todas las claves necesarias existen y no están vacías.
+2. **Handshake**: Construye scripts mínimos en `tools/` (ej: `test_api.py`) para verificar cada servicio.
+3. **Validación de Shape**: No basta con un HTTP 200. Verifica que la respuesta coincide con el schema definido en `genesis.md`. Compara campos, tipos de datos y estructura.
+4. **Bloqueo**: Si algún test falla, NO procedas a la fase de Estructurar. Documenta el fallo en `findings.md`.
+
+### Ejemplo de test mínimo
+
+```python
+# tools/test_api.py
+import os
+import requests
+
+API_KEY = os.getenv("API_KEY")
+BASE_URL = os.getenv("API_BASE_URL")
+
+def test_connection():
+    """Verifica conexión y shape de respuesta."""
+    response = requests.get(f"{BASE_URL}/health", headers={"Authorization": f"Bearer {API_KEY}"})
+    assert response.status_code == 200, f"Expected 200, got {response.status_code}"
+    data = response.json()
+    assert "id" in data, "Missing 'id' field in response"
+    assert "status" in data, "Missing 'status' field in response"
+    print("✅ API connection and shape validated")
+
+if __name__ == "__main__":
+    test_connection()
+```
+
+### Definition of Done — Fase P
+
+- [ ] Todas las credenciales `.env` verificadas (existen y no están vacías).
+- [ ] Scripts `test_*.py` ejecutados y pasando.
+- [ ] Respuestas de APIs validadas contra el schema de `genesis.md`.
+- [ ] Resultados documentados en `findings.md`.
+
+---
+
+## 3️⃣ E — Estructurar (La Construcción de 3 Capas)
+
+### Capa 1: Arquitectura (`architecture/`)
+
+SOPs (Standard Operating Procedures) técnicos en Markdown. Cada SOP define:
+
+- Propósito del script.
+- Entradas esperadas (con referencia al schema en `genesis.md`).
+- Salidas producidas.
+- Casos extremos y cómo manejarlos.
+- Dependencias con otras herramientas.
+
+**Regla**: Si la lógica cambia, actualiza el SOP **antes** que el código.
+
+### Capa 2: Navegación (El Agente)
+
+Capa de razonamiento. Enruta datos entre SOPs y herramientas. No ejecuta lógica de negocio directamente; delega a los scripts.
+
+### Capa 3: Herramientas (`tools/`)
+
+- Scripts atómicos y deterministas.
+- Las variables de entorno van en `.env`.
+- Usa `.tmp/` para todas las operaciones intermedias.
+- Cada script hace UNA cosa bien.
+
+### Regla de Idempotencia
+
+Toda herramienta DEBE ser idempotente. Herramientas con side-effects irreversibles se marcan:
+
+```python
+# META: side-effect: true
+# META: idempotent: false
+# META: requires-confirmation: true
+```
+
+### Grafo de Dependencias
+
+Si una herramienta produce output que consume otra, documéntalo en `genesis.md` bajo `## Pipeline`:
+
+```markdown
+## Pipeline
+### tool_fetch.py → tool_transform.py
+- Output: `.tmp/raw_data.json`
+- Formato: JSON array según schema X
+```
+
+### Definition of Done — Fase E
+
+- [ ] SOPs escritos en `architecture/` para cada herramienta.
+- [ ] Scripts implementados en `tools/`.
+- [ ] Grafo de dependencias documentado en `genesis.md`.
+- [ ] Tests de integración entre herramientas pasando.
+- [ ] Herramientas con side-effects marcadas con META tags.
+
+---
+
+## 4️⃣ R — Refinar (Refinamiento)
+
+### Templates de Output
+
+Toda salida del sistema se valida contra una plantilla definida en `templates/`. Las plantillas se referencian desde `genesis.md` bajo `## Templates`.
+
+El refinamiento no es subjetivo; es verificable contra una plantilla. Si el output no coincide con el template, no pasa.
+
+### Refinamiento de Carga Útil
+
+Formatea todas las salidas (Markdown, HTML, JSON limpio) para entrega profesional según lo definido en `genesis.md`.
+
+### UX/UI
+
+Si el proyecto tiene interfaz, aplica diseños limpios e intuitivos según las especificaciones.
+
+### Definition of Done — Fase R
+
+- [ ] Todas las salidas validadas contra sus templates en `templates/`.
+- [ ] Formatos de entrega (Markdown, HTML, JSON) verificados.
+- [ ] Si hay interfaz: revisión visual completada.
+
+---
+
+## 5️⃣ A — Automatizar (Despliegue)
+
+### Procedimiento
+
+1. **Limpieza**: Elimina residuos de `.tmp/`.
+2. **Transferencia**: Mueve la lógica finalizada a producción/nube.
+3. **Configuración**: Establece los disparadores (Cron, Webhooks).
+4. **Smoke Test**: Verificación mínima en el entorno de producción.
+
+### Definition of Done — Fase A
+
+- [ ] `.tmp/` limpio (sin archivos residuales).
+- [ ] Código desplegado en destino final.
+- [ ] Triggers configurados y verificados.
+- [ ] Smoke test en producción pasando.
+- [ ] `progress.md` actualizado con estado final.

package/templates/opera/registry.md

@@ -0,0 +1,28 @@
+# Skills Registry — {{PROJECT_NAME}}
+
+> Índice de skills instaladas en este proyecto. Gestionado automáticamente por `trackops skill`.
+
+---
+
+## Skills Instaladas
+
+_Sin skills instaladas. Usa `trackops skill install <nombre>` para añadir una._
+
+---
+
+## Cómo Usar una Skill
+
+1. Identifica el contexto en `.agent/hub/router.md`.
+2. Abre el archivo `SKILL.md` de la skill correspondiente.
+3. Sigue las instrucciones del protocolo definido en la skill.
+
+---
+
+## Gestión
+
+```bash
+trackops skill list          # Ver skills instaladas
+trackops skill catalog       # Ver skills disponibles
+trackops skill install <n>   # Instalar una skill
+trackops skill remove <n>    # Desinstalar una skill
+```

package/templates/opera/router.md

@@ -0,0 +1,39 @@
+# Router de Skills
+
+## Propósito
+Este archivo define las reglas de enrutamiento entre el agente principal y las skills disponibles. Cuando el agente detecta un contexto específico, consulta estas reglas para decidir qué skill invocar.
+
+## Reglas de Enrutamiento
+
+### Contexto: Commit de código
+- **Trigger**: El usuario pide hacer un commit o se completa un cambio de código.
+- **Skill**: `commiter`
+- **Acción**: Consulta la skill para formatear el mensaje de commit.
+
+### Contexto: Post-commit
+- **Trigger**: Se acaba de realizar un commit exitoso.
+- **Skill**: `changelog-updater`
+- **Acción**: Ejecuta el script de actualización del changelog.
+
+### Contexto: Inicialización de proyecto
+- **Trigger**: El usuario quiere crear un nuevo proyecto.
+- **Skill**: `project-starter-skill` (global)
+- **Acción**: Ejecutar el protocolo de inicialización completo.
+
+### Contexto: Seguimiento operativo
+- **Trigger**: Se va a empezar, retomar o cerrar un bloque de trabajo.
+- **Skill**: No aplica skill externa.
+- **Acción**: Ejecutar `trackops status`, tomar la siguiente tarea con `trackops next` y mantener `project_control.json` como fuente de verdad operativa.
+
+## Cómo Añadir Nuevas Reglas
+
+Cada regla sigue este formato:
+
+```markdown
+### Contexto: [descripción]
+- **Trigger**: [qué activa la regla]
+- **Skill**: [nombre de la skill]
+- **Acción**: [qué debe hacer el agente]
+```
+
+Al instalar una nueva skill con `trackops skill install <nombre>`, añade su regla de enrutamiento aquí.

package/templates/skills/changelog-updater/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: "changelog-updater"
+description: "Herramienta automatizada para actualizar el archivo CHANGELOG.md basándose en el último commit realizado. Usa esta skill inmediatamente después de confirmar un commit para mantener el historial de cambios al día. Se activa con 'actualizar changelog', 'registrar cambio', 'update changelog', o automáticamente tras un commit exitoso cuando el router lo indique."
+metadata:
+  version: "1.0"
+  type: "project"
+  triggers:
+    - "actualizar changelog"
+    - "registrar cambio"
+    - "update changelog"
+    - "post-commit"
+---
+
+# Actualizador de Changelog
+
+Esta skill mantiene actualizado el archivo `CHANGELOG.md` del proyecto de forma automática, leyendo la información directamente desde el historial de git.
+
+## Cuándo Usar
+
+Usa esta skill **inmediatamente después de realizar un commit** exitoso. El router debería activarla automáticamente tras detectar un commit, pero también puede invocarse manualmente.
+
+## Qué Hace
+
+1. Obtiene el último commit del repositorio via `git log`.
+2. Analiza el mensaje buscando el patrón de **Conventional Commits** (con soporte para emojis al inicio).
+3. Formatea una nueva entrada para `CHANGELOG.md` incluyendo:
+   - Emoji correspondiente al tipo de cambio.
+   - Ámbito (scope) si existe.
+   - Descripción del cambio.
+   - Hash corto del commit (7 caracteres).
+4. Inserta la entrada en la sección correspondiente a la fecha actual (`YYYY-MM-DD`).
+5. Si no existe `CHANGELOG.md`, lo crea con la estructura base.
+
+## Mapeo de Emojis
+
+El script reconoce estos tipos de commit y asigna sus emojis:
+
+| Tipo | Emoji | Descripción |
+| :--- | :---: | :--- |
+| `feat` | ✨ | Nueva característica |
+| `fix` | 🐛 | Corrección de errores |
+| `docs` | 📚 | Documentación |
+| `style` | 💄 | Estilos y formato |
+| `refactor` | ♻️ | Refactorización de código |
+| `perf` | ⚡ | Mejoras de rendimiento |
+| `test` | ✅ | Tests |
+| `build` | 📦 | Build y dependencias |
+| `ci` | 👷 | Integración continua |
+| `chore` | 🔧 | Tareas de mantenimiento |
+| `revert` | ⏪ | Reversión de cambios |
+
+Commits que no sigan el formato Conventional Commits se registran como "Misc".
+
+## Flujo de Trabajo Recomendado
+
+1. Realiza tus cambios en el código.
+2. Haz el commit siguiendo las convenciones (usa la skill `commiter`).
+3. Actualiza el changelog manualmente o via script si está configurado.
+
+## Requisitos
+
+- Repositorio git inicializado con al menos un commit.
+- El script se ejecuta desde la raíz del proyecto.
+
+## Manejo de Errores
+
+- Si no hay commits en el repo, el script muestra un mensaje informativo y no modifica nada.
+- Si `git` no está disponible, el script reporta el error y termina.
+- Si el `CHANGELOG.md` tiene una estructura inesperada, añade la entrada al final como fallback.

package/templates/skills/commiter/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: "commiter"
+description: "Guía para generar mensajes de commit en español siguiendo Conventional Commits estrictos con Emojis. Usa esta skill siempre que el usuario pida hacer un commit, generar un mensaje de commit, commitear cambios, o cuando se complete un cambio de código y sea momento de registrarlo en git. También se activa con 'commit', 'commitear', 'guardar cambios', 'registrar cambios' o cualquier intención de crear un punto en el historial de git."
+metadata:
+  version: "1.0"
+  type: "project"
+  triggers:
+    - "commit"
+    - "commitear"
+    - "guardar cambios"
+    - "registrar cambios"
+    - "hacer commit"
+    - "git commit"
+---
+
+# Generador de Commits
+
+Cuando se te pida realizar un commit o generar un mensaje de commit, DEBES seguir estrictamente este formato.
+
+## Estándar: Conventional Commits con Emojis
+
+Utilizamos **Conventional Commits** enriquecidos con **Gitmoji** como base. Todo el contenido debe estar en **ESPAÑOL**.
+
+## Formato
+
+```text
+<emoji> <tipo>(<alcance>): <descripción corta>
+
+<cuerpo detallado y extenso>
+
+<footer>
+```
+
+## Reglas Obligatorias
+
+1. **Emoji**: El mensaje DEBE comenzar con el emoji correspondiente al tipo de cambio.
+2. **Idioma**: Todo el contenido del commit (descripción y cuerpo) debe estar en **ESPAÑOL**.
+3. **Límite del Título**: La primera línea (asunto) **NO debe exceder los 50 caracteres** (sin contar el emoji). Sé conciso.
+4. **Descripción Extensa**: El cuerpo del mensaje es **OBLIGATORIO**. Debes explicar detalladamente:
+   - **Qué** se ha cambiado.
+   - **Por qué** se ha hecho el cambio.
+   - Detalles técnicos relevantes de la implementación.
+5. **Tiempos Verbales**: Usa el modo imperativo en el asunto (ej: "agrega", "corrige", "cambia"), no en pasado.
+
+## Tipos Permitidos y Emojis
+
+| Emoji | Tipo | Descripción |
+| :---: | :--- | :--- |
+| ✨ | `feat` | Nueva característica (correlaciona con MINOR en SemVer). |
+| 🐛 | `fix` | Corrección de un bug (correlaciona con PATCH en SemVer). |
+| 📚 | `docs` | Cambios en la documentación. |
+| 💄 | `style` | Cambios que no afectan el significado del código (espacios, formato, etc). |
+| ♻️ | `refactor` | Cambio de código que no corrige bugs ni añade funcionalidades. |
+| ⚡ | `perf` | Cambio de código que mejora el rendimiento. |
+| ✅ | `test` | Añadir tests faltantes o corregir existentes. |
+| 📦 | `build` | Cambios que afectan el sistema de construcción o dependencias externas. |
+| 👷 | `ci` | Cambios en archivos de configuración y scripts de CI. |
+| 🔧 | `chore` | Otros cambios que no modifican src o test files (ej. config de herramientas). |
+| ⏪ | `revert` | Reversión de un commit anterior. |
+
+## Procedimiento
+
+Cuando el usuario pida hacer commit:
+
+1. **Analiza los cambios**: Revisa qué archivos se modificaron y qué tipo de cambio representan.
+2. **Selecciona el tipo**: Elige el tipo de commit más apropiado de la tabla.
+3. **Define el alcance**: Identifica el módulo o componente afectado (opcional pero recomendado).
+4. **Redacta el asunto**: Máximo 50 caracteres, imperativo, en español.
+5. **Redacta el cuerpo**: Explica qué, por qué y detalles técnicos. Es obligatorio.
+6. **Ejecuta el commit**: Usa `git commit -m` con el formato completo.
+
+## Ejemplo Correcto
+
+```text
+✨ feat(auth): integra login social con Google
+
+Se ha implementado la autenticación mediante OAuth2 con Google para facilitar
+el acceso a nuevos usuarios.
+
+Cambios principales:
+- Agrega configuración de estrategia de Passport.js para Google.
+- Crea nuevas rutas de callback en el controlador de autenticación.
+- Actualiza el modelo de Usuario para almacenar el providerId.
+- Ajusta la interfaz de login para incluir el botón de "Entrar con Google".
+
+Motivación:
+Reducir la fricción en el registro de usuarios y aumentar la conversión.
+```
+
+## Errores Comunes a Evitar
+
+- `fix: error login` → Falta emoji, título vago, sin cuerpo.
+- `🐛 Fix: arregla login` → Tipo en mayúscula, lo correcto es minúscula `fix`.
+- `✨ feat(user): Update user logic` → En inglés, debe ser en español.
+- Título que excede 50 caracteres → Acorta y mueve el detalle al cuerpo.
+
+## Integración con el Workflow
+
+Después de ejecutar un commit exitoso, el router debe activar la skill `changelog-updater` para registrar el cambio automáticamente en `CHANGELOG.md`.

package/templates/skills/project-starter-skill/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: "project-starter-skill"
+description: "Skill global para inicializar proyectos completos usando el protocolo O.P.E.R.A. (Orquestar, Probar, Estructurar, Refinar, Automatizar). Usa esta skill siempre que el usuario quiera crear un nuevo proyecto, inicializar una estructura de agente, configurar un repositorio, o arrancar cualquier automatización desde cero. También se activa cuando el usuario menciona 'nuevo proyecto', 'iniciar proyecto', 'configurar proyecto', 'opera', 'project starter', 'scaffold', o cualquier intención de comenzar algo nuevo que necesite estructura."
+metadata:
+  version: "3.0"
+  type: "global"
+  triggers:
+    - "iniciar proyecto"
+    - "nuevo proyecto"
+    - "configurar proyecto"
+    - "opera"
+    - "project starter"
+    - "scaffold"
+    - "inicializar"
+---
+
+# 🚀 ProjectStarterSkill — O.P.E.R.A. v3.0
+
+## Identidad
+
+Eres el **Piloto del Sistema**. Tu misión es construir automatización determinista y autorreparable usando el protocolo O.P.E.R.A.
+
+## Filosofía
+
+- Fiabilidad sobre velocidad. Nunca adivines lógica de negocio.
+- Los LLMs son probabilísticos, pero tu código debe ser **determinista**.
+- Cada fase tiene un **Definition of Done** verificable. No avanzas sin cumplirlo.
+- `genesis.md` es la ley. Si un script la contradice, el script está mal.
+
+---
+
+## Protocolo de Inicialización
+
+Este protocolo se ejecuta secuencialmente y sin excepciones al crear un nuevo proyecto.
+
+### Paso 1 — Descubrimiento
+
+Antes de crear cualquier archivo, haz al usuario estas preguntas:
+
+| # | Pregunta | Propósito |
+|---|----------|-----------|
+| 1 | ¿Cuál es el resultado singular deseado? | Directriz principal |
+| 2 | ¿Qué servicios externos necesitamos? ¿Están listas las claves? | Integraciones |
+| 3 | ¿Dónde viven los datos primarios? | Fuente de la verdad |
+| 4 | ¿Cómo y dónde debe entregarse el resultado final? | Carga útil |
+| 5 | ¿Restricciones, tono o reglas específicas? | Reglas de comportamiento |
+
+También pregunta:
+- ¿Repositorio **público o privado**?
+- ¿Tipo de **licencia**? (MIT, Apache 2.0, GPL v3, Propietario)
+
+### Paso 2 — Inicialización con Ops
+
+Ejecuta la inicialización del sistema operativo:
+
+```bash
+npx trackops init --with-opera
+```
+
+Esto crea `project_control.json`, instala OPERA y registra el proyecto.
+
+### Paso 3 — Poblar genesis.md
+
+Con las respuestas del descubrimiento, completa `genesis.md` con:
+
+1. **Esquema de Datos JSON** (Input/Output) — esto es obligatorio antes de escribir código.
+2. **Reglas de comportamiento** — restricciones de negocio.
+3. **Invariantes arquitectónicas** — decisiones técnicas inamovibles.
+
+Esto es la regla "Datos-Primero": si el schema no está definido en `genesis.md`, no se escribe código.
+
+### Paso 4 — Completar task_plan.md
+
+Ejecuta `trackops sync` para regenerar `task_plan.md` y luego ajusta:
+- Fases y objetivos.
+- **Definition of Done** por cada fase (ver referencia `references/opera-cycle.md`).
+- Checklist verificable.
+
+### Paso 5 — Skills Base
+
+1. Instala las skills obligatorias:
+   ```bash
+   trackops skill install commiter
+   trackops skill install changelog-updater
+   ```
+2. Analiza la definición del proyecto en `genesis.md`.
+3. Busca skills adicionales con `trackops skill catalog` y **recomienda** (no instales sin aprobación) las que apliquen.
+
+### Paso 6 — Repositorio
+
+1. Crea el repositorio en GitHub (público o privado según elección).
+2. Genera `README.md` con la descripción del proyecto basada en `genesis.md`.
+3. Crea `LICENSE` según la elección del usuario.
+4. Inicializa `CHANGELOG.md` con entrada de creación.
+5. Realiza el primer commit (usa la skill `commiter`).
+
+### Paso 7 — Freno de Mano 🛑
+
+Tienes **prohibido** escribir scripts en `tools/` hasta que:
+
+- [ ] Las preguntas de descubrimiento estén respondidas.
+- [ ] El esquema de datos esté definido en `genesis.md`.
+- [ ] `task_plan.md` tenga un plano aprobado con Definition of Done.
+- [ ] La estructura `.agent/` y `.agents/` esté creada.
+- [ ] El repositorio esté inicializado.
+
+---
+
+## El Ciclo O.P.E.R.A.
+
+Una vez completada la inicialización, el proyecto avanza a través de las fases definidas. Para el detalle completo de cada fase, lee:
+```
+references/opera-cycle.md
+```
+
+### Resumen de Fases OPERA
+
+| Fase | Nombre | Foco | Entregable clave |
+|------|--------|------|-------------------|
+| **O** | Orquestar | Visión y lógica | Schema JSON en `genesis.md` |
+| **P** | Probar | Conectividad | Scripts de test pasando |
+| **E** | Estructurar | Construcción en 3 capas | SOPs + tools + tests de integración |
+| **R** | Refinar | Refinamiento | Outputs validados contra templates |
+| **A** | Automatizar | Despliegue | Triggers configurados + smoke test |
+
+### La Arquitectura de 3 Capas
+
+| Capa | Ubicación | Función |
+|------|-----------|---------|
+| Arquitectura | `architecture/` | SOPs técnicos en Markdown. Si la lógica cambia, actualiza el SOP **antes** que el código. |
+| Navegación | El Agente | Capa de razonamiento. Enruta datos entre SOPs y herramientas. |
+| Herramientas | `tools/` | Scripts atómicos y deterministas. Variables en `.env`. Temporales en `.tmp/`. |
+
+---
+
+## Gobernanza y Recuperación
+
+Para la matriz de autonomía (semáforo), el protocolo de auto-reparación y el sistema de rollback, lee:
+```
+references/autonomy-and-recovery.md
+```
+
+### Resumen Rápido
+
+**🔴 NIVEL ROJO** (Pide permiso): Modificar `genesis.md`, eliminar datos persistentes, desplegar a producción, enviar comunicaciones externas, crear repos.
+
+**🟢 NIVEL VERDE** (Avanza): Crear/editar scripts, leer archivos, ejecutar tests, actualizar logs, auto-reparar (máx. 3 intentos).
+
+---
+
+## Estructura de Archivos
+
+```
+proyecto/
+├── .agent/
+│   ├── hub/
+│   │   ├── agent.md              # Instrucciones del agente
+│   │   └── router.md             # Enrutamiento a skills
+│   └── skills/
+│       └── _registry.md          # Índice de skills instaladas
+├── .agents/
+│   └── skills/
+│       └── [skill-name]/
+│           └── SKILL.md          # Contenido de skills
+├── genesis.md                    # 📜 La Constitución
+├── task_plan.md                  # 🗺️ El Mapa (autogenerado)
+├── progress.md                   # 📓 El Diario (autogenerado)
+├── findings.md                   # 📖 La Biblioteca (autogenerado)
+├── CHANGELOG.md                  # 📋 El Historial
+├── architecture/                 # 📘 El Manual (SOPs)
+├── tools/                        # ⚙️ Los Motores
+├── templates/                    # 📐 Las Plantillas
+├── .tmp/                         # 🔧 El Taller
+├── .env                          # 🔑 Las Llaves
+├── project_control.json          # 🎛️ Control Operativo
+├── README.md
+├── LICENSE
+└── .gitignore
+```
+
+---
+
+## Checklist de Inicialización
+
+```markdown
+- [ ] Preguntas de descubrimiento respondidas
+- [ ] trackops init ejecutado
+- [ ] genesis.md poblado con schema y reglas
+- [ ] task_plan.md con Definition of Done por fase
+- [ ] progress.md generado
+- [ ] findings.md generado
+- [ ] .agent/hub/agent.md configurado
+- [ ] .agent/hub/router.md configurado
+- [ ] .agent/skills/_registry.md creado
+- [ ] Skills base instaladas (commiter, changelog-updater)
+- [ ] Repositorio GitHub creado
+- [ ] README.md generado
+- [ ] LICENSE creada
+- [ ] CHANGELOG.md inicializado
+- [ ] .gitignore configurado
+- [ ] Primer commit realizado
+```