Levantar el proyecto

Requisitos

Node.js 22 (es la versión con la que corre la integración continua) y npm 11. El Monorepo se administra con npm: yarn no funciona aquí.
Git.
Para la app móvil: Expo y Android Studio o Xcode.
Un backend al que apuntar: BoostAPI corriendo en la computadora (ver El backend) o el backend de desarrollo del equipo.

Instalar

git clone <repositorio> Monorepo
cd Monorepo
npm install

npm install en la raíz instala todas las aplicaciones y paquetes (son espacios de trabajo de npm, orquestados con Turborepo).

Variables de entorno

La web lee sus variables de apps/web/.env.local. Hay un archivo de ejemplo comentado en apps/web/.env.example: se copia y se completa con los valores que da el equipo.

cp apps/web/.env.example apps/web/.env.local

Las variables cubren el modo de ejecución (desarrollo, vista previa o producción), el ingreso con Zauru, la dirección del backend, el secreto de la sesión y la llave de mapas. Los valores reales nunca se suben al repositorio ni se pegan en un chat.

Arrancar

Qué	Comando
Todo a la vez (web, documentación, manual y app móvil)	`npm run dev`
Solo la web	`npm run dev --workspace=apps/web`
Solo esta documentación	`npm run docs:dev`
Solo el manual de usuario	`npm run manual:dev`
La app móvil con su túnel	`npm run dev:mobile:auto`

La web queda en http://localhost:3000. Los sitios de Astro imprimen su dirección al arrancar.

Comprobar un cambio antes del PR

En el Monorepo:

Qué	Comando
Tipos	`npm run typecheck`
Lint de la web (desde `apps/web`, no desde la raíz)	`npm run lint --workspace=apps/web`
Pruebas de la web	`npm run test --workspace=apps/web`
Build de todo	`npm run build`
Esta documentación (revisión y build)	`npm run docs:build`
Enlaces de toda la documentación y `AGENTS.md` igual a `CLAUDE.md`	`npm run docs:check`
La CLI de la web	`npm run test:web-cli`

Y para ver el cambio funcionando en la web de verdad, la CLI de la web abre cualquier pantalla con una sesión real, toma la captura y reporta errores de consola, de red y de sockets.

El backend (BoostAPI)

Es otro repositorio y se administra con Yarn 1 (no con npm). Requisitos: Node.js 22 (el mismo de su integración continua) y un MySQL 8 propio, por ejemplo en Docker.

yarn install
cp .env.template .env      # se llena con la base de la computadora, nunca con valores de producción
yarn start:dev             # el backend con recarga

Los nombres de las variables están en .env.template, .env.example y en la configuración de cada módulo; los valores reales viven en el servidor y nunca se imprimen. Las semillas de datos de prueba y lo que hace falta para iniciar sesión en una base nueva están en su guía de desarrollo local (docs/operacion/README.md de BoostAPI).

Antes del PR del backend:

Qué	Comando
Tipos	`yarn tsc --noEmit -p tsconfig.json`
Pruebas de lo que se tocó (la suite completa si cambió un contrato que otros usan)	`yarn jest <ruta>` / `yarn jest`
Que la aplicación arranque, si se tocó un módulo o un proveedor	`yarn check:boot`
Lint de los archivos tocados	`npx eslint <archivos>`
El catálogo de workflows, si se tocó el motor	`yarn docs:workflows:check`
La documentación técnica, si se tocó	`yarn docs:check`
El catálogo de códigos de error, si se agregó o cambió uno	`yarn docs:errores:check`
La CLI `boost`	`yarn -s test:cli`

La integración continua del backend solo corre tipos, build y pruebas: lo demás lo corre quien hace el cambio.

Trampas conocidas

Las pruebas de la web son una lista explícita. Un archivo de prueba nuevo no corre hasta que se agrega a la lista del script de pruebas de apps/web; los patrones con corchetes (las carpetas [id] o (protected)) no funcionan como comodín.
El proxy vivo es el de apps/web. En la raíz hay archivos de configuración de Next que no se usan.
Los cambios de base de datos se aplican a mano en el backend, antes del despliegue que los necesita. No hay migraciones, y la sincronización automática del esquema nunca se enciende contra una base compartida.
En el backend, yarn lint corrige y reformatea archivos enteros. Se usa npx eslint sobre los archivos tocados.
Pruebas del backend en verde no garantizan que arranque: cada prueba arma sus piezas a mano, por eso existe yarn check:boot.
Un proceso local nunca usa las colas ni los temporizadores de producción. Cada entorno tiene los suyos, y una guarda del backend impide que un proceso de otro entorno los consuma o los programe.