arnes/HOWTO.md

HOWTO (breve) — iniciar ARNES en proyecto nuevo o ya empezado

1) Proyecto nuevo (greenfield)

mkdir mi-proyecto && cd mi-proyecto
git init
# instalar/copiAR ARNES dentro de este repo de proyecto
/path/to/arnes/scripts/install_into_repo.sh .
./scripts/start.sh
./scripts/verify.sh
python3 scripts/agent_status.py show

Después:

• Mete tu código dentro de project/ (o indica otra ruta en el wizard).
• Edita backlog/features.json (project, description).
• Crea tu primera feature pending (puedes usar starter-pack/backlog.features.bootstrap.json).
• Empieza el ciclo SDD (una feature a la vez).

---

2) Proyecto ya empezado (brownfield)

Copia al repo existente solo el core ARNES y coloca el código real en project/ (o usa otra ruta al lanzar el wizard). Recomendado:

/path/to/arnes/scripts/install_into_repo.sh .

Contenido core:

• harness/
• spec/
• backlog/
• work/
• scripts/
• platforms/
• AGENTS.md, CHECKPOINTS.md

Luego ejecuta:

./scripts/start.sh
./scripts/verify.sh
python3 scripts/agent_status.py show

Y añade checks del dominio en:

• scripts/verify.local.sh (opcional)

---

Crear ticket nuevo (leader/triager, EN caveman):

python3 scripts/new_ticket.py

Tipos soportados:

• feature
• fix
• bug
• chore

Al final del ticket:

python3 scripts/publish_ticket.py --feature-id F-001

Modelo por tarea:

• Config base en harness/models.profiles.yml
• Reglas en harness/policies/model-routing.md

Reglas operativas mínimas

• Máximo una feature en in_progress.
• done requiere gates review/security/qa aprobados.
• done requiere publish final con commit+push del ticket.
• Evidencia siempre en work/artifacts/<feature_id>/.
• Si verify.sh falla, no se cierra la feature.