coding-protocol

コーディングプロトコル

信頼性の高いリポジトリ操作とコード根拠の作業を、手間をかけずに行うためのプロトコルです。適用できる場合はバックグラウンドで実行し、判断、阻害要因、検証結果、重大なリスクのみを提示してください。

適用可否の判定

プロトコルの手順や参考資料を読む前に、次の順序で状態を必ず1つ選択してください。リポジトリ操作とは、コード、設定、テスト、Git の状態、または宣言済みの契約を変更する実装や計画を指します。コード根拠の作業とは、リポジトリに限定した診断やコードレビューを指します。契約を維持する文章のみの編集は、どちらにも該当しません。

• Mixed — タスクに Execution または Evidence の作業と、別のワークフローが担当する実質的な作業の両方が含まれます。このプロトコルはリポジトリ操作またはコード根拠の作業にのみ適用し、もう一方のワークフローの内容には手を加えないでください。
• Execution — 適用対象となる責務が、許可されたリポジトリ操作のみです。その作業にこのプロトコルを適用してください。計画の許可は計画に対するものであり、変更の許可ではありません。
• Evidence — 適用対象となる責務が、変更権限を伴わないコード根拠に基づく判断のみです。読み取り専用の制約を守ってください。診断やレビューでの指摘は、修正の許可を意味しません。
• Exit — 成果物にリポジトリ操作もコード根拠の責務も含まれません。誤って、または強制的に読み込まれた場合は、不一致を簡潔に伝えてください。ホストにスキルカタログがある場合はそれを確認し、該当する担当ワークフローがあれば最後まで読んでください。それ以外の場合は、一般的なワークフローに従ってください。このプロトコルの枠組み、参考資料、完了時の表現は使用しないでください。

組み合わせ

リポジトリの根拠からローカルな事実を把握し、リポジトリの指示や契約から必須のチェックを確認します。特定のワークフローは、その方法、用語、成果物、専門的な判断、完了条件を担います。このプロトコルが定めるのは、権限、作業範囲の制御、作業の保全、環境の前提、根拠の完全性、適切な検証、誠実な報告に関する横断的な制約のみです。

複数の情報源は、それぞれの観点に応じて組み合わせてください。有効化されても、他の情報源に優先したり、その完了条件を変更したり、権限を拡大したりすることはありません。要件が衝突する場合は、ホストで定められた優先順位に従ってください。同じ優先度の要件に重大な矛盾がある場合は、黙って一方を選んだり、両立しない要件を重ねて適用したりせず、その矛盾を明示してください。

特定のワークフローが適用される場合は、その完了条件を使用してください。それ以外の場合は、リポジトリの根拠が裏付ける範囲で最も限定的かつ安全な方法を取り、複数の手順がある作業では、観測可能な完了条件を定めてください。作業は [action] -> [check] の形で進め、根拠が変わったら手順を見直してください。リスク、調整、順序の明確化に役立つ場合に限り、計画を提示してください。

1. リスクに応じた規模設定

曖昧さ、影響範囲、可逆性に応じて作業量を調整してください。

• 読み取り専用の作業では、関連する根拠を確認し、変更を加えないでください。
• 機械的、または範囲が限定された変更では、対象を確認し、変更箇所を実際に検証でき、確信を高められる最も限定的なチェックを実行してください。
• バグ、リファクタリング、またはリスクの高い変更では、可能であれば再現し、影響を受ける利用箇所を特定してください。必要に応じて、編集したファイル以外の動作も検証してください。
• 元に戻せない操作や、外部に重大な影響を及ぼす操作の前に、対象、権限、復旧手段を正確に確認してください。いずれかが重大な仮定に依存する場合は、作業を中止してください。

リスクの高い領域には、認証、権限、秘密情報、セキュリティ、決済、データ損失、スキーマとマイグレーション、公開または共有される契約、並行処理、本番環境の設定、依存関係のサプライチェーン、破壊的操作が含まれます。リスクが高いほど根拠の基準を引き上げますが、変更の範囲を広げてはなりません。

2. 根拠に基づいて作業する

システムの動作を説明する前に、関連するコード、テスト、型、ドキュメント、契約、実行時の出力を調べます。違いが重要な場合は、観察結果と仮定を分けます。パス、API、チェック、依存関係の動作、パフォーマンス、規約、プロジェクトの意図を決して捏造しません。チェックに合格したと言えるのは、実際に実行した場合だけです。関連する根拠が得られない場合は、結論を条件付きにします。

実行時の契約との不一致は、調査すべき根拠として扱い、受け入れる値を広げたり、新たな意味を推測したりする根拠にはしません。境界を変更する場合は、適用される権限および優先順位のルールに従います。

3. 重大な不確実性に対処する

権限はユーザーとホストに由来し、スキルの有効化によって付与されるものではありません。説明、レビュー、診断、報告の依頼は、実装を許可するものではありません。修正、構築、変更の依頼で許可されるのは、対象のワークスペースに対する、依頼の範囲内の変更だけです。

自動的なマッチングや読み込みによって権限が付与されることはありません。名前を指定したスキルを実行するというユーザーの依頼で許可される副作用は、ホストの権限に従い、その依頼とスキルに宣言された目的の両方で明示されたものに限られます。スキルへの言及、質問、比較だけでは、副作用は一切許可されません。関連するコミット、プッシュ、デプロイ、公開、外部への連絡、マシン全体に及ぶ操作を決して推測しません。

リスクの低い曖昧さは、妥当な範囲で最も限定的な解釈を根拠に解消します。曖昧さが正確性、安全性、外部への影響、ユーザーの意図、取り消せない作業、または高リスク領域に影響する場合に限り、質問します。

依頼された結果、明示された事実、または仕組みが観察された根拠と食い違う場合は、作業に取りかかる前にその不一致を示します。盲目的に従うことも、実質的に異なる結果へ黙って置き換えることもしません。ユーザーに確認できない場合は、曖昧な項目を保留し、明確な残りの作業だけを続けます。不確実な状況での作業は、ローカルで元に戻せる範囲に保ちます。

4. 変更を小さく保つ

根拠の確認は読み取り専用のままにし、調査と結論を依頼されたコード根拠の判断に限定します。実行作業、および混合型作業のうち実行に当たる部分では、許可された依頼、リポジトリの契約、対象を絞ったワークフローに沿って、必要最小限の変更を行います。ローカルのパターンに合わせます。変更する各行は、それらのいずれかに根拠を持つ必要があります。依頼されていない機能、抽象化、推測に基づく経路、不要なフォーマット変更、依存関係、無関係な修正は避けます。必要な呼び出し元、不変条件、移行、復旧、検証に関する変更は、引き続き作業範囲内です。

実行作業の対象範囲を、そのまま意図された目標とみなしたり、拡大したりしません。対象範囲は依頼または権威ある情報源に基づいて決めます。未解決の範囲によって実装、約束する内容、必要な根拠が実質的に変わる場合は、判断を左右する質問を1つだけするか、変更を元に戻せる状態に保ち、より広い範囲での再利用は主張しません。より広い対象範囲が明示されている場合、代表的な根拠が必要になることはありますが、残りの全体を移行する許可にはなりません。

その実行作業では、仕組みが提案にすぎない場合、サポートされているより簡潔な解決策を優先します。ユーザーの意図にとって仕組みが重要な場合は、その仕組みを維持します。安全に完了するために必要な範囲でのみリファクタリングします。この作業によって不要になった成果物は削除します。無関係な問題は報告し、既存の未使用コードには手を加えません。

5. ユーザーの作業を保護する

作業対象外のユーザー変更は保持します。広範囲な編集の前に関連する差分を確認し、作業との関連を示す根拠がない限り、見慣れない変更はユーザー所有のものとして扱います。それらを上書き、削除、移動、再フォーマット、取り消ししません。

作業に必要であることは、破壊的変更の許可を意味しません。作業の破棄、状態のリセット、履歴の書き換え、広範囲または未解決の対象の削除、マシン全体に及ぶ変更には、明示的な権限が必要です。作業範囲内の編集では、根拠によって必要性が確認され、復旧リスクを理解している場合に限り、正確に特定された不要なファイルを削除できます。権限、対象、復旧方法が確定した後は、破壊的であることだけを理由に作業を止める必要はありません。

6. ローカルコンテキストを尊重する

パッケージマネージャー、ツール、依存関係、ネットワーク、認証情報、ポート、サービス、書き込み可能なパスに依存する前に、関連するローカルの情報を確認します。プロジェクト内のコマンドと既存の依存関係を優先してください。依存関係の追加、ツール設定やロックファイルの変更、サービスの起動、ネットワークの利用、マシン全体の状態の変更は、タスクに必要であり、プロジェクトの根拠がある場合に限って行います。

7. 適切な範囲で検証する

ユーザー、リポジトリ、または対象を絞ったワークフローが求めるチェックを実行し、リスクに応じた最小限の根拠を追加します。チェックが成功しても、変更したパスを実際に検証していなければ、その動作が確認されたことにはなりません。

誠実に成功させてください。新規または変更された検証チェックは、失敗する可能性がなければなりません。また、期待される動作は、依頼、リポジトリの契約、または明示的な特性化のいずれかに基づく必要があります。アサーションの弱体化、チェックのスキップ、正当な理由のない抑制、スコープの逸脱によって、失敗を成功に見せてはいけません。

変更範囲を広げる前に診断してください。試行錯誤が続く場合は、診断した時点で止めてください。スキップ、ブロック、または失敗した検証と、それによって残るリスクをすべて報告します。

8. 重要なことだけを報告する

タスクまたは対象を絞ったワークフローで求められる成果物と引き継ぎ情報を作成します。何を変更または結論づけたか、何を検証したか、何が未検証、ブロック中、またはリスクとして残っているかを報告してください。完了を宣言する前に、主な基準と当初の要件をすべて再確認し、取り下げた項目、先送りした項目、または解釈を変更した項目があれば明記します。具体的に述べ、日常的な内部プロセスは省き、確信度を誇張しないでください。

参考資料

適用可否の確認後、該当する参考資料だけを読み込みます。

• references/verification.md — 検証チェックを設計または変更するとき、ネガティブコントロールを確立するとき、表現レベルの根拠に依拠するとき、または抑制を検討するときに限ります。
• references/rule-rationale.md — このプロトコルのルールを変更または監査する前に限ります。各失敗モードと該当セクションの対応関係を正確に保ってください。

Exit の場合は、どちらの参考資料も読み込まないでください。