@cristiancorreau/forge 2.1.0

package/assets/core/skills/obsidian-sync/SKILL.md

@@ -0,0 +1,152 @@
+# Skill: obsidian-sync
+
+Mantiene un vault de Obsidian sincronizado con el código del proyecto.
+Skill de integración — requiere Obsidian corriendo localmente con el plugin Local REST API.
+
+Triggers: /obsidian-sync, "actualizar obsidian", "sync vault", "documentar cambios",
+"nota diaria", "actualizar docs", "actualizar vault".
+
+---
+
+## Prerequisitos
+
+1. **Obsidian corriendo** con el plugin "Local REST API" activo.
+2. **Token configurado** — en `.env.local` o en `settings.local.json`:
+   ```
+   OBSIDIAN_TOKEN=<tu-token>
+   OBSIDIAN_API=http://127.0.0.1:27123
+   ```
+3. **Vault path configurado** en `project.yaml`:
+   ```yaml
+   integrations:
+     obsidian:
+       vault_path: "docs/mi-vault"   # relativo a la raíz del proyecto
+       map:                           # área modificada → nota del vault a actualizar
+         api: "03-api/endpoints.md"
+         database: "02-base-de-datos/migraciones.md"
+         frontend: "01-arquitectura/componentes.md"
+         deploy: "06-deploy/ci-cd.md"
+         decisions: "08-decisiones/log-decisiones.md"
+   ```
+
+---
+
+## Comandos MCP del plugin Local REST API
+
+```bash
+TOKEN=$OBSIDIAN_TOKEN
+API=http://127.0.0.1:27123
+
+# Leer una nota
+curl -s -H "Authorization: Bearer $TOKEN" "$API/vault/<ruta-nota>.md"
+
+# Reemplazar una nota completa (PUT)
+curl -X PUT \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: text/markdown" \
+  --data-binary "contenido" \
+  "$API/vault/<ruta-nota>.md"
+
+# Agregar al final de una nota (PATCH)
+curl -X PATCH \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: text/markdown" \
+  --data-binary "\n## Nuevo contenido" \
+  "$API/vault/<ruta-nota>.md"
+```
+
+---
+
+## Flujo de sync
+
+### 1. Identificar qué cambió
+
+```bash
+git log --oneline --since="today" 2>/dev/null || git log --oneline -5
+git diff --name-only HEAD~1 HEAD
+```
+
+### 2. Mapear cambios → notas del vault
+
+Usar el mapa configurado en `project.yaml` (`integrations.obsidian.map`).
+Si no hay mapa configurado, usar criterio propio:
+
+| Tipo de cambio | Nota típica a actualizar |
+|---------------|--------------------------|
+| Nuevos endpoints de API | sección de API del vault |
+| Cambios en schema de BD | sección de base de datos / migraciones |
+| Nuevas páginas o componentes | sección de arquitectura / UI |
+| Deploy / infra | sección de deploy / CI-CD |
+| Decisión de arquitectura | log de decisiones / ADRs |
+
+### 3. Leer nota actual → actualizar → verificar
+
+```bash
+# 1. Leer estado actual
+curl -s -H "Authorization: Bearer $TOKEN" "$API/vault/<ruta>.md"
+
+# 2. Preparar contenido actualizado (mantener lo que ya había, agregar lo nuevo)
+
+# 3. Escribir con PUT o PATCH según si reemplaza o agrega
+```
+
+### 4. Crear o actualizar nota diaria
+
+```bash
+DATE=$(date +%Y-%m-%d)
+curl -X PUT \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: text/markdown" \
+  --data-binary "# $DATE
+
+## Implementado
+- [listar cambios del día]
+
+## Archivos modificados
+$(git diff --name-only HEAD~1 HEAD | sed 's/^/- /')
+
+## Commits
+$(git log --oneline --since="today")
+
+## Decisiones
+- [si se tomó alguna decisión de arquitectura]
+
+## Pendiente
+- [si quedó algo sin terminar]
+" \
+  "$API/vault/daily-notes/$DATE.md"
+```
+
+---
+
+## Template de ADR (para sección de decisiones)
+
+Si la implementación implicó una decisión de arquitectura no documentada:
+
+```markdown
+## ADR-NNN — Título de la decisión (YYYY-MM-DD)
+
+**Contexto**: Por qué se necesitó tomar esta decisión.
+
+**Decisión**: Qué se decidió hacer exactamente.
+
+**Alternativas descartadas**: Qué otras opciones se evaluaron.
+
+**Consecuencias**: Qué implica esta decisión hacia adelante.
+```
+
+---
+
+## Cuándo NO usar este skill
+
+- Si Obsidian no está corriendo localmente → skip, no falla el flujo
+- Si el proyecto no tiene `integrations.obsidian` en `project.yaml` → skip
+- Si el cambio es trivial (fix de typo, cambio de style) → skip
+
+---
+
+## Relación con otros skills
+
+- Es invocado opcionalmente por `new-feature` (Fase 6) y `local2prod` (Paso 5).
+- Es una integración opcional — si no está configurada, los skills que la invocan la saltean.
+- No invoca otros skills.

package/assets/core/skills/phase-kickoff/SKILL.md

@@ -0,0 +1,69 @@
+# Skill: phase-kickoff
+
+Protocolo para iniciar una nueva fase de desarrollo en un proyecto forge.
+Activar al comienzo de cada sprint o fase nueva.
+
+---
+
+## Cuándo usar este skill
+
+Al iniciar trabajo en una nueva fase o sprint del proyecto.
+
+---
+
+## Pasos del kickoff
+
+### 1. Revisar el estado actual
+
+```bash
+# Ver qué está en curso y qué falta
+cat CLAUDE.md | grep -A 10 "Phases activas"
+ls docs/specs/
+git log --oneline -10
+```
+
+### 2. Leer specs de la fase
+
+Para cada spec de la fase que empieza:
+- Leer el archivo en `docs/specs/[ID]-[nombre].md`
+- Verificar que el estado sea `APPROVED` (no `DRAFT`)
+- Verificar que las dependencias estén implementadas
+
+### 3. Identificar dependencias entre specs
+
+Antes de asignar trabajo, mapear cuáles specs deben ir en qué orden:
+
+```
+Ejemplo:
+  A1 (schema) → A2 (consent store) → B1 (banner)
+  A1 (schema) → A3 (vendor catalog) [paralelo con A2]
+```
+
+### 4. Spawnear el team
+
+Con el mapa de dependencias claro:
+- Specs sin dependencias → pueden ir en paralelo (background agents)
+- Specs con dependencias → secuenciales o con SendMessage de coordinación
+
+### 5. Actualizar CLAUDE.md
+
+Al terminar la fase, actualizar la sección de "Phases activas":
+
+```markdown
+## Phases activas y estado
+
+- **Sprint actual:** Sprint N
+- **Completadas:** [IDs completados]
+- **En curso:** [IDs en progreso]
+- **Pendientes:** [IDs pendientes]
+```
+
+---
+
+## Checklist de kickoff
+
+- [ ] Specs de la fase leídas y en estado APPROVED
+- [ ] Dependencias entre specs mapeadas
+- [ ] Team spawneado con agentes apropiados
+- [ ] CLAUDE.md actualizado con fase activa
+- [ ] No hay specs en DRAFT sin aprobación del humano

package/assets/core/skills/security-audit/SKILL.md

@@ -0,0 +1,125 @@
+# Skill: security-audit
+
+Checklist de seguridad para endpoints de API y módulos que manejan autenticación,
+autorización o datos sensibles. Agnóstico al stack.
+
+Triggers: /security-audit, "auditar seguridad", "revisar endpoints", "security check",
+"vulnerabilidades", "es seguro", "revisar auth".
+
+---
+
+## Cuándo usar este skill
+
+- Al implementar nuevos endpoints de API
+- Al modificar lógica de autenticación o autorización
+- Antes de mergear cualquier PR que toque rutas protegidas
+- Cuando el security-auditor lo solicita como parte de un review
+
+---
+
+## Checklist por endpoint
+
+### 1. Autenticación — ¿quién sos?
+
+```
+✓ El token/sesión se verifica ANTES de procesar el request
+✓ Si no hay token válido → 401 inmediato, sin procesar nada
+✓ La verificación está en CADA método del handler (GET, POST, PUT, DELETE)
+  — no solo en el primero que se implementó
+
+✗ NUNCA saltear auth porque "es solo GET" o "es público por diseño" sin confirmarlo
+✗ NUNCA confiar en headers que el cliente puede modificar (X-User-Id, X-Role)
+```
+
+Patrón genérico:
+```typescript
+// Verificar antes de cualquier lógica
+const session = await getSession(request);
+if (!session) return Response.json({ error: 'No autenticado' }, { status: 401 });
+```
+
+### 2. Autorización — ¿podés hacer esto?
+
+```
+✓ Verificar que el usuario tiene el ROL requerido para la operación
+✓ Verificar que el usuario tiene ACCESO al recurso específico (no solo al tipo)
+✓ Las operaciones de escritura requieren más verificación que las de lectura
+```
+
+Patrón genérico:
+```typescript
+// Rol
+if (session.role !== 'admin') return Response.json({ error: 'Sin permiso' }, { status: 403 });
+
+// Acceso al recurso (IDOR check — ver punto 3)
+const resource = await db.find(id);
+if (resource.ownerId !== session.userId && session.role !== 'admin') return 403;
+```
+
+### 3. IDOR — Insecure Direct Object Reference
+
+```
+✓ Al acceder por ID, verificar que el recurso pertenece al usuario (o que tiene permiso)
+✓ No asumir que si el ID es "difícil de adivinar" está protegido
+✓ Siempre cargar el recurso de la BD y verificar ownership antes de operar
+
+Patrón de riesgo:
+  GET /api/documents/:id → devuelve el doc sin verificar si es del usuario
+  DELETE /api/comments/:id → borra sin verificar ownership
+```
+
+### 4. Validación de input
+
+```
+✓ Validar tipos, longitudes y formatos antes de pasar a la BD o cualquier servicio
+✓ Usar un schema de validación explícito (Zod, Yup, Joi, Pydantic, etc.)
+✓ No castear el body con 'as Type' — validar explícitamente
+✓ Parámetros preparados siempre — NUNCA interpolar input del usuario en queries SQL
+
+✗ NUNCA: `db.query("SELECT * FROM users WHERE id = " + userId)`
+✓ SIEMPRE: `db.query("SELECT * FROM users WHERE id = $1", [userId])`
+```
+
+### 5. Exposición de información
+
+```
+✓ Los errores de producción no exponen stacktraces ni mensajes internos al cliente
+✓ No loguear PII (email, teléfono, contraseña) en stdout/logs
+✓ Los IDs de BD no son el único control de acceso (ver IDOR)
+```
+
+---
+
+## Comandos de escaneo rápido
+
+Adaptar el path a la estructura del proyecto:
+
+```bash
+# Endpoints/handlers sin verificación de sesión:
+grep -r "export.*function\|app\.\(get\|post\|put\|delete\)" src/routes --include="*.ts" -l | \
+  xargs grep -L "session\|auth\|token\|verify" 2>/dev/null
+
+# Queries SQL con interpolación (peligro de inyección):
+grep -rn "queryRaw\|query\`\|execute\`" src/ --include="*.ts" | grep -v "queryRawTyped\|drizzle"
+
+# Input del body sin validación de schema:
+grep -rn "req\.body\|request\.json()\|await req\.json()" src/ --include="*.ts" | \
+  grep -v "parse\|validate\|schema\|zod\|yup"
+```
+
+---
+
+## Severidades
+
+- **CRÍTICO**: Sin auth en endpoint admin, SQL injection directa, IDOR sin verificación de ownership, RCE.
+- **ALTO**: Bypass de autorización por rol, mass assignment, información sensible en respuestas de error.
+- **MEDIO**: Sin rate limiting en endpoints de auth/IA, verbose errors en producción, CSRF en rutas sensibles.
+- **BAJO**: Headers de seguridad faltantes, dependencias desactualizadas sin CVE activo, slugs permisivos.
+
+---
+
+## Relación con otros skills
+
+- Este skill es invocado por `new-feature` como parte del checklist de implementación.
+- El agente `security-auditor` puede invocarlo en sus reviews.
+- No depende de otros skills (es standalone).

package/assets/core/skills/spec/SKILL.md

@@ -0,0 +1,72 @@
+# Skill: spec
+
+Redactar specs de features siguiendo la plantilla del framework forge.
+Activar antes de escribir cualquier spec nueva.
+
+---
+
+## Cuándo usar este skill
+
+- Al crear una spec nueva en `docs/specs/`
+- Al actualizar una spec existente después de cambios de implementación
+- Al convertir un ticket/issue en una spec formal
+
+---
+
+## Plantilla obligatoria
+
+```markdown
+# [ID] Título de la Feature
+
+> Estado: DRAFT | REVIEW | APPROVED | IMPLEMENTED
+> Responsable: [nombre o rol]
+> Creada: YYYY-MM-DD | Actualizada: YYYY-MM-DD
+
+## Contexto
+
+Por qué existe esta feature. Qué problema resuelve. Qué pasa si no la hacemos.
+
+## Decisión
+
+Qué vamos a implementar exactamente. Ser específico: endpoints, tablas, componentes.
+
+## Alternativas consideradas
+
+| Opción | Pros | Contras | Descartada por |
+|--------|------|---------|----------------|
+| Opción A | ... | ... | ... |
+| Opción B | ... | ... | ... |
+
+## Criterios de aceptación
+
+- [ ] Criterio verificable 1
+- [ ] Criterio verificable 2
+- [ ] Criterio verificable N
+
+## Impacto de compliance
+
+Si el proyecto tiene `compliance.frameworks` configurado, completar:
+
+- **Ley 21.719**: art. X → [descripción del impacto]
+- **GDPR**: Art. Y → [descripción del impacto]
+- No aplica (si no hay impacto de compliance)
+
+## Dependencias
+
+- Requiere que [otra spec ID] esté implementada
+- Bloqueada por [issue/ticket]
+
+## Notas de implementación
+
+Cualquier decisión tomada durante la implementación que no estaba en la spec original.
+```
+
+---
+
+## Reglas al redactar specs
+
+1. **ID único y secuencial**: `A1`, `A2`, `B1`, `C3`... La letra indica la fase/módulo.
+2. **Una spec por feature atómica**: si no podés implementarla en un sprint, dividila.
+3. **Criterios de aceptación verificables**: cada uno debe poder marcarse DONE sin ambigüedad.
+4. **Sin código de implementación en la spec**: la spec describe QUÉ, no CÓMO.
+5. **Actualizar la spec durante la implementación**: si tomás una decisión no contemplada, agregala en "Notas de implementación".

package/assets/core/skills/wiki-ingest/SKILL.md

@@ -0,0 +1,183 @@
+# Skill: wiki-ingest
+
+Ingesta una fuente nueva en el wiki del proyecto. Almacena el original en `raw/`,
+compila conocimiento en páginas wiki, actualiza el índice y registra la operación.
+
+Triggers: /wiki-ingest, "ingestar", "agregar al wiki", "aprender de", "leer e
+incorporar", "ingest this", "add to wiki", "incorporar este documento",
+"guardar conocimiento de".
+
+Argumento: URL, path a archivo, o texto pegado directamente.
+
+---
+
+## Cuándo usar este skill
+
+- Al incorporar documentación técnica, papers, specs regulatorias o decisiones de diseño
+- Al leer código fuente de dependencias relevantes para el proyecto
+- Al registrar una decisión de arquitectura que no está en un ADR formal
+- Cuando el usuario dice "recordá esto" o "guardá esto en el wiki"
+
+---
+
+## Protocolo de ingest
+
+### Paso 1 — Obtener la fuente
+
+```
+Si es URL     → agent-browser open <url> && agent-browser get text "article,main"
+Si es archivo → Read(path)
+Si es texto   → usar el texto tal como está
+```
+
+### Paso 2 — Almacenar en raw/ (inmutable)
+
+```
+Path: docs/wiki/raw/<tema>/<YYYY-MM-DD>-<slug-del-titulo>.md
+
+Formato del archivo raw:
+---
+source: <url o path original>
+date: <YYYY-MM-DD>
+title: <título inferido>
+---
+
+<contenido tal cual, sin editar>
+```
+
+`raw/` es append-only — NUNCA editar ni borrar archivos existentes.
+
+### Paso 3 — Extraer conocimiento
+
+Leer el contenido y identificar:
+
+1. **Entidades** — personas, proyectos, empresas, sistemas, frameworks mencionados
+2. **Conceptos** — ideas, patrones, métodos, protocolos
+3. **Hechos clave** — afirmaciones concretas, cifras, fechas, decisiones
+4. **Contradicciones** — si algo contradice páginas wiki existentes
+
+### Paso 4 — Actualizar páginas wiki
+
+Para cada concepto identificado:
+- Si `docs/wiki/concepts/<nombre>.md` existe → agregar sección con nueva info + citar fuente
+- Si no existe → crear la página desde la plantilla
+
+Para cada entidad identificada:
+- Si `docs/wiki/entities/<nombre>.md` existe → actualizar con nueva info
+- Si no existe → crear la página desde la plantilla
+
+Crear siempre `docs/wiki/sources/<slug>.md` con resumen de la fuente:
+
+```markdown
+---
+title: <título>
+source: <url o path>
+ingested: <YYYY-MM-DD>
+tags: [tag1, tag2]
+---
+
+# <título>
+
+## Resumen
+<2-3 párrafos con los puntos más importantes>
+
+## Hechos clave
+- <hecho 1>
+- <hecho 2>
+
+## Conceptos mencionados
+- [[concepts/nombre]] — breve contexto
+- [[concepts/nombre2]] — breve contexto
+
+## Entidades mencionadas
+- [[entities/nombre]] — rol en la fuente
+```
+
+### Paso 5 — Actualizar index.md y log.md
+
+En `docs/wiki/index.md`:
+- Agregar filas nuevas en las tablas correspondientes (concepts, entities, sources)
+- Si la categoría no existe, crearla
+
+En `docs/wiki/log.md` (append-only — NUNCA editar entradas anteriores):
+
+```markdown
+## [<YYYY-MM-DD>] ingest | <título de la fuente>
+
+- **Fuente**: <url o path>
+- **Páginas creadas**: [[concepts/X]], [[entities/Y]], [[sources/Z]]
+- **Páginas actualizadas**: [[concepts/W]]
+- **Contradicciones detectadas**: <si hay alguna, describirla>
+```
+
+---
+
+## Formato de páginas wiki
+
+### concepts/<nombre>.md
+
+```markdown
+---
+title: Nombre del Concepto
+tags: [tag1, tag2]
+sources: [[[sources/fuente1]], [[sources/fuente2]]]
+updated: YYYY-MM-DD
+---
+
+# Nombre del Concepto
+
+Definición en 1-2 oraciones.
+
+## Detalles
+
+Desarrollo del concepto. Cross-referencias con [[concepts/otro]] o [[entities/entidad]].
+
+## En este proyecto
+
+Cómo aplica específicamente al proyecto actual.
+
+## Fuentes
+- [[sources/fuente1]] — contexto
+```
+
+### entities/<nombre>.md
+
+```markdown
+---
+title: Nombre de la Entidad
+type: project | person | company | framework | api
+tags: [tag1, tag2]
+sources: [[[sources/fuente1]]]
+updated: YYYY-MM-DD
+---
+
+# Nombre de la Entidad
+
+Descripción en 1-2 oraciones.
+
+## Relevancia para el proyecto
+
+Por qué importa.
+
+## Fuentes
+- [[sources/fuente1]] — contexto
+```
+
+---
+
+## Contradicciones
+
+Si la nueva fuente contradice algo en el wiki:
+
+1. Agregar en la página afectada una sección `## Contradicciones`
+2. Describir qué fuente dice qué
+3. Marcar cuál es la versión actual adoptada por el proyecto
+4. Registrar en log.md
+
+---
+
+## Relación con otros skills
+
+- `wiki-query` consume las páginas que este skill crea
+- `wiki-lint` verifica la integridad después de un ingest
+- `docs-writer` puede invocar wiki-ingest al documentar una decisión nueva

package/assets/core/skills/wiki-lint/SKILL.md

@@ -0,0 +1,109 @@
+# Skill: wiki-lint
+
+Verifica la integridad estructural del wiki: índice, links, huérfanos y salud
+general. Auto-repara lo que puede; reporta lo que necesita decisión humana.
+
+Triggers: /wiki-lint, "lint wiki", "verificar wiki", "revisar wiki", "chequear
+wiki", "wiki health", "wiki check".
+
+---
+
+## Cuándo usar este skill
+
+- Después de un `wiki-ingest` para verificar consistencia
+- Periódicamente (por ejemplo, al inicio de cada sprint)
+- Cuando se sospecha que hay links rotos o páginas huérfanas
+
+---
+
+## Checklist de linting
+
+### 1. Integridad del índice
+
+Leer `docs/wiki/index.md` y verificar:
+
+```
+✓ Cada [[link]] del índice apunta a un archivo que existe
+✗ Archivos en concepts/, entities/, sources/, synthesis/ que NO están en el índice
+```
+
+Auto-reparar: agregar al índice los archivos que faltan (con descripción vacía marcada `TODO`).
+
+### 2. Wikilinks rotos
+
+Buscar en todas las páginas wiki referencias `[[ruta/nombre]]` y verificar que
+el archivo `docs/wiki/ruta/nombre.md` existe.
+
+```bash
+grep -rn "\[\[" docs/wiki/ --include="*.md" | grep -v "raw/"
+```
+
+Reportar: lista de links rotos con el archivo donde aparecen.
+
+### 3. Páginas huérfanas
+
+Páginas que no son referenciadas por ninguna otra página ni por el índice.
+
+```bash
+# Para cada archivo en wiki/ (excluyendo index, log, raw/)
+# verificar si su nombre aparece en algún [[link]] de otra página
+```
+
+Reportar: lista de huérfanas. No auto-borrar — requiere decisión humana.
+
+### 4. Integridad del log
+
+Verificar que `docs/wiki/log.md` existe y tiene al menos una entrada.
+El log es append-only — nunca modificar entradas pasadas.
+
+Reportar si el log no ha sido actualizado en los últimos 30 días (wiki posiblemente abandonado).
+
+### 5. Consistencia de frontmatter
+
+Para cada página wiki (excluyendo raw/):
+- Tiene bloque `---` con `title`, `tags`, `updated`
+- El campo `updated` tiene formato válido `YYYY-MM-DD`
+- El campo `sources` lista solo archivos que existen en `sources/`
+
+Auto-reparar: agregar campos faltantes con valor `TODO`.
+
+### 6. Raw/ inmutable
+
+Verificar que ningún archivo en `raw/` ha sido modificado desde su ingest.
+Comparar fecha de modificación vs fecha en frontmatter.
+
+---
+
+## Formato de reporte
+
+```
+Wiki Lint — <project>
+══════════════════════════
+
+RESUMEN
+  <N> páginas en el wiki
+  <N> en el índice
+  <N> issues encontrados
+
+ISSUES
+  ✗ [CRÍTICO] Link roto: [[concepts/X]] en entities/Y.md — archivo no existe
+  ⚠ [WARN]    Huérfana: sources/fuente-vieja.md — sin referencias
+  ⚠ [WARN]    Falta en índice: concepts/nuevo-concepto.md
+  → [INFO]    Log sin actualizaciones en 15 días
+
+AUTO-REPARADO
+  ✓ Agregado concepts/nuevo-concepto.md al índice
+  ✓ Agregado campo 'updated: TODO' a 2 páginas con frontmatter incompleto
+
+REQUIERE ATENCIÓN MANUAL
+  • sources/fuente-vieja.md — ¿borrar o referenciar?
+  • [[concepts/X]] roto en entities/Y.md — ¿crear X o actualizar la referencia?
+```
+
+---
+
+## Relación con otros skills
+
+- `wiki-ingest` puede crear inconsistencias que este skill detecta
+- `wiki-query` depende de los links que este skill verifica
+- Sin dependencias de otros skills (es standalone)