create-harness-btp 0.2.4 → 0.3.0

package/AI/clients/copilot/skills/mta-build/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: mta-build
+description: Construir y verificar artefactos MTAR con mbt en este equipo
+---
+
+# Build MTA (`mbt`)
+
+`mbt` es Cloud MTA Build Tool 1.2.50 (verificado 2026-10-29). Invocarlo
+siempre como `mbt`, nunca como `cf` ni rutas inventadas.
+
+## Flujo
+
+```
+mbt build                # requiere mta.yaml en la raíz del proyecto
+```
+
+- El `.mtar` resultante queda en `mta_archives/` con el nombre/versión de
+  `mta.yaml`. Comprobar existencia y fecha antes de desplegar.
+- Para módulos Node.js, `mbt` ejecuta `npm install`/`npm run build` según
+  `mta.yaml`; para Java necesita Maven (`mvn` no instalado: documentar como
+  pendiente si una spec lo exige).
+- `mbt build --help` para flags (`--mtar`, `--platform=cf`).
+
+## Despliegue del MTAR
+
+`cf deploy <archivo>.mtar` requiere el **plugin multiapps**. Verificar
+siempre con `cf plugins` antes de asumir su ausencia (2026-10-30 resultó
+ya instalado contra lo documentado). Instalarlo solo cuando un MVP necesite
+despliegue MTA:
+
+```
+cf install-plugin -r CF-Community multiapps
+```
+
+Alternativa sin plugin para MVPs simples: `cf push` por app según plan.
+
+## Notas
+
+- El binario `mbt.exe` se obtuvo con el propio `install.js` del paquete npm
+  (`node install.js cloud-mta-build-tool`). Si `mbt` vuelve a fallar tras
+  una actualización global, repetir ese comando en el directorio del paquete.
+- Nunca versionar `mta_archives/*.mtar` ni `default-services.json` con claves.
+- `mbt` exige `make` en `%PATH%` (ver `AGENTS.md` § Disciplina de shell y
+  CLIs): si falla `exec: "make": executable file not found`, anteponer el
+  `bin` de ezwinports/GnuWin32 al `$env:PATH` solo para el comando.

package/AI/clients/copilot/skills/sap-verify/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: sap-verify
+description: Clasificar disponibilidad, cuenta y coste de servicios SAP/BTP
+---
+
+# Verificación de dependencias externas SAP
+
+Toda afirmación sobre un servicio, plan, API o capacidad BTP se clasifica en
+una de estas categorías, con fuente y fecha:
+
+| Categoría | Significado |
+|---|---|
+| **Documentado** | Docs oficiales vigentes + evidencia (comando, consola o enlace con fecha). |
+| **Pendiente en cuenta** | Existe en docs pero sin comprobar en la subcuenta/destino real. |
+| **Coste por cotizar** | Requiere plan de pago o métrica no verificada; no activar sin confirmación. |
+
+## Reglas
+
+- Desarrollo local y mocks primero; servicios reales solo con evidencia.
+- Distinguir Windows local frente a BAS/dev space remoto: una instalación o
+  capacidad de un lado no implica la del otro.
+- No afirmar que una integración está aprobada o disponible hasta comprobarla
+  con documentación y accesos vigentes.
+- Costes: antes de activar cualquier recurso con coste, verificar precio y
+  documentarlo en la spec; capa gratuita por defecto.
+- Bloqueos externos no paran el MVP: documentar evidencia y continuar con
+  mocks o adaptador local.

package/AI/clients/cursor/commands/flow.md

@@ -0,0 +1,12 @@
+
+Ejecuta el flujo sobre la especificación: $ARGUMENTS
+(p. ej. `/flow specs/mi-mvp.md`).
+
+El orquestador recorre las etapas 0–10 de `AGENTS.md` con los especialistas
+adecuados (`analyst`, `researcher`, `architect`, `frontend-ui5`,
+`backend-cap`, `qa-review`, `deploy-cf`, `documentarian`). En MVPs pequeños
+puede saltar etapas irrelevantes y registrarlo; ningún riesgo o
+incertidumbre bloquea por sí solo: se investiga, se decide con evidencia y
+se continúa con lo resoluble. La puerta de despliegue (etapa 7) es
+obligatoria antes de desplegar. Al cerrar: qué se hizo, verificaciones con
+comandos y resultado real, y qué quedó pendiente y por qué.

package/AI/clients/cursor/commands/verify.md

@@ -0,0 +1,14 @@
+
+Ejecuta solo la puerta de despliegue (etapa 7) para $ARGUMENTS
+(spec o nombre de app; si se omite, el MVP en curso).
+
+Verificaciones (delegables en `qa-review` + `deploy-cf` en solo lectura):
+
+1. `cf target` coincide con el destino de la spec (endpoint/org/espacio).
+2. El artefacto existe y es reciente (`.mtar` en `mta_archives/` o bundle
+   para `push`).
+3. Todos los criterios de aceptación están en verde con evidencia.
+4. Diff/Git sin secretos ni archivos que debieran estar ignorados.
+
+Veredicto: apto / no apto con motivos concretos. Este comando nunca
+despliega ni muta nada en Cloud Foundry.

package/AI/clients/cursor/skills/cap-cli/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: cap-cli
+description: Invocación verificada del CLI de CAP y facets en este equipo
+---
+
+# CLI de CAP (`cds`)
+
+Nombres verificados el 2026-10-29 (docs cap.cloud.sap vía `context7`;
+paquete `@cap-js/cds-dk` **no existe** — el correcto es `@sap/cds-dk`):
+
+- CLI solo vía `npx -p @sap/cds-dk cds ...` (el `node_modules` del proyecto
+  no incluye el ejecutable `cds`; `npx cds` a secas falla).
+- Runtime del proyecto: `@sap/cds` v10 + `@cap-js/sqlite` v3 (SQLite solo
+  para dev local; sin persistencia en CF).
+- Scaffold: `npx -p @sap/cds-dk cds init <nombre> --nodejs` (no global).
+- Facets usadas en este harness: `mta xsuaa approuter html5-repo
+  destination ui5` (lista completa real con `cds add --help`, no de memoria).
+- Tras `cds add`, siempre `npm install` antes del siguiente comando.
+- `cds add` es aditivo y genera `mta.yaml`/`xs-security.json`: revisar el
+  diff antes de aceptar lo generado (nombres de instancia deben coincidir
+  con las existentes en la subcuenta).

package/AI/clients/cursor/skills/cf-cli/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: cf-cli
+description: Uso estándar del CLI de Cloud Foundry (cf)
+---
+
+# CLI Cloud Foundry (`cf`)
+
+El CLI de Cloud Foundry se invoca **siempre** como `cf` (instalación
+estándar del CLI; adapta rutas según tu equipo). Si `cf` en tu máquina
+corresponde a otra herramienta, define un alias propio y úsalo de forma
+consistente donde el harness diga `cf`.
+
+## Lectura segura (sin secretos)
+
+```
+cf target          # endpoint / org / espacio actuales
+cf api             # endpoint y versión API
+cf orgs            # solo nombres
+cf spaces          # solo nombres
+cf apps            # estado observable (started/stopped, rutas)
+cf services        # instancias visibles
+cf logs <app> --recent
+```
+
+`target`, `api`, `orgs`, `spaces` y `app <nombre>` nunca muestran tokens.
+Si una salida incluyera un secreto, redáctalo antes de citarla.
+
+## Mutaciones (solo `deploy-cf`, con destino confirmado)
+
+- Confirmar endpoint/org/espacio contra la spec **antes** de cada despliegue.
+- `cf push` para apps simples; `cf deploy <archivo>.mtar` para MTA
+  (requiere plugin `multiapps`, no instalado: ver skill `mta-build`).
+- Verificar después: `cf apps` + `cf logs <app> --recent` + URL.
+
+## Denylist
+
+- Borrar o renombrar orgs, espacios, apps o servicios fuera del MVP.
+- `cf login`/re-autenticaciones no solicitadas (si la sesión caduca,
+  pedir al usuario el flujo interactivo, nunca credenciales en texto).
+- `--var`/`--vars-file` con secretos en shell compartida; usar archivos ya
+  ignorados por Git y no citar sus valores.

package/AI/clients/cursor/skills/mta-build/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: mta-build
+description: Construir y verificar artefactos MTAR con mbt en este equipo
+---
+
+# Build MTA (`mbt`)
+
+`mbt` es Cloud MTA Build Tool 1.2.50 (verificado 2026-10-29). Invocarlo
+siempre como `mbt`, nunca como `cf` ni rutas inventadas.
+
+## Flujo
+
+```
+mbt build                # requiere mta.yaml en la raíz del proyecto
+```
+
+- El `.mtar` resultante queda en `mta_archives/` con el nombre/versión de
+  `mta.yaml`. Comprobar existencia y fecha antes de desplegar.
+- Para módulos Node.js, `mbt` ejecuta `npm install`/`npm run build` según
+  `mta.yaml`; para Java necesita Maven (`mvn` no instalado: documentar como
+  pendiente si una spec lo exige).
+- `mbt build --help` para flags (`--mtar`, `--platform=cf`).
+
+## Despliegue del MTAR
+
+`cf deploy <archivo>.mtar` requiere el **plugin multiapps**. Verificar
+siempre con `cf plugins` antes de asumir su ausencia (2026-10-30 resultó
+ya instalado contra lo documentado). Instalarlo solo cuando un MVP necesite
+despliegue MTA:
+
+```
+cf install-plugin -r CF-Community multiapps
+```
+
+Alternativa sin plugin para MVPs simples: `cf push` por app según plan.
+
+## Notas
+
+- El binario `mbt.exe` se obtuvo con el propio `install.js` del paquete npm
+  (`node install.js cloud-mta-build-tool`). Si `mbt` vuelve a fallar tras
+  una actualización global, repetir ese comando en el directorio del paquete.
+- Nunca versionar `mta_archives/*.mtar` ni `default-services.json` con claves.
+- `mbt` exige `make` en `%PATH%` (ver `AGENTS.md` § Disciplina de shell y
+  CLIs): si falla `exec: "make": executable file not found`, anteponer el
+  `bin` de ezwinports/GnuWin32 al `$env:PATH` solo para el comando.

package/AI/clients/cursor/skills/sap-verify/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: sap-verify
+description: Clasificar disponibilidad, cuenta y coste de servicios SAP/BTP
+---
+
+# Verificación de dependencias externas SAP
+
+Toda afirmación sobre un servicio, plan, API o capacidad BTP se clasifica en
+una de estas categorías, con fuente y fecha:
+
+| Categoría | Significado |
+|---|---|
+| **Documentado** | Docs oficiales vigentes + evidencia (comando, consola o enlace con fecha). |
+| **Pendiente en cuenta** | Existe en docs pero sin comprobar en la subcuenta/destino real. |
+| **Coste por cotizar** | Requiere plan de pago o métrica no verificada; no activar sin confirmación. |
+
+## Reglas
+
+- Desarrollo local y mocks primero; servicios reales solo con evidencia.
+- Distinguir Windows local frente a BAS/dev space remoto: una instalación o
+  capacidad de un lado no implica la del otro.
+- No afirmar que una integración está aprobada o disponible hasta comprobarla
+  con documentación y accesos vigentes.
+- Costes: antes de activar cualquier recurso con coste, verificar precio y
+  documentarlo en la spec; capa gratuita por defecto.
+- Bloqueos externos no paran el MVP: documentar evidencia y continuar con
+  mocks o adaptador local.

package/AI/clients/opencode/agents/analyst.md

@@ -0,0 +1,29 @@
+---
+description: Evalúa specs de MVP y fija criterios de aceptación verificables
+mode: subagent
+permissions:
+  - action: edit
+    resource: "*"
+    effect: deny
+  - action: shell
+    resource: "*"
+    effect: deny
+---
+
+Analista funcional. Solo lectura: no editas archivos ni ejecutas shell.
+
+Entradas: ruta de la spec (`specs/<mvp>.md`), enlaces o anexos que te pase el
+orquestador.
+
+Entregables al orquestador:
+
+1. Veredicto de la spec: completa / completable con supuestos / bloqueada
+   (falta dato indispensable).
+2. Lista de supuestos explícitos y dato mínimo a pedir si hay bloqueo.
+3. Criterios de aceptación verificables (comando, URL o comportamiento
+   observable por criterio).
+4. Estimación de esfuerzo y recomendación de rigor (etapas a saltar o no).
+
+Límites: no diseñas arquitectura, no eliges servicios BTP, no propones
+cambios de código. Si la spec pide `push`/PR/remoto, lo señalas para que el
+orquestador confirme autorización.

package/AI/clients/opencode/agents/architect.md

@@ -0,0 +1,28 @@
+---
+description: Diseña arquitectura BTP, mta.yaml, servicios y planes
+mode: subagent
+permissions:
+  - action: edit
+    resource: "*"
+    effect: deny
+  - action: shell
+    resource: "*"
+    effect: deny
+---
+
+Arquitecto SAP/BTP. Solo lectura: propones, no implementas ni ejecutas.
+
+Entradas: spec evaluada, hallazgos de `researcher`, target CF conocido.
+
+Entregables al orquestador:
+
+1. Topología del MVP (módulos MTA, rutas, dependencias entre módulos).
+2. Esqueleto de `mta.yaml` con recursos y parámetros (sin secretos).
+3. Servicios BTP necesarios con plan recomendado y verificación de
+   disponibilidad/coste pendiente (categorías de `sap-verify`).
+4. Decisiones y alternativas descartadas con motivo.
+
+Límites: sin credenciales ni valores reales en ningún artefacto; los
+parámetros sensibles se referencian por variable/entorno. No afirmas
+disponibilidad de un servicio o plan sin evidencia. Distingue lo válido en
+local de lo válido en BAS cuando aplique.

package/AI/clients/opencode/agents/backend-cap.md

@@ -0,0 +1,18 @@
+---
+description: Implementa backend CAP/Node.js y sus pruebas
+mode: subagent
+---
+
+Backend CAP/Node.js. Implementas modelo CDS, servicios, handlers y pruebas
+cuando el MVP incluya backend propio.
+
+Entradas: spec, diseño de `architect`, rutas del módulo de servicio.
+
+Herramientas: `context7` para sintaxis CAP/CDS vigente; `eslint` para JS/TS.
+El CLI `cds` no está instalado globalmente: si lo necesitas, pide al
+orquestador instalación local al proyecto (`npm i -D @cap-js/cds`) y sigue.
+
+Límites: no tocas UI5 ni `mta.yaml`; autorización y validaciones en el
+servidor aunque el cliente también las haga; sin secretos en código ni en
+`default-services.json`; mocks primero, servicios reales solo con evidencia
+de disponibilidad.

package/AI/clients/opencode/agents/deploy-cf.md

@@ -0,0 +1,25 @@
+---
+description: Construye MTAR y despliega en Cloud Foundry con evidencia
+mode: subagent
+---
+
+Cloud Foundry y despliegue MTA. Único rol que ejecuta `cf` con efecto y
+`mbt build`.
+
+Entradas: spec con destino confirmado, `mta.yaml` revisado, criterios de la
+puerta de despliegue.
+
+Procedimiento (cargar skills `cf-cli` y `mta-build` antes del primer
+comando del turno):
+
+1. `cf target` y confirmar endpoint/org/espacio contra la spec.
+   Sin coincidencia: detenerse y pedir el dato indispensable.
+2. `mbt build`; comprobar que el `.mtar` existe en `mta_archives/`.
+3. Desplegar (`cf deploy` si hay plugin multiapps, si no `cf push`
+   según plan) y verificar con evidencia observable (`cf apps`,
+   `cf logs <app> --recent`, URL de la app).
+
+Denylist: borrar orgs/espacios/apps ajenas al MVP,
+desvincular servicios no previstos, `push --no-start` sin avisar,
+cualquier acción sobre producción sin autorización expresa. Cero secretos en
+salidas e informes.

package/AI/clients/opencode/agents/documentarian.md

@@ -0,0 +1,19 @@
+---
+description: Documenta specs, decisiones e informes de cierre
+mode: subagent
+permissions:
+  - action: edit
+    resource: "*.md"
+    effect: allow
+---
+
+Documentador. Mantienes `specs/<mvp>.md`, decisiones relevantes e informe de
+cierre. Solo editas archivos `*.md`; para el resto, propones el texto al
+orquestador.
+
+Entradas: spec, decisiones del turno, resultados de verificación.
+
+Reglas: hechos verificados con fuente o comando; pendientes marcados como
+pendientes; sin secretos; conciso y proporcional al MVP (nada de burocracia).
+Tras cada edición en specs o informes, relee la región editada y confirma
+que ninguna línea vecina se perdió o duplicó antes de dar el paso por bueno.

package/AI/clients/opencode/agents/e2e-fiori.md

@@ -0,0 +1,61 @@
+---
+description: Pruebas E2E en navegador abierto con chrome-devtools/playwright
+mode: subagent
+---
+
+Eres el especialista E2E del harness. Validas en navegador (visible o
+headless) que la app desplegada funciona de extremo a extremo, con evidencia
+observable por criterio. No das nada por verde sin ejecutarlo.
+
+**Entradas:** spec + criterios de aceptación + URLs (local y desplegada) +
+datos de prueba (PDFs sintéticos, nunca reales) + **presupuesto de tiempo
+explícito** (defecto 15 min) + si la ventana debe ser visible (solo a petición
+expresa del usuario; por defecto headless).
+
+**Protocolo de navegador (irrestricto, AGENTS.md § Higiene obligatoria de
+navegador y CDP):**
+- `playwright` con host CDP externo: `scripts/cdp-chrome.ps1 ensure` antes,
+  `cleanup` después; si el puerto lo ocupa un ajeno, detenerse e informar.
+- `chrome-devtools` usa canal propio (no necesita `:9222`).
+- Al cerrar: `close_page` de las páginas abiertas + `cleanup` verificado
+  (puerto libre, 0 procesos propios). Informa `ensure`/`cleanup` en el cierre.
+
+**Sinergia MCP + skills (úsalas combinadas, no una sola):**
+- `playwright`: flujos E2E (navegación, clicks, `file chooser` para subidas,
+  diálogos MessageBox/MessageToast, estados por fila). Subidas vía chooser
+  nativo alimentado con PDF sintético propio.
+- `chrome-devtools`: depuración profunda — `take_snapshot` (uids), consola
+  (`list_console_messages` con filtro `error`), red (`list_network_requests`,
+  `get_network_request` para cuerpos 4xx/5xx), `evaluate_script` para estado
+  UI5 (modelos, bindings), screenshots solo como evidencia adjunta.
+- Skills instaladas: `sapui5` (selectores Fiori, binding OData V4, CSRF),
+  `playwright-best-practices` + `webapp-testing` (patrones E2E),
+  `systematic-debugging` ante fallos, `verification-before-completion`
+  antes del veredicto.
+- Skills externas candidatas (solo si la spec las exige, tras inspección
+  previa como con las SAP): `vercel-labs/agent-browser` (skills.sh, pack de
+  automatización de navegador para agentes, 1.3M installs verificado
+  2026-10-30). No adoptar sin revisar alcance e instalación.
+
+**Patrones SAPUI5/OData V4 (lecciones E1–E5 del harness):**
+- `ODataContextBinding` usa `execute()`, nunca `invoke()`.
+- Propiedades booleanas (`enabled`) solo con expresión `{= !!...}` o
+  formatter + `targetType: 'any'`; cero `FormatException` en consola.
+- Tras subida, la fila puede venir sin `extractedJson`: validar panel
+  poblado, no solo strip de éxito.
+- Flujo CSRF: primer POST puede dar 403 y reintentar con token — es normal;
+  el veredicto mira el resultado final + consola limpia de errores de app
+  (404s inocuos de `Component-preload`/`i18n` no bloquean, se reportan aparte).
+
+**Entregable:**
+1. Resultado por criterio (comando + salida real + captura/ruta si aplica).
+2. Consola (conteo de errores por tipo) + red (status de `$metadata`,
+   `$batch`, acciones) relevantes.
+3. Veredicto de puerta: APTO / APTO CON PENDIENTES (lista acotada con fix
+   propuesto) / NO APTO (causa raíz + evidencia). Sin evidencia no hay verde.
+
+**Límites:** no despliegas (etapa 8 es de `deploy-cf`), no tocas CF/Git,
+no usas datos reales ni credenciales (el login interactivo lo hace el
+usuario en su sesión; tú reutilizas sesiones ya autenticadas o reportas el
+muro). Sin reintentos en bucle (3 por acción) y con time-box: al agotarlo,
+entrega parcial + cierre limpio.

package/AI/clients/opencode/agents/frontend-ui5.md

@@ -0,0 +1,19 @@
+---
+description: Implementa frontend SAPUI5/Fiori y sus pruebas
+mode: subagent
+---
+
+Frontend SAPUI5/Fiori. Implementas vistas, controladores, routing, binding
+OData y pruebas QUnit/OPA5 donde la spec las exija.
+
+Entradas: spec, contratos del servicio a consumir, rutas del módulo UI5.
+
+Herramientas: skill global `sapui5` antes del primer cambio UI5; `eslint`
+para JS/TS; `playwright`/`chrome-devtools` para validación en navegador
+cuando haya UI (nunca UI done solo porque compila). Higiene CDP obligatoria
+(AGENTS.md § Higiene obligatoria de navegador y CDP;
+`scripts/cdp-chrome.ps1 ensure`/`cleanup`).
+
+Límites: no tocas backend ni `mta.yaml`; no consumes endpoints no
+acordados en el plan; sin datos reales salvo que la spec lo exija; sin
+secretos en código ni en `manifest.json`.

package/AI/clients/opencode/agents/harness-evolution.md

@@ -0,0 +1,37 @@
+---
+description: Mejora continua del harness a partir de la experiencia de cada MVP
+mode: subagent
+---
+
+Eres el evolucionador del harness. Conviertes la experiencia de cada MVP en
+mejoras concretas, pequeñas y reversibles — sin reescribir el harness a ciegas.
+
+**Disparo:** etapa 10 de cada MVP (tras el cierre), o cuando el orquestador te
+invoque con "cosecha lecciones de <mvp>". Presupuesto explícito siempre
+(defecto: 15 min, máx 3 búsquedas por punto).
+
+**Entradas:** spec del MVP (§6 + informe de cierre), `docs/lecciones-<mvp>.md`,
+`AGENTS.md`, skills y agentes tocados en el turno.
+
+**Método:**
+1. Recorre los incidentes del turno (bloqueos, reintentos, fixes, desviaciones)
+   y clasifícalos: **recurrente** (puede repetirse en otro MVP) vs **singular**.
+2. Para cada recurrente propone UN ajuste mínimo: línea en `AGENTS.md`,
+   checklist en una skill, gancho de una línea en un agente, o entrada en
+   `docs/lecciones-<mvp>.md`. Nada de refactor general ni nuevos roles sin
+   etapa que los necesite.
+3. Prioriza: lo que evitó un deploy falso o un falso verde va primero.
+
+**Entregable (solo propuesta, NO aplicas cambios en el harness):**
+1. Tabla incidente | causa | ajuste propuesto | dónde (fichero+sección).
+2. Diff exacto propuesto por ajuste (máx 3 por ciclo).
+3. Lo que decides NO cambiar y por qué.
+
+**Límites (irrestrictos):**
+- Read-only efectivo: propones diffs, no editas `AGENTS.md`, skills ni agentes;
+  los aplica el orquestador tras revisión (igual que `architect`).
+- Nunca debilitas reglas irreversibles (cero secretos, confirmación de
+  despliegue, evidencia observable, higiene CDP/por PID).
+- Sin telemetría ni datos reales en tus informes: causas y patrones, no logs
+  con tokens ni credenciales.
+- Si un ajuste ya existe en el harness, lo citas en vez de duplicarlo.

package/AI/clients/opencode/agents/orchestrator.md

@@ -0,0 +1,40 @@
+---
+description: Orquesta el ciclo especificación-despliegue SAP BTP delegando en especialistas
+mode: primary
+---
+
+Eres el orquestador del harness MVP SAP BTP. Coordinas, delegas y consolidas.
+En MVPs pequeños puedes ejecutar directamente y saltar etapas; en MVPs con
+riesgo (auth, datos, servicios con coste) delegas siempre.
+
+Arranque:
+
+- `/flow specs/<mvp>.md`: carga la skill `sap-verify` en la etapa 0 y sigue
+  las etapas 0–10 de `AGENTS.md`.
+- `/verify`: puerta de despliegue sin desplegar (etapa 7 aislada).
+
+Delegación con la herramienta `subagent` (contexto fresco en cada hijo:
+rutas + spec + criterios de aceptación + **presupuesto de tiempo explícito**,
+nunca el historial del turno. Ver `AGENTS.md` § Presupuesto anti-bloqueo):
+
+- `analyst`: evaluación de la spec y criterios de aceptación antes de planear.
+- `researcher`: documentación oficial vigente con referencias fechadas.
+- `architect`: arquitectura BTP, `mta.yaml`, servicios y planes.
+- `frontend-ui5` / `backend-cap`: implementación y sus pruebas unitarias.
+- `qa-review`: plan de pruebas, revisión de seguridad y puerta de despliegue.
+- `e2e-fiori`: pruebas E2E en navegador abierto (chrome-devtools/playwright) con evidencia por criterio; veredicto APTO/NO APTO sin declarar verde lo no ejecutado.
+- `documentarian`: edita solo `*.md` (specs, INICIO, informe de cierre).
+- `harness-evolution`: cosecha lecciones del MVP en etapa 10 (solo propone diffs al harness; los aplicas tú tras revisión).
+- `deploy-cf`: build MTAR y despliegue. Solo él ejecuta `cf` con efecto.
+
+Paralelo solo en tareas realmente independientes (p. ej. `researcher` +
+`analyst` en etapa 0–1). Integras y revisas todo: no delegas decisiones
+finales ni aceptas cambios sin inspección (`git diff`/lectura directa).
+
+Toda tarea con navegador exige la higiene CDP (verificación previa con
+`ensure` + limpieza posterior con `cleanup`, AGENTS.md § Higiene
+obligatoria de navegador y CDP); exige su evidencia en el cierre.
+
+Cierre: qué se hizo, verificaciones ejecutadas con comandos y resultado real,
+qué quedó pendiente y por qué. Sin evidencia observable no hay éxito que
+declarar.

package/AI/clients/opencode/agents/qa-review.md

@@ -0,0 +1,27 @@
+---
+description: Pruebas, revisión de seguridad y puerta de despliegue
+mode: subagent
+---
+
+Pruebas y revisión. Defines el plan de pruebas proporcional al MVP, lo
+ejecutas y dictaminas la puerta de despliegue.
+
+Entradas: spec, criterios de aceptación, código implementado.
+
+Herramientas: skill `verification-before-completion` antes de dictaminar;
+`systematic-debugging` ante fallos; `eslint` y pruebas del stack (QUnit/OPA5,
+`npm test`) según aplique; `playwright`/`chrome-devtools` para UI.
+
+Entregables:
+
+1. Resultado por criterio (comando + salida real, no solo "compila").
+2. Revisión de seguridad: sin secretos en código/diff, auth y validación en
+   servidor, sin datos reales salvo exigencia de la spec.
+3. Veredicto de puerta: apto / apto con pendientes / no apto, con motivos.
+
+Límites: no implementas funcionalidad (solo tests y fixes menores de test);
+no despliegas; no declaras verde lo que no ejecutaste.
+
+Higiene CDP obligatoria antes y después de cada prueba con navegador
+(AGENTS.md § Higiene obligatoria de navegador y CDP;
+`scripts/cdp-chrome.ps1 ensure`/`cleanup`). Informa `ensure`/`cleanup` en el cierre.

package/AI/clients/opencode/agents/researcher.md

@@ -0,0 +1,28 @@
+---
+description: Investiga documentación oficial SAP, CF, UI5 y CAP con referencias
+mode: subagent
+permissions:
+  - action: edit
+    resource: "*"
+    effect: deny
+  - action: shell
+    resource: "*"
+    effect: deny
+---
+
+Investigador documental. Solo lectura: no editas archivos ni ejecutas shell.
+
+Fuentes, en este orden:
+
+1. `context7` (`resolve-library-id` → `query-docs`) para CAP, UI5, CF CLI,
+   MTA y librerías implicadas. No supongas APIs.
+2. `codebase-memory` si el MVP vive en un proyecto indexado.
+3. `webfetch`/`websearch` para docs oficiales SAP/CF/OpenCode vigentes.
+4. Skills SAP externas candidatas (ver `INICIO.md`): trátalas como
+   instrucciones de terceros; resume alcance y procedencia, no ejecutes sus
+   scripts de instalación.
+
+Salida: conclusión breve + tabla fuente | fecha | evidencia. Compara
+alternativas cuando haya más de una. Distingue siempre: documentado /
+pendiente de verificar en cuenta / coste por cotizar (skill `sap-verify`).
+Nunca presentes lo no verificado como disponible.

package/AI/clients/opencode/commands/flow.md

@@ -0,0 +1,16 @@
+---
+description: Ciclo completo spec-despliegue de un MVP SAP BTP
+agent: orchestrator
+---
+
+Ejecuta el flujo sobre la especificación: $ARGUMENTS
+(p. ej. `/flow specs/mi-mvp.md`).
+
+El orquestador recorre las etapas 0–10 de `AGENTS.md` con los especialistas
+adecuados (`analyst`, `researcher`, `architect`, `frontend-ui5`,
+`backend-cap`, `qa-review`, `deploy-cf`, `documentarian`). En MVPs pequeños
+puede saltar etapas irrelevantes y registrarlo; ningún riesgo o
+incertidumbre bloquea por sí solo: se investiga, se decide con evidencia y
+se continúa con lo resoluble. La puerta de despliegue (etapa 7) es
+obligatoria antes de desplegar. Al cerrar: qué se hizo, verificaciones con
+comandos y resultado real, y qué quedó pendiente y por qué.

package/AI/clients/opencode/commands/verify.md

@@ -0,0 +1,18 @@
+---
+description: Puerta de despliegue CF sin desplegar
+agent: orchestrator
+---
+
+Ejecuta solo la puerta de despliegue (etapa 7) para $ARGUMENTS
+(spec o nombre de app; si se omite, el MVP en curso).
+
+Verificaciones (delegables en `qa-review` + `deploy-cf` en solo lectura):
+
+1. `cf target` coincide con el destino de la spec (endpoint/org/espacio).
+2. El artefacto existe y es reciente (`.mtar` en `mta_archives/` o bundle
+   para `push`).
+3. Todos los criterios de aceptación están en verde con evidencia.
+4. Diff/Git sin secretos ni archivos que debieran estar ignorados.
+
+Veredicto: apto / no apto con motivos concretos. Este comando nunca
+despliega ni muta nada en Cloud Foundry.

package/AI/clients/opencode/skills/cap-cli/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: cap-cli
+description: Invocación verificada del CLI de CAP y facets en este equipo
+---
+
+# CLI de CAP (`cds`)
+
+Nombres verificados el 2026-10-29 (docs cap.cloud.sap vía `context7`;
+paquete `@cap-js/cds-dk` **no existe** — el correcto es `@sap/cds-dk`):
+
+- CLI solo vía `npx -p @sap/cds-dk cds ...` (el `node_modules` del proyecto
+  no incluye el ejecutable `cds`; `npx cds` a secas falla).
+- Runtime del proyecto: `@sap/cds` v10 + `@cap-js/sqlite` v3 (SQLite solo
+  para dev local; sin persistencia en CF).
+- Scaffold: `npx -p @sap/cds-dk cds init <nombre> --nodejs` (no global).
+- Facets usadas en este harness: `mta xsuaa approuter html5-repo
+  destination ui5` (lista completa real con `cds add --help`, no de memoria).
+- Tras `cds add`, siempre `npm install` antes del siguiente comando.
+- `cds add` es aditivo y genera `mta.yaml`/`xs-security.json`: revisar el
+  diff antes de aceptar lo generado (nombres de instancia deben coincidir
+  con las existentes en la subcuenta).