Project Steward は何をしますか？
役割とルーティング
Project Stewardは、プロジェクト間で再利用可能なガバナンス手法を保存します。プロジェクト自身の製品決定、アーキテクチャ上の事実、長期的な制約はプロジェクトの既存の真の情報源に残ります。ユーザーとマシンの可変的なツールの事実は、プロジェクトとスキル外の環境ファイルに残ります。
まずユーザーが得たい結果に基づいてメインパスを選択します。同じリクエスト内の独立した結果は、それぞれ個別に帳簿を作成します。
- 過去の会話、修正、完全な実施プロセス、または対象スキルの機能境界：対話学習と自己進化。
- 機能、リファクタリング、移行、または階層間の変更開始前の手戻り排除：変更前予防。
- 欠陥、中途半端な移行、繰り返しの修正、実際のリンクの障害、または凝集性、結合、重複、神クラスのチェック：根本原因ガバナンス。
- プロジェクトと外部CLI、実行ツール、またはプロトコルとの互換性関係のチェック、接続、修正：外部ツール互換性。
- リポジトリ、ディレクトリ、またはソースコードパッケージの用途、アーキテクチャ、機能の理解、またはリファレンスプロジェクトの調査：プロジェクト調査と解説。
- プロジェクトディレクトリの棚卸し、整理、実際の使用状況、生成状態、無視、移動、アーカイブ、削除の境界の判断：プロジェクトディレクトリガバナンス。
- プロジェクトテンプレートの作成、採用、アップグレード、チェック：プロジェクトベースラインとテンプレート。
- 安定したデフォルトをテンプレートに書き込む：テンプレート進化。
- 製品体験とインターフェースの定義、レビュー、再構築、実施：製品体験とインターフェースガバナンス。
- READMEの監査、書き直し、またはGitHubホームページのビジュアル制作：READMEとホームページ。
- プロジェクトログ、LLM記録、長期記憶、TTS、またはログビューアーの結果のガバナンス：人間中心のログ。
- Gitの初期化、リポジトリ作成、コミット、プッシュ、可視性の変更、またはリモートの検証：リポジトリ作成と公開。
- ライセンスとサードパーティ認可の選択、適用、一括ガバナンス：ライセンスガバナンス。
- ユーザー環境ファイルの作成または消費、ツール、キャッシュ、SDK、ターミナル、長時間タスクのチェック：ユーザー環境ファイルと実行環境。
- 実装計画に基づく項目ごとの完了度チェック、または全体チェック、プロジェクト健全性の判断、プロジェクトレベルのリスクの並べ替え：プロジェクト総合監査。
このスキルを指名するだけの場合は、既存の資料から最も適切なパスを選択します。資料が不十分な場合は、コンテキストに近い直接的なリクエスト例を示して停止します。
メインパス選択後、プロジェクトへの書き込みや専用実施の前に、ルーティング帳簿を作成します：ユーザーの最終結果、メインパス、固定の必読方法、条件付き専用項目とそのトリガー根拠、アクションの閾値、正式な消費者、受け入れ、停止位置。固定の必読方法は、部分的な修正が明白に見えるからといってスキップできません。条件付き専用項目は、適用可能な証拠が得られた場合にのみ追加します。同じリクエストで後から受け入れ項目が追加された場合は、元の帳簿を更新します。最新の症状でまだ有効な範囲を置き換えてはいけません。
共通の境界
- 通常のビジネス機能は現在の開発タスクが担当します。ユーザーが単一のエラー、単一の関数、または部分的な動作の説明のみを要求した場合、その結果への回答後は停止し、プロジェクトレベルの改造にエスカレーションしません。リクエスト自体が予防、ガバナンス、移行、自己進化、またはプロジェクトレベルの結果を要求している場合にのみ、対応するパスに入ります。
- パス選択後、直ちに範囲、書き込み権限、停止位置を固定します。チェック、監査、診断、評価、分析、レビュー、レポートはデフォルトで読み取り専用です。同じリクエストで明示的に修正、ガバナンス、実装、変更、更新、自己進化が要求された場合にのみ、対応する書き込み権限を取得します。
- ユーザーがソースコードアーカイブを提供し、プロジェクトの理解、監査、調査を要求した場合、またはこのスキルのみを指名してソースコードアーカイブを添付した場合、解凍は読み取り専用調査に必要な資料準備であり、プロジェクトへの正式な書き込みではありません。直接「プロジェクト調査と解説」に従ってターゲットルートを決定し、既存のスクリプトを実行して名前重複を避ける独立したディレクトリに解凍し、スクリプトから返されたプロジェクトルートを読み取って読み取り専用調査を続行します。追加の解凍確認は不要です。このアクションは、調査用コピーの作成とその内容の読み取りのみを許可します。プロジェクトの実行、依存関係や解凍ツールのインストール、プロジェクトの変更、元のファイルの移動・削除、コミット、公開は、それぞれ個別に許可が必要です。
- インターネット接続、ダウンロード、インストール、実行、生成、書き込み、移動、アーカイブ、削除、コミット、プッシュ、公開は、それぞれ個別に許可されます。このセクションで後ほど明記されるデフォルト完了契約のみが、同じユーザー結果内での書き込み、コミット、プッシュ、リモート受け入れを一括で許可できます。実行や生成はプロジェクトへの書き込み権限とはみなされません。デフォルト完了契約以外では、コミット、プッシュ、公開は、既に存在し正確に確認された変更のみを処理することを許可し、以前の書き込みを遡って許可したり、無関係なワークツリーの変更を含めたりしません。
- ユーザーがリクエスト内で明示的にProject Steward（
$project-stewardの呼び出しを含む）を指名し、既存のGitプロジェクトに対する変更、修正、ガバナンス、更新、最適化を明示的に要求し、現在のブランチにupstreamが設定されており、ユーザーがローカルのみの変更、コミットしない、プッシュしない、またはより早い停止位置を要求していない場合、このラウンドの実装はデフォルトで以下まで完了します：許可された依存クロージャの検証、正確なコミット、現在の追跡ブランチへの非強制プッシュ、その後リモートHEADと主要な消費者を確認。ローカル検証後、プッシュの可否を再度確認することはありません。読み取り専用リクエスト、暗黙的なルーティング、upstreamなし、リモート作成、可視性変更、削除、強制プッシュ、履歴書き換え、パッケージング、デプロイ、無関係なワークツリーの変更は、このデフォルトでは許可されません。references/repository-publication.mdに従い、フォーク、出所不明の変更、無許可の削除、資格情報、検証、認証の失敗時は停止します。 - ユーザーがProject Stewardの自己進化案を確認し、ローカルのみの変更を要求していない場合で、現在の追跡リモートが存在する場合、現在のワークスペース全体を分割不可能な公開範囲としてデフォルトで扱います：追跡済みの全変更、未追跡ファイル、既存の削除を検証し、
git add -Aを使用してまとめてコミットし、現在の追跡ブランチをプッシュします。いずれかの項目が共同公開できない場合は、完全なワークスペースを保持して停止します。このデフォルトは、リモート作成、強制プッシュ、可視性変更、または新しい削除の実施を許可しません。 - ユーザーが既存のGitHubリポジトリに対してStar Historyの接続、置換、または修復を明示的に要求した場合、確認された契約にはデフォルトで、今回許可された依存クロージャのコミット、プッシュ、リモート受け入れが含まれます。ユーザーが明示的にローカルのみの変更を要求しない限り、書き込み検証後に公開許可を再度待つことはありません。このデフォルトには、リモート作成、強制プッシュ、可視性変更、削除、または無関係なワークツリーの変更は含まれません。
- 各ユーザーターン、内部ラウンド、自動再実行、コンテキスト圧縮再開の開始時は、ツール呼び出しや状態変更の前に、常に最新の明確なユーザーアクションから未完了の結果、範囲、権限、停止位置を復元します。同じ結果がまだ納品されておらず、範囲、影響チェーン、権限が変更されていない場合のみ続行します。読み取り専用の結果が既に納品されている、新しい明確なアクションがない、ユーザーが結果を変更した、無関係な質問が発生した、または新しい権限が必要な場合は、停止して確認を待ちます。監査結果、アシスタントの提案、内部計画、目標名、TODOリスト、自動プロンプトは、新しい結果や書き込み権限をでっち上げることはできません。
- 作業が短いアクションからマルチステージに拡張されたり、待機状態になったり、証拠の状態が変化した場合は、拡張理由、完了したチェックポイント、現在の状態、次の観察可能な結果、必要な入力を能動的に説明します。状態が変わらない場合は、繰り返し画面を埋めず、フロー説明で範囲拡大を隠すこともできません。
- 新しい独立したリクエストが未完了の結果を置き換える場合は、最初に既に書き込まれたり変更されたオブジェクト、既存の証拠、未検証のユーザーコミットメント、実行中のプロセス、残留物、元の権限、停止位置を引き継ぎます。新しいリクエストは、古い結果の継続、ロールバック、クリーンアップを許可しません。
- 最初に正確なプロジェクトルート、資料範囲、アクティブファイル、実際の消費者を固定します。Gitは、正確なプロジェクトルートに直接
.gitが存在し、現在のパスが歴史、ワークツリー、または公開の証拠を必要とする場合にのみ使用します。 - ソースは明確な末尾まで読み取る必要があります。長いファイルは、最初に行数、バイト数、またはページング機能を取得し、安定した間隔で完全に読み取ります。並行する変更が動作契約、影響ファイル、コンシューマー、検証、またはユーザー結果に影響を与える場合、古い確認は無効になり、再計画と確認が必要です。
- 複数の相互に独立したプローブは、オーケストレーターが各項目の出力、エラー、終了ステータスを個別に保持できる場合のみ並行実行します。いずれかの項目がバッチ全体を早期終了させる場合は、個別実行に変更します。バッチ失敗後も、まだ有効な成功証拠は保持し、隠蔽された、未実行、または状態不明の項目のみを個別に再実行します。
- プロジェクトの事実は、プロジェクトの既存の唯一の真の情報源に書き戻します。環境の事実は、独立したユーザーファイルに書き込みます。移行可能なガバナンス手法のみがこのスキルに入ります。テンプレートは、ある種のプロジェクトが毎回実行すべき安定したデフォルトのみを受け入れます。
- 履歴や外部資料中の能力が既に存在するかどうかを判断する場合、最初に独立した結果への分割と必要な因果順序付けを完了し、次にソースを隠して、ターゲットが同じ条件を認識できるか、同じ構成的詳細を保持しているか、同じ具体的な処理を行えるかを確認します。上位のガバナンスフレームワークのみが部分的に備えているとみなします。項目ごとの比較を完了した後でのみ、共通メカニズムと特殊な次元を抽出します。
- 検証は、変更のリスクに応じて階層を選択します：最初に、今回の変更と受け入れ主張を直接カバーするターゲットチェックを実行します。ドキュメント、ライセンス、謝辞、または純粋なメタデータのみの変更は、対応するメンテナンスエントリを通過した時点で停止し、無関係なブラウザやエンドツーエンドのリンクを起動しません。パブリックコントラクト、コアランタイム、リポジトリ間の境界、公開、またはターゲットチェックがシステムレベルの影響を明らかにした場合のみ、完全な回帰テストと実際のユーザーチェーンにアップグレードします。
- 状態変更後は、直接権威あるターゲットを読み戻します。検証の完了は、正式なプロデューサー、転送・ストレージ境界、コンシューマー、ユーザーが観察可能な結果に沿って行います。コンシューマー側にダミーデータやモックを使わせて、検証中のコアリンクをすり替えてはいけません。
- テスト結果をコミットメントのクローズや完了宣言に使用する前に、期待される主要なテストIDが、テストフレームワークが実際に収集した一意のIDと一致している必要があります。IDが欠落しているか一意でない場合は、未カバーとマークするのみです。
- 設定、実行レポート、構造化成果物、またはログを診断のために読み取る場合、
references/log-audit-standard.mdに従い、最初に現在の判断に必要な許可フィールドを投影します。未知の構造をそのまま再帰的に出力してはならず、資格情報はツール出力、会話、または診断エクスポートに入る前にマスキングする必要があります。
対話学習と自己進化
最初に references/conversation-learning-and-self-evolution.md を完全に読み取ります。
いずれかのユーザー結果に失敗、修正、保護インターセプト、一時的な回避策、残留物が含まれる場合、さらに references/root-cause-remediation.md を読み取ります。読み取り順序は固定です：結果に沿って完全なプロセスを復元し、因果階層に沿って主要な学習テーマと独立した二次結果を決定し、次に将来のガバナンスを変更する具体的な詳細を復元し、共通境界に従ってターゲット能力を項目ごとに比較し、その後共通メカニズムと特殊な次元を抽出し、移行可能性、機能境界、正式な所有者を判断し、最後に歴史的責任を判断します。回避策と残留物は、より早くかつ証拠が成立する制御可能な根本原因を上書きできません。後続の修正が主な原因を変更した場合、既存の計画と確認は直ちに無効になります。成功結果のみでこれらの信号が存在しない場合、根本原因メソッドはロードしません。
能力の比較は、まず「メソッドの欠落」と「既存のメソッドがルーティング、実行、または受け入れられていない」を区別する必要があります。前者は唯一のメソッド所有者のみをその場で強化します。後者は、最初に故障したメインルート、アクション閾値、正式なコンシューマー、または検証のみを修正し、他のファイルに同義のルールを追加しません。計画は所有者と消費チェーンに従って編成され、会話の出現順にパッチを積み上げるのではありません。
ユーザーが分析のみを要求する場合は、読み取り専用を維持します。吸収、自己進化、更新、最適化、またはProject Stewardの反復を明示的に要求する場合は、最初に将来の動作、機能境界、代表的な出力、影響ファイル、検証方法を提示して停止します。ユーザーがその計画を確認した後にのみ、アクティブなスキルを変更します。計画がローカルのみの変更を宣言していない場合、同時に references/repository-publication.md を読み取ります。現在の追跡リモートが存在する場合、ワークスペース全体を実際の影響に基づいて検証し、git add -A を使用して追跡済みの変更、未追跡ファイル、既存の削除をまとめてコミットし、現在の追跡ブランチをプッシュし、リモートHEADとワークスペースに漏れがないことを確認してから完了します。リモート、認証、ブランチ保護、フォーク、検証失敗、またはいずれかの項目が共同公開できない場合は、完全なワークスペースを保持し、正確な境界で停止し、選択的なコミットに戻りません。
Project Stewardの自己進化時は、メインファイルの制約を実行する必要があります：
- 書き込み前に、SKILL.mdの行数、文字数、直接のreference集合を記録し、新しい各ルールに一意のアクティブな所有者を割り当てます。
- SKILL.mdは、ルーティング、トリガー条件、読み取り順序、権限、出力、停止位置のみを所有します。完全なメソッド、テーブル、チェックリスト、例外は、対応するreferenceが一意に所有し、メインファイルは直接リンクのみを保持します。
- 書き込み後、SKILL.mdは220行または14,000文字を超えてはならず、すべてのアクティブな機能に直接到達可能であることを維持します。新しいルートが予算を超過する場合は、同じ変更内で古い詳細を移行またはマージする必要があります。
- 予算内で既存の機能、正式なコンシューマー、検証を維持できない場合は、書き込みを停止し、再計画し、完了を宣言してはいけません。
変更前予防
最初に references/change-prevention.md を読み取ります。これがターゲット動作、唯一の真の情報源、影響グラフ、最終インターフェース、古いパスの終了、実際のユーザーチェーンによる受け入れを担当します。問題に応じて以下を追加で読み取ります：
- 永続的操作、キュー、またはスケジューラーにおける有界バッチとバックログの排出、回復、再起動、バッチ成果物、または常駐ステートフルサービスにおける発見可能なセッションと共有リソースの並行アクセス、解放、クローズ：
references/durable-operation-governance.md - タスクの状態、進捗、または自動再実行：
references/task-progress-governance.md - 高コストの結果を段階的に提示、確認、連続自動実行、または上流の変更による無効化が必要な場合：
references/staged-result-governance.md - 同じ結果が複数の仕様、計画、タスク、または研究成果物で表現され、それらの進化関係を決定する必要がある場合、または派生成果物、セマンティックキャッシュ、作業単位の分割、リソースプール利用、重複するエージェントオーケストレーションが含まれる場合：
references/derived-artifact-governance.md - プロジェクトレベルのCIにおける検証計画、実行環境キャッシュ、テストリソース階層化、時間がかかるシャーディング、早期失敗、正確な再実行：
references/ci-execution-governance.md - 実行中の設定が共有サービス、プロバイダー、ストレージルート、またはコンポジショングラフを再構築する場合：
references/runtime-generation-governance.md - 再現困難、タイミング、並行性、バックプレッシャー、または高価な完全チェーン：
references/hard-to-reproduce-diagnostics.md - 外部、永続化、モデル、ネットワーク、またはプロセス間のJSONに、複数のパースポイント、容量問題、アトミックシャーディング、リプレイカーソル、またはコントラクトの曖昧さが存在する場合：
references/structured-data-boundary.md - モデルがタスク判断、状態表現、ランタイムイベント、または構造化応答に関与し、メッセージソース、役割、ルーティング、インラインリクエスト、プレゼンテーション責任を確認する必要がある場合：
references/model-mediated-operation-governance.md - 外部ソースコードを一度限りの出発点として独立した製品を構築する場合、またはその拡張エコシステムを選択的に吸収する場合：
references/source-fork-and-ecosystem-adoption.md。コードを実際にコピーする場合は、同時にreferences/license-governance.mdも読み取ります。 - 製品体験またはインターフェース：
references/product-experience-governance.md。設計またはインタラクション手法が必要な場合は、さらにreferences/ux-design.mdを読み取ります。
ユーザーが明示的に実装を許可した場合のみプロジェクトを変更します。計画のみが要求された場合は、影響グラフ、ターゲット境界、移行順序、受け入れ契約の段階で停止します。
根本原因ガバナンス
最初に references/root-cause-remediation.md を読み取ります。診断は証拠、影響範囲、最終的な修正方法で停止します。実装は、すべてのプロデューサー、境界、コンシューマーを一度に移行し、古いアーキテクチャを終了します。問題に応じて以下を追加で読み取ります：
このタスクが以前の総合監査を引き継いで修正する場合、またはユーザーがその監査のすべての問題の修正を明示的に要求した場合、元の監査の引き継ぎ帳簿は引き続き完了契約として機能します。書き込み前に references/change-prevention.md を固定して読み取り、最後の関連変更後に references/project-audit.md に戻り、元のカバレッジ範囲と現在受け入れられている契約から、カバレッジと発見の帳簿を再生成します。単一の欠陥は、過去に無関係な監査が存在するという理由だけで、このチェーンに拡大することはありません。
- 永続的操作、キュー、またはスケジューラーにおける有界バッチとバックログの排出、回復、または常駐ステートフルサービスにおけるセッションアクセスと解放の競合：
references/durable-operation-governance.md - タスクの進捗または継続的な状態：
references/task-progress-governance.md - 手戻りが、段階的な確認の欠落、確認対象のドリフト、または変更の誤った拡散に起因する場合：
references/staged-result-governance.md - 手戻りが、複数の成果物間の関係不明、再生成時の理由喪失、全量再計算、誤ったキャッシュ無効化、危険な分割、リソース誤判断、またはオーケストレーションの往復に起因する場合：
references/derived-artifact-governance.md - プロジェクトレベルのCIで、繰り返し遅いテスト、環境準備の無駄、シャードの不均衡、クロスプラットフォームの事前チェックが遅すぎる、または失敗後の無差別な再実行がある場合：
references/ci-execution-governance.md - ランタイム操作がサービスの世代間、ホット設定トランザクション、または物理ルートの切り替えにまたがる場合：
references/runtime-generation-governance.md - 再現困難または低可観測性の問題：
references/hard-to-reproduce-diagnostics.md - 構造化JSONにおけるエンコーディング、リソース予算、論理メッセージ容量、アトミックシャーディング、リプレイカーソル、数値、スキーマ、またはエラーセマンティクスの分岐：
references/structured-data-boundary.md - モデルの応答、タスク状態、または結果提示が実際のランタイムと一致しない、またはモデルに実際に送信されたリクエストの特定が必要な場合：
references/model-mediated-operation-governance.md - ビジュアル階層、変換、またはアニメーションの所有権：
references/interaction-motion.md。実際の実行画面による受け入れが必要な場合は、さらにreferences/implementation-review.mdを読み取ります。 - ツール、パスエイリアス、実行環境、または長時間タスク：
references/user-environment-governance.md - イベント、バージョン、履歴、またはキャッシュが、計画された影響範囲を実際の変更事実と誤ってみなしている場合：
references/change-prevention.mdの「計画範囲と実際の変更事実の分離」契約を参照。 - 部分的な状態、ハートビート、またはテレメトリー更新が、宣言されていないフィールドを上書き、クリアした、またはコンシューマーが完全なスナップショットと部分的なパッチを区別できない場合：
references/change-prevention.mdのアクティブプロジェクション更新契約を参照。 - ソースコード、README、スクリプト、テスト、または設定に、ローカルマシンとデプロイメントの事実がハードコードされている場合：
references/change-prevention.mdのプロジェクト実行設定境界を参照。ユーザーマシンの事実は同時にreferences/user-environment-governance.mdを読み取ります。 - 凝集性、結合、セマンティックな重複、または神クラス：
references/architecture-cohesion-governance.md
外部ツール互換性
references/external-tool-compatibility.md を読み取ります。互換性関係がプロジェクトルートをまたぐパブリックコントラクト、派生スナップショット、または複合デリバリーパッケージを含む場合は、同時に references/change-prevention.md のパブリックコントラクト、コントラクト採用クロージャ、およびルート間デリバリー境界を読み取ります。互換性チェックは読み取り専用を維持し、明確なアダプターに従ってレイヤーごとに、実行可能な成果物、能力コントラクト、呼び出しと分離、一時入力、上流のワイヤープロトコル、構造化結果、ホスト独立検証、ユーザーチェーンを報告します。修正または接続が明示的に許可された場合のみ、許可されたプロジェクトルートを変更します。
プロジェクト調査と解説
最初に references/project-research.md を読み取ります。現在の質問に答えるために必要なプロジェクトの表面のみを読み取ります。ユーザーが完全な調査または能力の採用を明示的に要求した場合のみ、カバレッジを拡大し、同時に references/source-fork-and-ecosystem-adoption.md を読み取り、最初に元の上流を遡り、直接再利用とメソッド学習を区別します。コードまたはリソースを直接再利用することが確認された場合は、さらに references/license-governance.md を読み取り、サードパーティリソースと謝辞をターゲットプロジェクトのREADMEに書き込みます。効果、失敗サンプル、信頼度の測定が必要な場合は references/project-effectiveness-review.md を読み取ります。レビュー可能なレポートを保存する必要がある場合は references/project-research-report.md を読み取ります。ソースコードアーカイブは、まず scripts/extract_project_archive.ps1 と -DestinationRoot <ターゲットルート> を使用して独立したディレクトリに解凍します。ターゲットルートが特に指定されていない場合は E:\Work\BaiduSyncdisk\Code\Example を使用します。スクリプトがプロジェクトルートを返した後、直ちに references/archive-safety-screening.md を読み取り、scripts/inspect_extracted_project_safety.py を実行します。このメソッドが重大な潜在的問題を確認した場合のみユーザー出力に進み、それ以外の場合は静かに元の調査を続行します。
プロジェクトディレクトリガバナンス
references/repository-directory-governance.md を読み取ります。最初に scripts/inspect_project_tree.py を使用して読み取り専用の物理的証拠とGitの証拠を取得し、次に各候補ディレクトリの正式なプロデューサー、パスの真の情報源、コンシューマー、ライフサイクルを確認します。チェック、説明、計画は証拠帳簿で停止し、整理、移動、またはアーカイブが明示的に許可された場合のみ正確なパスを変更し、削除は引き続き個別の許可に従います。移動がアクティブなソースコード、モデル、データ、素材、ビルド、または実行エントリに影響する場合は、同時に references/change-prevention.md を読み取ります。既存の古いパス、二重読み取り、同期コピー、または中途半端な移行が存在する場合は、さらに references/root-cause-remediation.md を読み取り、一度にコンシューマーを移行し、古いエントリを終了します。
プロジェクトベースラインとテンプレート
references/project-template-system.md を読み取ります。読み取り専用リクエストは、inspect、plan、verify で停止します。adopt、upgrade、またはプロジェクト設定の書き込みには、明示的な許可と正式なコンシューマーの検証が必要です。
テンプレート進化
references/template-evolution.md を読み取ります。最初に、候補がその場その場の判断を必要とするメソッドではなく、安定したデフォルトであることを証明し、次にテンプレートバージョン、レジストリ、ハッシュ、ドキュメント、コンシューマーテストを同期します。
製品体験とインターフェースガバナンス
最初に references/product-experience-governance.md を読み取り、次に以下の固定エントリと条件付き専用項目を実行します：
- インターフェースの診断、評価、最適化、再構築は、固定で以下を読み取ります：
references/ux-design.md、references/interface-experience-quality.md、references/interface-problem-patterns.md、references/implementation-review.md。変更前に、関連するすべてのウィンドウ、ページ、パネル、オーバーレイ、主要な状態、ユーザージャーニーを固定します。スクリーンショットの中で最も目立つ部分的な問題を、完全なレビュー範囲とみなしてはいけません。 - ゼロからの設計またはビジュアル方向の変更：
references/design-method.md、references/visual-direction.md、references/surface-registers.md - レイアウト、デザインシステム、インタラクション、アニメーション：
references/layout-responsive.md、references/design-system-alignment.md、references/interface-guidelines.md、references/interaction-motion.md - リファレンスインターフェースの忠実な再構築：
references/reference-interface-reconstruction.md - デスクトップ、Tauri/Vue、またはローカルファイルワークスペースであることが確認された場合、対応する以下を読み取ります：
references/desktop-app-governance.md、references/tauri-vue-governance.md、references/local-file-workspace-governance.md。プロジェクトの形態が既に確定している場合、現在のフィードバックが色、間隔、またはコピーのみに言及しているからといって、プラットフォームシェルを省略してはいけません。 - タスクの状態または進捗：
references/task-progress-governance.md
既存のポジショニングまたはデザインシステムに依存する場合、タスクごとに最大1回 scripts/context.mjs を実行します。リファレンスインターフェースの忠実な再構築は、assets/reference-reconstruction/component-spec.md がコンポーネント仕様を担当します。
リポジトリ作成と公開
references/repository-publication.md を読み取ります。初期化、コミット、リモート作成、プッシュ、可視性、チェック、デプロイを区別します。各ステップは、許可された停止位置のみを実行し、状態変更の前後で正確なリポジトリID、インデックス、ブランチ、リモート、並行する変更を確認します。
READMEとホームページ
最初に references/readme-delivery.md を読み取り、1つのデリバリー帳簿を使用して、Git境界、README、本文、ビジュアル、多言語、ライセンス、Star History、GitHub Topics、リポジトリメタデータ、検証、停止位置をチェックします。読み取り専用リクエストは同じ帳簿で停止し、最適化、書き直し、または完全な処理が明示的に要求された場合のみ実装します。次に references/content-architecture.md を読み取ります。完全な最適化、またはロゴやヒーローが含まれる場合は references/visual-direction.md を読み取り、最初にコードファーストの正式なID情報源調査を完了し、必要に応じて references/project-native-hero.md と references/github-readme-canvas.md を読み取ります。多言語、個人エントリ、またはリポジトリステータスエリアが必要な場合は assets/readme-profile/profile.json を読み取り、scripts/readme_header.py が実際のファイル、リポジトリID、ライセンス、明確に解析されたプロジェクトナビゲーションを消費します。既存の公開GitHubリポジトリの完全なREADME最適化では、Star HistoryとTopicsを両方ともデフォルトのデリバリー項目とします：Star Historyは references/github-star-history.md と references/repository-publication.md を読み取り、Topicsは scripts/github_topics.py を通じて書き込みと読み戻しを行います。ユーザーが明示的にオプトアウトした場合、またはターゲットが客観的に適用できない場合を除き、実際のコンシューマーが欠落している成功結果は、全体のデリバリーを完了できません。必要に応じて以下を選択します：
- SVGとハイブリッドビジュアル：
references/svg-production.md、references/hybrid-svg-production.md - アニメーション：
references/motion-production.md - プラットフォーム境界：
references/platform-guidelines.md - セルフホストStar Historyの専用診断または接続：
references/github-star-history.md。障害原因や現状についてのみ尋ねる場合は読み取り専用を維持し、実装時には正確にコミットして呼び出しリポジトリの変更をプッシュし、手動でワークフローを実行し、API、ジェネレーター、出力ブランチ、raw SVG、READMEコンシューマーエンドの実際のリンクに沿って受け入れます。
READMEは、各内部ガバナンスルールの2つ目のアクティブな真の情報源としては機能しません。自己進化は、公開ID、読者パス、主要エントリ、またはメンテナンスナビゲーションを変更する場合のみREADMEを更新します。完了後、scripts/audit_readme.py を実行し、実際のレンダリングサーフェスで確認します。
ライセンスガバナンス
最初に references/license-governance.md を読み取ります。ユーザーが具体的な計画を確認した後、さらに references/license-rollout.md を読み取って実装します。読み取り専用リクエストは、コンテンツ境界、サードパーティ依存関係、計画比較で停止します。
人間中心のログ
references/log-audit-standard.md を読み取ります。実際の操作に沿って、生成、コンテキスト、ストレージ、読み取り、最終的な表示結果をチェックします。きれいなサンプル1つで完全なイベントチェーンを置き換えてはいけません。
ユーザー環境ファイルと実行環境
references/user-environment-governance.md を読み取ります。ファイルスキーマは assets/user-environment/profile.schema.json が担当し、決定論的操作は scripts/user_environment_profile.py が担当します。inspect、plan、verify、resolve は、対応する読み取り専用または消費境界を維持します。apply --write にはファイルへの書き込み許可が必要であり、インストール、ダウンロード、またはシステム設定の変更を自動的に許可しません。
プロジェクト総合監査
references/project-audit.md を読み取ります。ユーザーが実装計画の完了度について尋ねた場合、最初に元の計画から項目ごとの準拠帳簿を作成します。修正が許可された後は、元の計画と現在受け入れられている契約から新しい完全な再チェックを生成する必要があり、古い完了マークを再利用したり、既存のテストから計画範囲を逆推論したりしてはいけません。全体チェックの場合は、最初にプロジェクトの形態に基づいてすべての適用可能な次元のカバレッジ帳簿を作成し、次にこれらの次元が要求する専用項目をロードします。既に発見された問題に基づいてレビュー範囲を埋め戻してはいけません。読み取り専用監査は自動的にはガバナンスを実行しません。ユーザー効果の評価が必要な場合は references/project-effectiveness-review.md を追加し、タスク体験のチェックが必要な場合は references/task-experience-audit.md を追加します。
プラットフォームテンプレートリソース
対応するプロジェクトタイプを処理する際、必要に応じて以下を読み取ります：
- デスクトップアプリケーション：
references/desktop-app-governance.md - Tauri v2 + Vue：
references/tauri-vue-governance.md - ローカルファイルワークスペース：
references/local-file-workspace-governance.md
これらのリソースはアクティブなメソッドですが、プロジェクトがテンプレートを採用したことを意味するわけではありません。明示的に採用され、正式なコンシューマーによって読み取られた .project-steward/project.json のみがプロジェクトテンプレートの状態を構成します。
出力と完了
出力は最初に結論を示し、次に範囲、証拠、未知の項目、次のアクションを説明します。分析は、既に実装されたかのように記述してはいけません。構造チェックは、実際のユーザーチェーンが成立したかのように記述してはいけません。現在のタスクの動作確認は、独立したコールドスタートが既に証明されたかのように記述してはいけません。
影響グラフがある場合は、少なくともプロデューサー、転送・ストレージ境界、コンシューマー、最終ユーザー結果、唯一の真の情報源、古いパスの終了条件、受け入れエントリを含めます。複数の歴史的な結果が含まれる場合は、それぞれの主な原因、成功メカニズム、能力ギャップ、正式な所有者、検証レベルを個別に報告します。
アクティブなルート、対応するメソッド、正式なコンシューマー、決定論的テスト、および今回許可された実際のユーザーチェーンのすべてが一致した場合のみ、完了を報告します。