Procedencia

La procedencia es el registro de una pieza de trabajo: una tarea, un plan, una tarea del plan o un paquete de trabajo. Responde a las preguntas que debe resolver un cambio mucho después de su fusión: de dónde proviene, quién lo solicitó, quién es su propietario, quién decidió qué y por qué, y qué se entregó.

Coroid genera este registro a partir de lo que ya ocurre mientras el trabajo avanza en la fábrica: la conversación o solicitud que lo inició, los documentos que las personas aprobaron, las decisiones que tomaron y las pull requests y commits que lo entregaron. Verá el mismo registro en el portal, en las pull requests y en los commits; además, los agentes que trabajan en la tarea también lo consultan.

Qué responde la procedencia#

• Origen. Lo que inició el trabajo, con un enlace a él: una conversación de chat, una revisión de Prepare Work, una solicitud de Nuevo trabajo, un issue importado o mediante webhook, un hook, una programación, un cliente MCP, el API, un hallazgo o informe, o un plan o tarea padre.
• Solicitante y propietario. La persona que solicitó el trabajo y quien lo posee ahora. Cuando el trabajo llega a través de una cuenta de servicio o de alguien externo a su organización, como el autor de un issue de GitHub, la procedencia indica esa cuenta o persona. Coroid nunca completa datos que tendría que adivinar.
• Decisiones. Aprobaciones, solicitudes de cambio, inicios, paradas, reintentos, fusiones, anulaciones y cambios de propiedad, cada uno con quien lo realizó, cuándo y la razón cuando se proporcionó.
• Discusión. Los mensajes de las personas que dieron forma al trabajo: extractos cortos de la conversación de origen y de los comentarios sobre sus documentos, cada uno con su autor y un enlace.
• Entrega. Las pull requests, commits, veredictos de QA, decisiones de revisión y evidencia.

Una tarea que pertenece a un plan comparte el origen y el solicitante del plan. Su procedencia también muestra la línea de ascendencia: la tarea, su plan y paquete de trabajo, y la conversación o solicitud de la que provienen.

Resumen primero#

Toda vista de la procedencia comienza con un resumen para que pueda ver de un vistazo para qué sirve el trabajo y quién lo respalda:

• Intención: lo que hace el trabajo y por qué, en un párrafo corto. Proviene de la intención aprobada, si no, de la especificación aprobada, si no, de la solicitud original, si no, de la descripción de la tarea o del plan. Debajo aparece una línea que indica cuál de ellos se utilizó.
• Solicitado por: la persona, cuenta de servicio o persona externa que lo solicitó.
• Propietario: quien posee el trabajo ahora. Es la persona a la que se transfirió por última vez, si no, la persona asignada a la tarea, si no, el propietario de la conversación de la que proviene, si no, el solicitante.
• Aprobado por: las personas que aprobaron su intención, especificaciones y plan de implementación, además del propio plan, indicando el rol que desempeñaron en la aprobación.
• Decisiones clave: hasta cinco de las decisiones más recientes tomadas por los usuarios, junto con el motivo de cada una.

Los aprobadores listados siempre son personas. Las aprobaciones que Coroid registró de forma automática se excluyen; consulte Decisiones automáticas.

Dónde se visualiza#

En el portal#

Abre una tarea o un plan en la Fábrica y despliega la sección de procedencia. Debajo del resumen encontrarás estas partes:

• Origen: indica el origen del trabajo, con un enlace a la conversación, solicitud, incidencia o informe correspondiente.
• Linaje: el plan y el paquete de trabajo al que pertenece una tarea, cuando forma parte de un plan.
• Decisiones: ordenadas de más antiguas a más recientes, cada una con su motivo. Un historial extenso muestra las ocho más recientes, y con un clic puedes ver el resto.
• Discusión: los mensajes que dieron forma al trabajo, ordenados de más recientes a más antiguos.
• Entrega: pull requests y quién los fusionó, commits, veredictos de QA, revisiones y pruebas.

Una versión resumida aparece en la pestaña Detalles de una tarea y en la revisión de promoción de un plan, con un enlace a la procedencia completa.

El acceso sigue al propio trabajo. La procedencia de una tarea requiere acceso de lectura a su proyecto, y la procedencia de un plan es visible en toda tu organización, al igual que el plan.

En los pull requests#

Cada pull request Coroid que se abre incluye una sección de procedencia, ya sea que entregue una tarea, un plan o un pull request de lanzamiento. La sección comienza con el mismo resumen: la intención, el trabajo, quién lo solicitó, quién es el propietario, quién lo aprobó y las decisiones clave. Luego vienen el origen y sus enlaces, seguido del linaje, las decisiones, la entrega y un enlace para abrir el trabajo en Coroid.

Coroid redacta las demás secciones alrededor de esta: un resumen del cambio, un enlace a la tarea y sus pruebas de revisión, los criterios de aceptación y el estado de control de calidad y revisión.

Coroid solo gestiona las secciones que marca con comentarios ocultos en la descripción. Cuando actualiza el pull request, por ejemplo tras una reelaboración, reemplaza esas secciones y mantiene todo lo que tú o tus revisores escribieron tal como estaba. Si el historial es demasiado extenso, las decisiones más antiguas se eliminan primero y la sección indica que hay más información en Coroid.

Un pull request de lanzamiento enumera cada pull request incluido: lo que entrega, quién lo solicitó y quién lo aprobó, en orden de fusión.

En los commits#

Cada commit que realiza Coroid termina con trailers que indican a qué trabajo pertenece:

Coroid-Task: 3f6e2b1c-7d4a-4c1e-9b2f-0a8d5e6c7b91
Coroid-Plan: 8a41b7c3-25d0-4f6b-a1e9-6c3d2b7f4e05
Coroid-Requested-By: Maya Lindqvist
Coroid-Origin: prepare_work

Dependiendo del trabajo, un commit también especifica su tarea de plan, paquete de trabajo, ejecución de agente, parche o lanzamiento. El trailer del solicitante muestra un nombre, nunca una dirección de correo electrónico.

Coroid es el autor de cada commit que realiza. Si un commit se crea con la cuenta conectada de una persona, Coroid también se añade como coautor:

Co-authored-by: Coroid <ai@coroid.ai>

Coroid también mantiene su propio mapa que relaciona cada commit con su tarea o plan. Cuando un pull request abierto por Coroid se fusiona en GitHub o GitLab, Coroid registra el commit de fusión o de compactación que se incorpora, para que una fusión de compactación no pierda el enlace.

Para los agentes#

El registro de trabajo de cada agente en una tarea resume su procedencia: el motivo por el que existe la tarea, quién la solicitó, quién es su responsable y qué se decidió al respecto. Cuando un agente necesite más información, podrá consultar todo el registro, sección por sección.

La especificación sigue siendo la norma. Si la procedencia y la especificación difieren, un agente sigue la especificación y indica el conflicto en su informe en lugar de decidir en silencio. Los mensajes y motivos escritos por personas pasan por el filtro contra inyección de prompts de Coroid antes de que un agente los lea, y el texto que el filtro bloquea no se incluye.

Lo que nunca llega a tu host de Git#

El texto de la conversación nunca se escribe en un pull request ni en un commit. Una solicitud de extracción incluye nombres, funciones, decisiones, motivos y enlaces. La discusión solo muestra la cantidad de mensajes y quién los redactó, con un enlace a la conversación en Coroid. Las direcciones de correo electrónico nunca se incluyen; las personas aparecen por su nombre.

Solo enlaces#

De forma predeterminada, la sección de procedencia de un pull request incluye el párrafo de intención, las decisiones clave y los motivos expuestos por las personas. Una organización puede optar por la opción 'solo enlaces'. En ese caso, la sección indicará quién solicitó el trabajo, quién es el propietario, quién realizó las aprobaciones, las decisiones y los enlaces a Coroid, omitiendo el párrafo de intención, las decisiones clave y todos los motivos.

Seleccione la opción 'solo enlaces' cuando personas que no deben acceder a la justificación del producto puedan ver su repositorio, por ejemplo, si es público. Esta configuración se aplicará a las solicitudes de extracción que Coroid abra o actualice tras realizar la selección. Por el momento, no existe una pantalla de configuración para ello. Contáctenos para cambiar la configuración de su organización a la opción 'solo enlaces'.

Decisiones y sus motivos#

Coroid registra qui decidió qué mientras el trabajo avanza en la fábrica: las aprobaciones de la intención, las Especificaciones y los Planes, la Calificación, el inicio, la detención, el reintento y la finalización manual del trabajo, las fusiones y fusiones forzadas, las anulaciones de controles, las aprobaciones de lanzamiento, los cambios en el Propietario o en los participantes de una conversación, así como los veredictos de los agentes de control de calidad y de Revisión y del coordinador.

Al aprobar y iniciar un plan, detener una tarea o volver a intentar ejecutar una tarea, el mensaje de confirmación solicita un motivo opcional de hasta 2.000 caracteres. Este se guarda junto con tu nombre en la procedencia del trabajo, y se muestra en las pull requests salvo que tu organización opte por usar únicamente enlaces. Una sola frase es suficiente: «Los clientes lo solicitaron antes de la campaña de primavera» transmite más información al siguiente lector que la mera aprobación. Para una fusión forzada ya se requiere un motivo por escrito, y este también se registra de la misma manera.

Decisiones automáticas#

Algunas decisiones se registran en nombre de otra persona en lugar de ser tomadas por ella. El contrato de entrega de una tarea del plan se aprueba automáticamente a partir del plan aprobado, y si un plan se aprueba sin intervención humana, su creador actúa como representante. La línea de tiempo etiqueta estas decisiones como "Automática" y nunca se consideran aprobaciones realizadas por personas.

Las decisiones tomadas por los agentes, como los veredictos de QA y de revisión, así como las decisiones del coordinador, aparecen bajo el nombre del agente junto con el resumen que proporcionó.

Añadir contexto a una tarea en curso#

Puede indicar algo a los agentes mientras una tarea se ejecuta, sin detenerla. Abra la pestaña Actividad de la tarea y seleccione "Añadir contexto" junto a la actividad en curso. Escriba lo que los agentes deben saber, hasta 2.000 caracteres, y confirme.

• Cuando un agente está en ejecución, leerá su mensaje en su siguiente turno. Un coordinador que esté esperando a otro agente se activará para leerlo.
• Si ningún agente está en ejecución, el próximo agente que inicie lo leerá.

El mensaje se registra en la procedencia de la tarea como una decisión de "Contexto añadido", con su nombre. No modifica lo que la tarea debe entregar: si su mensaje entra en conflicto con las especificaciones, el agente informará del conflicto en lugar de decidir en silencio. Para cambiar el resultado, modifique las especificaciones o envíe la tarea de nuevo como trabajo rechazado.

Para añadir contexto se necesita acceso de escritura al proyecto de la tarea. Las tareas completadas y canceladas no lo permiten.

Rastree el código hasta su trabajo correspondiente#

Puede partir de una línea de código y encontrar el trabajo que la generó. El portal, los agentes, los clientes MCP y Git le guiarán hasta allí.

¿Por qué está aquí?#

En la revisión de código de una tarea, cada fragmento que modifique líneas existentes tendrá este botón. Busca los commits que últimamente cambiaron esas líneas en la rama objetivo y muestra de dónde proviene cada uno:

• Creado por Coroid: la tarea o plan, con su intención, quién la solicitó y aprobó, las decisiones clave y un enlace a la procedencia completa.
• Creado fuera de Coroid: no existen registros de tarea o plan que expliquen por qué se realizó el cambio; por eso se muestra el autor y la fecha.

Un archivo que se añade con el cambio no tiene líneas anteriores, por lo que no tiene botón.

Con un agente o cliente MCP#

Los agentes y los clientes MCP formulan la misma consulta mediante una herramienta. Esta recibe un archivo y, si así lo deseas, un rango de líneas, además de una rama, etiqueta o confirmación. A continuación, devuelve cada rango de líneas junto con la confirmación que últimamente lo modificó. En el caso de una confirmación realizada por Coroid, también muestra la tarea o plan correspondiente y resume su procedencia. La herramienta se denomina explain_code.

• Agentes: Los agentes Desarrollador, Revisor y coordinador de Coroid lo utilizan antes de modificar o eliminar código cuyo propósito no está claro.
• Clientes MCP: se trata de una herramienta de lectura, por lo que requiere el rol de Revisor y este ámbito: mcp.read. Funciona únicamente en los proyectos a los que la conexión puede acceder y permite realizar 30 llamadas por minuto.

Con Git#

Cada commit que realiza Coroid incluye el nombre de su trabajo en los encabezados, por lo que Git también te lleva hasta allí:

git blame -L 120,120 src/search/alerts.ts   # the commit that last changed line 120
git log -1 <sha>                            # its Coroid-Task or Coroid-Plan trailer

Luego, abre esa tarea o plan en el portal para leer su procedencia:

• Tarea: https://client.coroid.ai/factory/task:<task id>?panel=provenance
• Plan: https://client.coroid.ai/factory/<plan id>#provenance

Para un commit de fusión o compactación, abre el pull request del que provino. Su sección de procedencia enlaza de nuevo a Coroid.

Exportar procedencia#

El panel cuenta con dos botones de descarga en la parte superior. El formato Markdown descarga la procedencia como un documento ordenado por resúmenes. Tiene el mismo formato que la sección de pull request, con las razones pero sin texto de conversación. JSON descarga el registro completo, incluidos los extractos de la discusión, para tus propios archivos o herramientas. Conserva el archivo JSON tan privado como la conversación que cita.

Origen no registrado#

Coroid registra la procedencia del trabajo creado después de la introducción de esta funcionalidad. El trabajo más antiguo muestra este mensaje en lugar de un origen:

Origen no registrado. Este trabajo se creó antes de que Coroid registrara la procedencia.

Cuando Coroid conoce un origen a partir de registros anteriores, como la conversación de la que provino un plan o el informe que lo respalda, el panel lo lista como origen conocido. Las decisiones ya registradas previamente, como las aprobaciones de documentos, siguen apareciendo; otras pueden estar ausentes.

Un origen etiquetado como "Derivado" fue reconstruido a partir de registros anteriores en lugar de capturarse cuando se creó el trabajo.

Relacionado#

• Tareas
• Planes
• Revisar y fusionar el resultado
• Asistente de chat
• Especificaciones
• Coroid como servidor MCP