pr-address-feedback

Examinons chaque commentaire de révision de cette pull request un par un et établissons un plan pour agir sur les retours ou répondre avec justification.

Cible de la PR : utilise le numéro/URL de la PR que j'ai passée avec cette commande, le cas échéant ; sinon la PR pour la branche actuelle.

Tu es en mode plan. Tant que je n'approuve pas le plan final, N'ÉDITE PAS les fichiers, ne commit pas, ne push pas, ne résous pas les threads, ne poste rien sur GitHub. Les commandes en lecture seule (gh, git log/diff/show, consultation de fichiers) vont bien.

La PR peut vivre sur github.com ou sur un autre host GitHub (p. ex. GitHub Enterprise Server). Récupère l'host à partir de l'url de la PR et passe --hostname <host> à chaque appel gh api (ou fais export GH_HOST=<host> une fois). gh api utilise par défaut github.com même à l'intérieur d'un checkout Enterprise Server.

1. Rassembler les retours

• Résous la PR : utilise la cible ci-dessus si fournie (numéro, URL, ou owner/repo#N) ; sinon utilise la PR de la branche actuelle (gh pr view --json number,url,headRefName,headRefOid,baseRefName,headRepository,headRepositoryOwner). Si aucune n'est trouvée, demande-moi.
• Récupère tous les threads de révision avec GraphQL (pagine), en incluant pour chaque thread : id, isResolved, isOutdated, path, line, startLine, originalLine, diffSide, et pour chaque commentaire databaseId, url, author.login, body, diffHunk, createdAt.
• Récupère aussi les corps de révision de premier niveau (reviews avec body non vide) et les commentaires généraux de conversation PR, car ils peuvent contenir des retours aussi.
• Saute les threads résolus et les threads où j'ai (l'auteur de la PR) eu le dernier mot à moins qu'ils semblent toujours non traités. Mentionne les threads obsolètes mais vérifie si le retour s'applique toujours au code actuel.
• Fais git fetch <base remote> refs/pull/<n>/head d'abord et vérifie que le SHA récupéré correspond à l'headRefOid de la PR. Lis le code à partir de ce SHA (<headSha> ci-dessous), pas depuis origin/<headRef>, qui peut ne pas exister pour les PRs depuis des forks. Si ma branche locale est en retard, dis-le.
• Ordonne les éléments pour que la révision se lise de manière cohérente, pas seulement par position dans la diff :
  • Avant d'ordonner, lis chaque élément et repère les dépendances et motifs. Certains commentaires renvoient à d'autres (« idem ci-dessus », « pareil », « comme je l'ai mentionné sur foo.go », « même problème ici »). D'autres répètent le même type de retour (p. ex. le même reproche de nommage ou vérification d'erreur manquante en plusieurs endroits).
  • Place en premier le commentaire qui établit un motif : celui qui l'explique complètement, généralement le plus ancien. Puis place immédiatement après chaque commentaire qui y renvoie ou le répète, pour que tu n'aies à comprendre le motif qu'une fois.
  • Ordonne le reste par fichier et ligne pour que les retours connexes restent ensemble. Résous les ex aequo par createdAt du commentaire.
• Dans un message visible (pas seulement dans la réflexion), dis-moi d'abord combien d'éléments il y a. Donne un index d'une ligne dans l'ordre dans lequel tu les présenteras (N. @revieweur path:line — gist). Marque les suites, p. ex. (même motif que #2). Note les threads ignorés ou déjà traités. Puis passe-les en revue un par un dans cet ordre.

2. Présenter chaque élément (un par tour)

CRITIQUE — l'élément doit être visible avant de demander. Je ne peux pas voir ta réflexion/raisonnement, la sortie d'outil, ou les lignes SQL. Les seules choses que je vois sont le texte de ton message assistant et l'invite ask_user courte. Donc pour chaque élément tu DOIS écrire le bloc d'élément complet ci-dessous en tant que texte de message assistant normal dans la même réponse, immédiatement avant l'appel ask_user. N'appelle jamais ask_user pour un élément tant que ce bloc n'a pas été écrit. Résumer l'élément seulement dans ta réflexion ne compte pas.

Ce bloc est exempt de toute guidance générale de brièveté / limite de mots — l'exhaustivité ici compte plus que la concision. Ne paraphrase pas le commentaire et ne saute pas la diff pour économiser de l'espace.

Écris chaque élément en utilisant exactement ce modèle (remplis chaque section ; écris « n/a » plutôt que d'en supprimer une) :

---
### Élément N sur M — @revieweur · [`path:line`](COMMENT_URL)
Thread : [ouvrir sur GitHub](COMMENT_URL) · statut : ouvert | obsolète

**Retour**
> texte complet du premier commentaire, verbatim (garde ses blocs de code / suggestions)
>
> **@répondeur :** texte complet de chaque réponse, dans l'ordre

**Contexte de diff** (depuis le `diffHunk` de la révision, tronqué à ~10 lignes autour de la ligne commentée)
```diff
...
```

**Code actuel** — `path` Ldébut–Lfin (toujours inclure ; c'est ce sur quoi je décide)
```go
214 | ...
```

**Preuve / contexte connexe**
- `other/file.go:123` — pourquoi c'est important (avec un snippet court si ça aide)
- Commentaire connexe : [@qui sur path:line](url) — comment ça interagit avec celui-ci

**Évaluation** : le revieweur a-t-il raison ? Quel est le compromis ?

**Recommandation** : **Agir** — fichiers exacts + esquisse courte du changement · ou · **Répondre** — brouillon de réponse dans ma voix, court et amical :
> texte du brouillon de réponse

Règles pour le bloc :

• COMMENT_URL est le champ url du commentaire (p. ex. https://github.com/o/r/pull/123#discussion_r456 ; l'host peut différer, p. ex. sur GitHub Enterprise Server). Ne l'omets jamais.
• Cite le retour verbatim depuis le body récupéré, pas de mémoire. Pour le retour de révision de premier niveau / commentaire de conversation, utilise l'URL de ce commentaire et remplace « Contexte de diff » par « n/a (pas un commentaire de ligne) », mais montre quand même le code actuel pertinent.
• Récupère le code actuel avec numéros de ligne depuis la head de la PR (p. ex. git show <headSha>:path | sed -n 'A,Bp' | nl -ba -v A ou gh api repos/<headOwner>/<headRepo>/contents/path?ref=<headSha> -H 'Accept: application/vnd.github.raw') — ne te fie pas à une branche locale qui peut être obsolète. Utilise le langage du fichier pour la clôture de code.
• Chaque affirmation dans Évaluation doit être soutenue par quelque chose dans « Preuve » (un path:line + snippet, un commit, un lien de doc, un commentaire connexe). Si tu as enquêté sur quelque chose pendant la réflexion, mets la découverte là pour que je la voie.

Puis appelle ask_user pour obtenir ma décision :

• Fais la question assez autonome pour identifier le commentaire même si je vois seulement l'invite : Élément N sur M — @revieweur sur path:line : "<premiers ~15 mots du commentaire>…" Comment dois-je le gérer ?
• Offre des choix comme : Agir comme proposé (Recommandé), Répondre avec justification, Agir différemment, Passer / reporter. Mets ta recommandation en premier.
• Pour un élément qui suit un motif antérieur, dis quel élément antérieur il référence et ce que j'ai décidé là, dans le bloc d'élément (sous Preuve) et dans l'invite. Offre Même que élément K (Recommandé) comme premier choix quand cette décision s'applique clairement.
• Si je choisis une option de forme libre, travaille-la avec moi avant de passer au suivant.
• Si je demande à revoir un élément, ré-imprime son bloc complet (re-récupère si besoin) plutôt que de le résumer.

Garde un enregistrement courant de chaque élément et décision (par exemple dans la base de données SQL de session : comment id, url, path, line, decision, planned change, reply text) pour que rien ne se perde et les éléments puissent être ré-rendus.

3. Construire le plan de résolution

Quand chaque élément est décidé, écris un plan unique qui liste, pour chaque élément : le lien du commentaire, la décision, le changement de code (si agir), le texte de réponse exact à poster (si répondre, ou pour confirmer une action), et si le thread sera résolu (voir les défauts dans §4). Termine le plan avec la liste des revieweurs dont la révision sera re-demandée. Puis appelle exit_plan_mode pour que je puisse le réviser et l'approuver.

4. Règles pour exécuter le plan approuvé

• Avant toute édition, assure-toi que l'arbre de travail est un checkout propre de la head de la PR : gh pr checkout <n> (qui définit aussi la destination push pour les PRs depuis les forks), puis vérifie que HEAD correspond au <headSha> vérifié. Si ce n'est pas le cas, ou que l'arbre est sale, arrête et demande-moi.
• Fais les changements de code en petits commits ciblés. Le cas échéant, utilise un commit par élément de retour pour que les réponses puissent pointer vers un SHA spécifique.
• Push avant de répondre. Toute réponse qui mentionne un SHA de commit ne doit être postée qu'après que ce commit soit sur GitHub. Sinon le SHA ne s'affichera pas en lien. Dans l'ordre :
  1. Commit, puis git push.
  2. Re-lis l'headRefOid de la PR (gh pr view <n> --json headRefOid) et confirme que chaque commit référencé est accessible depuis lui : git fetch <base remote> refs/pull/<n>/head, puis git merge-base --is-ancestor <sha> FETCH_HEAD. Si ce n'est pas le cas, arrête et répare ça avant de poster.
  3. Seulement ensuite poste les réponses. Utilise le SHA complet de 40 caractères (ou un lien https://{host}/{owner}/{repo}/pull/{n}/commits/{sha}, en utilisant l'host de la PR) pour que GitHub le lie.
• Réponds à l'intérieur du thread existant (gh api repos/{owner}/{repo}/pulls/{n}/comments/{comment_id}/replies -f body=...), pas en tant que nouveau commentaire de premier niveau. Pour le retour de révision de premier niveau / commentaire de conversation, poste un commentaire PR qui cite ce à quoi il répond.
• Poste le texte de réponse que j'ai approuvé. Ne changer que les SHAs va bien.
• Résous seulement les threads que le plan marque pour résolution, et seulement après que leur réponse soit postée. Défauts (tu peux modifier par élément dans le plan) :
  • Éléments Agir : résous.
  • Éléments Répondre avec justification : laisse ouvert pour que le revieweur puisse répondre.
  • Éléments Passer / reporter : laisse ouvert, ne réponds pas.
  • Le retour de révision de premier niveau / commentaire de conversation n'a pas de thread à résoudre ; saute.
  • Pour les threads marqués pour résolution, préfère l'outil reply_and_resolve_review_thread quand disponible (seulement certaines surfaces Copilot le fournissent ; passe le thread id + root comment databaseId), qui répond et résout en une étape. Sinon poste la réponse avec gh api comme ci-dessus, puis résous via GraphQL : gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -f id=<thread id>.
  • Pour les threads restant ouvert, utilise un appel de réponse seule (reply_to_review_thread si disponible, sinon l'appel gh api …/replies ci-dessus). N'utilise jamais l'outil de réponse-et-résolution pour eux.
• Re-demande la révision en dernier. Après tous les commits poussés, réponses postées, et threads résolus, re-demande la révision à chaque reviewer humain dont le retour a été traité dans ce passage (m'excluant moi et les comptes bot) : gh api -X POST repos/{owner}/{repo}/pulls/{n}/requested_reviewers -f 'reviewers[]=<login>' (répète reviewers[] pour chacun). Saute quiconque a déjà une demande de révision en attente. Si un appel échoue, rapporte-le plutôt que de réessayer aveuglément.
• À la fin, donne-moi un court résumé avec des liens vers chaque réponse que tu as postée, chaque commit que tu as poussé, les threads qui ont été résolus, et qui a été re-demandé.