product-enrich

/as:product-enrich — 商品情報の充実

作業を開始する前に、ホスト契約とこのコンポーネントの宣言（skill:product-enrich）を読みます。共有カタログから、参照されているモードプロファイルのみを読み込みます。実際のタスクに必要なモードを組み合わせます。宣言は要件であり、アクセス権や許可の証明ではありません。

ライブラリの変更は /as:product-library が担当します。選択した行と変更セット、および証拠をすべて準備してから、既存の認可のもとでネイティブ保存を引き継ぎます。担当側でバッチ全体を検証し、正確なリクエスト、プレビュー、現在の状態を関連付け、実際に公開されたことを確認します。このスキルは product-library.csv を独自に変更しません。

ホストアダプター：呼び出し、質問、対象へのアクセス、任意の委任については、デリバリー固有のガイダンスをお読みください。

記録の権限とホストへの引き継ぎ

構造化されたエビデンスを引き継ぐ場合は、完全版のネイティブな製品観察の所有者とスキーマを確認してください。エンベロープ全体に対してネイティブの validate/validate-batch を適用し、選択項目／現行リビジョン／フィールドの対応付けを明示した場合に限り、適合させてください。型付きの値、ソース／ロケーター／時刻、未知のステータスを正確に保持し、完全なエンベロープ、監査観察、競合、通知をまとめて保持してください。既存の null／空欄／ユーザーによる上書きは維持してください。これは未採用のエビデンスとレビュー提案であり、仕様を書き込む権限を与えるものではありません。

プロジェクトに紐づく作業では、ネイティブのコンテキスト解決を適用し、検証済みのプロジェクトIDを使用して、プロジェクトの指示を確認してください。インラインまたは単発のソース作業では、プロジェクトを作成する必要はありません。再利用可能な CSV の保存先は product-library、採用済み仕様の識別情報／リビジョンは master-schedule、受け入れ済みのジョブ入力は product-data-import が管理します。ディレクトリ、ソース文書、または納品時の宣言から権限を推定しないでください。

採用済みプロジェクトスケジュール、単発のソース作業、任意の再利用可能な product-library.csv を明確に区別してください。採用済みの品目／スケジュール記録が権威ある情報源です。/as:master-schedule を通じて固定されたリビジョンを読み込み、想定リビジョン、エビデンス、保持された上書きを添えて、変更をその所有者に提案してください。このスキルが正規の品目／スケジュール記録を独自に書き換えたり、承認を推定したりすることはありません。以下のライブラリ保存手順は、任意の CSV ライブラリにのみ適用され、プロジェクトスケジュールの採用や更新には適用されません。

ホストは、利用可能な機能を使って、提供されたワークブックを読み取り、編集します。元ファイル、選択された画像、数式、実際のハイパーリンク、無関係なセルを保持してください。採用済みスケジュールの場合、採用／照合作業と、編集前のネイティブバックアップ、および検証済みの編集前／編集後の記録 CSV 復旧スナップショットは、/as:master-schedule を通じて処理してください。ホストが抽出したワークブックデータとマッピングは、別途保持してください。単発モードでは、スケジュールスナップショットを実行したり記録を採用したりせず、ホストがネイティブバックアップと、実際にワークブックから抽出した CSV スナップショット／マッピングをジョブ復旧ファイルに保持します。三者間の競合や削除案には、明示的な解決が必要です。ワークブックへのアクセスがサポートされていない場合は、完了したと偽るのではなく、具体的な引き継ぎ内容を提示してください。単発作業では、受け入れ済みソースは暗黙に採用されることなく、タスク入力のまま維持されます。

ソースの識別情報、ページ／URL ロケーター、取得時刻、選択済みか利用可能かの構成、単位、不確実性を、それぞれの観察とともに保持してください。SKU の組み合わせ、寸法、仕上げの選択、価格、通貨を捏造しないでください。$ だけでは曖昧です。明示的に変更されるまで、ユーザーの選択を保持してください。現行の事実に関する主張には、実際のソース取得が必要です。アクセスできないエビデンスは未知のままにしてください。受け入れ済みのジョブ入力と修正は /as:product-data-import が管理し、差異の報告は /as:product-audit が行います。差異を黙って適用することはありません。/as:product-cut-sheet と /as:ffe-spec-book は、入力の解決後に共有ドキュメントテンプレートとホストのレンダリングを使用します。

最寄りのプロジェクトにある product-library.csv または貼り付けられたデータから製品行を取得し、不足しているカテゴリ、色、素材、スタイルのメタデータを提案します。

使用するタイミング

• 一括インポート後に、製品のカテゴリやタグが不足している場合
• デザイナーが製品の詳細を入力せず、すばやく製品をクリップした場合
• 異なるソースからの製品のメタデータを標準化する場合
• FF&E スケジュールを生成する前（データを充実させると、より良いスケジュールを作成できます）

ステップ 1：入力を受け付ける

任意の形式の製品データを受け付けます。

CSV ファイル：

/as:product-enrich ./products.csv

貼り付けられたデータ：

Synthetic formatting input only:
Example Product A | Example Manufacturer | quantity 2 | supplied specification pending

ステップ 2：各製品を分析する

各製品について、ソースに基づく仕様フィールドと、暫定的な説明分類であることが明記されたフィールドを区別します。

カテゴリ

../../schema/product-schema.md で定義された正規の語彙（22 用語）に対応付けます。

サブカテゴリ

カテゴリ内のより具体的な分類です：

• Chair → Task Chair、Lounge Chair、Dining Chair、Side Chair、Stool、Bench
• Table → Dining Table、Coffee Table、Side Table、Console Table、Conference Table
• Light → Pendant、Floor Lamp、Table Lamp、Wall Sconce、Ceiling、Task Light、Chandelier
• Sofa → Sofa、Sectional、Loveseat、Daybed、Settee
• Storage → Credenza、Bookcase、Filing Cabinet、Wardrobe、Sideboard、Dresser
• Desk → Writing Desk、Executive Desk、Standing Desk、Workstation

利用可能な色／仕上げと選択済みの色／仕上げ

メーカーの情報で確認できる選択肢と、確認済みの選択内容は分けてください。Colors/Finishesには利用可能な選択肢を、Selected Color/Finishにはユーザーが明示的に選択した仕上げ、または情報源によって裏付けられた選択内容のみを記載し、推測した選択肢は記載しないでください。選択済みの色だけでは、利用可能な選択肢の一覧として不十分です。暫定的な視覚的説明は、事実を記載する仕上げフィールドには含めず、Notesまたはプレビューに記載してください：

• 事実を記載するフィールドでは、情報源に記載された仕上げ名を正確に保持してください。Black、White、Brownなどの大まかな色名は、これらの名称に置き換えず、説明用タグとして提案できます。

素材

主な素材をカンマ区切りで記載します：

• Wood（種類が分かる場合は指定：Walnut、Oak、Maple、Teak、Birch、Ash、Beech）
• Metal（種類を指定：Steel、Aluminum、Brass、Chrome、Iron、Copper）
• Upholstery（種類を指定：Leather、Fabric、Velvet、Bouclé、Mohair、Linen、Wool）
• その他：Glass、Marble、Concrete、Ceramic、Plastic、Fiberglass、Rattan、Cane、Acrylic

スタイルタグ

以下から説明用タグを2〜4個選びます：

• 時代／ムーブメント：Mid-Century Modern、Art Deco、Bauhaus、Scandinavian、Japanese、Industrial、Contemporary、Traditional、Minimalist、Postmodern、Memphis
• 特徴：Organic、Geometric、Sculptural、Modular、Stackable、Compact、Statement、Classic、Iconic
• 用途：Residential、Contract、Hospitality、Healthcare、Education、Outdoor

画像分析

視覚情報の補完が求められ、情報源に指定されたImage URLフィールドが含まれている場合は、利用可能なホストの画像機能を通じて、実際に許可された画像アクセスを確立し、画像データを調べてください。アクセスできない場合、視覚情報の補完は未検証のままです。不足している事実属性については、許可されている場合に限り、既存の製品に該当する元の情報を取得してください。そうでない場合は、不明のままにしてください。画像を調べて、暫定的な視覚的説明を確認してください。画像だけでは、素材の構成や選択済みの仕上げを検証できません。画像から推測できる情報は次のとおりです：

• 表示されている照明下での見た目の色
• 見た目の質感（推測であることを明記）
• スタイルの特徴

ステップ3：プレビューを表示

適用前に、根拠の状態を示したプレビューを表示してください。この例示用テーブルは製品の根拠ではありません。実際の選択内容に例の仕上げを転記しないでください：

Synthetic formatting input only:
Example Product A | Example Manufacturer | quantity 2 | supplied specification pending

補完内容が不確かな製品にはフラグを付けてください：

⚠ "Custom Reception Desk" — unknown product, category set to Desk but verify

ステップ4：適用

プロジェクトライブラリへの適用

../../schema/product-schema.mdと../../schema/csv-conventions.mdを読み込んでください。根拠に裏付けられた補完情報を、正規の名称付きフィールドであるCategory、Materials、利用可能なColors/Finishes、および明確に確認されたSelected Color/Finishに対応付けてください。正確な変更が許可されていない限り、既存の選択内容と入力済みの値は保持してください。推測した色、質感、素材、サブカテゴリの説明はNotesに推測であることを明記して記載してください。提案する説明用スタイルタグをTagsに追加する場合は、判断のステータスをNotesに残してください。視覚的な推測を仕様上の事実にしないでください。

複数行を補完する場合は、提案する33列すべてを含むCSVを、レビュー用の一時ファイルまたはユーザーに表示するファイルとして作成してください。検証を行い、素材の変更内容すべてと対象のproduct-library.csvを一度プレビューしてから、既存の明示的な許可を適用するか、不足している承認を一度だけ求めてください。承認後は、完全なバッチをproduct-libraryのネイティブインポート操作に渡して、1回のガード付き公開を行ってください。行ごとのループは使用しないでください。真に単一レコードの補完であれば、一意に一致する安定したフィールドと、正確な依頼内容および現在の状態を示す根拠を用いて、所有者のネイティブ更新機能を使用できます。

会話へ

拡充した表を Markdown 形式で出力します。

ステップ 5：要約

✓ Enriched 4 products
  Categories: 4 assigned (0 already had values)
  Colors: 4 assigned
  Materials: 4 assigned
  Style tags: 14 total tags across 4 products
  Uncertain: 1 (flagged for review)

併用するスキル

• /as:product-spec-bulk-fetch — 先に仕様を取得し、その後で結果を拡充します
• /as:product-data-cleanup — cleanup で書式を正規化し、enrich でメタデータを追加します
• /as:product-data-import — 製品情報を拡充すると、より適切な書式のスケジュールを作成できます
• /as:product-match — タグを拡充すると、より適切なマッチを見つけられます

元の製品情報の根拠

タスクに関して、選択したメーカー／製品／バリアントの正確な事実を元のドキュメントから取得します。例示データは合成データであり、根拠として使用しません。製品情報、認証、価格、ベンダー形式の定義を再利用可能な参照知識としてプラグインにコピーしないでください。未解決の値はそのまま保持し、代表的な画像と、選択した正確なバリアントの画像を区別してください。

ネイティブ形式での出力とオーナーへの引き継ぎ

永続的に保存する作成済みレポートを依頼された場合は、正確な座標ベースの配置、クエリ、登録に、receive のネイティブドキュメントオーナーを使用します。ラベルからプロジェクトフォルダーを作成しないでください。単発レポートでは、明示的に許可された保存先のみを使用し、studio／project の設定は必要ありません。正式に採用されたリビジョンと再利用可能なライブラリへの保存は、それぞれのオーナーが管理します。既存の正確な権限は引き続き有効です。不足している範囲の権限、またはネイティブ権限のみを取得してください。

このスキルが実際に保存または編集する出力については、その影響を受ける対象全体に対し、ネイティブ変更手順を適用してください。元のバイト列／アクセス権、ソース／ID のガード、準備済みの出力全体、不在条件／事前条件を保持します。最初のパブリッシャーを実行する前に、永続的な保存を完了し、保持したすべての内容とアクセス権、および準備したすべての内容を個別に再読み込みして確認します。無関係なデータと、該当する場合は実際のワークブック機能を保持してください。実際の保存先ごとに、バイト列全体とモード／該当する所有権／ACL を再度読み込み、変更、ソースの系譜、保護対象の元データを確認してから、完了を報告してください。正しいバイト列、作成モードの引数、または出力されたレシートだけでは不十分です。保護がサポートされていない場合や、公開状況が不確かな場合は、復旧用の証拠を添えてブロック中／保留中の状態にしてください。

選択したモードに適したネイティブ機能を使用してください。選択した方法で必要な場合に限り、プロセス実行を任意で使用できます。Arch Studio のランナー、実行可能ファイルのダウンロード、ソースの再構築は不要です。読み取り専用／インラインの作業には、書き込み機能は必要ありません。実際の調査／抽出、検証済みの提案、個別に検証したオーナーによる保存を、それぞれ分けて報告してください。実際の証拠がない限り、オーナーへの引き継ぎが完了したと主張しないでください。

ネイティブワークブックの保持比較

明示的に選択した変更前／変更後のネイティブな .xlsx または .xlsm のペアと、許可されたセル編集が用意されている場合は、ワークブック比較オーナーの全体を読み込み、実際の ZIP／XML を検査してネイティブの workbook_preservation.compare を実行します。メンバーの正確なバイト列、宣言されたワークシート／セルの属性、数式とキャッシュの区別、XML の空白規則を保持してください。この読み取り専用の比較は、編集を許可するものではなく、タスクで必要となる実際の対象セルの読み戻し、バックアップ、機能検査、再計算、視覚的検証の代わりにもなりません。プロバイダー形式やバイナリー形式、および検査精度が得られない場合は、明示的な不足事項として扱ってください。それらを隠すためにワークブックを再保存／変換しないでください。Arch Studio のヘルパーやプロセスランタイムは必須ではありません。