Platform Integration

Guia de Integracion con Plataformas AI

Companion del AI-First Engineering Framework v7.5

Version: 1.1.0 | Fecha: Marzo 2026 Estado: ACTIVO Aplica a: Todo proyecto que adopte el AI-First Engineering Framework con cualquier plataforma de codificacion AI

1. El Modelo de Governance Wrapper

1.1 El Problema

Las plataformas de codificacion AI — Claude Code, Codex, Cursor, Copilot, Windsurf, Amazon Q — generan codigo excelente. Son las mejores herramientas de productividad que la ingenieria de software ha visto. Pero tienen un problema fundamental: generan codigo sin governance de ciclo de vida.

Son martillos sin plano arquitectonico.

Un agente AI puede:

Escribir una API REST completa en minutos
Refactorizar miles de lineas en segundos
Generar tests con cobertura alta

Pero sin governance, ese mismo agente:

No sabe si el proyecto requiere clasificacion de datos antes de codificar
No valida que la arquitectura fue aprobada antes de implementar
No verifica compliance de seguridad antes de hacer merge
No sigue un lifecycle de 10 fases — salta directo a codigo
No produce artefactos de trazabilidad (problem statement, domain model, contratos)

El framework Baseline resuelve esto: provee el plano arquitectonico, las reglas de governance, los gates de calidad y los artefactos de trazabilidad que cualquier plataforma AI necesita para producir software con rigor de ingenieria.

1.2 El Patron: Platform + Baseline = Governed AI Development

El patron fundamental es un wrapper de governance alrededor de cualquier plataforma:

┌─────────────────────────────────────────────────────────────────────┐
│                    GOVERNED AI DEVELOPMENT                          │
│                                                                     │
│  ┌───────────┐     ┌──────────────────────┐     ┌───────────────┐  │
│  │  INTENT   │────►│  BASELINE GOVERNANCE  │────►│  PLATAFORMA   │  │
│  │           │     │                       │     │  AI           │  │
│  │ - Issue   │     │ - CLAUDE.md (reglas)  │     │               │  │
│  │ - Ticket  │     │ - AGENTS.md (routing) │     │ - Claude Code │  │
│  │ - Intent  │     │ - Skills (metodologia)│     │ - Codex       │  │
│  │   YAML    │     │ - Rules (calidad)     │     │ - Cursor      │  │
│  │           │     │ - Gates (progresion)  │     │ - Copilot     │  │
│  └───────────┘     └──────────┬───────────┘     │ - Windsurf    │  │
│                               │                  │ - Amazon Q    │  │
│                               │                  └───────┬───────┘  │
│                               │                          │          │
│                    ┌──────────▼──────────────────────────▼────┐     │
│                    │          ENFORCEMENT                      │     │
│                    │                                           │     │
│                    │  - compliance-linter.py (10 reglas)       │     │
│                    │  - artifact-validator.py (28 schemas)     │     │
│                    │  - gate-check.sh (gates A-F + DG)        │     │
│                    │  - fab-gate-check.py (autonomous gates)  │     │
│                    │  - CI Pipeline (universal)                │     │
│                    └──────────────────────────────────────────┘     │
│                               │                                     │
│                    ┌──────────▼──────────┐                          │
│                    │     DELIVERY        │                          │
│                    │  PR → Review → Merge│                          │
│                    └─────────────────────┘                          │
└─────────────────────────────────────────────────────────────────────┘

El punto clave: la plataforma AI es intercambiable. La governance no lo es.

1.3 Tabla de Mapeo Generico

Cada concepto del framework Baseline tiene un equivalente en las plataformas AI. Esta tabla muestra el mapeo generico:

Concepto Baseline	Proposito	Equivalente Generico en Plataformas
`CLAUDE.md`	Instrucciones del proyecto para el agente	System instructions / rules file / config
`AGENTS.md`	Routing de contexto + principios del agente	Agent configuration / persona / instructions
`.claude/skills/`	Guias metodologicas por fase (F01-F10)	Custom docs / knowledge base / prompts
`.claude/rules/`	Reglas de calidad de codigo y YAML	Linting rules / code style config
`.claude/hooks/`	Acciones automaticas pre/post operacion	Pre-commit hooks / automations / triggers
`.claude/agents/`	Agentes especializados (architect, QA, security)	Agent personas / specialized modes
`compliance-linter.py`	Validacion de compliance por fase y track	CI pipeline check / linting step
`gate-check.sh`	Verificacion de gates antes de avanzar de fase	PR merge gate / quality gate
`fab-gate-check.py`	Decision autonoma de gates (para FABs)	Autonomous decision gate / auto-approve
`artifact-validator.py`	Validacion de YAML contra schemas	Schema validation / artifact check
`framework-mcp-server.py`	Consulta real-time del framework	MCP server / API tools / context provider
`context-router.py`	Mapeo tarea → guias relevantes	Context routing / knowledge selection

1.4 Principio de Integracion

Regla de oro: Adopta la governance al nivel mas alto que la plataforma soporte nativamente, y usa CI como red de seguridad universal.

Esto significa:

Si la plataforma soporta CLAUDE.md nativo → usarlo
Si soporta skills nativos → cargar las guias metodologicas ahi
Si soporta hooks nativos → configurar enforcement ahi
Siempre configurar CI como capa final de enforcement (funciona con todas las plataformas)

2. Claude Code — Integracion Nativa

Claude Code es la plataforma nativa del framework. Todos los conceptos de Baseline se mapean 1:1 sin adaptacion.

2.1 Ventajas de la Integracion Nativa

Caracteristica	Soporte
CLAUDE.md auto-cargado	Si — cargado automaticamente al iniciar sesion
AGENTS.md auto-cargado	Si — define principios y routing de contexto
Skills como slash commands	Si — `/f01-strategy`, `/fab-orchestrator`, etc.
Rules auto-cargadas por path	Si — `.claude/rules/*.md` se cargan automaticamente
Hooks nativos (PreCommit, PostToolUse)	Si — configurados en `settings.json`
Agents con `@mention`	Si — `@architect`, `@qa-engineer`, etc.
MCP server nativo	Si — `framework-mcp-server.py` como herramienta
FAB headless	Si — `claude --background` con intent documents
Worktrees aislados	Si — `.claude/worktrees/` nativo
Permisos granulares	Si — `settings.json` con allow/deny por herramienta

2.2 Setup Completo

Opcion A: Proyecto nuevo (greenfield)

# Clonar el framework
git clone https://github.com/aforero22/baseline.git
cd baseline

# Crear proyecto nuevo con scaffold completo
./scripts/init-project.sh "Mi Proyecto" "mi-proyecto" ~/projects

# El script automaticamente:
# 1. Crea ~/projects/mi-proyecto/
# 2. Agrega baseline como submodule
# 3. Copia templates → CLAUDE.md, AGENTS.md, .claude/, project/
# 4. Configura MCP server
# 5. Genera data governance artifacts
# 6. Hace commit inicial

Opcion B: Proyecto existente (brownfield)

# Desde la raiz del proyecto existente
cd ~/projects/mi-proyecto-existente

# Ejecutar adopcion aditiva
/path/to/baseline/scripts/init-brownfield.sh

# El script automaticamente:
# 1. Agrega baseline/ como submodule
# 2. Crea .claude/ con skills, rules, hooks, agents
# 3. Crea CLAUDE.md y AGENTS.md adaptados
# 4. Crea project/ con templates YAML
# 5. NO toca el codigo existente

Verificacion post-setup

# Verificar que la estructura esta completa
ls -la .claude/
# skills/  rules/  hooks/  agents/  settings.json

# Verificar CLAUDE.md
head -5 CLAUDE.md

# Verificar MCP config
cat .claude/mcp_config.json

# Correr compliance check inicial
python3 baseline/scripts/compliance-linter.py --project-dir . --track solo

2.3 Mapeo de Conceptos

Concepto Baseline	Feature Claude Code	Como Funciona
`CLAUDE.md`	CLAUDE.md (nativo)	Auto-cargado al inicio de cada sesion
`AGENTS.md`	AGENTS.md (nativo)	Auto-cargado, define 7 Golden Principles
`.claude/skills/*.md`	Slash commands (`/skill-name`)	Invocados con `/f01-strategy`, `/fab-orchestrator`, etc.
`.claude/rules/*.md`	Rules (auto-cargadas por path)	Aplicadas automaticamente segun patron de archivo
`.claude/hooks/`	settings.json hooks	PreCommit, PostToolUse, PostCompact
`.claude/agents/*.md`	`@agent` mentions	`@architect`, `@qa-engineer`, `@security-reviewer`
`.claude/settings.json`	Configuracion nativa	Permisos, hooks, MCP config
FAB Mode	`claude --background`	Ejecucion headless con intent documents
Worktrees	`.claude/worktrees/`	Aislamiento nativo por tarea
MCP Server	`mcp_config.json`	Framework como herramienta consultable

2.4 Hooks de Enforcement

El archivo .claude/settings.json configura hooks que se ejecutan automaticamente:

{
  "hooks": {
    "PreCommit": [
      {
        "command": "python3 baseline/scripts/compliance-linter.py --project-dir . --track $TRACK --phase $PHASE --format compact",
        "description": "Validar compliance del framework antes de commit"
      },
      {
        "command": "git diff --cached --name-only | grep -E '\\.ya?ml$' | xargs -I {} python3 baseline/scripts/artifact-validator.py {}",
        "description": "Validar YAML contra schemas del framework"
      },
      {
        "command": "git diff --cached --diff-filter=A --name-only | xargs grep -l -E '(api[_-]?key|secret|password|token)\\s*[:=]' || true",
        "description": "Escaneo basico de secretos en archivos nuevos"
      }
    ],
    "PostToolUse": [
      {
        "event": "Write",
        "pattern": "**/*.yaml",
        "command": "python3 -c \"import yaml, sys; yaml.safe_load(open(sys.argv[1]))\" $FILE",
        "description": "Validar sintaxis YAML despues de cada escritura"
      }
    ],
    "PostCompact": [
      {
        "command": "cat CLAUDE.md | head -100",
        "description": "Recargar contexto del proyecto despues de compactacion"
      }
    ]
  },
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(project/**)",
      "Write(.claude/**)",
      "Bash(python3 baseline/scripts/*)",
      "Bash(bash baseline/scripts/*)",
      "Bash(git *)",
      "Bash(npm *)",
      "MCP(framework-mcp-server)"
    ],
    "deny": [
      "Write(baseline/**)",
      "Bash(rm -rf *)",
      "Bash(curl * | bash)",
      "Bash(chmod 777 *)"
    ]
  }
}

2.5 MCP Server del Framework

El framework incluye un MCP server con 10 herramientas consultables por el agente:

{
  "mcpServers": {
    "framework": {
      "command": "python3",
      "args": ["baseline/scripts/framework-mcp-server.py", "--project-dir", "."],
      "description": "AI-First Engineering Framework — 10 tools"
    }
  }
}

Herramientas disponibles:

Tool MCP	Descripcion
`get_phase_guide`	Obtener guia completa de una fase (F01-F10)
`get_gate_requirements`	Requisitos del gate para una fase y track
`check_compliance`	Ejecutar compliance linter y obtener score
`validate_artifact`	Validar un artefacto YAML contra schema
`route_context`	Obtener guias y skills relevantes para una tarea
`list_templates`	Listar templates disponibles por fase
`get_template`	Obtener contenido de un template especifico
`get_framework_config`	Obtener configuracion del framework
`search_guides`	Buscar en guias operacionales por keyword
`get_track_config`	Obtener configuracion de un track (Full/Lean/Solo)

Ejemplo de uso desde Claude Code:

Usuario: "Necesito disenar la arquitectura del servicio de pagos"

Claude Code (internamente):
1. Llama route_context("disenar arquitectura servicio pagos")
   → Resultado: F04_Architecture, guides/Context_Engineering_Guide.md
2. Llama get_phase_guide("F04")
   → Resultado: guia completa de F04
3. Llama get_gate_requirements("F04", "lean")
   → Resultado: artefactos requeridos para Gate D
4. Llama get_template("architecture_decision_record")
   → Resultado: template ADR
5. Procede a disenar con governance completa

2.6 FAB — Fullstack Agent Builder

FAB (Fullstack Agent Builder) es el modo headless del framework donde agentes autonomos ejecutan tareas completas sin intervencion humana.

Flujo FAB

┌──────────────┐     ┌──────────────┐     ┌──────────────────┐
│  INTENT      │────►│  FAB INTAKE  │────►│  CLAUDE           │
│  (YAML)      │     │  (validacion)│     │  --background     │
└──────────────┘     └──────────────┘     │  --intent FILE    │
                                          └────────┬─────────┘
                                                   │
                            ┌──────────────────────▼──────────┐
                            │  EJECUCION AUTONOMA              │
                            │                                  │
                            │  1. Cargar intent + CLAUDE.md    │
                            │  2. Ejecutar F01→F10 segun scope │
                            │  3. Checkpoint cada 60 min       │
                            │  4. Gate check autonomo          │
                            │  5. PR al completar              │
                            └──────────────────────────────────┘

Ejemplo de intent document

intent:
  id: "INT-2026-0342"
  title: "Agregar servicio de procesamiento de pagos"
  type: "feature"
  priority: "high"
  source: "github-issue-142"

scope:
  phases: ["F01", "F02", "F03", "F04", "F05", "F07"]
  track: "lean"
  estimated_tokens: 500000

constraints:
  budget_usd: 15.00
  max_duration_hours: 4
  require_human_review: true
  security_classification: "confidential"

acceptance_criteria:
  - "API REST para procesamiento de pagos con Stripe"
  - "Tests de integracion con sandbox de Stripe"
  - "Documentacion de API en OpenAPI 3.1"
  - "Compliance check score >= 80%"

Ejecucion headless

# Validar el intent
python3 baseline/scripts/validate-intent.py intent/add-payment-service.yaml

# Lanzar FAB
claude --background \
  --intent intent/add-payment-service.yaml \
  --checkpoint-interval 60 \
  --cost-limit 15.00

# Monitorear
bash baseline/scripts/fab-health-check.sh

2.7 Ejemplo de Workflow Completo

1. Crear proyecto
   $ ./scripts/init-project.sh "Payment API" "payment-api" ~/projects

2. Abrir Claude Code
   $ cd ~/projects/payment-api
   $ claude

3. Claude Code carga automaticamente:
   - CLAUDE.md → instrucciones del proyecto
   - AGENTS.md → principios y routing
   - .claude/rules/ → reglas de calidad
   - .claude/settings.json → permisos y hooks

4. Iniciar trabajo con skill de estrategia
   > /f01-strategy
   > Necesito definir el problem statement para un servicio de pagos

5. Claude Code:
   - Usa MCP tool get_phase_guide("F01") para contexto
   - Genera problem_statement.yaml siguiendo el template
   - Hook PostToolUse valida YAML automaticamente

6. Avanzar a siguiente fase
   > /f04-architecture
   > Disenar la arquitectura basada en el problem statement

7. Hacer commit
   $ git add -A
   $ git commit -m "feat(F04): architecture decision records for payment service"
   # Hook PreCommit ejecuta compliance-linter automaticamente
   # Si score < threshold → commit rechazado con feedback

8. Gate check antes de PR
   $ bash baseline/scripts/gate-check.sh --phase F04 --track lean
   # Verifica que todos los artefactos requeridos existan y sean validos

9. Crear PR con governance completa

3. OpenAI Codex — Integracion

OpenAI Codex es una plataforma de codificacion AI con soporte nativo para agentes autonomos, tasks y automations. Su modelo de integracion se centra en AGENTS.md como archivo principal de instrucciones.

3.1 Mapeo de Conceptos

Concepto Baseline	Feature Codex	Notas
`CLAUDE.md`	`AGENTS.md` (Codex lo lee nativamente)	Codex usa AGENTS.md como archivo principal de instrucciones
`AGENTS.md`	`AGENTS.md`	Compatibilidad directa — mismo archivo
`.claude/skills/`	Directorio de skills	Codex soporta skills como documentos referenciables
`.claude/rules/`	Reglas en AGENTS.md o config	Las reglas se embeben en AGENTS.md o en archivos auxiliares
`.claude/hooks/`	Automations	Codex soporta automations triggered por eventos
`.claude/agents/`	Agent personas en AGENTS.md	Se definen como secciones del AGENTS.md
FAB Mode	`codex --task`	Ejecucion headless de tareas
`compliance-linter.py`	CI integration	Se ejecuta como step de CI
`gate-check.sh`	CI merge gate	Se ejecuta como check requerido en PR
MCP Server	MCP nativo	Codex soporta MCP como protocolo de herramientas

3.2 Setup

Paso 1: Crear AGENTS.md compatible con Codex

Codex usa AGENTS.md como su archivo principal de instrucciones. El framework ya genera un AGENTS.md, pero necesita ajustes para ser el archivo primario (en Claude Code, CLAUDE.md es el primario).

# AGENTS.md — Payment API
# AI-First Engineering Framework v7.2

## Instrucciones del Proyecto

Este proyecto sigue el AI-First Engineering Framework.
El framework esta disponible en `baseline/` como submodule.

## Principios (7 Golden Principles)

1. Framework-first: Toda decisión sigue el lifecycle F01-F10
2. Artifact-driven: Todo output es un artefacto versionado YAML
3. Gate-governed: No avanzar sin pasar el gate de la fase actual
4. Context-aware: Cargar solo las guias relevantes para la tarea
5. Quality-enforced: Compliance score >= 80% para merge
6. Track-appropriate: Full/Lean/Solo segun tamaño del equipo
7. Security-embedded: Clasificacion de datos desde F01

## Reglas de Calidad

- YAML: indentacion 2 espacios, sin tabs
- Codigo: docstrings, type hints, tests
- Commits: conventional commits (feat:, fix:, docs:, chore:)
- PRs: incluir compliance score en descripcion

## Guias por Fase

Para cada tarea, consulta la guia correspondiente:
- Estrategia: baseline/framework/core/F01_Strategy/
- Dominio: baseline/framework/core/F02_Domain/
- Conocimiento: baseline/framework/core/F03_Knowledge/
- Arquitectura: baseline/framework/core/F04_Architecture/
- Contratos: baseline/framework/core/F05_Contracts/
- Implementacion: baseline/framework/core/F06_Implementation/
- TEVV: baseline/framework/core/F07_TEVV/
- Seguridad: baseline/framework/core/F08_Security/
- Operaciones: baseline/framework/core/F09_Operations/
- Evolucion: baseline/framework/core/F10_Evolution/

## Enforcement

Antes de hacer commit, ejecutar:
$ python3 baseline/scripts/compliance-linter.py --project-dir . --track lean

Paso 2: Configurar skills

# Copiar skills del framework al directorio que Codex reconoce
mkdir -p .codex/skills/
cp .claude/skills/*.md .codex/skills/

# O crear un symlink si Codex lo soporta
ln -s .claude/skills .codex/skills

Paso 3: Configurar CI

name: Baseline Enforcement
on:
  pull_request:
    branches: [main, develop]

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: true

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: pip install pyyaml jsonschema

      - name: Run compliance linter
        run: |
          python3 baseline/scripts/compliance-linter.py \
            --project-dir . \
            --track lean \
            --min-score 80 \
            --format github-actions

      - name: Validate artifacts
        run: |
          find project/ -name "*.yaml" -exec \
            python3 baseline/scripts/artifact-validator.py {} \;

      - name: Gate check
        run: |
          bash baseline/scripts/gate-check.sh \
            --phase ${{ github.event.pull_request.title }} \
            --track lean

3.3 Adaptaciones Necesarias

Aspecto	Claude Code	Codex	Adaptacion
Archivo principal	CLAUDE.md	AGENTS.md	Mover contenido de CLAUDE.md → AGENTS.md
Hooks nativos	settings.json	Automations	Reconfigurar hooks como automations de Codex
MCP Server	mcp_config.json	MCP nativo	Configurar MCP server en config de Codex
Permisos	settings.json allow/deny	Config de Codex	Mapear permisos al modelo de Codex
Worktrees	.claude/worktrees/	Sandbox de Codex	Codex usa su propio aislamiento

3.4 Ejemplo de Workflow con Codex

1. Proyecto con AGENTS.md configurado
   $ cd ~/projects/payment-api

2. Iniciar tarea con Codex
   $ codex --task "Implementar endpoint POST /payments siguiendo F06"

3. Codex:
   - Lee AGENTS.md → obtiene instrucciones del framework
   - Consulta skills de F06 → implementacion
   - Genera codigo siguiendo reglas de calidad
   - Ejecuta tests automaticamente

4. CI valida compliance
   - compliance-linter.py verifica artefactos
   - artifact-validator.py valida schemas
   - gate-check.sh verifica gate E (implementacion)

5. PR lista para review

4. Cursor — Integracion

Cursor es un IDE con AI integrada que usa un sistema de reglas basado en archivos .cursor/rules/. La integracion con Baseline requiere transformar los conceptos del framework al formato de Cursor.

4.1 Mapeo de Conceptos

Concepto Baseline	Feature Cursor	Notas
`CLAUDE.md`	`.cursor/rules/*.md`	Cursor carga reglas desde `.cursor/rules/`
`AGENTS.md`	`.cursorrules` (raiz)	Archivo global de reglas en la raiz
`.claude/skills/`	Custom docs en `.cursor/rules/`	Cada skill como archivo de regla
`.claude/rules/`	`.cursor/rules/*.md` con glob patterns	Reglas con metadata de aplicacion
`.claude/hooks/`	Limitado — usar CI	Cursor no tiene hooks nativos robustos
`.claude/agents/`	No soportado nativamente	Usar instrucciones manuales
FAB Mode	No soportado	No hay modo headless
MCP Server	MCP nativo	Cursor soporta MCP servers
Agent Mode	Cursor Composer (Agent)	Modo agente para tareas complejas

4.2 Setup

Paso 1: Crear directorio de reglas

mkdir -p .cursor/rules/

Paso 2: Crear regla principal del framework

---
description: "Reglas de governance del AI-First Engineering Framework"
globs: ["**/*"]
alwaysApply: true
---

# Governance del Framework

Este proyecto sigue el AI-First Engineering Framework v7.2.
El framework esta en `baseline/` como submodule.

## Reglas Mandatorias

1. Todo cambio debe seguir el lifecycle F01-F10
2. Todo artefacto YAML debe seguir los schemas en baseline/scripts/schemas/
3. Compliance score minimo: 80%
4. Conventional commits obligatorios

## Antes de Implementar

Verificar que existen los artefactos de fases previas:
- F01: problem_statement.yaml
- F02: domain_model.yaml
- F04: architecture_decision_record.yaml
- F05: api_contracts.yaml

## Calidad de Codigo

- Python: docstrings, type hints, tests unitarios
- YAML: indentacion 2 espacios, validar con schema
- Commits: feat:, fix:, docs:, chore:

Paso 3: Crear reglas por tipo de archivo

---
description: "Reglas de calidad para archivos YAML del framework"
globs: ["project/**/*.yaml", "**/*.yml"]
---

# Calidad YAML

- Indentacion: 2 espacios, nunca tabs
- Strings con caracteres especiales: usar comillas
- Listas: usar guion + espacio (- item)
- Validar contra schema: python3 baseline/scripts/artifact-validator.py <file>
- Incluir header con metadata: titulo, version, fecha, autor

---
description: "Reglas de calidad para codigo Python"
globs: ["**/*.py"]
---

# Calidad Python

- Docstrings en todas las funciones publicas
- Type hints en parametros y retorno
- Guard clause: if __name__ == "__main__":
- Tests unitarios para toda logica de negocio
- Imports ordenados: stdlib, third-party, local

Paso 4: Crear reglas de skills como docs

---
description: "Guia de arquitectura (F04) del framework"
globs: ["project/F04_*/**", "**/architecture*"]
---

# Fase F04 — Arquitectura

Cuando trabajes en artefactos de arquitectura:

1. Consultar baseline/framework/core/F04_Architecture/ para la guia completa
2. Usar template: baseline/project-template/project/F04_architecture/
3. Artefactos requeridos:
   - architecture_decision_record.yaml (ADR)
   - component_diagram (descripcion textual)
   - technology_stack.yaml
4. Gate D requiere: ADR aprobado + stack definido

4.3 Script de Sincronizacion

Para mantener las reglas de Cursor sincronizadas con los skills y rules del framework:

#!/bin/bash
# Sincronizar reglas de Baseline → .cursor/rules/
set -euo pipefail

BASELINE_DIR="${1:-baseline}"
CURSOR_DIR=".cursor/rules"

echo "=== Sincronizando reglas Baseline → Cursor ==="

# Crear directorio si no existe
mkdir -p "$CURSOR_DIR"

# Sincronizar skills como reglas de Cursor
for skill in .claude/skills/*.md; do
  skill_name=$(basename "$skill" .md)
  target="$CURSOR_DIR/skill-${skill_name}.md"

  # Agregar frontmatter de Cursor si no existe
  if [ ! -f "$target" ] || [ "$skill" -nt "$target" ]; then
    echo "Sincronizando skill: $skill_name"
    cat > "$target" << EOF
---
description: "Skill del framework: ${skill_name}"
globs: ["**/*"]
---

EOF
    cat "$skill" >> "$target"
  fi
done

# Sincronizar rules
for rule in .claude/rules/*.md; do
  rule_name=$(basename "$rule" .md)
  target="$CURSOR_DIR/rule-${rule_name}.md"

  if [ ! -f "$target" ] || [ "$rule" -nt "$target" ]; then
    echo "Sincronizando rule: $rule_name"
    cp "$rule" "$target"
  fi
done

echo "=== Sincronizacion completa ==="
echo "Archivos en $CURSOR_DIR:"
ls -la "$CURSOR_DIR/"

Uso del script

# Sincronizar una vez
bash scripts/sync-cursor-rules.sh

# Agregar como pre-commit hook o como script de CI
# para mantener sincronizacion automatica

4.4 Ejemplo de Workflow con Cursor

1. Abrir proyecto en Cursor
   $ cursor ~/projects/payment-api

2. Cursor carga automaticamente:
   - .cursor/rules/*.md → reglas del framework
   - .cursorrules → principios generales

3. Usar Composer en modo Agent
   > "Disenar la arquitectura para el servicio de pagos
   >  siguiendo la fase F04 del framework"

4. Cursor:
   - Lee .cursor/rules/skill-architecture.md → contexto de F04
   - Lee .cursor/rules/framework-governance.md → reglas generales
   - Genera artefactos siguiendo templates

5. CI valida compliance en PR
   - compliance-linter.py
   - artifact-validator.py
   - gate-check.sh

5. Kiro (AWS) — Integracion Spec-Driven

Kiro es un IDE de AWS powered by Claude (Sonnet 4.5) que introduce un modelo spec-driven de desarrollo: genera automaticamente requirements.md → design.md → tasks.md antes de implementar. Este enfoque se alinea naturalmente con el lifecycle F01-F05 del framework Baseline.

5.1 Ventajas de la Integracion

Spec-driven nativo: El flujo requirements → design → tasks de Kiro mapea directamente a F01 (Strategy) → F04 (Architecture) → F05 (Contracts), promoviendo la generacion de artefactos antes de codigo
AGENTS.md nativo: Kiro reconoce y carga AGENTS.md automaticamente, igual que Claude Code y Codex
Powered by Claude (Sonnet 4.5): Al usar modelos Anthropic, es compatible con el ecosistema de prompts y contexto del framework
Steering files (.kiro/steering/): Equivalente a .claude/rules/ con 4 modos de inclusion (always, fileMatch, manual, auto), ofreciendo control granular de contexto
Hooks basados en eventos: Sistema de hooks con triggers fileEdit, fileCreate, fileDelete que permite enforcement automatico
MCP nativo: Soporta MCP servers, permitiendo conectar el framework-mcp-server.py directamente

5.2 Mapeo de Conceptos

Concepto Baseline	Equivalente Kiro	Notas
`CLAUDE.md`	`AGENTS.md` (nativo)	Kiro lee AGENTS.md automaticamente como archivo de instrucciones
`AGENTS.md`	`AGENTS.md`	Compatibilidad directa — mismo archivo, cargado al inicio
`.claude/rules/*.md`	`.kiro/steering/*.md`	YAML frontmatter con `inclusion: always/fileMatch/manual/auto`
`.claude/skills/*/SKILL.md`	`.kiro/steering/*.md` con `inclusion: auto`	Usar campo `description` para auto-matching por tarea
`.claude/hooks/`	`.kiro/hooks/*.kiro.hook`	Formato JSON con triggers: `fileEdit`, `fileCreate`, `fileDelete`
`.claude/agents/*.md`	Agent configs (JSON)	Diferente formato pero mismo concepto de agentes especializados
F01-F05 artifacts	`.kiro/specs/<feature>/`	`requirements.md` → `design.md` → `tasks.md`
`compliance-linter.py`	CI pipeline	Enforcement via GitHub Actions (igual que otras plataformas)
`gate-check.sh`	CI merge gate	Se ejecuta como check requerido en PR
FAB headless	Kiro CLI tasks	`kiro --task` como equivalente de ejecucion headless
MCP Server	MCP nativo	Configurar framework-mcp-server.py en settings de Kiro

5.3 Setup

Paso 1: Preparar AGENTS.md

Kiro reconoce AGENTS.md nativamente. El framework ya genera este archivo, asi que solo hay que asegurar que este en la raiz:

# Si usas init-project.sh, AGENTS.md ya esta en la raiz
ls -la AGENTS.md

# Si no existe, copiarlo desde el template
cp baseline/project-template/AGENTS.md .

Paso 2: Crear directorio .kiro/steering/ desde .claude/rules/

# Crear estructura de Kiro
mkdir -p .kiro/steering/
mkdir -p .kiro/hooks/
mkdir -p .kiro/specs/

Paso 3: Convertir rules a steering files

Cada steering file de Kiro usa YAML frontmatter con estos campos:

description: Descripcion de cuando aplicar la regla
inclusion: Modo de inclusion (always, fileMatch, manual, auto)
fileMatch: Patron glob (solo cuando inclusion: fileMatch)

---
description: "Reglas de governance del AI-First Engineering Framework para todo el proyecto"
inclusion: always
---

# Governance del Framework

Este proyecto sigue el AI-First Engineering Framework v7.2.
El framework esta en `baseline/` como submodule.

## Reglas Mandatorias

1. Todo cambio debe seguir el lifecycle F01-F10
2. Todo artefacto YAML debe seguir los schemas en baseline/scripts/schemas/
3. Compliance score minimo: 80%
4. Conventional commits obligatorios

---
description: "Reglas de calidad para archivos YAML del framework"
inclusion: fileMatch
fileMatch: ["project/**/*.yaml", "**/*.yml"]
---

# Calidad YAML

- Indentacion: 2 espacios, nunca tabs
- Strings con caracteres especiales: usar comillas
- Listas: usar guion + espacio (- item)
- Validar contra schema: python3 baseline/scripts/artifact-validator.py <file>
- Incluir header con metadata: titulo, version, fecha, autor

---
description: "Guia de arquitectura F04 — se activa automaticamente cuando el agente trabaja en tareas de arquitectura"
inclusion: auto
---

# Fase F04 — Arquitectura

Cuando trabajes en artefactos de arquitectura:

1. Consultar baseline/framework/core/F04_Architecture/ para la guia completa
2. Usar template: baseline/project-template/project/F04_architecture/
3. Artefactos requeridos:
   - architecture_decision_record.yaml (ADR)
   - component_diagram (descripcion textual)
   - technology_stack.yaml
4. Gate D requiere: ADR aprobado + stack definido

Paso 4: Configurar hooks de enforcement

Ver seccion 5.5 para ejemplos completos de hooks.

Paso 5: Configurar MCP server

{
  "mcpServers": {
    "baseline-framework": {
      "command": "python3",
      "args": ["baseline/scripts/framework-mcp-server.py", "--project-dir", "."]
    }
  }
}

5.4 Script de Sincronizacion

Este script convierte automaticamente los rules y skills de .claude/ al formato de .kiro/:

#!/bin/bash
# Sincronizar .claude/rules/ y .claude/skills/ → .kiro/steering/
# Genera .kiro/hooks/ desde settings.json
set -euo pipefail

CLAUDE_RULES=".claude/rules"
CLAUDE_SKILLS=".claude/skills"
CLAUDE_SETTINGS=".claude/settings.json"
KIRO_STEERING=".kiro/steering"
KIRO_HOOKS=".kiro/hooks"

echo "=== Sincronizando Baseline → Kiro ==="

# Crear directorios
mkdir -p "$KIRO_STEERING"
mkdir -p "$KIRO_HOOKS"

# --- Sincronizar rules → steering (inclusion: always o fileMatch) ---
echo ""
echo "--- Rules → Steering ---"
for rule in ${CLAUDE_RULES}/*.md; do
  [ -f "$rule" ] || continue
  rule_name=$(basename "$rule" .md)
  target="${KIRO_STEERING}/rule-${rule_name}.md"

  # Verificar si el rule tiene globs (para usar fileMatch)
  if grep -q "globs:" "$rule" 2>/dev/null; then
    # Extraer globs y convertir a fileMatch
    globs=$(grep "globs:" "$rule" | sed 's/.*globs:\s*//' | tr -d '[]"')
    cat > "$target" << EOF
---
description: "Regla del framework: ${rule_name}"
inclusion: fileMatch
fileMatch: [${globs}]
---

EOF
  else
    cat > "$target" << EOF
---
description: "Regla del framework: ${rule_name}"
inclusion: always
---

EOF
  fi
  # Agregar contenido original (sin frontmatter previo si existe)
  sed '/^---$/,/^---$/d' "$rule" >> "$target"
  echo "  [OK] $rule_name → rule-${rule_name}.md (steering)"
done

# --- Sincronizar skills → steering (inclusion: auto) ---
echo ""
echo "--- Skills → Steering ---"
for skill_dir in ${CLAUDE_SKILLS}/*/; do
  [ -d "$skill_dir" ] || continue
  skill_file="${skill_dir}SKILL.md"
  [ -f "$skill_file" ] || continue

  skill_name=$(basename "$skill_dir")
  target="${KIRO_STEERING}/skill-${skill_name}.md"

  # Extraer descripcion del skill si existe
  desc=$(grep -m1 "^#" "$skill_file" | sed 's/^#\s*//' || echo "Skill: ${skill_name}")

  cat > "$target" << EOF
---
description: "${desc}"
inclusion: auto
---

EOF
  cat "$skill_file" >> "$target"
  echo "  [OK] $skill_name → skill-${skill_name}.md (steering, auto)"
done

# --- Generar hooks desde settings.json ---
echo ""
echo "--- Generando Kiro Hooks ---"
if [ -f "$CLAUDE_SETTINGS" ]; then
  # Hook de validacion YAML
  cat > "${KIRO_HOOKS}/yaml-validation.kiro.hook" << 'HOOKEOF'
{
  "enabled": true,
  "name": "YAML Validation",
  "description": "Validar sintaxis YAML despues de cada edicion",
  "version": "1",
  "when": {
    "type": "fileEdit",
    "patterns": ["project/**/*.yaml", "project/**/*.yml"]
  },
  "then": {
    "type": "runCommand",
    "command": "python3 -c \"import yaml; yaml.safe_load(open('${filePath}'))\""
  }
}
HOOKEOF
  echo "  [OK] yaml-validation.kiro.hook"

  # Hook de compliance
  cat > "${KIRO_HOOKS}/compliance-check.kiro.hook" << 'HOOKEOF'
{
  "enabled": true,
  "name": "Compliance Check",
  "description": "Ejecutar compliance linter despues de cambios en artefactos del proyecto",
  "version": "1",
  "when": {
    "type": "fileEdit",
    "patterns": ["project/**/*.yaml"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Ejecuta python3 baseline/scripts/compliance-linter.py --project-dir . --track lean --format compact y reporta cualquier fallo encontrado"
  }
}
HOOKEOF
  echo "  [OK] compliance-check.kiro.hook"

  # Hook de secret scanning en archivos nuevos
  cat > "${KIRO_HOOKS}/secret-scan.kiro.hook" << 'HOOKEOF'
{
  "enabled": true,
  "name": "Secret Scanning",
  "description": "Escanear archivos nuevos por posibles secretos o credenciales",
  "version": "1",
  "when": {
    "type": "fileCreate",
    "patterns": ["**/*.yaml", "**/*.yml", "**/*.json", "**/*.env", "**/*.py", "**/*.ts"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Revisa el archivo ${filePath} recien creado y verifica que no contenga secretos, API keys, passwords o tokens hardcodeados. Si encuentras alguno, reportalo inmediatamente."
  }
}
HOOKEOF
  echo "  [OK] secret-scan.kiro.hook"
fi

echo ""
echo "=== Sincronizacion completa ==="
echo "Archivos en ${KIRO_STEERING}/:"
ls -la "${KIRO_STEERING}/" 2>/dev/null || echo "  (vacio)"
echo ""
echo "Hooks en ${KIRO_HOOKS}/:"
ls -la "${KIRO_HOOKS}/" 2>/dev/null || echo "  (vacio)"

Uso del script

# Ejecutar sincronizacion
bash scripts/sync-kiro-steering.sh

# Verificar resultado
tree .kiro/

# Agregar al workflow de sincronizacion multi-plataforma
# o ejecutar como parte de init-project.sh

5.5 Hooks de Enforcement

Kiro usa archivos .kiro.hook en formato JSON con dos tipos de acciones:

runCommand: Ejecuta un comando de shell (para validaciones rapidas)
askAgent: Delega al agente AI (para analisis mas complejos)

Hook de validacion YAML

{
  "enabled": true,
  "name": "YAML Validation",
  "description": "Validar sintaxis YAML en cada edicion de artefactos",
  "version": "1",
  "when": {
    "type": "fileEdit",
    "patterns": ["project/**/*.yaml", "project/**/*.yml"]
  },
  "then": {
    "type": "runCommand",
    "command": "python3 -c \"import yaml; yaml.safe_load(open('${filePath}'))\""
  }
}

Hook de compliance post-edicion

{
  "enabled": true,
  "name": "Compliance Check",
  "description": "Ejecutar compliance linter despues de cambios en artefactos del proyecto",
  "version": "1",
  "when": {
    "type": "fileEdit",
    "patterns": ["project/**/*.yaml"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Ejecuta python3 baseline/scripts/compliance-linter.py --project-dir . --track lean --format compact y reporta cualquier fallo"
  }
}

Hook de artifact validation en creacion

{
  "enabled": true,
  "name": "Artifact Schema Validation",
  "description": "Validar artefactos nuevos contra JSON schemas del framework",
  "version": "1",
  "when": {
    "type": "fileCreate",
    "patterns": ["project/**/*.yaml"]
  },
  "then": {
    "type": "runCommand",
    "command": "python3 baseline/scripts/artifact-validator.py ${filePath}"
  }
}

Hook de secret scanning

{
  "enabled": true,
  "name": "Secret Scanning",
  "description": "Escanear archivos nuevos por secretos o credenciales",
  "version": "1",
  "when": {
    "type": "fileCreate",
    "patterns": ["**/*.yaml", "**/*.json", "**/*.env", "**/*.py", "**/*.ts"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Revisa ${filePath} y verifica que no contenga secretos, API keys, passwords o tokens hardcodeados"
  }
}

Hook de gate check en borrado

{
  "enabled": true,
  "name": "Artifact Deletion Guard",
  "description": "Advertir cuando se elimina un artefacto requerido por un gate",
  "version": "1",
  "when": {
    "type": "fileDelete",
    "patterns": ["project/**/*.yaml"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Se ha eliminado ${filePath}. Verifica si este artefacto es requerido por algun gate (A-F) del framework ejecutando bash baseline/scripts/gate-check.sh --project-dir . --track lean y reporta el impacto"
  }
}

5.6 Ejemplo de Workflow Spec-Driven

El flujo spec-driven de Kiro se integra naturalmente con el lifecycle del framework:

1. Iniciar feature con specs
   > Abrir Kiro en ~/projects/payment-api
   > Solicitar: "Crear servicio de procesamiento de pagos"

2. Kiro genera specs automaticamente:
   .kiro/specs/payment-service/
     requirements.md    ← Mapea a F01 (Strategy) + F02 (Domain)
     design.md          ← Mapea a F04 (Architecture)
     tasks.md           ← Mapea a F05 (Contracts) + F06 (Implementation)

3. Usuario revisa requirements.md
   - Kiro presenta los requisitos funcionales y no-funcionales
   - El usuario aprueba, modifica o rechaza
   - Esto equivale a Gate A (Strategy Review) del framework

4. Kiro genera design.md basado en requirements aprobados
   - Incluye decisiones de arquitectura, componentes, dependencias
   - El usuario revisa y aprueba
   - Esto equivale a Gate D (Architecture Review) del framework

5. Kiro genera tasks.md con plan de implementacion
   - Tareas atomicas con criterios de aceptacion
   - Orden de ejecucion basado en dependencias
   - El usuario aprueba el plan

6. Implementacion con governance
   - Kiro implementa cada tarea siguiendo el plan
   - Steering files cargan reglas de calidad automaticamente
   - Hooks validan YAML y compliance en cada cambio
   - MCP server provee contexto del framework en tiempo real

7. Validacion final
   - CI ejecuta compliance-linter.py en el PR
   - artifact-validator.py verifica schemas
   - gate-check.sh confirma que todos los gates pasan

8. Artefactos del framework generados:
   project/F01_strategy/problem_statement.yaml  ← Desde requirements.md
   project/F04_architecture/adr.yaml            ← Desde design.md
   project/F05_contracts/api_contracts.yaml      ← Desde tasks.md + impl

Mapeo Specs → Artefactos del Framework

Spec de Kiro	Fase Baseline	Artefacto Generado
`requirements.md` (funcionales)	F01 Strategy	`problem_statement.yaml`
`requirements.md` (dominio)	F02 Domain	`domain_model.yaml`
`design.md` (arquitectura)	F04 Architecture	`architecture_decision_record.yaml`
`design.md` (stack tecnico)	F04 Architecture	`technology_stack.yaml`
`tasks.md` (contratos API)	F05 Contracts	`api_contracts.yaml`
`tasks.md` (implementacion)	F06 Implementation	Codigo fuente
Ejecucion de tests	F07 TEVV	`test_plan.yaml`

5.7 Estructura de Proyecto con Kiro

mi-proyecto/
  baseline/                    # Framework (submodule)
  AGENTS.md                    # Kiro lo lee nativamente
  CLAUDE.md                    # Para Claude Code (si se usa tambien)
  .kiro/
    steering/                  # Equivalente a .claude/rules/ + skills
      framework-governance.md  # inclusion: always
      yaml-quality.md          # inclusion: fileMatch
      python-quality.md        # inclusion: fileMatch
      skill-architecture.md    # inclusion: auto
      skill-strategy.md        # inclusion: auto
      skill-testing.md         # inclusion: auto
    hooks/                     # Enforcement automatico
      yaml-validation.kiro.hook
      compliance-check.kiro.hook
      artifact-validation.kiro.hook
      secret-scan.kiro.hook
    specs/                     # Specs generados por Kiro
      payment-service/
        requirements.md
        design.md
        tasks.md
  .claude/                     # Config Claude Code (coexistencia)
    skills/
    rules/
    hooks/
    agents/
    settings.json
  project/                     # Artefactos del framework
    F01_strategy/
    F04_architecture/
    F05_contracts/
  .github/
    workflows/
      baseline-enforcement.yml # CI universal

5.8 Adaptaciones Necesarias

Aspecto	Claude Code	Kiro	Adaptacion
Archivo principal	CLAUDE.md	AGENTS.md	Kiro lee AGENTS.md nativamente
Rules	.claude/rules/*.md	.kiro/steering/*.md	Agregar YAML frontmatter con `inclusion`
Skills	.claude/skills/*/SKILL.md	.kiro/steering/*.md (auto)	Convertir a steering con `inclusion: auto`
Hooks	settings.json	.kiro/hooks/*.kiro.hook	Convertir a formato JSON de Kiro
Agents	.claude/agents/*.md	Agent configs	Diferente formato, mismo concepto
Worktrees	.claude/worktrees/	No nativo	Usar git worktrees manualmente o CI
Permisos	settings.json allow/deny	No soportado nativamente	Confiar en steering + CI
Spec-driven	Manual (via skills)	Nativo	Kiro genera specs automaticamente

6. Otras Plataformas

6.1 GitHub Copilot

GitHub Copilot soporta instrucciones personalizadas a traves de .github/copilot-instructions.md.

Mapeo

Concepto Baseline	Feature Copilot
`CLAUDE.md`	`.github/copilot-instructions.md`
`AGENTS.md`	Secciones dentro de copilot-instructions
Skills	No soportado nativamente
Rules	Embebidas en copilot-instructions
Hooks	No soportado — usar CI
MCP	No soportado nativamente
Agent Mode	Copilot Chat con modo agente

Setup

## Framework

Este proyecto sigue el AI-First Engineering Framework v7.2.
Documentacion completa en baseline/framework/.

## Reglas

1. Seguir lifecycle F01-F10 para cualquier feature nueva
2. YAML: indentacion 2 espacios, validar con schemas
3. Conventional commits: feat:, fix:, docs:, chore:
4. Compliance score minimo: 80%

## Calidad de Codigo

- Python: docstrings, type hints, tests
- TypeScript: tipos estrictos, no any
- Tests: cobertura minima 80%

## Antes de Implementar

Verificar artefactos previos en project/:
- F01: problem_statement.yaml
- F04: architecture_decision_record.yaml
- F05: api_contracts.yaml

Enforcement

Copilot no tiene enforcement nativo — la gobernanza depende completamente de CI:

name: Governance Check
on: [pull_request]
jobs:
  baseline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { submodules: true }
      - run: pip install pyyaml jsonschema
      - run: python3 baseline/scripts/compliance-linter.py --project-dir . --track lean --min-score 80

6.2 Amazon Q Developer

Amazon Q Developer usa README.md y archivos de contexto para entender el proyecto.

Mapeo

Concepto Baseline	Feature Amazon Q
`CLAUDE.md`	README.md + archivos de contexto
`AGENTS.md`	AGENTS.md (reconocido por Q)
Skills	Documentos en directorio del proyecto
Rules	No soportado nativamente — CI
Hooks	No soportado — CI
MCP	No soportado nativamente
Agent Mode	Amazon Q Chat con modo agente

Setup

# Asegurar que README.md incluya referencia al framework
cat >> README.md << 'EOF'

## Framework de Desarrollo

Este proyecto usa el AI-First Engineering Framework v7.2.
Ver `CLAUDE.md` para instrucciones de AI y `AGENTS.md` para contexto.
Documentacion del framework en `baseline/framework/`.
EOF

6.3 Windsurf (Codeium)

Windsurf usa .windsurfrules como archivo de instrucciones y soporta MCP y un modo agente llamado Cascade.

Mapeo

Concepto Baseline	Feature Windsurf
`CLAUDE.md`	`.windsurfrules`
`AGENTS.md`	Secciones en .windsurfrules
Skills	Documentos referenciables
Rules	Embebidas en .windsurfrules
Hooks	No soportado — CI
MCP	Si — MCP nativo
Agent Mode	Cascade (modo agente)

Setup

# Generar .windsurfrules desde CLAUDE.md
cat > .windsurfrules << 'RULES'
# Windsurf Rules — AI-First Engineering Framework v7.2

## Proyecto
Este proyecto sigue el AI-First Engineering Framework.
Framework en baseline/. Documentacion en baseline/framework/.

## Lifecycle
Seguir fases F01-F10. No saltar a implementacion sin artefactos previos.

## Calidad
- YAML: 2 espacios, validar contra schemas
- Codigo: docstrings, type hints, tests
- Commits: conventional commits

## Enforcement
Antes de commit: python3 baseline/scripts/compliance-linter.py --project-dir . --track lean
RULES

MCP Server con Windsurf

{
  "mcpServers": {
    "baseline-framework": {
      "command": "python3",
      "args": ["baseline/scripts/framework-mcp-server.py", "--project-dir", "."]
    }
  }
}

6.4 Google Gemini CLI

Gemini CLI usa GEMINI.md como archivo de instrucciones del proyecto, similar a CLAUDE.md.

Mapeo

Concepto Baseline	Feature Gemini CLI
`CLAUDE.md`	`GEMINI.md`
`AGENTS.md`	Secciones en GEMINI.md
Skills	Documentos referenciables
Rules	`.gemini/rules/*.md`
Hooks	`.gemini/settings.json` (limitado)
MCP	Si — MCP nativo
Agent Mode	Gemini CLI con modo agente

Setup

# Generar GEMINI.md desde CLAUDE.md
cp CLAUDE.md GEMINI.md

# Crear directorio de reglas
mkdir -p .gemini/rules/
cp .claude/rules/*.md .gemini/rules/

# Configurar MCP
cat > .gemini/settings.json << 'EOF'
{
  "mcpServers": {
    "framework": {
      "command": "python3",
      "args": ["baseline/scripts/framework-mcp-server.py", "--project-dir", "."]
    }
  }
}
EOF

7. Nuevas Plataformas Emergentes (v7.5)

Las siguientes plataformas representan la nueva generacion de agentes autonomos de software. A diferencia de las plataformas IDE-centric (Cursor, Copilot), estas operan como ingenieros de software autonomos con workspaces persistentes, lo que las hace candidatas naturales como FAB runtimes alternativos.

7.1 Devin (Cognition)

Concepto: Ingeniero de software autonomo con workspace persistente. Devin opera en un entorno cloud completo (terminal, editor, navegador) y ejecuta tareas de forma autonoma con planificacion multi-paso. Cognition lo posiciona como un “AI teammate” que trabaja en paralelo al equipo humano.

Mapeo

Concepto Baseline	Feature Devin	Notas
`CLAUDE.md`	Playbook instructions	Instrucciones inyectadas al inicio de cada sesion
`AGENTS.md`	Session context	Contexto de equipo y proyecto
`.claude/skills/`	Knowledge base docs	Documentos cargados en el workspace
`.claude/rules/`	Playbook rules	Reglas definidas en playbooks
`.claude/hooks/`	No soportado — CI	Sin hooks locales
Gate check	Human review checkpoints	Puntos de revision humana en el workflow
Intent YAML	Devin task description	Tarea asignada via Slack, JIRA o dashboard
FAB headless	Devin session autonoma	Sesion completa sin intervencion
Worktrees	Workspace aislado (cloud)	Cada sesion tiene su propio entorno

Setup basico

# 1. Configurar playbook con reglas del framework
# En el dashboard de Devin, crear un playbook:
#   - Nombre: "Baseline Framework"
#   - Instrucciones: contenido de CLAUDE.md adaptado
#   - Knowledge: subir guias de framework/guides/

# 2. CI como enforcement (obligatorio — Devin no tiene gates nativos)
# Usar el workflow baseline-enforcement.yml estandar

# 3. Mapear intent → Devin task
# Desde fab-intake.sh, convertir intent YAML a tarea de Devin via API:
#   POST /v1/sessions
#   { "prompt": "<contenido del intent>", "playbook_id": "<id>" }

Limitaciones

Limitacion	Impacto	Mitigacion
Closed-source	No se puede auditar la governance interna	CI obligatorio como red de seguridad
Sin governance customizable	No se puede implementar gate-check nativo	Human review checkpoints + CI gates
Pricing por sesion	Costo puede escalar rapidamente	fab-cost-guard.py para monitorear
Sin MCP nativo	No se puede usar framework-mcp-server	Cargar guias como knowledge base
Sin hooks	No hay PreCommit enforcement	CI pipeline como unico enforcement

7.2 Replit Agent

Concepto: Agente full-stack con servicios integrados (Auth, DB, Hosting, Deployments). Replit Agent construye aplicaciones completas dentro del ecosistema Replit, incluyendo aprovisionamiento automatico de bases de datos, autenticacion y despliegue. Ofrece tres modos de esfuerzo: Economy, Power y Turbo.

Mapeo

Concepto Baseline	Feature Replit	Notas
`CLAUDE.md`	`.replit` + `replit.nix` config	Configuracion del entorno
`AGENTS.md`	Agent instructions (prompt)	Instrucciones en lenguaje natural
`.claude/skills/`	No soportado	Sin sistema de knowledge base
`.claude/rules/`	No soportado	Sin rules nativas
`.claude/hooks/`	No soportado — CI	Sin hooks locales
Gate check	No soportado — CI	Sin gates nativos
Intent YAML	Replit Agent task	Descripcion de tarea en chat
FAB headless	No soportado	Solo interactivo
F06 (implementacion)	Replit como entorno de prototipado	Build + deploy integrado
Cost profiles	Effort modes (Economy/Power/Turbo)	Economy = bajo costo, Turbo = maximo rendimiento

Setup basico

# 1. Crear Repl desde template con baseline
# En Replit, importar repo con baseline/ como submodule

# 2. Configurar .replit para enforcement
cat > .replit << 'EOF'
run = "python3 baseline/scripts/compliance-linter.py --project-dir . --track solo"
[languages.python3]
pattern = "**/*.py"
EOF

# 3. Usar Replit como entorno de prototipado rapido (F06)
# Ideal para: MVPs, prototipos, demos
# No ideal para: produccion enterprise, proyectos con governance estricta

# 4. Cost profiles para fab-cost-guard
# Economy → budget_profile: low (< $5/sesion)
# Power   → budget_profile: medium (< $15/sesion)
# Turbo   → budget_profile: high (< $30/sesion)

Limitaciones

Limitacion	Impacto	Mitigacion
Platform lock-in	Dificil migrar fuera de Replit	Usar como prototipado (F06), no produccion
Sin acceso a scripts locales	No se pueden ejecutar scripts de enforcement	CI externo obligatorio
Sin governance nativa	No hay gates, rules, ni hooks	CI como unica capa de enforcement
Sin MCP	No se puede usar framework-mcp-server	Documentacion manual en prompts
Sin FAB headless	No se puede automatizar	Solo desarrollo interactivo

7.3 Factory.ai

Concepto: Plataforma enterprise de Droids autonomos con seguridad corporativa. Factory.ai opera “Droids” — agentes autonomos especializados que ejecutan tareas de ingenieria dentro de un entorno seguro y auditable. Enfocada en equipos enterprise con requisitos de compliance y seguridad.

Mapeo

Concepto Baseline	Feature Factory.ai	Notas
`CLAUDE.md`	Droid configuration	Configuracion del Droid
`AGENTS.md`	Droid context / playbook	Contexto de proyecto
`.claude/skills/`	Droid knowledge base	Documentos del proyecto
`.claude/rules/`	Droid guardrails	Reglas de seguridad enterprise
`.claude/hooks/`	Droid triggers	Triggers automaticos
Gate check	Droid checkpoints	Puntos de verificacion
Intent YAML	Factory task	Tarea asignada al Droid
FAB headless	Droid session autonoma	Ejecucion sin intervencion
FABs	Droids	Mapeo 1:1 conceptual
Kill switch	Factory emergency stop	Parada de emergencia enterprise

Setup basico

# 1. Configurar Droid con contexto del framework
# En Factory.ai dashboard:
#   - Crear Droid con playbook basado en CLAUDE.md
#   - Cargar guias como knowledge base
#   - Configurar guardrails alineados con .claude/rules/

# 2. Mapear intents → Factory tasks
# Factory.ai soporta integracion con GitHub Issues y JIRA
# Configurar webhook para convertir intents a tasks

# 3. CI como enforcement complementario
# Factory tiene checkpoints nativos, pero CI sigue siendo recomendado
# para validacion cruzada con compliance-linter.py

# 4. Mapeo Droids → FABs
# Un Droid = Un FAB
# Factory task queue = Intent queue
# Droid metrics = FAB telemetria (via fab-eval-builders.py)

Limitaciones

Limitacion	Impacto	Mitigacion
Closed-source	No se puede auditar internamente	CI + auditorias periodicas
Pricing opaco	Dificil estimar costos de FAB	fab-cost-guard.py con alertas conservadoras
Sin MCP nativo	No se puede usar framework-mcp-server	Knowledge base como alternativa
Vendor lock-in	Dependencia de la plataforma	Mantener intents en formato estandar YAML
API limitada	Integracion programatica limitada	Webhook + CI como puente

7.4 OpenHands (All Hands AI)

Concepto: Framework open-source (licencia MIT) y model-agnostic para construir agentes de software. OpenHands provee un SDK para definir agentes personalizados, soporta multiples LLMs (Claude, GPT, Llama, etc.) y puede ejecutarse self-hosted. Es la opcion mas flexible y composable para implementar FABs custom.

Mapeo

Concepto Baseline	Feature OpenHands	Notas
`CLAUDE.md`	Agent config / system prompt	Instrucciones del agente
`AGENTS.md`	Agent definition (SDK)	Definicion programatica del agente
`.claude/skills/`	Agent tools / knowledge	Herramientas y contexto del agente
`.claude/rules/`	Agent guardrails (SDK)	Reglas implementadas en codigo
`.claude/hooks/`	Agent event handlers	Hooks programaticos via SDK
Gate check	Custom gate logic (SDK)	Implementable con fab-gate-check.py
Intent YAML	OpenHands task	Tarea asignada al agente
FAB headless	OpenHands headless mode	Ejecucion autonoma sin UI
FABs	OpenHands agents	Agentes definidos con SDK
MCP	Si — MCP nativo	framework-mcp-server.py integrable

Setup basico

# 1. Instalar OpenHands
pip install openhands-ai

# 2. Configurar agente con contexto Baseline
cat > openhands-config.yaml << 'EOF'
agent:
  name: "baseline-fab"
  model: "claude-sonnet-4-20250514"   # model-agnostic: cambiar por cualquier LLM
  system_prompt_file: "CLAUDE.md"
  tools:
    - name: "compliance-linter"
      command: "python3 baseline/scripts/compliance-linter.py --project-dir . --track solo"
    - name: "gate-check"
      command: "bash baseline/scripts/gate-check.sh --project-dir . --track solo"
  mcp_servers:
    - command: "python3"
      args: ["baseline/scripts/framework-mcp-server.py", "--project-dir", "."]
EOF

# 3. Ejecutar agente con intent
openhands run --config openhands-config.yaml --task "$(cat intent/current-intent.yaml)"

# 4. Self-hosted para privacidad total
docker run -v $(pwd):/workspace openhands/openhands:latest \
  --config /workspace/openhands-config.yaml \
  --task "Implementar feature segun intent"

Ventajas (vs plataformas closed-source)

Ventaja	Detalle
Open-source (MIT)	Codigo auditable, sin vendor lock-in
Self-hosted	Datos nunca salen del entorno del equipo
Model-agnostic	Funciona con Claude, GPT-4, Llama, Mistral, etc.
SDK composable	Definir agentes custom con logica de gates integrada
MCP nativo	Integra framework-mcp-server.py directamente
Hooks programaticos	Implementar PreCommit, PostToolUse en Python
Costo controlable	Self-hosted = solo costo de API del LLM

Limitaciones

Limitacion	Impacto	Mitigacion
Requiere setup tecnico	Mayor esfuerzo inicial que plataformas SaaS	Usar template de configuracion
Sin UI empresarial	No hay dashboard para managers	fab-factory.sh + fab-health-check.sh
Comunidad en crecimiento	Menos documentacion que plataformas establecidas	Contribuir al proyecto open-source
Sin soporte enterprise nativo	No hay SLA ni soporte comercial	Equipo interno de soporte

8. Scheduled Task Patterns (v7.5)

Las plataformas modernas estan convergiendo hacia un modelo de automations: tareas que se ejecutan automaticamente en respuesta a eventos o en horarios programados. Esta seccion documenta como el framework Baseline implementa estos patrones.

8.1 Patrones de Automatizacion por Plataforma

Codex-style Automations

OpenAI Codex introdujo el concepto de “automations” — tareas que se disparan automaticamente:

Trigger Codex	Descripcion	Equivalente Baseline
On GitHub push	Se ejecuta cuando hay push a un branch	CI workflow (on: push)
Scheduled (cron)	Se ejecuta en horarios programados	fab_triggers.yaml (cron)
On CI event	Se ejecuta cuando un job de CI falla/pasa	fab_triggers.yaml (ci_event)
On PR review	Se ejecuta cuando se solicita review	fab_triggers.yaml (pr_event)

Cursor-style Automations

Cursor esta desarrollando “background agents” con triggers similares:

Trigger Cursor	Descripcion	Equivalente Baseline
On Slack message	Se ejecuta al recibir mensaje en canal	fab_triggers.yaml (webhook)
On timer	Se ejecuta en intervalo definido	fab_triggers.yaml (cron)
On codebase change	Se ejecuta al detectar cambios	fab_triggers.yaml (file_watch)
On issue assigned	Se ejecuta al asignar issue	fab_triggers.yaml (github_event)

8.2 Implementacion en Baseline: fab_triggers.yaml

El framework unifica todos los patrones de automatizacion en un solo archivo declarativo:

# Scheduled Task Patterns — AI-First Engineering Framework v7.5

version: "1.0"
triggers:

  # ── Patron Codex-style: on push ──
  - id: "post-push-compliance"
    type: github_event
    event: push
    branches: [main, develop]
    action:
      intent: "Ejecutar compliance linter y reportar resultados"
      fab_mode: headless
      budget_max_usd: 2.00
      script: "python3 baseline/scripts/compliance-linter.py --project-dir . --track lean --format json"

  # ── Patron Codex-style: scheduled ──
  - id: "nightly-security-scan"
    type: cron
    schedule: "0 2 * * *"           # 2 AM diario
    action:
      intent: "Ejecutar SAST/SCA scan nocturno y crear issues para hallazgos criticos"
      fab_mode: headless
      budget_max_usd: 5.00
      script: "python3 baseline/scripts/sast-sca-scanner.py --project-dir . --format json --severity high,critical"
      on_finding: create_github_issue

  # ── Patron Codex-style: on CI event ──
  - id: "ci-failure-analysis"
    type: ci_event
    event: failure
    workflow: "baseline-enforcement"
    action:
      intent: "Analizar fallo de CI, identificar causa raiz y proponer fix"
      fab_mode: headless
      budget_max_usd: 3.00

  # ── Patron Cursor-style: webhook (Slack) ──
  - id: "slack-intake"
    type: webhook
    source: slack
    channel: "#engineering-requests"
    action:
      intent: "Procesar mensaje de Slack como intent, validar y agregar a cola"
      fab_mode: headless
      budget_max_usd: 1.00
      script: "bash baseline/scripts/fab-intake.sh --source slack"

  # ── Patron Cursor-style: file watch ──
  - id: "spec-change-validation"
    type: file_watch
    paths: ["project/F05_contracts/*.yaml"]
    action:
      intent: "Validar cambios en contratos API y verificar backward compatibility"
      fab_mode: headless
      budget_max_usd: 2.00
      script: "python3 baseline/scripts/artifact-validator.py"

  # ── Scheduled: DORA metrics semanal ──
  - id: "weekly-dora-report"
    type: cron
    schedule: "0 9 * * 1"           # Lunes 9 AM
    action:
      intent: "Generar reporte DORA semanal con atribucion AI y publicar en dashboard"
      fab_mode: headless
      budget_max_usd: 3.00
      script: "python3 baseline/scripts/dora-metrics.py --project-dir . --period weekly --format json"
      on_complete: notify_slack

8.3 Tabla Comparativa: Triggers

Patron	Codex Automations	Cursor Background	Baseline fab_triggers.yaml
On push	Si (nativo)	No	Si (github_event)
Cron/scheduled	Si (nativo)	Si (on timer)	Si (cron)
On CI event	Si (nativo)	No	Si (ci_event)
On PR review	Si (nativo)	No	Si (github_event)
On Slack message	No	Si (nativo)	Si (webhook)
On file change	No	Si (nativo)	Si (file_watch)
On issue assigned	No	Si (nativo)	Si (github_event)
Declarativo (YAML)	No (UI/API)	No (UI)	Si (fab_triggers.yaml)
Budget control	No	No	Si (budget_max_usd)
Plataforma-agnostico	Solo Codex	Solo Cursor	Cualquier FAB runtime
Auditable (git)	No	No	Si (versionado en repo)

8.4 Ejemplo: Nightly Security Scan Automation

Escenario: escaneo de seguridad nocturno que crea issues automaticamente.

# fab_triggers.yaml — trigger
- id: "nightly-security-scan"
  type: cron
  schedule: "0 2 * * *"
  action:
    intent: "Ejecutar SAST/SCA scan, OWASP ASI check, y MCP security audit"
    fab_mode: headless
    budget_max_usd: 5.00
    steps:
      - script: "python3 baseline/scripts/sast-sca-scanner.py --project-dir . --format json"
        output: "reports/sast-sca-latest.json"
      - script: "python3 baseline/scripts/owasp-asi-checker.py --project-dir . --format json"
        output: "reports/owasp-asi-latest.json"
      - script: "python3 baseline/scripts/mcp-security-audit.py --project-dir . --format json"
        output: "reports/mcp-audit-latest.json"
    on_finding:
      severity: [critical, high]
      action: create_github_issue
      labels: ["security", "automated"]
    on_complete:
      notify: slack
      channel: "#security-alerts"

Flujo de ejecucion:

2:00 AM → cron trigger
  → fab-factory.sh spawn FAB (headless)
    → sast-sca-scanner.py (SAST + SCA)
    → owasp-asi-checker.py (OWASP ASI01-ASI10)
    → mcp-security-audit.py (MCP security)
    → Generar reportes JSON
    → Si hay hallazgos critical/high → crear GitHub Issues
    → Notificar a #security-alerts en Slack
  → fab-cost-guard.py verifica budget ($5 max)
  → fab-eval-builders.py registra metricas de la sesion

8.5 Ejemplo: Weekly DORA Metrics Report

Escenario: reporte semanal de metricas DORA con atribucion AI.

# fab_triggers.yaml — trigger
- id: "weekly-dora-report"
  type: cron
  schedule: "0 9 * * 1"           # Lunes 9 AM
  action:
    intent: "Generar metricas DORA semanales con atribucion AI"
    fab_mode: headless
    budget_max_usd: 3.00
    steps:
      - script: "python3 baseline/scripts/dora-metrics.py --project-dir . --period weekly --format json"
        output: "reports/dora-weekly-latest.json"
      - script: "python3 baseline/scripts/fab-eval-builders.py --project-dir . --period weekly"
        output: "reports/fab-eval-weekly-latest.json"
    on_complete:
      notify: slack
      channel: "#engineering-metrics"
      template: |
        *DORA Weekly Report — {{date}}*
        - Deployment Frequency: {{deploy_freq}}
        - Lead Time: {{lead_time}}
        - MTTR: {{mttr}}
        - Change Failure Rate: {{cfr}}
        - AI Attribution: {{ai_pct}}% de commits asistidos por AI

9. Tabla Comparativa

9.1 Soporte de Features por Plataforma

Caracteristica	Claude Code	Codex	Cursor	Kiro	Copilot	Amazon Q	Windsurf	Gemini CLI	Devin	Replit Agent	Factory.ai	OpenHands
Instrucciones nativas	CLAUDE.md	AGENTS.md	.cursor/rules	Via AGENTS.md	copilot-instructions.md	README.md	.windsurfrules	GEMINI.md	Playbooks	Agent prompt	Droid config	Agent config
Skills nativos	Si	Si	Custom docs	Via steering	No	No	No	No	Knowledge base	No	Knowledge base	SDK tools
Rules auto-cargadas	Si	En AGENTS.md	Si	Si	No	No	En .windsurfrules	Si	En playbook	No	Guardrails	SDK guardrails
Hooks nativos	Si (settings.json)	Automations	Limitado	Si (.kiro.hook)	No	No	No	Limitado	No	No	Triggers	SDK handlers
MCP nativo	Si	Si	Si	Si	No	No	Si	Si	No	No	No	Si
Agent mode	Si	Si	Composer Agent	Si	Chat Agent	Chat Agent	Cascade	CLI Agent	Autonomo	Autonomo	Droids	SDK Agents
FAB headless	Si (—background)	Tasks (—task)	No	Via CLI tasks	No	No	No	No	Si (nativo)	No	Si (Droids)	Si (headless)
Gate enforcement	Nativo + CI	CI	CI	CI	CI	CI	CI	CI	Review + CI	CI	Checkpoints + CI	SDK + CI
Compliance linter	Nativo (hook)	CI	CI	CI	CI	CI	CI	CI	CI	CI	CI	SDK + CI
Worktrees / aislamiento	Nativo	Sandbox	No	No	No	No	No	No	Cloud workspace	Repl aislado	Workspace aislado	Docker/sandbox
Permisos granulares	Si	Si	Limitado	Limitado	No	No	Limitado	Limitado	Limitado	No	Si (enterprise)	SDK configurable
Spec-driven	Manual	Manual	Manual	Nativo	Manual	Manual	Manual	Manual	Manual	Manual	Manual	SDK configurable
Open-source	No	No	No	No	No	No	No	No	No	No	No	Si (MIT)
Self-hosted	No	No	No	No	No	No	No	No	No	No	On-premise	Si
Automations/Triggers	Hooks + CI	Automations	Background agents	Hooks	No	No	No	No	API triggers	No	Droid triggers	SDK triggers

9.2 Nivel de Integracion

Plataforma	Nivel	Esfuerzo de Setup	Governance Nativa	Requiere CI
Claude Code	Nativo (100%)	Minimo — init-project.sh	Completa	Recomendado
Codex	Alto (85%)	Bajo — adaptar AGENTS.md	Alta	Recomendado
Kiro	Alto (80%)	Bajo — sync steering + hooks	Alta	Recomendado
OpenHands	Alto (75%)	Medio — SDK config + MCP	Alta (SDK)	Recomendado
Cursor	Medio (65%)	Medio — sync rules	Media	Obligatorio
Gemini CLI	Medio (60%)	Medio — generar GEMINI.md	Media	Obligatorio
Windsurf	Medio (55%)	Medio — .windsurfrules + MCP	Parcial	Obligatorio
Devin	Medio (50%)	Medio — playbooks + knowledge	Parcial (checkpoints)	Obligatorio
Factory.ai	Medio (50%)	Medio — Droid config + knowledge	Parcial (checkpoints)	Obligatorio
Copilot	Bajo (35%)	Bajo — copilot-instructions.md	Minima	Obligatorio
Amazon Q	Bajo (30%)	Bajo — README.md	Minima	Obligatorio
Replit Agent	Bajo (25%)	Bajo — prompt instructions	Minima	Obligatorio

9.3 Recomendacion por Escenario

Escenario	Plataforma Recomendada	Razon
Maximo governance + autonomia	Claude Code	Integracion nativa completa, FAB headless
Equipo con preferencia OpenAI	Codex	Buen soporte de AGENTS.md, tasks headless
Spec-driven + governance	Kiro	Specs nativos alineados con F01-F05, steering + hooks
IDE-first (desarrolladores senior)	Cursor	Experiencia IDE fluida, MCP, Composer Agent
Organizacion enterprise Microsoft	Copilot	Integrado en GitHub y VS Code
Organizacion enterprise AWS	Kiro o Amazon Q	Kiro para governance, Amazon Q para integracion AWS
Equipo multimodelo	Windsurf	Soporta multiples modelos, MCP
Equipo Google Cloud	Gemini CLI	Integrado en ecosistema Google
FAB runtime open-source	OpenHands	MIT license, self-hosted, SDK composable, MCP nativo
FAB runtime enterprise (closed)	Factory.ai	Droids autonomos, seguridad enterprise, on-premise
Ingeniero autonomo cloud	Devin	Workspace persistente, ejecucion totalmente autonoma
Prototipado rapido (F06)	Replit Agent	Build + deploy integrado, ideal para MVPs

10. Mejores Practicas Cross-Platform

10.1 CI como Capa de Enforcement Universal

Independientemente de la plataforma AI que use el equipo, CI es la red de seguridad universal. Todo PR debe pasar por:

name: Baseline Framework Enforcement
on:
  pull_request:
    branches: [main, develop]

jobs:
  compliance-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout con submodules
        uses: actions/checkout@v4
        with:
          submodules: recursive

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Instalar dependencias
        run: pip install pyyaml jsonschema

      - name: Compliance Linter
        run: |
          python3 baseline/scripts/compliance-linter.py \
            --project-dir . \
            --track lean \
            --min-score 80 \
            --format github-actions
        continue-on-error: false

      - name: Validar artefactos YAML
        run: |
          find project/ -name "*.yaml" -type f | while read file; do
            echo "Validando: $file"
            python3 baseline/scripts/artifact-validator.py "$file"
          done

      - name: Gate Check
        run: |
          bash baseline/scripts/gate-check.sh \
            --project-dir . \
            --track lean \
            --format github-actions

      - name: Version Check
        run: |
          bash baseline/scripts/version-check.sh

Este workflow funciona igual sin importar si el codigo fue generado por Claude Code, Codex, Cursor, Copilot o cualquier otra plataforma.

10.2 AGENTS.md como Puente Universal

AGENTS.md es reconocido por la mayoria de plataformas (Claude Code, Codex) y puede adaptarse facilmente para otras. Es el archivo puente mas versatil:

# AGENTS.md — [Nombre del Proyecto]
# AI-First Engineering Framework v7.2

## 7 Golden Principles

1. **Framework-first**: Toda decision sigue el lifecycle F01→F10
2. **Artifact-driven**: Todo output es un artefacto YAML versionado
3. **Gate-governed**: No avanzar sin pasar el gate de la fase
4. **Context-aware**: Cargar solo guias relevantes para la tarea
5. **Quality-enforced**: Score >= 80% para merge
6. **Track-appropriate**: Full/Lean/Solo segun equipo
7. **Security-embedded**: Clasificacion de datos desde F01

## Context Router

| Tarea | Fase | Guia | Skill |
|---|---|---|---|
| Problem statement | F01 | CORE_F01_Strategy | f01-strategy |
| Domain modeling | F02 | CORE_F02_Domain | f02-domain |
| Knowledge base | F03 | CORE_F03_Knowledge | f03-knowledge |
| Architecture | F04 | CORE_F04_Architecture | f04-architecture |
| API contracts | F05 | CORE_F05_Contracts | f05-contracts |
| Implementation | F06 | CORE_F06_Implementation | f06-implementation |
| Testing & evals | F07 | CORE_F07_TEVV | f07-tevv |
| Security review | F08 | CORE_F08_Security | f08-security |
| Operations | F09 | CORE_F09_Operations | f09-operations |
| Evolution | F10 | CORE_F10_Evolution | f10-evolution |

## Reglas de Calidad

- YAML: 2 espacios, schemas validos
- Commits: conventional commits
- PRs: incluir score de compliance
- Tests: cobertura >= 80%

## Enforcement

Antes de merge:
$ python3 baseline/scripts/compliance-linter.py --project-dir . --track lean
$ bash baseline/scripts/gate-check.sh --project-dir . --track lean

10.3 Conventional Commits para AI Attribution

Independientemente de la plataforma, usar conventional commits con atribucion AI permite:

Rastrear que porcentaje del codigo fue generado por AI
Identificar que plataforma genero cada cambio
Medir productividad por plataforma

Formato recomendado

# Commit generado por Claude Code
git commit -m "feat(F06): implement payment processing endpoint

Implements POST /api/v1/payments with Stripe integration.
Includes input validation, error handling, and audit logging.

Co-Authored-By: Claude Code <noreply@anthropic.com>"

# Commit generado por Codex
git commit -m "feat(F07): add integration tests for payment service

Tests cover happy path, validation errors, and Stripe failures.
Coverage: 94% for payment module.

Co-Authored-By: OpenAI Codex <noreply@openai.com>"

# Commit generado por Cursor
git commit -m "fix(F06): handle race condition in concurrent payments

Adds distributed lock using Redis to prevent double-charge.

Co-Authored-By: Cursor AI <noreply@cursor.com>"

Script de analisis de atribucion

#!/bin/bash
# Generar reporte de atribucion AI por plataforma
set -euo pipefail

echo "=== AI Attribution Report ==="
echo ""

TOTAL=$(git log --oneline | wc -l)
echo "Total commits: $TOTAL"
echo ""

echo "Por plataforma:"
echo "  Claude Code: $(git log --all --author='Claude' --oneline 2>/dev/null | wc -l) commits"
echo "  Codex:       $(git log --all --grep='Co-Authored-By.*Codex' --oneline 2>/dev/null | wc -l) commits"
echo "  Cursor:      $(git log --all --grep='Co-Authored-By.*Cursor' --oneline 2>/dev/null | wc -l) commits"
echo "  Kiro:        $(git log --all --grep='Co-Authored-By.*Kiro' --oneline 2>/dev/null | wc -l) commits"
echo "  Copilot:     $(git log --all --grep='Co-Authored-By.*Copilot' --oneline 2>/dev/null | wc -l) commits"
echo "  Humano:      $(git log --all --oneline --invert-grep --grep='Co-Authored-By' 2>/dev/null | wc -l) commits"
echo ""

echo "Por fase del framework:"
for phase in F01 F02 F03 F04 F05 F06 F07 F08 F09 F10; do
  count=$(git log --all --grep="($phase)" --oneline 2>/dev/null | wc -l)
  if [ "$count" -gt 0 ]; then
    echo "  $phase: $count commits"
  fi
done

10.4 Gradual Adoption

No es necesario adoptar todo el framework de una vez. La estrategia recomendada es adopcion gradual:

Nivel 1: Solo CI (cualquier plataforma)

Esfuerzo: Minimo (1 hora)
Valor: Enforcement basico en PRs

Pasos:
1. Agregar baseline como submodule
2. Configurar CI workflow con compliance-linter
3. Establecer min-score en 60% (incrementar gradualmente)

Nivel 2: CI + Instrucciones (cualquier plataforma)

Esfuerzo: Bajo (2-4 horas)
Valor: Agentes AI siguen el framework

Pasos:
1. Todo lo anterior
2. Crear CLAUDE.md / AGENTS.md / .cursorrules / etc.
3. Documentar reglas de calidad del proyecto
4. Subir min-score a 70%

Nivel 3: CI + Instrucciones + Skills (plataformas con soporte)

Esfuerzo: Medio (4-8 horas)
Valor: Agentes AI tienen contexto metodologico completo

Pasos:
1. Todo lo anterior
2. Configurar skills/docs por fase
3. Configurar context routing
4. Subir min-score a 80%

Nivel 4: Integracion completa (Claude Code / Codex / Kiro)

Esfuerzo: Alto (1-2 dias)
Valor: Governance completa con enforcement nativo

Pasos:
1. Todo lo anterior
2. Configurar hooks nativos
3. Configurar MCP server
4. Configurar permisos granulares
5. Habilitar FAB mode para tareas autonomas
6. Subir min-score a 85%

10.5 Multi-Plataforma en el Mismo Proyecto

Es comun que un equipo use multiples plataformas simultaneamente. El framework lo soporta:

mi-proyecto/
  baseline/                    # Framework (submodule)
  CLAUDE.md                    # Para Claude Code
  AGENTS.md                    # Para Claude Code + Codex + Kiro
  GEMINI.md                    # Para Gemini CLI
  .cursorrules                 # Para Cursor (reglas globales)
  .windsurfrules               # Para Windsurf
  .claude/                     # Config Claude Code
    skills/
    rules/
    hooks/
    agents/
    settings.json
  .kiro/                       # Config Kiro
    steering/
    hooks/
    specs/
  .cursor/                     # Config Cursor
    rules/
  .gemini/                     # Config Gemini
    rules/
    settings.json
  .github/
    copilot-instructions.md    # Para Copilot
    workflows/
      baseline-enforcement.yml # CI universal
  project/                     # Artefactos del proyecto

Script de sincronizacion multi-plataforma

#!/bin/bash
# Sincronizar reglas de Baseline a todas las plataformas configuradas
set -euo pipefail

echo "=== Sincronizacion Multi-Plataforma ==="

# Fuente de verdad: CLAUDE.md + .claude/
SOURCE_INSTRUCTIONS="CLAUDE.md"
SOURCE_SKILLS=".claude/skills"
SOURCE_RULES=".claude/rules"

# --- Codex (AGENTS.md ya es compatible) ---
if [ -f "AGENTS.md" ]; then
  echo "[OK] AGENTS.md existe (Codex compatible)"
fi

# --- Kiro ---
if [ -d ".kiro" ]; then
  echo "Sincronizando → .kiro/steering/"
  mkdir -p .kiro/steering/
  for rule in ${SOURCE_RULES}/*.md; do
    rule_name=$(basename "$rule" .md)
    target=".kiro/steering/rule-${rule_name}.md"
    cat > "$target" << EOF
---
description: "Regla del framework: ${rule_name}"
inclusion: always
---

EOF
    cat "$rule" >> "$target"
  done
  echo "[OK] Kiro steering sincronizado"
fi

# --- Cursor ---
if [ -d ".cursor" ]; then
  echo "Sincronizando → .cursor/rules/"
  mkdir -p .cursor/rules/
  for rule in ${SOURCE_RULES}/*.md; do
    cp "$rule" ".cursor/rules/$(basename "$rule")"
  done
  echo "[OK] Cursor rules sincronizadas"
fi

# --- Windsurf ---
if [ -f ".windsurfrules" ]; then
  echo "[OK] .windsurfrules existe (actualizar manualmente si CLAUDE.md cambio)"
fi

# --- Gemini ---
if [ -d ".gemini" ]; then
  echo "Sincronizando → .gemini/rules/"
  mkdir -p .gemini/rules/
  for rule in ${SOURCE_RULES}/*.md; do
    cp "$rule" ".gemini/rules/$(basename "$rule")"
  done
  # Sincronizar GEMINI.md
  if [ -f "GEMINI.md" ] && [ "$SOURCE_INSTRUCTIONS" -nt "GEMINI.md" ]; then
    cp "$SOURCE_INSTRUCTIONS" "GEMINI.md"
    echo "[OK] GEMINI.md actualizado desde CLAUDE.md"
  fi
  echo "[OK] Gemini rules sincronizadas"
fi

# --- Copilot ---
if [ -d ".github" ]; then
  echo "[INFO] .github/copilot-instructions.md debe actualizarse manualmente"
fi

echo ""
echo "=== Sincronizacion completa ==="

10.6 Metricas de Governance Cross-Platform

Para medir la efectividad de la governance independientemente de la plataforma:

Metrica	Como Medir	Target
Compliance Score promedio	`compliance-linter.py` en CI	>= 80%
% PRs que pasan gate check	CI pipeline stats	>= 95%
Artefactos validos vs totales	`artifact-validator.py` en CI	>= 90%
Cobertura de fases (F01-F10)	Analisis de directorio `project/`	>= 6 fases
Tiempo de feedback (lint → fix)	CI pipeline duration	< 5 min
AI Attribution ratio	Script de atribucion	Reportar (sin target fijo)

11. Troubleshooting

11.1 Problemas Comunes

Problema	Plataforma	Solucion
CLAUDE.md no se carga	Claude Code	Verificar que esta en la raiz del proyecto
.cursor/rules/ ignorado	Cursor	Verificar frontmatter con `globs` y `description`
MCP server no conecta	Cualquiera con MCP	Verificar `python3` en PATH, permisos de ejecucion
Compliance score bajo	Todas	Ejecutar linter localmente para ver reglas fallidas
Submodule no actualizado	Todas	`cd baseline && git pull && cd .. && git add baseline`
Skills no disponibles	Cursor, Copilot	Estas plataformas no tienen skills nativos — usar CI
Hooks no ejecutan	Cursor, Windsurf	Configurar enforcement via CI en lugar de hooks nativos
Steering no se carga	Kiro	Verificar YAML frontmatter con `inclusion` y `description`
.kiro.hook no ejecuta	Kiro	Verificar formato JSON, `enabled: true` y patrones en `when`
FAB intent rechazado	Claude Code, Codex	Validar con `validate-intent.py` antes de lanzar

11.2 Verificacion de Integracion

#!/bin/bash
# Verificar que la integracion con la plataforma esta correcta
set -euo pipefail

echo "=== Verificacion de Integracion ==="
ERRORS=0

# Verificar baseline submodule
if [ -d "baseline" ] && [ -f "baseline/scripts/compliance-linter.py" ]; then
  echo "[OK] Baseline submodule presente"
else
  echo "[ERROR] Baseline submodule no encontrado"
  ERRORS=$((ERRORS + 1))
fi

# Verificar archivo de instrucciones
for file in CLAUDE.md AGENTS.md; do
  if [ -f "$file" ]; then
    echo "[OK] $file presente"
  else
    echo "[WARN] $file no encontrado"
  fi
done

# Verificar directorio .claude/
if [ -d ".claude" ]; then
  echo "[OK] .claude/ presente"
  for dir in skills rules hooks agents; do
    if [ -d ".claude/$dir" ]; then
      count=$(ls -1 ".claude/$dir/" 2>/dev/null | wc -l)
      echo "  [OK] .claude/$dir/ ($count archivos)"
    else
      echo "  [WARN] .claude/$dir/ no encontrado"
    fi
  done
else
  echo "[WARN] .claude/ no encontrado"
fi

# Verificar CI
if [ -f ".github/workflows/baseline-enforcement.yml" ]; then
  echo "[OK] CI workflow configurado"
else
  echo "[WARN] CI workflow no encontrado — governance limitada a plataforma"
fi

# Verificar plataformas especificas
echo ""
echo "Plataformas detectadas:"
[ -f "CLAUDE.md" ] && echo "  - Claude Code (CLAUDE.md)"
[ -f "AGENTS.md" ] && echo "  - Codex / Claude Code (AGENTS.md)"
[ -d ".kiro" ] && echo "  - Kiro (.kiro/)"
[ -d ".cursor" ] && echo "  - Cursor (.cursor/)"
[ -f ".cursorrules" ] && echo "  - Cursor (.cursorrules)"
[ -f ".windsurfrules" ] && echo "  - Windsurf (.windsurfrules)"
[ -f "GEMINI.md" ] && echo "  - Gemini CLI (GEMINI.md)"
[ -d ".gemini" ] && echo "  - Gemini CLI (.gemini/)"
[ -f ".github/copilot-instructions.md" ] && echo "  - GitHub Copilot (.github/copilot-instructions.md)"

echo ""
if [ $ERRORS -gt 0 ]; then
  echo "=== $ERRORS errores encontrados ==="
  exit 1
else
  echo "=== Verificacion completa — sin errores criticos ==="
fi

12. Roadmap de Integracion

12.1 Estado Actual (v7.2 — Marzo 2026)

Plataforma	Estado de Integracion	Proximos Pasos
Claude Code	Nativo completo	Mejorar FAB checkpoint protocol
Codex	Documentado, validado	Script de setup automatico
Kiro	Documentado, steering + hooks	Script de setup automatico, sync bidireccional
Cursor	Documentado, script de sync	Mejorar sync bidireccional
Copilot	Documentado, CI only	Evaluar Agent Mode mejoras
Amazon Q	Documentado, CI only	Evaluar nuevas features
Windsurf	Documentado, MCP	Mejorar integracion Cascade
Gemini CLI	Documentado, MCP + rules	Validar GEMINI.md compat
Devin	Documentado (v7.5)	Validar playbook integration, API automation
Replit Agent	Documentado (v7.5)	Evaluar como entorno F06, cost profiles
Factory.ai	Documentado (v7.5)	Validar Droid→FAB mapping, enterprise pilot
OpenHands	Documentado (v7.5)	SDK integration, template de agente Baseline

12.2 Futuro (v7.5+)

Script universal de setup: init-platform.sh <platform> que genera la config especifica
Sync bidireccional: Cambios en .cursor/rules/ se propagan de vuelta a .claude/rules/
Dashboard multi-plataforma: Metricas de governance unificadas
MCP Gateway: Un solo MCP server que abstrae la plataforma subyacente
Portabilidad de agentes: Definir agentes una vez, desplegar en cualquier plataforma
fab_triggers.yaml runtime: Motor de ejecucion para scheduled tasks (v7.5)
OpenHands SDK template: Template oficial de agente Baseline para OpenHands
Devin API integration: Mapeo automatico intent → Devin session via API
Factory.ai Droid connector: Puente FAB→Droid para enterprise

13. Referencias

Recurso	Ubicacion
Framework Overview	`framework/core/F00_Foundation/CORE_F00_Framework_Overview.md`
Framework Enforcement Guide	`framework/guides/Framework_Enforcement_Guide.md`
MCP Integration Guide	`framework/guides/MCP_Integration_Guide.md`
Context Engineering Guide	`framework/guides/Context_Engineering_Guide.md`
FAB Intake & Headless Guide	`framework/guides/FAB_Intake_Headless_Workspace_Guide.md`
Agentic Workforce Guide	`framework/guides/Agentic_Workforce_Factory_Operations_Guide.md`
Brownfield Adoption Guide	`framework/guides/Brownfield_Adoption_Guide.md`
Init Project Script	`scripts/init-project.sh`
Init Brownfield Script	`scripts/init-brownfield.sh`
Compliance Linter	`scripts/compliance-linter.py`
MCP Server	`scripts/framework-mcp-server.py`
FAB Gate Check	`scripts/fab-gate-check.py`