# 4D PluginLoader 決策確認表

本文件承接 [4D PluginLoader 邊界分析](phase-four-d-pluginloader-boundary-analysis.md)，把 4D 進入 PluginLoader contract 草案或任何程式實作前必須確認的 7 項決策整理成可逐項回覆的確認表。

本文件記錄使用者已同意 4D 七項文件型決策；此同意只代表可進入 PluginLoader contract 草案 / 實作前確認表，不代表已同意建立 PluginLoader、建立 `IPluginLoader` public contract、掃描 plugin folder、載入外部 DLL、執行外部程式碼、修改 `IDeviceAdapter` public contract、修改 config schema、導入 plugin framework、保存正式 DLL 路徑、接真實硬體、執行正式 DB DDL 或改變程式啟動方式。

## 0. 確認狀態

| 項目 | 內容 |
|---|---|
| 文件狀態 | 已確認 |
| 整理日期 | 2026-06-06 |
| 確認日期 | 2026-06-06 |
| 對應階段 | 第四階段 4D PluginLoader |
| 前置文件 | [4D PluginLoader 邊界分析](phase-four-d-pluginloader-boundary-analysis.md) |
| 程式 repo | `hs-device-control-template` |
| 程式 branch | `poc/nmodbus-tcp` |
| 程式基準 commit | `a846212 新增 4C ServiceHost 第一版與驗收測試` |
| 已完成前置 | 4A 邊界與決策確認、4B WebApi 第一版、4C ServiceHost 第一版、4D 邊界分析 |
| 本次確認範圍 | trust model、metadata contract、來源白名單、checksum、版本相容、Adapter contract、ServiceHost lifecycle、停止線 |
| 確認後可進入 | 4D PluginLoader contract 草案 / 實作前確認表 |
| 本次仍不做 | 不建立 Loader、不載入 DLL、不掃描 plugin folder、不改 Adapter / config / DB、不接真實硬體 |

## 1. 建議確認方式

使用者可直接回覆以下格式：

```text
4D 決策確認：
1. 同意
2. 同意
3. 同意
4. 同意
5. 同意
6. 同意
7. 同意
備註：若有需要調整的項目，請寫在這裡。
```

若任一項不同意，建議寫成：

```text
第 N 項不同意，改為：...
```

## 2. 七項決策確認表

| 編號 | 決策項 | 建議定案 | 若同意的影響 | 若不同意需補充 |
|---:|---|---|---|---|
| 1 | 4D 第一版先做 trust model / metadata contract | 先整理 PluginLoader contract 草案與實作前確認，不建立實際 Loader、不載入 DLL。 | 可安全固定來源信任、版本、狀態、錯誤與 audit 語意。 | 需說明是否要直接建立 Loader 或載入測試 DLL，並列出風險控管。 |
| 2 | 沿用 3D Plugin metadata 起點 | 以 3D `PluginDescriptor`、`PluginCapabilityDescriptor`、`IPluginCatalogService` 作為 metadata 起點。 | 可延續既有 Application contract，不重複發明 plugin metadata。 | 需說明新的 metadata model 與既有 3D contract 如何相容。 |
| 3 | 信任來源與驗證規則 | 第一版需定義來源白名單、checksum、版本相容與人工核准欄位。 | 可避免任意 DLL 或未知來源被視為可載入。 | 需說明哪些來源可被信任，以及不做 checksum / 白名單時的替代保護。 |
| 4 | Adapter public contract 不變 | 4D 不修改 `IDeviceAdapter` public contract，未來 plugin 也需經 Adapter / dispatcher 邊界承接。 | 可避免外部 plugin 破壞既有 Core / Adapter 分層。 | 需說明為何需要改 Adapter contract，以及相容與測試策略。 |
| 5 | Loader lifecycle 由 ServiceHost 承接 | 未來 Loader lifecycle 應由 4C ServiceHost 或受控背景入口組裝，不由 WebApi Controller 直接載入 DLL。 | 可維持 WebApi / ServiceHost 分責，降低 HTTP request 直接執行外部程式碼風險。 | 需說明若由 WebApi 載入，如何處理權限、重啟、隔離與錯誤回復。 |
| 6 | 本輪不改 config schema / 不保存正式路徑 | 只整理候選欄位，不修改 `devices.json`、`workflows.json`、`appsettings.json`，不保存正式 DLL path、IP、Port 或 token。 | 可避免未成熟 plugin schema 變成正式契約，也避免敏感資訊進 repo。 | 需說明要修改哪些 schema 欄位，以及敏感資訊保存與回復策略。 |
| 7 | 停止線維持 | 所有 Loader 實作、外部 DLL 測試、真實硬體、DB audit 寫入、plugin framework 套件導入都需另行確認。 | 可先完成文件與 contract 草案，不跨過高風險執行邊界。 | 需明確列出允許突破的停止線、驗證方式與回復策略。 |

## 3. 本次確認結果

| 編號 | 決策項 | 確認結果 |
|---:|---|---|
| 1 | 4D 第一版先做 trust model / metadata contract | 已同意 |
| 2 | 沿用 3D Plugin metadata 起點 | 已同意 |
| 3 | 信任來源與驗證規則 | 已同意 |
| 4 | Adapter public contract 不變 | 已同意 |
| 5 | Loader lifecycle 由 ServiceHost 承接 | 已同意 |
| 6 | 本輪不改 config schema / 不保存正式路徑 | 已同意 |
| 7 | 停止線維持 | 已同意 |

## 4. 確認後可進入的工作

| 順序 | 工作 | 範圍 |
|---:|---|---|
| 1 | 4D 決策確認結果回填 | 已完成，使用者已同意 1 至 7 項決策。 |
| 2 | 4D PluginLoader contract 草案 / 實作前確認表 | 固定 metadata、verification result、state、audit、候選檔案、測試策略與停止線。 |
| 3 | 程式 repo 唯讀結構檢查 | 盤點 `Application.Plugins`、`ServiceHost`、Adapter dispatcher、config schema 與測試專案。 |
| 4 | 最小 contract 實作評估 | 只在使用者確認後，評估是否新增 verification / state / audit contract。 |
| 5 | Loader 實作評估 | 需另行確認來源、簽章、checksum、隔離、卸載與測試 DLL；不得由本表自動授權。 |

## 5. 仍需停止的項目

即使七項決策全部同意，除非使用者另外明確授權，仍不得自動執行以下項目：

- 不建立 `PluginLoader` 程式。
- 不建立 `IPluginLoader` public contract。
- 不掃描 plugin folder。
- 不載入外部 DLL。
- 不呼叫 `Assembly.Load`、`LoadFrom`、`LoadFile` 或類似 API。
- 不執行外部 plugin 程式碼。
- 不新增或更換 plugin framework / DI framework / sandbox 套件。
- 不修改 `IDeviceAdapter` public contract。
- 不修改 Core / Adapters / Infrastructure / Application 既有 public method 簽章。
- 不修改 `devices.json`、`workflows.json`、`appsettings.json` schema。
- 不保存密碼、Token、IP、Port、完整 connection string、正式 DLL 路徑或正式環境資訊。
- 不執行 DB 寫入、DDL、ALTER TABLE 或正式 Apply。
- 不接真實硬體或案場客製 plugin。

## 6. 建議下一步

七項確認已完成。建議下一步整理 `4D PluginLoader contract 草案 / 實作前確認表`，並在進入任何程式修改前再次回報預計新增 / 修改檔案與原因。