Issue の起票者に、 聞いてはいけない質問がある タスク自走ハーネスの“質問の宛先”設計

1. の起票者に、 聞いてはいけない質問がある Issue タスク自走ハーネスの“質問の宛先”設計 @satoh_y_0323 ／ 個人OSS C3 (Claude Code Conductor)
2. AI 自走環境整備・運用スペシャル #4 餌ファイル”契約でタスクを自走させる “ 餌（タスク） ▶ headless 実行 ▶ サンドボックス実装 ▶ 提出 └ 情報不足なら 質問を書き戻して停止 タスク＝餌ファイル（Issue の抽象化：status 遷移・Q&A 履歴がファイルに残 る） 要件が空なら LLM 起動前に門前払い（品質はループの入口で担保） 1 タスク一周 数十秒・数十円、成果はブランチで回収 2
3. AI 自走環境整備・運用スペシャル #4 質問出口＝自走の生命線。では、宛先は？ 餌箱を Issue に置き換えれば、質問は Issue コメントへ → 起票者に届く 「エラーの再現手順は？」 → 起票者に聞く。自然 「例外処理はこのプロジェクトの流儀でいい？」 → 起票者に聞く……？ 3
4. AI 自走環境整備・運用スペシャル #4 質問には寿命があり、寿命が宛先を決める タスク寿命の質問 再現手順・仕様の細部 タスクと一緒に終わる 宛先：起票者 プロジェクト寿命の質問 判断原則・設計方針 タスクが終わっても生きる 宛先：メンテナ／リード 実話: AI が返した「外部参照する規約は参照先を必ず明記すべきでは？」 ——タスクの質問に見えて、プロジェクトの原則の提案だった 4
5. AI 自走環境整備・運用スペシャル #4 一人で回している間は、絶対に気づけない穴 暗黙の前提 回答者＝ 原則の承認者 一人二役なら成立 Jira/Wrike 要る Issue ➜ 化した瞬間 回答者は 外部の第三者になり得 る 前提が崩れる 起きること ➜ 起票者の回答で プロジェクトの原則が 書き換わる ＝権限昇格 の社内チケットでも同じ（起票者が QA・営業は普通）。信用の内側でも所有権の設計は 5
6. AI 自走環境整備・運用スペシャル #4 通知契約に「型と宛先」を持たせる 質問に型を付ける（task-question / axis-question） 2. 通知は「型 → 宛先の写像」を束縛（Issue コメント／メンテナ宛／Jira ロール） 3. 原則昇格の承認は権限で機械検証（GitHub author_association 等） 4. 軸の欠落はブロック／非ブロックを分岐（向き未定なら停止・提案なら進めて非 同期送付） 1. どのチケット管理でも要る、契約のコア仕様 6
7. 今日のひとこと 自走の境界線は「どこまで任せるか」 だけでなく、「誰に聞くか」にも引かれる。 ／ @satoh_y_0323 ／ つまずき報告がいちばんあ りがたいです C3 ─ pip install claude-code-conductor 7