Gentle-Programmierung/gentle-ai-issue-erstellung

Issue-Erstellung

Kernregel

Ermittle den Mitwirkungsablauf des Ziel-Repositorys, bevor du Vorschläge machst oder veröffentlichst. YAML-Issue-Formulare sind die Format-Autorität für den standardmäßig automatisierten Pfad: Überprüfte Antworten in eine private BODY_FILE materialisieren und mit --body-file veröffentlichen.

Sichere Erkundung

Führe zuerst schreibgeschützte Prüfungen durch:

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'

Überprüfe README.md, Mitwirkungsanleitungen, Kontaktlinks in .github/ISSUE_TEMPLATE/config.yml, Formulare, Labels sowie offene und geschlossene Issues. Folge bei Fragen/Support dem repository-vorgeschriebenen Discussions/Kontakt-Routing, falls vorhanden; andernfalls frage nach oder stoppe. Schließe die Zielverifikation für REPO, HOST und TARGET ab. Brich vor Mutation ab, wenn Authentifizierung, Zielverifikation, Issue-Verfügbarkeit, Richtlinie, Formularauswahl oder erforderliche Metadaten fehlen oder mehrdeutig sind. Ein leerer Fallback ist nur erlaubt, wenn isBlankIssuesEnabled explizit wahr ist.

Erstelle LABEL_ARGS nur aus überprüften Labels, die existieren und deren Anwendung die Richtlinie dem Akteur erlaubt:

LABEL_ARGS=()
LABEL_ARGS+=(--label "$LABEL") # Nur für jedes erlaubte gefundene Label wiederholen.

Duplikat- und Formularentscheidung

1. Beschreibe den Bericht in einem Satz, leite QUERY ab und führe eine Duplikatsuche über offene und geschlossene Issues durch:

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

   Der Agent muss die Duplikatsuche proaktiv durchführen und das Ergebnis aufbewahren. Wenn Ergebnisse gesättigt sind oder die Vollständigkeit unsicher ist, schränke die schreibgeschützte Suche ein oder stoppe. Kommentiere bei einem bestätigten Duplikat anstatt eines neuen Issues zu erstellen. Führe vor dem Kommentieren bei einem bestätigten Duplikat dieselbe Privatsphärenprüfung/Redaktion am exakten Kommentartext durch wie bei der Veröffentlichung.

2. Wähle nur dann ein Repository-eigenes Formular aus, wenn dessen deklarierter Zweck übereinstimmt. Wenn mehrere Formulare übereinstimmen und die Richtlinie sie nicht unterscheidet, stoppe und bitte um Entscheidung.

3. Lies bei einem YAML-Formular dessen Schema und lege die Steuerelemente in der deklarierten Reihenfolge fest. Unterstütze nur input, textarea, dropdown und checkboxes. Markdown-Steuerelemente sind nicht antwortende Anleitungen: Befolge ihre sichtbaren Anweisungen beim Sammeln und Materialisieren benachbarter Antworten, aber gib sie nicht als Antwortabschnitte wieder. Brich vor Mutation bei fehlerhaftem, nicht unterstütztem, fehlendem oder mehrdeutigem, erforderlichem Schema oder fehlenden/mangelhaften Antworten ab. Ein fehlerhaftes Schema oder fehlende/mehrdeutige erforderliche Antworten führen zum Abbruch: Öffne keinen Browser und mutiere nicht. Eine Browser-Übergabe ist nur verfügbar, wenn der Benutzer explizit eine Browser-Vervollständigung anfordert oder ein syntaktisch gültiges ausgewähltes Formular nicht sicher/zuverlässig durch den automatischen Pfad abgebildet werden kann; anderenfalls melde, warum Automatisierung unsicher ist, und stoppe.

Steuerelement	Erforderliche Handhabung
input / textarea	Behalte die sichtbare Bezeichnung bei. Erfordere eine Antwort, wenn validations.required wahr ist; andernfalls gib _No response_ aus.
dropdown	Behalte sichtbare Bezeichnungen und Optionen bei. Erfordere exakten ausgewählten Optionstext; Einfachauswahl hat eine Auswahl, Mehrfachauswahl behält Auswahl in der deklarierten Reihenfolge der Optionen bei. Ein erforderliches Dropdown benötigt mindestens eine gültige Auswahl; ein optionales Dropdown ohne Auswahl gibt _No response_ aus.
checkboxes	Behalte die sichtbare Bezeichnung und jede Option als - [x] oder - [ ] in der deklarierten Reihenfolge bei. Erzwinge individuell erforderliche Checkboxen. Für agentenverifizierbare operative Optionen führe die Aktion proaktiv aus und markiere sie nur mit aufbewahrter Evidenz; der Agent darf nur seine eigenen evidenzgestützten Arbeiten ausdrücklich bestätigen und darf dem Benutzer keine Handlungen zuschreiben. Persönliche Tatsachen, Einwilligungen, rechtliche Erklärungen und andere Ich-Aussagen des Benutzers erfordern explizite Benutzerbestätigung; erfordere für solche Benutzererklärungen eine explizite Ich-Bestätigung. Setze nicht pauschal alle Checkboxen: Eine Veröffentlichungsanfrage bestätigt keine Checkbox.

Gib für jede Antwort ### <sichtbare Bezeichnung> gefolgt von ihrem materialisierten Wert aus. Für textarea.attributes.render setze die Antwort in Fences mit der deklarierten Sprache und einer Fence-Länge, die für den Inhalt ausreicht. Erfinde niemals Antworten, Auswahlen, Bestätigungen oder Bezeichnungen.

Eine Markdown-Vorlage darf nur aus bekannter Evidenz in dieselbe private BODY_FILE vervollständigt werden. Wenn keine passende Vorlage existiert, verwende den überprüften strukturierten leeren Fallback nur, wenn Blank-Issues explizit aktiviert sind; andernfalls stoppe ohne Veröffentlichung.

Überprüfung und Veröffentlichung

Führe vor dem einzigen Erstellungsversuch eine Überprüfung von Ziel, Titel, ausgewähltem Formular oder erlaubtem Fallback, exaktem Body und erlaubten Labels durch. Der Agent muss die Privatsphärenprüfung/Redaktion des exakten Bodys unmittelbar vor der Veröffentlichung durchführen und das Ergebnis aufbewahren: Ersetze private Projektnamen, Benutzernamen, Hostnamen, Home-Pfade, Zugangsdaten und private Netzwerkadressen durch nützliche Platzhalter, ohne die Reproduktionsstruktur zu entfernen.

Erstelle ein temporäres Verzeichnis, das nur dem Eigentümer gehört, außerhalb des Repositorys für beide privaten Dateien; beschränke es auf den aktuellen Benutzer und entferne beide Dateien bei jedem Verlassen/Ergebnis:

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' "Temporäres Verzeichnis befindet sich im Repository" >&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' "Temporäres Verzeichnis befindet sich im Repository" >&2; exit 1 ;;
esac
chmod 700 "$TMP_DIR_REAL"
BODY_FILE="$TMP_DIR_REAL/body.md"
READBACK_FILE="$TMP_DIR_REAL/readback.json"

Führe einen Mutationsversuch über den automatisierten Pfad durch und veröffentliche genau einmal:

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

Wenn eine Browser-Vervollständigung gemäß der obigen Formularentscheidung verfügbar ist, kann eine optionale, separate Browser-Übergabe das Repository-Formular öffnen. Sie ist niemals ein Nachweis der Veröffentlichung und niemals eine Reaktion auf fehlerhafte Schemata oder fehlende/mehrdeutige erforderliche Antworten:

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

Wiederhole kein Timeout, keinen Netzwerkfehler, keine fehlende Identität oder anderes unsicheres Ergebnis. Erfasse die zurückgegebene Issue-Nummer und lese sie dann vom verifizierten Ziel-Host zurück, bevor du Erfolg meldest:

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

Bestätige, dass das zurückgelesene Issue auf dem Ziel-Host identifiziert wurde und dass Titel und Body nach reiner CRLF-zu-LF- und abschließender-Zeilenvorschub-Normalisierung übereinstimmen. Melde confirmed erst nach dieser Rückleseprüfung vom Ziel-Host. Melde andernfalls no_write, wenn eine autoritative Ablehnung beweist, dass kein Issue erstellt wurde, oder unknown und stoppe alle späteren Mutationen.

Triage

Überprüfe vor der Genehmigung oder Schließung eines Issues, ob es konkret, kein Duplikat, ausreichend belegt, im Rahmen und konsistent mit der Label-/Statusrichtlinie des Repositorys ist. Wenn ein Punkt unsicher ist, behalte den Repository-Überprüfungsstatus und fordere die kleinste fehlende Evidenz an.