Development Context and Execution Records

Por qué conservar evidencia de desarrollo

Un Development Context and Execution Record conserva información durable sobre trabajo de desarrollo realizado: objetivo, contexto pertinente, decisiones, cambios, comprobaciones e incertidumbres. Es una definición de trabajo del Atlas, no un estándar formal ni un schema obligatorio. Su propósito es permitir revisión y continuidad con evidencia suficiente, sin preservar necesariamente todo lo ocurrido durante la ejecución.

El problema aparece cuando una tarea termina o pasa a otra sesión y la explicación disponible se reduce a «listo». El diff muestra cambios, pero puede no explicar qué se intentó, qué prueba no pudo ejecutarse o qué decisión sigue abierta. Un registro útil conecta esas observaciones con el encargo y evita que el próximo participante deba reconstruirlas desde fragmentos dispersos.

Conservar tampoco equivale a acumular. Un transcript completo puede contener material repetido, sensible o irrelevante. Un resumen breve puede omitir una restricción decisiva. El valor depende de seleccionar evidencia pertinente y preservar su procedencia y límites. No se necesita diseñar una base de datos o un sistema de memoria para registrar responsablemente el resultado de una tarea.

Active Context vs Durable Record

El contexto activo es información disponible para decidir durante una ejecución. Un registro durable es información conservada que puede recuperarse después. Parte del registro puede incorporarse al contexto de otra tarea, pero no está automáticamente cargada, vigente o completa. context-engineering-for-software-development trata esa selección y renovación.

Una sesión puede conocer un fallo reciente que todavía no quedó registrado; un documento puede conservar una observación que ya dejó de ser actual. Por eso interesa señalar revisión, entorno o momento cuando condicionan la evidencia. Recuperar el registro ayuda a orientarse, pero no congela el repositorio ni demuestra que un resultado siga siendo reproducible tras cambios posteriores.

Development Context no significa aquí un contenedor universal de estado. El foco es conservar información pertinente sobre el trabajo junto con su evidencia de ejecución. No se redefine Context Engineering ni se supone que todo dato durable deba llegar al prompt. La continuidad mejora cuando el receptor puede localizar y contrastar las fuentes necesarias para su próxima decisión.

Objetivo y procedencia del encargo

El registro puede identificar qué se pidió, dentro de qué scope y con qué condiciones de terminación. task-prompts conserva el encargo como artefacto comunicativo; el registro documenta qué ocurrió respecto de él. Si el usuario aclaró una decisión durante la tarea, puede importar conservar esa modificación de alcance junto con su procedencia.

También conviene distinguir fuentes: instrucción humana, documento de repositorio, resultado de herramienta, referencia externa e inferencia del agente. Una hipótesis no se vuelve requisito porque aparezca en el resumen final. Una respuesta de otra ejecución sigue necesitando interpretación. La atribución ayuda a detectar dónde falta evidencia sin conceder autoridad adicional al material registrado.

El registro no necesita revelar razonamiento privado ni una cadena de pensamiento interna. Puede comunicar decisiones, alternativas relevantes y evidencia observable con una explicación adecuada para revisión. Pedir una justificación del cambio es diferente de exigir reconstruir cada inferencia interna. El objetivo es comprender el trabajo y sus límites, no producir una transcripción exhaustiva del proceso cognitivo.

La procedencia puede ser incompleta. Si una observación llega mediante un resumen sin acceso a su fuente, conviene conservar esa limitación en lugar de atribuirle una verificación directa. Los intentos fallidos también pueden ser útiles cuando evitan repetir una operación o explican por qué se eligió otra ruta; no hace falta conservar cada paso irrelevante de exploración.

Decisiones y cambios

Una decisión útilmente registrada conecta problema, opción elegida y razón pertinente. Puede explicar que se reutilizó una validación existente para conservar el contrato, o que una alternativa quedó pendiente por requerir una decisión del equipo. No toda decisión necesita un ADR; los cambios arquitectónicos durables conservan sus mecanismos de documentación cuando corresponda.

El diff muestra modificaciones concretas y permite contrastar la narración. El registro puede identificar archivos o revisión para ubicarlo, sin duplicar todo el patch. Si hay trabajo ajeno en el mismo workspace, importa separar lo realizado por la tarea de lo que ya estaba presente. Un reporte que atribuye todo el estado local al agente puede inducir una revisión incorrecta.

También puede haber un resultado valioso sin cambios de código. Investigar una falla puede demostrar una configuración inválida o descartar una hipótesis. Ese trabajo merece evidencia y límites, aunque no produzca un commit. Por el contrario, tener muchos archivos modificados no demuestra que se haya alcanzado el objetivo solicitado.

Evidencia de verificación

Solicitar una prueba y ejecutarla son hechos distintos. Ejecutarla y obtener éxito tampoco equivale a cubrir todo el comportamiento relevante. Un registro útil conecta comando o comprobación, revisión del código, entorno, resultado y alcance de la evidencia. El detalle necesario depende del riesgo y del tipo de cambio.

Estado de comprobación	Interpretación que debe conservarse
No ejecutada	No hay evidencia de ese resultado.
Ejecutada con fallo	Ocurrió un fallo que requiere diagnóstico.
Ejecutada con éxito	Pasó lo comprobado bajo esas condiciones.
Inconclusa	La observación no permite decidir la condición esperada.
Pendiente / bloqueada	Existe una comprobación identificada todavía sin cierre.

Un fallo de preparación puede impedir observar el comportamiento del código. No corresponde declararlo una regresión confirmada ni convertirlo en una prueba verde. Un test exitoso puede ser insuficiente si no ejercita la condición solicitada. El reporte necesita conservar esas diferencias en vez de reducir toda evidencia a un único estado de «completado».

Para cambios revisables, las referencias a logs o ejecuciones ayudan cuando son accesibles y pertinentes. No hace falta copiar miles de líneas. Puede bastar el comando exacto, su resultado y una ubicación durable del detalle, con datos sensibles tratados apropiadamente. Una URL temporal que dejará de estar disponible puede necesitar una síntesis mínima que conserve el hecho relevante.

Incertidumbre y trabajo incompleto

Registrar incertidumbre permite distinguir lo observado de lo inferido. «La consulta devuelve este error» es una observación; «probablemente falta un permiso» es una hipótesis. Si no se pudo comprobar la causa, el siguiente participante necesita saberlo. Un tono seguro no agrega evidencia y un resumen muy pulido puede ocultar el supuesto más importante.

Trabajo incompleto no significa automáticamente ejecución fallida. Una investigación autorizada puede terminar al identificar una decisión comercial pendiente. Una modificación puede estar lista para revisión sin autorización de publicación. El registro debe explicar qué resultado existe, qué falta y qué condición permitiría continuar. No debe ampliar el objetivo para producir una apariencia de cierre.

Las acciones con resultado desconocido merecen precisión. Si una operación externa pudo haberse aplicado antes de perder respuesta, no es equivalente a «no ejecutada». agent-harness conserva esa distinción de integración. El registro puede evitar una repetición indebida al señalar la incertidumbre y la comprobación necesaria antes de reintentar.

Record vs Memory y Trace

Memory es un mecanismo o capacidad de conservar y recuperar información entre momentos o ejecuciones. Un registro puede ser una de sus fuentes, pero no implementa por sí mismo selección, recuperación o actualización. Guardar un resumen en un repositorio no garantiza que el agente siguiente lo lea ni que identifique información obsoleta.

Una trace representa eventos de ejecución con el nivel de detalle de la instrumentación. Puede alimentar un registro revisable, pero no equivale a una explicación del trabajo. Una secuencia de llamadas no muestra automáticamente por qué el cambio satisface una necesidad. A su vez, un resumen final puede omitir eventos sin ser incorrecto si conserva la evidencia necesaria para su propósito.

Como ejemplo de implementación, Codex App Server documenta eventos de ejecución. Esos eventos pueden aportar observaciones a herramientas de seguimiento. Su existencia no define un estándar universal de Development Records ni convierte todo evento en evidencia suficiente de éxito. La selección y la interpretación siguen requiriendo relación con el encargo.

Record vs Plan, Checkpoint y Git Commit

Un plan describe trabajo previsto; el registro describe lo realizado y lo que quedó abierto. El plan puede conservarse como referencia, pero una lista marcada no demuestra que sus acciones ocurrieron. Cuando la investigación cambia el recorrido, interesa explicar la diferencia pertinente, sin presentar el plan inicial como historia exacta de la ejecución.

Un checkpoint preserva estado recuperable según el mecanismo utilizado. Puede ayudar a retomar, pero no necesariamente explica decisiones o comprobaciones. Un registro puede referenciarlo sin contener todo ese estado. Recuperar un checkpoint y comprender qué queda por hacer son responsabilidades relacionadas que necesitan información diferente.

Un Git commit conserva una instantánea de cambios versionados y su lugar en la historia. No contiene automáticamente resultados de tests, estado externo o autorizaciones. El mensaje puede resumir intención y el SHA puede identificar la revisión comprobada; aun así, el commit no prueba que una pipeline haya pasado. La documentación de Git sobre commits permite situar ese artefacto sin atribuirle evidencia que no conserva.

Artefacto	Pregunta principal	Límite respecto del registro
Contexto activo	¿Qué información está disponible ahora?	Puede ser transitorio.
Memory	¿Qué se conserva y recupera entre momentos?	Es un mecanismo, no un reporte de tarea.
Trace	¿Qué eventos se observaron?	No explica por sí sola el resultado.
Plan	¿Qué se pretende hacer?	Intención no demuestra ejecución.
Checkpoint	¿Qué estado puede recuperarse?	Recuperación no equivale a evidencia interpretada.
Git commit	¿Qué cambios versionados identifica esta revisión?	No incorpora todo el contexto de ejecución.

Handoffs

Un handoff de contexto útil comunica objetivo, scope, estado actual, fuentes, decisiones abiertas y siguiente acción razonable. persistent-instructions puede indicar guía que sigue siendo aplicable; el registro señala dónde localizarla. agent-handoffs trata la transferencia de responsabilidad o control: el registro puede aportar información para ella sin realizarla por sí mismo. No hace falta copiar todas las instrucciones ni todos los logs para que el receptor pueda continuar con criterio.

Transferir información no transfiere automáticamente autoridad. Un resumen que dice «publicar después» necesita la autorización vigente del encargo y los controles efectivos. Tampoco preserva por sí mismo credenciales o aprobaciones interactivas. agent-permissions-and-approval-boundaries conserva esa frontera. Una ejecución receptora debe revalidar los supuestos de los que depende su siguiente acción.

El handoff de contexto puede quedar obsoleto si alguien modifica el workspace. Por eso es útil identificar revisión y cambios locales cuando afectan la continuidad. Si el receptor encuentra una diferencia, debe investigarla antes de descartar trabajo o repetir acciones. El registro orienta la recuperación; no autoriza resetear el entorno para que vuelva a coincidir con una narración anterior.

Seguridad, privacidad y mantenimiento

Los registros pueden contener rutas, datos de negocio, prompts, respuestas de herramientas o identificadores sensibles. Conservar todo sin selección puede aumentar exposición sin mejorar revisión. Importa limitar el contenido a lo necesario y aplicar controles de acceso, redacción y retención adecuados al contexto. No se prescribe aquí una política legal universal.

Un secreto no debería copiarse al resumen para demostrar que una herramienta lo recibió. Puede registrarse la condición relevante sin revelar el valor. Las referencias externas también necesitan cuidado si su destino no comparte la misma autorización. Un registro público y uno privado tienen fronteras distintas; la utilidad de una evidencia no elimina esas restricciones.

El registro puede requerir actualización o una aclaración posterior si cambian hechos importantes. No corresponde reescribir silenciosamente evidencia histórica para simular que siempre fue correcta. Cuando se conserva como parte de una historia, distinguir observación original y corrección ayuda a interpretar decisiones. La forma concreta depende del equipo y de sus necesidades de trazabilidad.

Relaciones y fuentes

generated-code-verification utiliza procedencia y resultados para sostener afirmaciones sobre un cambio; coding-agent-failure-modes-and-recovery puede recuperar contexto o distinguir acciones reales de afirmaciones sin evidencia. El registro facilita ambas actividades, sin constituir por sí solo verificación ni requerir razonamiento privado del modelo.

ai-assisted-implementation-and-change-maintenance utiliza estos registros para distinguir cambios, checks ejecutados y dudas pendientes. ci-failure-investigation-and-release-assistance necesita vincular ejecución, revisión y artefacto; workspace-isolation-for-coding-agents agrega la base y copia de trabajo pertinentes al handoff. Conservar esas referencias facilita revisión y continuidad sin convertir el registro en prueba de corrección.

coding-agent puede producir evidencia de trabajo delegado. agent-skills, agent-profiles, lifecycle-hooks y agent-extension-packages pueden intervenir en la ejecución sin que sea obligatorio listar todos en cada reporte. ai-assisted-software-engineering conecta estos artefactos con generated-code-verification y la continuidad del trabajo. Este documento no crea un formato real de registros, una base de memoria ni automatización de captura.

Fuentes primarias consultadas el 2026-10-26. El concepto, los campos posibles, matrices y criterios de selección son síntesis editorial del Atlas. No se atribuye un estándar común a los productos.

• OpenAI: Codex App Server, ejemplo de eventos y estado de ejecución.
• Git: git-commit, responsabilidad del artefacto versionado.