decision-draw — 全体像と一括承認（バンドル決定版） は何をしますか？
5つや10もの決定が保留されていると、個々の選択肢の細部に埋もれ、全体としてどのようなシステムが生まれつつあるのか見失いがちです。decision-draw は alternatives を記述するのではなく、機能する全体像を描きます。すべての推奨事項が導入された後、システムはどのように連携するのか？ユーザーはその全体像を承認するか、的を絞ったフィードバックを提供します。
使用すべき場合
- 複数の相互依存する決定（decision-briefing または決定ブリーフィング文書から）を、退屈な個別質問のチェックリストとして処理したくない場合。
- ユーザーが承認する前に、実装後にコンポーネントが実際の運用でどのように相互作用するかを確認したい場合。
- 依存関係グラフ（decision-path）で特定された、密結合された決定のクラスターを、機能単位としてまとめて承認したい場合。
- トリガーワード:
/decision-draw、「全部賛成したら全体はどうなる？」、「全体像を描いて」、「全体決定コンセプト」、「decision draw」、「実装後、システムはどう連携する？」、「全体承認図」。 - 以下の場合は使用しないこと:
- 項目ごとに個別の選択肢を評価し、A/B/C のレターコードで選択させたい場合 — それは decision-briefing の役割です。
- ターミナル上で純粋な因果関係やボトルネック分析を行う場合 — それは decision-path の役割です。
- 単一の問題や密結合された質問に対して、5つのパート（コンテキスト、選択肢ごとの賛否、推奨）からなる独立したブロックで選択肢評価を行う場合 — それは decision-shot の役割です。
- 単一の未決定の方針問題を系統的に評価する場合 — それは decide の役割です。
決定ファミリーにおける境界
| スキル | UX と焦点 | 選択肢への態度 | 承認モード |
|---|---|---|---|
decision-briefing | 分解: 個別項目に分割 | すべての選択肢 A/B/C/D を表示 | レターコード (1A 2C 3B) |
decision-path | 構造化: 因果関係を整理 | グラフ内の選択肢を評価 | 端末診断 (ASCII) |
decision-draw | 首尾一貫した目標像: 相互依存する決定をバンドル | 推奨された選択肢のみを記述（代替案はリンク） | 全体承認または修正文 |
decision-shot | 構造化された個別ブロック: 単一問題または密結合グループ用 | 選択肢を2～4個の賛否ポイントで表示 | エグゼクティブ決定 / 個別レビュー |
decide | 1つの問題を解決 | 評価マトリックス（基準） | 分析的な推奨 |
コアルール:
decision-drawは推奨された選択肢のみを記述します。破棄された選択肢は消えたわけではありません。それらは decision-briefing、decision-shot、またはリンクされたチケットに文書化され、ヘッダーテーブルで参照されます。このリンクがない全体図は、選択を簡略化するどころか、ユーザーから選択肢を奪うことになります。
必須構造（7パート）
完全な decision-draw は、以下の7つのパートを厳密に守ります。
1. バンドルと範囲
バンドルに含まれるすべての項目の表形式の要約:
- 略称 / ID（例:
BH-A、MD-A、CF-A） - チケット参照
- 項目の短いタイトル
- 推奨される選択肢（この全体図の前提）
decision-avatarの信頼度（🟢 文書化済み、🟡 トレードオフ、🔴 エスカレーションが必要）- 詳細分析 / 代替案へのリンク
2. コンセプト
首尾一貫した散文で目標状態を記述:
- すべての推奨事項が計画通りに実行された場合、どのようなシステムランドスケープやワークフローが生まれるか？
- 選択肢の比較、仮定法の婉曲表現（「～することもできる」）はなし。
- 明確で確信に満ちた直説法: これが目標状態におけるシステムの動作です。
3. 連携
このスキルの機能的核心:
- 決定されたコンポーネントは、実装後に実際にどのように連携するのか？
- コンポーネントの静的リストではなく、具体的なエンドツーエンドの運用フロー（例: 「チケット到着 → エージェント開始 → バックエンドが割り当て → ホストにデプロイ」）に沿って構成。
- データフロー、インターフェース、運用責任を明確にする。
4. 実装
具体的な展開手順:
- 実際に何が、ステップバイステップで行われるか？
- 実行順序と依存関係ロジックは decision-path から直接継承。
- 独立したワークストリームは、並行トラックとして正直に表現する（人為的な因果連鎖を発明しないこと。バンドルは複数の並行トラックから構成される可能性がある）。順次順序付けは、実証された依存関係や締め切りが存在する場合にのみ主張する。
- ゲート、移行スクリプト、検証チェックを強調する。
5. この全体図がカバーしないもの
誤った完全性に対する境界防御:
- どの二次的な質問、未解決の問題、または 🔴 信頼度の項目が意図的に除外されているか？
- 隣接システムとの境界線はどこか？
- その周辺を隠した全体図は、誤った安心感を生み出します。
6. 承認
ユーザーとのやり取り:
- ユーザーは全体図を全体としてレビューする。
- 応答オプション 1: 明示的な全体承認（「よさそうだ」「承認する」「提案通りすべて実装する」）。この場合のみ、バンドル内のすべての項目が決定済みとして計上される。
- 応答オプション 2: 自然言語による的を絞った修正（「BH-A は小さいバリアントを選ぶ」「MD-A は自動再起動なし」「VM-A は現状維持」）。個別の決定への分解をトリガーする。修正されなかった項目は未解決のまま残る。
7. 書き戻し
ユーザーフィードバックから個別の ledger エントリへの体系的な変換:
- 自動同時計上なし: 変更されていない項目は、明示的な全体承認があった場合のみ計上される。部分的な修正は全体承認ではない！
- 修正時の分離: ユーザーが修正を送信した場合、それは個別の決定に分解される。バンドル内の他のすべての項目は、ユーザーが修正された全体図を全体として受け入れるか、残りの項目を個別に確認するまで、厳密に未解決のまま（ソースチケット / ledger 内で）残る。
- 必須の書き戻しテーブル: すべての部分的なフィードバックは、4つの列を持つ構造化された評価テーブルを生成する:
- 元の修正: ユーザーの発言をそのまま。
- 影響を受けるキー: どのバンドル ID が変更されるか（1つの発言が複数の決定に影響を与えるマルチヒットも含む）。
- ドミノステータス: decision-path 内のどの依存ノードまたは下流の前提が崩れるか、再評価が必要か。
- 未解決の曖昧さ: 修正が複数の解釈を許し、計上前に明確化が必要な箇所。
- マルチヒットの処理: 単一のユーザー発言が複数の決定を同時に変更する可能性がある。書き戻しはこの結合を解きほぐし、影響を受けるすべてのキーを一緒に取得する必要がある。
- Phase 4 経由の排他的書き込みパス:
decision-drawはチケットやレジスターへのネイティブな書き込みパスを持たない。Ledger の更新は、decision-briefing Phase 4（DECIDED-AND-DONE.mdまたはTO-DECIDE-USER.txtへの記録と永続化）の標準化されたプロトコルを排他的に介して行われる。
例（パイロットデータセット: Ticket-Master 2026-09-13 — BACH & System Cluster）
2026-09-13 付け Ticket-Master 決定ブリーフィングからの実際のバンドル: BH-A、MD-A、CF-A、VM-A、PD-A。
# DECISION-DRAW: BACH コアクライアントと運用インテグリティ
## 1. バンドルと範囲
| キー | チケット / ソース | トピック | 推奨される選択肢 | 信頼度 | 代替案と詳細 |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | モデルバックエンド = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac デプロイと再起動 | A1 + スクリプト（24/7はレポートのみ） | 🟢 | チケット `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | ホスト間の設定ターゲット | 1C（正当化）/ 2B（ホスト依存）/ 3B（高） | 🟢 / 🟡 | チケット `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager タイムゾーン | A（routinika のようなアプリ全体設定） | 🟢 | チケット `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC ページの可視性 | A（宣言を public に、現状維持） | 🟢 | チケット `T-20260913-609930207.txt` |
*注: 破棄されたすべての代替案（例: BH-A E5=B ocean-heart、MD-A A2 フル書き込みキー、VM-A B プロファイルごとのゾーン）は、Ticket-Master 決定ブリーフィングに文書化されたままです。*
---
## 2. コンセプト
我々は、クリーンで疎結合なマルチホストアーキテクチャを確立します。モデルバックエンドは `agents-heart` という独立したコアモジュールとして運用されます。ロール、権限、予算はリレーショナル SQLite データベースでクリーンに管理され、モデルルーティングの決定は 2 段階で行われます。BACH がドメインに適格な候補セットを構築し、clutch がそのセット内からコストと能力の最適なモデルを選択します。
Mac Studio では、24/7 のバックグラウンドサービスが読み取り専用のデプロイキーを使用して安全かつ確実に運用されます。コード更新は自動的にプルされ、実行中の 24/7 サービスは強制終了されるのではなく、穏やかに通知されます。設定はパフォーマンスが要求する場合、ホスト固有のままにすることができます。一方、アプリ全体の設定（実績のある routinika パターンに従った VersicherungsManager のタイムゾーンなど）は、決定論的にハードワイヤリングされます。USMC は、正規のパブリックメモリファサードとして残り、パブリックウェブサイト上での地位を維持します。
---
## 3. 連携
5つの項目は連続した因果連鎖を形成しません。代わりに、それらはシステム全体で並行して連動する、日常の運用インテグリティのためのモジュール化された疎結合の柱を表します。
- **コアアーキテクチャとモデルルーティング (`BH-A`):** `agents-heart` モジュールがモデル割り当てを分離します。タスクが到着すると、BACH がドメインに適格な候補セットを決定し、clutch がコストと容量の最適なモデルを選択します。
- **ホスト設定とデプロイインテグリティ (`CF-A`、`MD-A`):** 一貫した推論努力がラップトップとワークステーションに適用される一方（`CF-A`、ホスト依存モデルは透過的）、Mac Studio は検証済み設定の下で永続的なバックグラウンドプロセスを実行します。更新時、Mac は読み取り専用デプロイキーを介してコードをプルします（`MD-A`）。GUI サーバーは再起動し、長時間稼働する 24/7 サービスは更新要件をダッシュボードに穏やかに通知します。
- **ドメイン永続性と期限 (`VM-A`):** VersicherungsManager などのアプリケーションは、routinika パターンに従い、アプリ全体の `settings` テーブルに対して期限を保持します。計算と期限監視は、同じ IANA タイムゾーンですべてのプロファイルにわたって決定論的に動作します。
- **パブリック表示 (`PD-A`):** 夜間サイトビルダーはリポジトリ状態を検証します。USMC は修正された `public` 宣言の下でクリーンに公開され、セキュリティゲートでアラートをゼロにします。
---
## 4. 実装
ソースデータセットが依存関係グラフ（[decision-path](../decision-path/SKILL.md)）でこれらの5つの項目にわたる連続した連鎖を実証していないため、ロールアウトは4つの独立した並行ワークストリームに正直に構造化されます（アプローチ a: 発明された因果関係の代わりに並行トラック）。順次順序付けは、外部の締め切りや内部ステップが存在する場合にのみ適用されます。
- **トラック A（時間重要 — 期限 2026-09-14）:**
1. USMC メタデータを `public` に合わせる（`PD-A`）; Draft PR #2 を破棄。夜間ビルダー実行のため遅延は許容できないが、このステップは技術的に他のすべてのトラックから完全に独立している。
- **トラック B（ホスト設定と Mac デプロイ — 並列化可能）:**
1. B1: 設定ターゲットを `.SYNC` にコード化する（`CF-A`）、推論努力を両ホストで `high` に同期。
2. B2（B1 から独立）: Mac Studio に読み取り専用デプロイキーをインストールし、プルアンドレポートの自動化スクリプトをセットアップする（`MD-A`）。
- **トラック C（ドメインデータベース — 並列化可能）:**
1. VersicherungsManager に routinika パターンに従ったアプリ全体の `settings` テーブルマイグレーションを実装し（`VM-A`）、後続の publisher 開発のためのクリーンベースラインを確立する。
- **トラック D（アーキテクチャ抽出 — 内部マルチステップ計画）:**
1. D1: `agents-heart` にロールと予算のための SQLite スキーマをセットアップする（`BH-A` E1）。
2. D2: バックエンドカタログを Python モジュールとして切り出し（`BH-A` E3）、clutch 割り当てシームをバインドする（`BH-A` E2）。
3. D3: `agents-heart` モジュールを抽出してバインドする（`BH-A` E5、E6）。
---
## 5. この全体図がカバーしないもの
- **タスククレームの競合状態:** 重複タスククレームを許可する並行性バグは、専用のホットフィックスチケットで対応中であり、この承認の範囲外です。
- **Cockpit フロントエンド:** モニタリング Cockpit（`BH-A` E4）は、バックエンドがライブ運用テレメトリを生成するまで意図的に延期されます。
- **パブリックリポジトリの公開:** コードのマージとステージングは、プライベートリポジトリを自動的に公開しません。最終的な可視性の切り替えはユーザーに留保されます。
---
## 6. 承認
このシステムクラスターを全体として承認するか、自然言語で調整を行うことができます。
- **明示的な全体承認:** 「よさそうだ、提案通りに実装して。」（これのみがすべての項目の計上をトリガーします）。
- **修正の例:**
- *「Mac のホスト固有の特別処理は不要: MD-A は直接プッシュのためにフル書き込みキー (A2) が必要で、CF-A はすべての設定をワークステーションに厳密に合わせるべき (Group 1=A、2=A)。」* (マルチヒット)
- *「BH-A E5 は、agents-heart ではなく ocean-heart という名前にして。」*
- *「VM-A は今は延期して。publisher は後でいい。」*
---
## 7. 書き戻し
コンセプトが承認または修正された場合、スキルはフィードバックを ledger エントリに変換します。
### ケース A: 明示的な全体承認
ユーザーが全体としての全体図を明示的に承認した場合（例: *「よさそうだ、提案通りに実装して」*）:
- 5つの項目すべて（`BH-A: 1A/2A/3A/4B/5A/6A`、`MD-A: A1`、`CF-A: 1C/2B/3B`、`VM-A: A`、`PD-A: A`）が DECIDED として [decision-briefing](../decision-briefing/SKILL.md) Phase 4 に渡されます。
- Phase 4 が ledger エントリを実行します。
### ケース B: 部分的な修正
ユーザーが修正を送信した場合:...（例示のため省略 — 実装時に対応する実際の修正と書き戻しテーブルを含むこと）。