DSHIO/T 37—2026 檢測結果提交格式

---

📋 當前實施範圍

本標準自發布起生效。 提交倉庫：github.com/moldkey/dsh-conformance

驗證器只檢查「完整性」，不檢查「真實性」。 提交內容是否真實，由提交方負責。

---

1 範圍

本標準規定了檢測結果提交的目錄結構、必需文件、字段要求與驗證規則。

適用於： 任何依 DSHIO/T 36 提交檢測結果的機構或個人。

不適用於： 認證 —— DSHIO 當前不提供認證。

---

2 為什麼要規定提交格式

2.1 沒有格式，結果就沒法比較

兩家機構各寫各的報告，欄位不同、粒度不同 —— 讀者無法判斷差異來自插件還是來自寫法。

固定格式後，「通過」在所有提交者那裡是同一件事。

2.2 格式要能被機器驗

人工審查每份提交不現實。應能用腳本驗，且驗的結果可預期。

2.3 但驗的只能是完整性

驗證器不跑測試、不判斷真假。它只回答：

「這份提交齊全嗎？內部自洽嗎？」

真實性由提交方負責（DSHIO/T 36 §8）。

---

3 目錄結構

results/
  v<基準DSH版本>/
    <插件slug>/
      README.md
      result.json
      TESTER.yaml

3.1 版本目錄

3.2 插件 slug

3.3 一版本一目錄

同一插件的不同版本是不同目錄。 不應把多個版本放進同一目錄。

---

4 必需文件

4.1 三個文件，缺一不可

目錄內不應有其他文件。 多餘文件會導致無法判斷「審查了什麼」。

4.2 result.json 必需字段

4.3 環境指紋

應符合 DSHIO/T 21 §5.2：

dsh=<版本>;img=<鏡像>@<digest>;node=<版本>;pnpm=<版本>;mem=<內存>;cpu=<CPU>[:perm=<權限>]

六個必需分量： dsh、img、node、pnpm、mem、cpu。 perm 為建議分量。

4.4 階段記錄

stages 應含五個鍵：static、install、list、config、boot。

每個階段的對象至少含：

{"exit": 0, "duration": 3.4, "stdout": "...", "stderr": "..."}

原始輸出可以截斷，但應標明：

{"stdout_truncated": true, "stdout_bytes_total": 481203}

4.5 repeat 要求

consistent: false 的提交應標注為不穩定，不應用於任何背書。

4.6 TESTER.yaml 必需字段

4.7 利益衝突（強制）

conflicts 應含三個鍵，缺一不可：

可選補充： plugin_scope、notes。

為什麼不要求迴避。 我們沒有權力不應任何人測任何插件。 但我們可以要求：關係應寫在提交上。 讀者看到「本報告由插件作者的僱主出具」，自然知道怎麼看待它。

4.8 README.md 要求

應說明：

1. 插件名與版本
2. 使用的 DSH 版本
3. 執行的命令
4. 大致總耗時
5. 與 DSHIO/T 21 的偏離（沒有也要明說「無偏離」）

少於這些，讀者無法複現。

---

5 驗證規則

5.1 十二項檢查

5.2 驗證器的邊界

驗證器明確不檢查：

• 測試是否真的跑過
• 輸出是否真實
• 插件是否真的好用
• 環境是否真的符合指紋

這些由提交方負責。

5.3 失敗的處理

任一條失敗：

1. 提交被標記 not-verifiable
2. 逐條說明未通過的檢查
3. 提交方可修正後重新提交

not-verifiable 不是「造假」，是「格式不合規」。 兩者不同。

---

6 提交方式

6.1 一個提交一個 PR

每次 PR 只提交一個插件版本的結果。

理由： 多個混在一起時，無法判斷哪份被審查、哪份被合併。

6.2 修正已合併的結果

結果一旦合併即不可變。

修正方式：

1. 新開 PR
2. 刪除舊目錄
3. 加入新目錄
4. 在 PR 說明中解釋

git 歷史保留原始版本。這正是重點。

6.3 批量提交

可先提交 snapshots/<日期>.json 指向可下載的存檔， 再逐個補上單獨目錄。

snapshot 本身不是一致性結果，只是指針。

---

7 支持版本範圍

當前 + 前 2 個 DSH 版本。

DSH 發布新版本後，範圍向前滾動。超出範圍的提交會被拒絕。

---

8 分歧處理

8.1 同一插件、同一版本、兩份提交結論不同

1. 兩份都公開
2. 不應擇優採用
3. 讀者可自行要求第三方複測
4. DSHIO 記錄分歧

8.2 對抗性提交

任何人可用「挑戰」標籤指出某份提交的問題，須附可複現證據。

DSHIO 的做法：

1. 記錄爭議
2. 證據充分則標 disputed
3. 不仲裁

---

9 與其他標準的關係

DSHIO/T 20  測試方法 ── 怎麼測
DSHIO/T 21  測試條件 ── 什麼條件
DSHIO/T 36  檢測機構要求 ── 誰能做
      ↓
DSHIO/T 37  提交格式（本文件）── 怎麼交
      ↓
DSHIO/T 32  認證規則 ── 未啟用

---

附錄 A（規範性）最小合法提交

results/v0.2.2-rc.1/dsh-pet/
├── README.md
├── result.json
└── TESTER.yaml

result.json

{
  "plugin": "dsh-pet",
  "version": "0.4.5",
  "tested_at": "2026-11-08 10:00:00",
  "timezone": "+08:00",
  "baseline_dsh": "0.2.2-rc.1",
  "standard": "DSHIO/T 20, DSHIO/T 21",
  "fingerprint": "dsh=0.2.2-rc.1;img=dsh-sandbox:5.0@sha256:...;node=24.11.1;pnpm=9.15.9;mem=768m;cpu=1;perm=network",
  "stages": {
    "static": {"exit": 0},
    "install": {"exit": 0},
    "list": {"exit": 0},
    "config": {"exit": 0},
    "boot": {"exit": 0}
  },
  "verdict": "pass",
  "repeat": {"count": 2, "verdicts": ["pass", "pass"], "consistent": true}
}

TESTER.yaml

name: example.org
url: https://example.org
contact: ci@example.org
scope:
  stages: [T0, T1, T2, T3, T4]
  plugin_types: [tool]
environment:
  image: dsh-sandbox:5.0
  image_digest: sha256:...
  node: "24.11.1"
  pnpm: "9.15.9"
  mem: 768m
  cpu: 1
conflicts:
  develops_plugins: false
  paid_by_author: false
  result_dependent_fees: false
declaration: "Self-declares conformance with DSHIO/T 36."

---

附錄 B（資料性）為什麼照 Kubernetes 做

Kubernetes 一致性認證（CNCF）的做法：

1. 廠商自己跑 sonobuoy run --mode=certified-conformance
2. 提 PR 到 cncf/k8s-conformance，含 e2e.log + junit_01.xml + PRODUCT.yaml
3. Bot 驗 15 項技術要求（文件齊全、目錄結構、日誌無失敗）
4. 人工審政策項（會員資格、商標使用）
5. 合併 PR = 認證通過

CNCF 不測任何東西。它只要求公開原始日誌，然後蓋章。

我們採用同樣模式，但更輕：

• 不要求會員資格
• 不收取費用
• 不做認證（DSHIO/T 32 未啟用）

參考：

• CNCF Certified Kubernetes
• k8s-conformance instructions

---

修訂記錄