Issue作成 / トリアージ

Issue 作成

基本ルール

提案または公開前に、対象リポジトリのコントリビューションワークフローを発見すること。YAML Issue フォームがデフォルトの自動パスの形式権限を持つ。つまり、レビュー済みの回答をプライベートな BODY_FILE に具体化し、--body-file で公開する。

安全な発見

最初に読み取り専用チェックを実行する:

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'

README.md、コントリビューション手順、.github/ISSUE_TEMPLATE/config.yml の連絡先リンク、フォーム、ラベル、オープン/クローズ済みの Issue を検査する。質問やサポートについては、リポジトリが指定する Discussions/連絡先ルーティングに従う（利用可能な場合）。そうでなければ質問するか停止する。REPO、HOST、TARGET のターゲット検証を完了する。認証、ターゲット検証、Issue の可用性、ポリシー、フォームの選択、必要なメタデータが欠落または曖昧な場合は、ミューテーションの前にフェイルクローズドする。ブランクフォールバックは、isBlankIssuesEnabled が明示的に true の場合にのみ許可される。

LABEL_ARGS は、レビュー済みで存在し、ポリシーがアクターに適用を許可するラベルのみから構築する:

LABEL_ARGS=()
LABEL_ARGS+=(--label "$LABEL") # 許可された発見済みラベルごとに繰り返す。

重複判定とフォーム選択

1. レポートを1文で説明し、QUERY を導出してから、オープン/クローズ済みのすべての Issue を対象に1回の重複検索を実行する:

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

   エージェントは、重複検索を積極的に完了し、その結果の証拠を保持しなければならない。結果が飽和しているか完全性が不明な場合は、読み取り専用検索を絞り込むか停止する。確認された重複には、新しい Issue を作成する代わりにコメントする。確認された重複にコメントする前に、公開時と同様のプライバシースキャン/編集をコメント本文に対して実行する。

2. リポジトリが提供するフォームは、その宣言された目的が一致する場合にのみ1つ選択する。複数のフォームが一致し、ポリシーが区別しない場合は、停止してその判断を要求する。

3. YAML フォームの場合は、そのスキーマを読み取り、宣言された順序でコントロールを確立する。input、textarea、dropdown、checkboxes のみをサポートする。Markdown コントロールは非回答のガイダンスである。隣接する回答を収集・具体化する際に、その表示上の指示を尊重するが、応答セクションとしてレンダリングしてはならない。不正な形式、サポート外、欠落、または曖昧な必須構造や回答の場合は、ミューテーションの前にフェイルクローズドする。不正なスキーマ、または欠落/曖昧な必須回答の場合はフェイルクローズドする。ブラウザを開いたりミューテーションを行ったりしてはならない。ブラウザへのハンドオフは、ユーザーが明示的にブラウザでの完了を要求するか、構文的に有効な選択済みフォームを自動パスで安全/忠実に表現できない場合にのみ利用可能である。それ以外の場合は、自動化が安全でない理由を報告して停止する。

コントロール	必須の処理
input / textarea	表示ラベルを保持する。validations.required が true の場合は回答を必須にする。それ以外の場合は _No response_ をレンダリングする。
dropdown	表示ラベルと選択肢を保持する。選択された選択肢のテキストを正確に要求する。単一選択は1つの選択肢、複数選択は宣言された選択肢の順序で選択を保持する。必須の dropdown は少なくとも1つの有効な選択肢を必要とする。オプションの dropdown で選択がない場合は _No response_ をレンダリングする。
checkboxes	表示ラベルとすべての選択肢を、宣言された順序で - [x] または - [ ] として保持する。個別に必須のチェックボックスを強制する。エージェントが検証可能な運用上の選択肢については、積極的にアクションを完了し、証拠を保持した上でのみマークする。エージェントは自身の証拠に基づく作業についてのみ明示的に証明でき、自身のアクションをユーザーに帰属させてはならない。個人情報、同意、法的宣言、その他一人称のユーザー主張については、明示的なユーザーの確認を必要とする。そのようなユーザー宣言には明示的な一人称の肯定を要求する。チェックボックスを画一的にチェックしてはならない。公開リクエストはチェックボックスを肯定しない。

各回答について、### <表示ラベル> の後に具体化された値をレンダリングする。textarea.attributes.render については、回答を宣言された言語とその内容に十分な長さのフェンスで囲む。回答、選択、確認、ラベルを決して発明してはならない。

Markdown テンプレートは、既知の証拠からのみ同じプライベート BODY_FILE に完成させることができる。一致するテンプレートがない場合は、ブランク Issue が明示的に有効になっている場合にのみ、レビュー済みの構造化されたブランクフォールバックを使用する。それ以外は公開せずに停止する。

レビューと公開

1回の作成試行の前に、ターゲット、タイトル、選択されたフォームまたは許可されたフォールバック、正確な本文、許可されたラベルをレビューする。エージェントは、公開の直前に正確な本文のプライバシースキャン/編集を完了し、その証拠を保持しなければならない。プライベートなプロジェクト名、ユーザー名、ホスト名、ホームパス、認証情報、プライベートネットワークアドレスを、再現構造を壊さずに有用なプレースホルダーに置き換える。

リポジトリの外部に、両方のプライベートファイル用の所有者のみの一時ディレクトリを1つ作成する。現在のユーザーに制限し、すべての終了/結果で両方のファイルをクリーンアップする:

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' "一時ディレクトリがリポジトリ内にあります" >&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' "一時ディレクトリがリポジトリ内にあります" >&2; exit 1 ;;
esac
chmod 700 "$TMP_DIR_REAL"
BODY_FILE="$TMP_DIR_REAL/body.md"
READBACK_FILE="$TMP_DIR_REAL/readback.json"

自動パスで1回のミューテーション試行を行い、正確に1回だけ公開する:

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

上記のフォーム判断でブラウザ完了が利用可能な場合、オプションとして別のブラウザハンドオフでリポジトリフォームを開くことができる。これは公開の証明にはならず、不正なスキーマや欠落/曖昧な必須回答への応答にもならない:

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

タイムアウト、ネットワーク障害、ID不明、その他の不確実な結果に対して再試行してはならない。返された Issue 番号を取得し、成功を報告する前に検証済みのターゲットホストから読み戻す:

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

読み戻しによってターゲットホストの Issue が識別され、タイトルと本文が CRLF→LF および末尾改行の正規化のみの差異で一致することを確認する。このターゲットホストからの読み戻しの後にのみ confirmed を報告する。権威ある拒否によって Issue が作成されなかったことが証明された場合は no_write を報告し、unknown の場合は以降のすべてのミューテーションを停止する。

トリアージ

Issue を承認またはクローズする前に、それが具体的で、重複しておらず、十分な証拠があり、スコープ内であり、リポジトリのラベル/ステータスポリシーと一致していることを検証する。いずれかの点が不明な場合は、リポジトリのレビュー状態を保持し、最小限の不足証拠を要求する。