ask-navigator

Ask Navigator

Ask-navigator est le navigateur de Shipyard : il prend un effort enveloppé de brouillard — le chemin d'ici à la destination n'est pas encore visible — et le trace comme une carte de tickets de décision sur le tracker du dépôt, puis travaille la frontière un ticket par session jusqu'à ce que la voie soit claire. Il produit des décisions, jamais des livrables : quand la voie est claire, il passe la main, il ne construit pas. La livraison appartient à /oh-my-claudecode:launch.

Le contrat de rôle. Le capitaine (l'humain) signe la destination (W1) et la carte (W2) ; le navigateur rédige tout le reste et ne répond jamais à une question qui appartient au capitaine — une séance de gril au cours de laquelle l'agent répond à ses propres questions a brisé le rôle, pas seulement le processus. Les faits sont le travail du navigateur ; les décisions sont celles du capitaine.

Test de brouillard. Un effort est brumeux si l'une des réponses est non :

1. Q1 — La destination peut-elle être énoncée en une phrase : le spec, la décision ou le changement vers lequel cet effort se dirige ?
2. Q2 — Les trois premières décisions peuvent-elles être énoncées avec précision maintenant, même si aucune d'elles ne peut encore être résolue ?

Deux fois oui → pas besoin de carte ; lancez /oh-my-claudecode:launch (sa porte de brouillard envoie les efforts ici seulement quand une réponse est non). Soit non → cartographie d'abord. ask-navigator est également accessible directement : invoquez-le avec une idée vague, avec des questions résiduelles transmises par la porte de brouillard de launch, ou sans argument pour continuer la carte ouverte.

Carte d'accueil

La carte est un ticket unique étiqueté navigator:map sur le tracker du dépôt ; ses tickets de décision sont des tickets enfants de la carte. Le tracker doit avoir été enregistré par /oh-my-claudecode:drydock ; si aucun n'a été enregistré, demandez une fois (GitHub / GitLab / markdown local) et mémorisez la réponse dans les Notes de la carte.

• Avec tracker (GitHub, GitLab ou tracker enregistré) : un ticket de carte, des tickets enfants par ticket, relations de blocage/sous-ticket natives. Les sessions concurrentes et l'interface du tracker lui-même rendent la frontière — la carte vit là où les humains regardent déjà. Créez le label navigator:map si le tracker ne l'a pas encore ; les types de tickets vivent dans le corps du ticket, pas dans les labels.
• Repli Markdown local : .omc/wayfinder/<slug-carte>/carte.md plus decisions/NN-<slug>.md, un fichier par ticket, numérotés dans l'ordre des dépendances. Le mode local n'a pas de garantie de revendication concurrente : il est mono-pilote par convention, énoncé une fois dans les Notes de la carte.

La carte est un index, pas un magasin : une décision vit à exactement un endroit — son ticket. La carte résume chaque résolution en une ligne et lie ; elle ne répète jamais le détail.

Langue des documents

Le texte de la carte et des tickets suit le même contrat de langue des documents que /oh-my-claudecode:drydock : lisez documentLanguage depuis le frontmatter de CONTEXT.md quand il est présent ; si le chantier n'est pas établi, posez la question de langue une fois pendant la cartographie (W2) et enregistrez le tag résolu dans les Notes de la carte pour que la future exécution de launch l'hérite. Les chemins, labels, commandes slash, le label navigator:map, les noms de types de tickets (research, loft, grilling, task), HITL/AFK, et blockedBy sont des jetons stables et restent identiques octet par octet dans toutes les langues.

Cartographier la carte

Invoqué avec une idée vague (ou les questions résiduelles de launch). La cartographie est le travail d'une session ; elle ne résout rien manuellement.

1. Lancer l'audit, reporter les constats. Lancez l'audit /oh-my-claudecode:drydock --check en mode rapport seul : les constats ne bloquent jamais la cartographie (une carte produit des décisions, pas des atterrissages de créneaux), mais ils sont enregistrés textuellement dans les Notes de la carte — la porte du chantier de launch collectera cette dette quand l'effort entrera enfin en livraison. Si le chantier n'est pas du tout établi (pas de CONTEXT.md, pas de docs/adr/), proposez /oh-my-claudecode:drydock une fois ; si le capitaine décline, procédez en mode tracker seul et reportez tous les sédiments (voir Sédiment).
2. W1 — nommer la destination. Appelez l'outil Skill avec "deep-interview" et déterminez vers quoi cette carte se dirige : le spec, la décision ou le changement. La destination fixe le périmètre, elle est donc réglée en premier. W1 est une signature du capitaine : présentez l'énoncé de la destination et obtenez une confirmation explicite. Si le capitaine ne peut pas énoncer de destination même avec l'aide de l'interview, ce n'est pas une erreur — présentez les meilleurs candidats classés et laissez le capitaine en choisir un à cartographier ou mettre l'effort en attente.
3. Cartographier la frontière. Grillez à nouveau avec "deep-interview", en largeur d'abord : rayonnez dans tout l'espace plutôt que d'approfondir une seule piste, en faisant surface les décisions ouvertes et les premières étapes réalisables maintenant. Si cela ne révèle aucun brouillard — le chemin vers la destination est déjà clair et le voyage tient en une session — pas besoin de carte : arrêtez-vous et recommandez /oh-my-claudecode:launch.
4. W2 — signer la carte. Présentez la carte proposée : destination, tickets initiaux avec types et arêtes de blocage, et le croquis du brouillard. W2 est une signature du capitaine : une granularité erronée ici gaspille toutes les sessions suivantes. Itérez jusqu'à signature.
5. Créer la carte et les tickets. Étiquetez la carte navigator:map ; créez les tickets enfants ; câblez les arêtes de blocage dans un second passage (les tickets ont besoin d'identifiants avant de pouvoir se référencer mutuellement). Tout ce qui n'est pas encore assez précis pour être ticketé reste dans Pas encore spécifié.
6. Lancer les sous-agents de recherche. Pour chaque ticket research créé, lancez un sous-agent en arrière-plan pour le résoudre en parallèle (voir Types de tickets), en capturant les résultats là où le ticket peut les lier.
7. Arrêtez-vous avec le pointeur de fin de session : le lien vers la carte, combien de tickets sont sur la frontière, et "prochaine session, lancez /oh-my-claudecode:ask-navigator pour travailler la prochaine décision."

Travailler à travers la carte

Invoqué avec une carte (lien ou numéro) ou sans argument (reprendre la carte ouverte). Un ticket est facultatif : sans lui, prenez le prochain ticket de la frontière, pas un que le capitaine doit choisir.

1. Charger la carte : la vue basse résolution, jamais le corps de chaque ticket. Zoomez sur le corps complet d'un ticket à la demande.
2. Revendiquer avant de travailler : assignez le ticket au capitaine (tracker) ou définissez Revendiqué-par (local) d'abord, pour que les sessions concurrentes l'ignorent. Un ticket ouvert non revendiqué n'est pas revendiqué. Si l'assignation n'est pas possible (permissions, pas d'identifiant), enregistrez la revendication dans un commentaire du ticket à la place.
3. Le résoudre selon son type (voir Types de tickets). Zoomez si nécessaire ; appelez l'outil Skill avec "deep-interview" à chaque fois que la résolution nécessite l'apport du capitaine.
4. Enregistrer la résolution : publiez la réponse comme commentaire/section de résolution, fermez le ticket (comme terminé ; un ticket jugé hors de la destination se ferme comme non planifié), et ajoutez une ligne à Décisions jusqu'ici de la carte — [<titre du ticket>](lien) : <résumé en une ligne>.
5. Avancer la frontière : diplômez tout brouillard que la réponse a rendu spécifiable (supprimez-le de Pas encore spécifié, créez les nouveaux tickets, câblez les arêtes) ; si la réponse révèle qu'un ticket se trouve au-delà de la destination, fermez-le et laissez une ligne dans Hors périmètre ; mettez à jour ou supprimez les tickets que la décision a invalidés.
6. Sédiment (voir Sédiment).
7. Arrêtez-vous après un ticket. Une résolution par session est la cadence — c'est le budget de fenêtre de contexte, pas une politique. Le pointeur de fin de session nomme ce qui vient d'être résolu et ce qui est maintenant sur la frontière.

Types de tickets

Chaque ticket est HITL (travaillé avec le capitaine, qui parle pour lui-même) ou AFK (piloté par le navigateur seul). Un ticket HITL ne se résout que par un échange en direct ; l'agent ne se substitue jamais au côté du capitaine.

Type	Mode	Résolu par	Utiliser quand
research	AFK	Sous-agent en arrière-plan : enquêter sur les sources primaires (docs officiels, code source, specs), laisser un fichier Markdown cité à docs/research/<slug-ticket>.md (ou la convention de notes existante du dépôt quand elle existe), le lier depuis le ticket	Une décision attend des connaissances en dehors du répertoire de travail actuel
loft	HITL	Appeler l'outil Skill avec "loft" : un artefact jetable répond à la question du ticket — un module logique pur dans un shell cliquable, ou des variantes UI structurellement différentes derrière une route ; le capitaine réagit, la réponse se replie dans la résolution, l'artefact reste sur une branche loft/<nom>	La question est précise mais la prose ne peut pas la trancher — il faut la voir ou la cliquer, pas la décrire
grilling	HITL	Appeler l'outil Skill avec "deep-interview" ; le capitaine décide à chaque tour	La conversation est la résolution — le cas par défaut
task	HITL ou AFK	Le navigateur le pilote seul là où il le peut ; sinon, remet au capitaine une checklist précise	Travail manuel qui débloque une décision (s'inscrire à un service, provisionner un accès, déplacer des données pour que leur forme soit visible) — il gagne sa place en débloquant une décision, pas en livrant la destination

La réponse ne fait jamais partie du corps du ticket ; elle est enregistrée lors de la résolution. Les actifs créés pendant la résolution sont liés depuis le ticket, pas collés dedans.

Corps de la carte

## Destination

<à quoi ressemble l'atteinte de la fin de cette carte : le spec, la décision ou le changement vers lequel cet effort se dirige. Une ou deux lignes ; chaque session s'y oriente avant de choisir un ticket.>

## Notes

<domaine ; compétences que chaque session devrait consulter ; préférences permanentes ; constats drydock --check reportés (textuellement) ; tag documentLanguage résolu ; mises en garde du mode tracker pour le mode local>

## Décisions jusqu'ici

<!-- l'index : une ligne par ticket fermé, assez de pertinence pour juger, puis zoomez sur le lien pour le détail que le ticket contient -->

- [<titre du ticket fermé>](lien) : <résumé en une ligne de la réponse>

## Pas encore spécifié

<!-- brouillard dans le périmètre que vous ne pouvez pas encore ticketer ; diplômé à mesure que la frontière avance -->

## Hors périmètre

<!-- travail jugé au-delà de la destination ; fermé, ne diplôme jamais -->

Brouillard ou ticket ? Le test est de savoir si vous pouvez énoncer la question avec précision maintenant, pas si vous pouvez y répondre maintenant. Ticket quand la question est déjà nette, même si elle est bloquée. Pas encore spécifié quand vous ne pouvez pas la formuler aussi nettement — ne prédécoupez pas le brouillard en morceaux de taille de ticket ; un patch peut diplômer en plusieurs tickets, ou aucun. Hors périmètre est un acte de cadrage, pas une étape sur la route : le cadrage, pas la netteté, y place le travail, et il n'en revient que si la destination est redessinée.

Sédiment

Les résolutions atterrissent dans la piste écrite du chantier dès qu'elles se stabilisent — les mêmes emplacements que la phase 1 de launch utilise :

• un terme que les résolutions ont stabilisé ou précisé → glossaire de CONTEXT.md (une entrée : définition, frontière, ambiguïté résolue)
• une décision passant le test ADR (difficile à inverser, surprenante sans contexte, un vrai compromis) → docs/adr/NNNN-<slug>.md
• une règle métier ou un fait de fond → docs/business/ (un article par question métier)

Quand le chantier n'est pas établi (le capitaine a refusé drydock au moment de la cartographie), reportez, ne sautez pas : enregistrez chaque atterrissage en attente comme une ligne dans les Notes de la carte sous un en-tête Sédiment reporté. La porte du chantier de l'exécution ultérieure de /oh-my-claudecode:launch traite les surfaces non établies comme des constats, et les lignes reportées lui disent exactement quoi atterrir en premier.

Sortie — passer la main, ne pas construire

La carte est terminée quand aucun ticket ouvert ne reste et que Pas encore spécifié est vide. Alors :

1. Condensez Décisions jusqu'ici en un briefing de mission : objectif, frontière du périmètre, non-objectifs — écrivez-le maintenant parce que la voie est claire. Écrivez-le dans .omc/wayfinder/<slug-carte>/brief.md pour que le passage de main transmette un pointeur, pas du contenu.
2. Recommandez : "La voie est claire. Lancez /oh-my-claudecode:launch avec le brief dans .omc/wayfinder/<slug-carte>/brief.md." La carte reste le journal de bord de l'effort ; la porte du chantier de launch possède toutes les vérifications à partir de là.
3. L'entrée par défaut est la phase 1 de launch (la piste écrite est déjà à moitié remplie ; sa frontière se dégage vite). Ce n'est que lorsque les décisions ressemblent déjà à un spec qu'un spec peut être rédigé et launch entré en phase 2 avec le chemin du spec.

Périmètre et non-objectifs

• Pas de démon, pas de mode, pas de comportement toujours allumé, pas de machine d'état d'exécution : la carte est des tickets ordinaires du tracker ou des fichiers du dépôt.
• Les requêtes entrantes qui arrivent comme brouillard sont du ressort du port pour les acheminer : un ticket flou remis par /oh-my-claudecode:harbor se cartographie comme n'importe quelle idée vague, avec le fil de discussion original et les éventuels liens de décision signée comme matériau.
• Ne mute jamais le cycle de vie de l'équipe, les statuts de tâches ou l'état d'exécution ; ne publie jamais de tickets de livraison — les tickets de construction en tranche verticale appartiennent au C3 de launch, et le navigateur ne doit pas prédécouper le brouillard en eux.
• N'exécute jamais une décision au-delà de son enregistrement. La seule exception est un ticket task, qui ne fait que ce qui débloque une décision.
• Le Décisions-jusqu'ici de la carte est un index ; une décision vit à exactement un endroit, son ticket.

Définition d'achèvement

Une session de cartographie se termine avec une carte signée par le capitaine et des tickets de recherche lancés. Une session de travail se termine avec exactement une résolution enregistrée, la frontière avancée, et le pointeur de fin de session émis. L'effort se termine quand la voie est claire et que le briefing de mission est entre les mains du capitaine avec /oh-my-claudecode:launch recommandé — chaque décision que le navigateur a prise pour le compte du capitaine peut être répondue par un pointeur vers l'endroit où elle a été enregistrée.