146 lines
2.8 KiB
Markdown
146 lines
2.8 KiB
Markdown
# HOWTO — Cómo usar ARNES Framework
|
|
|
|
Guía rápida para arrancar proyectos nuevos usando este framework.
|
|
|
|
---
|
|
|
|
## Fórmula base (siempre igual)
|
|
|
|
1. **Crear repo nuevo**
|
|
2. **Copiar ARNES Framework dentro del repo**
|
|
3. **Configurar spec + backlog**
|
|
4. **Ejecutar verificación**
|
|
5. **Empezar implementación por features (una a la vez)**
|
|
|
|
---
|
|
|
|
## 1) Crear repo
|
|
|
|
```bash
|
|
mkdir mi-proyecto
|
|
cd mi-proyecto
|
|
git init
|
|
```
|
|
|
|
---
|
|
|
|
## 2) Copiar framework
|
|
|
|
Desde tu copia local de ARNES:
|
|
|
|
```bash
|
|
cp -R /ruta/a/arnes/* .
|
|
cp -R /ruta/a/arnes/.[!.]* . 2>/dev/null || true
|
|
```
|
|
|
|
> Si usas plantilla remota, clónala y copia su contenido al repo nuevo.
|
|
|
|
---
|
|
|
|
## 3) Personalizar proyecto
|
|
|
|
Edita mínimo:
|
|
|
|
- `README.md` (contexto del proyecto)
|
|
- `spec/product.md` (qué construir)
|
|
- `spec/tech.md` (stack y límites técnicos)
|
|
- `spec/acceptance.md` (criterios de aceptación)
|
|
- `backlog/features.json` (features iniciales en `pending`)
|
|
- `harness/agents.matrix.yml` (roles/permisos)
|
|
- `harness/workflow.stages.yml` (flujo y gates)
|
|
|
|
---
|
|
|
|
## 4) Elegir plataforma (pi.dev u opencode)
|
|
|
|
Usa el adaptador correspondiente:
|
|
|
|
- `platforms/pi/`
|
|
- `platforms/opencode/`
|
|
|
|
El núcleo del framework no cambia; solo cambian prompts/hooks/permisos de plataforma.
|
|
|
|
---
|
|
|
|
## 5) Inicializar estado de trabajo
|
|
|
|
Verifica que existan y estén limpios:
|
|
|
|
- `work/current.md`
|
|
- `work/history.md`
|
|
- `work/artifacts/`
|
|
|
|
Pon solo **1 feature activa** (`in_progress`) como máximo.
|
|
|
|
---
|
|
|
|
## 6) Ejecutar verificación inicial
|
|
|
|
```bash
|
|
./scripts/verify.sh
|
|
```
|
|
|
|
Si falla, **no empezar implementación** hasta dejar todo en verde.
|
|
|
|
---
|
|
|
|
## 7) Ciclo operativo por feature
|
|
|
|
Orden obligatorio:
|
|
|
|
1. `leader` orquesta
|
|
2. `architect` define/ajusta diseño
|
|
3. `implementer` implementa + tests
|
|
4. `reviewer` gate técnico
|
|
5. `security` gate seguridad
|
|
6. `qa` gate funcional
|
|
7. `leader` cierra si todo está aprobado
|
|
|
|
Reglas clave:
|
|
- una feature a la vez
|
|
- evidencia en disco (`work/artifacts/<feature>/...`)
|
|
- nadie marca `done` si falta un gate
|
|
|
|
---
|
|
|
|
## 8) Cierre de feature
|
|
|
|
Antes de pasar a `done`:
|
|
|
|
- `verify.sh` en verde
|
|
- review aprobado
|
|
- security aprobado
|
|
- qa aprobado
|
|
- resumen en `work/history.md`
|
|
|
|
---
|
|
|
|
## 9) Manejo de pérdida de contexto (memoria)
|
|
|
|
Si una sesión se corta:
|
|
|
|
1. leer `work/current.md`
|
|
2. revisar `backlog/features.json`
|
|
3. abrir artefactos de la feature activa
|
|
4. ejecutar `./scripts/verify.sh`
|
|
5. continuar desde “Próximo paso”
|
|
|
|
---
|
|
|
|
## 10) Checklist rápido de arranque
|
|
|
|
- [ ] Repo creado
|
|
- [ ] Framework copiado
|
|
- [ ] Specs escritas
|
|
- [ ] Backlog definido
|
|
- [ ] Matriz de agentes configurada
|
|
- [ ] Workflow de stages configurado
|
|
- [ ] Verificación inicial OK
|
|
- [ ] Primera feature en `pending`
|
|
|
|
---
|
|
|
|
## Comando mental (resumen)
|
|
|
|
**Crear repo → copiar framework → definir spec/backlog → verificar → ejecutar pipeline de 6 agentes con gates obligatorios.**
|