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

platforms/pi/README.md

@@ -0,0 +1,36 @@
+# 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>`