業務プロセス仕様 (BPS) 作成の指示テンプレート

• 以下のルールに従って、業務プロセス仕様（BPS） を 1 プロセス分作成してください。出力は Markdown とします。

• 対象は 1 つの業務プロセス（bps-xxx-xxxx）です。業務レベルの処理に限定してください。

  • 禁止: 物理テーブル名・カラム名・SQL全文、画面操作手順、実装クラス/関数名、UIコンポーネント名などの実装詳細

• 本文構成は、次の見出し（日本語）をこの順序で必ず出力してください：

  1. 概要
  2. トリガー
  3. 前提条件
  4. 入力
  5. 処理
  6. 出力
  7. 例外 / 異常系
  8. メモ / 将来課題

• 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（不要な項目は省略可だが、id / type / title / status は必須）：

  ---
  id: bps-<英小文字とハイフンで構成したID> # 例: bps-low-stock-detection
  type: domain
  title: <業務プロセス名> # 例: 在庫不足検知
  status: draft # draft / ready / deprecated のいずれか
  part_of: [] # 子プロセスの場合、親プロセスIDを指定
  based_on: [] # トリガーとなるイベントIDや参照する仕様IDなど
  supersedes: []
  ---

• トリガー には、起点となる業務内容と、対応する業務イベント ID（bes-xxx-xxx）を箇条書きで記述してください（例: 商品の在庫数が更新された: 在庫数更新イベント(bes-stock-amount-updated)）。

• 前提条件 では、プロセス開始前に真であるべき業務条件のみを列挙してください（例：「対象商品が販売中状態」など）。

• 入力 は概念レベルの業務データで記述し、業務データ辞書にあるエンティティ・論理名を想定して書いてください。

  • 形式の例（箇条書きで）：
    • エンティティ: 在庫 / 項目: 在庫数・発注点 / 用途: 発注判定の基準
    • エンティティ: 商品 / 項目: 販売状態 / 用途: 発注候補対象商品の絞り込み
  • 入力は「概念データの論理名」で統一し、物理名やSQLなどの実装詳細は書かないでください。

• 処理 は番号付きリストで 5〜9 ステップ程度 にまとめ、各ステップを短い日本語で記述してください。

  • 条件分岐は if/else ではなく、自然な日本語条件句（例：「在庫数が発注点を下回る場合は〜」）で表現してください。
  • 複雑なロジックを説明する必要がある場合、任意で TypeScript 風の擬似コードブロックを追加して構いませんが、業務用語ベースの説明を優先してください。
  • 擬似コードは「イベント駆動」を前提に、イベントハンドラ（リスナー）として記述してください。
    • 形: function <業務イベント>を処理する(event) { ... }
    • フロー: イベント受信 → 入力（概念データ）取得 → BR（ビジネスルール）呼び出し → 出力（イベント）発火
    • BR のロジックは擬似コード内に直書きせず、可能な限り 在庫不足判定(...) のように BR を関数呼び出しとして参照してください。
    • 商品を取得する / 〜イベントを発火する などは、インフラ詳細に踏み込まず 概念レベルの名前に留めてください。

• 出力 では、このプロセスによって生成・更新・削除される概念データ・イベント・通知を列挙してください。

  • イベントには bes-xxx-xxx 形式のIDを付けて記述してください（例: bes-order-candidate-generated）。
  • 「出力（イベント）」と「出力（概念データ/状態変化）」が両方ある場合は、同一セクション内で分けて列挙してください。

• 例外 / 異常系 では、主要な 2〜4 ケースを挙げ、各ケースについて

  • 何が異常か（例: 「発注点未設定」「外部APIタイムアウト」）
  • どう振る舞うか（例: 「スキップ」「3回リトライ後に失敗記録」「オペレーション通知」） を明確に記載してください。

• メモ / 将来課題 では、既知の改善余地や将来検討事項（例: 「閾値の動的化」「並列処理の最適化」など）を簡潔に書いてください。

• 全体を 業務用語で統一 し、略語を使う場合は、業務用語集に存在する一般的な略語のみとし、意味が推測しづらい略語や内部コードは使用しないでください。