Genera la base de un servicio NestJS hexagonal nuevo: capa shared completa (JSON:API, errores, logger, config+Joi, database-context, utils), archivos de config/enforcement (eslint, prettier, Dockerfile, verify-standards, hooks husky), main.ts y app.module.ts canónicos. Escribe en projectRoot. OBLIGATORIOS y SIEMPRE se le preguntan al usuario (no se inventan ni tienen valor por defecto): prefijoApi, prefijoError y motor (mssql | postgres | mysql | none); si falta alguno la herramienta no genera nada y dice cuál preguntar.

Genera un caso de uso completo (vertical slice hexagonal) en un dominio: puerto inbound/outbound, domain service, application service + interface + spec, adapter (TypeORM por defecto; SP opt-in con nombreSp), controller JSON:API + DTOs, entidad de dominio y TypeORM, catálogos de error, y los módulos del dominio. Escribe en src// (carpeta siempre lowercase; las clases salen en PascalCase sin importar el case de "dominio"). MULTI-CASO: al añadir el 2º/3er caso al MISMO dominio, el MCP MERGEA ese caso en los módulos del dominio ya generados (controller, adapter, providers, tokens, forFeature) — tanto en greenfield como en refactor. En refactor NUNCA toca app.module (eso lo cablea el agente). API EXTERNA: con adapterType="http" (apiExterna, rutaApi, metodoHttp) el caso consume una API con el fetch nativo y NO necesita base de datos, conexion ni motor; declara _BASE_URL en config, Joi y .env.example. SP: con adapterType="sp" el wiring es quirúrgico — apunta el módulo al .sp.adapter y quita del forFeature SOLO la entidad de ese caso, preservando las de los casos TypeORM. INFRA (refactor): usa infraStyle="project" + infraRoot (p.ej. "common") para que los imports de infra apunten a la carpeta del proyecto; aun así, concilia a mano los NOMBRES de clase (ResponseJsonApiBase/GenericException de los templates vs los del proyecto).

Devuelve lo que el MCP recuerda de ESTE repo por usos anteriores: convenciones (contexto del servicio, prefijos de error y conexiones ya usados), decisiones que el usuario tomo una vez (autorizacion) y los errores del verificador que se repiten en este repo. Es SOLO LECTURA y CONSULTIVO: no sustituye ni relaja las reglas base (get_rules) ni el verificador. Llamala justo despues de get_rules y usa los datos para PROPONER defaults que el usuario confirma. Si no hay nada util, lo dice y no pasa nada.

Registra una decision que el USUARIO tomo de forma explicita y que vale para todo el repo, para no volver a preguntarla en la siguiente sesion. Lista cerrada: authorization = enabled | disabled. Solo con una respuesta clara del usuario; nunca por suposicion del agente. Escribe en docs/mcp-learnings.json.

Instala (o actualiza) en el repo consumidor el punto de entrada del MCP: los agentes middleware-generator (el unico que se selecciona), middleware-gen-worker y middleware-auditor (.kiro/agents), la plantilla del middleware.spec.yaml (agentic/templates) y la sección del MCP en AGENTS.md (entre marcadores BEGIN/END; el resto del archivo no se toca). Idempotente: volver a correrla actualiza a la versión del MCP. Un archivo con el mismo nombre que no instaló este MCP se respeta salvo overwrite=true. Úsala cuando el usuario quiera dejar el repo listo para crear servicios con el MCP.

Devuelve el procedimiento paso a paso de un flujo (start | greenfield | refactor). Es la ÚNICA fuente del procedimiento: la comparten los prompts del MCP y el agente spec-builder-middleware instalado, para que no haya copias que se desincronicen.

OPT-IN. Agrega la autorización del borde HTTP al servicio: puerto agnóstico IAuthorizationVerifier + adapter por defecto (API de autorización) + Guard GLOBAL, secure-by-default (todo endpoint protegido salvo @SkipAuthorization()) y FAIL-CLOSED (denegado o autorizador inalcanzable = 403). El agente DEBE PREGUNTAR al usuario si quiere activarla; nunca decide solo ni la omite en silencio. Se crea UNA vez por servicio en src/shared/authorization. Parchea ConfigurationVariables, el schema Joi, .env.example y app.module (la registra DESPUÉS de SecurityModule para que el rate limit corra primero). Idempotente.

Genera un módulo hexagonal a partir de un middleware.spec.yaml declarativo (agnóstico de dominio: module/entity/use_cases los define el usuario en el spec). Soporta casos de uso con N métodos por puerto (inbound/outbound). Con dryRun=true (default) valida el spec y devuelve el PLAN de generación (casos, métodos, archivos) SIN escribir disco; con dryRun=false genera el slice por cada caso reutilizando add_use_case. Respeta las reglas de get_rules.

Registra un módulo en docs/architecture-inventory.json (envelope con mcpVersion/generatedAt; una entrada por módulo, sin tocar las de otros) y escribe docs/audits/-.md. Lee el middleware.spec.yaml del módulo para no duplicar datos; acepta compliance (salida de verify_standards), estado de build y decisiones. Es la memoria por repo del MCP: léela al abrir una sesión futura para no duplicar módulos.

Genera la documentacion de la API LEYENDO EL CODIGO REAL (controllers, DTOs, catalogos de error), nunca de memoria. Siempre: contrato por modulo (src//contracts/.api.md), diagrama Mermaid sequenceDiagram por modulo (src//diagrams/.flow.mmd) e indice docs/api/README.md, mas docs/ARCHITECTURE.md (diagrama Mermaid architecture-beta; siempre, no se pregunta). Opt-in (el agente PREGUNTA al usuario): postman=true crea docs/api/middleware.postman_collection.json (una coleccion, una carpeta por modulo, fusion sin tocar las demas). Idempotente y determinista; add_use_case y record_architecture la refrescan solos.

Ejecuta la verificación de estándares (naming, cabeceras de seguridad, @Version, .env.example, SP opt-in) sobre el proyecto destino. Devuelve el reporte; falla si hay errores bloqueantes.

Devuelve el cerebro de calidad del área (rules.yaml): las convenciones de arquitectura hexagonal, naming, puertos inbound/outbound multi-método, DTOs JSON:API, acceso a datos (TypeORM/SP), reglas de negocio, catálogo de errores, seguridad y complejidad. Es AGNÓSTICO de dominio (module/entity los pone el usuario) e incluye snippets destilados del repo canónico. El agente DEBE leerlo ANTES de generar un servicio nuevo o refactorizar uno existente.

Descubrimiento del proyecto destino (para el Flujo 2 refactor): detecta la convención de carpetas/case de dominios, la forma de la conexión TypeORM (forRoot por defecto vs conexiones nombradas, replication), la infraestructura transversal ya existente (JSON:API response, tipo de error, middleware, ConfigurationVariables) que debe REUSARSE, y los módulos presentes. Devuelve reglas a respetar antes de generar nada. Sobre el proyecto solo LEE; lo unico que puede escribir es la instalacion automatica del kit de agentes del MCP (.kiro/agents, agentic/templates y la seccion de AGENTS.md) la primera vez que se usa una herramienta en un repo, que es lo que el usuario pidio al configurar el MCP y se desactiva con MIDD_NESTJS_AUTO_KIT=off. Si lo instala, avisa que agente seleccionar.

Lista las plantillas disponibles en el dataset (shared, config, _domain-slice).

Devuelve el contenido crudo de una plantilla del dataset por su ruta relativa.