rikrdo/mercadodevida
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
425fedd13eb351d5f1f8d81894ee00140d50e0e4
mercadodevida/platforms/pi
History
rikrdo 1d4eebca54 feat(F-001): scaffold modular monolith skeleton with boundary checker 
- TypeScript + Fastify skeleton under project/ (src/modules, shared, infrastructure, app)
- scripts/check-module-boundaries.mjs enforcing module public-API rules (tested with fixtures)
- GET /health endpoint, error envelope without stack leakage
- specs/F-001-scaffold (SPEC/DESIGN/TASKS/TESTS), spec/tech.md dependency justification
- 30-ticket MercadoDeVida roadmap in backlog/features.json, spec/roadmap.md
- All gates approved: reviewer, security, qa; verify.sh green
2026-08-14 21:46:54 +02:00
..
extensions
feat(F-001): scaffold modular monolith skeleton with boundary checker
2026-08-14 21:46:54 +02:00
leader.prompt.md
feat(F-001): scaffold modular monolith skeleton with boundary checker
2026-08-14 21:46:54 +02:00
README.md
feat(F-001): scaffold modular monolith skeleton with boundary checker
2026-08-14 21:46:54 +02:00

README.md

Adaptador Pi

Orquestra se ejecuta desde Pi como un solo parent session secuencial. No instala subagentes.

Requisitos obligatorios

  • pi debe existir en PATH antes de instalar Orquestra.
  • El proyecto instalado debe abrirse desde su raíz.
  • Arrancar con ./scripts/pi_orquestra.sh, que ejecuta pi --no-extensions y carga solo extensiones Orquestra.
  • Extensiones project-local declaradas: .pi/extensions/orquestra-status/ y .pi/extensions/orquestra-web-fetch.ts.
  • El código de producto vive en project/; archivos de código en la raíz son inválidos.

Instalación esperada

Cuando Orquestra se instala en un repo de proyecto, el instalador debe copiar:

  • platforms/pi/extensions/orquestra-status/ -> .pi/extensions/orquestra-status/
  • platforms/pi/extensions/orquestra-web-fetch.ts -> .pi/extensions/orquestra-web-fetch.ts

No debe crear .pi/subagents/ ni .pi/subagents.json.

Flujo secuencial

  1. Ejecutar ./scripts/verify.sh.
  2. Abrir Pi limpio desde la raíz con ./scripts/pi_orquestra.sh.
  3. Confirmar el widget con /orquestra-status.
  4. El mismo parent session cambia de rol siguiendo harness/workflow.stages.yml.
  5. Antes de cada stage, actualizar estado con python3 scripts/agent_status.py set ....
  6. agent_status.py rechaza saltos de stage sin artefactos previos obligatorios.
  7. Durante build, escribir producto en project/ y tests en tests/; requiere feature_id, stage=build, agent=implementer y state=running en work/runtime-status.json.
  8. Al terminar cada stage, escribir el artefacto esperado en work/artifacts/<feature_id>/.
  9. Ejecutar document/documenter.md solo si cambiaron docs/API/contratos/comportamiento user-facing; no es gate obligatorio de cierre.
  10. Recién después empieza el siguiente rol/stage.

Modelos por rol

Si querés modelos distintos por etapa, se eligen secuencialmente antes de cada stage según harness/model-routing.yml. No hay ejecución paralela.

Respuesta estándar por etapa

  • done -> <ruta>
  • blocked -> <ruta>