変更 (褐地・ブラウンフィールド)

新しいPRDを作成せずに、既存の仕様書とコードベースに対して、境界が明確でレビュー可能な変更を加えます。1つの変更は、1つの提案と厳密に1つの4ドキュメントタスクバンドルを生成します。QAが通過した後、確定した差分は仕様書に書き戻され、提案はアーカイブされます。このスキルはプロンプトファーストです。すべてのステップには手動によるフォールバックがあり、付属のスクリプトはオプションのヘルパーです。

パイプライン上の位置: spec-generator -> change -> task-decomposition -> plan-linter (ゲート1) -> review (ゲート2) -> dev -> qa -> converge -> アーカイブ

既存の仕様 + 境界が明確な変更
  -> .specs/change-context/standards.md        (standards_extract.py; 暗黙の制約)
  -> .specs/changes/<change-id>/proposal.md    (ライフサイクル: proposed -> applied -> archived)
  -> tasks/<change-id>/01..04                  (1コントラクト、1バンドル)
  -> ゲート1 plan-linter -> ゲート2 review -> dev <-> qa -> converge -> アーカイブされた提案

使用するケース

既存の仕様書や出荷済みのコードベースに対して、段階的な変更（バグ修正、小機能、動作調整、境界が明確なNFR調整）が必要な場合。
変更が既存の#sec-*アンカーを再利用でき、マイクロ/標準の差分予算に収まる場合。
このリポジトリの4ドキュメントタスクプロトコルとファイルごとの単一所有者ロールを維持しながら、提案 -> 適用 -> アーカイブのループを実行したい場合。

使用しないケース

作業が新規開発（グリーンフィールド）であり、上流の仕様書がまだ存在しない場合。prd-generator、次にspec-generator、次にtask-decompositionを使用してください。
変更に新しいアーキテクチャ決定、新しいコンポーネント境界、新しい横断的不変条件、またはまったく新しい仕様セクション（新しい#sec-*アンカー）が必要な場合。変更にすり込まずにspec-generatorにエスカレーションしてください。
承認済みの仕様をタスクに分割するだけでよい場合。task-decompositionを使用してください。
既存のバンドルや提案を監査するだけでよい場合。plan-linterを使用してください。
タスクがすでに計画されており、実装/検証を待っている場合。dev / qaを使用してください。

入力

ベース仕様書: デフォルトでは .specs/02-tech-spec.md (およびそのモジュール部分)。
依頼者が平易な言葉で記述した、境界が明確な変更の要件。
ステップ1で生成されるリポジトリ規約レポート。
オプション: 変更が継続する既存のタスクバンドル、および関連するADR。

出力

成果物	スキャフォールディング後の所有者	目的
`.specs/change-context/standards.md`	ツール	決定論的なリポジトリ標準と暗黙の制約（生成され、手動編集不可）。
`.specs/changes/<change-id>/proposal.md`	プランナー	境界が明確な変更の提案: 動機、差分、影響範囲、不変条件/NFR、ロールバック、検証。
`.specs/changes/<change-id>/convergence.md`	統合ツール	QA通過後に記述。何が仕様に折り返されたかを記録。
`tasks/<change-id>/01-contract.md` ... `04-process.md`	プランナー / 開発 / QA / ツール	厳密に1つの4ドキュメントバンドル。task-decompositionテンプレートを再利用。

提案はPRDではなく、仕様の代替でもありません。これは変更する既存のアンカーを指定する差分です。完全なライフサイクルとサイジングルールについては、references/brownfield-protocol.mdを参照してください。

ワークフロー

リポジトリ標準を抽出する (設定変更ごとに1回):
```
python .agents/skills/change/scripts/standards_extract.py --repo-root . --json
python .agents/skills/change/scripts/standards_extract.py --repo-root . --check
```
計画を立てる前に.specs/change-context/standards.mdを読んでください。その「暗黙の制約」セクションは拘束力があります。証拠のあるコマンドのみを使用し、宣言されたテストレイアウト、ランタイム最低要件、既存のアンカーを尊重してください。--checkの終了コード1は、レポートが古くなっていることを意味します。計画を立てる前に再生成してください。レポートを手動で編集しないでください。
提案と1つのタスクバンドルをスキャフォールディングする (ファイルを書き込む唯一のステップ):
```
python .agents/skills/change/scripts/scaffold_change.py \
  --change-id CHG-001-rate-limit \
  --title "Rate limit login attempts" \
  --anchor "#sec-auth-tokens" \
  --kind modify \
  --size-class micro --estimated-lines 40 \
  --touch-files "modify:src/auth/rate_limit.py" \
  --repo-root .
```
スキャフォルダーはベース仕様に対してアンカーを検証し、base_spec_sha256を計算し、task-decomposition (scaffold_task.py) に委任するか、それが無ければ最小限のインラインバンドルを生成します。プレビューには--dry-runを、使い捨ての実行を上書きするには--forceを使用してください。
プランナーが提案とコントラクトを記入します。 提案内のガイド (motivation、[CHG-<n>]ハンク、パス、不変条件/NFR、ロールバック、検証) とコントラクト内のプレースホルダー (module、adherence_adrs、dod、エッジケース、不変条件の説明文) を置き換えます。パスやアンカーをでっち上げないでください。02/03は空欄のロールフォームのままにし、提案のstatus: proposedは維持してください。

ゲート1、次にゲート2。 決定論的なゲート1を実行し、次に独立したセマンティックレビューを実行します:

# リポジトリルートから実行します。ゲート1ヘルパーはplan-linterスキルがインストールされている必要があります。
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks --repo-root . --spec .specs/02-tech-spec.md --changes-dir .specs/changes
python .agents/skills/change/scripts/lint_change.py --change-id CHG-001-rate-limit --repo-root .

実装前にゲート1が合格している必要があります。ゲート2はBLOCKEDまたはREQUEST CHANGESを報告してはなりません。

実装と検証。 dev (宣言されたtouch_filesのみ、02の記入、引き継ぎ) とqa (tests/acceptance/下での独立したテスト、03の記入、1つの判定) を実行します。実装と検証が合格すると、提案はappliedに移行します。
統合とアーカイブ。 QA_PASSED後、convergeを実行して確認された逸脱を.specs/02-tech-spec.mdに追記し、convergence.mdを書き込み、バンドルをtasks/archive/に移動し、提案のstatus: archivedを設定します。convergeがない場合は、手動で同じ追記書き戻しを実行します。

手動フォールバック (Pythonなし)

ハンドリストで標準リストを作成: リポジトリルート設定、テスト/ソースツリー、ランタイム、#sec-*アンカー。
assets/templates/proposal.template.md を .specs/changes/<change-id>/proposal.md にコピーし、すべてのトークン ({{...}}) を記入し、base_spec_sha256 を計算します。
task-decomposition テンプレートまたは references/brownfield-protocol.md のフォールバックを使用して、tasks/<change-id>/ 4ドキュメントバンドルを作成します。
ゲート1 / ゲート2のチェックリストを手動で実行し、証拠をバンドルに記録します。
同じ成果物を使用してワークフローステップ5～6に従います。

品質ゲートチェックリスト

標準レポートが生成され、最新である (standards_extract.py --check が0で終了する)。
提案のフロントマターが完全で、status: proposed、kind が正しく、base_spec_sha256 が最新である。
すべての [CHG-<n>] ブロックがベース仕様に存在する実際の #sec-* アンカーを指定している。
厳密に1つのタスクバンドルが存在し、change_id が提案IDと等しく、origin_spec_anchor が提案の impact_anchors の1つである。
差分予算が守られている: マイクロは1タッチファイル (デフォルト10-49行)、標準は1-3ファイル (デフォルト50-250行)。数値はplan-linter設定で設定可能。
ゲート1が記入済みのコントラクトに合格し、提案がオープンである (proposed/applied)。
ゲート2レビューにブロッキングな発見事項がなく、レビュアーは独立しており読み取り専用である。
開発者は宣言された touch_files のみを実装し、QAは証拠を添えて厳密に1つの判定を発行した。
統合により差分が仕様に追記され、提案が archived になっている。

ハルシネーション防止ルール

ファイルパスを決してでっち上げないこと。 すべての touch_files エントリは、modify するための既存ファイル、または create するための既存ディレクトリ内の新しいファイルでなければなりません (リポジトリ相対、フォワードスラッシュ)。
すべての差分ハンクは実際のアンカーを指定すること。 既存の #sec-* アンカーを再利用してください。スキャフォルダーとリンターは、存在しないアンカーやドリフトしたアンカーを拒否します。
コマンドや規約をでっち上げないこと。 宣言された設定 (標準レポート) によって証拠のあるコマンドのみがコントラクトのDoDに現れることができます。
構造的な変更はエスカレーションすること。 変更に新しい仕様セクション/アンカー、新しいコンポーネント、新しいADR、または不変条件の変更が必要な場合は、中止して spec-generator を使用してください。
ゲートを過大評価しないこと。 ゲート1は決定論的な帳簿整理であり、ゲート2はプロンプトレビューです。git と CI が引き続き権威を持ちます。

ヘルパースクリプト

scripts/standards_extract.py — 決定論的な標準抽出ツール。.specs/change-context/standards.md を書き込みます (--json、--check、--dry-run、--version)。
scripts/scaffold_change.py — 提案と1つのタスクバンドルを作成します (--dry-run、--force、--json、--version)。
scripts/lint_change.py — 提案/バンドルの一貫性とベース仕様のドリフトチェック (--json、--version)。

すべてのヘルパーはstdlibのみに依存し、自身のディレクトリを解決し、終了コード 0 (成功)、1 (ゲート失敗)、2 (使用法エラー)、3 (予期しないエラー) で終了します。

失敗処理

ベース仕様がない場合: 停止。褐地変更にはベース仕様が必要です。スキャフォルダーはコード2で終了します。
未知のアンカー: 停止。既存のアンカーを再利用するか、spec-generator にエスカレーションしてください。
古いレポートまたは仕様のドリフト (終了コード 1): レポートを再生成し、提案をリベースし、ゲート1を再実行してください。base_spec_sha256 を手動で編集しないでください。
変更ディレクトリが存在する: 使い捨ての場合のみ --force を付けて再実行してください。それ以外の場合は既存の提案を編集してください。
スクリプトが利用できない: 手動フォールバックに従ってください。ワークフローはプロンプトファーストです。

正直な限界

標準レポートは宣言された設定を説明するものであり、必ずしも実施されている慣行を説明するものではありません。これはプランナーへのプロンプトであり、準拠の証明ではありません。
base_spec_sha256 はベース仕様へのあらゆるバイト変更を検出します。統合後、アーカイブされた提案はドリフトチェックの対象外となります。
オプションのスクリプトはバイパス可能です。CIとリポジトリの権限が引き続き権威を持ちます。

Change (Brownfield)