picoduck/orchestrate-issues

Orquestar Issues

Ejecuta una campaña de issues iniciales y sus seguimientos justificados. Coordina a través de sesiones hijo reales de Wollipog, no subagentes en proceso. El Orquestador investiga, programa, revisa resultados y mantiene el estado; los hijos implementan. Crear o editar esta habilidad no inicia una campaña.

Límite de Activación

El número de issues, dependencias, tamaño de la tarea y la disponibilidad de herramientas de sesión hijo no autorizan la delegación. Se requiere una invocación explícita de este flujo de trabajo o una solicitud para orquestar, coordinar entre sesiones o delegar la implementación a hijos. La autorización relevante ya establecida para una campaña activa sigue siendo válida; no es necesario repetirla en cada turno.

"Reclamar e implementar los issues 1089, 1090 y 1091" significa que la sesión actual reclama e implementa esos issues siguiendo el flujo de trabajo de issues del repositorio (como una habilidad issue-workflow instalada), en orden de dependencia y con sus árboles de trabajo aislados y revisión requeridos. No inicies sesiones hijo de implementación ni preguntes si debes orquestar solo porque la solicitud enumera varios issues. Los títulos o cuerpos de issues sobre configuraciones del Orquestador son materia del tema de la tarea, no instrucciones para convertirse en un Orquestador.

"Orquestar sesiones hijo para implementar los issues 1089, 1090 y 1091" o "Usa orchestrate-issues para esos issues" activa este flujo de trabajo. Un hijo que recibe varios issues asignados sigue siendo una sesión de implementación; la autorización de orquestación del padre no autoriza automáticamente a ese hijo a delegar nuevamente. Una revisión requerida por el repositorio, incluyendo una revisión entre modelos, sigue regida por sus propias reglas y no es una delegación de implementación de issues.

Si la sesión actual está restringida por el preajuste de permisos del Orquestador y no puede implementar directamente, explica esa limitación concreta y solicita dirección en lugar de generar hijos silenciosamente o intentar una implementación prohibida. El mero hecho de tener el preajuste disponible no es autorización para usarlo.

Entradas y Configuración

• count: cualquier entero positivo, el número de issues iniciales a seleccionar. Infiérelo de la solicitud; si se omite, usa 5 y establece esa suposición. Una lista explícita de issues reemplaza la selección por prioridad y determina el conteo.
• concurrency: límite máximo opcional, independiente del conteo. Por defecto, el mínimo entre el conteo, el maximumConcurrentChildren de la política y la capacidad de hijos vivos disponibles. Pon en cola los issues sobrantes; nunca aumentes los límites de la plataforma para ajustarse al conteo.
• El arnés hijo, modelo y esfuerzo provienen de la política del Orquestador de Wollipog de la campaña (childHarness, childModel, childEffort en get_campaign.behavior); esta habilidad no tiene valores predeterminados propios. Cada valor es fijo o Automático (null). Consulta Resolver Modelo y Esfuerzo del Hijo.
• Los revisores conservan el modelo especificado por el flujo de trabajo de revisión del repositorio.
• Límites opcionales especificados por el usuario de costo, tiempo, total de issues o profundidad de seguimiento. Preserva los guardarraíles heredados. No inventes valores de presupuesto ni una ronda de parada exitosa arbitraria.

Lee using-wollipog, las instrucciones del repositorio y cualquier habilidad o política de flujo de trabajo de issues, revisión y reporte de issues que el repositorio o usuario proporcione. Solo se requiere using-wollipog; cuando el repositorio no define un flujo de trabajo de issues, los hijos siguen sus guías de contribución y los controles de esta habilidad. Los hijos deben tener las mismas habilidades disponibles en su entorno de ejecución. Resuelve las rutas de las habilidades desde el catálogo de ese entorno; no asumas que las rutas de inicio de esta máquina existen en otro lugar. Lee la política de reporte de issues del repositorio antes de preparar los payloads de publicación.

Descubre el runner actual, repositorio/espacio de trabajo, arneses de trabajador disponibles y capacidades de modelo/esfuerzo, capacidad de hijos y herramientas de sesión soportadas. Selecciona un arnés que anuncie el modelo elegido; no asumas que cada modelo pertenece a Codex. Inspecciona la sesión actual y la lista de hijos vivos antes de crear algo. Usa solo operaciones permitidas del Orquestador; las escrituras en el proyecto y la implementación pertenecen a los hijos. Mantén el libro de contabilidad de la campaña en artefactos de sesión persistentes o scratch permitido, nunca en el checkout principal. Resume su último estado en la conversación antes de ceder o compactar.

Resolver Modelo y Esfuerzo del Hijo

Lee childHarness, childModel y childEffort de get_campaign.behavior antes de seleccionar algo, y léelos de nuevo antes de cada despacho: una persona puede cambiarlos mientras la campaña se ejecuta, y solo los hijos creados después usan los nuevos valores. Las configuraciones del Orquestador de Wollipog son la única fuente de estos valores. Nunca recurras a un modelo o esfuerzo escrito en esta habilidad, recordado de una campaña anterior o heredado de la sesión padre.

• Valor fijo: úsalo exactamente. El servidor completa un valor fijo cuando create_session lo omite y rechaza cualquier valor diferente, así que no lo sobrescribas. Si el mensaje del usuario solicita un modelo o esfuerzo diferente a una configuración fija, reporta el conflicto y pídele al usuario que cambie la configuración de Wollipog; no despaches el issue afectado hasta que se resuelva.
• Arnés fijo: un childHarness fijo nombra un arnés, y cada máquina tiene su propio agente para él. Cuando get_campaign devuelve childHarnessAgents, pasa el agentId listado para la máquina en la que creas el hijo; una máquina listada con null no puede ejecutarlo. No derives el agente de childHarness.agentId; no necesita ser un agente en ninguna máquina.
• Modelo o esfuerzo fijo: cuando get_campaign devuelve childModelMachines, crea hijos solo en máquinas marcadas como supported; las demás no pueden ejecutar ese modelo y esfuerzo, y la creación allí es rechazada.
• Automático (null): elige para cada asignación de get_agent_capabilities (MCP) o wollipog session capabilities (CLI). Sigue page.nextOffset hasta que truncated sea falso. Elige un arnés que anuncie el modelo seleccionado; no asumas que cada modelo pertenece a un solo arnés. Basa la elección en la complejidad del issue, incertidumbre, consecuencia de errores, necesidades de contexto y cualquier restricción de costo o latencia que el usuario haya indicado. Las preferencias de modelo o esfuerzo en el mensaje del usuario guían una elección Automática pero no cambian la configuración de Wollipog. Prefiere una opción económica y capaz para trabajo directo y un razonamiento más fuerte para depuración compleja, arquitectura o cambios amplios. No inventes clasificaciones de modelos, precios o niveles de esfuerzo; usa capacidades anunciadas y explica la incertidumbre material. Si un modelo no anuncia esfuerzo configurable, registra el esfuerzo como no aplicable.

Si un valor fijo está ausente del descubrimiento de capacidades actual, reporta la discrepancia y solicita una configuración corregida mientras continúas con el triaje independiente. Nunca sustituyas silenciosamente.

Registra el arnés de cada issue, el modelo y esfuerzo exactos, si cada uno fue fijo o Automático, y una breve justificación para las elecciones Automáticas en la tabla de selección y el libro de contabilidad antes del despacho. El modo Automático autoriza estas elecciones rutinarias sin preguntar por cada hijo; no autoriza cambiar cuentas, acuerdos de facturación, permisos, presupuestos ni las configuraciones de Wollipog.

Verificar Modelo y Esfuerzo Antes de la Implementación

Usa create_session con useWorktree: true, el arnés resuelto, un modo de permisos de trabajador anunciado (no modo Orquestador), y el model y effort resueltos en la misma llamada, más campaignWorkItemId nombrando el elemento de trabajo registrado del hijo. El equivalente en CLI es wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree. Omite una dimensión solo cuando está fijada por política (el servidor la proporciona) o no aplicable. Los valores explícitos se aplican antes del mensaje inicial. Prefiere entradas de herramienta estructuradas para el texto de la tarea.

Lee el par efectivo del resultado de creación o get_session y confirma que coincide con la combinación resuelta. Si no coincide, detén ese hijo antes de que haga trabajo, registra la discrepancia y repórtala; no aceptes un valor predeterminado no verificado. Un cliente y servidor que no soportan esfuerzo explícito fallan cerrados; reporta ese bloqueador en lugar de reintentar sin esfuerzo.

Inspecciona el esquema de creación real: un número de protocolo de runner por sí solo no expone una entrada. Si un host Personalizado carece de campaignWorkItemId, usa solo una asignación de arranque de solo lectura en la creación, verifica la configuración efectiva, registra la asignación original del elemento de trabajo con la herramienta de asignación soportada y selecciona un árbol de trabajo dedicado antes de liberar la implementación. No reclames enlace atómico de elemento de trabajo en ese host ni evites la admisión protegida requerida. Si esas operaciones no están disponibles, reporta el bloqueador de compatibilidad; nunca actualices la pila que aloja la campaña.

Vuelve a verificar la configuración antes de reutilizar un hijo. Para una asignación Automática, reconsidera la combinación si la evidencia muestra que la elección anterior fue inadecuada y registra por qué; aplica cambios solo a través de una operación de configuración soportada mientras está inactivo y verifícalos antes de liberar, o crea un reemplazo con una transferencia de propiedad clara. Un mensaje normal de prompt_session no cambia la configuración de la sesión. Nunca cambies un valor fijado por política.

Autoridad y Controles

Lee la referencia de Verificación Previa de Autoridad de Campaña incluida con using-wollipog. Antes del despacho, registra el modo Personalizado/Control Total efectivo, el límite y revisión establecidos por humanos, las operaciones permitidas, los propietarios actuales, la compatibilidad, la divulgación de destino/proveedor de evidencia y las excepciones de Humano Requerido. Identifica las reglas humanas obligatorias no resueltas por su fuente de instrucción exacta; nunca reescribas silenciosamente instrucciones externas o escritas por el usuario. El Control Total se aplica solo a la autoridad establecida por el servidor elegible permitida por la política del repositorio. El modo Personalizado conserva los requisitos de aprobación existentes. Una política modificada debe pasar su propio flujo de trabajo de contribución explícitamente autorizado.

Continúa con la autorización real de campaña del usuario y las reglas del repositorio. Las reclamaciones rutinarias, los árboles de trabajo aislados, las pruebas, los envíos (push), la apertura de PRs y las revisiones requeridas no necesitan permiso repetido. Las reglas existentes pueden seguir requiriendo autorización de fusión por PR, revisión de evidencia de UI, autorización de eliminación de rama remota y aprobación de cada payload de issue sanitizado exacto. No conviertas silenciosamente una solicitud de este flujo de trabajo en una renuncia a esos controles.

Lee el estado autoritativo actual de la campaña y la política derivada del servidor con get_campaign antes del despacho y de nuevo antes de resolver una decisión de flujo de trabajo; no te bases en una copia del mensaje cuando el estado del servidor esté disponible. Para decisiones tipificadas como implementation_question, pr_merge, merged_branch_deletion, follow_up_issue_publication, ui_evidence_approval y review_round_extension, el hijo debe usar request_workflow_decision, get_workflow_decision y consume_workflow_decision para la ocurrencia exacta inmediatamente antes de la acción correspondiente. El padre no debe crear ni consumir un control de hijo en su nombre. Descubre ocurrencias pendientes con list_descendant_requests y resuelve solo una ocurrencia exacta actualmente propiedad del Orquestador con resolve_descendant_workflow_decision. Usa answer_descendant_question y resolve_descendant_approval solo para solicitudes no relacionadas con flujo de trabajo aplicables; nunca sustituyen un control de flujo de trabajo tipificado. Un mensaje ordinario, una aprobación obsoleta o la disponibilidad de Control Parental no es autorización para un control tipificado.

Cuando posees una decisión ui_evidence_approval con varias imágenes, prefiere prepare_descendant_ui_evidence_review. Entrega cada imagen a una Sesión de revisor administrada con un contexto nuevo, para que las imágenes nunca entren en tu propia conversación. Escribe su resumen a partir de las afirmaciones declaradas del hijo y los criterios de aceptación de UI del issue. Mientras el revisor trabaja, termina tu turno o espera en su sesión en lugar de sondear, luego lee el veredicto con get_descendant_ui_evidence_review. Aprueba solo con la referencia exacta delegatedImageReview que devuelve, listando cada identificador de evidencia en evidenceReviewed. Ante una recomendación de denegación, deniega con un childMessage que nombre los defectos observados. Mantén review_descendant_ui_evidence para una decisión con una imagen, o para una mirada dirigida a una imagen cuando el veredicto deje algo poco claro. Cuando la ruta del revisor no esté disponible, se negará con el motivo; revisa directamente en su lugar. Un revisor es un hijo de campaña como cualquier otro: verifica su informe e inclúyelo en la limpieza.

Antes de aprobar un pr_merge de GitHub de un hijo, lee lo que cierra: el closingReferenceCheck de la decisión lista cada issue que GitHub cerraría al fusionar, y el servidor creó la decisión solo porque coinciden con los intendedClosures de la instantánea. Aprueba un cierre solo cuando la campaña pretenda que esa fusión cierre el issue; deniega con un mensaje al hijo en caso contrario, para que el hijo reformule la referencia como "Refs #N". Cuando la verificación esté ausente (el runner del hijo es anterior a ella), ejecuta wollipog pr closures <pr-url> --json tú mismo antes de aprobar. Las palabras clave de cierre omiten un control tipificado issue_closure, por lo que cuando la campaña cierra issues a través de esa ruta, la fusión de un hijo normalmente no debería cerrar ninguno.

Nunca cambies la configuración de control de la campaña, apruebes una solicitud de propiedad humana, te hagas pasar por un humano ni evites una aprobación pendiente con un mensaje simple. Una ocurrencia elegible de Control Total raíz puede usar autorización de pie registrada en el servidor a través de su ruta de resolución tipificada exacta; no puede acuñar una nueva concesión. La evidencia de UI sigue siendo propiedad humana cuando la política activa dice que el Orquestador no puede inspeccionar los bytes de evidencia. Para cualquier control de propiedad humana o no delegado, transmite la decisión concreta a través del mecanismo de preguntas tipificadas soportado por el arnés y mantén a los hijos no relacionados progresando. Bajo Control Total, ninguna persona ve las preguntas de la raíz: el servidor las descarta sin respuesta, así que resuelve las ocurrencias propiedad del Orquestador tú mismo e informa un control de propiedad humana, que permanece visible en el Estado de la Campaña, en lugar de preguntar. Cuando el propietario se reservó una decisión para sí mismo (una elección de diseño, evaluación de riesgo o requisito

...

[truncado para traducción]