v1.5.0: Introduce cross-cutting concepts for system-wide rules

CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## v1.5.0 (2026-09-05)
+
+### New
+
+- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。横断しているのはルール（文）ではなく概念（名詞）という整理に基づき、オーナーの BR の「横断概念」セクションに 1 概念 = 1 行で宣言し（業務用語 + `xc:{cap}/{slug}` 形式の ID + 宣言文 + 定義ルール ID + 行末 `<!-- cross-concept -->` マーカー）、効果を持つケイパビリティは自分のルールに `[xc:…]` タグを付ける。非適用は記録しない。一覧は `grep 'cross-concept' miko/*/business_rules.md`、特定概念の全体像（宣言 + 全適用ルール）は ID の grep で都度導出し、中央レジストリは持たない。網羅性は記録や事後監査ではなく **プロセスの門で構成的に保証する** — ケイパビリティ × 概念の全ペアは、概念の宣言（propose の影響調査）かケイパビリティの新規作成（new-cap の判定ステップ）の遅い方で必ず一度検討される。判定テスト（他者性・全称性・必達性）、ID・宣言・タグの書式、書き込み時 lint（orphan 参照・宣言重複・書式）を `business_rules_guide.md` の「横断概念とは何か」に定義。`.miko/examples/business_rules.md` に実例（宣言 `xc:order_management/pay-defaulter` とタグ付きルール ORD-05）を追加。検討経緯と却下した代替案（中央レジストリ・ルール単位マーク・適合セクション・非適用の記録・グローバル連番 ID・harae での網羅監査）は `business_rules_driven_development.md` の「解決済みの論点」を参照
+
+### Changed
+
+- **`/miko.propose` の他ケイパビリティ影響調査を任意から必須に変更** — 従来の「調査しますか？」の確認をやめ、デフォルトで実行する（主さまが明示的にスキップを指示した場合のみ省略し、proposal に記録）。横断概念の網羅保証の門その 1。調査ガイドに横断概念の観点（宣言・定義に触れる変更の影響先を ID の grep で特定、昇格候補の報告）を追加
+- **`/miko.new-cap` に全ケイパビリティ BR の関連調査（サブエージェント・必須）と横断概念の判定ステップを追加** — 従来は「外部との接点」に挙がった隣接 BR だけを読んでいたが、新規ケイパビリティ作成時が横断ルールの取りこぼしが最も起きやすいため、全 BR の走査と、宣言済み横断概念の判定（grep → 対話 → 効果を持つならタグ付きルールを作成）を必須化。横断概念の網羅保証の門その 2
+- **BR を更新するスキルに書き込み時 lint を追加** — `/miko.quick-impl`・`/miko.speckit.implement`・`/miko.catchup`・`/miko.quick-catchup`・`/miko.new-cap` は BR 更新直後に横断概念の構文検査（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）を実行する
+
 ## v1.4.2 (2026-07-28)
 
 ### Changed

business_rules_driven_development.md

@@ -264,10 +264,12 @@ proposal に代替案を追記（AI：重要な検討経緯があれば）
 ### 2.1 ドメインビジネスルール
 ### 2.2 システムビジネスルール
 ## 3. 関連ケイパビリティとの境界
+## 4. 横断概念（宣言する概念を所有する場合のみ）
 ```
 
 - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `<!-- last: POL-XX -->` で最終採番を記録する
 - **2.1 ドメインビジネスルール / 2.2 システムビジネスルール**: ルールを「紙運用」テストで振り分けて配置する。カテゴリ（ORD、PAY 等）はどちらか一方に置く
+- **4. 横断概念**: このケイパビリティがオーナーとして宣言する横断概念（1 概念 = 1 行、`xc:` ID + 行末マーカー）。宣言する概念を所有する場合のみセクションを作る。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照
 
 ### 操作の定義（Operations）
 
@@ -379,6 +381,39 @@ miko/<other_capability>/proposals/
 
 ## 解決済みの論点
 
+### 横断的なビジネスルールの管理（横断概念）
+
+**決定（v1.5.0〜）:** 複数ケイパビリティに効果が及ぶルール（例: 「規約違反ユーザーは各所で発信系の操作が制限される」）は、**横断概念**という一級市民の仕組みで管理する。
+
+**構造:**
+
+- **横断しているのはルール（文）ではなく概念（名詞）。** ルールは書き方次第で分割・統合される不安定な単位のため、義務は概念に付ける。横断なのはエンティティ（ユーザー）ではなく状態（規約違反）である
+- **判定テスト（3 問すべて Yes で横断概念）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか
+- **概念 ID:** `xc:{ケイパビリティディレクトリ名}/{短い英語スラッグ}`（例: `xc:user_management/tos-violator`）。ID がオーナー BR へのポインタを兼ねる。採番なし
+- **宣言（オーナーのみ）:** BR の「横断概念」セクションに 1 概念 = 1 行（業務用語 + ID + 宣言文 + 定義ルール ID + 行末 `<!-- cross-concept -->` マーカー）。定義は通常ルールとして持つ。宣言の追加・変更・除去は proposal 必須（横断プロポーザル）。セクションは宣言する概念を所有する場合のみ作る
+- **適用（効果を持つケイパビリティ）:** 効果を担うルールに `[xc:…]` タグを付ける。「概念に誰が応えているか」は ID の grep で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される）
+- **非適用は書かない。** 「検討したが効果を持たない」の記録は持たない（propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すのみ）
+- **一覧は grep で導出:** `grep -n 'cross-concept' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する
+
+**網羅性は記録ではなくプロセスの門で保証する（構成的保証）:** ケイパビリティ × 概念のすべての組は、どちらか遅い方の誕生イベントで必ず一度検討される。
+
+1. **門 1 — propose の他ケイパビリティ影響調査（必須化）:** 概念の宣言・変更は横断プロポーザルになり、影響調査が全ケイパビリティに判定を下す。調査は昇格候補（未宣言の横断関係）の発見も担う
+2. **門 2 — new-cap の横断概念判定ステップ（新設）:** 新規ケイパビリティ作成時に宣言を grep し、各概念について対話で判定する。適用なら `[xc:…]` タグ付きルールを作る
+
+加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）を実行する。harae に横断概念の必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。
+
+**既存 BR への遡及なし:** 宣言行とタグは概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。マイグレーション不要。
+
+**検討・却下した代替案:**
+
+- **glossary での管理** — glossary は参考情報でありルールとして管理・強制されない。ただし「横断するのは用語（概念）」という着眼だけは採用した
+- **ルール単位の `[横断]` マーク（横断性の宣言をルールに付ける）** — ルールは言い回しで分割・統合されるため、マークの付け先が不安定。なお採用した `[xc:…]` タグは別物で、概念への「参照」なので分割・統合で壊れない
+- **中央レジストリファイル / system HLD への機構の記載** — レジストリは本体と索引の二重管理でズレる。system HLD はプロジェクトが編集できるデータであり、miko の機構を置く場所ではない（消されても誰も復元しない）
+- **サブエージェント全走査のみ（宣言なし）** — 走査は確率的な想起であり、漏れたことを検出する分母がない。門の入力源（昇格候補の発見）として併用する
+- **適合セクション（各 BR に全宣言への適用/非適用を明示する verdict 台帳）** — 適用行はルール側タグと二重管理になり、非適用行は概念 × ケイパビリティの積で増えるノイズ。網羅性を「事後の照合」で保証する発想の産物で、門の構成的保証に置き換えて廃止
+- **非適用の記録（BR / harae.md / proposal のいずれかに残す）** — 「無記載と検討済みの区別」は事後照合が前提のときだけ必要。門で保証するなら証明の役目を失う。理由の陳腐化（後から該当操作が増える等）は記録では検出できず、残す理由にならない
+- **グローバル連番の概念 ID（XC-01 等）** — 並行ブランチで採番が衝突し、番号が情報を担わない。概念は少数で名前が一意なので、修飾付き名前で足りる
+
 ### 複数ケイパビリティにまたがる変更
 
 **決定（v0.6.0〜）:** umbrella/sub パターンに統一する。propose で横断影響を含む 1 本のプロポーザルを作成し、split-proposal で影響先ケイパビリティに影響先サブプロポーザルを作成する。implement は各サブの BR 変更に従って各ケイパビリティの business_rules.md を更新する。
@@ -388,8 +423,7 @@ miko/<other_capability>/proposals/
 ```
 /miko.propose 時:
   → 対話でドラフトを確定
-  → 「他ケイパビリティへの影響を調査しますか？」と確認
-  → サブエージェントが business_rules.md 存在するケイパビリティを走査
+  → サブエージェントが business_rules.md 存在するケイパビリティを走査（必須。v1.5.0 で任意から必須に変更）
   → 調査結果をもとに proposal の「他ケイパビリティへの影響」セクション + <needs-split> マーカーを付与
   → 完了報告で /miko.split-proposal の実行を案内
 

ofuda/VERSION

@@ -1,2 +1,2 @@
-1.4.2
-202607281022
+1.5.0
+202609050930

ofuda/examples/business_rules.md

@@ -61,6 +61,7 @@ stateDiagram-v2
 - **注文作成** — ユーザーがカートの内容から注文を作成する。
 - **注文確定** — ユーザーが注文内容を確認し確定する。
 - **注文キャンセル** — ユーザーが注文をキャンセルする。
+- **注文コメント投稿** — ユーザーが注文に問い合わせコメントを付ける。
 
 ### イベント駆動
 - **決済完了通知** — 決済プロバイダからの通知で決済完了を受け付ける。
@@ -92,6 +93,10 @@ stateDiagram-v2
 - **ORD-04** [制約] 猶予期間経過後のキャンセルは管理者操作でのみ可能とする。
   <!-- 判定: 代替案「猶予期間後は一切キャンセル不可」「カスタマーサポート経由で受付」→ ビジネスルール -->
   <!-- 紙運用: 権限による分岐は紙でも成立 → ドメインビジネスルール -->
+- **ORD-05** [制約][xc:user_management/tos-violator] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。
+  <!-- 判定: 代替案「注文操作自体も制限する」「コメントも許可し事後検閲する」→ ビジネスルール -->
+  <!-- 紙運用: 権限による分岐は紙でも成立 → ドメインビジネスルール -->
+  <!-- 横断概念の効果を担うルールの例。「規約違反ユーザー」の定義はオーナー（ユーザー管理）が持ち、このケイパビリティでの効果（どの操作を制限するか）はここで決める。タグの xc: ID が宣言への機械可読なリンク（サンプル用コメント） -->
 
 <details><summary>実装マッピング</summary>
 
@@ -100,10 +105,11 @@ stateDiagram-v2
 - ORD-02 → `Ec::OrdersController#cancel` / キャンセル前のガード
 - ORD-03 → `Ec::Order::CANCEL_GRACE_PERIOD` / 定数定義
 - ORD-04 → `Ec::OrderPolicy#cancel?` / ロール判定
+- ORD-05 → `Ec::OrderCommentPolicy#create?` / 規約違反状態の判定
 
 </details>
 
-<!-- last: ORD-04 -->
+<!-- last: ORD-05 -->
 
 ---
 
@@ -116,15 +122,20 @@ stateDiagram-v2
 - **PAY-02** [制約] 決済済み注文のキャンセル時は、対応する金額を返金しなければならない。
   <!-- 判定: 代替案「返金しない（クレジット付与のみ）」「条件付きで返金」はありえる → ビジネスルール -->
   <!-- 紙運用: 「決済済みをキャンセルしたら返金」は紙でも成立 → ドメインビジネスルール -->
+- **PAY-03** [導出] 直近90日間で未決済による自動キャンセル（PAY-01）が3回発生したユーザーは「支払い不履行ユーザー」と定義する。
+  <!-- 判定: 回数・期間はビジネスが決めた値。「1回で即」「定義しない」もありえた → ビジネスルール -->
+  <!-- 紙運用: 台帳の記録から判定できる → ドメインビジネスルール -->
+  <!-- 横断概念のオーナー側の定義ルールの例。「4. 横断概念」の宣言から参照される -->
 
 <details><summary>実装マッピング</summary>
 
 - PAY-01 → `Ec::Jobs::ExpireUnpaidOrdersJob` / 日次バッチ
 - PAY-02 → `Ec::Services::CancelOrderService` / 返金ジョブ投入
+- PAY-03 → `Ec::Orders::PaymentDefaultQuery` / 直近90日の自動キャンセル集計
 
 </details>
 
-<!-- last: PAY-02 -->
+<!-- last: PAY-03 -->
 
 ---
 
@@ -169,3 +180,11 @@ stateDiagram-v2
 - **借りているもの:** 配達完了通知
 - **渡しているもの:** 出荷依頼
 - **境界の注意点:** 配送業者の通知遅延により、実際の配達完了とステータス更新にタイムラグが生じる。この間ユーザーには「出荷済み」のまま表示される
+
+---
+
+## 4. 横断概念
+
+- **支払い不履行ユーザー** (`xc:order_management/pay-defaulter`) — 未決済の自動キャンセルを繰り返したユーザー。各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。定義: PAY-03 <!-- cross-concept -->
+  <!-- 宣言は 1 概念 = 1 行、行末の cross-concept マーカーが grep の対象。このセクションは宣言する概念を所有する場合のみ作る（サンプル用コメント） -->
+  <!-- 宣言文には「各ケイパビリティが何を表明すべきか」の軸だけを書く。他ケイパビリティの操作名は列挙しない — 効果は各ケイパビリティが自分のルール（[xc:…] タグ付き。ORD-05 参照）として持つ（サンプル用コメント） -->