STEP 1
LABEL
Identify · 5 行 Dockerfile
在 image 上掛 OCI 標準 label（org.opencontainers.image.*）+ R2K 專屬 label（com.releaseasknowledge.*）宣告身份。
開發團隊腦袋裡的知識,跟著新版本被釋出 ──
但這份知識並不會跟著 image 一起發布出去。
The R2K Thesis
從「丟一個 binary」升級成「結構化、可機器索引的知識傳遞」── R2K v1 拆成四個可漸進採用的步驟,每一步都有對應工具與驗證。
在 image 上掛 OCI 標準 label（org.opencontainers.image.*）+ R2K 專屬 label（com.releaseasknowledge.*）宣告身份。
build 時把 OpenAPI / DB schema / config / SBOM 等事實 dump 進 /r2k/,並用 /r2k/index.yaml 當入口清單。
對兩個 release 的 snapshots 做跨資產 diff,輸出統一的 change.yaml。每種資產一個 plugin。
把多個 diff 跨資產關聯成風險洞察。可接 LLM、規則引擎、policy-as-code,並輸出 R2K badge。
R2K 不是產品、不是工具、不是 vendor。 它是一份 thesis,由 8 條原則組成 —— 描述軟體發布應該怎麼運作,卻很少被這樣做。
OCI image 該存 L1（LABEL）+ L2（snapshots：API spec、DB schema、config）,這些是事實。L3（Change Manifest）是解讀,從事實計算出來,不必烘焙進 image。
類比 git：commit 存 snapshot,diff 是計算的。
類比 SBOM：存元件清單,vulnerability scan 是計算的。
R2K 對 OCI image 做 git 對 source code 做的事。
API spec、config schema、migration plan、SBOM 應該跟 image 同步發布、同步版本化、同步流通。不是事後寫 release notes,是 build 當下自動採集。
「這次哪個 API breaking」「哪個 migration 危險」「哪個 config 必填」這類知識,不該停留在工程師腦袋或 PR description。必須在 build 時被結構化萃取。
能用 OCI Referrers 就用、能用 CycloneDX 就用、能用 OpenAPI 就用。R2K 是把業界既有工具的輸出整合,不是另起爐灶。
R2K 的服務對象不是開發者(他們已有 git、PR、Slack),而是支援團隊、業務、客戶 DevOps、稽核者、合規團隊。任何呈現都要假設讀者不會讀程式碼或翻 git log。
高頻輕查（版本、case_type）用 LABEL 索引（~50ms）。低頻重查（SBOM、test report）用 metadata layer（~300ms）。完整深度查詢用 Change Manifest。
R2K 不要求重寫 CI/CD。從 Level 1 的 5 行 Dockerfile 開始,每一級都有獨立價值,可以漸進採用。
Change Manifest、License Manifest、Network Contract — 結構化 yaml/json 是組織內外協作的共同語言。比 release notes 精確,比 wiki 即時,比 Slack 對話可追溯。
像 SLSA 一樣,R2K 漸進採用。每一級都可以單獨宣告達成 ──「我們是 R2K Level 2」就跟「我們是 SLSA Level 3」一樣可以單獨成立。
Docker LABEL · build-arg
所有 production image 帶 OCI 標準 LABEL（org.opencontainers.image.*）+ R2K namespace LABEL（com.releaseasknowledge.*）,任何 scanner 秒掃。
/r2k/* snapshots · index.yaml
+ OpenAPI、DB schema、config、SBOM、runtime manifest 寫進 /r2k/,並由 index.yaml 列表 + sha256 防竄改。
change.yaml · diff plugin SPI
+ 跨 API/DB/Config/SBOM 的統一 change.yaml。L3 是 derived intelligence,從 L1+L2 計算而來 —— Mode A 預先算 / Mode B 即時算（見下）。
OCI Referrers · badge · 跨組織
+ 完全 OCI 1.1 化,R2K artifact 跨組織傳遞,客戶端可離線讀取,並輸出 R2K badge（Level + Mode）。
L1 = Identify · L2 = Trust · L3 = Understand · L4 = Share
把軟體發布從「shipping software」轉變成「shipping interpretable change intelligence」。
L3 是 derived intelligence ── 但在哪一刻 derive,有兩個合法選項。R2K v1 設計 Mode A / Mode B 雙模式,讓 R2K 同時服務 air-gap ISV 跟 SaaS vendor。
Pre-computed
CI 階段就把 Change Manifest 算好 + attach 到 image。客戶端不需要 Diff Engine 服務。
適用 air-gap on-prem ISV、客戶 DevOps 不能連回 vendor
代價 from→to 預設綁死、規則升級需 rebuild
On-demand
CI 只 attach snapshots（L1+L2）,Diff Engine 在查詢時即時計算。任何 from→to 組合可查。
適用 SaaS、connected enterprise、開源工具
代價 首查稍慢(可 cache)、需 host Diff Engine
重大 release 同時 ship:主 image 內帶 Mode A 預設組合 manifest（air-gap 客戶可直接用）,L2 snapshots 完整保留（連線客戶可走 Mode B 算任意組合）。底層機制完全相同,差別只在 manifest 在 lifecycle 哪一段算。
| 維度 | Mode A | Mode B | 雙模式 |
|---|---|---|---|
| Air-gap 友好 | ✓ 完美 | ✗ 需服務 | ✓ |
| 任意 from→to 查詢 | ✗ 預設綁死 | ✓ 完整 | ✓ |
| Diff 規則升級自動受惠 | ✗ 需 rebuild | ✓ 自動 | △ 部分 |
| CI 整合複雜度 | ✓ 簡單 | ✓ 簡單 | △ 中等 |
| 客戶端複雜度 | ✓ 簡單 | △ 需連線 | △ 看 path |
| 適用 vendor 類型 | ISV / on-prem | SaaS | 中型混合 |
R2K 作為 framework 不規定哪一個 ── 但第 1 原則（facts vs intelligence）讓兩種模式都成為合法的實踐方式。選擇取決於你的客戶端是否能連到你的服務。
清楚的邊界讓 thesis 變得有用。R2K 跟既有概念有重疊,但解的是不同的問題。
想更深一點讀 R2K?這裡是社群與作者持續整理的相關文章 ── 規格、敘事、實作筆記、跨平台版本。歡迎分享、引用,或丟回饋。
沒有行動的 manifesto 只是裝飾。挑一條最適合你目前處境的路徑。