# TEMPLATE.md — Cómo adaptar ARNES a cualquier proyecto

## 1) Clonar y renombrar contexto
- Pon el código real dentro de `project/` (o elige otra ruta en `./scripts/start.sh`).
- Ajusta `backlog/features.json` (`project`, `description`).
- Crea primeras features reales en `features[]`.

## 2) Reglas específicas (sin tocar core)
- Opcional: crea `AGENTS.local.md` con reglas del dominio.
- Opcional: crea `scripts/verify.local.sh` con checks propios del stack.
- Mantén tickets y órdenes internas en English caveman (`harness/policies/language.md`).
- Usa tipos de ticket consistentes: `feature`, `fix`, `bug`, `chore`.
- Ajusta routing de modelos por rol/tarea en `harness/models.profiles.yml`.

## 3) Flujo estándar
0. Instalar ARNES en repo externo: `./scripts/install_into_repo.sh /path/to/project-repo`
1. `./scripts/start.sh` (primer uso)
2. `python3 scripts/new_ticket.py` (leader/triager)
3. `python3 scripts/agent_status.py show`
4. Seleccionar 1 feature `pending` y pasarla a `in_progress`
5. Implementar con artefactos en `work/artifacts/<feature_id>/`
6. Cerrar con gates `review/security/qa` + `documenter` aprobados
7. Publicar ticket: `python3 scripts/publish_ticket.py --feature-id F-001`
8. `python3 scripts/agent_status.py reset`

## 4) Contrato de cierre
- `status=done` exige:
  - `reviewer.json` APPROVED
  - `security.json` APPROVED
  - `qa.json` APPROVED
  - `leader-close.json` APPROVED
  - `publish.json` PUBLISHED
  - `./scripts/verify.sh` OK

## 5) Principio de template
- El core ARNES es agnóstico.
- Todo lo específico de proyecto vive en overlays (`AGENTS.local.md`, `verify.local.sh`, docs propias).
