🔄 Lifecycle — Ciclo de Vida

Objetivo: Que cualquier agente (o humano) pueda poner el proyecto en marcha con un solo comando.

El init.sh es la primera línea de defensa contra el caos. Debe detectar el stack, instalar dependencias y verificar que todo esté listo. Un buen init.sh incluye:

• set -e — fallar rápido si algo falla
• Detección de stack — package.json, Cargo.toml, requirements.txt, pyproject.toml
• Instalación de dependencias — npm install, cargo build, pip install
• Copia de .env — desde .env.example si no existe .env
• Verificación final — ¿el comando principal funciona?

Ejemplo de init.sh:

#!/bin/bash
# init.sh — Bootstrap del proyecto
set -e

echo "🔧 Inicializando proyecto..."

# Detectar gestor de paquetes
if [ -f "package.json" ]; then
    echo "📦 Instalando dependencias Node..."
    npm install
elif [ -f "Cargo.toml" ]; then
    echo "🦀 Construyendo proyecto Rust..."
    cargo build
elif [ -f "requirements.txt" ]; then
    echo "🐍 Instalando dependencias Python..."
    python3 -m venv venv
    source venv/bin/activate
    pip install -r requirements.txt
fi

# Copiar .env si no existe
if [ -f ".env.example" ] && [ ! -f ".env" ]; then
    cp .env.example .env
    echo "⚠️  Creado .env desde .env.example"
fi

echo "✅ Proyecto listo"

Tip: Mantenlo en la raíz con permisos de ejecución: chmod +x init.sh.

Objetivo: Garantizar que el proyecto corra igual en cualquier máquina.

Un Dockerfile o docker-compose.yml elimina la frase "en mi máquina sí funciona". Para proyectos con agentes, es aún más importante porque el agente puede ejecutarse en diferentes entornos.

Cuándo usar cada uno:

• Dockerfile — para una sola aplicación o servicio
• docker-compose.yml — para múltiples servicios (app + base de datos + agente)
• Containerfile — alternativa rootless con Podman

Checks del evaluador:

• ¿Existe Dockerfile, docker-compose.yml o Containerfile?
• ¿El compose define servicios con nombres claros?

Ejemplo docker-compose.yml:

version: "3.9"
services:
  app:
    build: .
    ports:
      - "3000:3000"
    env_file: .env
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb

Objetivo: Declarar explícitamente todo lo que el proyecto necesita para funcionar.

Sin un archivo de dependencias, el agente debe adivinar qué instalar. Los archivos más comunes:

• Python: requirements.txt, pyproject.toml, Pipfile
• Node: package.json, package-lock.json
• Rust: Cargo.toml, Cargo.lock
• Go: go.mod, go.sum
• Ruby: Gemfile, Gemfile.lock

Mejores prácticas:

• Versionar el lockfile (package-lock.json, Cargo.lock) para reproducibilidad
• Usar rangos de versión conservadores en el manifest principal
• Documentar dependencias de sistema (ej. libpq-dev) en README.md

Ejemplo pyproject.toml:

[project]
name = "harness-course"
version = "0.1.0"
dependencies = [
    "requests>=2.28",
    "pydantic>=2.0",
]

Objetivo: Separar secretos del código, ignorar archivos irrelevantes y definir los términos legales.

.env.example es el contrato de variables de entorno. Debe incluir todas las keys que el proyecto usa, con valores vacíos o de ejemplo:

# API Keys
TAVILY_API_KEY=
BRAVE_API_KEY=

# Configuración
DEBUG=false
PORT=3000

.gitignore evita que secrets y archivos temporales entren al repo:

# OS
.DS_Store
Thumbs.db

# Environment
.env

# Python
__pycache__/
*.py[cod]
venv/
.venv/

# IDE
.vscode/
.idea/

LICENSE define cómo otros pueden usar tu código. Para proyectos open-source, MIT es simple y permisiva:

MIT License

Copyright (c) 2026 Brahyan Belalcazar (ElBeRi)

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software...

Objetivo: Dejar el proyecto en un estado donde la próxima sesión pueda retomar sin fricción.

El session handoff es el procedimiento de cierre de sesión. Incluye:

• Commit de todo el trabajo en progreso
• Actualizar TASK.md con el estado actual
• Documentar bloqueos o descubrimientos en MEMORY.md
• Limpiar archivos temporales
• Verificar que init.sh sigue funcionando desde cero

Clean State Checklist:

• No hay archivos sin commit
• No hay secrets en el diff
• Los tests pasan
• El proyecto se puede clonar e inicializar en otra máquina

Documentación del handoff: Al menos un archivo del repo debe mencionar "handoff", "clean state" o "retomar" para que el evaluador lo detecte.

Antes de iniciar y antes de cerrar sesión, el agente debe verificar:

• ¿Existe init.sh, setup.sh, Makefile o script de bootstrap?
• ¿Existe Dockerfile o docker-compose.yml?
• ¿El repo tiene un archivo de dependencias declarado?
• ¿Existe .env.example con todas las variables documentadas?
• ¿Existe .gitignore que excluya .env y archivos temporales?
• ¿Existe LICENSE con copyright actualizado?
• ¿Hay documentación de handoff o clean state?
• ¿El init.sh ejecuta sin errores desde un clone fresco?

Score objetivo del subsistema Lifecycle: ≥ 80% en harness scan . --json