Ejecución: las acciones A a E

En la pestaña Ejecución están las cinco acciones. Cada tarjeta indica qué etapa ISO cubre, cuándo se ejecutó por última vez y, si no aplica a tu perfil o a tu CDE, por qué. A la derecha, la salida muestra en vivo lo que hace cada acción; Detener la corta si hace falta (lo que alcanzó a generar queda guardado) y Fijo arriba mantiene la salida a la vista. Repetir una acción no duplica nada.

Ejecución en RPW, con Forma configurado por Kronesta.

	Acción
A	Revisar los libros. Valida los libros y la norma, y muestra lo que se haría en el CDE. No cambia nada. Ejecútala siempre primero. Si el CDE está en otra plataforma, la tarjeta lo nombra («CDE en Dalux») y al terminar te dice que lo configures allí con lo que dicen los libros. Si Kronesta no configura el CDE, A se titula «Revisión de los libros» y no muestra avisos de configuración. También avisa si faltan las fechas de inicio o fin de la inversión y si una hoja usa un código de Autor que no está en 2_Partes.
B	Ejecutar en Forma. Crea o actualiza el proyecto, las empresas, los miembros, las carpetas, los permisos y el flujo de revisión y aprobación, y genera la norma de nomenclatura (impórtala y asígnala en Forma justo después). Pide confirmación. Solo con Forma configurado por Kronesta.
C	Formatos MEF (sector público). Llena los formatos oficiales que corresponden a tu perfil y deja cada uno listo para firmar (ver Firmar los Formatos MEF).
D	Documentos ISO 19650. Word y PDF con la marca del proyecto (y Excel para los programas). Antes de generar, valida los libros igual que A, avisa de los errores y genera igual. Compara cada documento con su última emisión: si cambió, sube la revisión (P01, P02…) y guarda la anterior en Historial. Sin Forma, genera también el archivo de la norma de nomenclatura, que entra en la información de referencia.
E	Publicar en Forma. Sube la información de referencia a 00_REFERENCIA: la norma y, si tu cliente es parte que designa, los Formatos 01 a 04 firmados (el PDF de la carpeta Firmados, nunca el Excel) y el OIR, AIR, PIR y EIR. Solo sube lo que cambió. Requiere haber ejecutado B. Sin Forma, la referencia se comparte desde «Licitar».

Antes de generar, D pide una descripción opcional del cambio para la tabla de control.

La tarjeta de resultado después de D: qué se generó, con qué revisión y qué sigue.

Al terminar: la tarjeta de resultado

Cuando una acción termina, Kronesta se queda en Ejecución y muestra una tarjeta con lo que pasó: un título («Libros validados», «CDE creado en Forma · YAKU», «8 documentos generados»…), las cifras, cada documento con su revisión, los avisos y, después de B, lo que queda por hacer a mano en Forma. Arriba trae Lo que sigue, con el botón del paso siguiente de Chaski. El texto completo de la acción sigue en Ver el detalle técnico.

La tarjeta está…	Qué significa
Verde (✔)	La acción terminó bien.
Ámbar (!)	Terminó, pero algo no se pudo hacer (por ejemplo, un Word abierto que D no pudo guardar). Lo que falló va marcado con ✖: corrígelo y vuelve a ejecutar. Ámbar con ■: la detuviste.
Roja (✖)	No terminó. La tarjeta muestra los errores (en A, los de los libros) y deja abierto el detalle técnico.

Qué genera C y D según el perfil

Perfil	C · Formatos MEF	D · Documentos ISO 19650
Parte que designa	N.º 01 OIR, 02 AIR, 03 PIR y 04 EIR	OIR, AIR, PIR, EIR y protocolo de información (Word y PDF)
Parte designada · pre contrato	N.º 05 BEP y 06 competencias y capacidades	BEP de la oferta, con movilización y riesgos (Word y PDF)
Parte designada · confirmado	N.º 05 BEP, 07 matriz, 08 MIDP y 09 TIDP por equipo	BEP confirmado y EIR de la parte designada principal para cada equipo (Word y PDF); matriz, MIDP y TIDP (Excel)
Equipo de tarea · pre contrato	N.º 06 de su equipo	Su evaluación de competencia y capacidad (Word y PDF, con firma)
Equipo de tarea · confirmado	N.º 09 TIDP de su equipo	Su TIDP (Excel) y la aceptación de la designación (Word y PDF, con firma)

Lo que A y B revisan en Forma

A no cambia nada en Forma: anuncia lo que B haría. B solo agrega, actualiza o quita lo que el libro indica; repetirlo no duplica nada.

Qué ves	Qué significa
Funciones que faltan en el hub	Forma no deja crear funciones por API: créalas en Forma › Hub Admin › Funciones con el nombre exacto de 3_CDE › 4_Funciones. Chaski trae Ya lo hice → comprobar con A.
«Ya hay en el hub un proyecto llamado…»	Respondiste que Kronesta crea el proyecto, pero el hub ya tiene uno con ese nombre. A y B se detienen sin cambiar nada. Si es el tuyo, responde «el proyecto ya existe en Forma» con su ID; si no, cambia el nombre.
«Se quitaría» o «Quitado»	Una empresa de 3_CDE › 2_Partes tiene un permiso que el libro ya no le da y B lo quita. Nunca toca usuarios, funciones, empresas ajenas al libro ni permisos heredados.
«Quedaron sin permisos»	Una empresa no tiene miembros en el proyecto y no se le pudo dar acceso. Agrega una persona por empresa en 3_Miembros y vuelve a ejecutar B.
Espera que acepten la invitación	B no crea el flujo de aprobación mientras alguien de 10_Aprobacion no aceptó la invitación de Forma. Cuando acepten: Ya aceptaron → volver a ejecutar B.
Norma cambiada después de importarla	Cambiaste en el libro una norma que ya está en Forma. Chaski pide editarla en Forma igual que en el libro y marcar que ya la editaste.
Personas que le faltan al flujo	El flujo ya existe y 10_Aprobacion tiene personas nuevas. Como la API no deja editarlo, Chaski pide agregarlas en Forma.
Flujo esperando la norma	El flujo pide Estado y Revisión, que existen solo con la norma asignada en la carpeta de lo aprobado. Asígnala y vuelve a ejecutar B.

Validar antes de compartir. La norma pide revisar la información antes de compartirla (5.6.3 y 5.6.4), no antes de generarla. Por eso D puede generar sin pasar antes por A, pero marcar un envío o publicar con E exige que la última validación de los libros (A, B o la de D) no tenga errores y sea posterior al último cambio de los libros. Si no, Chaski te pide validar primero.Regla de pre contrato: si tu cliente está postulando y el CDE es de la entidad (o de un tercero), B y E quedan bloqueados hasta pasar el Momento del BEP a «Confirmado (designación)». Si tu cliente es un equipo de tarea, B y E no aplican nunca: trabaja en su carpeta del CDE de otro.
Antes de ejecutar B: los miembros nuevos reciben una invitación real por correo de Autodesk. Revisa la simulación y la lista de miembros; si la principal ya fue designada, Chaski pide antes registrar a sus personas en 3_Miembros. Los pasos a mano en Forma se hacen con la cuenta de un administrador del proyecto (3_Miembros), no con la que usa Kronesta. Chaski te pide además revisar el flujo de aprobación (3_CDE › 10_Aprobacion), porque después la API no deja editarlo: márcalo con Revisado: está bien.