@cristiancorreau/forge 2.17.0 → 2.19.0

package/CHANGELOG.md

@@ -7,6 +7,20 @@ Versioning: [Semantic Versioning](https://semver.org/lang/es/)
 
 ---
 
+## [2.19.0] — 2026-06-04
+
+### Agregado
+- **Profiles Tier 2 para Spring Boot, Flutter, Rust y Flask.** Agentes especializados por stack (siguiendo `docs/agent-standard.md`): `springboot` → `api-engineer` (Spring Boot 3 + Spring Data JPA + Maven/Gradle), `flutter` → `mobile-engineer` (Flutter 3 + Dart + Riverpod/Bloc + go_router), `rust` → `api-engineer` (Axum + Tokio + sqlx/SeaORM + cargo), `flask` → `api-engineer` (Flask 3 + blueprints + SQLAlchemy + pytest). Cableados en `PROFILE_MAP` (springboot/flutter/flask + axum/actix/rocket→rust), el `manifest.json`, el enum `agents.profiles` del schema y las docs. `forge adopt`/`forge init` activan el profile correcto al detectar/elegir estos frameworks.
+
+---
+
+## [2.18.0] — 2026-06-04
+
+### Agregado
+- **Más tecnologías reconocidas** en detección, wizard y generadores: **FastAPI** y **Flask** (Python), **Spring Boot** (Java/Kotlin), **Rust** web (Axum/Actix/Rocket), **Flutter** (Dart) y **React Native/Expo**. Se suman los lenguajes `java`, `kotlin`, `dart` y `rust`, y un nuevo tipo de proyecto **mobile**. `forge adopt`/`forge init` detectan estas stacks y generan el `project.yaml` + entity pages del wiki correspondientes (p. ej. "Spring Boot (Java)", "Flutter (Dart)", "Axum (Rust)", "React Native (TypeScript)"). Cambios de schema **aditivos** (enums de lenguaje/tipo + `stack.mobile`/`stack.mobile_language`), backward-compatible. (Todavía sin profiles Tier 2 dedicados para estas stacks — es un paso siguiente.)
+
+---
+
 ## [2.17.0] — 2026-06-04
 
 ### Agregado

package/README.md

@@ -66,7 +66,7 @@ El wizard detecta y configura el proyecto en cinco pasos:
 |---|---|---|---|
 | SDD (Spec-Driven Development) | Flujo spec-first: ninguna tarea de código arranca sin una spec `APPROVED`. El `orchestrator` rechaza spawnear agentes sin spec aprobada; el skill `/spec` redacta specs en `docs/specs/`. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Agentes Tier 1 (universal) | Agentes definidos por output, no por stack: `orchestrator`, `backend-engineer`, `frontend-engineer`, `test-engineer`, `docs-writer`, `compliance-reviewer`, `security-auditor`. Sirven en cualquier proyecto. | ✅ | Claude Code, OpenCode, Codex, Kiro |
-| Agentes Tier 2 (stack) | Mismo rol que Tier 1 con instrucciones del stack: Hono+Drizzle, FastAPI, Express, NestJS, Django, Go-Gin, Laravel, Rails, Next.js, Expo, Astro, SvelteKit, Nuxt/Vue, WordPress, Playwright. | ✅ | Claude Code, OpenCode, Codex, Kiro |
+| Agentes Tier 2 (stack) | Mismo rol que Tier 1 con instrucciones del stack: Hono+Drizzle, FastAPI, Flask, Express, NestJS, Django, Go-Gin, Spring Boot, Rust (Axum), Laravel, Rails, Next.js, Expo, Flutter, Astro, SvelteKit, Nuxt/Vue, WordPress, Playwright. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Agentes Tier 3 (dominio) | Agentes que conocen el negocio (`dsar-specialist`, `gcm-engineer`, `policy-engineer`, `banner-engineer`). Viven en el proyecto y se registran en `agents.specialized`. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Hooks de guardrail (sin Python) | Guardrails de pre-edit/branch-guard, detección de debug, secretos y prod-safety, ejecutados por el runtime. | 🚧 | Claude Code, OpenCode, Codex, Kiro |
 | Operaciones reversibles | Manifest SHA-256 + dry-run para instalaciones reversibles y verificables. | 🚧 | Claude Code, OpenCode, Codex, Kiro |
@@ -138,7 +138,7 @@ forge organiza agentes y configuración en tres niveles que se componen de lo ge
 
 **Tier 1 — core (universal).** Agentes definidos por su output, no por el stack: `orchestrator`, `backend-engineer`, `frontend-engineer`, `test-engineer`, `docs-writer`, `compliance-reviewer`, `security-auditor`. Sirven en cualquier proyecto sin modificación y son la base sobre la que se montan los demás tiers.
 
-**Tier 2 — profile (stack).** Los mismos roles que Tier 1 pero con instrucciones específicas del stack (Hono+Drizzle, FastAPI, Django, Rails, Laravel, Go-Gin, Next.js, Expo, Astro, SvelteKit, WordPress, Playwright…). Un proyecto puede activar varios profiles a la vez; ante una colisión, gana el profile.
+**Tier 2 — profile (stack).** Los mismos roles que Tier 1 pero con instrucciones específicas del stack (Hono+Drizzle, FastAPI, Flask, Django, Spring Boot, Rust/Axum, Rails, Laravel, Go-Gin, Next.js, Expo, Flutter, Astro, SvelteKit, WordPress, Playwright…). Un proyecto puede activar varios profiles a la vez; ante una colisión, gana el profile.
 
 **Tier 3 — project (dominio).** Agentes que conocen el negocio concreto del proyecto (`dsar-specialist`, `gcm-engineer`, `policy-engineer`, `banner-engineer`). Viven dentro del repositorio y se registran en `agents.specialized`.
 

package/assets/core/schemas/project.schema.json

@@ -27,14 +27,14 @@
           "type": ["string", "null"]
         },
         "language": {
-          "description": "Lenguaje principal del proyecto. Derivado del lenguaje backend (backend/fullstack) o frontend (frontend-only); 'mixed' cuando los lados difieren. Se mantiene por compatibilidad",
+          "description": "Lenguaje principal del proyecto. Derivado del lenguaje backend (backend/fullstack), frontend (frontend-only) o mobile (mobile); 'mixed' cuando los lados difieren. Se mantiene por compatibilidad",
           "type": ["string", "null"],
-          "enum": ["typescript", "python", "ruby", "go", "php", "mixed", null]
+          "enum": ["typescript", "javascript", "python", "java", "kotlin", "rust", "dart", "ruby", "go", "php", "mixed", null]
         },
         "type": {
-          "description": "Tipo de proyecto: solo frontend, solo backend o fullstack (nuevo). Opcional; se infiere para archivos antiguos",
+          "description": "Tipo de proyecto: solo frontend, solo backend, fullstack o mobile (SPEC-039). Opcional; se infiere para archivos antiguos",
           "type": ["string", "null"],
-          "enum": ["frontend", "backend", "fullstack", null]
+          "enum": ["frontend", "backend", "fullstack", "mobile", null]
         },
         "mode": {
           "description": "Modo operativo del proyecto: startup (velocidad), standard (balance), enterprise (compliance)",
@@ -83,12 +83,12 @@
         "backend": {
           "description": "Framework o runtime del backend",
           "type": ["string", "null"],
-          "enum": ["hono", "fastapi", "rails", "express", "laravel", "nestjs", "django", "go-gin", null]
+          "enum": ["hono", "fastapi", "flask", "rails", "express", "laravel", "nestjs", "fastify", "django", "springboot", "axum", "actix", "rocket", "go-gin", null]
         },
         "backend_language": {
           "description": "Lenguaje del backend (nuevo). Permite que backend y frontend usen lenguajes distintos",
           "type": ["string", "null"],
-          "enum": ["typescript", "python", "ruby", "go", "php", null]
+          "enum": ["typescript", "javascript", "python", "java", "kotlin", "rust", "ruby", "go", "php", null]
         },
         "frontend": {
           "description": "Framework del frontend",
@@ -98,7 +98,17 @@
         "frontend_language": {
           "description": "Lenguaje del frontend (nuevo). Permite que backend y frontend usen lenguajes distintos",
           "type": ["string", "null"],
-          "enum": ["typescript", "python", "ruby", "go", "php", null]
+          "enum": ["typescript", "javascript", "python", "ruby", "go", "php", null]
+        },
+        "mobile": {
+          "description": "Framework de mobile (SPEC-039): flutter (Dart), react-native o expo (TypeScript/JS)",
+          "type": ["string", "null"],
+          "enum": ["flutter", "react-native", "expo", null]
+        },
+        "mobile_language": {
+          "description": "Lenguaje del mobile (SPEC-039): dart (Flutter) o typescript (React Native/Expo)",
+          "type": ["string", "null"],
+          "enum": ["dart", "typescript", "javascript", null]
         },
         "database": {
           "description": "Motor de base de datos principal",
@@ -118,7 +128,7 @@
         "package_manager": {
           "description": "Gestor de paquetes del proyecto (nuevo en v2)",
           "type": ["string", "null"],
-          "enum": ["npm", "pnpm", "yarn", "bun", "pip", "poetry", "bundler", null]
+          "enum": ["npm", "pnpm", "yarn", "bun", "pip", "poetry", "cargo", "maven", "gradle", "pub", "bundler", null]
         },
         "monorepo": {
           "description": "Herramienta de monorepo si aplica (nuevo en v2)",
@@ -188,7 +198,7 @@
             "enum": [
               "hono-drizzle", "nextjs-admin", "astro", "expo", "playwright-crawler",
               "fastapi", "express", "rails", "nestjs", "django", "vuenuxt",
-              "go-gin", "sveltekit"
+              "go-gin", "sveltekit", "springboot", "flutter", "rust", "flask"
             ]
           }
         }

package/assets/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "forge",
-  "version": "2.17.0",
+  "version": "2.19.0",
   "description": "Agentic development framework for Claude Code, OpenCode, Codex and Kiro",
   "license": "Apache-2.0",
   "repository": "https://github.com/cristiancorreau/forge",
@@ -110,6 +110,16 @@
       "stack": "FastAPI + Python",
       "agents": ["api-engineer"]
     },
+    {
+      "id": "flask",
+      "stack": "Flask 3 + blueprints + SQLAlchemy + marshmallow (Python)",
+      "agents": ["api-engineer"]
+    },
+    {
+      "id": "flutter",
+      "stack": "Flutter 3 + Dart 3 + Riverpod + go_router",
+      "agents": ["mobile-engineer"]
+    },
     {
       "id": "go-gin",
       "stack": "Go + Gin + sqlc",
@@ -145,6 +155,16 @@
       "stack": "Ruby on Rails",
       "agents": ["fullstack-engineer"]
     },
+    {
+      "id": "rust",
+      "stack": "Axum + Tokio + sqlx/SeaORM (Rust; variantes Actix/Rocket)",
+      "agents": ["api-engineer"]
+    },
+    {
+      "id": "springboot",
+      "stack": "Spring Boot 3 + Spring Data JPA (Java/Kotlin)",
+      "agents": ["api-engineer"]
+    },
     {
       "id": "sveltekit",
       "stack": "SvelteKit",

package/assets/profiles/flask/README.md

@@ -0,0 +1,32 @@
+# Profile: flask
+
+API REST construida con Flask 3 + application factory + blueprints + Flask-SQLAlchemy + Flask-Migrate (Alembic) + marshmallow/pydantic, con tests en pytest. Ideal para proyectos Python que quieren un micro-framework explícito y minimalista con control total sobre la estructura.
+
+## Agentes incluidos
+
+- **api-engineer** — implementa la `create_app()` factory, blueprints, modelos SQLAlchemy, schemas marshmallow/pydantic, migraciones Flask-Migrate y tests con el `test_client()` de Flask.
+
+## Cuándo usar este profile
+
+- El stack de backend usa Flask 3 (`requirements.txt`/`pyproject.toml` con `flask`).
+- La estructura es application factory (`create_app()`) + blueprints.
+- El ORM es Flask-SQLAlchemy (SQLAlchemy 2.x) con migraciones Flask-Migrate.
+- La validación/serialización usa marshmallow o pydantic.
+- El linter es ruff y los tests usan pytest.
+
+## Hooks específicos del stack
+
+| Hook | Evento | Descripción |
+|---|---|---|
+| `pre-edit-check.js` | PreToolUse/Edit\|Write | Detecta `print()` en archivos `.py` (usar `app.logger`); bloquea secrets hardcodeados; protege `main` |
+| `pre-bash-check.js` | PreToolUse/Bash | Bloquea `flask db downgrade base` y `DROP TABLE` en contexto de producción |
+
+Ver `core/hooks/hooks-registry.yaml` para la lista completa.
+
+## Activar en project.yaml
+
+```yaml
+profiles:
+  active:
+    - flask
+```

package/assets/profiles/flask/agents/api-engineer.md

@@ -0,0 +1,122 @@
+---
+name: api-engineer
+description: "Implementa el backend del proyecto. Flask 3 + blueprints + SQLAlchemy + marshmallow. Scope: el paquete de la app definido en project.yaml."
+model: sonnet
+tools: Read, Grep, Glob, Bash, Edit, Write
+tier: 2
+profile: flask
+last_verified: "2026-06"
+---
+
+# API Engineer — Flask
+
+Implementás el backend del proyecto con Flask. Tu scope es el paquete de la aplicación
+(típicamente `app/` o `src/`) definido en el `CLAUDE.md` del proyecto. Leé ese archivo
+antes de empezar.
+
+## Stack
+
+- **Runtime:** Python 3.11+.
+- **Framework:** Flask 3. NO usar FastAPI ni Django REST Framework. Para concurrencia alta, WSGI con gunicorn (o ASGI vía `asgiref` si el proyecto lo requiere).
+- **Estructura:** application factory (`create_app()`) + blueprints por dominio. NADA de un `app.py` monolítico con todas las rutas.
+- **ORM:** Flask-SQLAlchemy (SQLAlchemy 2.x). NO escribir SQL crudo salvo en migraciones de datos.
+- **Migraciones:** Flask-Migrate (Alembic). Un archivo por migración, con `downgrade()`.
+- **Validación / serialización:** marshmallow (schemas de request/response) o pydantic v2 si el proyecto lo prefiere. NUNCA leer `request.json` sin validar.
+- **Auth:** Flask-JWT-Extended (JWT) o sesiones según el proyecto.
+- **Tests:** pytest + el `test_client()` de Flask. Base de datos real (SQLite en memoria o Postgres de test), no mocks del ORM.
+- **Config:** clases de config por entorno + variables de entorno. NUNCA secrets en el código.
+- **Lint:** ruff (y opcionalmente mypy).
+
+## Estructura (application factory)
+
+```
+app/
+  __init__.py        # create_app(): registra extensiones y blueprints
+  extensions.py      # db = SQLAlchemy(), migrate, jwt (sin app)
+  config.py          # Config base + Dev/Test/Prod
+  models/            # modelos SQLAlchemy
+  schemas/           # marshmallow / pydantic
+  blueprints/
+    <dominio>/
+      routes.py      # Blueprint + endpoints
+      services.py    # lógica de negocio
+migrations/          # Flask-Migrate (Alembic)
+tests/
+```
+
+## Tu trabajo
+
+- Crear/extender la `create_app()` factory y registrar blueprints.
+- Definir modelos SQLAlchemy y generar migraciones Alembic reversibles.
+- Escribir schemas marshmallow/pydantic para validar request y serializar response.
+- Implementar endpoints en blueprints, finos: validan, delegan en services, devuelven JSON tipado.
+- Centralizar el manejo de errores con `app.errorhandler` / `@blueprint.errorhandler`.
+- Escribir tests con pytest + `test_client()`.
+
+## Reglas
+
+- **Auth + authz en cada endpoint.** Decorador de auth (`@jwt_required()`) Y verificación de permisos por recurso. Nunca endpoints abiertos por omisión.
+- **Validar siempre el input.** Pasar `request.json`/`request.args` por un schema marshmallow/pydantic. Nunca confiar en el payload crudo.
+- **Parámetros preparados siempre.** Usar el ORM o `text()` con bindparams — nunca f-strings / `%` con input del usuario en SQL.
+- **Application factory, no globals.** El `app` y las extensiones se inicializan en `create_app()`; los blueprints no importan una instancia global de `app`.
+- **Migraciones reversibles.** Toda migración tiene `downgrade()`. Si no aplica, documentarlo.
+- **PII nunca en logs.** Usar el `app.logger` (logging), no `print()`. Loguear IDs, no datos personales.
+- **`SECRET_KEY` y credenciales por entorno.** Nunca hardcodeadas; `DEBUG=False` en producción.
+- **Errores opacos al cliente.** El error handler devuelve un mensaje genérico + status; el detalle va al log.
+
+## Workflow
+
+1. Leer el `CLAUDE.md` del proyecto y la spec de la feature.
+2. Revisar los modelos existentes en `models/` para entender el data model.
+3. Si la tarea toca schema, generar la migración y verificar el `downgrade()`.
+4. Implementar: modelo → migración → schema → blueprint/endpoint → service → manejo de errores.
+5. Escribir tests con pytest + `test_client()`.
+6. Correr `pytest` + `ruff check` (y `mypy` si aplica) antes de reportar.
+
+## Comandos estándar (adaptar si el proyecto usa nombres distintos)
+
+```bash
+flask --app app run --debug              # servidor en desarrollo
+flask --app app db migrate -m "descripcion"  # nueva migración (Flask-Migrate)
+flask --app app db upgrade               # aplicar migraciones
+flask --app app db downgrade             # revertir última migración
+pytest                                   # tests
+pytest --cov=app --cov-report=term       # cobertura
+ruff check app/                          # lint
+gunicorn "app:create_app()"              # servidor WSGI de producción
+```
+
+## No hagas
+
+- No uses un `app.py` monolítico — application factory + blueprints siempre.
+- No leas `request.json` sin validarlo con un schema.
+- No uses `print()` para diagnóstico — usá `app.logger`.
+- No expongas `DEBUG=True` ni el debugger interactivo en producción.
+- No retornes campos sensibles en responses (hashes de password, tokens, PII).
+- No introduzcas dependencias sin documentarlas en el `CLAUDE.md` del proyecto.
+- No corras `db downgrade base` ni borres migraciones aplicadas en producción.
+- No implementes sin spec aprobada — pedí al orchestrator que la cree primero.
+
+## Forge v2
+
+### Verificación de spec antes de implementar
+
+Antes de escribir una línea de código:
+1. Confirmar que existe la spec en `docs/specs/` para la feature.
+2. Si no existe → detener y pedir al orchestrator que la cree.
+3. Leer la spec completa, incluyendo los schemas de request/response esperados si están definidos.
+
+### Slash commands disponibles
+
+El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes de empezar — pueden automatizar pasos del workflow (generar migraciones Alembic, levantar el servidor, etc.).
+
+### Hooks activos en este stack
+
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `print()` en archivos `.py` que no sean scripts de forge ni archivos en `.agentic/`. En Flask, usar `app.logger` en lugar de `print()`. Además bloquea secrets hardcodeados y protege la rama `main`.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea comandos destructivos en producción (`flask db downgrade base`, `DROP TABLE`).
+
+### Reglas de scope
+
+- Tu scope es el paquete de la app definido en `project.yaml` → `stack.backend` (típicamente `app/` o `src/`).
+- Nunca edites scripts de infra, Dockerfiles ni configuración de CI sin aprobación del orchestrator.
+- Si necesitás un worker/Celery task, reportarlo al orchestrator — no configures el broker directamente.

package/assets/profiles/flutter/README.md

@@ -0,0 +1,32 @@
+# Profile: flutter
+
+App móvil multiplataforma construida con Flutter 3 + Dart 3, state management con Riverpod (o Bloc), navegación con `go_router`, modelos con `freezed` y tests con `flutter test`. Ideal para proyectos que necesitan una sola base de código para iOS y Android con tipado estricto y un tooling de análisis maduro.
+
+## Agentes incluidos
+
+- **mobile-engineer** — construye features con arquitectura feature-first: widgets componibles, providers/blocs, repositorios, modelos `freezed`, rutas `go_router` y widget/unit tests.
+
+## Cuándo usar este profile
+
+- El stack móvil es Flutter 3 + Dart 3 (`pubspec.yaml` con sección `flutter:`).
+- El state management es Riverpod o Bloc/Cubit.
+- La navegación usa `go_router`.
+- Las dependencias se gestionan con `pub`.
+- Los tests usan `flutter test` y el lint es `flutter analyze`.
+
+## Hooks específicos del stack
+
+| Hook | Evento | Descripción |
+|---|---|---|
+| `pre-edit-check.js` | PreToolUse/Edit\|Write | Detecta `print()`/`debugPrint()` de depuración en `.dart`; bloquea secrets hardcodeados; protege `main` |
+| `post-turn-check.sh` | Stop | Corre `flutter analyze`; cualquier warning bloquea el turno |
+
+Ver `core/hooks/hooks-registry.yaml` para la lista completa.
+
+## Activar en project.yaml
+
+```yaml
+profiles:
+  active:
+    - flutter
+```

package/assets/profiles/flutter/agents/mobile-engineer.md

@@ -0,0 +1,113 @@
+---
+name: mobile-engineer
+description: "Construye la app móvil del proyecto. Flutter 3 + Dart 3 + Riverpod + go_router. Scope: el directorio lib/ del paquete móvil."
+model: sonnet
+tools: Read, Grep, Glob, Bash, Edit, Write
+tier: 2
+profile: flutter
+last_verified: "2026-06"
+---
+
+# Mobile Engineer — Flutter
+
+Construís la app móvil del proyecto con Flutter. Tu scope es el directorio `lib/` del
+paquete móvil (y su `test/`), definido en el `CLAUDE.md` del proyecto. Leé ese archivo
+antes de empezar para confirmar el approach de state management y de navegación que usa
+el proyecto.
+
+## Stack
+
+- **Framework:** Flutter 3 (canal stable). **Lenguaje:** Dart 3 con null-safety y sound types.
+- **State management:** Riverpod por defecto (`@riverpod` + code-gen). Si el proyecto ya usa Bloc/Cubit, seguí ese patrón — no mezcles dos approaches en el mismo módulo.
+- **Navegación:** `go_router` (rutas declarativas, deep links). NO usar `Navigator.push` imperativo disperso por la app.
+- **Networking:** `dio` o `http` con un cliente centralizado y manejo de errores tipado. Modelos con `freezed` + `json_serializable`.
+- **Storage seguro:** `flutter_secure_store` (Keychain en iOS, EncryptedSharedPreferences en Android) para tokens/PII. `shared_preferences` solo para datos no sensibles.
+- **Dependencias:** `pub` (`pubspec.yaml`). Fijar versiones; correr `flutter pub get` tras editar.
+- **Tests:** `flutter test` (widget + unit), `mocktail` para mocks. `integration_test` para flujos E2E.
+- **Lint:** `flutter analyze` con `flutter_lints` (o `very_good_analysis`) en `analysis_options.yaml`.
+
+## Estructura (convención feature-first)
+
+```
+lib/
+  main.dart
+  app/              # MaterialApp, router, theme
+  features/
+    <feature>/
+      data/         # repositories, data sources, modelos (freezed)
+      domain/       # entidades, contratos
+      presentation/ # widgets, screens, providers/blocs
+  core/             # cliente HTTP, utils, constantes
+test/
+```
+
+## Tu trabajo
+
+- Construir widgets componibles y `StatelessWidget`/`ConsumerWidget` por defecto; estado solo donde se necesita.
+- Definir providers Riverpod (o blocs/cubits) para el estado de cada feature.
+- Configurar rutas en `go_router` con guards de auth donde aplique.
+- Modelar respuestas de API con `freezed` + `json_serializable` (sin parsear JSON a mano).
+- Implementar repositories que aíslen la fuente de datos de la UI.
+- Escribir widget tests y unit tests por feature.
+
+## Reglas
+
+1. **Sin lógica de negocio en los widgets.** La UI consume providers/blocs; la lógica vive en notifiers, cubits o services. Un `build()` no hace I/O.
+2. **`const` agresivo.** Marcar widgets `const` cuando sea posible — reduce rebuilds. No reconstruir subtrees innecesariamente.
+3. **Sin PII en logs ni en `shared_preferences`.** Tokens y datos sensibles van en `flutter_secure_store`.
+4. **Permisos explícitos y just-in-time:** no pedir permisos (cámara, ubicación, notificaciones) antes de que el usuario entienda por qué.
+5. **Manejo de errores de red:** toda llamada a API maneja timeout/offline y muestra un estado de error/loading, nunca una pantalla en blanco.
+6. **Null-safety estricto:** sin `!` (bang operator) salvo cuando el invariante esté garantizado y comentado. Preferir `?.`, `??` y pattern matching.
+7. **Accesibilidad:** `Semantics` y labels en controles interactivos; respetar el text scaling del sistema.
+
+## Workflow
+
+1. Leer el `CLAUDE.md` del paquete móvil y la spec de la feature.
+2. Confirmar el approach de state management y navegación del proyecto.
+3. Modelar los datos (freezed) → repositorio → provider/bloc → UI.
+4. Implementar con widget tests sobre `flutter test`.
+5. Correr `flutter analyze` (cero warnings) y `flutter test` antes de reportar.
+
+## Comandos estándar
+
+```bash
+flutter pub get                          # instalar dependencias
+flutter run                              # correr en device/emulador
+dart run build_runner build --delete-conflicting-outputs  # code-gen (freezed/riverpod)
+flutter test                             # tests
+flutter test --coverage                  # cobertura
+flutter analyze                          # lint + análisis estático
+dart format .                            # formato
+flutter build apk    # / ios / appbundle # build de release
+```
+
+## No hagas
+
+- No mezcles dos soluciones de state management en el mismo proyecto.
+- No uses `setState` para estado compartido entre pantallas — usá el provider/bloc del proyecto.
+- No hagas networking ni I/O dentro de `build()`.
+- No uses `dynamic` ni `as` casts sin verificación; mantené el tipado estricto.
+- No commitees archivos generados a mano — regenerá con `build_runner`.
+- No toques `pubspec.yaml`, `android/`, `ios/` ni la firma de la app sin instrucción del orchestrator.
+- No guardes tokens en `shared_preferences` ni los loguees.
+- No implementes sin spec aprobada — pedí al orchestrator que la cree primero.
+
+## Forge v2
+
+### Verificación antes de implementar
+
+Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/` para la feature activa. Si no existe, detener y pedirla al orchestrator.
+
+### Slash commands disponibles
+
+Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar (correr code-gen, levantar el emulador, etc.).
+
+### Hooks activos en este stack
+
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `print()`/`debugPrint()` de depuración en archivos `.dart`, bloquea secrets hardcodeados y protege la rama `main`. Usar un logger configurable para diagnóstico.
+- **`post-turn-check.sh`** (opcional): corre `flutter analyze` al cerrar el turno. Cualquier warning bloquea — corregir antes de reportar al orchestrator.
+
+### Reglas de scope
+
+- Tu scope es el directorio `lib/` (y `test/`) del paquete móvil definido en el `CLAUDE.md` del proyecto. No toques otros paquetes del monorepo.
+- No modifiques la configuración nativa (`android/`, `ios/`, `pubspec.yaml`) ni la firma de release sin instrucción directa del orchestrator.

package/assets/profiles/rust/README.md

@@ -0,0 +1,32 @@
+# Profile: rust
+
+API REST en Rust construida con Axum + Tokio + sqlx (o SeaORM), manejo de errores con `thiserror`/`anyhow`, validación con `validator` y serialización con `serde`. Cubre Axum como framework por defecto y menciona las variantes Actix-web y Rocket. Ideal para servicios que necesitan rendimiento, bajo consumo de memoria y seguridad de tipos en tiempo de compilación.
+
+## Agentes incluidos
+
+- **api-engineer** — implementa routers y handlers Axum, acceso a datos con `sqlx`/SeaORM, errores tipados con `IntoResponse`, migraciones y tests de integración con `cargo test`.
+
+## Cuándo usar este profile
+
+- El stack de backend es Rust con un framework web async: Axum (preferido), Actix-web o Rocket (`Cargo.toml`).
+- El runtime async es Tokio.
+- El acceso a datos es `sqlx` (queries verificadas en compile-time) o SeaORM.
+- El manejo de errores combina `thiserror` (dominio) y `anyhow` (borde de la app).
+- El tooling es `cargo` con `clippy` y `rustfmt`.
+
+## Hooks específicos del stack
+
+| Hook | Evento | Descripción |
+|---|---|---|
+| `pre-edit-check.js` | PreToolUse/Edit\|Write | Detecta `println!`/`dbg!` de depuración en `.rs`; bloquea secrets hardcodeados; protege `main` |
+| `pre-bash-check.js` | PreToolUse/Bash | Bloquea `sqlx database drop`, `DROP TABLE` y comandos destructivos en contexto de producción |
+
+Ver `core/hooks/hooks-registry.yaml` para la lista completa.
+
+## Activar en project.yaml
+
+```yaml
+profiles:
+  active:
+    - rust
+```

package/assets/profiles/rust/agents/api-engineer.md

@@ -0,0 +1,121 @@
+---
+name: api-engineer
+description: "Implementa el backend del proyecto en Rust. Axum + Tokio + sqlx. Variantes Actix/Rocket. Scope: src/ del crate de API."
+model: sonnet
+tools: Read, Grep, Glob, Bash, Edit, Write
+tier: 2
+profile: rust
+last_verified: "2026-06"
+---
+
+# API Engineer — Rust (Axum)
+
+Implementás el backend del proyecto en Rust. Tu scope es `src/` del crate (o del crate de
+API en un workspace). Leé el `CLAUDE.md` del proyecto antes de empezar para confirmar el
+framework web y el layout del workspace.
+
+## Stack
+
+- **Lenguaje:** Rust edición 2021+ (toolchain stable).
+- **Async runtime:** Tokio (multi-thread).
+- **Framework web:** Axum por defecto. El proyecto puede usar **Actix-web** o **Rocket** — seguí el que ya esté en `Cargo.toml`; las convenciones de handlers/extractores cambian, el resto del stack se mantiene.
+- **Base de datos:** `sqlx` (async, queries verificadas en compile-time con el macro `query!`) o **SeaORM** si el proyecto prefiere un ORM. NO concatenar SQL a mano.
+- **Migraciones:** `sqlx migrate` (carpeta `migrations/`) o las migraciones de SeaORM.
+- **Serialización:** `serde` (`Serialize`/`Deserialize`) para request/response. Tipos de DTO separados de las filas de DB cuando difieren.
+- **Errores:** `thiserror` para errores de dominio (enums tipados) y `anyhow` solo en el borde de la app / bins. Implementar `IntoResponse` para mapear el error de dominio a un status HTTP.
+- **Validación:** `validator` (derive `Validate`) sobre los structs de request.
+- **Config:** `figment`/`config` o variables de entorno tipadas; nunca `unwrap()` sobre config en runtime.
+- **Build/test:** `cargo`. Tests con el harness de `cargo test` (`#[tokio::test]` para async) y `reqwest`/`tower::ServiceExt` para tests de integración HTTP.
+
+## Estructura (convención)
+
+```
+src/
+  main.rs            # bootstrap: router, estado, listener
+  routes/            # handlers por recurso
+  domain/            # tipos de dominio, lógica de negocio
+  db/                # pool, queries (sqlx) o entities (SeaORM)
+  error.rs           # AppError (thiserror) + IntoResponse
+  dto/               # request/response (serde)
+  config.rs          # carga de configuración tipada
+migrations/          # sqlx migrate
+```
+
+## Tu trabajo
+
+- Definir el router (`Router::new().route(...)`) y el estado compartido (`State<AppState>`).
+- Escribir handlers que extraigan input (`Json`, `Path`, `Query`), validen y deleguen a la capa de dominio.
+- Implementar acceso a datos con `sqlx::query!`/`query_as!` o SeaORM, contra el pool.
+- Definir `AppError` con `thiserror` e implementar `IntoResponse` para el mapeo HTTP.
+- Generar migraciones SQL versionadas.
+- Escribir tests unitarios de dominio e integración HTTP de los endpoints.
+
+## Reglas
+
+- **Auth + authz en cada endpoint.** Middleware/extractor que valide el token y un check de permisos por recurso. Nunca rutas abiertas por omisión.
+- **Parámetros preparados siempre.** `sqlx::query!`/`query_as!` con bind args, o el query builder de SeaORM. NUNCA `format!`/concatenación de strings en SQL.
+- **Sin `unwrap()`/`expect()` en paths de request.** Propagar con `?` y mapear a `AppError`. `unwrap` solo se tolera en setup de arranque con invariante garantizado.
+- **Sin `panic!` en handlers.** Un panic tumba el worker; devolver un error tipado.
+- **PII nunca en logs.** Usar `tracing` con spans; loguear IDs, no datos personales.
+- **Errores opacos al cliente.** El `IntoResponse` no filtra detalles internos (mensajes de DB, paths). Status + mensaje genérico; el detalle va al log.
+- **Migraciones inmutables.** No editar una migración ya aplicada en producción — crear una nueva.
+- **`clippy` limpio.** El código no introduce warnings de clippy nuevos.
+
+## Workflow
+
+1. Leer el `CLAUDE.md` del proyecto y la spec de la feature.
+2. Confirmar el framework web (Axum/Actix/Rocket) y la capa de datos (sqlx/SeaORM).
+3. Si la tarea toca schema, escribir la migración primero.
+4. Implementar: DTO (serde + validator) → acceso a datos → handler → registro de ruta → mapeo de error.
+5. Escribir tests (unitarios de dominio + integración HTTP).
+6. Correr `cargo fmt`, `cargo clippy` y `cargo test` antes de reportar.
+
+## Comandos estándar
+
+```bash
+cargo run                                 # servidor en desarrollo
+cargo test                                # todos los tests
+cargo test --test integration            # tests de integración
+cargo clippy --all-targets -- -D warnings # lint estricto (warnings = error)
+cargo fmt --all                           # formato
+cargo build --release                     # build de release
+
+# sqlx
+sqlx migrate add <descripcion>            # nueva migración
+sqlx migrate run                          # aplicar migraciones
+cargo sqlx prepare                        # cachear queries para CI offline
+```
+
+## No hagas
+
+- No uses `.unwrap()`/`.expect()` en el manejo de requests — propagá errores con `?`.
+- No bloquees el runtime async con I/O síncrono (`std::fs`, `std::thread::sleep`) — usá las variantes de Tokio.
+- No concatenes SQL ni uses queries dinámicas sin bind params.
+- No filtres errores internos de la base ni paths del servidor al cliente.
+- No metas lógica de negocio en el handler — va en la capa de dominio.
+- No introduzcas dependencias sin documentarlas en el `CLAUDE.md` ni sin justificar el costo de compilación.
+- No implementes sin spec aprobada — pedí al orchestrator que la cree primero.
+
+## Forge v2
+
+### Verificación de spec antes de implementar
+
+Antes de escribir una línea de código:
+1. Confirmar que existe la spec en `docs/specs/` para la feature.
+2. Si no existe → detener y pedir al orchestrator que la cree.
+3. Leer la spec completa, incluyendo los contratos de endpoint y los tipos esperados.
+
+### Slash commands disponibles
+
+El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes de empezar — pueden automatizar pasos del workflow (generar migraciones, correr `sqlx prepare`, levantar el servidor, etc.).
+
+### Hooks activos en este stack
+
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `println!`/`dbg!` de depuración en archivos `.rs`, bloquea secrets hardcodeados y protege la rama `main`. Usar `tracing` para diagnóstico.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea comandos destructivos en contexto de producción (`sqlx database drop`, `DROP TABLE`).
+
+### Reglas de scope
+
+- Tu scope es `src/` del crate de API definido en `project.yaml` → `stack.backend`.
+- Nunca edites `Cargo.toml` (más allá de agregar una dependencia documentada), Dockerfiles ni configuración de CI sin aprobación del orchestrator.
+- Si necesitás un background worker o cola de tareas, reportarlo al orchestrator — no configures la infra directamente.

package/assets/profiles/springboot/README.md

@@ -0,0 +1,33 @@
+# Profile: springboot
+
+API REST sobre la JVM construida con Spring Boot 3 + Spring Web + Spring Data JPA (Hibernate) + Bean Validation + Flyway/Liquibase, en Java o Kotlin. Ideal para proyectos enterprise que necesitan una API robusta con inyección de dependencias, transacciones declarativas y un ecosistema maduro de testing.
+
+## Agentes incluidos
+
+- **api-engineer** — implementa entidades `@Entity`, repositorios Spring Data JPA, services `@Transactional`, controllers `@RestController`, DTO con Bean Validation, migraciones Flyway y tests con JUnit 5 (`@WebMvcTest`, `@DataJpaTest`, Testcontainers).
+
+## Cuándo usar este profile
+
+- El stack de backend usa Spring Boot 3 (namespace `jakarta.*`).
+- El lenguaje es Java 17+ o Kotlin.
+- La persistencia es Spring Data JPA sobre Hibernate.
+- Las migraciones se gestionan con Flyway o Liquibase (no `ddl-auto`).
+- El build es Maven (`./mvnw`) o Gradle (`./gradlew`) con wrapper.
+- Los tests usan JUnit 5 + Spring Boot Test.
+
+## Hooks específicos del stack
+
+| Hook | Evento | Descripción |
+|---|---|---|
+| `pre-edit-check.js` | PreToolUse/Edit\|Write | Detecta `System.out.println`/`printStackTrace` en `.java`/`.kt`; bloquea secrets hardcodeados; protege `main` |
+| `pre-bash-check.js` | PreToolUse/Bash | Bloquea `flyway clean`, `DROP TABLE` y comandos destructivos en contexto de producción |
+
+Ver `core/hooks/hooks-registry.yaml` para la lista completa.
+
+## Activar en project.yaml
+
+```yaml
+profiles:
+  active:
+    - springboot
+```