ellmos-ai/decision-path

decision-path — 保留中の決定のASCII依存関係グラフ

決定は真空の中で発生しません。単独では合理的に見えても、後続の作業を頻繁にブロックしたり、未構築の前提条件を必要としたり、確立された安全ゲートを迂回したりします。decision-pathは、因果関係、実行順序、矛盾をターミナルに透過的に表示します。

---

使用すべき場合

• オープンな決定の既存インベントリ（decision-briefingフェーズ1、セッションコンテキスト、またはチケットマスターの決定ブリーフィングから）を構造化する必要がある場合。
• どの決定が即座にアクション可能か（ルートノード）、どの決定が前提条件や外部ブロッカーに依存しているかを特定する必要がある場合。
• どの推奨事項が調和的に適合し、どの推奨事項が論理的または運用上衝突するかの概要が必要な場合。
• トリガーワード: /decision-path、「どの決定が互いに依存しているか」、「決定依存関係グラフ」、「決定パスを可視化」、「ASCII決定木」、「決定間の矛盾」、「因果依存関係を確認」。
• 使用すべきでない場合:
  • 未解決の質問を最初に発見してインベントリ化する — これはdecision-briefingフェーズ1が行います。
  • 承認のために推奨事項を単一の一貫したコンセプトにまとめる — これはdecision-drawが行います。
  • オプションと各オプションの賛否を含むコンパクトな5部構成ブロックを作成する — これはdecision-shotが行います。
  • フレームワーク（加重スコアリング、シナリオ分析）を使用して単一の複雑な決定を系統的に評価する — これはdecideが行います。

---

決定ファミリーにおける境界

スキル	役割	入力	出力
decide	単一の決定を系統的に構造化	基準、オプション	スコアリングマトリックス、単一決定
decision-briefing	多数のオープン決定を個別の質問に分解	保留中のポイントのリスト	番号付きA/B/C/Dブリーフィング、大まかな依存関係マーカー、バッチ予約
decision-path	多数の決定にわたる因果関係と矛盾を検証および可視化	ブリーフィング/レジスタからの大まかなマーカー	5つのノード評価とエッジステータスを持つASCII依存関係グラフ
decision-draw	承認のために推奨事項を一貫した全体にバンドル	decision-pathからのバンドル	コンセプト、相互作用（推奨バリアントのみ）、バックトランスファー
decision-shot	完了した分析をエグゼクティブエッセンスに圧縮（1決定またはタイトなバンドル）	1つの分析済み質問またはグループ	オプション、賛否、および完全な分析へのリンクを含む5部構成ショートフォーム
decision-avatar	ユーザー設定と行動履歴をモデル化	コンテキスト、過去の選択	信頼度評価 🟢 / 🟡 / 🔴

decision-briefingに関する契約と責任

decision-briefingフェーズ1は、取り込み中に（例：「その後自動的に：」、ブロッカー、チケット参照などのシグナルから）大まかな依存関係と実行順序をすでに導出します。decision-pathはこの導出を重複しませんが、これらの大まかなマーカーに直接基づいて構築します:

1. decision-briefingが大まかなマーカーを提供: 保留中の項目の生のインベントリと初期の結合手がかりを供給します。
2. decision-pathが検証、評価、可視化: 文書化された事実に対してシグナルを検証し、確認されたエッジと推定されたエッジを分離し、ノードごとに5つの評価を割り当て、ゲートの衝突を公開します。
3. 差異に関するフィードバックループ: decision-pathがブリーフィングで欠落または誤って表現された依存関係を発見した場合、それは決して静かに吸収せず、修正ノートとしてブリーフィングに明示的に報告します。

---

ノードあたり5つの評価（およびエッジ検証ステータス）

5つの次元 [S E U Z W] はノード（そのシステムコンテキスト内での保留中または確定済みの決定）を評価します。エッジは、セマンティックな関係タイプ（例：解除、ブロック、前提条件）と検証ステータス（確認済み vs 推定）を持ちます。

グラフ内のすべてのノードは、コンパクトな5要素評価文字列を表示します:

[S+ E:<Option> U<Direction><Confidence> Z+ W-]

1. 合理的（S） — 技術的およびアーキテクチャ的な健全性:

   • S+: ソリューションは堅牢で、実際の問題に対処し、人為的な複雑さを回避します。
   • S~: 部分的に健全ですが、メンテナンスまたは運用上のオーバーヘッドをもたらします。
   • S-: 誤ったソリューション、表面的な活動、または証明された行き止まり（例：間違ったレバーでのフィルタリング）。

2. 推奨（E） — 具体的で証拠に基づいた推奨アクション:

   • E:<Option>: 明確な選択（例： E:A、 E:B、 E:resolve、 E:Step1）。
   • E-: 実行可能な推奨は不可能（事実の欠落またはハイレベルなポリシー問題）。

3. ユーザー典型的（U） — ユーザーの過去の習慣とコード化されたルールとの整合性（decision-avatar経由）: 方向（オプションは習慣に適合しますか？）と検証信頼度を個別にコード化:

   • 方向（Uの後の最初の文字）:
     • +: ユーザー典型的 — 過去の決定、ポリシー（CLAUDE.md）、または明示的な設定と一致。
     • ~: 中立/オープン — 文書化された支配的な履歴設定なし。
     • -: 非典型的 — 通常のワークフローまたは確立された習慣から逸脱。
   • 検証信頼度（2番目の文字）:
     • ASCIIグラフ内の純粋なASCII:
       • !: 高/根拠あり（散文では 🟢 文書化済み）。
       • ~: 中/もっともらしい（散文では 🟡 トレードオフは基本的にユーザーに属します）。
       • ?: 低/未検証（散文では 🔴 ポリシー問題、前例なし）。推測するよりもエスカレーション！
   • 例: U+!（典型的かつ文書化済み）、U+~（典型的だが、ユーザー判断）、U-!（非典型的と文書化）、U~?（オープン、前例なし -> エスカレーション）。

4. 整合性（Z） — 隣接ノードとのソフトなアーキテクチャおよびスタイルの調和:

   • Z+: 先行および下流の決定とシームレスに統合。摩擦なくまとまりのある全体を形成。
   • Z~: 軽微なスタイルの摩擦または運用上のオーバーヘッドがあるが、機能上は実行可能。
   • Z-: システム間の相互作用における顕著な摩擦（例：構成の乱雑さ、扱いにくい結合）だが、ハードルールを破らない。

5. 矛盾（W） — ハードな矛盾とポリシー/ゲート違反（最も重要な出力 — 警告！）:

   • W-: 他の推奨事項、ポリシー、およびアクティブな安全ゲートに対する矛盾がない。
   • W+: ハードな衝突/警告！ 別の推奨事項を無効にし、確立されたポリシー（CLAUDE.md、P-00x）に違反するか、アクティブな安全ゲートを迂回します。衝突するノードは、常に CONTRADICTIONS セクションで根本原因と解決パスとともに明示的に強調表示されます。

---

エッジタイプと導出ルール

依存関係はソーステキストから厳密に導出され、決して発明されません。エッジは関係タイプと検証ステータスを持ちます:

ソース内のシグナル	エッジタイプ	表記	意味
「その後自動的に：...」、「解除する」、「有効にする」	解除	+-->	ターゲット決定はソース決定後にのみアクション可能（文書化済み）
「ブロックする」、「防ぐ」、「安全ゲートがトリガーする」	ブロック	=>	ターゲットはソースが解決されるまでブロックされる
「必要とする」、「事前に必要」、「前提条件」	必要とする	-->	ターゲットは論理的かつ時間的にソースを必要とする
「フォローアップ決定」、「後のステップ2」	シーケンス	-->	実行後の下流の論理的進行
「測定によって反論された」、「時代遅れ」、「取って代わられた」	無効にする	--X-->	ソースの洞察によりターゲットが時代遅れになる
共有D-ID、チケットID、またはテキストによる証明なしの同じサブシステム	推定	?-->	文書化された因果関係の証明なしのもっともらしい結合（未検証）

未検証エッジのルール: テキストに明示的な因果関係の記述がない場合、エッジは推定（?-->）としてマークされなければなりません — 確認された事実として決してマークしてはいけません。関係が文書化されていない場合、ノードは接続されずに並べて表示されます。

---

ASCIIグラフのフォーマットガイドライン

1. 等幅フォント＆ターミナル最適化: 最大行幅 100 カラム。ターミナルレイアウトを壊すような幅広いテーブルは禁止。
2. 文字セットと純粋さ: 純粋なASCII。グラフコードフェンス内では、絵文字（🟢🟡🔴）を表示してはいけません。信頼度はASCIIマーカー（!、 ~、 ?）でのみ表現されます。
3. ノードID: 既存の識別子のみ（PD-A、 MD-A、 BH-A、 VM-A、 QR-A、 CL-A、 MO-A、 D-001、 732597768）。合成IDを決して発明しないでください！項目に略語がない場合、その項目番号が使用されます。フォローアップ内部ステップは、番号なしのエッジ注釈 (...) として表されます。
4. 階層構造:
   • LEVEL 0 - independent: ルートノード、ブロックされていないアイテム、外部トリガー。
   • LEVEL 1 - depends on exactly one: 直接のフォローアップ。
   • LEVEL 2 - depends on multiple / deep chain: 多重依存または深いシーケンシャルノード。
   • CONTRADICTIONS: ハードな衝突、ゲート違反、および矛盾する推奨事項（W+）。
   • LEGEND: すべてのグラフ出力で必須。グラフで使用されるすべての構造文字（|、 =Option、 (...)、エッジ矢印）は、凡例にリストされ説明されなければなりません。
5. オプションのMermaidフェンス: 有用な場合、追加の mermaid コードブロックを追加しても構いません。ただし、ASCIIグラフが主要かつ権威ある出力です。

---

例（パイロットデータセット: チケットマスター 2026-09-13）

チケットマスターミーティングブリーフィングからの実際の抜粋（732597768、 MO-A、 CL-A、 QR-A、 387521104、 CL-B）:

====================================================================================================
DECISION-PATH: DEPENDENCY GRAPH (Pilot Ticket-Master 2026-09-13)
====================================================================================================

LEVEL 0 - independent (Root decisions & external blockers)
  [732597768] Resolve GitHub billing issue                  [S+ E:resolve U+! Z+ W-]
      |  unlocks
      +--> [MO-A] Release Wave 2                            [S+ E:A       U+~ Z+ W-]

  [CL-A] clutch admin merge PR #6 & PR #8                   [S+ E:A       U+! Z+ W-]
      |  blocked by: [Gate "1 Approving Review" (self-approval impossible)]
      --> (follow-up decision: set branch protection to 0 or bot)

  [QR-A] Queue rename NTFS junction (_TICKETS -> TICKETS)   [S+ E:B       U+! Z+ W-]
      +--> [387521104] Night window runs                    (documented: only under B)

  [CL-B] Review gate pilot: Mac signing key                 [S+ E:Step1   U+~ Z+ W-]
      --> (follow-up steps 2-4: model automation after key provisioning)

LEVEL 1 - depends on exactly one precursor
  [MO-A] Release Wave 2                                     [S+ E:A       U+~ Z+ W-]
      |  requires: [732597768] (billing resolved, remote CI gates active again)
      |  requires: [Gate PRIVATE.txt "green remote CI"]
      --> (follow-up step: toggling visibility remains user-only action)

LEVEL 2 - depends on multiple / deep chain
  [387521104] Autonomous migration run in night window      [S+ E:B       U+! Z+ W-]
      |  requires: [QR-A]=B (NTFS junction established)
      |  requires: (junction set on the second host via transfer ticket -
      |             ticket number not stated in the briefing)

----------------------------------------------------------------------------------------------------
CONTRADICTIONS & GATE COLLISIONS
----------------------------------------------------------------------------------------------------
  [MO-A]=B  X  [Gate PRIVATE.txt "green remote CI"]
               Conflict: Option B would release Wave 2 based solely on local tests,
               even though two module contracts explicitly demand green remote CI.
               Resolution: Recommendation A forces [732597768] (billing) first, resolving collision.

  [CL-A]=StatusQuo  X  [Gate "1 Approving Review" (self-approval impossible)]
               Conflict: master demands 1 review, but sole repository account is lukisch.
               Resolution: Recommendation A (admin merge) legitimately breaks the dead end.

----------------------------------------------------------------------------------------------------
LEGEND & RATING KEY
----------------------------------------------------------------------------------------------------
  Edges & Structure:
    +-->   unlocks / enables (causality documented in source)
    =>     blocks / prevents (gate or external blocker)
    -->    requires / sequence (precondition or follow-up step)
    ?-->   presumed dependency (plausible coupling, but undocumented)
    --X--> invalidates / supersedes (source insight renders target obsolete)
    X      contradiction / collision (gate or policy violation)
    |      vertical hierarchy line / attribute mapping
    [ID]   decision node (item abbreviation or item number from briefing)
    [Gate]  external gate / rule / contract - NOT a decision node
    =Opt   specific option for a node (e.g. [MO-A]=B)
    (...)  unnumbered edge annotation / follow-up step (no invented synthetic ID)

  Node Assessment [S E U Z W]:
    S: Sensible      (+ sound / ~ qualified / - unsound)
    E: Recommended   (A, B, C, resolve, Step1, - none)
    U: User-typical  (direction: + typical / ~ neutral / - atypical;
                      confidence: ! grounded / ~ trade-off / ? escalation)
                      [! = documented (prose green), ~ = user trade-off (prose yellow),
                       ? = unverified / escalation (prose red)]
    Z: Coherent      (+ harmonizes / ~ slight friction / - architectural break)
    W: Contradictory (- conflict-free / + hard collision with gate or policy)
====================================================================================================

---

decision-pathが行わないこと

1. 決定は行いません: このスキルは構造的な透明性を提供します。決定する権限はユーザーにあります。
2. オプションを発明しません: このスキルは新しい代替案や重み付け基準をブレインストーミングしません。それは decide または decision-briefing に属します。