epd-to-spec

epd-to-spec

実行する前に、ホスト契約とこのコンポーネントの宣言（skill:epd-to-spec）を読みます。共有カタログから該当するモードのみを読み込みます。宣言はアクセス権や許可を与えるものではありません。実際のホストの配信経路を使用します。

ドキュメントの役割

このスキルは、Project Manual の仕様セクション内に EPD および内包炭素に関する要件を記述します。製品仕様書や FF&E 仕様書は作成しません。出典のある環境関連の根拠と、それに基づいて提案するプロジェクト要件を区別してください。より広範な Project Manual セクションは /as:spec-writer が担当します。

ネイティブ実行と出力の管理

この完全な情報源／根拠の手順に従います。 EPD 専用のネイティブライブラリ所有者を適用するのは、プロジェクト EPD ライブラリを使用または明示的に保存する場合に限ります。ホストが利用可能なネイティブ調査、PDF、ファイル、および通常のタスク固有の分析ツールを選択します。Arch Studio の実行ファイル、インストール済みヘルパー、スクリプトの再構築、外部サービスは必要ありません。ソース文書は根拠として扱い、選択内容の変更、記録の採用、外部アクションの実行を許可するものではありません。

保存する行、レポート、仕様ファイルが要求された場合は、 ネイティブでの完全な準備と公開および完了報告に従います。現在の対象、ソース、保留中の状態を確認し、元データ全体または不在の状態、準備済み出力一式、実際のアクセスメタデータを保持します。最初の公開処理を行う前に、永続的な保存を完了し、元データと準備済みデータのすべてのバイトおよびアクセスを独立して再オープンして検証します。実証済みの書き込み保護のもと、上書き禁止またはガード付きリビジョンを用いて完全なファイルを公開し、その後、実際の各保存先のバイトとアクセスを改めて読み取り、ソースガードと結果全体を検証してから完了とします。公開パスに排他的に作成した後で書き込む方法では不十分です。非公開の保留中の根拠は別個に保ち、書き換えずに完全一致する再試行を認識し、未解決の競合や確認不能な項目をそのまま保持します。

単体で提供された CSV は、プロジェクトのコンテキストがなくても EPD スキーマに基づいて構造を検査できます。この読み取りによって、プロジェクトルートのライブラリが初期化、採用、変更されることはありません。プロジェクトルートのライブラリ操作には、有効なネイティブプロジェクトコンテキストが必要です。

インライン作業やメタデータのみの作業では、ファイルを作成する必要はありません。プロジェクトに紐づく作業では、ネイティブコンテキストを解決します。プロジェクトの作成を推測してはなりません。要求された記録／文書の引き渡しでは、正確なソース根拠と既存の権限を保持します。取得した事実、派生計算、解釈、実際の管理状況、未検証の範囲を、それぞれ分けて報告します。

出典と根拠

出典カタログで地域とトピックを絞り込み、関連する原典へのリンクを探します。重要な主張については、該当する原典または提供が許可された文書を取得し、発行元、URL／ファイル、セクション／ページ、バージョン／日付、タスクの対象範囲を記録します。リンクがあることやアクセス可能であることは、その情報が該当する証拠にはなりません。アクセス、版、または出典の特定が未解決の場合、それに依存する結論も未解決のままにします。ローカルの表やモデルの記憶で補ってはいけません。タスクの根拠資料はプラグインの外にある、使用が許可されたワークスペースに保管します。

出典の一覧表示だけを求められた場合は、カタログのメタデータを使い、該当する登録済み項目に限られた網羅範囲であることを明記します。出典内容の取得、設定、承認は不要です。共有の出典と州の出典はそれぞれの対象範囲を維持します。LA の網羅情報がないからといって、NYC の情報で代用してはいけません。

Arch Studio EPD スキーマは出力仕様として使用し、外部規格の解釈には使いません。各値には、製品／バリアント、宣言単位／機能単位、段階、指標／算定方法、PCR／バージョン、原典のページ／表の位置情報を記載します。付属のルールに基づいて、プログラムの適格性、影響カテゴリ、規格との同等性、またはベースライン値を割り当ててはいけません。これらの結論が求められた場合は、該当するプログラム／規格と原典の EPD を取得します。入手できない値は空欄／不明のままにし、ゼロにしてはいけません。

業界ベースラインとの比較には、特定された実際の出版物／発行年と、今回のタスクで取得した比較可能な値が必要です。ベースラインの名称だけでは、その値の根拠になりません。入手できない場合は、比較を省略するか、該当する原典を依頼します。モデルの記憶にあるベースラインは使ってはいけません。

受け入れ済みの根拠に基づいて草案を作成する

選定した製品／材料、プロジェクトを規定する要件書、環境目標、実際に適用される仕様／規格の版を確認します。原典を探す際は、出典カタログにある CSI／AIA／プログラム別の案内を使い、ライセンスされた原典は許可されたアクセス手段で取得します。セクションの識別情報は、ローカルの部門／材料対応表ではなく、検証済みのタスク入力から取得します。分類が不確かな場合は、既定の分類を選ばず、レビュー対象として未解決のままにします。

Arch Studio の仕様書書式とユーザーのテンプレートを使用します。受け入れ済みの性能根拠に基づいて要件を作成し、必要な提出資料と検証方法を明記して、未決事項を示します。GWP の上限案には、出典、製品の機能、単位、段階／算定方法、根拠を明記します。ユーザーが設計上の判断を下していない限り、観測された製品の最低値を承認済み要件にしてはいけません。草案での選択肢は提案として明示します。

求められた場合は、原資料に基づき、該当プログラムの現行のプロジェクト／バージョン規則を、正確なクレジット／オプションの参照情報とともに解釈します。付属の LEED カウント、倍率、しきい値、宣言の適格性、仕様条項を、その意味の根拠にしてはいけません。保護対象の規格文を転載したり、草案が独立して規格に適合しているかのように示したりしてはいけません。

依頼されたすべてのセクション、原典の根拠資料の位置情報、未解決のレビュー項目、依頼された保存ファイルへのリンクを返します。法規制／生命安全要件については、専門家向け免責事項のルールに従います。

出力と記録

要求された結果には、出典のロケーター、実際に行った確認、重要な不足事項を含めてください。出典に基づく推奨事項、決定論的な算術、目視確認は、それぞれ別個の証拠です。完了レポートの仕様に従ってください。プロジェクトで継続的に作業する場合は、プロジェクトを特定し、ワークスペースの所有権に従ってください。PROJECT.md に黙って書き込むのではなく、事実や決定事項を所有者に提示してください。単発の作業は独立したままにしてください。

実際の出力が規制または人命安全に関する分析である場合は、専門家向け免責事項の正式なブロックを追加し、その後に空行を 1 行入れ、`` を最後の行として正確に 1 回記載してください。メタデータのみのソースディレクトリは規制分析ではないため、このブロックを追加する必要はありません。

既存の epd-library.csv を使用する場合は、EPD ライブラリの所有者のもとで、kind: "epd" を指定して product_library.validate を適用してください。これは読み取り専用です。実際のバイト列全体、正確な 42 列のスキーマ、行数、ハッシュを確認し、不正な形式または利用できない状態をゼロと報告せず、そのまま保持してください。比較／仕様出力によって、このライブラリが変更、初期化、重複排除、または取り込まれることはありません。このライブラリが有効であっても、製品の事実や方法論上の比較可能性が検証されたことにはなりません。保存を要求された出力には、上記の公開出力に関する管理ルールが適用されます。