Gentleman-Programming/gentle-ai-issue-creation

Création d'Issue

Règle Fondamentale

Découvrez le workflow de contribution du dépôt cible avant de proposer ou de publier. Les formulaires d'issue YAML sont l'autorité de format pour le chemin automatisé par défaut : matérialisez les réponses examinées dans un BODY_FILE privé et publiez avec --body-file.

Découverte Sécurisée

Effectuez d'abord des vérifications en lecture seule :

gh auth status
REPO="$(gh repo view --json nameWithOwner -q .nameWithOwner)"
REPO_URL="$(gh repo view --json url -q .url)"
HOST="${REPO_URL#*://}"
HOST="${HOST%%/*}"
TARGET="$HOST/$REPO"
gh repo view --json nameWithOwner,url,hasDiscussionsEnabled,hasIssuesEnabled,isBlankIssuesEnabled
git ls-files README.md CONTRIBUTING.md CONTRIBUTING.* .github/CONTRIBUTING.md .github/ISSUE_TEMPLATE .github/ISSUE_TEMPLATE/config.yml
gh api --hostname "$HOST" --paginate "repos/$REPO/labels?per_page=100" --jq '.[].name'

Inspectez le README.md, les instructions de contribution, les liens de contact de .github/ISSUE_TEMPLATE/config.yml, les formulaires, les étiquettes, et les issues ouvertes et fermées. Pour les questions/support, suivez le routage Discussions/contact prescrit par le dépôt lorsqu'il est disponible ; sinon, demandez ou arrêtez-vous. Terminez la vérification de la cible pour REPO, HOST et TARGET. Échouez en fermeture avant mutation lorsque l'authentification, la vérification de la cible, la disponibilité des issues, la politique, la sélection du formulaire ou les métadonnées requises sont manquantes ou ambiguës. Un recours vierge n'est autorisé que lorsque isBlankIssuesEnabled est explicitement vrai.

Construisez LABEL_ARGS uniquement à partir des étiquettes examinées qui existent et que la politique autorise l'acteur à appliquer :

LABEL_ARGS=()
LABEL_ARGS+=(--label "$LABEL") # Répéter uniquement pour chaque étiquette découverte autorisée.

Décision sur les Doublons et le Formulaire

1. Décrivez le rapport en une phrase, dérivez QUERY, puis effectuez une recherche de doublons parmi les issues ouvertes et fermées :

   gh issue list --repo "$TARGET" --state all --search "$QUERY" --limit 1000
   

   L'agent doit effectuer la recherche de doublons de manière proactive et conserver la preuve de son résultat. Si les résultats sont saturés ou si l'exhaustivité est incertaine, réduisez la recherche en lecture seule ou arrêtez-vous. Commentez un doublon confirmé au lieu d'en créer un. Avant de commenter un doublon confirmé, effectuez le même scan de confidentialité/occultation sur le corps exact du commentaire que pour la publication.

2. Sélectionnez un seul formulaire fourni par le dépôt uniquement lorsque son objectif déclaré correspond. Si plusieurs formulaires correspondent et que la politique ne les distingue pas, arrêtez-vous et demandez cette décision.

3. Pour un formulaire YAML, lisez son schéma et établissez les contrôles dans l'ordre déclaré. Prenez en charge uniquement input, textarea, dropdown et checkboxes. Les contrôles Markdown sont des directives sans réponse : respectez leurs instructions visibles lors de la collecte et de la matérialisation des réponses adjacentes, mais ne les rendez pas en tant que sections de réponse. Échouez en fermeture avant mutation en cas de structure ou de réponses obligatoires malformées, non prises en charge, manquantes ou ambiguës. Un schéma malformé, ou des réponses obligatoires manquantes ou ambiguës, échouent en fermeture : n'ouvrez pas de navigateur et ne mutez pas. Une délégation au navigateur n'est disponible que lorsque l'utilisateur demande explicitement la complétion par navigateur ou qu'un formulaire sélectionné syntaxiquement valide ne peut pas être représenté de manière sûre/fidèle par le chemin automatisé ; sinon, signalez pourquoi l'automatisation est dangereuse et arrêtez-vous.

Contrôle	Gestion requise
input / textarea	Conservez le libellé visible. Exigez une réponse lorsque validations.required est vrai ; sinon, rendez _No response_.
dropdown	Conservez les libellés et les options visibles. Exigez le texte exact de l'option sélectionnée ; la sélection unique a une seule sélection, et la sélection multiple conserve les sélections dans l'ordre des options déclarées. Un menu déroulant obligatoire nécessite au moins une sélection valide ; un menu déroulant facultatif sans sélection rend _No response_.
checkboxes	Conservez le libellé visible et chaque option sous la forme - [x] ou - [ ] dans l'ordre déclaré. Appliquez les cases à cocher individuellement obligatoires. Pour les options opérationnelles vérifiables par l'agent, effectuez de manière proactive l'action et marquez-la uniquement avec une preuve conservée ; l'agent peut attester explicitement uniquement de son propre travail basé sur des preuves et ne doit pas attribuer ses actions à l'utilisateur. Les faits personnels, le consentement, les déclarations légales et autres affirmations de l'utilisateur à la première personne nécessitent une confirmation explicite de l'utilisateur ; exigez une affirmation explicite à la première personne pour ces déclarations de l'utilisateur. Ne cochez pas toutes les cases en bloc : une demande de publication n'affirme aucune case à cocher.

Pour chaque réponse, rendez ### <libellé visible> suivi de sa valeur matérialisée. Pour textarea.attributes.render, encadrez la réponse avec le langage déclaré et une clôture suffisamment longue pour son contenu. N'inventez jamais de réponses, sélections, confirmations ou libellés.

Un modèle Markdown peut être complété uniquement à partir de preuves connues dans le même BODY_FILE privé. Si aucun modèle correspondant n'existe, utilisez le recours vierge structuré examiné uniquement lorsque les issues vierges sont explicitement activées ; sinon, arrêtez-vous sans publier.

Révision et Publication

Avant la seule tentative de création, examinez la cible, le titre, le formulaire sélectionné ou le recours autorisé, le corps exact et les étiquettes autorisées. L'agent doit effectuer le scan de confidentialité/occultation du corps exact immédiatement avant la publication et conserver la preuve : remplacez les noms de projet privés, les noms d'utilisateur, les noms d'hôte, les chemins personnels, les identifiants et les adresses réseau privées par des espaces réservés utiles sans supprimer la structure de reproduction.

Créez un seul répertoire temporaire appartenant au propriétaire en dehors du dépôt pour les deux fichiers privés ; limitez-le à l'utilisateur actuel et nettoyez les deux fichiers à chaque sortie/résultat :

umask 077
REPO_ROOT="$(git rev-parse --show-toplevel)" || exit 1
REPO_ROOT="$(cd "$REPO_ROOT" && pwd -P)" || exit 1
if [ "$REPO_ROOT" = "/" ]; then
  printf '%s\n' "Le répertoire temporaire se trouve dans le dépôt" >&2; exit 1
fi
TMP_DIR="$(TMPDIR=/tmp mktemp -d /tmp/gentle-ai-issue.XXXXXXXX)" || exit 1
trap 'rm -rf -- "$TMP_DIR"' EXIT
TMP_DIR_REAL="$(cd "$TMP_DIR" && pwd -P)" || exit 1
case "$TMP_DIR_REAL/" in
  "$REPO_ROOT/") printf '%s\n' "Le répertoire temporaire se trouve dans le dépôt" >&2; exit 1 ;;
esac
chmod 700 "$TMP_DIR_REAL"
BODY_FILE="$TMP_DIR_REAL/body.md"
READBACK_FILE="$TMP_DIR_REAL/readback.json"

Effectuez une seule tentative de mutation via le chemin automatisé et publiez exactement une fois :

gh issue create --repo "$TARGET" --title "$TITLE" --body-file "$BODY_FILE" "${LABEL_ARGS[@]}"

Lorsque la complétion par navigateur est disponible selon la décision de formulaire ci-dessus, une délégation au navigateur facultative et séparée peut ouvrir le formulaire du dépôt. Elle ne constitue jamais une preuve de publication et n'est jamais une réponse à des schémas malformés ou à des réponses obligatoires manquantes/ambiguës :

gh issue create --repo "$TARGET" --web

Ne réessayez pas en cas de timeout, d'échec réseau, d'identité manquante ou d'autre résultat incertain. Capturez le numéro d'issue retourné, puis relisez-le depuis l'hôte cible vérifié avant de signaler le succès :

gh issue view "$NUMBER" --repo "$TARGET" --json number,url,title,body,state,labels >"$READBACK_FILE"

Confirmez que la relecture identifie l'issue de l'hôte cible et que le titre et le corps correspondent après normalisation CRLF-vers-LF et nouvelle ligne finale. Signalez confirmé uniquement après cette relecture depuis l'hôte cible. Sinon, signalez no_write lorsqu'un rejet faisant autorité prouve qu'aucune issue n'a été créée, ou inconnu et arrêtez toutes les mutations ultérieures.

Triage

Avant d'approuver ou de fermer une issue, vérifiez qu'elle est concrète, non dupliquée, suffisamment documentée, dans le périmètre et cohérente avec la politique d'étiquettes/de statut du dépôt. Si un point est incertain, conservez l'état de révision du dépôt et demandez la plus petite preuve manquante.