ask-navigator

Ask Navigator (Navegador)

Ask-navigator es el navegador del astillero: toma un esfuerzo envuelto en niebla — el camino desde aquí hasta el destino aún no es visible — y lo traza como un mapa de tickets de decisión en el gestor de incidencias del repositorio, luego trabaja en la frontera un ticket por sesión hasta que la ruta esté clara. Produce decisiones, nunca entregables: cuando el camino está despejado, pasa el testigo, no construye. La entrega pertenece a /oh-my-claudecode:launch.

El contrato de roles. El capitán (el humano) firma el destino (W1) y la carta (W2); el navegador redacta todo lo demás y nunca responde una pregunta que pertenezca al capitán — una sesión de interrogatorio en la que el agente responde sus propias preguntas ha roto el rol, no solo el proceso. Los hechos son trabajo del navegador; las decisiones son del capitán.

Prueba de niebla. Un esfuerzo tiene niebla cuando cualquiera de las respuestas es no:

1. P1 — ¿El destino se puede enunciar en una frase: la especificación, decisión o cambio al que este esfuerzo está encontrando el camino?
2. P2 — ¿Se pueden enunciar con precisión las tres primeras decisiones ahora mismo, aunque ninguna de ellas pueda responderse todavía?

Ambos sí → no se necesita mapa; ejecuta /oh-my-claudecode:launch (su puerta de niebla envía los esfuerzos aquí solo cuando una respuesta es no). Cualquier no → traza primero. ask-navigator también se puede alcanzar directamente: invócalo con una idea vaga, con preguntas residuales entregadas por la puerta de niebla de launch, o sin argumento para continuar el mapa abierto.

Hogar del mapa

El mapa es un único issue etiquetado navigator:map en el gestor de incidencias del repositorio; sus tickets de decisión son issues hijos del mapa. El gestor debería haber sido registrado por /oh-my-claudecode:drydock; si no se registró ninguno, pregunta una vez (GitHub / GitLab / markdown local) y recuerda la respuesta dentro de las Notas del mapa.

• Con gestor (GitHub, GitLab, o gestor registrado): un issue de mapa, issues hijos por ticket, relaciones nativas de bloqueo/sub-issue. Las sesiones concurrentes y la interfaz del propio gestor renderizan la frontera — el mapa vive donde los humanos ya miran. Crea la etiqueta navigator:map si el gestor aún no la tiene; los tipos de ticket viven en el cuerpo del ticket, no en las etiquetas.
• Alternativa markdown local: .omc/wayfinder/<slug-del-mapa>/map.md más decisions/NN-<slug>.md, un archivo por ticket, numerados en orden de dependencia. El modo local no tiene garantía de reclamo concurrente: es un solo conductor por convención, indicado una vez en las Notas del mapa.

El mapa es un índice, no un almacén: una decisión vive en un único lugar — su ticket. El mapa resume cada resolución en una línea y enlaza; nunca vuelve a exponer el detalle.

Idioma del documento

La prosa del mapa y los tickets sigue el mismo contrato de idioma que /oh-my-claudecode:drydock: lee documentLanguage del frontmatter de CONTEXT.md cuando esté presente; si el astillero no está dispuesto, pregunta la cuestión del idioma una vez durante el trazado (W2) y registra la etiqueta resuelta en las Notas del mapa para que la ejecución posterior de launch la herede. Las rutas, etiquetas, comandos slash, la etiqueta navigator:map, los nombres de tipos de ticket (research, loft, grilling, task), HITL/AFK y blockedBy son tokens estables y permanecen byte por byte estables en todos los idiomas.

Trazar el mapa

Se invoca con una idea vaga (o las preguntas residuales de launch). Trazar es trabajo de una sesión; no resuelve nada manualmente.

1. Ejecuta la auditoría, aplaza los hallazgos. Ejecuta la auditoría /oh-my-claudecode:drydock --check en modo solo informe: los hallazgos nunca bloquean el trazado (un mapa produce decisiones, no aterrizajes de ranuras), pero se registran textualmente en las Notas del mapa — la puerta del astillero de launch cobrará esa deuda cuando el esfuerzo finalmente entre en entrega. Si el astillero no está dispuesto en absoluto (sin CONTEXT.md, sin docs/adr/), ofrece /oh-my-claudecode:drydock una vez; si el capitán declina, procede en modo solo gestor y aplaza todo el sedimento (ver Sedimento).
2. W1 — nombra el destino. Llama a la herramienta Skill con "deep-interview" y concreta a qué se dirige este mapa: la especificación, decisión o cambio. El destino fija el alcance, por lo que se resuelve primero. W1 es una firma del capitán: presenta la declaración de destino y obtén confirmación explícita. Si el capitán no puede enunciar un destino incluso con la ayuda de la entrevista, eso no es un error — presenta los mejores candidatos ordenados y deja que el capitán elija uno para trazar hacia él o aparcar el esfuerzo.
3. Traza la frontera. Entrevista de nuevo con "deep-interview", en anchura: explora todo el espacio en lugar de profundizar en un solo hilo, sacando a la luz las decisiones abiertas y los primeros pasos que se pueden dar ahora. Si esto no revela niebla — el camino hacia el destino ya está claro y el recorrido cabe en una sesión — no se necesita mapa: detente y recomienda /oh-my-claudecode:launch.
4. W2 — firma la carta. Presenta el mapa propuesto: destino, tickets iniciales con tipos y bordes de bloqueo, y el boceto de niebla. W2 es una firma del capitán: una granularidad incorrecta aquí desperdicia todas las sesiones posteriores. Itera hasta que esté firmado.
5. Crea el mapa y los tickets. Etiqueta el mapa navigator:map; crea los tickets hijos; conecta los bordes de bloqueo en una segunda pasada (los issues necesitan ids antes de poder referenciarse entre sí). Todo lo que aún no está lo suficientemente nítido para etiquetarlo permanece en Aún no especificado.
6. Dispara los subagentes de investigación. Para cada ticket research recién creado, genera un subagente en segundo plano para resolverlo en paralelo (ver Tipos de ticket), capturando los hallazgos donde el ticket pueda enlazarlos.
7. Detente con el puntero de cierre de sesión: el enlace al mapa, cuántos tickets están en la frontera, y "la próxima sesión, ejecuta /oh-my-claudecode:ask-navigator para trabajar la siguiente decisión."

Trabajar a través del mapa

Se invoca con un mapa (enlace o número) o sin argumento (retomar el mapa abierto). Un ticket es opcional: sin uno, toma el siguiente ticket de la frontera, no uno que el capitán deba elegir.

1. Carga el mapa: la vista de baja resolución, nunca el cuerpo de cada ticket. Acércate al cuerpo completo de un ticket bajo demanda.
2. Reclama antes de trabajar: asigna el ticket al capitán (gestor) o establece Reclamado por (local) primero, para que las sesiones concurrentes lo salten. Un ticket abierto y no reclamado no está reclamado. Si la asignación no es posible (permisos, sin identificador), registra el reclamo en un comentario del ticket en su lugar.
3. Resuélvelo según su tipo (ver Tipos de ticket). Acércate según sea necesario; llama a la herramienta Skill con "deep-interview" siempre que la resolución necesite la entrada del capitán.
4. Registra la resolución: publica la respuesta como un comentario/sección de resolución, cierra el ticket (como completado; un ticket considerado fuera del destino se cierra como no planificado), y añade una línea al Decisiones hasta ahora del mapa — [<título del ticket>](enlace): <resumen de una línea>.
5. Avanza la frontera: promueve cualquier niebla que la respuesta haya hecho especificable (elimínala de Aún no especificado, crea los nuevos tickets, conecta los bordes); si la respuesta revela que un ticket está más allá del destino, ciérralo y deja una línea en Fuera de alcance; actualiza o elimina los tickets que la decisión haya invalidado.
6. Sedimento (ver Sedimento).
7. Detente después de un ticket. Una resolución por sesión es la cadencia — es el presupuesto de la ventana de contexto, no una política. El puntero de cierre de sesión nombra lo que acaba de resolverse y lo que ahora está en la frontera.

Tipos de ticket

Cada ticket es HITL (trabajado con el capitán, que habla por sí mismo) o AFK (impulsado solo por el navegador). Un ticket HITL solo se resuelve mediante intercambio en vivo; el agente nunca suplanta al capitán.

Tipo	Modo	Resuelto por	Úsalo cuando
research	AFK	Subagente en segundo plano: investiga fuentes primarias (documentación oficial, código fuente, especificaciones), deja un archivo Markdown citado en docs/research/<slug-del-ticket>.md (o la convención de notas existente del repo cuando exista), enlácelo desde el ticket	Una decisión espera conocimiento fuera del directorio de trabajo actual
loft	HITL	Llama a la herramienta Skill con "loft": un artefacto desechable responde la pregunta del ticket — un módulo de lógica pura en un shell ejecutable, o variantes de interfaz estructuralmente diferentes detrás de una ruta; el capitán reacciona, la respuesta se pliega en la resolución, el artefacto permanece en una rama loft/<nombre>	La pregunta es precisa pero la prosa no puede resolverla — necesita verse o ejecutarse, no describirse
grilling	HITL	Llama a la herramienta Skill con "deep-interview"; el capitán decide cada ronda	La conversación es la resolución — el caso predeterminado
task	HITL o AFK	El navegador lo impulsa solo cuando puede; de lo contrario, entrega al capitán una lista de verificación precisa	Trabajo manual que desbloquea una decisión (registrarse en un servicio, aprovisionar acceso, mover datos para que se pueda ver su forma) — se gana su lugar desbloqueando una decisión, no entregando el destino

La respuesta nunca es parte del cuerpo del ticket; se registra en la resolución. Los activos creados durante la resolución se enlazan desde el ticket, no se pegan.

Cuerpo del mapa

## Destino

<cómo se ve llegar al final de este mapa: la especificación, decisión o cambio al que este esfuerzo se dirige. Una o dos líneas; cada sesión se orienta a él antes de elegir un ticket.>

## Notas

<dominio; habilidades que cada sesión debería consultar; preferencias permanentes; hallazgos diferidos de drydock --check (textualmente); etiqueta documentLanguage resuelta; advertencias del modo gestor para modo local>

## Decisiones hasta ahora

<!-- el índice: una línea por ticket cerrado, suficiente para juzgar relevancia, luego acércate al enlace para el detalle que contiene el ticket -->

- [<título del ticket cerrado>](enlace): <resumen de una línea de la respuesta>

## Aún no especificado

<!-- niebla dentro del alcance que aún no puedes etiquetar; asciende a medida que avanza la frontera -->

## Fuera de alcance

<!-- trabajo considerado más allá del destino; cerrado, nunca asciende -->

¿Niebla o ticket? La prueba es si puedes enunciar la pregunta con precisión ahora, no si puedes responderla ahora. Etiqueta cuando la pregunta ya está nítida, incluso si está bloqueada. Aún no especificado cuando no puedes formularla con esa nitidez — no cortes la niebla en trozos del tamaño de un ticket de antemano; un parche puede ascender a varios tickets, o a ninguno. Fuera de alcance es un acto de delimitación, no un paso en la ruta: el alcance, no la nitidez, coloca el trabajo allí, y solo regresa si el destino se redibuja.

Sedimento

Las resoluciones aterrizan en el rastro documental del astillero en el momento en que se asientan — las mismas ranuras que usa la Fase 1 de launch:

• un término que las resoluciones asentaron o afilaron → glosario de CONTEXT.md (una entrada: definición, límite, ambigüedad resuelta)
• una decisión que pasa la prueba ADR (difícil de revertir, sorprendente sin contexto, una compensación real) → docs/adr/NNNN-<slug>.md
• una regla de negocio o hecho de fondo → docs/business/ (un artículo por pregunta de negocio)

Cuando el astillero no está dispuesto (el capitán declinó drydock en el momento del trazado), aplaza, no omitas: registra cada aterrizaje pendiente como una línea en las Notas del mapa bajo un encabezado Sedimento diferido. La ejecución posterior de /oh-my-claudecode:launch trata las superficies no dispuestas como hallazgos, y las líneas diferidas le dicen exactamente qué aterrizar primero.

Salida — pasa el testigo, no construyas

El mapa está terminado cuando no quedan tickets abiertos y Aún no especificado está vacío. Entonces:

1. Colapsa Decisiones hasta ahora en un briefing de misión: objetivo, límite de alcance, no-objetivos — redactable ahora porque el camino está despejado. Escríbelo en .omc/wayfinder/<slug-del-mapa>/brief.md para que la transferencia pase un puntero, no contenido.
2. Recomienda: "El camino está despejado. Ejecuta /oh-my-claudecode:launch con el briefing en .omc/wayfinder/<slug-del-mapa>/brief.md." El mapa permanece como el cuaderno de bitácora del esfuerzo; la puerta del astillero de launch posee todas las comprobaciones a partir de ahí.
3. La entrada predeterminada es la Fase 1 de launch (el rastro documental ya está medio lleno; su frontera se despeja rápido). Solo cuando las decisiones ya se leen como una especificación se puede redactar una especificación y entrar en launch en la Fase 2 con la ruta de especificación.

Alcance y no-objetivos

• Sin daemon, sin modo, sin comportamiento siempre activo, sin máquina de estados en tiempo de ejecución: el mapa son issues ordinarios del gestor o archivos del repositorio.
• Las solicitudes entrantes que llegan como niebla son responsabilidad del puerto para enrutarlas: un issue difuso entregado por /oh-my-claudecode:harbor se traza como cualquier idea vaga, con el hilo original y cualquier enlace de decisión firmada como material.
• Nunca muta el ciclo de vida del equipo, los estados de las tareas ni el estado en tiempo de ejecución; nunca publica tickets de entrega — los tickets de construcción de porción vertical pertenecen al C3 de launch, y el navegador no debe precortar niebla en ellos.
• Nunca ejecuta una decisión más allá de registrarla. La única excepción es un ticket task, que hace solo lo que desbloquea una decisión.
• El Decisiones hasta ahora del mapa es un índice; una decisión vive en un único lugar, su ticket.

Definición de finalización

Una sesión de trazado termina con un mapa firmado por el capitán y tickets de investigación disparados. Una sesión de trabajo termina con exactamente una resolución registrada, la frontera avanzada, y el puntero de cierre de sesión emitido. El esfuerzo termina cuando el camino está despejado y el briefing de misión está en manos del capitán con /oh-my-claudecode:launch recomendado — cada decisión que el navegador tomó en nombre del capitán es respondible con un puntero a dónde se registró.