grahama1970/ask

¿Qué hace ask?

Detener Primero

Si el usuario nombra $ask, /ask, un modo ask, oráculo, revisión profunda, revisión de pares, mesa redonda, debate, revisión de brechas CAE o un DAG ask, lee este archivo completo antes de actuar. Luego usa el punto de entrada del runtime real a menos que el usuario solicite explícitamente un plan de respaldo o el runtime no esté disponible y ese respaldo sea reportado.

No sustituyas spawn_agent, una llamada de modelo simple, una búsqueda web simple, un resumen manual o una revisión inventada por $ask.

Punto de Entrada del Runtime

Ejecuta los comandos desde este directorio. La sintaxis de comando de habilidad de Pi como /skill:ask webgpt ¿Cuánto es 2 + 2? es un atajo de primera clase: el manejador de navegador principal (webgpt, webclaude, webkimi, webgemini o webgrok) se enruta a un DAG de manejador de navegador single-call de Tau con --execute --json. Las referencias en línea de habilidades de Pi como $ask webgpt ¿Cuánto es 2 + 2? y la ortografía en lenguaje natural con espacios $ask web gpt ¿Cuánto es 2 + 2? deben tratarse de la misma manera (web gpt se normaliza a webgpt). Esto es solo un atajo de compatibilidad para los usuarios de Pi; no debe usar la ruta de oráculo WebGPT directa eliminada.

./run.sh tau-dag "<solicitud>" se asigna internamente al subcomando tau-dag run de Typer. ./run.sh team-plan "<solicitud>" --team <preajuste> renderiza un plan multiagente basado en roles y una vista previa congelada del DAG de Tau; la ejecución requiere --execute --live explícito (ver README "Team Orchestration").

cd skills/ask
./run.sh --help
./run.sh webgpt ¿Cuánto es 2 + 2?
./run.sh webgpt --compile-only ¿Cuánto es 2 + 2?
./run.sh ask --help
./run.sh tau-dag run --help

Cada ejecución no trivial debe conservar los artefactos del runtime. El conjunto de artefactos estándar es:

• <ask_id>.request.json
• <ask_id>.status.json
• <ask_id>.events.jsonl
• Salidas específicas del modo como review.md, review.json, manifiestos DAG o evidencia del navegador

Los artefactos del runtime se ubican por defecto en .ask_artifacts/runs/<ask_id> o en la ruta proporcionada --run-output-root. Para ejecuciones largas, en vivo o generadas, prefiere una raíz respaldada por almacenamiento como /mnt/storage12tb/skills/ask/outputs/.... No confirmes artefactos de ask generados.

Cada llamada de manejador ejecutada (éxito o fallo) se registra en la colección ask_call_log en $memory en el punto de estrangulamiento de ejecución, con manejador, estado, código de fallo y controlled_tab_id/URL de conversación cuando esté presente, más el método probado de la última llamada exitosa (selección de razonamiento, enlace de pestaña, mode de ciclo de vida, comando de despacho con secretos redactados). Los ID de modelo se validan contra el catálogo de SciLLM en vivo en tiempo de compilación (invalid_scillm_model_id BLOQUEADO con las alternativas válidas más cercanas); un asiento de navegador con 3+ fallos consecutivos registrados se marca como conocido-malo antes del despacho con sus códigos de fallo. Verifica un asiento antes de confiar en él: python3 skills/ask/scripts/ask_call_history.py --handler webgemini imprime la última llamada exitosa y los fallos recientes; añade --recommend para el método probado exacto para reutilizar. Un manejador sin éxito registrado es una suposición ciega: primero compila solo o prueba de forma económica. Las ejecuciones históricas se pueden rellenar: python3 skills/ask/scripts/backfill_call_log.py [raíz-de-salidas] ingiere cada recibo de nodo en disco de forma idempotente (clave _key determinista por ejecución+nodo). Cada JSON de resultado de ejecución EJECUTADA (y execution-status.json) también lleva handler_last_success: por asiento, el último método exitoso de la memoria (URL de conversación, pestaña, ciclo de vida/diseño), fallos consecutivos actuales y códigos de fallo a evitar, devueltos en contexto para que el agente del proyecto nunca necesite una búsqueda de historial separada después de consumir una ejecución.

Referencias en Profundidad (leer bajo demanda)

Antes de hacer esto	Lee
team-plan con un archivo de plan; status --run --projection	references/plans-and-status.md
Objetivo explícito de subagente nativo de Pi	references/pi-subagents.md
Convertir salida ask (única/mesa redonda/competencia/sala limpia) en carriles de subagente	references/lane-handoff.md
herdr list/who/send al panel de otro agente	references/herdr.md
Elegir entre única vs mesa redonda vs competencia; selectores de modelo/esfuerzo	references/modes.md
Auditorías de panel, lista de asientos, asientos con límite de velocidad, política de webclaude	references/seats-and-audits.md
Ejecutar/supervisar cualquier ejecución en vivo (monitoreo, ventanas, matriz de carga, desbloqueo, desviación)	references/operations.md
Cualquier fallo de ejecución	references/diagnosis.md
Compilar/ejecutar cualquier DAG de múltiples asientos (mesa redonda/competencia/creador-revisor)	references/workflows.md
Cualquier ejecución de manejador de navegador	references/browser.md

Cuatro Tipos de Destino

/ask aborda cuatro tipos de destino pares. Se diferencian en el transporte, no en la categoría:

Destino	Ejemplo	Propietario del transporte
Sesión Herdr — un agente en vivo en un panel	memory, w11:p13	$monitor-herdr vía herdr pane run
Llamada de modelo — manejador de modelo/API	gpt-5.5-high, Codex-opus-5-high, deepseek-ai/DeepSeek-V3.2-TEE	$tau (SciLLM es interno a Tau)
Modelo web — revisor con respaldo de navegador (pestaña de chat, NO el modelo agéntico; ver la advertencia de webclaude a continuación)	webgpt, webclaude, webkimi	$surf + $browser-oracle
Subagente nativo de Pi — asesor/trabajador hijo local de Pi	pi reviewer, subagent general-purpose, local coder	Herramienta nativa subagent de pi-subagents

Un agente del proyecto no debería preocuparse por qué lado es navegador, modelo, sesión Herdr o subagente nativo de Pi más allá de nombrar el destino.

Inicio Rápido para Agentes del Proyecto

Comienza aquí cuando el usuario solicite una sola llamada de modelo, una mesa redonda, una competencia o un bucle creador-revisor. Usa una de estas formas; no inventes una ruta de orquestación personalizada.

Intención del usuario	Forma del comando
Un manejador responde	./run.sh tau-dag "<tarea>" --repo <repo> --target <objetivo> --immutable-goal "<meta>" --handler <manejador-o-modelo> --execute --json
Mesa redonda	./run.sh tau-dag "<tarea compartida>" --repo <repo> --target <objetivo> --immutable-goal "<meta>" --dag-template roundtable --handler <a> --handler <b> --topology concurrent --execute --json
Competencia	./run.sh compete "<tarea aislada>" --repo <repo> --target <objetivo> --immutable-goal "<meta>" --handler <a> --handler <b> --criterion <criterio> --execute --json
Única (respuestas por asiento, sin consenso)	./run.sh one-shot "<pregunta>" --handler <a> --handler <b> --handler <c> — N carriles independientes de llamada única se ejecutan concurrentemente; cada uno devuelve su propia respuesta vinculada a un nonce o un bloqueador nombrado. Las respuestas parciales son DEGRADADAS-pero-utilizables (salida 0 en o por encima de --min-answered); el rechazo por quórum de una mesa redonda nunca se aplica aquí.
Subagente nativo de Pi desde Pi	subagent({ action: "list" }), luego subagent({ agent: "<agente>", task: "<tarea>" }) o un workflowScript de abanico. Esto es solo para objetivos explícitos de pi/subagent/local reviewer; no es un reemplazo para los manejadores de Tau/navegador.
Creador luego revisor	./run.sh tau-dag "<tarea del creador luego veredicto del revisor>" --repo <repo> --target <objetivo> --immutable-goal "<meta>" --dag-template creator-reviewer --handler <creador> --handler <revisor> --topology sequential --execute --json
Diagnosticar/arreglar/cerrar issues de GitHub	./run.sh fix-issues --repo <dueño/nombre> --issue <N> [--issue <M>] [--handler gpt-5.5] [--execute] — recopila cada issue vía gh, diagnostica a través de un manejador de llamada única en vivo en JSON estructurado de causa/arreglo con la puerta de depurador (needs_debugger recomienda $debugger solo cuando la transición fallida es un estado de runtime en proceso que ningún artefacto explica), y falla cerrada: por defecto en seco; --execute cierra un issue SOLO después de que su comando de verificación nombrado (típicamente un fixture de $agentic-evals) realmente pase. Sin verificación → blocked; verificación fallida → verify-failed, el issue permanece abierto. Recibos por issue en outputs/fix-issues/. Puerta: fixtures/fix_issues.json.

Los manejadores son pares incluso cuando sus transportes difieren. Los manejadores de navegador (webgpt, webclaude, webkimi, webgemini, webgrok) se ejecutan a través de $surf y $browser-oracle. Los manejadores de API/modelo como gpt-5.5-high, gpt-5.5-xhigh, Codex-opus-5-high o chutes deepseek-ai/DeepSeek-V3.2-TEE son enrutados por Tau. Los agentes del proyecto no deberían preocuparse por qué lado es navegador o API más allá de nombrar el manejador.

Los manejadores son pares ya sea que tengan respaldo de navegador (webgpt, webclaude, webkimi, webgemini, webgrok vía $surf/$browser-oracle) o respaldo de API (gpt-5.5-high, claude-opus-5-high, chutes <proveedor/modelo> vía Tau). Antes de ejecutar cualquier DAG de múltiples asientos: compila primero (omite --execute), muestra el gráfico ASCII impreso al humano y ejecuta solo con confirmación. Ejemplos de modos completos y reglas de selección: references/modes.md. Protocolos completos y tablas de fallo cerrado: references/workflows.md.

No Negociables para Cada Ejecución

• Se requiere una meta inmutable explícita (--immutable-goal o una línea etiquetada Immutable goal:) para mesa redonda, creador-revisor y competencia; la meta faltante falla la verificación previa con NEEDS_INTERVIEW antes de contactar a cualquier manejador.
• Las mesas redondas SIEMPRE son --topology concurrent con un paquete idéntico para cada asiento. Los candidatos de competencia están aislados y nunca se ven entre sí.
• Los DAG ejecutados deben ser monitoreados hasta un veredicto terminal a través de los artefactos de flujo JSON de la ejecución (events.jsonl, dag-progress.json, recibos de nodo, execution-status.json); no los inicies y te vayas.
• PASS es solo evidencia del revisor/modelo; el cierre local requiere prueba local determinista. DEGRADED/NEEDS_ATTENTION/límites de velocidad son por carril: mantén los asientos utilizables, sigue el paquete de recuperación del carril fallido.
• Las finalizaciones de API no transmitidas deben pasar una admisión tipificada con finish_reason=stop antes de que su texto pueda contar como evidencia. Las finalizaciones truncadas, filtradas, sin motivo de finalización o mal formadas emiten scillm_response_incomplete; conserva los bytes brutos y los errores de validación de response.meta.json. No repares texto de veredicto parcial ni reintentes automáticamente. Casos retenidos: completion-admission-rejects-truncation (repetición capturada) y completion-admission-live-positive (lectura real del proveedor).
• Los fallos no son silenciosos: cada carril fallido expone failure_code, un paquete de recuperación y una instrucción next_command/ticket. Ante cualquier fallo, lee references/diagnosis.md y despacha en el recibo propietario antes de teorizar.
• El enrutamiento directo del oráculo WebGPT ($ask chatgpt, --oracle-backend webgpt, --webgpt-*) falla cerrado; los manejadores de navegador de Tau siguen siendo compatibles.
• Continuidad de seguimiento: el recibo de nodo / response.meta.json de cada carril de navegador debe llevar controlled_tab_id y la URL de conversación; un id de pestaña nulo es una transferencia fallida. Cuando el humano pueda hacer preguntas aclaratorias o de seguimiento, ejecuta con --browser-tab-lifecycle fresh-keep (o reuse-bound) — el valor predeterminado auto/fresh-temporary CIERRA la ventana después de la ejecución, matando la conversación. Después de la ejecución, reporta el id de pestaña + URL de conversación y enlázalos (skills/browser-oracle/run.sh bind <proyecto> --backend <b> --tab-id <id> --url <url> --manual) para que el seguimiento se dirija a la misma sesión.
• Puerta de visibilidad de pestaña (observado 2026-09-15, webgemini): algunos proveedores (Gemini confirmado) difieren el envío del compositor mientras la pestaña es un documento oculto; en una ventana compartida solo una pestaña puede estar al frente, por lo que N-1 de N carriles concurrentes siempre están ocultos y se estancan como prompt_too_large_or_stalled ("el prompt permaneció en el compositor después del envío"). Los carriles de navegador concurrentes, por lo tanto, predeterminan ventanas aisladas (una ventana por asiento, colocadas en el escritorio del revisor) para que cada pestaña de carril sea un documento visible; --window-layout shared es optativo. Un compositor estancado que ya ha escrito se puede recuperar: skills/surf/run.sh tab.switch <id> hace visible la pestaña y el envío en cola se despacha. Verifica document.visibilityState antes de reducir los prompts para esta clase de fallo. El método de trabajo verificado por asiento está almacenado en $memory (clave ask_call_log ask:method:webgemini; ver ask_call_history.py --handler webgemini --recommend).
• webclaude es una pestaña de chat de claude.ai, solo para pruebas — NO es Claude agéntico. Prefiere claude-fable-low, luego claude-opus-4-8-high (ver references/seats-and-audits.md).

Enrutador de Modos

Usa el modo más específico que coincida con la solicitud del usuario.

Solicitud	Patrón de runtime	Detalles requeridos
Pregunta con respaldo de memoria	./run.sh ask "<pregunta>" --json	Incluye el alcance cuando sea relevante.
Respuesta de oráculo	./run.sh ask "<pregunta>" --oracle ... --json	Elige backend/modelo/persona explícitamente cuando se solicite.
Atajo de manejador de navegador Pi	./run.sh webgpt ¿Cuánto es 2 + 2? desde /skill:ask webgpt ¿Cuánto es 2 + 2?	Reescribe a Tau single-call con --handler webgpt --execute --json; usa --compile-only para emitir el DAG sin transporte de navegador en vivo.
Manejador único nombrado	./run.sh tau-dag "<solicitud>" --handler <manejador-o-modelo> --json	Los manejadores de navegador usan $surf; los manejadores que no son de navegador son nombres de modelo $scillm enrutados por Tau. Añade --execute para transporte en vivo.
Objetivo de subagente nativo de Pi	Herramienta nativa subagent de Pi, después de subagent({ action: "list" })	Solo cuando se ejecuta dentro de Pi y el usuario nombra explícitamente pi, subagent, pi-subagent, local reviewer o local coder. Las solicitudes de navegador/modelo/Tau Ask no usan esta ruta.
Mesa redonda con múltiples manejadores	./run.sh tau-dag "<solicitud>" --handler webclaude --handler gpt-5.5 ... --topology concurrent --execute --json	La mesa redonda es de prompt a DAG de Tau. Los manejadores de navegador obtienen una ventana nueva propiedad de Ask por defecto. Conserva browser-tab-lifecycle.json, dag.json, especificaciones de comando, recibos de manejador y recibos de unión.
Competición / bakeoff	./run.sh compete "<tarea>" --handler webgpt --handler webclaude --handler gpt-5.5-high --criterion deterministic-proof --execute --json	Candidatos aislados más tarjeta de puntuación de competencia y solicitud de continuación del ganador. Los manejadores de navegador/API son pares. El agente del proyecto debe verificar las características localmente antes de la promoción.
Bucle creador-revisor	./run.sh tau-dag "<tarea del creador> ... <veredicto del revisor>" --repo <repo> --target <objetivo> --immutable-goal "<meta>" --dag-template creator-reviewer --handler <creador> --handler <revisor> --topology sequential --execute --json	Secuencial obligatorio. La meta inmutable es obligatoria.