dev-context-multi-repo

複数リポジトリのコンテキスト

このスキルを使うと、多数のリポジトリの情報を調査、正規化し、まとまりのあるナレッジハブとして公開できます。基本となるのは、未加工のソース記録と、LLM が管理するプロファイル、概念ページ、バックリンク、派生レポートを備えたコンパイル済み Markdown ハブから成る、2 層構成のシステムです。リポジトリの検出、重要度の高い情報の抽出、リポジトリ間の推論、成果物セットの生成、ナレッジグラフの構築を担います。単一リポジトリのコンテキストやコードグラフの作業に取って代わるものではありません。

クイックリファレンス

タスク	使用するもの
リポジトリを検出し、ポートフォリオの構成を分類する	scripts/discover_repos.py、references/repo-discovery-patterns.md
リポジトリをスキャンして正規化済みプロファイルを作成する	scripts/scan_repo.py、scripts/scan_portfolio.py、references/repo-classification-rules.md
標準の成果物セットを構築する	scripts/build_artifact_set.py、references/output-model-and-gap-analysis.md
グラフ出力を構築して検証する	scripts/build_knowledge_graph.py、scripts/validate_graph.py、scripts/check_graph_consistency.py、references/knowledge-graph-patterns.md
根拠に基づいてグラフのエッジの重みを調整する	scripts/calibrate_weights.py、references/knowledge-graph-patterns.md
グラフの近傍、パス、影響度、ランク、PPR、コミュニティをクエリする	scripts/query_graph.py --node|--from|--impact|--rank|--ppr|--communities、references/knowledge-graph-patterns.md
コミュニティ（Louvain）を検出し、コミュニティごとの要約を生成する	scripts/query_graph.py --communities --resolution、assets/community-summary-template.md
双時点の時間スライスクエリ	scripts/query_graph.py --as-of <date> --known-at <date>、references/knowledge-graph-patterns.md §12
調整ハブを作成または運用する	assets/coordination-repo-layout-template.md、references/hub-operations-playbook.md
未加工データの取り込みからコンパイル済み Wiki までの一連の処理を実行する	docs-notes-retrieval スキル、references/hub-design-patterns.md、references/hub-operations-playbook.md
最新性とドリフトを確認する	scripts/report_drift.py、scripts/check_hub_freshness.sh、references/hub-freshness-checking.md

使用する場面

• 多数のサービスやリポジトリを対象とするマスターコンテキストリポジトリやドキュメントハブを構築する場合。
• その場しのぎの要約ではなく、リポジトリごとに正規化済みプロファイルを作成する場合。
• 手作業による要約ではなく、構造化 JSON プロファイルとグラフのエッジから一貫性のあるリポジトリの説明を生成する場合。
• エージェントランタイム、リモートブリッジ、ターミナル中心の CLI、プラグインホスト、ワークツリーコーディネーターなどの複雑なオーケストレーションリポジトリを、unknown に分類せずに分類する場合。
• ポートフォリオ全体にわたって、スタック、インターフェース、依存関係、オーナー、統合エッジをマッピングする場合。
• オンボーディング、移行計画、アーキテクチャレビュー、RAG 向けのハブ成果物を生成する場合。
• 既存の調整ハブにナレッジグラフを後付けする場合。
• リポジトリのポートフォリオ向けに、raw/ の根拠レイヤーとコンパイル済み Markdown Wiki を運用する場合。
• 大規模なリポジトリポートフォリオを維持または更新する場合。これには、単発の要約よりも段階的なコンパイルが重要となる、100 以上のリポジトリを含むハブも含まれます。

要件ハブを再作成する

すぐにコピーできる空のハブが assets/hub-scaffold/ に用意されています。このスキルが生成するものと同じ構成で、ホットレイヤー（AGENTS.md、rules/）、コンパイル済みレイヤー（context/）、ドメインフォルダーの例が1つ含まれており、組織固有のコンテンツは一切含まれていません。

cp -r assets/hub-scaffold ~/repos/requirements-hub

続いて、assets/hub-scaffold/context/scripts/README.md のエンドツーエンドのコマンド手順に従います。discover_repos.py → scan_portfolio.py → build_knowledge_graph.py → query_graph.py --rank → validate_graph.py の順に実行し、その後、再利用した dev-context-engineering のスクリプトでハブ自体のコンテキストグラフを構築、検証します。スキャフォールドの rules/ のスタブは、dev-context-engineering/assets/ にある汎用テンプレートを明示して参照しています。それぞれの規制への参照を、独自の規制コンテキストに置き換えてください。

別の方法を選ぶ場合

• 単一リポジトリのコンテキストレイヤーや、ツール全体への展開については、dev-context-engineering を使用します。
• 1つのリポジトリ内のシンボルまたはファイルのグラフについては、dev-context-code-graph を使用します。
• 仕様書や意思決定ドキュメントの作成については、docs-ai-prd を使用します。
• ドキュメントの鮮度監査については、qa-docs-coverage を使用します。
• 明示的な委任を伴う多数のリポジトリ間での並列調査については、agents-swarm-orchestration を使用します。

デフォルト

• まず構造化メタデータを扱い、説明文はその後にします。
• リポジトリごとに正規プロファイルを1つ用意します。
• まず生データを取り込み、その後にコンパイル済み Wiki を作成します。
• リポジトリに関する知識を信頼できる唯一の情報源として扱い、ルートのエージェント用ファイルは百科事典ではなく案内図として維持します。
• デフォルトではジャストインタイム読み込みを使用します。安定した識別子、パス、グラフノード ID、レポートへのリンクを保存し、タスクの実行時に関連する成果物を読み込みます。
• 詳細に読み込む前に、重要度の高いファイルを読み込みます。
• 生のエビデンス、正規化されたメタデータ、人間向けの要約を分けます。
• 重い検索レイヤーを追加する前に、Markdown ネイティブのインデックスページ、要約、バックリンクを優先します。
• コンパイル済みハブの維持は LLM に任せます。すべてのページを手作業で編集するのではなく、人間がレビューし、整理し、ドリフトを修正します。
• 長期的に役立つ回答、図、レポートをハブに保存し、ポートフォリオへのクエリを重ねるごとに知見が蓄積されるようにします。
• 隠れた差別化要因を最初から重要な抽出対象として扱います。トランスポートモデル、コントロールプレーン、パーミッションブリッジ、セッションのライフサイクル、ワークツリーモデル、プラグインのライフサイクル、復旧ポリシーは、多くの場合、言語やパッケージのメタデータより重要です。
• 網羅性が不十分な場合は、主張に verified、subset-verified、inferred、unverified のいずれかを付けます。
• 生成された成果物はドキュメント内に散在させず、1つの成果物ルートの下にまとめます。
• ポートフォリオへのクエリごとに、独立した Markdown レポートを作成しないでください。再利用可能な出力は、ハブのカタログ、レポートのライフサイクル、または生成されたコンテキスト成果物セットに格納します。

2026年5月時点の方針

現時点での最適なデフォルトは、「すべてにインデックスを付けてプロンプトに詰め込む」ことではありません。実行時に適切な根拠を選択できる、小規模でナビゲーション可能なコンテキストシステムを構築します。

• AGENTS.md や同階層の実行時ファイルは短く保ちます。ハブの内容を重複させるのではなく、エージェントをハブへ案内する役割にします。
• 構造化された成果物をコンパイラーの入力にします。プロファイル、コードグラフ、システム間のエッジ、鮮度レポート、根拠への参照などです。
• Markdown をオペレーター向けの画面にします。カタログページ、概念ノート、アーキテクチャマップ、再利用可能なクエリ出力などです。
• 関係性の構造によって回答が変わる場合は、グラフ探索を使います。依存関係の経路、所有権、影響範囲、共有プロバイダー、リポジトリ間のフロー、移行の境界、あるいは「このシステムについて概要を教えて」といった質問などです。
• 単純な検索質問には、語句検索、インデックスページ、またはファイルの直接読み取りを使います。すべてのクエリでグラフ優先の検索を行うと、遅延とノイズが増えます。
• 質問がリポジトリ、ドメイン、プロセスを起点としながら、1〜2ホップの近傍を超える予算内のコンテキストを必要とする場合は、Personalized PageRank を使います。
• 質問が全体像を尋ねるもの（「プラットフォームはどのような構成ですか？」）で、単一のシードからの探索では構造を見落とす場合は、複数の解像度でコミュニティ検出（--communities）を使います。1,000ノードを超えるポートフォリオで、より強い連結性の保証が必要な場合は、igraph または graspologic を使って Leiden を導入します。
• 散文、Mermaid、マニフェスト、スキーマがすべてエッジに寄与する場合は、重みを調整します。複数のソースに裏付けられた直接的な根拠は、単一ソースの散文によるエッジより優先されるべきです。
• シンボルレベルのグラフは、dev-context-code-graph によるリポジトリごとの成果物として保持します。すべてのシンボルをポートフォリオグラフに統合するのではなく、概要やリンクをハブに取り込みます。
• 公開前にコンテキスト衛生のゲートを適用します。関連性、出典、鮮度、ACL／機密性の適用範囲、矛盾のリスク、トークン数の上限などです。
• 「グラフ全体を含める」静的なプロンプトより、無関係なグラフコミュニティやサブグラフを動的に刈り込む方法を優先します。

ワークフロー

1. 候補となるリポジトリを一覧化し、リポジトリの形態を分類します。
2. まず生の根拠にインデックスを付けます。リポジトリのルート、アーキテクチャ文書、API コントラクト、データセット、スクリーンショット、その他のソースの記録は、要約に平坦化せず、生データ層に置きます。
3. シグナルの強いマニフェスト、文書、CI ファイル、スキーマの手がかり、指示用の成果物だけを読みます。
4. 根拠を正規化し、リポジトリごとに 1 つの RepoProfile にまとめます。
5. リポジトリがオーケストレーション中心のランタイムと見られる場合は、汎用的な分類を確定する前に、トランスポート、リモート／セッション、承認、ワークツリー、プラグイン、リカバリー関連のファイルを重点的に調べます。
6. 過剰な主張を避けながら、リポジトリの種類、インターフェース、依存関係、ストレージ、所有権、機能ファミリーを推定します。
7. 正規化されたプロファイルと関係エッジから、リポジトリごとに 1 つの説明を生成または更新します。信頼度ラベルは、根拠の網羅状況に基づいて付与します。
8. Markdown ハブを段階的にコンパイルします。エージェントが毎回コーパス全体をスキャンせずにナビゲートできるよう、リポジトリカタログページ、リポジトリ横断の概念ノート、バックリンク、インデックスファイルを作成します。
9. 可能な場合は、変更のあったページ、インデックス、グラフエッジだけを再構築します。デフォルトではポートフォリオ全体を再要約しません。
10. 成果物一式を生成します。プロファイル、カタログページ、グラフ、レポートなどです。
11. グラフの整合性と鮮度を検証し、ハブのヘルスチェックを実行します。古い主張、欠落した要約、インデックスされていないレポート、追加候補となるページを確認してから、ハブを最新と見なします。

ASCII フロー

multi-repo context request
  -> discover repos and classify portfolio shape
  -> ingest raw evidence without flattening it into prose
  -> scan high-signal files into one RepoProfile per repo
  -> build compiled hub: catalog pages, indexes, backlinks, reports
  -> build graph artifacts: system edges and knowledge graph
  -> query with lexical search, direct reads, graph paths, PPR, or communities
  -> validate coverage, freshness, consistency, and unindexed outputs
  -> publish only durable hub artifacts, not free-floating reports

中核となる判断

出力モデル

デフォルトの成果物セット：

• profiles/<repo>.json
• catalog/<repo>.md
• graphs/system-edges.json
• graphs/knowledge-graph.json
• reports/coverage.md
• reports/drift.json

下流の利用者が変換レイヤーを必要とする場合を除き、別の形式を独自に作らないでください。

デフォルトでは、catalog/ と reports/ をコンパイル済み Markdown レイヤーとして扱います。概念記事やクエリ出力を利用する明確な下流の利用者がいる場合に限り、concepts/ や research/ などのフォルダーを追加してください。

リポジトリの説明ページは通常、次の情報から生成してください。

• profiles/<repo>.json 内の検証済みフィールド
• graphs/system-edges.json の関係エッジ
• 数を絞った直接的な証拠への参照

説明ページを、根拠のない文章要約にしないでください。

複雑なリポジトリでは、プロファイルに表層的なメタデータだけでなく、機能群を記録してください。優れたプロファイルには、多くの場合、次の項目または派生セクションが必要です。

• ランタイムまたはデプロイモード
• コントロールプレーンとトランスポートモデル
• リモートまたはブリッジの役割
• セッションと再開のセマンティクス
• 権限と承認の経路
• ワークツリーまたは並列タスクの分離モデル
• プラグイン、フック、またはホットリロードのライフサイクル
• 復旧またはリトライのポリシー

抽出戦略

まず、リポジトリの実態をすばやく把握できるファイルを確認してください。

• マニフェストとロックファイル
• CI ワークフロー
• コンテナおよびインフラストラクチャのファイル
• Package.swift、project.yml、.xcodeproj、.xcworkspace などのネイティブ／モバイルプロジェクトのマニフェスト
• スキーマとマイグレーションのファイル
• API コントラクト
• リポジトリの指示ファイル
• 仕様書と計画書

ハブにリポジトリ以外の証拠も保存する場合は、それらのキャプチャを生データレイヤーに保管し、スクリーンショット、エクスポート、記事の抜粋をカタログの独立したページとして扱うのではなく、コンパイル済みハブに要約してください。

シグナルの強いレイヤーだけではリポジトリの分類やインテグレーションの実証が不十分な場合に限り、詳細な読み込みを行ってください。

オーケストレーションを多用するリポジトリでは、シグナルの強いレイヤーにマニフェストだけでなく、ランタイムの中核となるファイルも含めてください。

• トランスポートの実装
• リモートブリッジ、またはクライアント／サーバーのセッションマネージャー
• 権限および承認のブリッジコード
• ワークツリーとタスクのオーケストレーション設定
• プラグイン、フック、ホットリロードのローダー
• 再接続、バックプレッシャー、バッチ処理、復旧のロジック

最も重要な差別化要因の多くは、パッケージのメタデータからは見えません。抽出器が言語、ロックファイル、README のテキストしか見ていないと、実際にはランタイム設計で優れているリポジトリを過小評価して分類してしまいます。

複雑なランタイムの分類

リポジトリに次のいずれかが複数含まれている場合は、unknown ではなく複雑なランタイムとして分類することを優先してください。

• リモートブリッジまたはリモート実行のサポート
• SSE、WebSocket、読み取り／書き込みのハイブリッドトランスポートなど、明示的なトランスポート抽象化
• セッションマネージャーまたは再開ライフサイクル
• 権限または承認の仲介
• タスク、コーディネーター、チームメイト、またはワーカーのオーケストレーション
• ワークツリーの作成、ブランチの分離、または tmux／セッションのブートストラップ
• プラグイン、フック、または遅延ローダーのインフラストラクチャ
• 明示的な復旧、リトライ抑制、バッファリング、またはバックプレッシャーの仕組み

認識すべき代表的な分類：

• エージェントランタイム
• コーディングエージェント CLI
• リモート実行ブリッジ
• ターミナル UI ホスト
• プラグインプラットフォーム
• マルチリポジトリコーディネーター

検証範囲

統合する前に、次の点を確認してください。

• 直接的な証拠と推論した構造を分ける
• 関連するすべてのリポジトリを確認していない限り、ポートフォリオ全体に当てはまる普遍的な主張を避ける
• ストレージエンジンは README の文章ではなく、マニフェストとドライバーから検証する
• 要約や表では、カバレッジが部分的であることを明示する

生成するリポジトリの説明では、次の点に留意してください。

• マニフェストやワークフローから実証された内容と、命名やトポロジーから推論した内容を区別する
• 確信を装う物語調の説明より、簡潔で構造化された説明を優先する
• リポジトリを確信を持って分類できない場合は、不明点を明示する

ナレッジグラフ

ハブでリポジトリ、システム、成果物間の関係を検索できるようにする必要がある場合は、ナレッジグラフを使用します。シンボルレベルのグラフ処理はこのレイヤーでは行わず、単一リポジトリのコードグラフワークフローに任せます。

グラフはMarkdownハブを補完するものであり、置き換えるものではありません。基本的には、グラフを活用したMarkdownページにバックリンク、インデックスノート、簡潔な要約を付け、コーパスの規模が小〜中程度であればエージェントが直接読めるようにするのが最適です。

複雑なランタイムでは、依存関係のエッジだけでなく、機能や動作を示すエッジも追加します。役立つ例：

• uses_transport
• splits_read_write_channels
• supports_resumable_streams
• bridges_permissions
• manages_remote_sessions
• supports_worktree_isolation
• supports_plugin_hot_reload
• serializes_writes
• buffers_stream_events
• has_recovery_policy

Q&Aと派生出力

回答はターミナルだけに出力するのではなく、ファイルとして保存することを優先します：

• アーキテクチャに関する質問や移行マップ向けのMarkdownレポート
• 関係性を示すビュー向けのMermaidなどの図
• 閲覧環境があり、質問がプレゼンテーション重視の場合はスライドや画像の出力

回答が再び役立つ可能性が高い場合は、ハブにファイルを追加し、関連するリポジトリページまたはコンセプトページからリンクします。

ファイルを追加する前に、ハブへの配置テストを実施します：

• 既存のリポジトリカタログ、コンセプトページ、またはレポートに含めるべきですか？
• ハブのインデックスまたは関連するリポジトリページからリンクされますか？
• 構造化された入力から生成されるものですか？その場合、再生成コマンドは把握されていますか？
• 特定時点の分析である場合、ライフサイクル状態は設定されていますか？

該当しない場合は、タスクスレッドに残すか、既存のハブページを更新します。

100以上のリポジトリを運用する

大規模なポートフォリオでは、一度きりの大掛かりなスキャンではなく、メンテナンスのサイクルを最適化します：

• リポジトリのレジストリと最終更新状態を管理します
• 毎回すべてのページを再構築するのではなく、増分コンパイルを行います
• LLMが適切なリポジトリやコンセプトをすばやく見つけられるよう、短いインデックスページを維持します
• 差分確認、Lint、修復が可能なJSON、Markdown、グラフの成果物を優先します
• 大掛かりな検索システムに頼る前に、検索、鮮度チェック、対象を絞った再構築に使える軽量なCLIを追加します

ハブのレイアウト

以下を備えた調整用リポジトリを優先します：

• ルートのエントリーファイル
• ルートに配置したドメインフォルダー
• context/ または docs/context/ 配下の生成済みハブインフラストラクチャ
• LLMがハブにコンパイルする証拠情報を保存する、任意の raw/ 取り込み領域

ルートはナビゲーションに特化させます。インベントリを AGENTS.md に貼り付けないでください。

ネイティブ／モバイルのリポジトリでは、デフォルトのスキャナーは汎用的な言語ヒューリスティックに頼る前に、シグナルの強いプロジェクトファイルから分類する必要があります。project.yml、.xcodeproj、または .xcworkspace が確認できる場合、Swift／Xcodeリポジトリは確実に app リポジトリとして分類し、スキャンでは .build、DerivedData、Pods、SourcePackages などの生成済みビルドツリーを無視する必要があります。

出力モード

以下のいずれかをデフォルトにします：

• ポートフォリオインベントリ： リポジトリレジストリ、分類、スキャン範囲。
• コンテキストハブ： プロファイル、カタログページ、関係性を示すエッジ、ナレッジグラフ。
• コンパイル済みWiki： 生の証拠情報レジストリ、Markdownインデックス、コンセプトノート、バックリンク、再利用可能なクエリ出力。
• リポジトリ説明セット： プロファイルJSON、グラフのエッジ、検証済みの証拠情報からコンパイルした、リポジトリごとの根拠に基づくページ。
• 機能マップ： READMEレベルの要約ではなく、ソースの証拠情報から導き出した、リポジトリごとのランタイム機能、差別化要素、運用動作。
• 移行マップ： 現行システムとレガシーシステム、統合エッジ、移行の主要箇所。
• 鮮度レポート： ドリフト、古くなったドキュメント、再検証キュー。

既知の落とし穴

• 汎用的なリポジトリ分類を早まって受け入れ、オーケストレーター、ブリッジ、コントロールプレーンを実際に区別する運用上の振る舞いを見落とすこと。
• マニフェスト、ワークフロー、ランタイムスクリプトが別のことを示しているのに、README が充実したリポジトリを権威ある情報源であるかのように読むこと。
• 実際に変更されたリポジトリから増分的にコンパイルするのではなく、スキャンのたびにハブ全体を再構築すること。
• 推定されたリポジトリ間の関連を、マニフェスト、スキーマ、または具体的な統合の証拠にさかのぼって確認する前に「事実」として確定させること。
• 生の証拠や正規化されたプロファイルがひそかにずれていく一方で、ポートフォリオの概要を信頼できる情報源として扱うこと。
• モデルのコンテキストウィンドウが長くなったことを、ハブ全体を読み込んでよいという許可と見なすこと。無関係なコンテキストが多いと、依然として注意が散漫になり、コンテキストが劣化します。
• 直接的なカタログ検索、語彙検索、または範囲を限定したファイル読み込みのほうが正確な場合にも、あらゆる質問に GraphRAG やグラフ探索を適用すること。
• 構造化プロファイルとグラフの契約から文章を再生成するのではなく、生成された Markdown と生成された JSON がそれぞれ独立してずれていくこと。
• 元のソースとタイムスタンプを保持せずに、LLM が生成した概要を新たな証拠として再取り込みすること。

アンチパターン

• 1 つのリポジトリの概要をポートフォリオのモデルとして扱うこと。
• 検証済みのスキャンレジストリなしに、完全な網羅性を主張すること。
• 生の証拠、正規化されたデータ、コメントを同じファイルに混在させること。
• マニフェストではなくドキュメントからストレージやランタイムに関する主張を検証すること。
• 有用なポートフォリオに関する回答をチャットの出力にとどめ、ハブに記録しないこと。
• ポートフォリオの一覧をルートのエージェントメモリファイルに貼り付けること。
• シンボルレベルのコードグラフをポートフォリオのナレッジグラフに無理に組み込むこと。
• インデックスページ、簡潔な概要、バックリンクを整備する前に、負荷の大きい RAG に頼ること。
• 一部しか変更されていないのに、130 件のリポジトリの説明を一から作り直すこと。
• プロファイル JSON とグラフのエッジではなく、チャットでの印象からリポジトリの説明を直接書くこと。
• スキャナーがマニフェストと README のテキストしか確認しないため、複雑なリポジトリが unknown のままになること。
• 依存関係のエッジだけをモデル化し、権限ブリッジ、セッションコントロールプレーン、再開可能なストリーム、ワークツリーの分離などの運用上のエッジを見落とすこと。
• リポジトリが所有するプロファイル、証拠への参照、鮮度チェックの代わりに、ベクトルデータベース、GraphRAG スタック、または MCP サーバーを使うこと。
• パースの網羅率、スキャン日、除外されたパス、未対応言語に関する注記を示さずに、「コードベース全体のコンテキスト」を提供すると主張すること。
• 機密区分とアクセス境界を設けずに、公開ドキュメント、非公開コードの証拠、シークレット、顧客データを 1 つのコンテキストレイヤーに混在させること。

ナビゲーション

• コアリファレンス：references/repo-discovery-patterns.md、references/repo-classification-rules.md、references/architecture-inference-rules.md、references/integration-signal-detection.md、references/confidence-scoring.md
• ハブとグラフの操作：references/output-model-and-gap-analysis.md、references/knowledge-graph-patterns.md、references/hub-design-patterns.md、references/hub-operations-playbook.md、references/hub-freshness-checking.md、references/large-portfolio-strategy.md
• references/network-science-applied.md — 複数のリポジトリにまたがるナレッジグラフとポートフォリオのトポロジーに適用する、中心性、PageRank、コミュニティ検出、伝播。
• アセット：assets/hub-scaffold/（コピーして使える空のハブ。「Requirements-Hub の再作成」を参照）、assets/coordination-repo-layout-template.md、assets/repo-catalog-page-template.md、assets/architecture-map-template.md、assets/integration-matrix-template.md、assets/freshness-report-template.md、assets/legacy-transition-map-template.md、assets/hub-agents-template.md
• スクリプトとスキーマ：scripts/discover_repos.py、scripts/scan_repo.py、scripts/scan_portfolio.py、scripts/build_artifact_set.py、scripts/build_hub_views.py、scripts/build_knowledge_graph.py、scripts/query_graph.py、scripts/validate_profiles.py、scripts/validate_graph.py、scripts/check_graph_consistency.py、scripts/report_drift.py、scripts/check_hub_freshness.sh、schemas/repo-profile.schema.json、schemas/knowledge-graph.schema.json、schemas/system-edge.schema.json

ファクトチェック

• 既知のバグ、リグレッション、フレームワーク／コンパイラー／ランタイムに関する落とし穴、バージョン固有のクラッシュや回避策に関する情報は、現在の事実として扱う前に、最新の一次ウェブソースで検証する必要があります。
• 外部ソースの対応付けは data/sources.json にあります。
• ポートフォリオの概要では、検証済みの事実と推論されたエッジを区別する必要があります。
• 主張の根拠をマニフェスト、スキーマ、ワークフロー、その他の直接的な証拠までたどれない場合は、事実として確定するのではなく、その旨を明記してください。