Delivery architecture

English | 日本語

通常 path

GitHub Issue
  → exact Issue-linked branch と registered worktree
  → focused implementation check
  → review-stable required profile
  → exact head SHA の Pull Request
  → exact-head hosted validate
  → eligible merge
  → Issue/check/commit readback
  → remote/local topic branch cleanup

GitHub と Git が system of record です。通常作業は main へ直接 push しません。既存の user change を include/test/remove しません。hosted validation が failed/skipped/stale/unavailable の場合は、 isolated self-hosted runner/workflow が新しい exact-head success を生成するまで acceptance を block します。

Verification の関係

focused check は反復用の速い証拠、required profile は review-stable repository candidate の証拠、 merge acceptance は Pull Request head に結び付いた証拠です。release gate は累積的かつ merge とは別です。

disposable self-hosted runner は host mount、Docker socket、delivery credential を受け取りません。 local test result は iteration evidence であり、merge evidence にはなりません。

実行可能な contract は trusted deliveryです。 現在の candidate request identity は current-only の ai-teams-delivery-request/v1 で、以前の未リリース identity は拒否します。

再発対策の受入れ

終了処理では、観測された再発事象を「学習候補」「操作ミス」などの分類にかかわらず 追跡します。未解決の事象には、実際に開いている独立した Issue が必要です。 終了対象の Issue 自体を未解決の追跡先としたまま閉じることはできません。

今回の Issue での恒久対策は、事象ごとの受入れ証拠に基づきます。実際の Issue コメントに 記録された障害系列、現在の受入れ条件、レビューした原因・修正・回帰検証、採用された リビジョンを結び付け、保存前にその対応関係と PR の成果物を読み戻します。 CI の成功だけで因果関係が正しいとは判断しません。対策が原因に効くかは引き続き 担当者のレビューが担い、ソースの提供と後日の有効性確認を分離します。

事象がない通常の経路では、追加のプロバイダー読取りや手書きの申告ファイルは不要です。 再発事象の機械的な申告項目と、効果が未確認であることを示す追跡情報は終了処理側が生成し、 証拠の補完や対策の選択は行いません。 実行契約と 設計議論 #1220を参照してください。 ホストでの事象の自動捕捉、終了処理全体の段階別復旧は、 今回の最初の改修には含まれません。

作業準備の操作入口

設計議論 #1220 の次の改修では、既存の prepare_workspace.py を入口に保ちます。 変更を行わない --describe が正規の説明、実際の引数定義、通常実行と共有する条件を返します。 不足・矛盾した入力にも、リポジトリの読取りや準備を始める前に同じ案内を返します。 利用できないローカルPythonはworktree作成前に拒否し、有効な仮想環境のパスは維持します。

説明の取得は読了の証明でも編集許可でもありません。ホスト・ユーザーポリシー、厳密な worktree照合、実行環境検査、claim、一回限りの編集leaseは引き続き必須です。 有効な通常呼出しには新しい証明書や説明取得を追加せず、入力形式の知識を既存の入口に集約します。 操作契約を参照してください。 インストール済み環境への採用と後日の有効性確認は未完です。ソースの受入れだけで 作業全体の高速化を達成したとは扱いません。

検索、PR事前検査、終了処理の再開

検索操作の search --describe と search-github --describe は、検索条件を検証する 同じ担当モジュールから入力スキーマと例を返します。誤入力にも同じ契約を提示し、SQLiteや 外部サービスに触れる前に停止します。通常の呼出しに説明取得や新しい入力文書は不要です。

リポジトリの品質検査は、既存のCI実行前にPRの受入れ項目、Issueとの関連、設計契約を まとめて確認します。--describe が既存の設計入力文書を案内し、 run --profile ci --pr-input INPUT が既存のローカル隔離モードを選び、実際のoriginと 変更のない正確な候補を実行前後に照合します。 渡されたIssue本文はローカルのスナップショットです。マージには引き続きGitHub上の読戻しと 候補そのものの validate 成功が必要であり、検証ポリシーは二重化しません。

完了した作業では、ポリシーに沿うcleanupを最終証拠より先に実施します。終了処理は残存する 作業ディレクトリからローカル・リモートの対象参照と、detached状態も含む正規worktreeを確認します。 正規の keep はローカル作業の保持として記録し、ask は既存の選択を必要とします。 Blocked/Failedの作業は保持し、完了したcleanupとは表現しません。

保存先は同じ不変の内容を読み戻してから書き込みます。一致する保存済みデータは再利用し、 新しいIssueコメントは既存の操作レシートと厳密な読戻しを通します。応答喪失や保存後の読戻し失敗は 保存先の照合から再開し、成功済みの書き込みや実行履歴全体の再構築を繰り返しません。 前回の操作が不確かなまま保存内容を確認できない場合、再書き込みを止めます。 終了処理用の第二の台帳、スケジューラー、自動的な原因解消の承認は追加しません。

これらは設計判断 #1220の残る操作境界の改修です。 インストール済みホストへの採用、未対応ホストのイベント収集の完全性、後日の再発防止効果は、 ローカルテストやマージだけでは確認済みにしません。

統一ステータスと Decision Inbox

有限操作 decision_inbox.py は、GitHub の上限付き取得、既存の product marker・ 再構築処理、Project State を結合します。ai-teams-decision/v2 は同じ Goal・Bet に属する作業の対象範囲と案内を追加し、v1 は移行が必要な案内として読み続けます。 保留は判断待ちから導出するだけで、worker や許可の権限を取得しません。 未関連付けの open Issue は、関係を推測せず別に表示します。

回答操作は GitHub の revision 検査付き更新と操作 receipt の既存所有者を使い、 Issue 本文の周囲の記述を保持して、1回の正確な readback を確認します。 書き込み直前の読み取りは GitHub の原子的 compare-and-swap ではありません。 競合する更新は呼び出し側で直列化し、不確かな結果を自動再試行しません。 任意の Control Lite 参照は読み取り専用接続とリポジトリの絞り込みを使い、 スキーマ作成、lease 復旧、ジョブ変更を行わず、payload や lease token を出力 しません。上限、ライフサイクル、互換性、権限は 正規契約 を参照してください。

成果評価と次の Bet の提案

outcome_evaluation.py は既存の配備記録、Observation Plan、Control Lite のジョブ、 プロダクトの状態遷移を接続します。明示的な観測予約には、公開成功の記録と現在の Goal・Bet・観測計画のリビジョンが必要です。観測開始時刻より前にはジョブを開始せず、 取得には Evidence Source 側の読取り権限を使います。技術的な配備検証だけで成果を 確認済みとは扱いません。

証拠のリビジョンに結び付けた意味評価を、確認・反証・保留・取得不能として記録します。 確認または反証された成果証拠だけが、合法な Bet 状態遷移と判断待ちの Decision を提案します。 観測不足や実装失敗から次の Bet は提案せず、Goal の前提が反証された場合も、Goal を 自動変更せず判断を求めます。外部への更新には、最新の正規リビジョン、因果関係のレビュー、 別途認められた書込み権限が引き続き必要です。

任意の Control Lite 拡張は、同じ証拠のリビジョンを一度だけ評価します。再起動後は元の 提案を回復でき、新たな再計画を重複生成しません。正規プロバイダーに既存の Decision が あれば、その識別子でも重複を防ぎます。有限の CLI 操作はバックグラウンド worker を 開始せず、外部書込み・配備・認証情報・承認の権限を付与しません。スキーマ、上限、 再実行時の挙動と成果の有効性確認の限界は 正規の成果評価契約 を参照してください。