Awesome CopilotAdventures

Documentación del producto verificada

La convergencia de los tres reinos

[!NOTE] Estado: Contenido listo · Multimedia: Portada generada e ilustración SVG original · Última verificación: 2026-09-05
Capacidad principal: Integrar agentes locales, en la nube y en runtime

Una mantenedora revisa artefactos entre un taller local, una ciudadela en la nube y una fundición de autómatas.

Ilustración conceptual original (SVG)

Desarrollo local, revisión en la nube, evaluación en tiempo de ejecución ilustrados a través de La Convergencia de los Tres Reinos.

[!TIP] Descarga este kit de aprendizaje y usa la guía de extracción y configuración. Mantén intacto el starter original.

---
config:
  theme: base
  look: classic
  themeVariables:
    darkMode: false
    background: "#ffffff"
    primaryColor: "#f5f5f5"
    primaryTextColor: "#111111"
    primaryBorderColor: "#555555"
    secondaryColor: "#e0e0e0"
    secondaryTextColor: "#111111"
    secondaryBorderColor: "#666666"
    tertiaryColor: "#bdbdbd"
    tertiaryTextColor: "#111111"
    tertiaryBorderColor: "#444444"
    lineColor: "#444444"
    textColor: "#111111"
    mainBkg: "#f5f5f5"
    nodeBorder: "#555555"
    clusterBkg: "#ffffff"
    clusterBorder: "#999999"
    edgeLabelBackground: "#ffffff"
    actorBkg: "#e0e0e0"
    actorBorder: "#555555"
    actorTextColor: "#111111"
    actorLineColor: "#777777"
    signalColor: "#333333"
    signalTextColor: "#111111"
    labelBoxBkgColor: "#f5f5f5"
    labelBoxBorderColor: "#777777"
    labelTextColor: "#111111"
    loopTextColor: "#111111"
    activationBkgColor: "#bdbdbd"
    activationBorderColor: "#555555"
    noteBkgColor: "#f5f5f5"
    noteTextColor: "#111111"
    noteBorderColor: "#777777"
    attributeBackgroundColorOdd: "#f5f5f5"
    attributeBackgroundColorEven: "#e0e0e0"
---
flowchart LR
    accTitle: Mapa de capacidades de La Convergencia de los Tres Reinos
    accDescr: La trazabilidad requiere tanto evidencia de implementación como de ejecución en tiempo de ejecución. Etiqueta las etapas no disponibles para que el revisor vea exactamente qué se ejecutó y qué no.
    A["Ask: hallazgos"] --> P["Plan: diseño"]
    P --> L["Implementación local: verificación"]
    L --> C["Trabajo en la nube: pull request"]
    C --> S["SDK: informe de evaluación"]
    C --> R["Revisión humana"]
    S --> R
    R --> D["Decisión con evidencia"]

Leyenda. Los cuadros son etapas responsables; las flechas llevan artefactos con nombre, no identidad compartida ni aprobación automática.

Explicación. La trazabilidad requiere tanto evidencia de implementación como de ejecución en tiempo de ejecución. Marca las etapas no disponibles para que el revisor vea exactamente qué se ejecutó y qué no.

Referencias oficiales

Estas fuentes oficiales son la autoridad sobre el comportamiento y la disponibilidad del producto. Vuelve a consultarlas cuando uses otra superficie o después de una actualización del producto.

Historia

El taller local, la ciudadela de la nube de GitHub y la fundición de aplicaciones convergen. La autoridad, los artefactos y la evidencia deben cruzar cada frontera de forma deliberada.

La fantasía es una ayuda para la memoria; la lección de ingeniería exige evidencia observable y reproducible.

Objetivos de aprendizaje

  • Mapea seis etapas ordenadas a actores, roles, harnesses, entornos y artefactos consumidos.
  • Mantén la revisión humana separada de la ejecución del agente y conserva la evidencia en cada transferencia.
  • Entrega un flujo de trabajo local trazable con observaciones opcionales de la nube y del SDK claramente etiquetadas.

Requisitos previos

Para preparar las herramientas y las cuentas personales, completa la guía de requisitos previos. Para estudiar solo desde el terminal, sigue la ruta de la CLI desde el kit extraído; la evidencia específica de VS Code sigue siendo independiente.

Requisito Por qué importa
Completar la aventura anterior, o demostrar su evidencia de salida Mantiene esta misión enfocada en su capacidad nombrada
Node 24 y el kit extraído El verificador local usa el runtime y los archivos suministrados
Una carpeta desechable fuera de otro proyecto Las personalizaciones y los fallos intencionales no deben filtrarse a otro trabajo
Acceso autorizado al host, solo para pasos en vivo La disponibilidad, las herramientas y las políticas difieren

Límite de evidencia: Completar el contrato del flujo de trabajo no es una entrega de producción. Registra las etapas de la nube y del SDK no ejecutadas como alternativas sobre papel, nunca como observaciones inventadas.

Tiempo estimado de la sesión: 45–75 minutos después de los prerrequisitos; la duración real varía. Nunca uses secretos de producción ni datos de clientes.

Explicación de conceptos

El proyecto final trata la ingeniería agéntica como un sistema con gobernanza. El primer reino es un harness local, como VS Code o Copilot CLI. El segundo es GitHub Copilot cloud agent. El tercero es una aplicación en ejecución creada con GitHub Copilot SDK. Cada uno tiene identidades, herramientas, entornos y evidencia diferentes. Los límites deben ser explícitos, la autoridad mínima, las capacidades en versión preliminar deben estar etiquetadas y las afirmaciones, fundamentadas.

Caso de uso concreto

Un desarrollador local, un trabajador en la nube y un agente de tiempo de ejecución incrustado tienen identidades y salidas distintas. El mantenedor final necesita tanto la evidencia de implementación como la evaluación en tiempo de ejecución antes de decidir.

Comprobación de vocabulario

  • Rol: Ask, Plan, Agent o un agente personalizado.
  • Harness/superficie: el entorno de ejecución o la superficie del producto en que opera un rol.
  • Destino: el destino de sesión seleccionado, como Local, Copilot o Cloud cuando se ofrecen.
  • Entorno: la carpeta, el worktree, la máquina local, el Codespace o el entorno remoto.
  • Instrucciones: contexto duradero que se aplica automáticamente.
  • Prompt: una plantilla de tarea invocada manualmente.
  • Skill: conocimientos reutilizables que se cargan cuando son pertinentes.
  • Agente personalizado: un rol con instrucciones, herramientas y transferencias opcionales.
  • MCP: Model Context Protocol.
  • Evidencia: una ruta, un diff, el resultado de un comando, una traza o una decisión de revisión.

Flujo de trabajo Ask → Plan → Agent

Ask — investigar

  1. Identifica el resultado real que busca el usuario y la fuente de verdad actual.
  2. Inspecciona los archivos, las instrucciones, las herramientas, los permisos y las comprobaciones existentes que sean relevantes.
  3. Cita rutas concretas o evidencia de la plataforma para cada hallazgo importante.
  4. Registra la incertidumbre y no deduzcas capacidades que no estén disponibles.

Punto de control: No implementes nada hasta comprender el estado actual y la evidencia.

Plan — diseñar

  1. Establece el alcance, los objetivos excluidos, las suposiciones, los riesgos y los límites de confianza.
  2. Selecciona el mínimo rol, herramientas, autoridad y entorno necesarios.
  3. Define los criterios de aceptación, los comandos de verificación, la revisión y el restablecimiento.
  4. Señala cualquier dependencia en versión preliminar o experimental y proporciona una alternativa.

Punto de control: Otra persona que esté aprendiendo debería poder anticipar qué significa completar el trabajo a partir del plan.

Agent — ejecutar

  1. Realiza el cambio reversible más pequeño o produce el artefacto planificado.
  2. Usa ciclos cortos de inspeccionar → cambiar → verificar.
  3. Conserva la salida de los comandos, el estado de salida, los diffs, las trazas o los registros de la plataforma.
  4. Detente cuando se cumplan los criterios de aceptación; no realices tareas de limpieza ajenas al alcance.

Revisión — cuestionar

  1. Inspecciona el diff o el artefacto completo.
  2. Compara cada resultado con el plan y los criterios de aceptación.
  3. Ejecuta la comprobación existente más específica que sea pertinente y amplía su alcance solo cuando esté justificado.
  4. Registra las limitaciones y los riesgos sin resolver.
  5. Puntúa el trabajo con rubric.md.

Misión guiada

1. Prepara una copia aislada

  1. Descarga y extrae el kit convergence-of-three-realms en un nuevo directorio de la unidad de trabajo.
  2. Lee KIT-START.md en su raíz. Abre starter/ como el workspace de VS Code al probar el descubrimiento, pero ejecuta el verificador desde la raíz del kit.
  3. Inspecciona starter/workflow.json, verify.js antes de editar.
  4. Desde la raíz del kit extraído, ejecuta node verify.js.
  5. Registra el rechazo documentado del starter. Un runtime faltante o un fallo no relacionado no es el resultado esperado del ejercicio.

2. Investiga y planifica

Comando de comprobación inicial listo para copiar, desde la raíz del kit extraído:

node verify.js

En Ask, solicita un rastreo de los archivos inspeccionados y de lo que el verificador observa realmente. Cuestiona cualquier afirmación sobre ejecución en vivo que no esté respaldada por la salida.

Usa este prompt de planificación:

Complete the six-stage contract using the supplied actor and artifact dimensions. Explain every consumes/produces edge, trust boundary and evidence item. Keep agent-only fields null for human review.
Do not implement yet. Identify affected files, the negative case and a safe reset.

3. Implementa el fragmento revisado

  1. Aprueba solo el artefacto starter nombrado y las pruebas enfocadas necesarias.
  2. Pide a Agent que implemente un solo fragmento; inspecciona los comandos propuestos antes de ejecutarlos.
  3. Ejecuta node verify.js otra vez desde la raíz del kit, o node ../verify.js desde starter/.
  4. Compara el resultado exacto con el punto de control de abajo y revisa el diff completo.
  5. Registra por separado el descubrimiento del host o la actividad en vivo cuando esté disponible. No habilites servicios extra para fabricar un resultado aprobado.

[!IMPORTANT] Punto de control: El grafo conserva, en orden, hallazgos, diseño, verificación, pull request, informe de evaluación y decisión humana. Completar el contrato del flujo de trabajo no es una entrega de producción. Registra las etapas de la nube y del SDK no ejecutadas como alternativas sobre papel, nunca como observaciones inventadas.

4. Demuestra que una comprobación puede rechazar un error

Asigna al agente de revisión humana un harness de agente y confirma que el verificador rechaza la confusión. Restaura el límite de revisión distinto.

Observación Decisión Acción Evidencia Limitación
Estado inicial y diagnóstico exacto Por qué se necesita este cambio Archivo nombrado y cambio acotado Comando, código de salida y resultado observado Lo que la comprobación local no demuestra

Termina con la evidencia de capacidad específica de la aventura en la rúbrica, no solo con la presencia de un archivo.

Fallo intencional: Los reinos colapsados

Haz esto únicamente en un entorno desechable:

Llama a cada participante «el agente» y después intenta asignar permisos y responsabilidades. La atribución se vuelve imposible porque se confunden las identidades de desarrollo, de la nube y de ejecución.

Recuperación

Vuelve a Ask, identifica el límite vulnerado, acota el plan, elimina la autoridad o el contexto innecesarios y repite la verificación pertinente más pequeña. Documenta la lección sobre las causas en lugar de limitarte a afirmar que el intento falló.

Desafío independiente

Entrega el proyecto final con una capacidad de la nube no disponible, usando una alternativa en papel claramente etiquetada que preserve los contratos y la evidencia.

Restricciones:

  • No copies literalmente la misión guiada.
  • No añadas herramientas, permisos ni recursos en la nube sin una necesidad declarada.
  • No afirmes calidad, rendimiento, compatibilidad ni disponibilidad sin evidencia obtenida mediante ejecución.
  • Mantén el lenguaje fantástico subordinado a la claridad técnica.

Lista de comprobación de evidencia

  • Hallazgos de Ask fundamentados en las fuentes.
  • Plan aprobado con alcance, objetivos excluidos, riesgos, comprobaciones y restablecimiento.
  • Diff o artefacto de Agent limitado al alcance declarado.
  • Salida de verificación con comando, estado o registro de la plataforma.
  • Causa raíz del fallo intencional y recuperación.
  • Resultado del desafío independiente.
  • Limitaciones explícitas y notas sobre el estado de las funciones.
  • rubric.md completada.

Instrucciones de restablecimiento

  1. Guarda tu diff, la salida del comando y las limitaciones del kit desechable.
  2. Detén solo el proceso o la sesión de aprendizaje que iniciaste. No detengas otros proyectos.
  3. Si inicializaste Git en el kit, inspecciona git status --short allí y restaura solo tus archivos de ejercicio nombrados desde su línea base local.
  4. De lo contrario, extrae el ZIP original en un nuevo directorio sin usar para otro intento; no sobrescribas tu trabajo actual.
  5. Elimina solo configuraciones, worktrees o recursos remotos propiedad del ejercicio después de revisar lo que valga la pena conservar.

La fuente del currículo y los demás proyectos deben permanecer sin cambios. Un restablecimiento de la copia del kit no es un reinicio completo del repositorio.

Siguiente aventura

Has completado el itinerario actual de aventuras. Revisa cualquier carencia de evidencia antes de aplicar este flujo de trabajo en producción.

Buscar

Búsqueda en español. Las rutas y los ejemplos ejecutables conservan el texto original.