From 7fa1f36a069b8b8cd225cdb65a577f9762ce2d1e Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 07:50:19 +0000 Subject: [PATCH 1/8] =?UTF-8?q?=E6=A8=AA=E6=96=AD=E6=A6=82=E5=BF=B5?= =?UTF-8?q?=E3=82=92=E5=B0=8E=E5=85=A5:=20=E6=A8=AA=E6=96=AD=E7=9A=84?= =?UTF-8?q?=E3=81=AA=20BR=20=E3=82=92=E5=AE=A3=E8=A8=80=E3=83=BB=E9=81=A9?= =?UTF-8?q?=E5=90=88=E3=83=BBgrep=20=E3=81=A7=E7=AE=A1=E7=90=86=E3=81=99?= =?UTF-8?q?=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限） を「横断概念」として管理する仕組みを追加する。 - 横断しているのはルール（文）ではなく概念（名詞）。オーナーの BR が 「宣言」（1 行 + cross-concept マーカー）を持ち、全ケイパビリティが 「適合」で態度を明示する（適用: ルール ID / 非適用: 理由）。 無記載 = 検討漏れとして機械検出できる - 一覧は grep で都度導出し、中央レジストリは持たない - harae に網羅チェック（機械照合）を追加（new-harae / harae 両モード） - new-cap に全ケイパビリティ BR 調査（必須）と適合判定ステップを追加 - propose の他ケイパビリティ影響調査を任意から必須に変更し、 調査ガイドに横断概念の観点（影響先特定・昇格候補）を追加 - 既存 BR へは遅延マイグレーション: BR を更新するスキルが更新のついでに セクションを導入し、該当なしでも「特になし」を明示する Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- CHANGELOG.md | 13 +++ business_rules_driven_development.md | 33 ++++++- ofuda/VERSION | 4 +- ofuda/examples/business_rules.md | 33 ++++++- ofuda/guides/business_rules_guide.md | 85 ++++++++++++++++++- ofuda/guides/harae_guide.md | 16 ++++ skills/miko.catchup/SKILL.md | 1 + skills/miko.harae/SKILL.md | 7 +- skills/miko.miko/SKILL.md | 8 +- skills/miko.new-cap/SKILL.md | 41 +++++++-- skills/miko.new-harae/SKILL.md | 14 +-- skills/miko.propose/SKILL.md | 19 ++--- .../guides/cross_capability_impact_guide.md | 28 +++++- skills/miko.quick-catchup/SKILL.md | 1 + skills/miko.quick-impl/SKILL.md | 4 + skills/miko.speckit.implement/SKILL.md | 1 + 16 files changed, 271 insertions(+), 37 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5923997..cc6e3d6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,18 @@ # Changelog +## v1.5.0 (2026-09-05) + +### New + +- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。横断しているのはルール（文）ではなく概念（名詞）という整理に基づき、オーナーの BR の「横断概念 > 宣言」に 1 概念 = 1 行で宣言し（行末に `` マーカー）、全ケイパビリティは「横断概念 > 適合」で全宣言への態度を明示する（適用: ルール ID / 非適用: 理由。無記載 = 検討漏れとして機械検出可能）。一覧は `grep 'cross-concept' miko/*/business_rules.md` で都度導出し、中央レジストリは持たない。判定テスト（他者性・全称性・必達性）、宣言・適合の書式、責務の分担を `business_rules_guide.md` の「横断概念とは何か」に定義。BR 構造にセクション 4 を追加し、`.miko/examples/business_rules.md` に実例（ORD-05 と適合セクション）を追加。検討経緯は `business_rules_driven_development.md` の「解決済みの論点」を参照 +- **harae に横断概念の網羅チェック（機械照合）を追加** — `harae_guide.md` に手順を定義し、`/miko.new-harae`・`/miko.harae`（再実行・proposal 検証の両モード）がメインセッションで実施する。未移行セクション・適合の検討漏れ・要判定の放置・参照切れを推論ではなく機械照合で検出する +- **既存 BR への遅延マイグレーション** — 横断概念セクションを持たない既存 business_rules.md は、BR を更新するスキル（`/miko.quick-impl`・`/miko.speckit.implement`・`/miko.catchup`・`/miko.quick-catchup`）が更新のついでにセクションを導入する（「既存 BR の構造に手を入れない」原則の唯一の例外）。該当がなくても `特になし` を明示し、「未検討」と「検討済みでゼロ」を区別する + +### Changed + +- **`/miko.propose` の他ケイパビリティ影響調査を任意から必須に変更** — 従来の「調査しますか？」の確認をやめ、デフォルトで実行する（主さまが明示的にスキップを指示した場合のみ省略し、proposal に記録）。調査ガイドに横断概念の観点（宣言・定義に触れる変更の影響先特定、昇格候補の報告）を追加 +- **`/miko.new-cap` に全ケイパビリティ BR の関連調査（サブエージェント・必須）と横断概念の適合判定ステップを追加** — 従来は「外部との接点」に挙がった隣接 BR だけを読んでいたが、新規ケイパビリティ作成時が横断ルールの取りこぼしが最も起きやすいため、全 BR の走査と、宣言済み横断概念への適合判定（grep → 対話 → 適合セクションに記録）を必須化 + ## v1.4.2 (2026-07-28) ### Changed diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index 2f9038e..9720e01 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -264,10 +264,14 @@ proposal に代替案を追記（AI：重要な検討経緯があれば） ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 +## 4. 横断概念 +### 宣言 +### 適合 ``` - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `` で最終採番を記録する - **2.1 ドメインビジネスルール / 2.2 システムビジネスルール**: ルールを「紙運用」テストで振り分けて配置する。カテゴリ（ORD、PAY 等）はどちらか一方に置く +- **4. 横断概念**: 全ケイパビリティに適合判定を課す概念の「宣言」（オーナー側）と、他ケイパビリティの宣言への「適合」（全ケイパビリティ）。該当がなくても `特になし` を明示する。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 ### 操作の定義（Operations） @@ -379,6 +383,32 @@ miko//proposals/ ## 解決済みの論点 +### 横断的なビジネスルールの管理（横断概念） + +**決定（v1.5.0〜）:** 複数ケイパビリティに効果が及ぶルール（例: 「規約違反ユーザーは各所で発信系の操作が制限される」）は、**横断概念**という一級市民の仕組みで管理する。 + +**構造:** + +- **横断しているのはルール（文）ではなく概念（名詞）。** ルールは書き方次第で分割・統合される不安定な単位のため、義務は概念に付ける。横断なのはエンティティ（ユーザー）ではなく状態（規約違反）である +- **判定テスト（3 問すべて Yes で横断概念）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか +- **宣言（オーナー側）:** 概念のオーナーが BR の「横断概念 > 宣言」に 1 概念 = 1 行で宣言し、行末に `` マーカーを付ける。定義（誰がその状態になるか）は通常ルールとして持つ。宣言の追加・変更・除去は proposal 必須（横断プロポーザル） +- **適合（全ケイパビリティ）:** 各 BR の「横断概念 > 適合」に、他ケイパビリティの全宣言への態度を明示する。適用ならルール ID（効果はそのケイパビリティのドメイン判断なので、消費側の通常ルールとして書く）、非適用なら理由。**非適用の明示により「無記載 = 検討漏れ」が機械検出可能になる** +- **一覧は grep で導出:** `grep -n 'cross-concept' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する + +**強制は 2 層:** + +1. **決定的チェック（grep・保証担当）** — new-cap が宣言を grep して全概念の適合判定を必須ステップで確認し、harae が「全宣言 × 適合」の網羅を機械照合する。宣言済みの義務の取りこぼしをゼロにする +2. **サブエージェント全走査（発見担当）** — new-cap / propose で全ケイパビリティ BR の調査を必須化（従来 propose では任意だった）。未宣言の横断関係や「横断概念に昇格すべき候補」を発見し、宣言（層 1）の入力源にする。走査は発見はできるが漏れの検出はできない（分母がない）ため、層 1 の代替にはならない + +**既存 BR への導入は遅延マイグレーション:** business_rules.md を更新するスキル（quick-impl / speckit.implement / catchup / quick-catchup）が、更新のついでに横断概念セクションを導入する。該当がなくても `特になし` を明示し、「未検討」と「検討済みでゼロ」を区別する。 + +**検討・却下した代替案:** + +- **glossary での管理** — glossary は参考情報でありルールとして管理・強制されない。ただし「横断するのは用語（概念）」という着眼だけは採用した +- **ルール単位の `[横断]` マーク** — ルールは言い回しで分割・統合されるため、マークの付け先が不安定（「点を調べる」ことになる） +- **中央レジストリファイル / system HLD への機構の記載** — レジストリは本体と索引の二重管理でズレる。system HLD はプロジェクトが編集できるデータであり、miko の機構を置く場所ではない（消されても誰も復元しない） +- **サブエージェント全走査のみ（宣言なし）** — 走査は確率的な想起であり、漏れたことを検出する分母がない。判断が記録されず毎回再検討になる。層 2 として併用に留める + ### 複数ケイパビリティにまたがる変更 **決定（v0.6.0〜）:** umbrella/sub パターンに統一する。propose で横断影響を含む 1 本のプロポーザルを作成し、split-proposal で影響先ケイパビリティに影響先サブプロポーザルを作成する。implement は各サブの BR 変更に従って各ケイパビリティの business_rules.md を更新する。 @@ -388,8 +418,7 @@ miko//proposals/ ``` /miko.propose 時: → 対話でドラフトを確定 - → 「他ケイパビリティへの影響を調査しますか？」と確認 - → サブエージェントが business_rules.md 存在するケイパビリティを走査 + → サブエージェントが business_rules.md 存在するケイパビリティを走査（必須。v1.5.0 で任意から必須に変更） → 調査結果をもとに proposal の「他ケイパビリティへの影響」セクション + マーカーを付与 → 完了報告で /miko.split-proposal の実行を案内 diff --git a/ofuda/VERSION b/ofuda/VERSION index 1a6966b..4ebdf61 100644 --- a/ofuda/VERSION +++ b/ofuda/VERSION @@ -1,2 +1,2 @@ -1.4.2 -202607281022 +1.5.0 +202609050749 diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index 72b1549..34c3b12 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -61,6 +61,7 @@ stateDiagram-v2 - **注文作成** — ユーザーがカートの内容から注文を作成する。 - **注文確定** — ユーザーが注文内容を確認し確定する。 - **注文キャンセル** — ユーザーが注文をキャンセルする。 +- **注文コメント投稿** — ユーザーが注文に問い合わせコメントを付ける。 ### イベント駆動 - **決済完了通知** — 決済プロバイダからの通知で決済完了を受け付ける。 @@ -92,6 +93,10 @@ stateDiagram-v2 - **ORD-04** [制約] 猶予期間経過後のキャンセルは管理者操作でのみ可能とする。 +- **ORD-05** [制約] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 + + +
実装マッピング @@ -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?` / 規約違反状態の判定
- + --- @@ -169,3 +175,28 @@ stateDiagram-v2 - **借りているもの:** 配達完了通知 - **渡しているもの:** 出荷依頼 - **境界の注意点:** 配送業者の通知遅延により、実際の配達完了とステータス更新にタイムラグが生じる。この間ユーザーには「出荷済み」のまま表示される + +--- + +## 4. 横断概念 + + + +### 宣言 + +このケイパビリティが所有する横断概念。全ケイパビリティ（将来作成されるものを含む）に適合判定の義務を課す。 + +- 特になし + + + +### 適合 + +他ケイパビリティが宣言する横断概念への態度。宣言されている**すべての**概念について、適用（対応するルール ID）または非適用（理由）を明示する。 + +- **規約違反ユーザー**（ユーザー管理）→ 適用: ORD-05 +- **凍結テナント**（テナント管理）→ 非適用（本ケイパビリティの操作はすべて単一テナント内で完結し、凍結テナントのユーザーはログイン自体が拒否されるため） + diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 53dcc1b..55e9a34 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -325,6 +325,80 @@ high_level_design.md（AI が更新：構造の変化） --- +## 横断概念とは何か + +**横断概念とは、他ケイパビリティが所有する操作の可否や意味を変える状態・属性のことである。** 「規約違反ユーザー」「凍結テナント」のように、1 つのケイパビリティが定義するが、効果はシステム全体に及ぶ。 + +横断概念は、**まだ存在しないケイパビリティも含めた全ケイパビリティ**に「この概念にどう向き合うか」の表明（適合判定）を義務づける。義務をルール（文）ではなく概念（名詞）に付けるのは、ルールは書き方次第で分割・統合される不安定な単位である一方、概念は言い回しで増減しないためである。 + +### 判定テスト: 横断概念か + +候補が横断概念かどうかは、以下の 3 問で判定する。**すべて Yes のときだけ**横断概念として宣言する。 + +1. **他者性**: その状態・属性は、**他ケイパビリティが所有する操作**の可否や意味を変えるか？ 自ケイパビリティの操作しか変えないなら No（例: 注文の「出荷済み」はキャンセル可否を変えるが、それは注文管理自身の操作 → No） +2. **全称性**: 義務の相手を列挙できないか？ 特定の 2〜3 ケイパビリティ間の話なら、境界セクションとルールの相互参照で足りる（No）。**将来作られるケイパビリティも対象**になるものだけが Yes +3. **必達性**: 新しいケイパビリティを作る人に、中身を聞く前に必ず伝えるべきことか？ + +**数の目安**: 横断概念はシステム全体で数個に収まるはずである（例: 規約違反ユーザー、テナント分離、料金プランによる機能制限、退会ユーザーのデータ保持）。10 個に近づいたら、判定テストの運用が緩んでいるか、ドメイン設計自体の問題（神概念の存在）を疑う。 + +**横断なのはエンティティではなく状態である。** 「ユーザー」という概念全体が横断なのではない。「規約違反」という特定の状態だけが横断であり、「メール確認済み」「最終ログイン日時」はオーナーに閉じる。 + +### 責務の分担 + +| 何を | どこに書くか | +|---|---| +| 概念の定義（誰がその状態になるか・解除条件） | オーナーの BR の通常ルール（[導出] / [制約]） | +| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「横断概念 > 宣言」 | +| 各ケイパビリティでの具体的な効果 | 各ケイパビリティの BR の通常ルール + 「横断概念 > 適合」 | + +効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。 + +### 宣言の書き方 + +宣言は **1 概念 = 1 行**とし、行末に機械マーカー `` を付ける。このマーカーが grep の対象であり、**システム全体の横断概念一覧は次のコマンドで都度導出する**（中央のレジストリファイルは持たない。本体と索引の二重管理を避けるため）: + +```bash +grep -n 'cross-concept' miko/*/business_rules.md +``` + +```markdown +### 宣言 + +- **規約違反ユーザー** — 規約違反が確定したが、ビジネス上 BAN はできないユーザー。各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。定義: USER-08〜USER-09 +``` + +- 宣言する概念がなければ `- 特になし` と明示する（セクション自体は省略しない） +- 宣言文には、概念の 1 行説明・各ケイパビリティが何を表明すべきかの軸・定義ルールの ID を書く。個別ケイパビリティの操作名は書かない +- マーカー `` は宣言行以外に書かない（散文・ルール本文・適合エントリに書くと grep の一覧が壊れる） +- **宣言の追加・変更・除去は proposal 必須。** 全ケイパビリティに適合判定の義務を課す（または解除する）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う + +### 適合の書き方 + +他ケイパビリティが宣言する**すべての**横断概念について、態度を 1 行で明示する。**無記載の概念があってはならない**（無記載は「検討漏れ」として harae が機械的に指摘する）。自ケイパビリティが宣言した概念は書かない。 + +```markdown +### 適合 + +- **規約違反ユーザー**（ユーザー管理）→ 適用: RESTRICT-01 +- **凍結テナント**（テナント管理）→ 非適用（このケイパビリティの操作はテナント文脈を持たないため） +``` + +- **適用**: 効果を表す自ケイパビリティのルール ID を列挙する +- **非適用**: 理由を必ず書く。「検討したうえで対象外と判断した」ことの記録であり、無記載（検討漏れ）と区別するための明示である +- 判定をその場で確定できない場合は `→ 要判定 ` と書き、完了報告で明示する +- 宣言されている横断概念がシステムに 1 つもない場合は `- 特になし（宣言されている横断概念はない）` と書く + +### 既存 BR への導入（遅延マイグレーション） + +横断概念セクションを持たない既存の business_rules.md は、**business_rules.md を更新するスキルが、更新のついでにセクションを導入する**（「既存 BR の構造に手を入れない」原則の唯一の例外）。手順: + +1. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する +2. 既存の構造を崩さず、末尾（境界セクションの後）に「横断概念」セクションを追加する。既存 BR のセクション番号体系が異なる場合は番号を無理に合わせなくてよい（番号なしの `## 横断概念` でよい） +3. 「宣言」は `- 特になし` から始める。このケイパビリティが横断概念を所有していそうな場合も、この場では宣言せず「昇格候補」としてユーザーに報告する（宣言は proposal を通す） +4. 「適合」は宣言済みの各概念について判定を記録する。対話フェーズのあるスキルはユーザーに確認し、確認できないものは `→ 要判定 ` と書いて完了報告で明示する + +--- + ## ドキュメント構造 ``` @@ -338,9 +412,12 @@ high_level_design.md（AI が更新：構造の変化） ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 +## 4. 横断概念 +### 宣言 +### 適合 ``` -**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。 +**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。**唯一の例外は横断概念セクション**で、business_rules.md を更新するスキルが更新のついでに導入する（前述「既存 BR への導入（遅延マイグレーション）」参照）。 ### 各セクションの指針 @@ -369,7 +446,9 @@ high_level_design.md（AI が更新：構造の変化） **ビジネスルール・カタログ**: `### 2.1 ドメインビジネスルール`（紙の運用でも成り立つもの）と `### 2.2 システムビジネスルール`（システム前提のもの）の 2 セクションに分けて配置する。同一カテゴリ（ORD、PAY 等）はどちらか一方に置く。ドメインとシステムが混じるカテゴリはカテゴリの分割を検討する。詳細は前述の「ドメインビジネスルール / システムビジネスルールの区別」と、後述の「ビジネスルール・カタログの書き方」を参照。 -**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。 +**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。 + +**横断概念**: 「宣言」と「適合」の 2 サブセクション。詳細は前述の「横断概念とは何か」を参照。宣言する概念がなくても、適合すべき概念がなくても、`特になし` を明示する（セクションは省略しない）。 > **注意:** アーキテクチャ上の決定事項（ADR）は business_rules.md には書かない。技術選択の「決定・意図・トレードオフ」は high_level_design.md の「設計上の特徴」セクションに記載する。 @@ -450,6 +529,7 @@ high_level_design.md（AI が更新：構造の変化） 6. 各ルール候補に「紙運用」テストを適用し、ドメインビジネスルール（2.1）とシステムビジネスルール（2.2）に振り分ける。1 ルール内に両方が混在している場合は分解する 7. 実装マッピングを `
` 内に記載する 8. コードに暗黙的に埋め込まれているが明文化されていないルール・ポリシーがあれば「暗黙のルール（要確認）」として末尾に列挙する +9. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、「横断概念 > 適合」に各概念への判定を記載する（前述「適合の書き方」参照）。コードから適合が読み取れる場合（例: 制限の実装が見つかる）は対応ルールと紐づける ### モード B: 提案から生成する場合 * 提案には、ビジネスルールではない詳細な仕様が書かれることがあるが、それはビジネスルールには記載しない。 @@ -460,3 +540,4 @@ high_level_design.md（AI が更新：構造の変化） 4. ルール候補に「紙運用」テストを適用し、ドメインビジネスルール（2.1）とシステムビジネスルール（2.2）に振り分ける 5. 提案に明示されていないが論理的に必要なルール・ポリシーを推論し「暗黙のルール（要確認）」として末尾に列挙する 6. 提案に技術選択が含まれる場合、high_level_design.md の「設計上の特徴」への追記を検討する +7. 提案に含まれる状態・属性に「判定テスト: 横断概念か」を適用し、満たすものは横断概念の昇格候補としてユーザーに提示する（宣言は proposal を通す） diff --git a/ofuda/guides/harae_guide.md b/ofuda/guides/harae_guide.md index 3f64261..2e262a6 100644 --- a/ofuda/guides/harae_guide.md +++ b/ofuda/guides/harae_guide.md @@ -45,6 +45,22 @@ --- +## 機械照合: 横断概念の網羅チェック（メインセッションが実施） + +サブエージェント A/B/C の担当外。呼び出し元スキルのメインセッションが、6軸の探索とは別に **推論ではなく機械照合として** 実施する。 + +1. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する（対象ケイパビリティ自身の宣言は分母から除く） +2. 対象 BR の「横断概念 > 適合」と突き合わせ、以下を指摘する: + - 横断概念セクション自体がない（未移行の旧フォーマット） + - 宣言済み概念に対応する適合エントリがない（検討漏れ） + - `要判定` のまま放置されている適合エントリ + - 適用エントリが参照するルール ID が対象 BR に存在しない +3. 逆方向も確認する: 対象 BR が宣言する横断概念について、宣言行の書式（1 行・行末マーカー）が守られているか、定義ルールが実在するか + +指摘は検証軸「不完全性」に分類し、通常の指摘と同じ構造で記述する（深刻度は検討漏れ・未移行なら「高」）。照合が全件一致なら指摘なし。 + +--- + ## サブエージェント A: 論理的整合性 担当軸: **内部矛盾** + **不完全性** diff --git a/skills/miko.catchup/SKILL.md b/skills/miko.catchup/SKILL.md index 64e9921..d3a027b 100644 --- a/skills/miko.catchup/SKILL.md +++ b/skills/miko.catchup/SKILL.md @@ -161,6 +161,7 @@ $ARGUMENTS - 承認された削除 - 実装マッピング - 操作の定義（コードから新しい操作が見つかった場合） +- **横断概念セクションの遅延マイグレーション** — business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定はコード精読の結果から案を立て、確認②で主さまに確認する。確認できないものは `→ 要判定 ` として記録し完了報告で明示する **glossary.md の更新:** - proposal で新しい用語が登場した場合は `miko/glossary.md` に追加する（ファイルがなければ作成） diff --git a/skills/miko.harae/SKILL.md b/skills/miko.harae/SKILL.md index d5b815c..e2c21e5 100644 --- a/skills/miko.harae/SKILL.md +++ b/skills/miko.harae/SKILL.md @@ -89,7 +89,9 @@ proposal が指定されていない場合。メインセッションで棚卸 ### 3. 差分探索 -メインセッションが6軸で新たな指摘を探索する。既存の指摘（全ステータス）と重複するものは除外する。 +まず `.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」を実施する（未移行・検討漏れ・要判定の放置・参照切れを機械的に検出する）。 + +続けて、メインセッションが6軸で新たな指摘を探索する。既存の指摘（全ステータス）と重複するものは除外する。 ### 4. harae.md 更新 @@ -146,6 +148,9 @@ proposal に「他ケイパビリティへの影響」セクションがある メインセッションとサブエージェントで役割を分担する: +**メインセッション — 横断概念の網羅チェック（機械照合）:** +proposal のルール変更を仮想適用した BR に対して、`.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」を実施する。proposal が横断概念の宣言を追加・変更・除去する場合は、全ケイパビリティの適合が揃うか（「他ケイパビリティへの影響」セクションでカバーされているか）も照合する。 + **メインセッション — 6軸の差分探索:** proposal のルール変更を仮想適用した BR 体系に対して、6軸で新たな指摘を探索する。既存の harae.md の指摘（全ステータス）と重複するものは除外する。 diff --git a/skills/miko.miko/SKILL.md b/skills/miko.miko/SKILL.md index e2d7c43..38d08a6 100644 --- a/skills/miko.miko/SKILL.md +++ b/skills/miko.miko/SKILL.md @@ -169,7 +169,13 @@ miko の実装フローでは **constitution**（`.specify/memory/constitution.m 5. **「用語の定義はどこに書く？」** - すべて `miko/glossary.md` に定義する（BR には用語集セクションを持たない） -6. **「constitution に何を書けばいい？」「CLAUDE.md に書くのと何が違う？」** +6. **「複数のケイパビリティに効くルールはどこに書く？」「これって横断概念？」** + - `business_rules_guide.md` の「判定テスト: 横断概念か」（他者性・全称性・必達性）を一緒に適用する + - 3 問すべて Yes → オーナーの BR に宣言（`/miko.propose` 経由）、効果は各ケイパビリティのルール + 適合に書く + - 相手を列挙できる二者間の依存 → 境界セクションで足りる（横断概念にしない） + - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md` で提示する + +7. **「constitution に何を書けばいい？」「CLAUDE.md に書くのと何が違う？」** - 実装フローで毎回守ってほしいプロジェクト固有のルール → constitution - 日常の開発作業全般に効かせたい指示 → CLAUDE.md - 具体例: 「API 実装時は Swagger 必須」「スキーマ変更は独立フェーズ」→ constitution 向き diff --git a/skills/miko.new-cap/SKILL.md b/skills/miko.new-cap/SKILL.md index 348d1d0..f995848 100644 --- a/skills/miko.new-cap/SKILL.md +++ b/skills/miko.new-cap/SKILL.md @@ -136,15 +136,35 @@ $ARGUMENTS **コードが見つからなかった場合:** - 完全に新規のケイパビリティ。実装マッピングは全て `（未実装）` とする -**6b. 隣接ケイパビリティの BR 読み込み** +**6b. 全ケイパビリティ BR の関連調査（サブエージェント・必須）** -- `miko/*/business_rules.md` を Glob で検出し、確認①の「外部との接点」に挙がったケイパビリティの business_rules.md を読む -- 外部との接点に該当しなくても、ケイパビリティ名やドメイン概念が関連しそうなものは読む -- **確認する観点:** - - 同じ概念に矛盾する定義がないか（用語の不整合） - - 境界の責務分担が既存 BR と整合するか - - 隣接 BR から借りられるルール（重複定義を避ける） -- 隣接 BR との整合性の問題を発見した場合、ステップ 9 の確認②に「隣接 BR との整合性」セクションを追加して報告する +`miko/*/business_rules.md` を Glob で列挙する。既存 BR が 1 つもなければこのステップをスキップする。 + +存在する場合、Sonnet サブエージェント（Agent ツール、model: "sonnet"）を起動し、**全ケイパビリティ**の BR を調査する（対象が多い場合はケイパビリティを分担して並列起動する）。「外部との接点」に挙がったものだけに絞らない — 新規ケイパビリティ作成時は、関連の見落としが最も起きやすい。 + +サブエージェントに渡す情報: +- 確認①の要約（目的・主要な操作・中心データ・外部との接点） +- 担当ケイパビリティの business_rules.md のパス + +サブエージェントに報告させる観点: +- 同じ概念に矛盾する定義がないか（用語の不整合） +- 境界の責務分担が既存 BR と整合するか / 借りられるルール（重複定義を避ける） +- 新ケイパビリティとの間に横断的な依存がないか（あれば境界セクションの候補として報告） + +発見された問題は、ステップ 9 の確認②に「既存 BR との整合性」セクションを追加して報告する。 + +**6c. 横断概念の適合判定（必須）** + +`grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する。 + +ヒットした各概念について: +1. 宣言行（概念名・宣言文・定義ルール ID）を読む。判定に必要なら、オーナー BR から定義ルールの本文だけを読む（BR ファイル全体は読まない） +2. ユーザーに適合を確認する（例: 「ユーザー管理が横断概念『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） +3. 判定結果を記録する — 適用（効果を表すルールをルール候補に加える）/ 非適用（理由） + +ヒットが 1 件もない場合も「特になし」を記録する（ステップ 11 で「適合」に明示するため、このステップ自体は省略しない）。 + +ヒアリングやコード調査で、新ケイパビリティ自身が横断概念（`.miko/guides/business_rules_guide.md` の「判定テスト: 横断概念か」を満たす状態）を持ちそうな場合は、この場では宣言せず**昇格候補**として記録し、ステップ 12 の完了報告で `/miko.propose` を案内する（宣言は全ケイパビリティに義務を課すため proposal を通す）。 ### 7. ルール策定・構造化 @@ -214,6 +234,9 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を - 実装マッピング: - 既存コードがある場合: `
` 内に記載 - 未実装の場合: `
` 内に `（未実装）` マーク付きで記載 +- **横断概念セクションを必ず含める**（ガイドの「横断概念とは何か」参照）: + - 「宣言」は `- 特になし`（昇格候補があっても宣言しない。proposal を通す） + - 「適合」はステップ 6c の判定結果を全概念分記載する。宣言済み概念がなければ `- 特になし（宣言されている横断概念はない）` - 未決事項がある場合、末尾に「未決事項」セクションを追加 ```markdown @@ -250,4 +273,4 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を ### 12. 完了報告 -生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。 +生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数、横断概念の適合判定数（適用/非適用）をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。ステップ 6c で横断概念の昇格候補を記録した場合は提示し、`/miko.propose` による宣言を案内する。 diff --git a/skills/miko.new-harae/SKILL.md b/skills/miko.new-harae/SKILL.md index a75ca15..27f46c5 100644 --- a/skills/miko.new-harae/SKILL.md +++ b/skills/miko.new-harae/SKILL.md @@ -59,7 +59,11 @@ $ARGUMENTS - `miko//high_level_design.md` — あれば - `miko/glossary.md` — あれば -### 2. 攻撃的検証（サブエージェント並列） +### 2. 横断概念の網羅チェック（機械照合） + +`.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」に従い、メインセッションで実施する。指摘があれば検証軸「不完全性」としてステップ 4 の統合結果に加える。 + +### 3. 攻撃的検証（サブエージェント並列） 3つのサブエージェントを並列で起動する。 @@ -78,13 +82,13 @@ $ARGUMENTS 各サブエージェントは **指摘リストのみ** 返す。問題が見つからなければ「指摘なし」。 -### 3. 結果統合・ファイル生成 +### 4. 結果統合・ファイル生成 -サブエージェントの結果を統合し、重複を排除して `harae.md` を生成する。 +ステップ 2 の機械照合の指摘とサブエージェントの結果を統合し、重複を排除して `harae.md` を生成する。 **指摘がない場合も `harae.md` を生成する。** 指摘一覧テーブルは空にし、詳細セクションに「6軸すべてで指摘事項なし」と記載する。 -### 4. 対話 +### 5. 対話 指摘について主さまと対話し、対処を決める。 @@ -96,6 +100,6 @@ $ARGUMENTS **指摘がない場合はこのステップをスキップする。** -### 5. 完了 +### 6. 完了 指摘数とステータス内訳（resolved/dismissed/open）をサマリーテーブルで提示する。open があれば `/miko.harae` による再検証をお勧めする。 diff --git a/skills/miko.propose/SKILL.md b/skills/miko.propose/SKILL.md index 152d691..724e2b1 100644 --- a/skills/miko.propose/SKILL.md +++ b/skills/miko.propose/SKILL.md @@ -153,19 +153,9 @@ $ARGUMENTS 最終的な proposal と同じ構造（`.miko/examples/proposal.md` 参照）で骨子を提示し、フィードバックを受ける。特にビジネスルールの変更案の妥当性、機能仕様のスコープ、見落としている代替案がないかを確認する。禊の審査結果（審査件数・修正・除外・覆しと理由）も簡潔に報告する。大きな方向転換があればステップ 5 に戻る。 -### 9. 他ケイパビリティへの影響調査（任意） +### 9. 他ケイパビリティへの影響調査（必須） -確認②が承認されたら、以下を確認する: - -``` -⛩️ 他のケイパビリティへの影響を調査いたしましょうか？ -business_rules.md が存在するケイパビリティを対象に、サブエージェントが調査いたします。 -（はい / いいえ） -``` - -**「いいえ」の場合:** このステップをスキップし、ステップ 10 へ進む。 - -**「はい」の場合:** サブエージェント（Agent ツール）を起動して調査を行う。 +確認②が承認されたら、サブエージェント（Agent ツール）を起動して調査を行う。**このステップは省略しない**（主さまが明示的にスキップを指示した場合のみ省略し、その旨を proposal の影響範囲セクションに記録する）。`miko/` 配下に他ケイパビリティの business_rules.md が 1 つも存在しない場合はスキップしてよい。 サブエージェントに渡す情報: - `.claude/skills/miko.propose/guides/cross_capability_impact_guide.md` のパス — 「このファイルを読み、指示に従え」と指示する @@ -175,6 +165,9 @@ business_rules.md が存在するケイパビリティを対象に、サブエ **調査結果の扱い:** - 影響なし: 「他ケイパビリティへの影響はございませんでした」と報告し、ステップ 10 へ進む - 影響あり: 結果をユーザーに提示し、内容を確認・修正してもらう。確認後にステップ 10 でプロポーザルの「他ケイパビリティへの影響」セクションに反映し、**プロポーザルの先頭に `` マーカーを付与する**（このマーカーがないと実装対象プロポーザルとして扱われてしまうため） +- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「横断概念 > 宣言」の追加を含め、全ケイパビリティの「横断概念 > 適合」への影響を「他ケイパビリティへの影響」に反映して `` を付与する + +**横断プロポーザルになる典型:** 変更が横断概念の宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念に適合している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 ### 10. プロポーザル生成 @@ -184,7 +177,7 @@ business_rules.md が存在するケイパビリティを対象に、サブエ **構造:** `.miko/examples/proposal.md` に従う。以下の点に注意: - 該当するセクションのみ含める（空セクションは作らない） -- 「他ケイパビリティへの影響」はステップ 9 で影響ありの場合のみ +- 「他ケイパビリティへの影響」はステップ 9 で影響ありの場合のみ。ステップ 9 を主さまの指示でスキップした場合は、影響範囲セクションに「他ケイパビリティへの影響調査は主さまの指示によりスキップ」と記録する - ステップ 9 で影響ありの場合、プロポーザルの先頭に `` マーカーを付与する - 「祓え検証」セクションは `/miko.harae` が後から追記する。propose では生成しない - 検討・却下した代替案は「これを知らないと将来間違えそう」というものだけ記録する diff --git a/skills/miko.propose/guides/cross_capability_impact_guide.md b/skills/miko.propose/guides/cross_capability_impact_guide.md index 0aa3d3d..0845256 100644 --- a/skills/miko.propose/guides/cross_capability_impact_guide.md +++ b/skills/miko.propose/guides/cross_capability_impact_guide.md @@ -11,12 +11,18 @@ ## 最初に読むファイル 調査を始める前に、以下のファイルを自分で読み込むこと: -- `.miko/guides/business_rules_guide.md` — ルールの判定テスト基準 +- `.miko/guides/business_rules_guide.md` — ルールの判定テスト基準（「横断概念とは何か」を含む） - `miko/<メインケイパビリティ>/business_rules.md` — メインケイパビリティの現行ルール - `miko/<メインケイパビリティ>/high_level_design.md` — メインケイパビリティの構造（あれば） - `miko/system_high_level_design.md` — システム全体のアーキテクチャ（あれば） - `miko/glossary.md` — 用語集。ケイパビリティ間で共有される概念の定義を確認する（あれば） +さらに、宣言済みの横断概念を列挙しておく: + +```bash +grep -n 'cross-concept' miko/*/business_rules.md +``` + ## 目的 今回の変更案が、メインケイパビリティ以外のケイパビリティのビジネスルールに波及的な変更を必要とするかを調査する。 @@ -64,6 +70,11 @@ business_rules.md が存在しないケイパビリティは管理対象外で **廃止が必要なケース:** - 変更案でメインケイパビリティの責務が変わり、このケイパビリティのルールが不要になる +**横断概念に関わるケース:** +- 変更案が宣言済み横断概念の宣言文・定義ルールを変える → その概念に適合している（「横断概念 > 適合」に適用/非適用を表明している）全ケイパビリティが影響対象。適合エントリと適用ルールの改訂要否を判定する +- 変更案が新しい横断概念の宣言を含む → 全ケイパビリティで適合の追記が必要（各ケイパビリティの操作から適用/非適用の案を出す） +- 変更案に含まれる状態・属性が「判定テスト: 横断概念か」（business_rules_guide.md）を満たす → 変更案自体は宣言していなくても **昇格候補** として報告する + ### 3. 影響なしの判定基準 以下の場合は「影響なし」と判定し、報告しない: @@ -101,6 +112,21 @@ business_rules.md が存在しないケイパビリティは管理対象外で - **PREF-XX**（廃止） - 理由: （なぜ不要になるか） +##### 横断概念の適合の変更（該当する場合） +- **{概念名}**（{オーナー}）→ 適用: PREF-XX / 非適用（理由） + - 根拠: （変更案のどの部分が起点か） + +``` + +### 横断概念の昇格候補（該当する場合） + +変更案に含まれる状態・属性が横断概念の判定テストを満たす場合、影響一覧とは別に報告する: + +``` +### 横断概念の昇格候補 + +- **{概念名}** — {宣言文の案（各ケイパビリティが何を表明すべきかの軸を含む）} + - 判定根拠: 他者性 / 全称性 / 必達性 それぞれの理由 ``` **ルール ID の採番:** diff --git a/skills/miko.quick-catchup/SKILL.md b/skills/miko.quick-catchup/SKILL.md index f33247e..e1846cd 100644 --- a/skills/miko.quick-catchup/SKILL.md +++ b/skills/miko.quick-catchup/SKILL.md @@ -115,6 +115,7 @@ diff ソース、変更の要約、ビジネスルールへの影響（新設/ **ステップ 6 で生成した proposal の内容を business_rules.md に反映する。** - proposal の新設・改訂を適用する - 実装マッピングを更新する +- **横断概念セクションの遅延マイグレーション** — business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものはステップ 8 末尾の確認で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する - 新しい用語があれば `miko/glossary.md` に追加する（`.miko/examples/glossary.md` のフォーマットに従う。実装の詳細は書かず、1〜2文の定義だけを書く） - ケイパビリティの節は配置の軸であり、意味のスコープではない。見出し語はシステム全体で一意にする。既存の見出し語と衝突する場合は、同じ意味なら1項目に統合し、別概念なら一意な別名を立てる（注文確定 / 決済確定） diff --git a/skills/miko.quick-impl/SKILL.md b/skills/miko.quick-impl/SKILL.md index 2738f83..c7ef5b5 100644 --- a/skills/miko.quick-impl/SKILL.md +++ b/skills/miko.quick-impl/SKILL.md @@ -144,6 +144,10 @@ miko の原則として BR ルール本文の変更には proposal が必要。p - proposal がある場合のみ: proposal の新設・改訂・廃止を BR 本文に適用する - proposal がない場合: BR 本文は一切触らない（スコープガード (d) で除外済みのはず） +#### 横断概念セクションの遅延マイグレーション + +business_rules.md を更新した場合で、そのファイルに横断概念セクション（宣言 / 適合）がないとき、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものは末尾の「更新内容の確認」で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する。BR を更新しない実行ではスキップする。 + #### 実装マッピングの横断更新（Sonnet サブエージェント） 実装の変更がどの cap の実装マッピングに波及したかを機械的にチェック・更新する。 diff --git a/skills/miko.speckit.implement/SKILL.md b/skills/miko.speckit.implement/SKILL.md index 439641c..2b929d9 100644 --- a/skills/miko.speckit.implement/SKILL.md +++ b/skills/miko.speckit.implement/SKILL.md @@ -143,6 +143,7 @@ tasks.md の最終フェーズに到達したら、以下の順序で実行す - 今回の実装で作成・変更したファイルを元に、該当ルールの実装マッピング（`
` 内）を更新する - 既存ルールでも実装場所が変わったものがあれば更新する - **spec.md の Miko コンテキストに複数ケイパビリティのサブプロポーザルが含まれている場合:** 各サブプロポーザルの BR 変更セクションに従って、各ケイパビリティの `miko//business_rules.md` をそれぞれ更新する +- **横断概念セクションの遅延マイグレーション:** 更新した各 business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものはステップ 6 の確認で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する **3. high_level_design.md の更新** - 今回の実装で構造に変更があった場合、`miko//high_level_design.md` を更新する From 6c227b492034b36d1a18f057a14179ae267c5913 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 08:24:57 +0000 Subject: [PATCH 2/8] =?UTF-8?q?=E6=A8=AA=E6=96=AD=E6=A6=82=E5=BF=B5?= =?UTF-8?q?=E3=81=AE=E5=AE=A3=E8=A8=80/=E9=81=A9=E5=90=88=E3=82=92?= =?UTF-8?q?=E8=A6=8B=E5=87=BA=E3=81=97=E3=81=A7=E8=87=AA=E5=B7=B1=E6=96=87?= =?UTF-8?q?=E6=9B=B8=E5=8C=96=E3=81=97=E3=80=81example=20=E3=82=92?= =?UTF-8?q?=E5=AE=9F=E4=BE=8B=E3=81=AB=E5=B7=AE=E3=81=97=E6=9B=BF=E3=81=88?= =?UTF-8?q?=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 「宣言」「適合」の見出しを「宣言（このケイパビリティがオーナーの横断概念）」 「適合（他ケイパビリティの横断概念への態度）」に改名し、説明文なしで 向きが読み取れるようにする。ガイドに provided / required の関係として 分担の説明を追加 - example から機構の説明文（ガイドの内容）を削除。補足はサンプル用 コメントに限定する - example の宣言を「特になし」から実例（支払い不履行ユーザー、定義 ルール PAY-03 を新設）に差し替え、オーナー側・消費側の両方を示す Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- business_rules_driven_development.md | 4 ++-- ofuda/examples/business_rules.md | 28 ++++++++++++---------------- ofuda/guides/business_rules_guide.md | 21 ++++++++++++++------- 3 files changed, 28 insertions(+), 25 deletions(-) diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index 9720e01..37fbad3 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -265,8 +265,8 @@ proposal に代替案を追記（AI：重要な検討経緯があれば） ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 ## 4. 横断概念 -### 宣言 -### 適合 +### 宣言（このケイパビリティがオーナーの横断概念） +### 適合（他ケイパビリティの横断概念への態度） ``` - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `` で最終採番を記録する diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index 34c3b12..bce0cc4 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -122,15 +122,20 @@ stateDiagram-v2 - **PAY-02** [制約] 決済済み注文のキャンセル時は、対応する金額を返金しなければならない。 +- **PAY-03** [導出] 直近90日間で未決済による自動キャンセル（PAY-01）が3回発生したユーザーは「支払い不履行ユーザー」と定義する。 + + +
実装マッピング - PAY-01 → `Ec::Jobs::ExpireUnpaidOrdersJob` / 日次バッチ - PAY-02 → `Ec::Services::CancelOrderService` / 返金ジョブ投入 +- PAY-03 → `Ec::Orders::PaymentDefaultQuery` / 直近90日の自動キャンセル集計
- + --- @@ -180,23 +185,14 @@ stateDiagram-v2 ## 4. 横断概念 - +### 宣言（このケイパビリティがオーナーの横断概念） -### 宣言 +- **支払い不履行ユーザー** — 未決済の自動キャンセルを繰り返したユーザー。各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。定義: PAY-03 + + -このケイパビリティが所有する横断概念。全ケイパビリティ（将来作成されるものを含む）に適合判定の義務を課す。 - -- 特になし - - - -### 適合 - -他ケイパビリティが宣言する横断概念への態度。宣言されている**すべての**概念について、適用（対応するルール ID）または非適用（理由）を明示する。 +### 適合（他ケイパビリティの横断概念への態度） - **規約違反ユーザー**（ユーザー管理）→ 適用: ORD-05 - **凍結テナント**（テナント管理）→ 非適用（本ケイパビリティの操作はすべて単一テナント内で完結し、凍結テナントのユーザーはログイン自体が拒否されるため） - + diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 55e9a34..561193c 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -343,13 +343,20 @@ high_level_design.md（AI が更新：構造の変化） **横断なのはエンティティではなく状態である。** 「ユーザー」という概念全体が横断なのではない。「規約違反」という特定の状態だけが横断であり、「メール確認済み」「最終ログイン日時」はオーナーに閉じる。 -### 責務の分担 +### 宣言と適合 — 2 つのサブセクションの分担 + +横断概念セクションは「宣言」と「適合」の 2 サブセクションを持つ。向きが逆である: + +- **宣言（このケイパビリティがオーナーの横断概念）** — 外向き。自分が定義する状態について、全ケイパビリティに適合判定の義務を**課す**側 +- **適合（他ケイパビリティの横断概念への態度）** — 内向き。他ケイパビリティが宣言した概念に対し、課された義務に**答える**側（適用 / 非適用） + +インターフェースの provided / required の関係にあたる。1 つのケイパビリティは両方を持ちうる（自分の概念を宣言しつつ、他者の概念に適合する）。 | 何を | どこに書くか | |---|---| | 概念の定義（誰がその状態になるか・解除条件） | オーナーの BR の通常ルール（[導出] / [制約]） | -| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「横断概念 > 宣言」 | -| 各ケイパビリティでの具体的な効果 | 各ケイパビリティの BR の通常ルール + 「横断概念 > 適合」 | +| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「宣言」 | +| 各ケイパビリティでの具体的な効果 | 各ケイパビリティの BR の通常ルール + 「適合」 | 効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。 @@ -362,7 +369,7 @@ grep -n 'cross-concept' miko/*/business_rules.md ``` ```markdown -### 宣言 +### 宣言（このケイパビリティがオーナーの横断概念） - **規約違反ユーザー** — 規約違反が確定したが、ビジネス上 BAN はできないユーザー。各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。定義: USER-08〜USER-09 ``` @@ -377,7 +384,7 @@ grep -n 'cross-concept' miko/*/business_rules.md 他ケイパビリティが宣言する**すべての**横断概念について、態度を 1 行で明示する。**無記載の概念があってはならない**（無記載は「検討漏れ」として harae が機械的に指摘する）。自ケイパビリティが宣言した概念は書かない。 ```markdown -### 適合 +### 適合（他ケイパビリティの横断概念への態度） - **規約違反ユーザー**（ユーザー管理）→ 適用: RESTRICT-01 - **凍結テナント**（テナント管理）→ 非適用（このケイパビリティの操作はテナント文脈を持たないため） @@ -413,8 +420,8 @@ grep -n 'cross-concept' miko/*/business_rules.md ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 ## 4. 横断概念 -### 宣言 -### 適合 +### 宣言（このケイパビリティがオーナーの横断概念） +### 適合（他ケイパビリティの横断概念への態度） ``` **既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。**唯一の例外は横断概念セクション**で、business_rules.md を更新するスキルが更新のついでに導入する（前述「既存 BR への導入（遅延マイグレーション）」参照）。 From fecdbe3a5a08169ef4824679cc60af84d49fd033 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 08:38:44 +0000 Subject: [PATCH 3/8] =?UTF-8?q?=E9=81=A9=E5=90=88=E3=81=AE=E4=BD=8D?= =?UTF-8?q?=E7=BD=AE=E3=81=A5=E3=81=91=E3=82=92=E6=98=8E=E7=A2=BA=E5=8C=96?= =?UTF-8?q?:=20=E4=BE=9D=E5=AD=98=E6=83=85=E5=A0=B1=E3=81=AE=E7=BD=AE?= =?UTF-8?q?=E3=81=8D=E5=A0=B4=E3=82=92=E9=81=A9=E5=90=88=E3=81=AB=E4=B8=80?= =?UTF-8?q?=E6=9C=AC=E5=8C=96=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 横断概念への依存は境界セクションに書かない（適合が唯一の置き場）ことを 境界と適合の両方の指針に明記し、二重管理を封じる - 適合エントリは判定（verdict）の機械可読レイヤーであり、ルール本文の 言い直しではないことを明記（ルール本文は自由な日本語のため機械照合の 分母にできない。実装マッピングと同じ位置づけで、参照切れは harae が照合） - オーナーは消費者一覧を持たず、逆引きは適合セクションの grep で導出する ことを明記 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- ofuda/guides/business_rules_guide.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 561193c..e35a4d8 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -395,6 +395,11 @@ grep -n 'cross-concept' miko/*/business_rules.md - 判定をその場で確定できない場合は `→ 要判定 ` と書き、完了報告で明示する - 宣言されている横断概念がシステムに 1 つもない場合は `- 特になし（宣言されている横断概念はない）` と書く +適合エントリはルール本文の言い直しではなく、**判定（verdict）の機械可読レイヤー**である。ルール本文は自由な日本語で「概念に触れるルールが存在するか」を機械判定できないため、「全宣言 × 適合エントリ」の 1:1 照合を成立させるためだけにこの行を持つ（実装マッピングと同じ位置づけ。参照切れは harae が機械照合する）。同じ理由から、依存情報の置き場はここに一本化する: + +- **横断概念への依存は境界セクションに書かない**（適合が唯一の置き場） +- **オーナーは消費者の一覧を持たない**。「この概念に誰が適合しているか」は、適合セクションの概念名を grep して都度導出する + ### 既存 BR への導入（遅延マイグレーション） 横断概念セクションを持たない既存の business_rules.md は、**business_rules.md を更新するスキルが、更新のついでにセクションを導入する**（「既存 BR の構造に手を入れない」原則の唯一の例外）。手順: @@ -453,7 +458,7 @@ grep -n 'cross-concept' miko/*/business_rules.md **ビジネスルール・カタログ**: `### 2.1 ドメインビジネスルール`（紙の運用でも成り立つもの）と `### 2.2 システムビジネスルール`（システム前提のもの）の 2 セクションに分けて配置する。同一カテゴリ（ORD、PAY 等）はどちらか一方に置く。ドメインとシステムが混じるカテゴリはカテゴリの分割を検討する。詳細は前述の「ドメインビジネスルール / システムビジネスルールの区別」と、後述の「ビジネスルール・カタログの書き方」を参照。 -**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。 +**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。逆に、**横断概念への依存は境界には書かない**（「適合」が唯一の置き場。二重管理を避ける）。 **横断概念**: 「宣言」と「適合」の 2 サブセクション。詳細は前述の「横断概念とは何か」を参照。宣言する概念がなくても、適合すべき概念がなくても、`特になし` を明示する（セクションは省略しない）。 From 7aca5c67069f287af83c1cc9fa23e672b4c5bf09 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 09:30:49 +0000 Subject: [PATCH 4/8] =?UTF-8?q?=E6=A8=AA=E6=96=AD=E6=A6=82=E5=BF=B5?= =?UTF-8?q?=E3=82=92=E5=AE=A3=E8=A8=80=20+=20xc:=20=E3=82=BF=E3=82=B0=20+?= =?UTF-8?q?=20=E3=83=97=E3=83=AD=E3=82=BB=E3=82=B9=E3=81=AE=E9=96=80?= =?UTF-8?q?=E3=81=AB=E3=82=88=E3=82=8B=E6=A7=8B=E6=88=90=E7=9A=84=E4=BF=9D?= =?UTF-8?q?=E8=A8=BC=E3=81=AB=E5=86=8D=E8=A8=AD=E8=A8=88=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 議論の結果、verdict 台帳（適合セクション）と事後監査による網羅チェックを 廃止し、最小の形に再設計する。 - 概念 ID を xc:{ケイパビリティディレクトリ名}/{短い英語スラッグ} 形式に する。ID がオーナー BR へのポインタを兼ね、採番は不要 - 宣言はオーナーの BR の「横断概念」セクションに 1 行（所有する場合のみ セクションを作る）。効果はルールの [xc:…] タグで表す。非適用は記録しない - 網羅性は記録ではなくプロセスの門で構成的に保証する: 門 1 = propose の 影響調査（必須）、門 2 = new-cap の横断概念判定ステップ。全ペアは 遅い方の誕生イベントで必ず一度検討される - harae の必須照合を廃止する。harae は完成したはずの体系を攻撃する事後の 監査であり、必ず通るべき門を置く場所ではない（不完全性軸の攻撃観点と してのみ残す） - 適合セクション廃止に伴い遅延マイグレーションも廃止し、BR 更新スキルの 書き込み時 lint（orphan 参照・宣言重複・書式）に置き換える - 却下した代替案（適合セクション・非適用の記録・グローバル連番 ID 等）を business_rules_driven_development.md に記録する Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- CHANGELOG.md | 9 +- business_rules_driven_development.md | 29 +++--- ofuda/VERSION | 2 +- ofuda/examples/business_rules.md | 18 ++-- ofuda/guides/business_rules_guide.md | 89 +++++++++---------- ofuda/guides/harae_guide.md | 18 +--- skills/miko.catchup/SKILL.md | 2 +- skills/miko.harae/SKILL.md | 7 +- skills/miko.miko/SKILL.md | 4 +- skills/miko.new-cap/SKILL.md | 21 +++-- skills/miko.new-harae/SKILL.md | 14 ++- skills/miko.propose/SKILL.md | 4 +- .../guides/cross_capability_impact_guide.md | 10 +-- skills/miko.quick-catchup/SKILL.md | 2 +- skills/miko.quick-impl/SKILL.md | 4 +- skills/miko.speckit.implement/SKILL.md | 2 +- 16 files changed, 100 insertions(+), 135 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index cc6e3d6..ac80fab 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,14 +4,13 @@ ### New -- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。横断しているのはルール（文）ではなく概念（名詞）という整理に基づき、オーナーの BR の「横断概念 > 宣言」に 1 概念 = 1 行で宣言し（行末に `` マーカー）、全ケイパビリティは「横断概念 > 適合」で全宣言への態度を明示する（適用: ルール ID / 非適用: 理由。無記載 = 検討漏れとして機械検出可能）。一覧は `grep 'cross-concept' miko/*/business_rules.md` で都度導出し、中央レジストリは持たない。判定テスト（他者性・全称性・必達性）、宣言・適合の書式、責務の分担を `business_rules_guide.md` の「横断概念とは何か」に定義。BR 構造にセクション 4 を追加し、`.miko/examples/business_rules.md` に実例（ORD-05 と適合セクション）を追加。検討経緯は `business_rules_driven_development.md` の「解決済みの論点」を参照 -- **harae に横断概念の網羅チェック（機械照合）を追加** — `harae_guide.md` に手順を定義し、`/miko.new-harae`・`/miko.harae`（再実行・proposal 検証の両モード）がメインセッションで実施する。未移行セクション・適合の検討漏れ・要判定の放置・参照切れを推論ではなく機械照合で検出する -- **既存 BR への遅延マイグレーション** — 横断概念セクションを持たない既存 business_rules.md は、BR を更新するスキル（`/miko.quick-impl`・`/miko.speckit.implement`・`/miko.catchup`・`/miko.quick-catchup`）が更新のついでにセクションを導入する（「既存 BR の構造に手を入れない」原則の唯一の例外）。該当がなくても `特になし` を明示し、「未検討」と「検討済みでゼロ」を区別する +- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。横断しているのはルール（文）ではなく概念（名詞）という整理に基づき、オーナーの BR の「横断概念」セクションに 1 概念 = 1 行で宣言し（業務用語 + `xc:{cap}/{slug}` 形式の ID + 宣言文 + 定義ルール ID + 行末 `` マーカー）、効果を持つケイパビリティは自分のルールに `[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 に記録）。調査ガイドに横断概念の観点（宣言・定義に触れる変更の影響先特定、昇格候補の報告）を追加 -- **`/miko.new-cap` に全ケイパビリティ BR の関連調査（サブエージェント・必須）と横断概念の適合判定ステップを追加** — 従来は「外部との接点」に挙がった隣接 BR だけを読んでいたが、新規ケイパビリティ作成時が横断ルールの取りこぼしが最も起きやすいため、全 BR の走査と、宣言済み横断概念への適合判定（grep → 対話 → 適合セクションに記録）を必須化 +- **`/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) diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index 37fbad3..fda9d7c 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -264,14 +264,12 @@ proposal に代替案を追記（AI：重要な検討経緯があれば） ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 -## 4. 横断概念 -### 宣言（このケイパビリティがオーナーの横断概念） -### 適合（他ケイパビリティの横断概念への態度） +## 4. 横断概念（宣言する概念を所有する場合のみ） ``` - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `` で最終採番を記録する - **2.1 ドメインビジネスルール / 2.2 システムビジネスルール**: ルールを「紙運用」テストで振り分けて配置する。カテゴリ（ORD、PAY 等）はどちらか一方に置く -- **4. 横断概念**: 全ケイパビリティに適合判定を課す概念の「宣言」（オーナー側）と、他ケイパビリティの宣言への「適合」（全ケイパビリティ）。該当がなくても `特になし` を明示する。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 +- **4. 横断概念**: このケイパビリティがオーナーとして宣言する横断概念（1 概念 = 1 行、`xc:` ID + 行末マーカー）。宣言する概念を所有する場合のみセクションを作る。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 ### 操作の定義（Operations） @@ -391,23 +389,30 @@ miko//proposals/ - **横断しているのはルール（文）ではなく概念（名詞）。** ルールは書き方次第で分割・統合される不安定な単位のため、義務は概念に付ける。横断なのはエンティティ（ユーザー）ではなく状態（規約違反）である - **判定テスト（3 問すべて Yes で横断概念）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか -- **宣言（オーナー側）:** 概念のオーナーが BR の「横断概念 > 宣言」に 1 概念 = 1 行で宣言し、行末に `` マーカーを付ける。定義（誰がその状態になるか）は通常ルールとして持つ。宣言の追加・変更・除去は proposal 必須（横断プロポーザル） -- **適合（全ケイパビリティ）:** 各 BR の「横断概念 > 適合」に、他ケイパビリティの全宣言への態度を明示する。適用ならルール ID（効果はそのケイパビリティのドメイン判断なので、消費側の通常ルールとして書く）、非適用なら理由。**非適用の明示により「無記載 = 検討漏れ」が機械検出可能になる** +- **概念 ID:** `xc:{ケイパビリティディレクトリ名}/{短い英語スラッグ}`（例: `xc:user_management/tos-violator`）。ID がオーナー BR へのポインタを兼ねる。採番なし +- **宣言（オーナーのみ）:** BR の「横断概念」セクションに 1 概念 = 1 行（業務用語 + ID + 宣言文 + 定義ルール ID + 行末 `` マーカー）。定義は通常ルールとして持つ。宣言の追加・変更・除去は proposal 必須（横断プロポーザル）。セクションは宣言する概念を所有する場合のみ作る +- **適用（効果を持つケイパビリティ）:** 効果を担うルールに `[xc:…]` タグを付ける。「概念に誰が応えているか」は ID の grep で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される） +- **非適用は書かない。** 「検討したが効果を持たない」の記録は持たない（propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すのみ） - **一覧は grep で導出:** `grep -n 'cross-concept' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する -**強制は 2 層:** +**網羅性は記録ではなくプロセスの門で保証する（構成的保証）:** ケイパビリティ × 概念のすべての組は、どちらか遅い方の誕生イベントで必ず一度検討される。 -1. **決定的チェック（grep・保証担当）** — new-cap が宣言を grep して全概念の適合判定を必須ステップで確認し、harae が「全宣言 × 適合」の網羅を機械照合する。宣言済みの義務の取りこぼしをゼロにする -2. **サブエージェント全走査（発見担当）** — new-cap / propose で全ケイパビリティ BR の調査を必須化（従来 propose では任意だった）。未宣言の横断関係や「横断概念に昇格すべき候補」を発見し、宣言（層 1）の入力源にする。走査は発見はできるが漏れの検出はできない（分母がない）ため、層 1 の代替にはならない +1. **門 1 — propose の他ケイパビリティ影響調査（必須化）:** 概念の宣言・変更は横断プロポーザルになり、影響調査が全ケイパビリティに判定を下す。調査は昇格候補（未宣言の横断関係）の発見も担う +2. **門 2 — new-cap の横断概念判定ステップ（新設）:** 新規ケイパビリティ作成時に宣言を grep し、各概念について対話で判定する。適用なら `[xc:…]` タグ付きルールを作る -**既存 BR への導入は遅延マイグレーション:** business_rules.md を更新するスキル（quick-impl / speckit.implement / catchup / quick-catchup）が、更新のついでに横断概念セクションを導入する。該当がなくても `特になし` を明示し、「未検討」と「検討済みでゼロ」を区別する。 +加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）を実行する。harae に横断概念の必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。 + +**既存 BR への遡及なし:** 宣言行とタグは概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。マイグレーション不要。 **検討・却下した代替案:** - **glossary での管理** — glossary は参考情報でありルールとして管理・強制されない。ただし「横断するのは用語（概念）」という着眼だけは採用した -- **ルール単位の `[横断]` マーク** — ルールは言い回しで分割・統合されるため、マークの付け先が不安定（「点を調べる」ことになる） +- **ルール単位の `[横断]` マーク（横断性の宣言をルールに付ける）** — ルールは言い回しで分割・統合されるため、マークの付け先が不安定。なお採用した `[xc:…]` タグは別物で、概念への「参照」なので分割・統合で壊れない - **中央レジストリファイル / system HLD への機構の記載** — レジストリは本体と索引の二重管理でズレる。system HLD はプロジェクトが編集できるデータであり、miko の機構を置く場所ではない（消されても誰も復元しない） -- **サブエージェント全走査のみ（宣言なし）** — 走査は確率的な想起であり、漏れたことを検出する分母がない。判断が記録されず毎回再検討になる。層 2 として併用に留める +- **サブエージェント全走査のみ（宣言なし）** — 走査は確率的な想起であり、漏れたことを検出する分母がない。門の入力源（昇格候補の発見）として併用する +- **適合セクション（各 BR に全宣言への適用/非適用を明示する verdict 台帳）** — 適用行はルール側タグと二重管理になり、非適用行は概念 × ケイパビリティの積で増えるノイズ。網羅性を「事後の照合」で保証する発想の産物で、門の構成的保証に置き換えて廃止 +- **非適用の記録（BR / harae.md / proposal のいずれかに残す）** — 「無記載と検討済みの区別」は事後照合が前提のときだけ必要。門で保証するなら証明の役目を失う。理由の陳腐化（後から該当操作が増える等）は記録では検出できず、残す理由にならない +- **グローバル連番の概念 ID（XC-01 等）** — 並行ブランチで採番が衝突し、番号が情報を担わない。概念は少数で名前が一意なので、修飾付き名前で足りる ### 複数ケイパビリティにまたがる変更 diff --git a/ofuda/VERSION b/ofuda/VERSION index 4ebdf61..df977da 100644 --- a/ofuda/VERSION +++ b/ofuda/VERSION @@ -1,2 +1,2 @@ 1.5.0 -202609050749 +202609050930 diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index bce0cc4..1d8ca2c 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -93,10 +93,10 @@ stateDiagram-v2 - **ORD-04** [制約] 猶予期間経過後のキャンセルは管理者操作でのみ可能とする。 -- **ORD-05** [制約] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 +- **ORD-05** [制約][xc:user_management/tos-violator] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 - +
実装マッピング @@ -185,14 +185,6 @@ stateDiagram-v2 ## 4. 横断概念 -### 宣言（このケイパビリティがオーナーの横断概念） - -- **支払い不履行ユーザー** — 未決済の自動キャンセルを繰り返したユーザー。各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。定義: PAY-03 - - - -### 適合（他ケイパビリティの横断概念への態度） - -- **規約違反ユーザー**（ユーザー管理）→ 適用: ORD-05 -- **凍結テナント**（テナント管理）→ 非適用（本ケイパビリティの操作はすべて単一テナント内で完結し、凍結テナントのユーザーはログイン自体が拒否されるため） - +- **支払い不履行ユーザー** (`xc:order_management/pay-defaulter`) — 未決済の自動キャンセルを繰り返したユーザー。各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。定義: PAY-03 + + diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index e35a4d8..19a6062 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -329,7 +329,7 @@ high_level_design.md（AI が更新：構造の変化） **横断概念とは、他ケイパビリティが所有する操作の可否や意味を変える状態・属性のことである。** 「規約違反ユーザー」「凍結テナント」のように、1 つのケイパビリティが定義するが、効果はシステム全体に及ぶ。 -横断概念は、**まだ存在しないケイパビリティも含めた全ケイパビリティ**に「この概念にどう向き合うか」の表明（適合判定）を義務づける。義務をルール（文）ではなく概念（名詞）に付けるのは、ルールは書き方次第で分割・統合される不安定な単位である一方、概念は言い回しで増減しないためである。 +横断概念は、**まだ存在しないケイパビリティも含めた全ケイパビリティ**に「この概念にどう向き合うか」の検討を義務づける。義務をルール（文）ではなく概念（名詞）に付けるのは、ルールは書き方次第で分割・統合される不安定な単位である一方、概念は言い回しで増減しないためである。 ### 判定テスト: 横断概念か @@ -343,71 +343,68 @@ high_level_design.md（AI が更新：構造の変化） **横断なのはエンティティではなく状態である。** 「ユーザー」という概念全体が横断なのではない。「規約違反」という特定の状態だけが横断であり、「メール確認済み」「最終ログイン日時」はオーナーに閉じる。 -### 宣言と適合 — 2 つのサブセクションの分担 - -横断概念セクションは「宣言」と「適合」の 2 サブセクションを持つ。向きが逆である: - -- **宣言（このケイパビリティがオーナーの横断概念）** — 外向き。自分が定義する状態について、全ケイパビリティに適合判定の義務を**課す**側 -- **適合（他ケイパビリティの横断概念への態度）** — 内向き。他ケイパビリティが宣言した概念に対し、課された義務に**答える**側（適用 / 非適用） - -インターフェースの provided / required の関係にあたる。1 つのケイパビリティは両方を持ちうる（自分の概念を宣言しつつ、他者の概念に適合する）。 +### 責務の分担 | 何を | どこに書くか | |---|---| | 概念の定義（誰がその状態になるか・解除条件） | オーナーの BR の通常ルール（[導出] / [制約]） | -| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「宣言」 | -| 各ケイパビリティでの具体的な効果 | 各ケイパビリティの BR の通常ルール + 「適合」 | +| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「横断概念」セクション（1 行） | +| 各ケイパビリティでの具体的な効果 | 効果を持つケイパビリティの通常ルール（`[xc:…]` タグ付き） | +| 非適用（効果を持たない判断） | **書かない**（後述） | 効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。 -### 宣言の書き方 +### 概念 ID -宣言は **1 概念 = 1 行**とし、行末に機械マーカー `` を付ける。このマーカーが grep の対象であり、**システム全体の横断概念一覧は次のコマンドで都度導出する**（中央のレジストリファイルは持たない。本体と索引の二重管理を避けるため）: +横断概念には `xc:{ケイパビリティディレクトリ名}/{スラッグ}` 形式の ID を振る。 -```bash -grep -n 'cross-concept' miko/*/business_rules.md -``` +- ケイパビリティ部は `miko/` 配下のディレクトリ名をそのまま使う。ID がオーナーの BR ファイルへのポインタを兼ねる +- スラッグは短い英語（1〜2 語、ケバブケース、略語可）。例: `xc:user_management/tos-violator`、`xc:order_management/pay-defaulter` +- 日本語の業務用語（「規約違反ユーザー」）は glossary とルール本文の語彙のまま使う。ID は参照用の機械キーであり、対訳は宣言行が持つ + +### 宣言の書き方（オーナーの BR） + +宣言は **1 概念 = 1 行**とし、「横断概念」セクションに置き、行末に機械マーカー `` を付ける。 ```markdown -### 宣言（このケイパビリティがオーナーの横断概念） +## 4. 横断概念 -- **規約違反ユーザー** — 規約違反が確定したが、ビジネス上 BAN はできないユーザー。各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。定義: USER-08〜USER-09 +- **規約違反ユーザー** (`xc:user_management/tos-violator`) — 規約違反が確定したが、ビジネス上 BAN はできないユーザー。各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。定義: USER-08〜USER-09 ``` -- 宣言する概念がなければ `- 特になし` と明示する（セクション自体は省略しない） +- **セクションは宣言する概念があるときだけ作る**。宣言しないケイパビリティ（大多数）の BR には何も足さない - 宣言文には、概念の 1 行説明・各ケイパビリティが何を表明すべきかの軸・定義ルールの ID を書く。個別ケイパビリティの操作名は書かない -- マーカー `` は宣言行以外に書かない（散文・ルール本文・適合エントリに書くと grep の一覧が壊れる） -- **宣言の追加・変更・除去は proposal 必須。** 全ケイパビリティに適合判定の義務を課す（または解除する）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う +- マーカー `` は宣言行以外に書かない。**システム全体の横断概念一覧はこの grep で都度導出する**（中央のレジストリファイルは持たない）: + +```bash +grep -n 'cross-concept' miko/*/business_rules.md +``` -### 適合の書き方 +- **宣言の追加・変更・除去は proposal 必須。** 全ケイパビリティに検討の義務を課す（または解除する）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う -他ケイパビリティが宣言する**すべての**横断概念について、態度を 1 行で明示する。**無記載の概念があってはならない**（無記載は「検討漏れ」として harae が機械的に指摘する）。自ケイパビリティが宣言した概念は書かない。 +### 適用の書き方（効果を持つケイパビリティのルール） -```markdown -### 適合（他ケイパビリティの横断概念への態度） +横断概念の効果を担うルールは、タグ位置に概念 ID を付ける。 -- **規約違反ユーザー**（ユーザー管理）→ 適用: RESTRICT-01 -- **凍結テナント**（テナント管理）→ 非適用（このケイパビリティの操作はテナント文脈を持たないため） +```markdown +- **ORD-05** [制約][xc:user_management/tos-violator] 規約違反ユーザーは注文コメントを投稿できない。 ``` -- **適用**: 効果を表す自ケイパビリティのルール ID を列挙する -- **非適用**: 理由を必ず書く。「検討したうえで対象外と判断した」ことの記録であり、無記載（検討漏れ）と区別するための明示である -- 判定をその場で確定できない場合は `→ 要判定 ` と書き、完了報告で明示する -- 宣言されている横断概念がシステムに 1 つもない場合は `- 特になし（宣言されている横断概念はない）` と書く +- ルール本文は通常どおりビジネス語彙（日本語の用語）で書く。タグが機械可読なリンクを担う +- 「この概念にどのケイパビリティのどのルールが応えているか」は `grep -n 'xc:user_management/tos-violator' miko/*/business_rules.md` で都度導出する（宣言行 + 全適用ルールが 1 コマンドで列挙される）。オーナーは消費者の一覧を持たない +- **横断概念への依存は境界セクションに書かない**（タグが唯一の置き場。二重管理を避ける） -適合エントリはルール本文の言い直しではなく、**判定（verdict）の機械可読レイヤー**である。ルール本文は自由な日本語で「概念に触れるルールが存在するか」を機械判定できないため、「全宣言 × 適合エントリ」の 1:1 照合を成立させるためだけにこの行を持つ（実装マッピングと同じ位置づけ。参照切れは harae が機械照合する）。同じ理由から、依存情報の置き場はここに一本化する: +### 非適用は書かない -- **横断概念への依存は境界セクションに書かない**（適合が唯一の置き場） -- **オーナーは消費者の一覧を持たない**。「この概念に誰が適合しているか」は、適合セクションの概念名を grep して都度導出する +「検討したが効果を持たない」判断は、どこにも記録しない。網羅性は記録ではなく**プロセスの門**で保証する。ケイパビリティ × 概念のすべての組は、概念の宣言（propose の影響調査が全ケイパビリティに判定を下す）か、ケイパビリティの新規作成（new-cap の横断概念判定ステップ）の、どちらか遅い方のイベントで必ず一度検討される。propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すため、痕跡はそこにある。 -### 既存 BR への導入（遅延マイグレーション） +### 書き込み時の検査（lint） -横断概念セクションを持たない既存の business_rules.md は、**business_rules.md を更新するスキルが、更新のついでにセクションを導入する**（「既存 BR の構造に手を入れない」原則の唯一の例外）。手順: +business_rules.md を更新するスキルは、更新の直後に以下を機械的に検査し、問題があれば修正する（できなければユーザーに報告する）: -1. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する -2. 既存の構造を崩さず、末尾（境界セクションの後）に「横断概念」セクションを追加する。既存 BR のセクション番号体系が異なる場合は番号を無理に合わせなくてよい（番号なしの `## 横断概念` でよい） -3. 「宣言」は `- 特になし` から始める。このケイパビリティが横断概念を所有していそうな場合も、この場では宣言せず「昇格候補」としてユーザーに報告する（宣言は proposal を通す） -4. 「適合」は宣言済みの各概念について判定を記録する。対話フェーズのあるスキルはユーザーに確認し、確認できないものは `→ 要判定 ` と書いて完了報告で明示する +1. **orphan 参照**: `xc:` 参照のうち、対応する宣言行（`` 付き）が存在しないもの +2. **宣言の重複**: 同じ ID の宣言行が複数存在しないか +3. **書式**: 宣言行が「1 行・業務用語・ID・宣言文・定義ルール ID・行末マーカー」を満たすか。タグが `[制約]/[導出]` の直後に置かれているか --- @@ -424,12 +421,10 @@ grep -n 'cross-concept' miko/*/business_rules.md ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 -## 4. 横断概念 -### 宣言（このケイパビリティがオーナーの横断概念） -### 適合（他ケイパビリティの横断概念への態度） +## 4. 横断概念（宣言する概念を所有する場合のみ） ``` -**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。**唯一の例外は横断概念セクション**で、business_rules.md を更新するスキルが更新のついでに導入する（前述「既存 BR への導入（遅延マイグレーション）」参照）。 +**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。横断概念の仕組みも既存 BR に遡及しない — 宣言行や `[xc:…]` タグは、概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。 ### 各セクションの指針 @@ -458,9 +453,9 @@ grep -n 'cross-concept' miko/*/business_rules.md **ビジネスルール・カタログ**: `### 2.1 ドメインビジネスルール`（紙の運用でも成り立つもの）と `### 2.2 システムビジネスルール`（システム前提のもの）の 2 セクションに分けて配置する。同一カテゴリ（ORD、PAY 等）はどちらか一方に置く。ドメインとシステムが混じるカテゴリはカテゴリの分割を検討する。詳細は前述の「ドメインビジネスルール / システムビジネスルールの区別」と、後述の「ビジネスルール・カタログの書き方」を参照。 -**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。逆に、**横断概念への依存は境界には書かない**（「適合」が唯一の置き場。二重管理を避ける）。 +**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。逆に、**横断概念への依存は境界には書かない**（ルールの `[xc:…]` タグが唯一の置き場。二重管理を避ける）。 -**横断概念**: 「宣言」と「適合」の 2 サブセクション。詳細は前述の「横断概念とは何か」を参照。宣言する概念がなくても、適合すべき概念がなくても、`特になし` を明示する（セクションは省略しない）。 +**横断概念**: このケイパビリティがオーナーとして宣言する横断概念の一覧（1 概念 = 1 行）。宣言する概念を所有する場合のみセクションを作る。詳細は前述の「横断概念とは何か」を参照。 > **注意:** アーキテクチャ上の決定事項（ADR）は business_rules.md には書かない。技術選択の「決定・意図・トレードオフ」は high_level_design.md の「設計上の特徴」セクションに記載する。 @@ -541,7 +536,7 @@ grep -n 'cross-concept' miko/*/business_rules.md 6. 各ルール候補に「紙運用」テストを適用し、ドメインビジネスルール（2.1）とシステムビジネスルール（2.2）に振り分ける。1 ルール内に両方が混在している場合は分解する 7. 実装マッピングを `
` 内に記載する 8. コードに暗黙的に埋め込まれているが明文化されていないルール・ポリシーがあれば「暗黙のルール（要確認）」として末尾に列挙する -9. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、「横断概念 > 適合」に各概念への判定を記載する（前述「適合の書き方」参照）。コードから適合が読み取れる場合（例: 制限の実装が見つかる）は対応ルールと紐づける +9. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、コードから概念の効果（制限等）を実装しているルールが見つかった場合は、そのルールに `[xc:…]` タグを付ける（前述「適用の書き方」参照） ### モード B: 提案から生成する場合 * 提案には、ビジネスルールではない詳細な仕様が書かれることがあるが、それはビジネスルールには記載しない。 diff --git a/ofuda/guides/harae_guide.md b/ofuda/guides/harae_guide.md index 2e262a6..a5f3cc1 100644 --- a/ofuda/guides/harae_guide.md +++ b/ofuda/guides/harae_guide.md @@ -45,22 +45,6 @@ --- -## 機械照合: 横断概念の網羅チェック（メインセッションが実施） - -サブエージェント A/B/C の担当外。呼び出し元スキルのメインセッションが、6軸の探索とは別に **推論ではなく機械照合として** 実施する。 - -1. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する（対象ケイパビリティ自身の宣言は分母から除く） -2. 対象 BR の「横断概念 > 適合」と突き合わせ、以下を指摘する: - - 横断概念セクション自体がない（未移行の旧フォーマット） - - 宣言済み概念に対応する適合エントリがない（検討漏れ） - - `要判定` のまま放置されている適合エントリ - - 適用エントリが参照するルール ID が対象 BR に存在しない -3. 逆方向も確認する: 対象 BR が宣言する横断概念について、宣言行の書式（1 行・行末マーカー）が守られているか、定義ルールが実在するか - -指摘は検証軸「不完全性」に分類し、通常の指摘と同じ構造で記述する（深刻度は検討漏れ・未移行なら「高」）。照合が全件一致なら指摘なし。 - ---- - ## サブエージェント A: 論理的整合性 担当軸: **内部矛盾** + **不完全性** @@ -125,6 +109,8 @@ business_rules.md の「操作の定義」から全操作を、「状態遷移 「関連ケイパビリティとの境界」を確認し、境界で「借りているもの」「渡しているもの」それぞれについて、失敗時や遅延時のルールが定義されているか確認する。 +あわせて横断概念も見る: `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、対象ケイパビリティの操作に関係しそうな概念なのに `[xc:…]` タグ付きルールが 1 本もない場合は、対応漏れの可能性として指摘する（関係するかどうかは操作の内容から推論する。網羅の義務チェックではなく攻撃の観点として扱う）。 + > 例: 在庫管理との境界で「在庫引き当てにはタイムアウトがある」「バッチによる自動キャンセルまで引き当てが残り続ける」と記述されている。在庫引き当てがタイムアウトした場合（在庫管理側でタイムアウト解放、注文管理側ではまだ confirmed）、注文側のステータスはどうなるか？ この状態不整合を扱うルールがない。 > 例: 配送管理との境界で「通知遅延により実際の配達完了とステータス更新にタイムラグが生じる」と記述されている。このタイムラグ中にユーザーがキャンセルを試みた場合（shipped 状態だが実際には配達済み）、ORD-02 により返品プロセスへ誘導されるが、実際にはまだ「出荷済み」として扱われている。これは意図通りか？ diff --git a/skills/miko.catchup/SKILL.md b/skills/miko.catchup/SKILL.md index d3a027b..21d377e 100644 --- a/skills/miko.catchup/SKILL.md +++ b/skills/miko.catchup/SKILL.md @@ -161,7 +161,7 @@ $ARGUMENTS - 承認された削除 - 実装マッピング - 操作の定義（コードから新しい操作が見つかった場合） -- **横断概念セクションの遅延マイグレーション** — business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定はコード精読の結果から案を立て、確認②で主さまに確認する。確認できないものは `→ 要判定 ` として記録し完了報告で明示する +- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものは主さまに報告する **glossary.md の更新:** - proposal で新しい用語が登場した場合は `miko/glossary.md` に追加する（ファイルがなければ作成） diff --git a/skills/miko.harae/SKILL.md b/skills/miko.harae/SKILL.md index e2c21e5..d5b815c 100644 --- a/skills/miko.harae/SKILL.md +++ b/skills/miko.harae/SKILL.md @@ -89,9 +89,7 @@ proposal が指定されていない場合。メインセッションで棚卸 ### 3. 差分探索 -まず `.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」を実施する（未移行・検討漏れ・要判定の放置・参照切れを機械的に検出する）。 - -続けて、メインセッションが6軸で新たな指摘を探索する。既存の指摘（全ステータス）と重複するものは除外する。 +メインセッションが6軸で新たな指摘を探索する。既存の指摘（全ステータス）と重複するものは除外する。 ### 4. harae.md 更新 @@ -148,9 +146,6 @@ proposal に「他ケイパビリティへの影響」セクションがある メインセッションとサブエージェントで役割を分担する: -**メインセッション — 横断概念の網羅チェック（機械照合）:** -proposal のルール変更を仮想適用した BR に対して、`.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」を実施する。proposal が横断概念の宣言を追加・変更・除去する場合は、全ケイパビリティの適合が揃うか（「他ケイパビリティへの影響」セクションでカバーされているか）も照合する。 - **メインセッション — 6軸の差分探索:** proposal のルール変更を仮想適用した BR 体系に対して、6軸で新たな指摘を探索する。既存の harae.md の指摘（全ステータス）と重複するものは除外する。 diff --git a/skills/miko.miko/SKILL.md b/skills/miko.miko/SKILL.md index 38d08a6..1d656db 100644 --- a/skills/miko.miko/SKILL.md +++ b/skills/miko.miko/SKILL.md @@ -171,9 +171,9 @@ miko の実装フローでは **constitution**（`.specify/memory/constitution.m 6. **「複数のケイパビリティに効くルールはどこに書く？」「これって横断概念？」** - `business_rules_guide.md` の「判定テスト: 横断概念か」（他者性・全称性・必達性）を一緒に適用する - - 3 問すべて Yes → オーナーの BR に宣言（`/miko.propose` 経由）、効果は各ケイパビリティのルール + 適合に書く + - 3 問すべて Yes → オーナーの BR に宣言（`/miko.propose` 経由）、効果は各ケイパビリティのルールに `[xc:…]` タグ付きで書く - 相手を列挙できる二者間の依存 → 境界セクションで足りる（横断概念にしない） - - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md` で提示する + - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md`、特定の概念の全体像（宣言 + 適用ルール）は `grep -n 'xc:{cap}/{slug}' miko/*/business_rules.md` で提示する 7. **「constitution に何を書けばいい？」「CLAUDE.md に書くのと何が違う？」** - 実装フローで毎回守ってほしいプロジェクト固有のルール → constitution diff --git a/skills/miko.new-cap/SKILL.md b/skills/miko.new-cap/SKILL.md index f995848..8a7c9d9 100644 --- a/skills/miko.new-cap/SKILL.md +++ b/skills/miko.new-cap/SKILL.md @@ -153,16 +153,14 @@ $ARGUMENTS 発見された問題は、ステップ 9 の確認②に「既存 BR との整合性」セクションを追加して報告する。 -**6c. 横断概念の適合判定（必須）** +**6c. 横断概念の判定（必須）** -`grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する。 +`grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する。ヒットが 1 件もなければこのステップをスキップする。 ヒットした各概念について: -1. 宣言行（概念名・宣言文・定義ルール ID）を読む。判定に必要なら、オーナー BR から定義ルールの本文だけを読む（BR ファイル全体は読まない） -2. ユーザーに適合を確認する（例: 「ユーザー管理が横断概念『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） -3. 判定結果を記録する — 適用（効果を表すルールをルール候補に加える）/ 非適用（理由） - -ヒットが 1 件もない場合も「特になし」を記録する（ステップ 11 で「適合」に明示するため、このステップ自体は省略しない）。 +1. 宣言行（業務用語・`xc:` ID・宣言文・定義ルール ID）を読む。判定に必要なら、オーナー BR から定義ルールの本文だけを読む（BR ファイル全体は読まない） +2. ユーザーに確認する（例: 「ユーザー管理が横断概念『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） +3. 効果を持つと判定された概念について、効果を表すルールをルール候補に加える（生成時に `[xc:…]` タグを付ける）。効果を持たない概念については何も書かない（この対話で検討したこと自体が保証であり、非適用の記録は持たない） ヒアリングやコード調査で、新ケイパビリティ自身が横断概念（`.miko/guides/business_rules_guide.md` の「判定テスト: 横断概念か」を満たす状態）を持ちそうな場合は、この場では宣言せず**昇格候補**として記録し、ステップ 12 の完了報告で `/miko.propose` を案内する（宣言は全ケイパビリティに義務を課すため proposal を通す）。 @@ -234,9 +232,10 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を - 実装マッピング: - 既存コードがある場合: `
` 内に記載 - 未実装の場合: `
` 内に `（未実装）` マーク付きで記載 -- **横断概念セクションを必ず含める**（ガイドの「横断概念とは何か」参照）: - - 「宣言」は `- 特になし`（昇格候補があっても宣言しない。proposal を通す） - - 「適合」はステップ 6c の判定結果を全概念分記載する。宣言済み概念がなければ `- 特になし（宣言されている横断概念はない）` +- **横断概念**（ガイドの「横断概念とは何か」参照）: + - ステップ 6c で効果を持つと判定した概念のルールに `[xc:…]` タグを付ける + - 「横断概念」セクションは作らない（宣言は proposal を通すため、new-cap では昇格候補の案内まで） + - 生成後、ガイドの「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・タグの書式） - 未決事項がある場合、末尾に「未決事項」セクションを追加 ```markdown @@ -273,4 +272,4 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を ### 12. 完了報告 -生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数、横断概念の適合判定数（適用/非適用）をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。ステップ 6c で横断概念の昇格候補を記録した場合は提示し、`/miko.propose` による宣言を案内する。 +生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数、横断概念の判定結果（検討した概念数と、効果を持つと判定した概念 → 対応ルール）をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。ステップ 6c で横断概念の昇格候補を記録した場合は提示し、`/miko.propose` による宣言を案内する。 diff --git a/skills/miko.new-harae/SKILL.md b/skills/miko.new-harae/SKILL.md index 27f46c5..a75ca15 100644 --- a/skills/miko.new-harae/SKILL.md +++ b/skills/miko.new-harae/SKILL.md @@ -59,11 +59,7 @@ $ARGUMENTS - `miko//high_level_design.md` — あれば - `miko/glossary.md` — あれば -### 2. 横断概念の網羅チェック（機械照合） - -`.miko/guides/harae_guide.md` の「機械照合: 横断概念の網羅チェック」に従い、メインセッションで実施する。指摘があれば検証軸「不完全性」としてステップ 4 の統合結果に加える。 - -### 3. 攻撃的検証（サブエージェント並列） +### 2. 攻撃的検証（サブエージェント並列） 3つのサブエージェントを並列で起動する。 @@ -82,13 +78,13 @@ $ARGUMENTS 各サブエージェントは **指摘リストのみ** 返す。問題が見つからなければ「指摘なし」。 -### 4. 結果統合・ファイル生成 +### 3. 結果統合・ファイル生成 -ステップ 2 の機械照合の指摘とサブエージェントの結果を統合し、重複を排除して `harae.md` を生成する。 +サブエージェントの結果を統合し、重複を排除して `harae.md` を生成する。 **指摘がない場合も `harae.md` を生成する。** 指摘一覧テーブルは空にし、詳細セクションに「6軸すべてで指摘事項なし」と記載する。 -### 5. 対話 +### 4. 対話 指摘について主さまと対話し、対処を決める。 @@ -100,6 +96,6 @@ $ARGUMENTS **指摘がない場合はこのステップをスキップする。** -### 6. 完了 +### 5. 完了 指摘数とステータス内訳（resolved/dismissed/open）をサマリーテーブルで提示する。open があれば `/miko.harae` による再検証をお勧めする。 diff --git a/skills/miko.propose/SKILL.md b/skills/miko.propose/SKILL.md index 724e2b1..76a27ec 100644 --- a/skills/miko.propose/SKILL.md +++ b/skills/miko.propose/SKILL.md @@ -165,9 +165,9 @@ $ARGUMENTS **調査結果の扱い:** - 影響なし: 「他ケイパビリティへの影響はございませんでした」と報告し、ステップ 10 へ進む - 影響あり: 結果をユーザーに提示し、内容を確認・修正してもらう。確認後にステップ 10 でプロポーザルの「他ケイパビリティへの影響」セクションに反映し、**プロポーザルの先頭に `` マーカーを付与する**（このマーカーがないと実装対象プロポーザルとして扱われてしまうため） -- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「横断概念 > 宣言」の追加を含め、全ケイパビリティの「横断概念 > 適合」への影響を「他ケイパビリティへの影響」に反映して `` を付与する +- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「横断概念」セクションへの宣言行追加を含め、影響先ケイパビリティの `[xc:…]` タグ付きルールの新設・改訂を「他ケイパビリティへの影響」に反映して `` を付与する -**横断プロポーザルになる典型:** 変更が横断概念の宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念に適合している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 +**横断プロポーザルになる典型:** 変更が横断概念の宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念を `[xc:…]` タグで参照している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 ### 10. プロポーザル生成 diff --git a/skills/miko.propose/guides/cross_capability_impact_guide.md b/skills/miko.propose/guides/cross_capability_impact_guide.md index 0845256..13cf5ae 100644 --- a/skills/miko.propose/guides/cross_capability_impact_guide.md +++ b/skills/miko.propose/guides/cross_capability_impact_guide.md @@ -71,8 +71,8 @@ business_rules.md が存在しないケイパビリティは管理対象外で - 変更案でメインケイパビリティの責務が変わり、このケイパビリティのルールが不要になる **横断概念に関わるケース:** -- 変更案が宣言済み横断概念の宣言文・定義ルールを変える → その概念に適合している（「横断概念 > 適合」に適用/非適用を表明している）全ケイパビリティが影響対象。適合エントリと適用ルールの改訂要否を判定する -- 変更案が新しい横断概念の宣言を含む → 全ケイパビリティで適合の追記が必要（各ケイパビリティの操作から適用/非適用の案を出す） +- 変更案が宣言済み横断概念の宣言文・定義ルールを変える → その概念の ID（`xc:…`）を grep し、タグで参照している全ルールが影響対象。各ルールの改訂要否を判定する +- 変更案が新しい横断概念の宣言を含む → 全ケイパビリティについて、概念の効果を持つ操作があるかを判定する。効果を持つケイパビリティには `[xc:…]` タグ付きルールの新設を提案する。効果を持たないケイパビリティは報告しない（調査済み一覧に含まれることが検討の痕跡になる） - 変更案に含まれる状態・属性が「判定テスト: 横断概念か」（business_rules_guide.md）を満たす → 変更案自体は宣言していなくても **昇格候補** として報告する ### 3. 影響なしの判定基準 @@ -112,12 +112,10 @@ business_rules.md が存在しないケイパビリティは管理対象外で - **PREF-XX**（廃止） - 理由: （なぜ不要になるか） -##### 横断概念の適合の変更（該当する場合） -- **{概念名}**（{オーナー}）→ 適用: PREF-XX / 非適用（理由） - - 根拠: （変更案のどの部分が起点か） - ``` +横断概念に関わる新設・改訂ルールには、本文の先頭タグに概念 ID を含めて提案する（例: `[制約][xc:user_management/tos-violator]`）。 + ### 横断概念の昇格候補（該当する場合） 変更案に含まれる状態・属性が横断概念の判定テストを満たす場合、影響一覧とは別に報告する: diff --git a/skills/miko.quick-catchup/SKILL.md b/skills/miko.quick-catchup/SKILL.md index e1846cd..5da7efd 100644 --- a/skills/miko.quick-catchup/SKILL.md +++ b/skills/miko.quick-catchup/SKILL.md @@ -115,7 +115,7 @@ diff ソース、変更の要約、ビジネスルールへの影響（新設/ **ステップ 6 で生成した proposal の内容を business_rules.md に反映する。** - proposal の新設・改訂を適用する - 実装マッピングを更新する -- **横断概念セクションの遅延マイグレーション** — business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものはステップ 8 末尾の確認で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する +- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものはステップ 8 末尾の確認で主さまに報告する - 新しい用語があれば `miko/glossary.md` に追加する（`.miko/examples/glossary.md` のフォーマットに従う。実装の詳細は書かず、1〜2文の定義だけを書く） - ケイパビリティの節は配置の軸であり、意味のスコープではない。見出し語はシステム全体で一意にする。既存の見出し語と衝突する場合は、同じ意味なら1項目に統合し、別概念なら一意な別名を立てる（注文確定 / 決済確定） diff --git a/skills/miko.quick-impl/SKILL.md b/skills/miko.quick-impl/SKILL.md index c7ef5b5..4e37200 100644 --- a/skills/miko.quick-impl/SKILL.md +++ b/skills/miko.quick-impl/SKILL.md @@ -144,9 +144,9 @@ miko の原則として BR ルール本文の変更には proposal が必要。p - proposal がある場合のみ: proposal の新設・改訂・廃止を BR 本文に適用する - proposal がない場合: BR 本文は一切触らない（スコープガード (d) で除外済みのはず） -#### 横断概念セクションの遅延マイグレーション +#### 横断概念の書き込み時検査（lint） -business_rules.md を更新した場合で、そのファイルに横断概念セクション（宣言 / 適合）がないとき、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものは末尾の「更新内容の確認」で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する。BR を更新しない実行ではスキップする。 +business_rules.md を更新した場合、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものは主さまに報告する。BR を更新しない実行ではスキップする。 #### 実装マッピングの横断更新（Sonnet サブエージェント） diff --git a/skills/miko.speckit.implement/SKILL.md b/skills/miko.speckit.implement/SKILL.md index 2b929d9..ac99dfc 100644 --- a/skills/miko.speckit.implement/SKILL.md +++ b/skills/miko.speckit.implement/SKILL.md @@ -143,7 +143,7 @@ tasks.md の最終フェーズに到達したら、以下の順序で実行す - 今回の実装で作成・変更したファイルを元に、該当ルールの実装マッピング（`
` 内）を更新する - 既存ルールでも実装場所が変わったものがあれば更新する - **spec.md の Miko コンテキストに複数ケイパビリティのサブプロポーザルが含まれている場合:** 各サブプロポーザルの BR 変更セクションに従って、各ケイパビリティの `miko//business_rules.md` をそれぞれ更新する -- **横断概念セクションの遅延マイグレーション:** 更新した各 business_rules.md に横断概念セクション（宣言 / 適合）がない場合、`.miko/guides/business_rules_guide.md` の「既存 BR への導入（遅延マイグレーション）」に従って導入する。適合判定に判断が必要なものはステップ 6 の確認で主さまに確認し、確認できないものは `→ 要判定 ` として記録し完了報告で明示する +- **横断概念の書き込み時検査（lint）:** 更新した各 business_rules.md に対して、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものはステップ 6 の確認で主さまに報告する **3. high_level_design.md の更新** - 今回の実装で構造に変更があった場合、`miko//high_level_design.md` を更新する From f3e06176b39f9d5a387e77de3ed6451532d6f9ab Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 06:17:41 +0000 Subject: [PATCH 5/8] =?UTF-8?q?=E6=A8=AA=E6=96=AD=E6=A6=82=E5=BF=B5?= =?UTF-8?q?=E3=82=92=E3=82=AB=E3=83=86=E3=82=B4=E3=83=AA=E3=81=AE=E5=8F=AF?= =?UTF-8?q?=E8=A6=96=E6=80=A7=E4=BF=AE=E9=A3=BE=E3=81=A8=E3=81=97=E3=81=A6?= =?UTF-8?q?=E5=86=8D=E8=A8=AD=E8=A8=88=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit カテゴリ＝モジュール、横断＝可視性という見立てに基づき、宣言の表現を 専用セクション + 宣言行からカテゴリマークに変更する。BR の階層 （ケイパビリティ / カテゴリ / ルール）は（パッケージ / モジュール / 関数） に対応し、共有の実体は関数（ルール）だが思考と契約の単位はモジュール （カテゴリ）である。 - 宣言 = 概念のカテゴリ見出しに [横断] マーク + cross-concept マーカーを 付けて public 化する。lead 文が宣言文、定義はカテゴリ内の通常ルール - 概念 ID = xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}。 プレフィックスは既存機構の再利用で、新しい命名・採番はない - カテゴリは既定で private（自由に再編可）。public 化したカテゴリの 改名・分割・マーク変更だけが proposal 必須の契約変更になる - 定義が既存カテゴリに埋まっている場合は public 化の時点で切り出す - 可視性 ≠ 義務（義務の根拠は判定テストを通った宣言文）を明記し、 将来の別種マークの余地を設計メモに残す - example は横断カテゴリ「支払い不履行ユーザー（DEFAULT）」として PAY-03 を DEFAULT-01 に抽出し、専用セクションを廃止 - 却下した代替案（専用セクション + 宣言行、消費側の同名カテゴリ複製）を business_rules_driven_development.md に追記 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- CHANGELOG.md | 2 +- business_rules_driven_development.md | 16 ++--- ofuda/VERSION | 2 +- ofuda/examples/business_rules.md | 44 ++++++++----- ofuda/guides/business_rules_guide.md | 61 +++++++++++-------- skills/miko.catchup/SKILL.md | 2 +- skills/miko.miko/SKILL.md | 4 +- skills/miko.new-cap/SKILL.md | 6 +- skills/miko.propose/SKILL.md | 2 +- .../guides/cross_capability_impact_guide.md | 2 +- skills/miko.quick-catchup/SKILL.md | 2 +- skills/miko.quick-impl/SKILL.md | 2 +- skills/miko.speckit.implement/SKILL.md | 2 +- 13 files changed, 87 insertions(+), 60 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ac80fab..26cc531 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,7 +4,7 @@ ### New -- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。横断しているのはルール（文）ではなく概念（名詞）という整理に基づき、オーナーの BR の「横断概念」セクションに 1 概念 = 1 行で宣言し（業務用語 + `xc:{cap}/{slug}` 形式の ID + 宣言文 + 定義ルール ID + 行末 `` マーカー）、効果を持つケイパビリティは自分のルールに `[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` の「解決済みの論点」を参照 +- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。BR の階層（ケイパビリティ / カテゴリ / ルール）を（パッケージ / モジュール / 関数）と見立て、横断概念を**カテゴリの可視性修飾**として表現する: オーナーは概念のカテゴリ見出しに `[横断]` マークと `` マーカーを付けて public 化し（lead 文が宣言文、定義はカテゴリ内の通常ルール）、効果を持つケイパビリティは自分のルールに `[xc:{cap}/{プレフィックス}]` タグを付けて参照する（import に相当）。非適用は記録しない。一覧は `grep 'cross-concept' miko/*/business_rules.md`、特定概念の全体像（宣言 + 全適用ルール）は ID の grep で都度導出し、中央レジストリは持たない。public カテゴリの改名・分割・マーク変更は proposal 必須（private カテゴリの再編は従来どおり自由）。網羅性は記録や事後監査ではなく **プロセスの門で構成的に保証する** — ケイパビリティ × 概念の全ペアは、概念の宣言（propose の影響調査）かケイパビリティの新規作成（new-cap の判定ステップ）の遅い方で必ず一度検討される。判定テスト（他者性・全称性・必達性）、ID・マーク・タグの書式、書き込み時 lint（orphan 参照・マーク整合・書式）を `business_rules_guide.md` の「横断概念とは何か」に定義。`.miko/examples/business_rules.md` に実例（横断カテゴリ `xc:order_management/DEFAULT` とタグ付きルール ORD-05）を追加。検討経緯と却下した代替案（中央レジストリ・ルール単位マーク・適合セクション・非適用の記録・グローバル連番 ID・専用セクション + 宣言行・harae での網羅監査）は `business_rules_driven_development.md` の「解決済みの論点」を参照 ### Changed diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index fda9d7c..1f62425 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -264,12 +264,11 @@ proposal に代替案を追記（AI：重要な検討経緯があれば） ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 -## 4. 横断概念（宣言する概念を所有する場合のみ） ``` - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `` で最終採番を記録する - **2.1 ドメインビジネスルール / 2.2 システムビジネスルール**: ルールを「紙運用」テストで振り分けて配置する。カテゴリ（ORD、PAY 等）はどちらか一方に置く -- **4. 横断概念**: このケイパビリティがオーナーとして宣言する横断概念（1 概念 = 1 行、`xc:` ID + 行末マーカー）。宣言する概念を所有する場合のみセクションを作る。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 +- **横断概念**: 専用セクションは持たない。オーナーがカタログ内のカテゴリに `[横断]` マークを付けて宣言する（カテゴリ＝モジュール、横断＝可視性）。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 ### 操作の定義（Operations） @@ -388,10 +387,11 @@ miko//proposals/ **構造:** - **横断しているのはルール（文）ではなく概念（名詞）。** ルールは書き方次第で分割・統合される不安定な単位のため、義務は概念に付ける。横断なのはエンティティ（ユーザー）ではなく状態（規約違反）である +- **カテゴリ＝モジュール、横断＝可視性。** BR の階層（ケイパビリティ / カテゴリ / ルール）は（パッケージ / モジュール / 関数）に対応する。カテゴリは既定で private（オーナーが自由に再編できる整理棚）だが、`[横断]` マークで public モジュールになり、名前が公開 API になる。共有の実体は関数（ルール）だが、思考と契約の単位はモジュール（カテゴリ）— という プログラミングの直感に合わせる。可視性 ≠ 義務（義務の根拠は判定テストを通った宣言文）であり、将来「特定ケイパビリティにのみ公開」等が必要になれば別のマークを立てる - **判定テスト（3 問すべて Yes で横断概念）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか -- **概念 ID:** `xc:{ケイパビリティディレクトリ名}/{短い英語スラッグ}`（例: `xc:user_management/tos-violator`）。ID がオーナー BR へのポインタを兼ねる。採番なし -- **宣言（オーナーのみ）:** BR の「横断概念」セクションに 1 概念 = 1 行（業務用語 + ID + 宣言文 + 定義ルール ID + 行末 `` マーカー）。定義は通常ルールとして持つ。宣言の追加・変更・除去は proposal 必須（横断プロポーザル）。セクションは宣言する概念を所有する場合のみ作る -- **適用（効果を持つケイパビリティ）:** 効果を担うルールに `[xc:…]` タグを付ける。「概念に誰が応えているか」は ID の grep で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される） +- **概念 ID:** `xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}`（例: `xc:user_management/TOS`）。ID がオーナー BR へのポインタを兼ねる。プレフィックスは既存機構の再利用で、新しい採番・命名はない +- **宣言（オーナーのみ）:** 概念のカテゴリ見出しに `[横断]` マーク + `` マーカーを付け、lead 文に宣言文（各ケイパビリティが何を表明すべきかの軸）を書く。定義はカテゴリ内の通常ルール。定義が既存カテゴリに埋まっている場合は public 化の時点でカテゴリを切り出す。マークの付与・除去・横断カテゴリの改名は proposal 必須（横断プロポーザル）。private カテゴリの再編は従来どおり自由 +- **適用（効果を持つケイパビリティ）:** 効果を担うルールに `[xc:…]` タグを付ける（import に相当。置き場は自分のカテゴリでよく、オーナーの分類法を持ち込まない）。「概念に誰が応えているか」は ID の grep で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される） - **非適用は書かない。** 「検討したが効果を持たない」の記録は持たない（propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すのみ） - **一覧は grep で導出:** `grep -n 'cross-concept' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する @@ -400,9 +400,9 @@ miko//proposals/ 1. **門 1 — propose の他ケイパビリティ影響調査（必須化）:** 概念の宣言・変更は横断プロポーザルになり、影響調査が全ケイパビリティに判定を下す。調査は昇格候補（未宣言の横断関係）の発見も担う 2. **門 2 — new-cap の横断概念判定ステップ（新設）:** 新規ケイパビリティ作成時に宣言を grep し、各概念について対話で判定する。適用なら `[xc:…]` タグ付きルールを作る -加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）を実行する。harae に横断概念の必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。 +加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）を実行する。harae に横断概念の必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。 -**既存 BR への遡及なし:** 宣言行とタグは概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。マイグレーション不要。 +**既存 BR への遡及なし:** `[横断]` マークとタグは概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。マイグレーション不要。 **検討・却下した代替案:** @@ -413,6 +413,8 @@ miko//proposals/ - **適合セクション（各 BR に全宣言への適用/非適用を明示する verdict 台帳）** — 適用行はルール側タグと二重管理になり、非適用行は概念 × ケイパビリティの積で増えるノイズ。網羅性を「事後の照合」で保証する発想の産物で、門の構成的保証に置き換えて廃止 - **非適用の記録（BR / harae.md / proposal のいずれかに残す）** — 「無記載と検討済みの区別」は事後照合が前提のときだけ必要。門で保証するなら証明の役目を失う。理由の陳腐化（後から該当操作が増える等）は記録では検出できず、残す理由にならない - **グローバル連番の概念 ID（XC-01 等）** — 並行ブランチで採番が衝突し、番号が情報を担わない。概念は少数で名前が一意なので、修飾付き名前で足りる +- **専用セクション + 宣言行（カテゴリとは独立した公開面）** — カタログ再編の自由を守るための間接層だったが、可視性の意味論（public にしたカテゴリだけ再編が契約変更になり、private は自由なまま）で同じ目的がより一般的に達成できる。カテゴリ＝モジュールの見立てに置き換えて廃止 +- **消費側も同名カテゴリで持つ（アスペクト複製型）** — オーナーの分類法を消費側に強制することになる。効果ルールの置き場は消費側のドメインの整理に従い、タグで参照する ### 複数ケイパビリティにまたがる変更 diff --git a/ofuda/VERSION b/ofuda/VERSION index df977da..2c166a9 100644 --- a/ofuda/VERSION +++ b/ofuda/VERSION @@ -1,2 +1,2 @@ 1.5.0 -202609050930 +202609070617 diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index 1d8ca2c..d8ccca6 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -93,10 +93,10 @@ stateDiagram-v2 - **ORD-04** [制約] 猶予期間経過後のキャンセルは管理者操作でのみ可能とする。 -- **ORD-05** [制約][xc:user_management/tos-violator] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 +- **ORD-05** [制約][xc:user_management/TOS] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 - +
実装マッピング @@ -122,20 +122,40 @@ stateDiagram-v2 - **PAY-02** [制約] 決済済み注文のキャンセル時は、対応する金額を返金しなければならない。 -- **PAY-03** [導出] 直近90日間で未決済による自動キャンセル（PAY-01）が3回発生したユーザーは「支払い不履行ユーザー」と定義する。 - - -
実装マッピング - PAY-01 → `Ec::Jobs::ExpireUnpaidOrdersJob` / 日次バッチ - PAY-02 → `Ec::Services::CancelOrderService` / 返金ジョブ投入 -- PAY-03 → `Ec::Orders::PaymentDefaultQuery` / 直近90日の自動キャンセル集計
- + + +--- + +#### 支払い不履行ユーザー（DEFAULT）[横断] + +未決済の自動キャンセルを繰り返したユーザー。 +各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。 + + + +**ルール:** +- **DEFAULT-01** [導出] 直近90日間で未決済による自動キャンセル（PAY-01）が3回発生したユーザーは「支払い不履行ユーザー」と定義する。 + + + +
実装マッピング + +- DEFAULT-01 → `Ec::Orders::PaymentDefaultQuery` / 直近90日の自動キャンセル集計 + +
+ + --- @@ -180,11 +200,3 @@ stateDiagram-v2 - **借りているもの:** 配達完了通知 - **渡しているもの:** 出荷依頼 - **境界の注意点:** 配送業者の通知遅延により、実際の配達完了とステータス更新にタイムラグが生じる。この間ユーザーには「出荷済み」のまま表示される - ---- - -## 4. 横断概念 - -- **支払い不履行ユーザー** (`xc:order_management/pay-defaulter`) — 未決済の自動キャンセルを繰り返したユーザー。各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。定義: PAY-03 - - diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 19a6062..2151fd6 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -343,55 +343,67 @@ high_level_design.md（AI が更新：構造の変化） **横断なのはエンティティではなく状態である。** 「ユーザー」という概念全体が横断なのではない。「規約違反」という特定の状態だけが横断であり、「メール確認済み」「最終ログイン日時」はオーナーに閉じる。 +### カテゴリ＝モジュール、横断＝可視性 + +BR の階層（ケイパビリティ / カテゴリ / ルール）は、プログラミングの（パッケージ / モジュール / 関数）に対応する。横断概念はこの見立ての上の**可視性修飾**である: カテゴリは既定で private（オーナーの整理棚。自由に分割・改名・統合してよい）だが、`[横断]` マークを付けたカテゴリは **public モジュール**になり、その名前（プレフィックス）は他ケイパビリティから参照される公開 API になる。 + +- public にしたカテゴリの改名・分割・除去は契約変更であり、proposal 必須（横断プロポーザル）。private カテゴリの再編は従来どおり自由 +- 概念の定義ルールが既存カテゴリの中に埋まっている場合は、public 化の時点で概念のカテゴリとして**切り出す**（関数を公開したくなったらモジュールを抽出するのと同じ。凝集を強制する良い圧である） +- 可視性 ≠ 義務: 全ケイパビリティに検討を義務づける根拠は `[横断]` マークではなく、判定テストを通った宣言文である。現時点のマークは「public かつ全称義務」の 1 種類のみ + ### 責務の分担 | 何を | どこに書くか | |---|---| -| 概念の定義（誰がその状態になるか・解除条件） | オーナーの BR の通常ルール（[導出] / [制約]） | -| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の「横断概念」セクション（1 行） | -| 各ケイパビリティでの具体的な効果 | 効果を持つケイパビリティの通常ルール（`[xc:…]` タグ付き） | +| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の横断カテゴリ（`[横断]` マーク + lead 文） | +| 概念の定義（誰がその状態になるか・解除条件） | 横断カテゴリ内の通常ルール（[導出] / [制約]） | +| 各ケイパビリティでの具体的な効果 | 効果を持つケイパビリティの通常ルール（`[xc:…]` タグ付き。置き場はそのケイパビリティ自身のカテゴリ） | | 非適用（効果を持たない判断） | **書かない**（後述） | -効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。 +効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。オーナーの分類法（カテゴリ名）を消費側に強制しない — 消費側のルールは自分のドメインのカテゴリに置き、タグで参照する。 ### 概念 ID -横断概念には `xc:{ケイパビリティディレクトリ名}/{スラッグ}` 形式の ID を振る。 +横断概念の ID は `xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}` 形式である。 - ケイパビリティ部は `miko/` 配下のディレクトリ名をそのまま使う。ID がオーナーの BR ファイルへのポインタを兼ねる -- スラッグは短い英語（1〜2 語、ケバブケース、略語可）。例: `xc:user_management/tos-violator`、`xc:order_management/pay-defaulter` -- 日本語の業務用語（「規約違反ユーザー」）は glossary とルール本文の語彙のまま使う。ID は参照用の機械キーであり、対訳は宣言行が持つ +- プレフィックス部は横断カテゴリの英字プレフィックスそのもの（例: `xc:user_management/TOS`）。新しい命名機構は導入しない +- 日本語の業務用語（「規約違反ユーザー」）は glossary とルール本文の語彙のまま使う。ID は参照用の機械キーであり、対訳はカテゴリ見出しが持つ -### 宣言の書き方（オーナーの BR） +### 宣言の書き方（オーナーの BR の横断カテゴリ） -宣言は **1 概念 = 1 行**とし、「横断概念」セクションに置き、行末に機械マーカー `` を付ける。 +概念のカテゴリ見出しに `[横断]` マークと機械マーカー `` を付け、lead 文として宣言文（モジュールの docstring に相当）を書く。定義ルールはカテゴリ内の通常ルール。 ```markdown -## 4. 横断概念 +#### 規約違反ユーザー（TOS）[横断] -- **規約違反ユーザー** (`xc:user_management/tos-violator`) — 規約違反が確定したが、ビジネス上 BAN はできないユーザー。各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。定義: USER-08〜USER-09 +規約違反が確定したが、ビジネス上 BAN はできないユーザー。 +各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。 + +**ルール:** +- **TOS-01** [導出] 通報が確定し、かつ有償契約が継続中のユーザーは「規約違反ユーザー」と定義する。 +- **TOS-02** [制約] 規約違反状態の解除は運営者の手動操作でのみ行える。 ``` -- **セクションは宣言する概念があるときだけ作る**。宣言しないケイパビリティ（大多数）の BR には何も足さない -- 宣言文には、概念の 1 行説明・各ケイパビリティが何を表明すべきかの軸・定義ルールの ID を書く。個別ケイパビリティの操作名は書かない -- マーカー `` は宣言行以外に書かない。**システム全体の横断概念一覧はこの grep で都度導出する**（中央のレジストリファイルは持たない）: +- 宣言文には、概念の説明と「各ケイパビリティが何を表明すべきか」の軸を書く。個別ケイパビリティの操作名は列挙しない +- マーカー `` は横断カテゴリの見出し行以外に書かない。**システム全体の横断概念一覧はこの grep で都度導出する**（中央のレジストリファイルは持たない）: ```bash grep -n 'cross-concept' miko/*/business_rules.md ``` -- **宣言の追加・変更・除去は proposal 必須。** 全ケイパビリティに検討の義務を課す（または解除する）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う +- **`[横断]` マークの付与・除去、横断カテゴリの改名・分割は proposal 必須。** 全ケイパビリティに検討の義務を課す（または契約を変える）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う ### 適用の書き方（効果を持つケイパビリティのルール） -横断概念の効果を担うルールは、タグ位置に概念 ID を付ける。 +横断概念の効果を担うルールは、タグ位置に概念 ID を付ける（モジュールの import に相当）。 ```markdown -- **ORD-05** [制約][xc:user_management/tos-violator] 規約違反ユーザーは注文コメントを投稿できない。 +- **ORD-05** [制約][xc:user_management/TOS] 規約違反ユーザーは注文コメントを投稿できない。 ``` - ルール本文は通常どおりビジネス語彙（日本語の用語）で書く。タグが機械可読なリンクを担う -- 「この概念にどのケイパビリティのどのルールが応えているか」は `grep -n 'xc:user_management/tos-violator' miko/*/business_rules.md` で都度導出する（宣言行 + 全適用ルールが 1 コマンドで列挙される）。オーナーは消費者の一覧を持たない +- 「この概念にどのケイパビリティのどのルールが応えているか」は `grep -n 'xc:user_management/TOS' miko/*/business_rules.md` で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される）。オーナーは消費者の一覧を持たない - **横断概念への依存は境界セクションに書かない**（タグが唯一の置き場。二重管理を避ける） ### 非適用は書かない @@ -402,9 +414,9 @@ grep -n 'cross-concept' miko/*/business_rules.md business_rules.md を更新するスキルは、更新の直後に以下を機械的に検査し、問題があれば修正する（できなければユーザーに報告する）: -1. **orphan 参照**: `xc:` 参照のうち、対応する宣言行（`` 付き）が存在しないもの -2. **宣言の重複**: 同じ ID の宣言行が複数存在しないか -3. **書式**: 宣言行が「1 行・業務用語・ID・宣言文・定義ルール ID・行末マーカー」を満たすか。タグが `[制約]/[導出]` の直後に置かれているか +1. **orphan 参照**: `xc:` 参照のうち、対応する横断カテゴリ（`[横断]` + `` 付き見出し）が存在しないもの +2. **マークの整合**: `[横断]` マークと見出し行のマーカーが片方だけになっていないか。同じ ID の横断カテゴリが複数存在しないか +3. **書式**: 横断カテゴリの見出しが「業務用語（プレフィックス）[横断] マーカー」の形式か、lead 文（宣言文）があるか。タグが `[制約]/[導出]` の直後に置かれているか --- @@ -421,10 +433,9 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 ### 2.1 ドメインビジネスルール ### 2.2 システムビジネスルール ## 3. 関連ケイパビリティとの境界 -## 4. 横断概念（宣言する概念を所有する場合のみ） ``` -**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。横断概念の仕組みも既存 BR に遡及しない — 宣言行や `[xc:…]` タグは、概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。 +**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。横断概念の仕組みも既存 BR に遡及しない — `[横断]` マークや `[xc:…]` タグは、概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。 ### 各セクションの指針 @@ -455,7 +466,7 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 **境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。逆に、**横断概念への依存は境界には書かない**（ルールの `[xc:…]` タグが唯一の置き場。二重管理を避ける）。 -**横断概念**: このケイパビリティがオーナーとして宣言する横断概念の一覧（1 概念 = 1 行）。宣言する概念を所有する場合のみセクションを作る。詳細は前述の「横断概念とは何か」を参照。 +横断概念に専用セクションはない — 宣言はカタログ内の横断カテゴリ（`[横断]` マーク）として表現する。詳細は前述の「横断概念とは何か」を参照。 > **注意:** アーキテクチャ上の決定事項（ADR）は business_rules.md には書かない。技術選択の「決定・意図・トレードオフ」は high_level_design.md の「設計上の特徴」セクションに記載する。 @@ -472,6 +483,8 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 ### スレッド管理（THREAD） ``` +カテゴリは既定で private（自由に分割・改名・統合してよいオーナーの整理単位）。横断概念のカテゴリだけは `[横断]` マークで public になり、改名等が契約変更になる（「横断概念とは何か」参照）。 + ### ルールID `{プレフィックス}-{連番}` 形式。削除したルールの番号は欠番にする（詰めない）。harae.md や proposal がルールIDで指摘を参照しているため、番号を振り直すと参照が壊れる。 diff --git a/skills/miko.catchup/SKILL.md b/skills/miko.catchup/SKILL.md index 21d377e..fe31bbc 100644 --- a/skills/miko.catchup/SKILL.md +++ b/skills/miko.catchup/SKILL.md @@ -161,7 +161,7 @@ $ARGUMENTS - 承認された削除 - 実装マッピング - 操作の定義（コードから新しい操作が見つかった場合） -- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものは主さまに報告する +- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものは主さまに報告する **glossary.md の更新:** - proposal で新しい用語が登場した場合は `miko/glossary.md` に追加する（ファイルがなければ作成） diff --git a/skills/miko.miko/SKILL.md b/skills/miko.miko/SKILL.md index 1d656db..a580e96 100644 --- a/skills/miko.miko/SKILL.md +++ b/skills/miko.miko/SKILL.md @@ -171,9 +171,9 @@ miko の実装フローでは **constitution**（`.specify/memory/constitution.m 6. **「複数のケイパビリティに効くルールはどこに書く？」「これって横断概念？」** - `business_rules_guide.md` の「判定テスト: 横断概念か」（他者性・全称性・必達性）を一緒に適用する - - 3 問すべて Yes → オーナーの BR に宣言（`/miko.propose` 経由）、効果は各ケイパビリティのルールに `[xc:…]` タグ付きで書く + - 3 問すべて Yes → オーナーの BR で概念のカテゴリに `[横断]` マークを付ける（`/miko.propose` 経由）。効果は各ケイパビリティのルールに `[xc:…]` タグ付きで書く - 相手を列挙できる二者間の依存 → 境界セクションで足りる（横断概念にしない） - - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md`、特定の概念の全体像（宣言 + 適用ルール）は `grep -n 'xc:{cap}/{slug}' miko/*/business_rules.md` で提示する + - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md`、特定の概念の全体像（宣言 + 適用ルール）は `grep -n 'xc:{cap}/{プレフィックス}' miko/*/business_rules.md` で提示する 7. **「constitution に何を書けばいい？」「CLAUDE.md に書くのと何が違う？」** - 実装フローで毎回守ってほしいプロジェクト固有のルール → constitution diff --git a/skills/miko.new-cap/SKILL.md b/skills/miko.new-cap/SKILL.md index 8a7c9d9..43f708f 100644 --- a/skills/miko.new-cap/SKILL.md +++ b/skills/miko.new-cap/SKILL.md @@ -158,7 +158,7 @@ $ARGUMENTS `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する。ヒットが 1 件もなければこのステップをスキップする。 ヒットした各概念について: -1. 宣言行（業務用語・`xc:` ID・宣言文・定義ルール ID）を読む。判定に必要なら、オーナー BR から定義ルールの本文だけを読む（BR ファイル全体は読まない） +1. 横断カテゴリ（見出しの業務用語・`xc:` ID・lead 文の宣言文）を読む。判定に必要なら、オーナー BR からそのカテゴリの定義ルールだけを読む（BR ファイル全体は読まない） 2. ユーザーに確認する（例: 「ユーザー管理が横断概念『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） 3. 効果を持つと判定された概念について、効果を表すルールをルール候補に加える（生成時に `[xc:…]` タグを付ける）。効果を持たない概念については何も書かない（この対話で検討したこと自体が保証であり、非適用の記録は持たない） @@ -234,8 +234,8 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を - 未実装の場合: `
` 内に `（未実装）` マーク付きで記載 - **横断概念**（ガイドの「横断概念とは何か」参照）: - ステップ 6c で効果を持つと判定した概念のルールに `[xc:…]` タグを付ける - - 「横断概念」セクションは作らない（宣言は proposal を通すため、new-cap では昇格候補の案内まで） - - 生成後、ガイドの「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・タグの書式） + - `[横断]` マーク付きカテゴリは作らない（横断カテゴリの新設は proposal を通すため、new-cap では昇格候補の案内まで） + - 生成後、ガイドの「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・タグの書式） - 未決事項がある場合、末尾に「未決事項」セクションを追加 ```markdown diff --git a/skills/miko.propose/SKILL.md b/skills/miko.propose/SKILL.md index 76a27ec..eba8c83 100644 --- a/skills/miko.propose/SKILL.md +++ b/skills/miko.propose/SKILL.md @@ -165,7 +165,7 @@ $ARGUMENTS **調査結果の扱い:** - 影響なし: 「他ケイパビリティへの影響はございませんでした」と報告し、ステップ 10 へ進む - 影響あり: 結果をユーザーに提示し、内容を確認・修正してもらう。確認後にステップ 10 でプロポーザルの「他ケイパビリティへの影響」セクションに反映し、**プロポーザルの先頭に `` マーカーを付与する**（このマーカーがないと実装対象プロポーザルとして扱われてしまうため） -- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「横断概念」セクションへの宣言行追加を含め、影響先ケイパビリティの `[xc:…]` タグ付きルールの新設・改訂を「他ケイパビリティへの影響」に反映して `` を付与する +- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「概念のカテゴリへの `[横断]` マーク付与（定義ルールが既存カテゴリに埋まっている場合はカテゴリの切り出しを含む）」を含め、影響先ケイパビリティの `[xc:…]` タグ付きルールの新設・改訂を「他ケイパビリティへの影響」に反映して `` を付与する **横断プロポーザルになる典型:** 変更が横断概念の宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念を `[xc:…]` タグで参照している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 diff --git a/skills/miko.propose/guides/cross_capability_impact_guide.md b/skills/miko.propose/guides/cross_capability_impact_guide.md index 13cf5ae..4bea4b1 100644 --- a/skills/miko.propose/guides/cross_capability_impact_guide.md +++ b/skills/miko.propose/guides/cross_capability_impact_guide.md @@ -114,7 +114,7 @@ business_rules.md が存在しないケイパビリティは管理対象外で ``` -横断概念に関わる新設・改訂ルールには、本文の先頭タグに概念 ID を含めて提案する（例: `[制約][xc:user_management/tos-violator]`）。 +横断概念に関わる新設・改訂ルールには、本文の先頭タグに概念 ID を含めて提案する（例: `[制約][xc:user_management/TOS]`）。 ### 横断概念の昇格候補（該当する場合） diff --git a/skills/miko.quick-catchup/SKILL.md b/skills/miko.quick-catchup/SKILL.md index 5da7efd..7ef6771 100644 --- a/skills/miko.quick-catchup/SKILL.md +++ b/skills/miko.quick-catchup/SKILL.md @@ -115,7 +115,7 @@ diff ソース、変更の要約、ビジネスルールへの影響（新設/ **ステップ 6 で生成した proposal の内容を business_rules.md に反映する。** - proposal の新設・改訂を適用する - 実装マッピングを更新する -- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものはステップ 8 末尾の確認で主さまに報告する +- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 8 末尾の確認で主さまに報告する - 新しい用語があれば `miko/glossary.md` に追加する（`.miko/examples/glossary.md` のフォーマットに従う。実装の詳細は書かず、1〜2文の定義だけを書く） - ケイパビリティの節は配置の軸であり、意味のスコープではない。見出し語はシステム全体で一意にする。既存の見出し語と衝突する場合は、同じ意味なら1項目に統合し、別概念なら一意な別名を立てる（注文確定 / 決済確定） diff --git a/skills/miko.quick-impl/SKILL.md b/skills/miko.quick-impl/SKILL.md index 4e37200..cda114f 100644 --- a/skills/miko.quick-impl/SKILL.md +++ b/skills/miko.quick-impl/SKILL.md @@ -146,7 +146,7 @@ miko の原則として BR ルール本文の変更には proposal が必要。p #### 横断概念の書き込み時検査（lint） -business_rules.md を更新した場合、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものは主さまに報告する。BR を更新しない実行ではスキップする。 +business_rules.md を更新した場合、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものは主さまに報告する。BR を更新しない実行ではスキップする。 #### 実装マッピングの横断更新（Sonnet サブエージェント） diff --git a/skills/miko.speckit.implement/SKILL.md b/skills/miko.speckit.implement/SKILL.md index ac99dfc..d0a7dbc 100644 --- a/skills/miko.speckit.implement/SKILL.md +++ b/skills/miko.speckit.implement/SKILL.md @@ -143,7 +143,7 @@ tasks.md の最終フェーズに到達したら、以下の順序で実行す - 今回の実装で作成・変更したファイルを元に、該当ルールの実装マッピング（`
` 内）を更新する - 既存ルールでも実装場所が変わったものがあれば更新する - **spec.md の Miko コンテキストに複数ケイパビリティのサブプロポーザルが含まれている場合:** 各サブプロポーザルの BR 変更セクションに従って、各ケイパビリティの `miko//business_rules.md` をそれぞれ更新する -- **横断概念の書き込み時検査（lint）:** 更新した各 business_rules.md に対して、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・宣言 ID の重複・宣言行とタグの書式）。問題があれば修正し、修正できないものはステップ 6 の確認で主さまに報告する +- **横断概念の書き込み時検査（lint）:** 更新した各 business_rules.md に対して、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 6 の確認で主さまに報告する **3. high_level_design.md の更新** - 今回の実装で構造に変更があった場合、`miko//high_level_design.md` を更新する From ddd42d8d4fcebd018fe7319afc9ca4a8cf6041e1 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 06:22:06 +0000 Subject: [PATCH 6/8] =?UTF-8?q?example=20=E3=82=92=E8=87=AA=E5=B7=B1?= =?UTF-8?q?=E5=AE=8C=E7=B5=90=E3=81=95=E3=81=9B=E3=80=81=E3=82=AA=E3=83=BC?= =?UTF-8?q?=E3=83=8A=E3=83=BC=E8=87=AA=E8=BA=AB=E3=81=AE=E5=8A=B9=E6=9E=9C?= =?UTF-8?q?=E3=83=AB=E3=83=BC=E3=83=AB=E3=81=AB=E3=82=82=E3=82=BF=E3=82=B0?= =?UTF-8?q?=E3=82=92=E4=BB=98=E3=81=91=E3=82=8B=E8=A6=8F=E7=B4=84=E3=82=92?= =?UTF-8?q?=E6=98=8E=E6=96=87=E5=8C=96?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit example が 1 ファイルしかないため、効果ルール（ORD-05）がサンプル世界に 存在しないユーザー管理の横断概念を参照していた。注文管理が自分で宣言した xc:order_management/DEFAULT の効果ルールを自分で持つ形に書き換え、 定義（DEFAULT-01）と利用（ORD-05 のタグ）が同一サンプル内で閉じるようにする。 - ORD-05 を「支払い不履行ユーザーの未決済注文は同時 1 件まで」に変更し、 タグを xc:order_management/DEFAULT に差し替え。旧 ORD-05 用に足していた 注文コメント投稿の操作は削除 - ガイドに「オーナー自身の効果ルールにも同じタグを付ける（grep の結果が 効果の全量になる）。定義ルールにはタグ不要（横断カテゴリへの包含が定義を 表す）」を明文化 - 他ケイパビリティからの参照が同じ形であることはサンプルコメントで補足 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- ofuda/examples/business_rules.md | 20 +++++++++++--------- ofuda/guides/business_rules_guide.md | 1 + 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index d8ccca6..3ac6eb1 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -61,7 +61,6 @@ stateDiagram-v2 - **注文作成** — ユーザーがカートの内容から注文を作成する。 - **注文確定** — ユーザーが注文内容を確認し確定する。 - **注文キャンセル** — ユーザーが注文をキャンセルする。 -- **注文コメント投稿** — ユーザーが注文に問い合わせコメントを付ける。 ### イベント駆動 - **決済完了通知** — 決済プロバイダからの通知で決済完了を受け付ける。 @@ -93,10 +92,12 @@ stateDiagram-v2 - **ORD-04** [制約] 猶予期間経過後のキャンセルは管理者操作でのみ可能とする。 -- **ORD-05** [制約][xc:user_management/TOS] 規約違反ユーザーは注文コメントを投稿できない。注文の作成・確定・キャンセルは通常どおり可能とする。 - - - +- **ORD-05** [制約][xc:order_management/DEFAULT] 支払い不履行ユーザーが同時に持てる未決済の注文は 1 件までとする。決済済みの注文には影響しない。 + + +
実装マッピング @@ -105,7 +106,7 @@ stateDiagram-v2 - ORD-02 → `Ec::OrdersController#cancel` / キャンセル前のガード - ORD-03 → `Ec::Order::CANCEL_GRACE_PERIOD` / 定数定義 - ORD-04 → `Ec::OrderPolicy#cancel?` / ロール判定 -- ORD-05 → `Ec::OrderCommentPolicy#create?` / 規約違反状態の判定 +- ORD-05 → `Ec::Order#confirmable?` / 未決済注文数の判定
@@ -140,9 +141,10 @@ stateDiagram-v2 各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。 + ID は xc:order_management/DEFAULT。効果を持つケイパビリティのルールがタグで参照する + （オーナー自身の効果ルールも同様。ORD-05 参照）。見出し行の cross-concept マーカーが + grep の対象。lead 文が宣言文（各ケイパビリティが何を表明すべきかの軸だけを書き、 + 他ケイパビリティの操作名は列挙しない）（サンプル用コメント） --> **ルール:** - **DEFAULT-01** [導出] 直近90日間で未決済による自動キャンセル（PAY-01）が3回発生したユーザーは「支払い不履行ユーザー」と定義する。 diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 2151fd6..76e6353 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -403,6 +403,7 @@ grep -n 'cross-concept' miko/*/business_rules.md ``` - ルール本文は通常どおりビジネス語彙（日本語の用語）で書く。タグが機械可読なリンクを担う +- **オーナー自身が自分の概念の効果ルールを持つ場合も、同じタグを付ける**（grep の結果が効果の全量になる）。定義ルール（[導出] で状態を定義するもの）にはタグ不要 — 横断カテゴリへの包含が定義であることを表す - 「この概念にどのケイパビリティのどのルールが応えているか」は `grep -n 'xc:user_management/TOS' miko/*/business_rules.md` で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される）。オーナーは消費者の一覧を持たない - **横断概念への依存は境界セクションに書かない**（タグが唯一の置き場。二重管理を避ける） From ef7ace9b92d2c197f9adc79c0c083bbfcc1990d4 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 06:27:51 +0000 Subject: [PATCH 7/8] =?UTF-8?q?example=20=E3=81=AB=E4=BB=96=E3=82=B1?= =?UTF-8?q?=E3=82=A4=E3=83=91=E3=83=93=E3=83=AA=E3=83=86=E3=82=A3=E5=81=B4?= =?UTF-8?q?=E3=81=AE=E5=8A=B9=E6=9E=9C=E3=83=AB=E3=83=BC=E3=83=AB=E3=81=AE?= =?UTF-8?q?=E6=8A=9C=E7=B2=8B=E3=82=92=E8=BF=BD=E5=8A=A0=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 自己完結化により、サンプル内で宣言と効果が注文管理に閉じてしまい、 横断概念の「横断」（他者性）が見えなくなっていた。1 ファイルでは本物の 横断を表現できないため、予約管理の BR の抜粋であることを明示した 引用ブロック（RSV-04）を DEFAULT カテゴリの直後に添え、他ケイパビリティが 同じタグで参照する形を示す。 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- ofuda/examples/business_rules.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index 3ac6eb1..85ec303 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -159,6 +159,12 @@ stateDiagram-v2 +> **サンプル解説（実際の business_rules.md には書かない）:** この概念が「横断」なのは、注文管理の外の操作にも効くからである。効果を持つ**他ケイパビリティ側**の書き方は、例えば `miko/reservation/business_rules.md`（予約管理）では次のようになる — 自分のドメインのカテゴリに自分のルールとして書き、タグで参照する: +> +> ```markdown +> - **RSV-04** [制約][xc:order_management/DEFAULT] 支払い不履行ユーザーは商品の取り置きを申し込めない。 +> ``` + --- ### 2.2 システムビジネスルール From c8257ed07a3162b0e963a9d3c2247238b90ccc15 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 7 Sep 2026 06:37:53 +0000 Subject: [PATCH 8/8] =?UTF-8?q?=E6=A9=9F=E6=A7=8B=E5=90=8D=E3=82=92?= =?UTF-8?q?=E3=80=8C=E6=A8=AA=E6=96=AD=E6=A6=82=E5=BF=B5=E3=80=8D=E3=81=8B?= =?UTF-8?q?=E3=82=89=E3=80=8C=E6=A8=AA=E6=96=AD=E3=82=AB=E3=83=86=E3=82=B4?= =?UTF-8?q?=E3=83=AA=E3=80=8D=E3=81=AB=E6=94=B9=E5=90=8D=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 設計がカテゴリの可視性修飾に落ちた時点で、実体はカテゴリであり 「横断概念」という機構名は旧設計（宣言行方式）の残骸だった。機構名を 実体に合わせて「横断カテゴリ」に統一し、マーカーも cross-concept から cross-category に変更する。「概念」という語は、カテゴリが表す状態・属性を 説明する文脈にのみ残す（判定テストの対象は状態・属性のまま）。 - ガイドの章名を「横断カテゴリとは何か」に変更し、定義文を「状態・属性 （横断的な概念）を表す public なカテゴリ」に修正 - 判定テスト名を「横断カテゴリにすべきか」に変更 - ID の呼称を「横断カテゴリの ID」に統一 - guide / example / harae_guide / BRDD / CHANGELOG / 各 SKILL.md の 用語とマーカーを一括更新 Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_019MrZz6XvUK3g1xUVTnGnRH --- CHANGELOG.md | 8 ++-- business_rules_driven_development.md | 16 +++---- ofuda/VERSION | 2 +- ofuda/examples/business_rules.md | 8 ++-- ofuda/guides/business_rules_guide.md | 48 +++++++++---------- ofuda/guides/harae_guide.md | 2 +- skills/miko.catchup/SKILL.md | 2 +- skills/miko.miko/SKILL.md | 8 ++-- skills/miko.new-cap/SKILL.md | 12 ++--- skills/miko.propose/SKILL.md | 4 +- .../guides/cross_capability_impact_guide.md | 22 ++++----- skills/miko.quick-catchup/SKILL.md | 2 +- skills/miko.quick-impl/SKILL.md | 2 +- skills/miko.speckit.implement/SKILL.md | 2 +- 14 files changed, 69 insertions(+), 69 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 26cc531..bf63961 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,13 +4,13 @@ ### New -- **横断概念（cross-cutting concept）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。BR の階層（ケイパビリティ / カテゴリ / ルール）を（パッケージ / モジュール / 関数）と見立て、横断概念を**カテゴリの可視性修飾**として表現する: オーナーは概念のカテゴリ見出しに `[横断]` マークと `` マーカーを付けて public 化し（lead 文が宣言文、定義はカテゴリ内の通常ルール）、効果を持つケイパビリティは自分のルールに `[xc:{cap}/{プレフィックス}]` タグを付けて参照する（import に相当）。非適用は記録しない。一覧は `grep 'cross-concept' miko/*/business_rules.md`、特定概念の全体像（宣言 + 全適用ルール）は ID の grep で都度導出し、中央レジストリは持たない。public カテゴリの改名・分割・マーク変更は proposal 必須（private カテゴリの再編は従来どおり自由）。網羅性は記録や事後監査ではなく **プロセスの門で構成的に保証する** — ケイパビリティ × 概念の全ペアは、概念の宣言（propose の影響調査）かケイパビリティの新規作成（new-cap の判定ステップ）の遅い方で必ず一度検討される。判定テスト（他者性・全称性・必達性）、ID・マーク・タグの書式、書き込み時 lint（orphan 参照・マーク整合・書式）を `business_rules_guide.md` の「横断概念とは何か」に定義。`.miko/examples/business_rules.md` に実例（横断カテゴリ `xc:order_management/DEFAULT` とタグ付きルール ORD-05）を追加。検討経緯と却下した代替案（中央レジストリ・ルール単位マーク・適合セクション・非適用の記録・グローバル連番 ID・専用セクション + 宣言行・harae での網羅監査）は `business_rules_driven_development.md` の「解決済みの論点」を参照 +- **横断カテゴリ（cross-cutting category）を導入** — 複数ケイパビリティに効果が及ぶルール（例: 規約違反ユーザーの発信制限）を管理する仕組み。BR の階層（ケイパビリティ / カテゴリ / ルール）を（パッケージ / モジュール / 関数）と見立て、横断カテゴリを**カテゴリの可視性修飾**として表現する: オーナーは概念のカテゴリ見出しに `[横断]` マークと `` マーカーを付けて public 化し（lead 文が宣言文、定義はカテゴリ内の通常ルール）、効果を持つケイパビリティは自分のルールに `[xc:{cap}/{プレフィックス}]` タグを付けて参照する（import に相当）。非適用は記録しない。一覧は `grep 'cross-category' miko/*/business_rules.md`、特定概念の全体像（宣言 + 全適用ルール）は ID の grep で都度導出し、中央レジストリは持たない。public カテゴリの改名・分割・マーク変更は proposal 必須（private カテゴリの再編は従来どおり自由）。網羅性は記録や事後監査ではなく **プロセスの門で構成的に保証する** — ケイパビリティ × 概念の全ペアは、概念の宣言（propose の影響調査）かケイパビリティの新規作成（new-cap の判定ステップ）の遅い方で必ず一度検討される。判定テスト（他者性・全称性・必達性）、ID・マーク・タグの書式、書き込み時 lint（orphan 参照・マーク整合・書式）を `business_rules_guide.md` の「横断カテゴリとは何か」に定義。`.miko/examples/business_rules.md` に実例（横断カテゴリ `xc:order_management/DEFAULT` とタグ付きルール 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 の重複・宣言行とタグの書式）を実行する +- **`/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:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）を実行する ## v1.4.2 (2026-07-28) diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index 1f62425..7356430 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -268,7 +268,7 @@ proposal に代替案を追記（AI：重要な検討経緯があれば） - **ビジネスポリシー（ビジネス方針）**: `POL-{連番}` 形式。ケイパビリティを貫く価値判断。3〜5 個程度を目安に少数に保つ。セクション末尾に `` で最終採番を記録する - **2.1 ドメインビジネスルール / 2.2 システムビジネスルール**: ルールを「紙運用」テストで振り分けて配置する。カテゴリ（ORD、PAY 等）はどちらか一方に置く -- **横断概念**: 専用セクションは持たない。オーナーがカタログ内のカテゴリに `[横断]` マークを付けて宣言する（カテゴリ＝モジュール、横断＝可視性）。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断概念とは何か」を参照 +- **横断カテゴリ**: 専用セクションは持たない。オーナーがカタログ内のカテゴリに `[横断]` マークを付けて宣言する（カテゴリ＝モジュール、横断＝可視性）。詳細は「解決済みの論点 > 横断的なビジネスルールの管理」と `ofuda/guides/business_rules_guide.md` の「横断カテゴリとは何か」を参照 ### 操作の定義（Operations） @@ -380,27 +380,27 @@ miko//proposals/ ## 解決済みの論点 -### 横断的なビジネスルールの管理（横断概念） +### 横断的なビジネスルールの管理（横断カテゴリ） -**決定（v1.5.0〜）:** 複数ケイパビリティに効果が及ぶルール（例: 「規約違反ユーザーは各所で発信系の操作が制限される」）は、**横断概念**という一級市民の仕組みで管理する。 +**決定（v1.5.0〜）:** 複数ケイパビリティに効果が及ぶルール（例: 「規約違反ユーザーは各所で発信系の操作が制限される」）は、**横断カテゴリ**という一級市民の仕組みで管理する。 **構造:** - **横断しているのはルール（文）ではなく概念（名詞）。** ルールは書き方次第で分割・統合される不安定な単位のため、義務は概念に付ける。横断なのはエンティティ（ユーザー）ではなく状態（規約違反）である - **カテゴリ＝モジュール、横断＝可視性。** BR の階層（ケイパビリティ / カテゴリ / ルール）は（パッケージ / モジュール / 関数）に対応する。カテゴリは既定で private（オーナーが自由に再編できる整理棚）だが、`[横断]` マークで public モジュールになり、名前が公開 API になる。共有の実体は関数（ルール）だが、思考と契約の単位はモジュール（カテゴリ）— という プログラミングの直感に合わせる。可視性 ≠ 義務（義務の根拠は判定テストを通った宣言文）であり、将来「特定ケイパビリティにのみ公開」等が必要になれば別のマークを立てる -- **判定テスト（3 問すべて Yes で横断概念）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか +- **判定テスト（3 問すべて Yes で横断カテゴリ）:** ①他者性 — 他ケイパビリティが所有する操作の可否・意味を変えるか ②全称性 — 義務の相手を列挙できないか（将来のケイパビリティも対象か。列挙できる二者間依存は境界セクションで足りる） ③必達性 — 新しいケイパビリティを作る人に必ず伝えることか - **概念 ID:** `xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}`（例: `xc:user_management/TOS`）。ID がオーナー BR へのポインタを兼ねる。プレフィックスは既存機構の再利用で、新しい採番・命名はない -- **宣言（オーナーのみ）:** 概念のカテゴリ見出しに `[横断]` マーク + `` マーカーを付け、lead 文に宣言文（各ケイパビリティが何を表明すべきかの軸）を書く。定義はカテゴリ内の通常ルール。定義が既存カテゴリに埋まっている場合は public 化の時点でカテゴリを切り出す。マークの付与・除去・横断カテゴリの改名は proposal 必須（横断プロポーザル）。private カテゴリの再編は従来どおり自由 +- **宣言（オーナーのみ）:** 概念のカテゴリ見出しに `[横断]` マーク + `` マーカーを付け、lead 文に宣言文（各ケイパビリティが何を表明すべきかの軸）を書く。定義はカテゴリ内の通常ルール。定義が既存カテゴリに埋まっている場合は public 化の時点でカテゴリを切り出す。マークの付与・除去・横断カテゴリの改名は proposal 必須（横断プロポーザル）。private カテゴリの再編は従来どおり自由 - **適用（効果を持つケイパビリティ）:** 効果を担うルールに `[xc:…]` タグを付ける（import に相当。置き場は自分のカテゴリでよく、オーナーの分類法を持ち込まない）。「概念に誰が応えているか」は ID の grep で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される） - **非適用は書かない。** 「検討したが効果を持たない」の記録は持たない（propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すのみ） -- **一覧は grep で導出:** `grep -n 'cross-concept' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する +- **一覧は grep で導出:** `grep -n 'cross-category' miko/*/business_rules.md`。中央レジストリファイルは持たない（本体と索引の二重管理によるズレを避ける）。機構自体は guide とスキル手順（miko 本体、upgrade で配布・復元される）が所有する **網羅性は記録ではなくプロセスの門で保証する（構成的保証）:** ケイパビリティ × 概念のすべての組は、どちらか遅い方の誕生イベントで必ず一度検討される。 1. **門 1 — propose の他ケイパビリティ影響調査（必須化）:** 概念の宣言・変更は横断プロポーザルになり、影響調査が全ケイパビリティに判定を下す。調査は昇格候補（未宣言の横断関係）の発見も担う -2. **門 2 — new-cap の横断概念判定ステップ（新設）:** 新規ケイパビリティ作成時に宣言を grep し、各概念について対話で判定する。適用なら `[xc:…]` タグ付きルールを作る +2. **門 2 — new-cap の横断カテゴリ判定ステップ（新設）:** 新規ケイパビリティ作成時に宣言を grep し、各概念について対話で判定する。適用なら `[xc:…]` タグ付きルールを作る -加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）を実行する。harae に横断概念の必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。 +加えて、BR を更新するスキルは更新直後に **書き込み時 lint**（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）を実行する。harae に横断カテゴリの必須ステップは持たせない — harae は完成したはずのルール体系を攻撃的に疑う事後の監査であり、必ず通るべき門をそこに置くと保証にならないため（不完全性軸の攻撃観点の一つとして残るのみ）。 **既存 BR への遡及なし:** `[横断]` マークとタグは概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。マイグレーション不要。 diff --git a/ofuda/VERSION b/ofuda/VERSION index 2c166a9..7e45753 100644 --- a/ofuda/VERSION +++ b/ofuda/VERSION @@ -1,2 +1,2 @@ 1.5.0 -202609070617 +202609070637 diff --git a/ofuda/examples/business_rules.md b/ofuda/examples/business_rules.md index 85ec303..0533e9e 100644 --- a/ofuda/examples/business_rules.md +++ b/ofuda/examples/business_rules.md @@ -95,7 +95,7 @@ stateDiagram-v2 - **ORD-05** [制約][xc:order_management/DEFAULT] 支払い不履行ユーザーが同時に持てる未決済の注文は 1 件までとする。決済済みの注文には影響しない。 - @@ -135,14 +135,14 @@ stateDiagram-v2 --- -#### 支払い不履行ユーザー（DEFAULT）[横断] +#### 支払い不履行ユーザー（DEFAULT）[横断] 未決済の自動キャンセルを繰り返したユーザー。 各ケイパビリティは、与信が発生する操作（後払い・予約・取り置き等）の制限を表明すること。 - diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 76e6353..1096af2 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -325,27 +325,27 @@ high_level_design.md（AI が更新：構造の変化） --- -## 横断概念とは何か +## 横断カテゴリとは何か -**横断概念とは、他ケイパビリティが所有する操作の可否や意味を変える状態・属性のことである。** 「規約違反ユーザー」「凍結テナント」のように、1 つのケイパビリティが定義するが、効果はシステム全体に及ぶ。 +**横断カテゴリとは、他ケイパビリティが所有する操作の可否や意味を変える状態・属性（横断的な概念）を表す public なカテゴリである。** 「規約違反ユーザー」「凍結テナント」のように、状態の定義は 1 つのケイパビリティが持つが、効果はシステム全体に及ぶ。 -横断概念は、**まだ存在しないケイパビリティも含めた全ケイパビリティ**に「この概念にどう向き合うか」の検討を義務づける。義務をルール（文）ではなく概念（名詞）に付けるのは、ルールは書き方次第で分割・統合される不安定な単位である一方、概念は言い回しで増減しないためである。 +横断カテゴリは、**まだ存在しないケイパビリティも含めた全ケイパビリティ**に「この状態にどう向き合うか」の検討を義務づける。義務をルール（文）ではなくカテゴリ（が表す概念）に付けるのは、ルールは書き方次第で分割・統合される不安定な単位である一方、概念は言い回しで増減しないためである。 -### 判定テスト: 横断概念か +### 判定テスト: 横断カテゴリにすべきか -候補が横断概念かどうかは、以下の 3 問で判定する。**すべて Yes のときだけ**横断概念として宣言する。 +候補の状態・属性を横断カテゴリとして public 化すべきかは、以下の 3 問で判定する。**すべて Yes のときだけ**横断カテゴリにする。 1. **他者性**: その状態・属性は、**他ケイパビリティが所有する操作**の可否や意味を変えるか？ 自ケイパビリティの操作しか変えないなら No（例: 注文の「出荷済み」はキャンセル可否を変えるが、それは注文管理自身の操作 → No） 2. **全称性**: 義務の相手を列挙できないか？ 特定の 2〜3 ケイパビリティ間の話なら、境界セクションとルールの相互参照で足りる（No）。**将来作られるケイパビリティも対象**になるものだけが Yes 3. **必達性**: 新しいケイパビリティを作る人に、中身を聞く前に必ず伝えるべきことか？ -**数の目安**: 横断概念はシステム全体で数個に収まるはずである（例: 規約違反ユーザー、テナント分離、料金プランによる機能制限、退会ユーザーのデータ保持）。10 個に近づいたら、判定テストの運用が緩んでいるか、ドメイン設計自体の問題（神概念の存在）を疑う。 +**数の目安**: 横断カテゴリはシステム全体で数個に収まるはずである（例: 規約違反ユーザー、テナント分離、料金プランによる機能制限、退会ユーザーのデータ保持）。10 個に近づいたら、判定テストの運用が緩んでいるか、ドメイン設計自体の問題（神概念の存在）を疑う。 **横断なのはエンティティではなく状態である。** 「ユーザー」という概念全体が横断なのではない。「規約違反」という特定の状態だけが横断であり、「メール確認済み」「最終ログイン日時」はオーナーに閉じる。 ### カテゴリ＝モジュール、横断＝可視性 -BR の階層（ケイパビリティ / カテゴリ / ルール）は、プログラミングの（パッケージ / モジュール / 関数）に対応する。横断概念はこの見立ての上の**可視性修飾**である: カテゴリは既定で private（オーナーの整理棚。自由に分割・改名・統合してよい）だが、`[横断]` マークを付けたカテゴリは **public モジュール**になり、その名前（プレフィックス）は他ケイパビリティから参照される公開 API になる。 +BR の階層（ケイパビリティ / カテゴリ / ルール）は、プログラミングの（パッケージ / モジュール / 関数）に対応する。横断カテゴリはこの見立ての上の**可視性修飾**である: カテゴリは既定で private（オーナーの整理棚。自由に分割・改名・統合してよい）だが、`[横断]` マークを付けたカテゴリは **public モジュール**になり、その名前（プレフィックス）は他ケイパビリティから参照される公開 API になる。 - public にしたカテゴリの改名・分割・除去は契約変更であり、proposal 必須（横断プロポーザル）。private カテゴリの再編は従来どおり自由 - 概念の定義ルールが既存カテゴリの中に埋まっている場合は、public 化の時点で概念のカテゴリとして**切り出す**（関数を公開したくなったらモジュールを抽出するのと同じ。凝集を強制する良い圧である） @@ -355,16 +355,16 @@ BR の階層（ケイパビリティ / カテゴリ / ルール）は、プロ | 何を | どこに書くか | |---|---| -| 横断概念の宣言（義務の発生源・判断の軸） | オーナーの BR の横断カテゴリ（`[横断]` マーク + lead 文） | +| 横断カテゴリの宣言（義務の発生源・判断の軸） | オーナーの BR の横断カテゴリ（`[横断]` マーク + lead 文） | | 概念の定義（誰がその状態になるか・解除条件） | 横断カテゴリ内の通常ルール（[導出] / [制約]） | | 各ケイパビリティでの具体的な効果 | 効果を持つケイパビリティの通常ルール（`[xc:…]` タグ付き。置き場はそのケイパビリティ自身のカテゴリ） | | 非適用（効果を持たない判断） | **書かない**（後述） | 効果を各ケイパビリティに書くのは、「チャットでは発言不可・いいねは可」のような線引きが**そのケイパビリティのドメインで下した判断**（「却下した代替案」テストが働く場所）だからである。オーナーには判断の軸（宣言文）だけを書き、他ケイパビリティの操作は列挙しない。オーナーの分類法（カテゴリ名）を消費側に強制しない — 消費側のルールは自分のドメインのカテゴリに置き、タグで参照する。 -### 概念 ID +### 横断カテゴリの ID -横断概念の ID は `xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}` 形式である。 +横断カテゴリの ID は `xc:{ケイパビリティディレクトリ名}/{カテゴリプレフィックス}` 形式である。 - ケイパビリティ部は `miko/` 配下のディレクトリ名をそのまま使う。ID がオーナーの BR ファイルへのポインタを兼ねる - プレフィックス部は横断カテゴリの英字プレフィックスそのもの（例: `xc:user_management/TOS`）。新しい命名機構は導入しない @@ -372,10 +372,10 @@ BR の階層（ケイパビリティ / カテゴリ / ルール）は、プロ ### 宣言の書き方（オーナーの BR の横断カテゴリ） -概念のカテゴリ見出しに `[横断]` マークと機械マーカー `` を付け、lead 文として宣言文（モジュールの docstring に相当）を書く。定義ルールはカテゴリ内の通常ルール。 +概念のカテゴリ見出しに `[横断]` マークと機械マーカー `` を付け、lead 文として宣言文（モジュールの docstring に相当）を書く。定義ルールはカテゴリ内の通常ルール。 ```markdown -#### 規約違反ユーザー（TOS）[横断] +#### 規約違反ユーザー（TOS）[横断] 規約違反が確定したが、ビジネス上 BAN はできないユーザー。 各ケイパビリティは、ユーザーが発信する操作への制限を表明すること。 @@ -386,17 +386,17 @@ BR の階層（ケイパビリティ / カテゴリ / ルール）は、プロ ``` - 宣言文には、概念の説明と「各ケイパビリティが何を表明すべきか」の軸を書く。個別ケイパビリティの操作名は列挙しない -- マーカー `` は横断カテゴリの見出し行以外に書かない。**システム全体の横断概念一覧はこの grep で都度導出する**（中央のレジストリファイルは持たない）: +- マーカー `` は横断カテゴリの見出し行以外に書かない。**システム全体の横断カテゴリ一覧はこの grep で都度導出する**（中央のレジストリファイルは持たない）: ```bash -grep -n 'cross-concept' miko/*/business_rules.md +grep -n 'cross-category' miko/*/business_rules.md ``` - **`[横断]` マークの付与・除去、横断カテゴリの改名・分割は proposal 必須。** 全ケイパビリティに検討の義務を課す（または契約を変える）変更であり、横断プロポーザル（``）として全ケイパビリティへの影響を扱う ### 適用の書き方（効果を持つケイパビリティのルール） -横断概念の効果を担うルールは、タグ位置に概念 ID を付ける（モジュールの import に相当）。 +横断カテゴリの効果を担うルールは、タグ位置に横断カテゴリの ID を付ける（モジュールの import に相当）。 ```markdown - **ORD-05** [制約][xc:user_management/TOS] 規約違反ユーザーは注文コメントを投稿できない。 @@ -405,17 +405,17 @@ grep -n 'cross-concept' miko/*/business_rules.md - ルール本文は通常どおりビジネス語彙（日本語の用語）で書く。タグが機械可読なリンクを担う - **オーナー自身が自分の概念の効果ルールを持つ場合も、同じタグを付ける**（grep の結果が効果の全量になる）。定義ルール（[導出] で状態を定義するもの）にはタグ不要 — 横断カテゴリへの包含が定義であることを表す - 「この概念にどのケイパビリティのどのルールが応えているか」は `grep -n 'xc:user_management/TOS' miko/*/business_rules.md` で都度導出する（宣言 + 全適用ルールが 1 コマンドで列挙される）。オーナーは消費者の一覧を持たない -- **横断概念への依存は境界セクションに書かない**（タグが唯一の置き場。二重管理を避ける） +- **横断カテゴリへの依存は境界セクションに書かない**（タグが唯一の置き場。二重管理を避ける） ### 非適用は書かない -「検討したが効果を持たない」判断は、どこにも記録しない。網羅性は記録ではなく**プロセスの門**で保証する。ケイパビリティ × 概念のすべての組は、概念の宣言（propose の影響調査が全ケイパビリティに判定を下す）か、ケイパビリティの新規作成（new-cap の横断概念判定ステップ）の、どちらか遅い方のイベントで必ず一度検討される。propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すため、痕跡はそこにある。 +「検討したが効果を持たない」判断は、どこにも記録しない。網羅性は記録ではなく**プロセスの門**で保証する。ケイパビリティ × 概念のすべての組は、概念の宣言（propose の影響調査が全ケイパビリティに判定を下す）か、ケイパビリティの新規作成（new-cap の横断カテゴリ判定ステップ）の、どちらか遅い方のイベントで必ず一度検討される。propose の影響調査が「調査したケイパビリティの一覧」を proposal に残すため、痕跡はそこにある。 ### 書き込み時の検査（lint） business_rules.md を更新するスキルは、更新の直後に以下を機械的に検査し、問題があれば修正する（できなければユーザーに報告する）: -1. **orphan 参照**: `xc:` 参照のうち、対応する横断カテゴリ（`[横断]` + `` 付き見出し）が存在しないもの +1. **orphan 参照**: `xc:` 参照のうち、対応する横断カテゴリ（`[横断]` + `` 付き見出し）が存在しないもの 2. **マークの整合**: `[横断]` マークと見出し行のマーカーが片方だけになっていないか。同じ ID の横断カテゴリが複数存在しないか 3. **書式**: 横断カテゴリの見出しが「業務用語（プレフィックス）[横断] マーカー」の形式か、lead 文（宣言文）があるか。タグが `[制約]/[導出]` の直後に置かれているか @@ -436,7 +436,7 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 ## 3. 関連ケイパビリティとの境界 ``` -**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。横断概念の仕組みも既存 BR に遡及しない — `[横断]` マークや `[xc:…]` タグは、概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。 +**既存 BR の扱い:** この構造は新規ケイパビリティ向け。既存の `business_rules.md` は、ユーザーから明示的な移行依頼がない限り、**ファイル構造**（ポリシーセクションの新設、2.1/2.2 への分割、等）と **proposal が触らない既存ルールの本文**には手を入れない（文字数・語彙規律など現在基準への合わせ込みも行わない）。proposal で **改訂・新設するルール** には現在基準を適用する（既存ファイルの構造は踏襲したまま、改訂後の本文・新規ルールの本文だけが新基準に従う）。横断カテゴリの仕組みも既存 BR に遡及しない — `[横断]` マークや `[xc:…]` タグは、概念に関わる変更（proposal / new-cap）が入ったときに初めて現れる。 ### 各セクションの指針 @@ -465,9 +465,9 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 **ビジネスルール・カタログ**: `### 2.1 ドメインビジネスルール`（紙の運用でも成り立つもの）と `### 2.2 システムビジネスルール`（システム前提のもの）の 2 セクションに分けて配置する。同一カテゴリ（ORD、PAY 等）はどちらか一方に置く。ドメインとシステムが混じるカテゴリはカテゴリの分割を検討する。詳細は前述の「ドメインビジネスルール / システムビジネスルールの区別」と、後述の「ビジネスルール・カタログの書き方」を参照。 -**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断概念にしない）。逆に、**横断概念への依存は境界には書かない**（ルールの `[xc:…]` タグが唯一の置き場。二重管理を避ける）。 +**境界**: 他のケイパビリティとのビジネス上の責務分担。「借りているもの」「渡しているもの」「境界の注意点」の3軸。このケイパビリティの責務がどこまでかを明確にする。相手を列挙できる二者間の依存はここで扱う（横断カテゴリにしない）。逆に、**横断カテゴリへの依存は境界には書かない**（ルールの `[xc:…]` タグが唯一の置き場。二重管理を避ける）。 -横断概念に専用セクションはない — 宣言はカタログ内の横断カテゴリ（`[横断]` マーク）として表現する。詳細は前述の「横断概念とは何か」を参照。 +横断カテゴリに専用セクションはない — 宣言はカタログ内の横断カテゴリ（`[横断]` マーク）として表現する。詳細は前述の「横断カテゴリとは何か」を参照。 > **注意:** アーキテクチャ上の決定事項（ADR）は business_rules.md には書かない。技術選択の「決定・意図・トレードオフ」は high_level_design.md の「設計上の特徴」セクションに記載する。 @@ -484,7 +484,7 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 ### スレッド管理（THREAD） ``` -カテゴリは既定で private（自由に分割・改名・統合してよいオーナーの整理単位）。横断概念のカテゴリだけは `[横断]` マークで public になり、改名等が契約変更になる（「横断概念とは何か」参照）。 +カテゴリは既定で private（自由に分割・改名・統合してよいオーナーの整理単位）。横断カテゴリのカテゴリだけは `[横断]` マークで public になり、改名等が契約変更になる（「横断カテゴリとは何か」参照）。 ### ルールID @@ -550,7 +550,7 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 6. 各ルール候補に「紙運用」テストを適用し、ドメインビジネスルール（2.1）とシステムビジネスルール（2.2）に振り分ける。1 ルール内に両方が混在している場合は分解する 7. 実装マッピングを `
` 内に記載する 8. コードに暗黙的に埋め込まれているが明文化されていないルール・ポリシーがあれば「暗黙のルール（要確認）」として末尾に列挙する -9. `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、コードから概念の効果（制限等）を実装しているルールが見つかった場合は、そのルールに `[xc:…]` タグを付ける（前述「適用の書き方」参照） +9. `grep -n 'cross-category' miko/*/business_rules.md` で宣言済みの横断カテゴリを列挙し、コードから概念の効果（制限等）を実装しているルールが見つかった場合は、そのルールに `[xc:…]` タグを付ける（前述「適用の書き方」参照） ### モード B: 提案から生成する場合 * 提案には、ビジネスルールではない詳細な仕様が書かれることがあるが、それはビジネスルールには記載しない。 @@ -561,4 +561,4 @@ business_rules.md を更新するスキルは、更新の直後に以下を機 4. ルール候補に「紙運用」テストを適用し、ドメインビジネスルール（2.1）とシステムビジネスルール（2.2）に振り分ける 5. 提案に明示されていないが論理的に必要なルール・ポリシーを推論し「暗黙のルール（要確認）」として末尾に列挙する 6. 提案に技術選択が含まれる場合、high_level_design.md の「設計上の特徴」への追記を検討する -7. 提案に含まれる状態・属性に「判定テスト: 横断概念か」を適用し、満たすものは横断概念の昇格候補としてユーザーに提示する（宣言は proposal を通す） +7. 提案に含まれる状態・属性に「判定テスト: 横断カテゴリにすべきか」を適用し、満たすものは横断カテゴリの昇格候補としてユーザーに提示する（宣言は proposal を通す） diff --git a/ofuda/guides/harae_guide.md b/ofuda/guides/harae_guide.md index a5f3cc1..936ca2f 100644 --- a/ofuda/guides/harae_guide.md +++ b/ofuda/guides/harae_guide.md @@ -109,7 +109,7 @@ business_rules.md の「操作の定義」から全操作を、「状態遷移 「関連ケイパビリティとの境界」を確認し、境界で「借りているもの」「渡しているもの」それぞれについて、失敗時や遅延時のルールが定義されているか確認する。 -あわせて横断概念も見る: `grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙し、対象ケイパビリティの操作に関係しそうな概念なのに `[xc:…]` タグ付きルールが 1 本もない場合は、対応漏れの可能性として指摘する（関係するかどうかは操作の内容から推論する。網羅の義務チェックではなく攻撃の観点として扱う）。 +あわせて横断カテゴリも見る: `grep -n 'cross-category' miko/*/business_rules.md` で宣言済みの横断カテゴリを列挙し、対象ケイパビリティの操作に関係しそうな概念なのに `[xc:…]` タグ付きルールが 1 本もない場合は、対応漏れの可能性として指摘する（関係するかどうかは操作の内容から推論する。網羅の義務チェックではなく攻撃の観点として扱う）。 > 例: 在庫管理との境界で「在庫引き当てにはタイムアウトがある」「バッチによる自動キャンセルまで引き当てが残り続ける」と記述されている。在庫引き当てがタイムアウトした場合（在庫管理側でタイムアウト解放、注文管理側ではまだ confirmed）、注文側のステータスはどうなるか？ この状態不整合を扱うルールがない。 diff --git a/skills/miko.catchup/SKILL.md b/skills/miko.catchup/SKILL.md index fe31bbc..fdd9415 100644 --- a/skills/miko.catchup/SKILL.md +++ b/skills/miko.catchup/SKILL.md @@ -161,7 +161,7 @@ $ARGUMENTS - 承認された削除 - 実装マッピング - 操作の定義（コードから新しい操作が見つかった場合） -- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものは主さまに報告する +- **横断カテゴリの書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものは主さまに報告する **glossary.md の更新:** - proposal で新しい用語が登場した場合は `miko/glossary.md` に追加する（ファイルがなければ作成） diff --git a/skills/miko.miko/SKILL.md b/skills/miko.miko/SKILL.md index a580e96..d2133dd 100644 --- a/skills/miko.miko/SKILL.md +++ b/skills/miko.miko/SKILL.md @@ -169,11 +169,11 @@ miko の実装フローでは **constitution**（`.specify/memory/constitution.m 5. **「用語の定義はどこに書く？」** - すべて `miko/glossary.md` に定義する（BR には用語集セクションを持たない） -6. **「複数のケイパビリティに効くルールはどこに書く？」「これって横断概念？」** - - `business_rules_guide.md` の「判定テスト: 横断概念か」（他者性・全称性・必達性）を一緒に適用する +6. **「複数のケイパビリティに効くルールはどこに書く？」「これって横断カテゴリ？」** + - `business_rules_guide.md` の「判定テスト: 横断カテゴリにすべきか」（他者性・全称性・必達性）を一緒に適用する - 3 問すべて Yes → オーナーの BR で概念のカテゴリに `[横断]` マークを付ける（`/miko.propose` 経由）。効果は各ケイパビリティのルールに `[xc:…]` タグ付きで書く - - 相手を列挙できる二者間の依存 → 境界セクションで足りる（横断概念にしない） - - 現在の宣言一覧は `grep -n 'cross-concept' miko/*/business_rules.md`、特定の概念の全体像（宣言 + 適用ルール）は `grep -n 'xc:{cap}/{プレフィックス}' miko/*/business_rules.md` で提示する + - 相手を列挙できる二者間の依存 → 境界セクションで足りる（横断カテゴリにしない） + - 現在の宣言一覧は `grep -n 'cross-category' miko/*/business_rules.md`、特定の概念の全体像（宣言 + 適用ルール）は `grep -n 'xc:{cap}/{プレフィックス}' miko/*/business_rules.md` で提示する 7. **「constitution に何を書けばいい？」「CLAUDE.md に書くのと何が違う？」** - 実装フローで毎回守ってほしいプロジェクト固有のルール → constitution diff --git a/skills/miko.new-cap/SKILL.md b/skills/miko.new-cap/SKILL.md index 43f708f..daac4b7 100644 --- a/skills/miko.new-cap/SKILL.md +++ b/skills/miko.new-cap/SKILL.md @@ -153,16 +153,16 @@ $ARGUMENTS 発見された問題は、ステップ 9 の確認②に「既存 BR との整合性」セクションを追加して報告する。 -**6c. 横断概念の判定（必須）** +**6c. 横断カテゴリの判定（必須）** -`grep -n 'cross-concept' miko/*/business_rules.md` で宣言済みの横断概念を列挙する。ヒットが 1 件もなければこのステップをスキップする。 +`grep -n 'cross-category' miko/*/business_rules.md` で宣言済みの横断カテゴリを列挙する。ヒットが 1 件もなければこのステップをスキップする。 ヒットした各概念について: 1. 横断カテゴリ（見出しの業務用語・`xc:` ID・lead 文の宣言文）を読む。判定に必要なら、オーナー BR からそのカテゴリの定義ルールだけを読む（BR ファイル全体は読まない） -2. ユーザーに確認する（例: 「ユーザー管理が横断概念『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） +2. ユーザーに確認する（例: 「ユーザー管理が横断カテゴリ『規約違反ユーザー』を宣言しております。このケイパビリティにはユーザーが発信する操作はございますか？ 制限は必要でしょうか？」） 3. 効果を持つと判定された概念について、効果を表すルールをルール候補に加える（生成時に `[xc:…]` タグを付ける）。効果を持たない概念については何も書かない（この対話で検討したこと自体が保証であり、非適用の記録は持たない） -ヒアリングやコード調査で、新ケイパビリティ自身が横断概念（`.miko/guides/business_rules_guide.md` の「判定テスト: 横断概念か」を満たす状態）を持ちそうな場合は、この場では宣言せず**昇格候補**として記録し、ステップ 12 の完了報告で `/miko.propose` を案内する（宣言は全ケイパビリティに義務を課すため proposal を通す）。 +ヒアリングやコード調査で、新ケイパビリティ自身が横断カテゴリ（`.miko/guides/business_rules_guide.md` の「判定テスト: 横断カテゴリにすべきか」を満たす状態）を持ちそうな場合は、この場では宣言せず**昇格候補**として記録し、ステップ 12 の完了報告で `/miko.propose` を案内する（宣言は全ケイパビリティに義務を課すため proposal を通す）。 ### 7. ルール策定・構造化 @@ -232,7 +232,7 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を - 実装マッピング: - 既存コードがある場合: `
` 内に記載 - 未実装の場合: `
` 内に `（未実装）` マーク付きで記載 -- **横断概念**（ガイドの「横断概念とは何か」参照）: +- **横断カテゴリ**（ガイドの「横断カテゴリとは何か」参照）: - ステップ 6c で効果を持つと判定した概念のルールに `[xc:…]` タグを付ける - `[横断]` マーク付きカテゴリは作らない（横断カテゴリの新設は proposal を通すため、new-cap では昇格候補の案内まで） - 生成後、ガイドの「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・タグの書式） @@ -272,4 +272,4 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を ### 12. 完了報告 -生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数、横断概念の判定結果（検討した概念数と、効果を持つと判定した概念 → 対応ルール）をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。ステップ 6c で横断概念の昇格候補を記録した場合は提示し、`/miko.propose` による宣言を案内する。 +生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数、横断カテゴリの判定結果（検討した概念数と、効果を持つと判定した概念 → 対応ルール）をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。ステップ 6c で横断カテゴリの昇格候補を記録した場合は提示し、`/miko.propose` による宣言を案内する。 diff --git a/skills/miko.propose/SKILL.md b/skills/miko.propose/SKILL.md index eba8c83..c28833f 100644 --- a/skills/miko.propose/SKILL.md +++ b/skills/miko.propose/SKILL.md @@ -165,9 +165,9 @@ $ARGUMENTS **調査結果の扱い:** - 影響なし: 「他ケイパビリティへの影響はございませんでした」と報告し、ステップ 10 へ進む - 影響あり: 結果をユーザーに提示し、内容を確認・修正してもらう。確認後にステップ 10 でプロポーザルの「他ケイパビリティへの影響」セクションに反映し、**プロポーザルの先頭に `` マーカーを付与する**（このマーカーがないと実装対象プロポーザルとして扱われてしまうため） -- 横断概念の昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「概念のカテゴリへの `[横断]` マーク付与（定義ルールが既存カテゴリに埋まっている場合はカテゴリの切り出しを含む）」を含め、影響先ケイパビリティの `[xc:…]` タグ付きルールの新設・改訂を「他ケイパビリティへの影響」に反映して `` を付与する +- 横断カテゴリの昇格候補が報告された場合: ユーザーに提示し、宣言するか確認する。宣言する場合はビジネスルールの変更に「概念のカテゴリへの `[横断]` マーク付与（定義ルールが既存カテゴリに埋まっている場合はカテゴリの切り出しを含む）」を含め、影響先ケイパビリティの `[xc:…]` タグ付きルールの新設・改訂を「他ケイパビリティへの影響」に反映して `` を付与する -**横断プロポーザルになる典型:** 変更が横断概念の宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念を `[xc:…]` タグで参照している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 +**横断プロポーザルになる典型:** 変更が横断カテゴリの宣言・定義に触れる場合（新規宣言・宣言文の変更・除去・定義ルールの改訂）は、その概念を `[xc:…]` タグで参照している全ケイパビリティが影響対象になる（詳細は調査ガイドが扱う）。 ### 10. プロポーザル生成 diff --git a/skills/miko.propose/guides/cross_capability_impact_guide.md b/skills/miko.propose/guides/cross_capability_impact_guide.md index 4bea4b1..09f8a6f 100644 --- a/skills/miko.propose/guides/cross_capability_impact_guide.md +++ b/skills/miko.propose/guides/cross_capability_impact_guide.md @@ -11,16 +11,16 @@ ## 最初に読むファイル 調査を始める前に、以下のファイルを自分で読み込むこと: -- `.miko/guides/business_rules_guide.md` — ルールの判定テスト基準（「横断概念とは何か」を含む） +- `.miko/guides/business_rules_guide.md` — ルールの判定テスト基準（「横断カテゴリとは何か」を含む） - `miko/<メインケイパビリティ>/business_rules.md` — メインケイパビリティの現行ルール - `miko/<メインケイパビリティ>/high_level_design.md` — メインケイパビリティの構造（あれば） - `miko/system_high_level_design.md` — システム全体のアーキテクチャ（あれば） - `miko/glossary.md` — 用語集。ケイパビリティ間で共有される概念の定義を確認する（あれば） -さらに、宣言済みの横断概念を列挙しておく: +さらに、宣言済みの横断カテゴリを列挙しておく: ```bash -grep -n 'cross-concept' miko/*/business_rules.md +grep -n 'cross-category' miko/*/business_rules.md ``` ## 目的 @@ -70,10 +70,10 @@ business_rules.md が存在しないケイパビリティは管理対象外で **廃止が必要なケース:** - 変更案でメインケイパビリティの責務が変わり、このケイパビリティのルールが不要になる -**横断概念に関わるケース:** -- 変更案が宣言済み横断概念の宣言文・定義ルールを変える → その概念の ID（`xc:…`）を grep し、タグで参照している全ルールが影響対象。各ルールの改訂要否を判定する -- 変更案が新しい横断概念の宣言を含む → 全ケイパビリティについて、概念の効果を持つ操作があるかを判定する。効果を持つケイパビリティには `[xc:…]` タグ付きルールの新設を提案する。効果を持たないケイパビリティは報告しない（調査済み一覧に含まれることが検討の痕跡になる） -- 変更案に含まれる状態・属性が「判定テスト: 横断概念か」（business_rules_guide.md）を満たす → 変更案自体は宣言していなくても **昇格候補** として報告する +**横断カテゴリに関わるケース:** +- 変更案が宣言済み横断カテゴリの宣言文・定義ルールを変える → その概念の ID（`xc:…`）を grep し、タグで参照している全ルールが影響対象。各ルールの改訂要否を判定する +- 変更案が新しい横断カテゴリの宣言を含む → 全ケイパビリティについて、概念の効果を持つ操作があるかを判定する。効果を持つケイパビリティには `[xc:…]` タグ付きルールの新設を提案する。効果を持たないケイパビリティは報告しない（調査済み一覧に含まれることが検討の痕跡になる） +- 変更案に含まれる状態・属性が「判定テスト: 横断カテゴリにすべきか」（business_rules_guide.md）を満たす → 変更案自体は宣言していなくても **昇格候補** として報告する ### 3. 影響なしの判定基準 @@ -114,14 +114,14 @@ business_rules.md が存在しないケイパビリティは管理対象外で ``` -横断概念に関わる新設・改訂ルールには、本文の先頭タグに概念 ID を含めて提案する（例: `[制約][xc:user_management/TOS]`）。 +横断カテゴリに関わる新設・改訂ルールには、本文の先頭タグに横断カテゴリの ID を含めて提案する（例: `[制約][xc:user_management/TOS]`）。 -### 横断概念の昇格候補（該当する場合） +### 横断カテゴリの昇格候補（該当する場合） -変更案に含まれる状態・属性が横断概念の判定テストを満たす場合、影響一覧とは別に報告する: +変更案に含まれる状態・属性が横断カテゴリの判定テストを満たす場合、影響一覧とは別に報告する: ``` -### 横断概念の昇格候補 +### 横断カテゴリの昇格候補 - **{概念名}** — {宣言文の案（各ケイパビリティが何を表明すべきかの軸を含む）} - 判定根拠: 他者性 / 全称性 / 必達性 それぞれの理由 diff --git a/skills/miko.quick-catchup/SKILL.md b/skills/miko.quick-catchup/SKILL.md index 7ef6771..681ccf3 100644 --- a/skills/miko.quick-catchup/SKILL.md +++ b/skills/miko.quick-catchup/SKILL.md @@ -115,7 +115,7 @@ diff ソース、変更の要約、ビジネスルールへの影響（新設/ **ステップ 6 で生成した proposal の内容を business_rules.md に反映する。** - proposal の新設・改訂を適用する - 実装マッピングを更新する -- **横断概念の書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 8 末尾の確認で主さまに報告する +- **横断カテゴリの書き込み時検査（lint）** — 更新後、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 8 末尾の確認で主さまに報告する - 新しい用語があれば `miko/glossary.md` に追加する（`.miko/examples/glossary.md` のフォーマットに従う。実装の詳細は書かず、1〜2文の定義だけを書く） - ケイパビリティの節は配置の軸であり、意味のスコープではない。見出し語はシステム全体で一意にする。既存の見出し語と衝突する場合は、同じ意味なら1項目に統合し、別概念なら一意な別名を立てる（注文確定 / 決済確定） diff --git a/skills/miko.quick-impl/SKILL.md b/skills/miko.quick-impl/SKILL.md index cda114f..6b80ab5 100644 --- a/skills/miko.quick-impl/SKILL.md +++ b/skills/miko.quick-impl/SKILL.md @@ -144,7 +144,7 @@ miko の原則として BR ルール本文の変更には proposal が必要。p - proposal がある場合のみ: proposal の新設・改訂・廃止を BR 本文に適用する - proposal がない場合: BR 本文は一切触らない（スコープガード (d) で除外済みのはず） -#### 横断概念の書き込み時検査（lint） +#### 横断カテゴリの書き込み時検査（lint） business_rules.md を更新した場合、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものは主さまに報告する。BR を更新しない実行ではスキップする。 diff --git a/skills/miko.speckit.implement/SKILL.md b/skills/miko.speckit.implement/SKILL.md index d0a7dbc..9848ee5 100644 --- a/skills/miko.speckit.implement/SKILL.md +++ b/skills/miko.speckit.implement/SKILL.md @@ -143,7 +143,7 @@ tasks.md の最終フェーズに到達したら、以下の順序で実行す - 今回の実装で作成・変更したファイルを元に、該当ルールの実装マッピング（`
` 内）を更新する - 既存ルールでも実装場所が変わったものがあれば更新する - **spec.md の Miko コンテキストに複数ケイパビリティのサブプロポーザルが含まれている場合:** 各サブプロポーザルの BR 変更セクションに従って、各ケイパビリティの `miko//business_rules.md` をそれぞれ更新する -- **横断概念の書き込み時検査（lint）:** 更新した各 business_rules.md に対して、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 6 の確認で主さまに報告する +- **横断カテゴリの書き込み時検査（lint）:** 更新した各 business_rules.md に対して、`.miko/guides/business_rules_guide.md` の「書き込み時の検査（lint）」を実行する（orphan `xc:` 参照・`[横断]` マークとマーカーの整合・横断カテゴリとタグの書式）。問題があれば修正し、修正できないものはステップ 6 の確認で主さまに報告する **3. high_level_design.md の更新** - 今回の実装で構造に変更があった場合、`miko//high_level_design.md` を更新する