rikrdo/orquestra
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
orquestra/AGENTS.md
rikrdo 70ff54cfa3 refactor: reinforce harness to prevent contract violations 
- verify.sh: validate prohibited dirs, gate nomenclature, feature schema, runtime consistency
- orquestra-status: block direct writes to backlog/features.json
- install.sh: add build artifacts to .gitignore template
- AGENTS.md: document prohibited dirs, gate nomenclature, feature schema
- Reset runtime-status to idle state
2026-08-17 18:59:39 +02:00

1.9 KiB
Raw Permalink Blame History

AGENTS.md — Entrada de Orquestra

Arranque obligatorio

  1. Ejecutar ./scripts/verify.sh.
  2. Leer work/current.md.
  3. Leer backlog/features.json y seleccionar una feature pending.
  4. Seguir harness/workflow.stages.yml y harness/agents.matrix.yml.
  5. Actualizar estado visible con python3 scripts/agent_status.py set ... antes de cada stage.

Reglas duras

  • Orquestra se ejecuta secuencialmente en Pi: no subagentes.
  • Para Pi limpio, arrancar con ./scripts/pi_orquestra.sh, no con pi directo.
  • Una sola feature en in_progress.
  • Ningún rol pasa código por chat: todo va a work/artifacts/<feature_id>/.
  • implementer nunca marca done.
  • done requiere gates aprobados: reviewer, security, qa.
  • Si verify.sh falla, no se cierra la feature.
  • Solo se puede escribir en carpetas permitidas: project/, tests/, work/, backlog/, spec/, harness/, scripts/, platforms/, docs/. Cualquier otra escritura será bloqueada por la extensión orquestra-status.
  • Al cerrar una feature, el leader ejecuta scripts/close_feature.py <feature_id> que valida gates, actualiza el backlog y hace commit/push automáticamente.
  • NUNCA editar backlog/features.json directamente. Usar siempre scripts/close_feature.py para cerrar features. La extensión orquestra-status bloquea escrituras directas a este archivo.
  • Directorios prohibidos: specs/ (plural), apps/, frontend/, src/, lib/. El código del producto va en project/.
  • Nomenclatura de gates: usar reviewer, no review. El verify.sh valida que no se usen nombres deprecated.
  • Schema de features: todas las features deben tener al menos id y status. Las gates deben usar nombres válidos: reviewer, security, qa, close, leader.

Reentrada

  • Releer work/current.md, work/runtime-status.json y artefactos de la feature activa.
  • Ejecutar ./scripts/verify.sh.
  • Continuar desde el próximo stage pendiente.