Crear y publicar un playbook

Al crear un playbook se guarda su primera versión. Al publicar una actualización se guarda una nueva versión inmutable que las personas y los agentes pueden usar con los permisos actuales del playbook. Para actualizar, indique la versión más reciente como base.

Elija la operación según su objetivo:

Preparar los archivos de entrada

Guarde el siguiente ejemplo como playbook.json en su directorio de trabajo. Crea un playbook privado en el espacio activo o en el espacio personal. Compruebe el espacio seleccionado antes de ejecutar el comando.

{
  "private": true,
  "definition": {
    "schemaVersion": 1,
    "title": "Evaluar un piloto de IA",
    "description": "Confirmar el objetivo del cliente y acordar cómo evaluar el piloto.",
    "category": "operations",
    "inputSchema": {
      "type": "object"
    },
    "steps": [
      {
        "title": "Confirmar el objetivo del cliente",
        "instructions": "Registre el alcance acordado, las cifras iniciales, los criterios de éxito y quién decide."
      }
    ]
  }
}

En un espacio de trabajo, elija exactamente una opción inicial: private: true para acceso del creador, teamIds para edición mediante equipos seleccionados o access para la configuración completa. Para compartir este ejemplo con el equipo del cliente al crearlo, sustituya "private": true por "teamIds": ["<client-team-id>"] con el UUID real del equipo. No conserve ambas opciones.

Para actualizar, copie playbook.json como next-version.json, elimine el campo superior private y modifique el contenido de definition. El archivo de actualización debe contener solo el objeto definition, sin campos de creación como ownerId, private, teamIds o access. El comando siguiente indica la versión base mediante --base-version-id. El prefijo @ indica a la CLI que lea el archivo JSON.

Para definir entradas, pasos y recursos, consulte Crear un playbook.

epismo playbook create --request @playbook.json
epismo playbook get <playbook-id>
epismo playbook version publish <playbook-id> \
  --base-version-id <latest-version-id> --request @next-version.json

Si hay un conflicto, consulte la versión más reciente e incorpore sus cambios en una nueva definición.

Iterar primero con un borrador

Publicar directamente está bien para un cambio pequeño y seguro. Para cualquier cosa que necesite algunas pasadas, guárdela como borrador; nunca crea una versión, por lo que no hay nada que limpiar si cambia de opinión:

Prepare draft.json con el mismo formato que next-version.json: un objeto superior definition con la definición revisada completa. Use en --base-revision la revisión devuelta por draft get; indique 0 solo si aún no existe un borrador.

epismo playbook draft get <playbook-id>
epismo playbook draft save <playbook-id> --base-revision <revision> --request @draft.json
epismo playbook draft publish <playbook-id>
epismo playbook draft discard <playbook-id>

--base-revision es la última revisión que leyó (0 para un nuevo borrador); un valor obsoleto indica que otra persona guardó cambios desde entonces: vuelva a leer el borrador e inténtelo de nuevo. Un playbook tiene un borrador, visible solo para quienes pueden editarlo. draft publish crea una versión a partir del borrador actual y elimina el borrador en la misma operación; draft discard elimina el borrador sin publicar nada.

• Permisos: access: { visibility, grants }; los permisos viewer y editor son independientes de la visibilidad public.
• Alias: referencia memorable; nunca concede acceso.
• URL compartida: redirige a la página del playbook, donde sigue aplicándose la ACL actual. Las URL compartidas actuales no tienen caducidad ni una operación para revocarlas.
• Borrador: contenido mutable no publicado que requiere edición. Las URL compartidas no conceden ese permiso.

Compartir con el equipo del cliente

Después de publicar la versión, elija quién la utilizará. Para el trabajo con clientes, mantenga la visibilidad en restricted y conceda acceso al equipo. Primero prepare el equipo y, si necesita un método específico, copie una versión adecuada.

Lea los permisos actuales de la copia. Por ejemplo, un equipo interno puede mantenerla y el equipo del cliente leerla:

epismo playbook access get <client-playbook-id>
epismo playbook access set <client-playbook-id> \
  --access '{"visibility":"restricted","grants":{"<internal-team-id>":"editor","<client-team-id>":"viewer"}}'

Es un mapa completo de ejemplo, no una combinación con los permisos anteriores. Conserve los demás colaboradores previstos y al menos un editor explícito. Conceda editor al equipo del cliente si debe actualizar el playbook; los editores también leen borradores y cambian permisos. Antes de compartir, revise las versiones publicadas, el borrador y los recursos para esa audiencia.

Compruebe con un participante del cliente que puede leer o editar según lo previsto. Comparta el caso por separado: no hereda los permisos del playbook. Una URL o alias es una referencia y no sustituye el permiso del equipo. Consulte Coordinar un caso.