Libros de jugadas y versiones
Guía reutilizable con identidad inmutable y ejecución flexible.
Un Playbook es un contenedor lógico con un propietario implícito, visibility, editores explícitos, un alias oficial opcional, la última versión y estado de archivo. Su contenido real se encuentra en versiones inmutables, por lo que un título o un cambio de paso siempre crea un nuevo hecho histórico en lugar de reescribir la definición utilizada en trabajos anteriores.
Definición
Una Versión contiene schemaVersion, título, descripción, una categoría, un esquema de entrada y una lista ordenada de Pasos. Las categorías son productivity, programming, design, sales, marketing, operations y learning.
El esquema de entrada es JSON Schema Draft 2020-12 con una raíz de objeto. Describe la entrada de caso aceptada; no hace que Epismo ejecute el Playbook.
Cada Paso tiene:
| Campo | Significado |
|---|---|
id |
Identidad estable de cuatro caracteres dentro del Playbook lógico |
title |
Breve descripción del paso del tamaño de un juicio |
instructions |
Orientación para una persona o agente |
resourceHints[] |
Habilidades de los candidatos, servidores MCP, CLI, API, complementos, gráficos, documentos, agentes o recursos personalizados |
expectedOutputs[] |
Sugerencias legibles por humanos y agentes, no puertas de finalización impuestas por máquinas |
Los pasos no tienen estado, asignados, transiciones, política de reintento, dependencias ni marcas de tiempo de finalización. Un agente puede omitirlos, combinarlos, reordenarlos o ampliarlos.
Editorial e identidad
La creación de un Playbook crea el contenedor y la Versión 1 de forma atómica. Para publicar otra versión se requiere baseVersionId. Si la última versión cambió, la publicación falla con un conflicto en lugar de sobrescribir el trabajo simultáneo.
El servidor normaliza una definición, almacena JSON canónico y calcula un resumen sha256:. El formato JSON o YAML equivalente produce la misma identidad de contenido. Un caso anclado a una versión almacena su ID de versión y su resumen, de modo que la guía con la que comenzó sigue siendo verificable.
Los nuevos pasos omiten las identificaciones; el servidor los asigna. Conserve una ID existente solo cuando el Paso sea el mismo Paso lógico. Las identificaciones eliminadas no se reutilizan.
Archivar versiones
Un administrador propietario puede archivar una versión histórica desde su página de detalles, la CLI, MCP o la API HTTP. Las versiones archivadas desaparecen de las listas normales, las lecturas directas y los nuevos inicios de casos. Sus números nunca se reutilizan: si se archiva la Versión 2 después de publicar las Versiones 1–3, el historial visible muestra las Versiones 1 y 3, y la siguiente publicación es la Versión 4.
La última versión no se puede archivar porque sigue siendo la definición actual del Playbook y la base de los borradores y publicaciones futuras. Los casos existentes conservan la referencia a su versión fijada y siguen funcionando, pero el contenido de la versión archivada deja de exponerse mediante lecturas normales.
Borradores
Un Playbook tiene como máximo un borrador: contenido mutable e inédito que un administrador propietario puede guardar tantas veces como desee sin crear una versión. Cada guardado toma la última revisión leída (0 para un primer borrador); se rechaza una revisión obsoleta, la misma disciplina que un conflicto entre la versión base al publicarse.
Un borrador sigue el acceso de edición del Playbook: los editores y administradores propietarios pueden leerlo y editarlo, mientras que los lectores públicos y los enlaces compartidos no pueden acceder a él. Al publicar un Borrador se crea una nueva Versión a partir de su contenido y se descarta el Borrador en el mismo paso; descartarlo directamente deja intacta la versión publicada.
Descubrimiento y referencias
Busque Playbooks legibles por texto y categoría, o explore el catálogo web por tipo de recurso y referencia de recurso normalizada. El catálogo agrupa las formas equivalentes de URL y de proveedor de GitHub y npm, y mantiene separados los tipos de recursos. Marque los Playbooks útiles o asigne un alias en su namespace activo. Cada namespace personal o Workspace administrado puede dar un alias a un Playbook legible. Los formularios de visualización canónicos son pb:alias para un alias resuelto localmente y pb:handle/alias para un namespace nombrado. El alias del propietario del Playbook se muestra e indexa como oficial. Un alias de terceros se muestra solo a su propietario como "tu alias" y no se indexa. Un alias nunca otorga acceso y siempre apunta al Playbook lógico, no a una versión.
Los tokens compartidos brindan acceso de lectura basado en tokens sin cambiar el acceso permanente. Los Playbooks públicos exponen sus instrucciones y sugerencias de recursos, por lo que debe eliminar secretos, URL firmadas, referencias internas y datos personales antes de establecer visibility como public.