Los artefactos de GitHub Issues dan un lugar estable a los planes
El código queda en el pull request, pero su motivo puede perderse en un chat antiguo. Si la investigación de un agente está en otro lugar, quien retome la tarea quizá la repita. El 28 de octubre GitHub presentó la vista previa pública de artefactos asociados directamente a un issue.
La conversación y el documento cumplen funciones distintas
Un artefacto puede ser un documento Markdown, un enlace externo o un documento HTML: análisis de causas, prototipos o conversaciones de Slack y Teams. En github.com se pueden crear y editar conservando versiones. No son los artefactos de GitHub Actions, que corresponden a resultados de ejecuciones de workflows.
Imaginemos un pago procesado dos veces. Los comentarios recogen observaciones nuevas y el plan reúne la clave usada en los reintentos y las pruebas pendientes. La primera imagen es un ejemplo inventado para este artículo, no una captura de GitHub. Separar observaciones e hipótesis evita presentar una suposición como requisito confirmado.
Adjuntar un archivo y seguir manteniéndolo
gh issue artifact create acepta un número o URL de issue y archivos o enlaces. gh issue artifact create 42 retry-plan.md -R OWNER/REPO adjuntaría el archivo al issue 42. Son valores de ejemplo; ejecutarlo crea contenido en el issue. No lo ejecutamos para este artículo.
El nombre puede proceder del archivo o indicarse con --name. --body-file lee el contenido de un documento y --attach permite adjuntar imágenes y vídeos. gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO reemplaza el contenido. La segunda imagen ilustra sintaxis, no una carga ejecutada con éxito.
Conservar el plan actual y su historia
edit cambia el nombre o contenido, pero no el tipo. --restore-version guarda el nombre y contenido antiguos como una versión nueva; view muestra el historial. Así se puede mantener un plan vigente sin borrar su evolución.
En el ejemplo del pago, la investigación podría pasar de sospechar un timeout a revisar claves duplicadas. Actualizar el plan y enlazar un comentario con la explicación es una propuesta de trabajo, no una automatización prometida. El documento tampoco sustituye las pruebas del código.
HTML tiene límites según la superficie
El anuncio permite alternar entre vista renderizada y código fuente de HTML. Sin embargo, crear y ver HTML en GitHub App figura como función futura. La asociación automática de resultados de sesiones no implica soporte completo de HTML en todas partes. La CLI también sigue en vista previa.
Lo valioso es encontrar el contexto junto al issue. Un plan existente y su siguiente revisión bastan para explorar el flujo. Consulta el anuncio y la documentación actual para conocer sus límites.