Crea módulos y skills
Diseña la lógica sectorial, verifica cada subacción y registra la skill en el tenant.
Alcance y estado
Esta guía recoge los diagramas y las aclaraciones de producto facilitados el 14 de septiembre de 2026. «Implementado» identifica el estado comunicado para este material; no certifica la disponibilidad en todos los entornos. Las propuestas se indican expresamente.
Abrir gráfico interactivo y ampliar · Ver imagen a tamaño completo
El texto de la guía desarrolla el gráfico para que puedas seguir el recorrido también sin utilizar el visor.
Este recorrido construye una capacidad que Hermes puede utilizar. Puede apoyarse únicamente en herramientas existentes de Pimia o necesitar un módulo con datos propios. No presupone construir antes una aplicación completa.
Del flujo a la implementación
- Describe el trabajo. Recoge documentos, capturas o una transcripción del proceso, sus entradas y el resultado esperado.
- Prepara la especificación y el grafo. Explica acciones, dependencias y decisiones. El material incluye una aprobación del diseño en el visor antes de construir.
- Construye con las herramientas del MCP. Define los pasos de la skill y los recursos necesarios.
- Añade un backend solo si hacen falta datos propios. La propuesta de arquitectura utiliza InsForge para tablas, RLS, funciones y webhooks del módulo.
- Obtén el veredicto y registra. Una skill rechazada se rediseña; una admitida declara su verificabilidad y se registra para el tenant.
El gráfico muestra Claude Code y skill-creator como herramientas del flujo descrito; esos nombres no sustituyen la especificación funcional de la solución.
Tier y nivel de verificabilidad son escalas distintas
| Clasificación | Qué describe | Consecuencia |
|---|---|---|
| Tier T0–T3 | Las herramientas que toca la skill. | T2 y T3 requieren revisión de plataforma al publicar, según el material. |
| Nivel 1–4 | Cómo se verifica cada subacción bloqueante. | Determina el checkpoint; el nivel 4 exige intervención humana visible. |
No hay una correspondencia automática entre un tier y un nivel. No se asignan aquí significados individuales a T0–T3 o a los niveles 1–3 que no hayan sido facilitados.
Cada subacción bloqueante declara su nivel y si cuenta para el sello. register_specialization rechaza la ausencia de esa declaración con missing_verifiability_declaration. El veredicto RECHAZADA detiene el recorrido y exige rediseñar; no se supera simplemente publicando la ficha.
Token prestado: implementado
Un servicio que atiende una petición ya autenticada recibe su cabecera Authorization y reenvía el bearer token mediante withBorrowedToken.
- Crea un cliente por petición.
- No utiliza
TokenStore, no persiste el token y nunca lo refresca. - Si caduca, devuelve el
401al propietario del grant, que gestiona su renovación. - Pimia sigue evaluando los permisos; el servicio no amplía los derechos del token recibido.
Consulta el ejemplo compartido de Token prestado. Los datos propios del módulo se relacionan con Pimia mediante identificadores y external_ref donde el contrato lo admita.
JWT del host: propuesta pendiente
Diseño propuesto, no construido
No utilices este apartado como contrato disponible. El nombre oficial, los campos exactos y el mecanismo de integración están pendientes.
El diseño propone que el fork valide la cookie de sesión y emita un JWT de vida corta firmado con un secreto compartido con InsForge. Contendría usuario, tenant, empresa y el rol authenticated. InsForge comprobaría la firma y aplicaría RLS con ese contexto.
Este JWT no transporta permisos de Pimia ni sustituye su autorización. La conexión de Hermes con las herramientas del módulo también sigue marcada como propuesta.
Qué autoriza una ejecución
Deben cumplirse tres controles diferentes:
- Los scopes del token de Hermes limitan las operaciones disponibles.
- Las abilities de quien delega son otro límite: la skill no puede hacer más de lo que esa persona puede hacer.
- El nivel de cada subacción determina su checkpoint de verificación o aprobación.
La autorización efectiva debe respetar ambos conjuntos de permisos. Una aprobación humana no concede scopes adicionales.
Resultado: skill registrada en el contexto del tenant, con subacciones verificables. Esto no equivale a publicar una ficha comercial: continúa en Publica y distribuye.