Roadmap / Planning Artifact
- -AI-BIM-governance：SaaS 路線圖規劃（2026-05）
+AI-BIM-governance：SaaS 路線圖規劃（2026-05）
文件性質：roadmap / planning artifact（不是 OpenSpec change，不修改產品程式碼） 依據輸入：使用者於 2026-05-08 提供的兩張架構圖（v1 路線圖 + v2 目標架構） @@ -235,10 +233,11 @@
AI-BIM-governance：SaaS
2026-05-12 更新（OpenSpec archive 後 roadmap 對齊規範）：新增 §1.6，明定每次 OpenSpec sync / archive 後，必須同步更新本 roadmap 的 spec 清單、歸檔 change 溯源、Phase 狀態、候選優先級與驗證證據引用，避免
openspec/specs/與本文件漂移。2026-05-12 更新（
worker-real-conversion-qualityarchive 對齊）：依openspec/changes/archive/2026-05-11-worker-real-conversion-quality/與現行openspec/specs/更新 §1.2 / §1.3 / §1.4 / §2 / §4 / §5 / §6 / §7 / §9.8 / §10。P0 #1 已 land 並歸檔：_worker已具備真實 IFC→USDC adapter、USDC openability hard gate、real mapping quality metrics 與 single Kit/browser 截圖證據；mapping coverage 仍採 measure-first，尚未鎖 production baseline 門檻。2026-05-12 更新（#2 GPU 容量等待）：依使用者指示，
+multi-artifact-kit-routing/streaming-multi-instance-orchestration的dedicated_instanceruntime 驗證改為 等待 GPU 購買與部署後執行。在至少兩個 GPU-backed Kit endpoints 可用前，roadmap 與 OpenSpec 只保留 control-plane contract / routing target，不把 dedicated multi-Kit runtime 視為進行中、passed 或 failed。2026-05-12 更新（
worker-mapping-lineage-quality-baselinearchive 對齊）：依openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/與現行openspec/specs/更新 §1.2 / §1.3 / §1.4 / §2 / §5 / §6 / §10。原候選 #3 lineage API 與 #3A mapping quality baseline 已合併為同一 change 並歸檔：_worker已具備 lineage query API、worker UI lineage / quality view、all-IFC-entity coverage 語意、minimum_coverage_ratio=1.0policy 與 storage batch verification helper；canonical 13-file real batch 仍未完成，因此 production baseline 尚未鎖定。
本文件目的是把使用者提供的兩張架構圖（v1 從 PoC 到 SaaS 的執行路線圖、v2 SaaS 級目標架構與落地順序）對照目前 repo 現況，產出下一階段最小、可驗證、不擴散範圍的 OpenSpec change 候選清單，並標出每個候選的優先級、風險、KPI 與 repo 邊界。
-
0. 規劃原則（Karpathy / AGENTS.md / 既有路線圖一致）
+0. 規劃原則（Karpathy / AGENTS.md / 既有路線圖一致）
- 依 AGENTS.md 的 repo 邊界與 source-of-truth 順序執行：
bim-control 是資料權威，_worker 是檔案/轉檔 facade，coordinator 是 session control plane，
bim-streaming-server 是 Kit runtime，web-viewer-sample 是 browser client。
@@ -250,14 +249,14 @@ 0. 規劃原則
- 跨 5 個 repo 邊界的整合 spec，先拆成單 repo 邊界內的子 change，避免 high-risk impact analysis。
-
1. 現況基線（2026-05-08）
+1. 現況基線（2026-05-08）
-與 workflow v3 的分工：本文件是 OpenSpec 候選（#1-#9 + #1A / #2A）、NVIDIA Reference 採用決策矩陣（§13）、§11.4 Multi-Kit Instance 並行官方定義、硬體配置（§9.0-§9.8）、MCP 查詢結果（§11） 的權威。 開發流程入口（七層架構、Phase 完成度、驗證證據 4 層分級、品質管線 7 步、開發協作流程、PR Checklist、服務測試命令、核心資料流 sequence diagram）見
docs/PROJECT_DEVELOPMENT_WORKFLOW.md。 兩份文件互補不替代：workflow v3 不重述本文件的決策矩陣與 spec id；本文件不重述 workflow v3 的 sequence diagram 與 PR checklist。任何後續分工調整應走 OpenSpec change，不直接在 main 上覆蓋。
1.1 已存在的核心服務
-| 服務 | @@ -298,10 +297,10 @@OK |
|---|
1.2 已歸檔的 OpenSpec specs（權威：openspec/specs/）
+1.2 已歸檔的 OpenSpec specs（權威：openspec/specs/）
下列 11 個 capability 為目前 repo 現行規格（各 spec.md）；歷史 delta 與 merge 過程見 §1.4 openspec/changes/archive/。
| Spec | @@ -315,7 +314,7 @@worker-artifact-pipeline |
1 | 3-B | -✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / original_filename / real IFC→USDC conversion quality |
+✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / original_filename / real IFC→USDC conversion quality / lineage graph API / all-IFC-entity coverage policy |
|---|---|---|---|---|---|
worker-dev-ifc-source-selection |
@@ -327,7 +326,7 @@ worker-demo-upload-convert-ui |
0/1 | 2 | -✓ Worker demo UI on 8005 | +✓ Worker demo UI on 8005；含 lineage / conversion quality view |
legacy-storage-conversion-retirement |
@@ -363,7 +362,7 @@ runtime-verification-evidence |
0 | 6 | -✓ 證據分層（contract / real conversion / single-Kit / multi-Kit / stress） | +✓ 證據分層（contract / real conversion / storage batch baseline / single-Kit / multi-Kit / stress） |
runtime-verification-task-status |
@@ -378,8 +377,8 @@ ✓ workflow v3 / SaaS roadmap / README / OpenSpec specs 分工權威 |
1.3 已驗證的閉環與 runtime evidence
+1.3 已驗證的閉環與 runtime evidence
# 2026-05-08 spec / review-session baseline
_bim-control pytest: 21 / 21 passed
bim-review-coordinator vitest: 102 / 102 passed
@@ -396,11 +395,11 @@ 1.3 已驗證的閉環與 ru
real IFC→USDC root smoke: passed (89,394,282 bytes fixture; coverage_ratio=0.950556913882097)
single Kit/browser real worker USDC: passed (review_session_001a59d345ce; 1920×1080; non-black stream frame)
-# 2026-05-12 worker-mapping-lineage-quality-baseline（branch evidence，尚未 archive）
+# 2026-05-12 worker-mapping-lineage-quality-baseline（archived spec + validation evidence）
openspec validate --strict: passed
_worker store/converter/batch tests: 56 passed
_worker clean venv full tests: 94 passed, 1 skipped
-lineage API / UI / quality policy: implemented in change branch
+lineage API / UI / quality policy: archived into current specs
_worker dependency baseline: requirements pin fastapi/starlette/uvicorn to repo baseline
canonical storage dry-run: 13 IFC fixtures found; not converted; minimum_coverage_locked=false
real batch --limit 1: timed out after 600s; full baseline not locked
@@ -415,16 +414,16 @@ 1.3 已驗證的閉環與 ru
2026-05-11 real conversion：docs/verification/2026-05-11-worker-real-conversion-quality.md
Single Kit/browser 截圖與 summary：docs/verification/evidence/2026-05-11-worker-real-conversion-quality/
-限制：worker-real-conversion-quality 已解除 placeholder converter blocker，但該 evidence 仍採 measure-first；worker-mapping-lineage-quality-baseline 分支已加入 minimum_coverage_ratio=1.0 / all-IFC-entity semantics 與 lineage API，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
+限制：worker-real-conversion-quality 已解除 placeholder converter blocker；worker-mapping-lineage-quality-baseline 已將 minimum_coverage_ratio=1.0 / all-IFC-entity semantics 與 lineage API 併入現行 specs，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
註（2026-05-12）：multi-artifact-kit-routing 的 dedicated_instance runtime 不再列為既有分支驗證狀態；後續必須等 GPU 購買與部署完成、可提供至少兩個 GPU-backed Kit endpoints 後，才重新啟動驗證並更新 runtime-verification-evidence。
-1.4 OpenSpec 已歸檔 change → 現行 openspec/specs/ 溯源
+1.4 OpenSpec 已歸檔 change → 現行 openspec/specs/ 溯源
用途： roadmap 只摘要狀態；需求句式與 Requirement 編號以各 spec 為準。下列為 openspec/changes/archive/ 目錄（folder 名）與本 repo 現行 capability 的對應（2026-05-12 盤點）。
-
+
已歸檔 change（openspec/changes/archive/）
@@ -468,18 +467,23 @@ 1.4 OpenSpec
worker-artifact-pipeline、runtime-verification-evidence（MODIFY）_worker real IFC→USDC adapter、openable model.usdc hard gate、real ifc_index / usd_index / element_mapping、one-to-many mapping schema、quality metrics、measure-first coverage report、single Kit/browser real worker artifact evidence
+
+2026-05-12-worker-mapping-lineage-quality-baselineworker-artifact-pipeline、runtime-verification-evidence、worker-demo-upload-convert-ui（MODIFY）lineage graph API、stable derived/index/mapping artifact IDs、all-IFC-entity coverage denominator、minimum_coverage_ratio=1.0 policy、warn reviewable / fail blocking readiness、storage batch evidence tier、worker UI lineage / quality view
+
-
+
規格目錄約定：
openspec/specs/<capability-id>/spec.md ← 現行權威
openspec/changes/archive/<date>-<slug>/ ← 已合併 PR 的提案／設計／tasks／當時 spec 快照
-1.5 本機環境一致性基線（2026-05-12）
+1.5 本機環境一致性基線（2026-05-12）
目的：避免「OpenSpec / smoke evidence 曾通過」與「今天本機 demo 可重新啟動」被混為一談。OpenSpec 驗證是當時 commit + 當時環境的證據；每次重新執行 demo 前，仍需確認本機 runtime dependencies 沒有 drift。
-啟動前必要條件
-
+啟動前必要條件
+
範圍
@@ -519,8 +523,8 @@ 啟動前必要條件
Invoke-WebRequest http://127.0.0.1:8001/health 等四個 endpoint
-
-已知 drift 症狀
+
+已知 drift 症狀
_bim-control / _worker:
TypeError: Router.__init__() got an unexpected keyword argument 'on_startup'
→ 通常代表 FastAPI 0.111.0 搭到 Starlette 1.x；應回到 starlette==0.37.2。
@@ -533,7 +537,7 @@ 已知 drift 症狀
'vite' is not recognized as an internal or external command
→ `node_modules` 存在但 Vite binary 缺失；重跑 npm ci。
-恢復基線命令
+恢復基線命令
.\scripts\stop-all.ps1
py -3.12 -m venv .venv
@@ -548,18 +552,18 @@ 恢復基線命令
.\scripts\start-all.ps1 -SkipStreaming
-Roadmap 判讀規則
+Roadmap 判讀規則
- §1.3 的「已驗證閉環」代表 2026-05-08 的功能證據，不代表任何日期的本機環境都可直接啟動。
- 若 health probe 失敗，先看 scripts/.run/*.log.err 與本節 drift 症狀；不要先把問題歸因為 OpenSpec 規格退化。
- Runtime evidence 更新前，PR / branch 驗證紀錄必須附上 Python package 版本、Node binary presence、start-all health result。
- 若只跑 `-SkipStreaming`，Kit / GPU / WebRTC 未啟動是預期；但 `_bim-control`、`_worker`、coordinator、viewer 四個非 Kit 服務仍必須健康。
-1.6 OpenSpec sync / archive 後 roadmap 對齊規範（2026-05-12）
+1.6 OpenSpec sync / archive 後 roadmap 對齊規範（2026-05-12）
觸發時機：任何 OpenSpec change 被正式接受、執行 sync / archive、或 openspec/specs/ 內容因 archive 產生新增 / 修改 / 移除時，都必須在同一輪文件更新中檢查本節清單。
-必更新章節
-
+必更新章節
+
章節
@@ -609,8 +613,8 @@ 必更新章節
不得讓 HTML 成為 source of truth；不得只改 HTML 而不更新 Markdown
-
-對齊檢查
+
+對齊檢查
OpenSpec archive 後，至少檢查：
1. openspec/specs/<capability-id>/spec.md 是否與 §1.2 的 capability 數量與名稱一致。
2. openspec/changes/archive/<date>-<slug>/ 是否已加入 §1.4 溯源表。
@@ -619,7 +623,7 @@ 對齊檢查
5. 若 runtime evidence 有更新，附上測試指令、日期、環境基線與證據文件路徑。
6. 重新產生同名 HTML 檢視版，確認它引用的來源檔與更新時間反映本 Markdown。
-完成定義
+完成定義
一次 OpenSpec sync / archive 完成，必須同時滿足：
- openspec/specs/ 代表最新規格權威。
- openspec/changes/archive/ 保留已接受 change 的歷史 delta。
@@ -630,8 +634,8 @@ 完成定義
2. v1 路線圖 vs 既有 specs 對照
-Phase 0：基線穩定化 — 狀態：✓ 已完成
-
+Phase 0：基線穩定化 — 狀態：✓ 已完成
+
v1 路線圖項目
@@ -656,9 +660,9 @@ Phase 0：基線穩定化 —
✓
-
-Phase 1：_worker 收攏（最優先）— 狀態：✓ 主要紅星已解除；lineage / coverage baseline 分支實作中，real batch 未鎖定
-
+
+Phase 1：_worker 收攏（最優先）— 狀態：✓ 主要紅星已解除；lineage / coverage baseline 已歸檔，real batch 未鎖定
+
v1 路線圖項目
@@ -684,19 +688,19 @@ Phase 2：檢討閉環 — 狀態：✓ 已完成並驗證
-
+Phase 2：檢討閉環 — 狀態：✓ 已完成並驗證
+
v1 路線圖項目
@@ -721,9 +725,9 @@ Phase 2：檢討閉環
✓
-
-Phase 3：Session lifecycle 核心 — 狀態：⚠ Spec 完整，dedicated multi-Kit runtime 等待 GPU 購買部署
-
+
+Phase 3：Session lifecycle 核心 — 狀態：⚠ Spec 完整，dedicated multi-Kit runtime 等待 GPU 購買部署
+
v1 路線圖項目
@@ -748,18 +752,18 @@ Phase 3 ↔ Phase 4.4 / 4.5 / 4.11 層級對照（2026-05-08 17:00 釐清 ⓜ）
+Phase 3 ↔ Phase 4.4 / 4.5 / 4.11 層級對照（2026-05-08 17:00 釐清 ⓜ）
「Phase 3 多 artifact / 多 instance 調度」與 「Phase 4.4 Multi-Kit instance 並行」不是同一件事，是同一條鏈的上下兩層；本次澄清依 MCP 對 NVIDIA Kit base extension 與 OVAS 文件的交叉驗證（詳見 §11.4）。
-
+
層級
@@ -782,7 +786,7 @@ Phase 3
可用 OVAS app instance lifecycle 接管（§11.4 / §12.2 #2A）
-
+
關鍵結論（回答使用者問題 1）：
Q：Phase 3「多 artifact / 多 instance 調度」與 Phase 4.4「Multi-Kit instance 並行」的關係？
A：上層業務 spec ↔ 下層 runtime infrastructure 的關係。
@@ -803,7 +807,7 @@ Phase 3
- 4.4 不是 #2 的子集；4.4 是 #2 的「工人」，#2 是 4.4 的「指揮」
- 兩者解耦的好處：spec 不被 OVAS 鎖死；單機 docker-compose 與 K8s OVAS 走同一個 spec
-Phase 4：高併發平台化 — 狀態：❌ 我方無 spec ⓜ；NVIDIA 官方有 reference implementation
+Phase 4：高併發平台化 — 狀態：❌ 我方無 spec ⓜ；NVIDIA 官方有 reference implementation
2026-05-08 16:30 拆分原則（依 §13 決策框架）：
@@ -814,8 +818,8 @@ Phase 4 細項清單（11 項）
-
+Phase 4 細項清單（11 項）
+
#
@@ -928,7 +932,7 @@ Phase 4 細項清單（11 項）
P2.5 候選 #2A；GPU 購買部署且 #2 runtime evidence land 後再開
-
+
整體採用比例：
@@ -939,7 +943,7 @@ Phase 4 細項清單（11 項）
Gap：候選 #2 的 dedicated_instance routing 必須等 GPU 購買與部署完成、可提供至少兩個 GPU-backed Kit endpoints 後再執行；完成前 #2A（OVAS）維持「探索性 spike，不開新 spec」，不得把 dedicated multi-Kit runtime 視為已在驗證中。
-Phase 5：Omniverse 平台能力最大化 — 狀態：❌ 我方無 spec ⓜ；Kit base 多數能力已內建，只缺 IFC / sensor / 環境模擬
+Phase 5：Omniverse 平台能力最大化 — 狀態：❌ 我方無 spec ⓜ；Kit base 多數能力已內建，只缺 IFC / sensor / 環境模擬
2026-05-08 16:30 拆分原則（依 §13 決策框架）：
@@ -949,12 +953,12 @@ Phase 5 細項清單（18 項）
+Phase 5 細項清單（18 項）
欄位語意：「採用順序」✅ 全採用 NVIDIA / ⚠ NVIDIA 為主 + 自主 fallback 或漸進採用 / ❌ NVIDIA 無對應，必須自建。
-A. 物理與模擬（PhysX 系列；不可能自製）
-
+A. 物理與模擬（PhysX 系列；不可能自製）
+
#
@@ -995,9 +999,9 @@ A. 物理與模擬（Phy
❌ 未啟用；與 #5（ai-rule contract）結合輸出規則檢查結果
-
-B. 渲染與材質（RTX / MDL；不可能自製）
-
+
+B. 渲染與材質（RTX / MDL；不可能自製）
+
#
@@ -1047,9 +1051,9 @@ B. 渲染與材質（RTX / MD
❌ 未啟用；app .kit 加 dep
-
-C. 多人協作（USD live layer；NVIDIA 已有 + 與我們 Socket.IO 重疊）
-
+
+C. 多人協作（USD live layer；NVIDIA 已有 + 與我們 Socket.IO 重疊）
+
#
@@ -1099,9 +1103,9 @@
#1A 依賴；未啟動
-
-D. 領域邏輯（NVIDIA 沒有覆蓋；必須自建）
-
+
+D. 領域邏輯（NVIDIA 沒有覆蓋；必須自建）
+
#
@@ -1151,9 +1155,9 @@ D. 領域邏輯（NVIDI
P2 候選 #5
-
-E. Sensor / Synthetic Data（NVIDIA 有，但需獨立部署）
-
+
+E. Sensor / Synthetic Data（NVIDIA 有，但需獨立部署）
+
#
@@ -1185,9 +1189,9 @@ E. Sensor / Synth
❌ 未啟用
-
-F. 大型場景（USD 標準；已有 spec）
-
+
+F. 大型場景（USD 標準；已有 spec）
+
#
@@ -1210,7 +1214,7 @@ F. 大型場景（USD 標準；
✓ 我們有 streaming-multi-layer-payload-loading spec
-
+
整體採用比例（共 18 項，A/B/C/D/E/F 六類）：
@@ -1225,11 +1229,11 @@ F. 大型場景（USD 標準；
- #1（IFC pipeline）已於 2026-05-11 archive；#5（ai-rule contract）仍在 P2 候選清單內，本次拆分不改其優先級。
-Phase 6：Production & SaaS 營運 — 狀態：⏸ 等待公司的業務系統接入；目前不規劃 OpenSpec spec
+Phase 6：Production & SaaS 營運 — 狀態：⏸ 等待公司的業務系統接入；目前不規劃 OpenSpec spec
2026-05-08 16:05 決策：依使用者明確指示，Phase 6 所有細部項目即使技術成熟，也暫不啟動 OpenSpec change；等到公司端確認業務系統（CRM / SSO / billing / IT 維運 SLA）接入時程後，才會逐項開 explore。本表只列「分類」與「對應業務系統觸發點」。
-
+
細部項目
@@ -1336,13 +1340,13 @@ 3. v2 6 層架構 vs 現況對照
-
+
Layer
@@ -1382,13 +1386,13 @@ 3. v2 6 層架構 vs 現況對照
⚠ Workflows + runtime-verification-evidence 是雛形；K8s / SLA / Backup 未做
-
+
-4. IFC → USD 品質保護管線（v2 紅星風險點）
+4. IFC → USD 品質保護管線（v2 紅星風險點）
v2 圖右側標：「★ 這是目前最重要的技術風險控制點 ★」
-
+
#
@@ -1441,8 +1445,8 @@ 4. IFC → USD 品質
MEDIUM
-
-結論（2026-05-12 對齊）：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 worker-real-conversion-quality 解除。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline；該門檻與 failure policy 改由候選 #3A worker-mapping-quality-baseline 鎖定。
+
+結論（2026-05-12 對齊）：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 worker-real-conversion-quality 解除；lineage API 與 all-IFC-entity mapping quality policy 已由 worker-mapping-lineage-quality-baseline 歸檔。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline，直到 canonical storage real batch 通過並鎖定 evidence。
5. 下一階段 OpenSpec change 候選清單
每一個候選都遵守：
@@ -1450,9 +1454,9 @@ 5. 下一階段 OpenSpec ch
- 每個候選都列 KPI、風險等級、衝擊面、最小驗證指令。
- 候選不重疊；若新候選含已歸檔 spec 範圍，會用 ADD/MODIFY/REMOVE 注記。
-5.0 已完成 / Archived
-已歸檔 #1：worker-real-conversion-quality
-
+5.0 已完成 / Archived
+已歸檔 #1：worker-real-conversion-quality
+
項目
@@ -1498,13 +1502,13 @@ 已歸檔 #1：worker-
剩餘限制
-Coverage 仍是 measure-first；尚未鎖 production 最低 mapping coverage hard gate。此限制改由候選 #3A worker-mapping-quality-baseline 承接，不重開 #1
+Coverage policy 已定義為 all-IFC-entity + minimum_coverage_ratio=1.0，但 canonical 13-file real batch 未完成；尚未鎖 production 最低 mapping coverage hard gate。不重開 #1 / #3 / #3A，後續補 evidence 即可
-
-5.1 P0-hold（等待 GPU 購買部署）
-候選 #2：streaming-multi-instance-orchestration
-
+
+5.1 P0-hold（等待 GPU 購買部署）
+候選 #2：streaming-multi-instance-orchestration
+
項目
@@ -1557,53 +1561,10 @@ 候選 #2：strea
GPU 購買與部署完成前維持 ⏸；重啟驗證後才更新 §1.3 / §2 Phase 3 / §9.2 與 runtime-verification-evidence
-
-5.2 P1（這月）
-候選 #3：worker-artifact-lineage-api
-
-
-
-項目
-內容
-
-
-
-
-目標
-把現有 metadata.json 中 parent_artifact_id / conversion_job_id 整理成可查詢的 lineage graph API；worker UI 視覺化三層關係
-
-
-解決的 v1 phase / v2 layer
-Phase 1 / Layer 3-B
-
-
-repo 邊界
-只動 _worker/；UI 改動限於 _worker/app/static/
-
-
-風險
-MEDIUM（API shape 設計影響後續 Layer 5 audit log）
-
-
-KPI
-1) GET /api/artifacts/{id}/lineage 回完整祖系 + 子代鏈；2) worker UI 顯示 source → derived → mapping 三層樹；3) 既有 worker pytest 全綠
-
-
-驗證指令
-cd _worker && python -m pytest tests + browser open /ui/lineage
-
-建議 spec id
-worker-artifact-lineage-api
-
-與既有 spec 關係
-MODIFY worker-artifact-pipeline Req4 versioned object layout（補 lineage query semantics）
-
-
-
-候選 #3A：worker-mapping-quality-baseline
-
+
+5.2 P1（這月）
+已完成：候選 #3 / #3A 合併為 worker-mapping-lineage-quality-baseline
+
項目
@@ -1612,41 +1573,29 @@ 候選 #3A：worker-map
-目標
-將 #1 archive 後保留的 measure-first mapping coverage 轉成可審查 baseline：定義最低 coverage threshold、material / prim fidelity smoke criteria、低 coverage 的 failure / warn policy，以及 issue → real prim highlight 可接受門檻
+Archive
+openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/
-解決的 v1 phase / v2 layer
-Phase 1 quality gate / Layer 3-B
+涵蓋原候選
+#3 worker-artifact-lineage-api + #3A worker-mapping-quality-baseline
-repo 邊界
-主要動 _worker/ 與 verification docs；若需要 viewer smoke，只作 evidence consumer，不讓 viewer 接管 mapping ownership
+已併入 specs
+worker-artifact-pipeline、runtime-verification-evidence、worker-demo-upload-convert-ui
-風險
-MEDIUM（過早鎖門檻可能讓不同 IFC 類型誤 fail；需先用至少 2-3 個 fixture 校準）
+已完成
+lineage graph API、stable mapping/index derived artifact IDs、worker UI lineage / quality view、all-IFC-entity coverage denominator、minimum_coverage_ratio=1.0 policy、warn reviewable / fail blocking readiness、storage batch helper
-KPI
-1) runtime-verification-evidence 明確記錄 minimum_coverage_locked=true 的條件；2) _worker conversion quality report 區分 pass / warn / fail；3) issue highlight smoke 使用 real IFC GUID → USD prim path；4) baseline fixture evidence 不低於門檻
-
-
-驗證指令
-cd _worker && python -m pytest tests + real conversion smoke + single Kit/browser issue highlight smoke（有 GPU 時）
-
-建議 spec id
-worker-mapping-quality-baseline
-
-與既有 spec 關係
-MODIFY worker-artifact-pipeline real mapping quality gate；MODIFY runtime-verification-evidence real conversion quality metrics
+仍未宣稱完成
+canonical 13-file real batch 未完成；minimum_coverage_locked=true production baseline 與 issue → real prim verified evidence 尚未成立
-
-候選 #4：coordinator-session-lifecycle-events-audit
-
+
+候選 #4：coordinator-session-lifecycle-events-audit
+
項目
@@ -1687,10 +1636,10 @@ 候選 #4：c
MODIFY review-session-request-lifecycle Req4「lifecycle 顯式」+ ADD audit event schema
-
-5.3 P2（下月）
-候選 #5：ai-rule-carbon-result-contract
-
+
+5.3 P2（下月）
+候選 #5：ai-rule-carbon-result-contract
+
項目
@@ -1731,9 +1680,9 @@ 候選 #5：ai-rule-carbo
ADD（新 spec）
-
-候選 #6：notification-webhook-service
-
+
+候選 #6：notification-webhook-service
+
項目
@@ -1774,9 +1723,9 @@ 候選 #6：notification-we
ADD（新 spec），依賴 #4 lifecycle event schema
-
-候選 #7：tenant-rbac-foundation
-
+
+候選 #7：tenant-rbac-foundation
+
項目
@@ -1817,10 +1766,10 @@ 候選 #7：tenant-rbac-foundatio
MODIFY 多個 spec（review-session-request-lifecycle、worker-artifact-pipeline、session-first-review-viewer）
-
-5.4 P3（季度）
-候選 #8：observability-audit-baseline
-
+
+5.4 P3（季度）
+候選 #8：observability-audit-baseline
+
項目
@@ -1853,9 +1802,9 @@ 候選 #8：observability-a
observability-audit-baseline
-
-候選 #9：production-deployment-baseline
-
+
+候選 #9：production-deployment-baseline
+
項目
@@ -1880,13 +1829,16 @@ 候選 #9：production-de
production-deployment-baseline
-
+
6. 優先順序總結
Archived / 已完成:
#1 worker-real-conversion-quality ✓ 已於 2026-05-11 archive
解除 IFC→USDC placeholder blocker；real worker-produced USDC 已有 single Kit/browser evidence
- 剩餘：coverage baseline 門檻仍是 measure-first，待後續 spec 鎖定
+ 剩餘：canonical storage real batch 未完成，production coverage baseline 未鎖定
+ #3/#3A worker-mapping-lineage-quality-baseline ✓ 已於 2026-05-12 archive
+ lineage API / worker UI / all-IFC-entity coverage policy 已併入 specs
+ 剩餘：canonical 13-file real batch 未完成，production coverage baseline 未鎖定
P0-hold (等待 GPU 購買與部署):
#2 streaming-multi-instance-orchestration ★★ ⏸ 等待 GPU 購買與部署後執行
@@ -1895,8 +1847,6 @@ 6. 優先順序總結
roadmap 端：GPU capacity 到位後才重啟驗證並同步 §1.3 / §2 / §9.2
P1 (這月):
- #3 worker-artifact-lineage-api 收斂 lineage 為 query API
- #3A worker-mapping-quality-baseline 鎖定 #1 archive 後仍 measure-first 的 mapping coverage / issue highlight 門檻
#4 coordinator-session-lifecycle-events-audit 事件 schema 收斂（為 #6 webhook 鋪路；audit log 持久化屬 Phase 6 凍結）
P2 (下月):
@@ -1918,14 +1868,14 @@ 6. 優先順序總結
依賴圖（粗線是強依賴；⏸ 表示等業務接入才解凍）：
#1 (✓ archived) ─┬─→ Kit GPU render 證據已解鎖
├─→ Phase 5 可用 real worker-produced USDC 作前提
- ├─→ #3A mapping coverage / issue highlight baseline 鎖門檻
- └─→ #3 lineage API 將 metadata lineage 變成可查詢圖
+ └─→ #3/#3A (✓ archived) lineage API + all-IFC-entity coverage policy
#2 (⏸ 等待 GPU 購買與部署)
─→ GPU-backed multi-instance routing 證據解鎖
─→ #2A (OVAS Helm 升級需要先在已部署 GPU capacity 上跑通多 Kit)
-#3 ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
+#3/#3A (✓ archived) ─→ 後續只剩 canonical storage real batch 與 issue highlight evidence
+ ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
#4 ─→ #6 mock webhook (P2 可探索)
─→ ⏸ #8 audit (Phase 6 凍結)
@@ -1936,7 +1886,7 @@ 6. 優先順序總結
7. 風險與 trade-off
-
+
#
@@ -1948,7 +1898,7 @@ 7. 風險與 trade-off
R1
#1 已選 IfcOpenShell + usd-core 作為 real IFC→USDC adapter external prerequisites，後續仍有 dependency / license / Windows runtime drift 風險
-保持 adapter boundary，不讓 _worker contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。Coverage baseline 仍採 measure-first，待後續 spec 鎖最低門檻
+保持 adapter boundary，不讓 _worker contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。#3/#3A 已定義 all-IFC-entity coverage policy，但 canonical storage real batch 未完成前不得把 production baseline 標成 locked
R2
@@ -2001,7 +1951,7 @@ 7. 風險與 trade-off
每次 archive 後依 §1.6 檢查並更新本文件；若沒有新的 runtime evidence，不得把 §1.3 標成 passed；若候選已 archive，必須更新 §5 / §10，避免已完成工作仍留在 P0/P1
-
+
8. 不在這次規劃範圍
- 本文件不直接創建 OpenSpec change folder；那是 explore / propose 的工作。
@@ -2016,11 +1966,11 @@ 9. Phase 4 / Phase 5 硬體配置
適用範圍：本節只規劃 Phase 4（高併發平台化）與 Phase 5（Omniverse 平台能力最大化）兩階段的硬體；Phase 6（K8s / Backup / SLA）的硬體配置會在 production-deployment-baseline spec 階段才細化。
2026-05-08 更新：交叉驗證並改寫整個 §9；新增 §9.0 釐清 NVIDIA 語意（kit.exe = OS process；Multi-Kit = 多進程／多容器；primary／spectator／AOV = 同一進程內可多 signaling endpoint）。依據 OVAS Overview、omni.services.livestream.webrtc 文件、本機 kit-mcp／usd-code-mcp、bim-streaming-server/SYSTEM_DESIGN.md。
-9.0 NVIDIA／Omniverse 對齊：kit.exe、Kit instance、WebRTC endpoint、GPU（2026-05-08 交叉驗證）
+9.0 NVIDIA／Omniverse 對齊：kit.exe、Kit instance、WebRTC endpoint、GPU（2026-05-08 交叉驗證）
為何需要本節：舊稿將「1 GPU 可跑多少 Kit」講得過簡，容易被誤讀成「一個 kit.exe 進程底下還能掛多台 獨立 Omniverse streaming app／每台各有獨立 framebuffer」，因而與 NVIDIA 官方模型不符。以下將語意收斂到 OVAS + Kit livestream extension 官方文件 + 本 repo SYSTEM_DESIGN.md，並以本機 kit-mcp:9902、usd-code-mcp:9903 做輔助查證。
-驗證來源（工具與文件）
+驗證來源（工具與文件）
- NVIDIA Kit App Streaming (OVAS) Overview：
https://docs.omniverse.nvidia.com/ovas/latest/index.html
（Kubernetes 上對 containerized Kit apps 做 registration / configuration / lifecycle management，
@@ -2038,8 +1988,8 @@ 驗證來源（工具與文件）
- 本 repo：`bim-streaming-server/SYSTEM_DESIGN.md` 假設 6「One Kit process = one stage = one user session」
-A. 名詞對照表（本 roadmap 建議用法）
-
+A. 名詞對照表（本 roadmap 建議用法）
+
名詞
@@ -2069,8 +2019,8 @@ A. 名詞對照表（本 roa
「多個瀏覽器／tab 一定要連不同埠」——實務上 多個 PeerConnection 可對同一 signaling endpoint；只有在你切到 spectator／AOV 或 另一個 Kit 進程 時才會出現 第二個以上的 signalPort
-
-B. 官方架構結論（回答「一個 GPU 怎麼管多台 Kit？」）
+
+B. 官方架構結論（回答「一個 GPU 怎麼管多台 Kit？」）
1) 橫向擴展（真・多台 Kit／多個獨立 framebuffer／多個獨立 stage 負載）
= 多個 Kit Application Instance = 多個 OS process／containers。
OVAS 負責這些 container 的 lifecycle（對齊 Overview 原文）。
@@ -2085,9 +2035,9 @@ B. 官方架
- 連到「同一 Kit instance、不同 spectator／AOV」：會看到 **多組 stream 設定／埠位**（REST `/api/stream-config`／下拉選單）。
- 連到「不同 Kit instance（不同 routing slot）」：Tier A 需要 **不同 signaling port pair**（或由 OVAS／LB 做路由）；這才是 dedicated_instance／GPU pool 意義上的 scale-out。
-C. 與下文容量表的銜接
+C. 與下文容量表的銜接
後文若未另加注，**「並發 Kit instance／並發 review streaming slot」**預設指 「獨立 Kit Application Instance（獨立 kit.exe／container）× 單一載入場景」，對齊 SYSTEM_DESIGN.md 與 §11.4（NVIDIA Multi‑Kit／OVAS 語意）。Spectator／AOV應視為 同一進程內附加 encoder／頻寬／VRAM 成本，不得直接當成「又多一台 Kit」來套 (VRAM ÷ 3 GB) 公式。
-9.1 規格依據（來自 SYSTEM_DESIGN.md §3 / §9）
+9.1 規格依據（來自 SYSTEM_DESIGN.md §3 / §9）
- Per-session VRAM 硬上限 : 3 GB（Kit + Hydra + RTX + 平均 USD 500 MB）
- Per-session VRAM 峰值 : 5 GB（USD 峰值 2 GB 時）
- 1 GPU 可同時跑的獨立 Kit 進程（Kit Application Instance）粗算上界 : VRAM // 3 GB（保留 1-2 GB 給 driver / NVENC / overhead）
@@ -2099,8 +2049,8 @@ 9.1 規格依據（來自 S
- WebRTC 預設頻寬 : 5 Mbps / session（720p/1080p simulcast）
- TURN relay 比例 : 20-30%（企業內網需要 TURN cluster）
-9.2 開發階段（單機）：極限配置
-現況基線（已量測）
+9.2 開發階段（單機）：極限配置
+現況基線（已量測）
GPU : NVIDIA GeForce RTX 4060 Ti
VRAM : 8188 MiB（≈ 8 GB）
Driver : 580.97
@@ -2109,8 +2059,8 @@ 現況基線（已量測）
dedicated_instance 驗證（2026-05-12）: 等待 GPU 購買與部署後執行
→ 在 main 上現況只驗到 same_instance routing；dedicated_instance 證據必須等 GPU 購買與部署完成、具備至少兩個 GPU-backed Kit endpoints 後才重啟驗證。完成前 runtime-verification-evidence §6.4 應維持 deferred pending capacity，不得標為 passed / failed / in-progress。
-開發階段「最大限度」單機配置（建議）
-
+開發階段「最大限度」單機配置（建議）
+
元件
@@ -2169,7 +2119,7 @@ 開發階段「最大限
Ubuntu 24.04 LTS（更多 Kit headless 測試）
-
+
為什麼挑這個推薦：
- 24 GB VRAM 是「解開 #2 streaming-multi-instance-orchestration P0 候選」的最小門檻。
SYSTEM_DESIGN §3 直接寫 A10G/L4-class 24 GB → 4-8 concurrent Kit sessions。RTX 4090 / 5090 在 24-32 GB 級距上等價 A10G。
@@ -2177,7 +2127,7 @@ 開發階段「最大限
- 2 TB Gen4 SSD 是因為 USD local cache（
SYSTEM_DESIGN §11）+ 10 個並行 conversion job 的中間檔，1 TB 在 demo 用沒問題、但跑 worker-real-conversion-quality benchmark 會打爆。
- WSL2 是讓 Linux Kit instance 與 Windows Kit instance 能在同一台機器並存，方便驗證跨平台 routing。
-Phase 4「最大化」單機可達上限（24 GB GPU）
+Phase 4「最大化」單機可達上限（24 GB GPU）
Kit Streaming（GPU） : 6-9 個獨立 Kit 進程／容器（各 ≈ 1 × Kit Application Instance；假設每進程 1 × stage、per-slot 3 GB VRAM cap）
Conversion Worker : 4 個 IFC→USDC parallel job（CPU only，不吃 VRAM）
Coordinator : 1 個 Node 進程
@@ -2192,11 +2142,11 @@ Phase 4「最大化」
→ 若 routing policy 要求 **每個 session 一台獨立 Kit**，則「並發 review session」上限才會逼近 Kit 進程數。
→ 適合 1-3 名開發者本機壓測 P1/P2 候選 spec
-Phase 5「最大化」單機可達上限（含 NVIDIA 真實 extension 對應 ⓜ）
+Phase 5「最大化」單機可達上限（含 NVIDIA 真實 extension 對應 ⓜ）
本表已對照 kit-mcp:9902 查得的 Kit base extension 真實版本（2026-05-08 查詢）。「需自建」表示 Kit base 沒有對應 extension，必須在 bim-streaming-server 自寫 Kit extension 或引入第三方。
-
+
Phase 5 能力
@@ -2267,8 +2217,8 @@ omni.kit.usd.layers.LiveSyncing / omni.kit.usd.layers.LiveSession
-
-本機開發版「Phase 5 啟用清單」（建議 bim-streaming-server 加進 .kit 檔）
+
+本機開發版「Phase 5 啟用清單」（建議 bim-streaming-server 加進 .kit 檔）
[dependencies]
# 基線（已存在）
"omni.kit.livestream.webrtc" = { version = "9.0.2" }
@@ -2294,8 +2244,8 @@ 9.3 SaaS 等級（中小型工作室）：cluster 配置
-規模假設（依 SYSTEM_DESIGN §3 + 中小型工作室常見比例）
+9.3 SaaS 等級（中小型工作室）：cluster 配置
+規模假設（依 SYSTEM_DESIGN §3 + 中小型工作室常見比例）
工作室人數 : 10-50 名建築師 / BIM 工程師 / 審查員
日活躍使用者 DAU : 8-30 名
並發審查 session : 5-15 個（高峰期）
@@ -2307,8 +2257,8 @@ 規模
AI 規則 / 碳排檢查 : 每 review session 1-3 次
依 SYSTEM_DESIGN §3 「500 peak concurrent sessions ÷ 6 per GPU ≈ 85 GPU instances」反推：15 並發 session ÷ 6 per GPU ≈ 2.5 GPU host。
-Tier A：最小可行（5-10 並發 session，10-20 人工作室）
-
+Tier A：最小可行（5-10 並發 session，10-20 人工作室）
+
Layer
@@ -2376,10 +2326,10 @@ Tier A：最
不含備援；停一台會降級不會停服
-
+
→ Tier A 容量：12-16 並發 session、40-60 並發 viewer、日 100 conversion；高峰時無冗餘。
-Tier B：推薦平衡（10-15 並發 session，20-50 人工作室）
-
+Tier B：推薦平衡（10-15 並發 session，20-50 人工作室）
+
Layer
@@ -2450,9 +2400,9 @@ Tier B：
—
-
+
→ Tier B 容量：18-24 並發 session、80-120 viewer、日 500 conversion；單台失效不停服。
-Tier C：成長型（多區域，準備擴 Phase 6）
+Tier C：成長型（多區域，準備擴 Phase 6）
- GPU host: 5+ 台（含 1 台 H100/H200 80 GB 跑 Phase 5 重模擬 / AI inference）
- 加 K8s control plane（3 master + 5 worker）
- 加多 region TURN（國內 + 海外）
@@ -2460,11 +2410,11 @@ Tier C：成長型（多
- 物件儲存改 distributed MinIO 或外接 AWS S3
→ 進到 Tier C 就應啟動候選 #9 production-deployment-baseline，本節不展開。
-中小型工作室「Phase 5 啟用清單」（依 NVIDIA OVAS reference impl ⓜ）
+中小型工作室「Phase 5 啟用清單」（依 NVIDIA OVAS reference impl ⓜ）
基準：Kit 5 streaming server 應該以 NVIDIA Omniverse Kit App Streaming (OVAS) 作為 reference implementation；OVAS 在 NGC Collection（nvidia/omniverse/kit-appstreaming-collection）已提供 Helm chart、container images、API gateway 設定。我們的 bim-streaming-server 是 OVAS 的「自建單節點精簡版」，Tier B/C 直接走 OVAS K8s 模式可大幅縮短 Phase 4 平台化的工程時間。
-
+
Phase 5 能力
@@ -2529,8 +2479,8 @@
NGC kit-appstreaming-collection；K8s + API gateway + LB；對應候選 #2 升級到 #9
-
-中小型工作室部署藍圖（Tier B + Phase 5 對應）
+
+中小型工作室部署藍圖（Tier B + Phase 5 對應）
[ Browser users ]
│
▼
@@ -2567,7 +2517,7 @@ 中小型工作室
- Conversion 走 IFC 自建（IfcOpenShell）+ Kit 官方 omni.services.convert.cad（DGN/JT/HOOPS）
- Per-AOV streaming 是進階選項，不影響基礎審查流程
-9.4 GPU Pool 容量計算公式
+9.4 GPU Pool 容量計算公式
slots_per_host = floor( (VRAM_GB - reserve_GB) / per_session_VRAM_GB )
reserve_GB:
@@ -2589,8 +2539,8 @@ 9.4 GPU Pool 容量計算公式
L40S 48 GB Linux 含 PhysX : (48-1.5)/4 = 11
H100 80 GB Linux 含 PhysX + MDL : (80-2)/4.5 = 17
-9.5 網路 / 儲存 / 備援邊界
-
+9.5 網路 / 儲存 / 備援邊界
+
軸
@@ -2643,8 +2593,8 @@ 9.5 網路 / 儲存 / 備援邊界
streaming replication + 異地 backup
-
-9.6 升級觸發條件（什麼時候從 Tier A → B → C）
+
+9.6 升級觸發條件（什麼時候從 Tier A → B → C）
A → B 觸發：
- 並發 session 高峰連續 2 週 > 8（80% 容量）
- GPU 容量不足拒絕的 review session > 2 件 / 週
@@ -2656,8 +2606,8 @@ 9.6 升級觸發條
- 出現需要 H100 級 GPU 的 Phase 5 工作負載（如全屋 CFD）
- SLA 承諾上修到 99.9%
-9.7 預算粗估（僅供決策參考，硬體價格波動大）
-
+9.7 預算粗估（僅供決策參考，硬體價格波動大）
+
Tier
@@ -2687,10 +2637,10 @@ 9.7 預算粗
NT$ 25-50 萬（Tier B 等價）
-
+
→ 中小型工作室建議：先雲端 Tier A（縮短 time-to-value），驗證 12 並發 session 穩定後再評估自建 Tier B。
-9.8 與 OpenSpec 候選的對應
-
+9.8 與 OpenSpec 候選的對應
+
候選
@@ -2750,12 +2700,12 @@ 9.8 與 OpenSpec 候選的對應
Tier B 起（單機可先用 kind / minikube 驗 chart）；不等 #9 解凍即可探索
-
+
#2 ↔ #2A 的層級關係（2026-05-08 17:00）：#2 解 §2 Phase 3 業務語意層（routing decision + kit_instance_bindings 紀錄）；#2A 解 §2 Phase 4.4 / 4.5 / 4.11 runtime infrastructure 層（OVAS 接管 Kit container lifecycle）。採用 OVAS 後 bim-review-coordinator/src/services/kitPool.ts 變 thin client（call OVAS REST app instance API），spec 只需 1 個 MODIFY（Req2 provider enum 擴 "ovas"），其他 4 個 Req 不變。完整影響表見 §12.2、官方定義見 §11.4。
-10. 建議的下一步（給 monkey1sai）
+10. 建議的下一步（給 monkey1sai）
-
先恢復並鎖定本機環境一致性（新增，2026-05-12）：
@@ -2766,11 +2716,20 @@ 10. 建議的下一步（給 monke
-
-
確認 #1 archive 對齊已完成，後續不再重開 worker-real-conversion-quality：
+確認 #1 與 #3/#3A archive 對齊已完成，後續不再重開已完成 change：
#1 worker-real-conversion-quality 已歸檔到 openspec/changes/archive/2026-05-11-worker-real-conversion-quality/。- 現行 specs 已同步到
worker-artifact-pipeline 與 runtime-verification-evidence。
-- 下一步若要提升品質，不是重開 #1，而是另開 #3A
worker-mapping-quality-baseline（mapping coverage / material fidelity / issue highlight 門檻）或 #3 worker-artifact-lineage-api（lineage API / UI）等更小 spec。
+#3/#3A worker-mapping-lineage-quality-baseline 已歸檔到 openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/，並同步到 worker-artifact-pipeline、runtime-verification-evidence、worker-demo-upload-convert-ui。- 後續若要提升品質，不重開 #1 / #3 / #3A；改以 canonical storage batch completion 或 issue highlight evidence 作為下一個更小切片。
+
+
+-
+
下一個 worker 品質工作：補 canonical storage 13-file real batch evidence：
+
+- 使用
C:\Repos\active\iot\AI-BIM-governance\storage\*.ifc 作為正式本機 fixture root。
+- 先解決 89MB fixture
--limit 1 超過 600s timeout 的 runtime / performance 問題，再擴到 13-file batch。
+- 只有全批次 real conversion、USDC openability、lineage API、all-IFC-entity coverage 都通過時，才可把
minimum_coverage_locked=true production baseline 寫入 evidence。
-
@@ -2783,12 +2742,11 @@
10. 建議的下一步（給 monke
-
-
挑一個 P1 候選啟動 OpenSpec explore：
+下一個 P1 OpenSpec 候選以 #4 coordinator-session-lifecycle-events-audit 為主：
-- 推薦在
#3 worker-artifact-lineage-api、#3A worker-mapping-quality-baseline 與 #4 coordinator-session-lifecycle-events-audit 三選一。
-- 若要延續 #1 的 worker 成果並處理 archive 後的品質 gap，優先
#3A：把 mapping coverage / material fidelity / issue highlight 門檻從 measure-first 變成 baseline。
-- 若要強化 artifact traceability，選
#3：把 source → derived → mapping lineage 從 metadata 變成可查詢 API / worker UI。
+- #3 / #3A 已完成並歸檔，不再列為候選池。
- 若要支撐後續 webhook / observability，選
#4：把 lifecycle events 收斂成 append-only event schema。
+- 若要先補 worker evidence，不開新 spec，優先延續現行
runtime-verification-evidence 的 canonical storage batch evidence。
-
@@ -2832,7 +2790,7 @@
10. 建議的下一步（給 monke
-11. Phase 4 / Phase 5 NVIDIA 真實能力對應（2026-05-08 MCP + 官方文件查詢）
+11. Phase 4 / Phase 5 NVIDIA 真實能力對應（2026-05-08 MCP + 官方文件查詢）
查詢來源：
@@ -2842,7 +2800,7 @@ 11.1 MCP server 載入步驟（給後續 session 沿用）
+11.1 MCP server 載入步驟（給後續 session 沿用）
# 1. 確認 container 已在跑
docker ps --filter "name=kit-mcp" --filter "name=usd-code-mcp"
@@ -2854,7 +2812,7 @@ 11.1 MCP server
Invoke-WebRequest http://127.0.0.1:9902/health # {"status":"healthy",...}
Invoke-WebRequest http://127.0.0.1:9903/health
-Streamable HTTP MCP 直接呼叫範例（不靠 Cursor MCP catalog）
+Streamable HTTP MCP 直接呼叫範例（不靠 Cursor MCP catalog）
# 三步握手 (initialize → notifications/initialized → tools/call)，必帶 Accept: application/json, text/event-stream
$h = @{ "Accept" = "application/json, text/event-stream"; "Content-Type" = "application/json" }
$init = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"x","version":"1"}}}'
@@ -2866,7 +2824,7 @@ Stream
Invoke-WebRequest -Uri http://127.0.0.1:9902/mcp -Method POST -Headers $h2 `
-Body '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_kit_extensions","arguments":{"query":"physx","top_k":5}}}' -UseBasicParsing
-若要把它們加進 Cursor 設定（推薦做法）
+若要把它們加進 Cursor 設定（推薦做法）
Cursor MCP catalog 不含這兩個 server（mcp-find 結果為空）。直接用 streamable HTTP URL 加進 user / project mcp.json：
@@ -2877,9 +2835,9 @@ 若要把它們加進
}
}
-11.2 兩個 MCP server 的工具能力總覽
-kit-mcp（port 9902）— Kit 開發 / extension 知識庫
-
+11.2 兩個 MCP server 的工具能力總覽
+kit-mcp（port 9902）— Kit 開發 / extension 知識庫
+
工具
@@ -2908,9 +2866,9 @@ kit-mcp（port 9902）
列出 extension 提供的 Python API
-
-usd-code-mcp（port 9903）— USD code / 文件知識庫
-
+
+usd-code-mcp（port 9903）— USD code / 文件知識庫
+
工具
@@ -2945,10 +2903,10 @@ usd-code-mcp（port 990
—
-
-11.3 MCP 查詢結果摘要（驅動 §2 / §3 / §9 校正的依據）
-A. Phase 4 — 平台化（NVIDIA 真實 reference impl）
-
+
+11.3 MCP 查詢結果摘要（驅動 §2 / §3 / §9 校正的依據）
+A. Phase 4 — 平台化（NVIDIA 真實 reference impl）
+
主題
@@ -2981,7 +2939,7 @@ A. Phase 4 — 平台
omni.services.convert.cad v507.1.5（FastAPI-style service；POST request 送 import_path / output_path / converter_options；可 container 部署 + TAAS / Farm 整合）
-
+
對 P0 候選的影響：
#2 streaming-multi-instance-orchestration:
不要重新發明輪子。OVAS 已經是 NVIDIA 自家的 K8s reference，
@@ -2993,8 +2951,8 @@ A. Phase 4 — 平台
暗示我們的 _worker 可以演進成「Kit service extension + FastAPI 包裝」混合，
而非純 Python FastAPI app。但**只支援 DGN/JT/HOOPS**，IFC 仍需自建。
-B. Phase 5 — Omniverse 平台能力最大化（NVIDIA 真實 extension）
-
+B. Phase 5 — Omniverse 平台能力最大化（NVIDIA 真實 extension）
+
Phase 5 主題
@@ -3023,9 +2981,9 @@ B. Ph
omni.kit.usd.layers.LiveSyncing / omni.kit.usd.layers.LiveSession（限制：Presence Layer 只在 Root Layer 進入 Live Session 時建立）
-
-C. 關鍵缺口（Kit base 沒有，必須自建或第三方）
-
+
+C. 關鍵缺口（Kit base 沒有，必須自建或第三方）
+
缺口
@@ -3050,14 +3008,14 @@ C. 關鍵缺口
OVAS Helm chart（NGC kit-appstreaming-collection）— 詳見 §11.4
-
-11.4 NVIDIA 對「Multi-Kit Instance 並行」的官方定義（2026-05-08 17:00）
+
+11.4 NVIDIA 對「Multi-Kit Instance 並行」的官方定義（2026-05-08 17:00）
與 §9 的關係：§9.0–§9.2 把 kit.exe／進程／signalPort／spectator／AOV 與「Multi‑Kit instance」的硬體容量語意對齊；本節保留 OVAS／Kit App Instance／業務層 vs runtime 層 的完整論述。
來源：MCP kit-mcp search_kit_extensions 結果 + NVIDIA OVAS 官方文件 Overview / Get Started 頁。
-A. 名詞定義（NVIDIA 官方語意）
-
+A. 名詞定義（NVIDIA 官方語意）
+
術語
@@ -3087,8 +3045,8 @@ A. 名詞定義（NVIDIA 官方語
候選 #2A 預定接管的範圍（取代自寫 KitInstancePool）
-
-B. NVIDIA 對「Multi-Kit instance 並行」的定義
+
+B. NVIDIA 對「Multi-Kit instance 並行」的定義
官方語意：
「同時運行多個 Kit Application Instance container，
每個 instance 是一個獨立的 application framebuffer，
@@ -3109,7 +3067,7 @@ B. NVIDIA 對「Multi-
4. Kit base extension 只提供「單 instance 內」的 livestream session control（omni.services.livestream.session）；
**沒有任何 Kit base extension 跨 instance 做 lifecycle / pool / scheduling**（MCP 已驗證）。
-C. 對應到我們現況的層級
+C. 對應到我們現況的層級
flowchart TB
subgraph BIZ["業務語意層（自家 spec；NVIDIA 不管）"]
S1["multi-artifact-kit-routing<br/>Req3: routing_policy<br/>same/dedicated/shared_state"]
@@ -3130,7 +3088,7 @@ C. 對應到我們現況的層級
OVAS -.-> K2
S3 -.->|多 Kit 服務同一 session<br/>collaboration 由 coordinator 廣播| OVAS
-D. 關鍵結論（對使用者問題的直接回答）
+D. 關鍵結論（對使用者問題的直接回答）
結論 1：可以用 OVAS app instance lifecycle 達到「Multi-Kit instance 並行」
- OVAS 是 NVIDIA 官方對該需求的 reference implementation
- 接管自寫 KitInstancePool / start-multi-kit.ps1 / docker-compose 多 GPU 啟動
@@ -3149,8 +3107,8 @@ D. 關鍵結論（對
- kit_instance_bindings.provider 由 "local-script" 多一個值 "ovas"
- 其他 Req（routing policy / lifecycle / draining / shared_state）完全不變
-E. MCP 與官方文件的交叉驗證
-
+E. MCP 與官方文件的交叉驗證
+
來源
@@ -3175,14 +3133,14 @@ E. MCP 與官方文件的交叉驗
明文：「The Omniverse Kit App Streaming NGC Collection contains all of the required artifacts to immediately deploy to AWS, Microsoft Azure or on-premise」
-
+
12. 由 MCP 結果新增的候選
這兩個候選都不取代 §5 既有 P0 / P1，而是讓 P0 候選在實作時直接對齊 NVIDIA 真實做法，避免「自建版」與「NVIDIA 版」雙軌成本。
-12.1 候選 #1A：streaming-collaboration-presence-layer-upgrade
-
+12.1 候選 #1A：streaming-collaboration-presence-layer-upgrade
+
項目
@@ -3231,9 +3189,9 @@ 12.1 候
需要先有 Nucleus（NVIDIA Omniverse Nucleus）或自建 USD live transport；Tier A 起才適合啟動
-
-12.2 候選 #2A：streaming-ovas-helm-baseline
-
+
+12.2 候選 #2A：streaming-ovas-helm-baseline
+
項目
@@ -3290,12 +3248,12 @@ 12.2 候選 #2A：str
#1 已 land，待 GPU 購買部署且 #2 runtime evidence land 後；不要在 dedicated multi-Kit 還沒驗證前提早跳到 K8s。先在開發機 kind / minikube 驗證再評估雲端
-
-#2A 對 spec multi-artifact-kit-routing 的具體影響（2026-05-08 17:00）
+
+#2A 對 spec multi-artifact-kit-routing 的具體影響（2026-05-08 17:00）
回應使用者問題「Phase 3 #2 與 4.4 的關係 + 是否可用 OVAS app instance lifecycle 達到 multi-Kit instance 並行」。
-
+
Spec Requirement
@@ -3336,9 +3294,9 @@ 無變
-
+
關鍵：OVAS 接管後，multi-artifact-kit-routing spec 只需要 1 個 MODIFY（Req2 provider enum 擴值），其他 4 個 Requirement 完全不變。這證實 §2 Phase 3 ↔ §2 Phase 4.4 的「業務語意層 vs runtime infrastructure 層」解耦設計是正確的。
-採用 OVAS 之後 KitInstancePool 的角色變化
+採用 OVAS 之後 KitInstancePool 的角色變化
採用前（Tier A，目前 main 自寫）：
bim-review-coordinator/src/services/kitPool.ts
- 直接 spawn / kill Kit process
@@ -3362,7 +3320,7 @@ 採用 OVAS 之後 K
- web-viewer-sample（仍是我們自己的 review UI；只是 WebRTC 對端 URL 換成 OVAS 提供）
- _bim-control / _worker / Socket.IO collaboration 全部不變
-#1A / #2A 與既有 P0 / P1 的依賴
+#1A / #2A 與既有 P0 / P1 的依賴
#1 worker-real-conversion-quality (✓ archived)
└─→ 已解開 IFC→USDC placeholder 紅星；coverage baseline 門檻仍待後續 spec
@@ -3385,11 +3343,11 @@ 13. 採用 NV
2026-05-08 16:05 新增：回應使用者問題「Phase 4 / Phase 5 NVIDIA 已提供功能是否可直接採用？優缺點與風險？」。
本節不是「全部採用」或「全部不採用」的二分決策，而是給每個能力一個獨立的決策矩陣，避免 reference impl 把整個 stack 鎖死。
-13.1 決策矩陣（每個能力獨立判斷）
+13.1 決策矩陣（每個能力獨立判斷）
圖例：✅ = 推薦採用 NVIDIA reference；⚠ = 部分採用 / 條件採用；❌ = 不採用（自建或第三方）
-
+
能力
@@ -3492,8 +3450,8 @@ 13.1 決策矩陣（每個
（所有候選）
-
-13.2 採用 reference implementation 的「優點」
+
+13.2 採用 reference implementation 的「優點」
時間成本：
- OVAS Helm 從 0 到 K8s deploy，內部估計 1-2 週
- 自寫 KitInstancePool + scheduler + autoscaling 從 0 到 production-ready，估計 ≥ 6 週
@@ -3519,8 +3477,8 @@ 13.2 採用 reference i
- Kit 109.x 升 110.x 時自動繼承新功能
- 不需要為 driver / CUDA 升級 patch 自家程式碼
-13.3 採用 reference implementation 的「缺點」與風險
-
+13.3 採用 reference implementation 的「缺點」與風險
+
編號
@@ -3603,10 +3561,10 @@ 13.3 採用 r
評估階段允許從 NGC pull；商業階段 mirror 到內部 registry + 安全掃描
-
-13.4 採用建議（依各 Phase 對應）
-Phase 4（高併發平台化）
-
+
+13.4 採用建議（依各 Phase 對應）
+Phase 4（高併發平台化）
+
子能力
@@ -3636,9 +3594,9 @@ Phase 4（高併發平台化）
0%
-
-Phase 5（Omniverse 平台能力最大化）
-
+
+Phase 5（Omniverse 平台能力最大化）
+
子能力
@@ -3673,8 +3631,8 @@ Phase 5（Omniverse 平台能
0%
-
-Phase 6（Production & SaaS 營運）
+
+Phase 6（Production & SaaS 營運）
全部 ⏸ 凍結，等公司業務系統接入。
當解凍時：
@@ -3683,7 +3641,7 @@ Phase 6（Production & SaaS 營運
- Observability / SLA / SLO → 對應 #8（凍結中）
- 完整 production deployment → 對應 #9（凍結中）
-13.5 何時「不要」採用 reference implementation
+13.5 何時「不要」採用 reference implementation
1. 開發階段 PoC 為了快速驗證單一假設
例：候選 #2 在單機驗 multi-Kit
理由：OVAS K8s 對 PoC 過重；先用 docker-compose 驗，再升
@@ -3703,7 +3661,7 @@ 13.5 何時「不要
5. 業務邏輯 / RBAC / multi-tenant
永遠不採用 NVIDIA reference — 那是我們自己的領域
-13.6 決策流程（給每個 Phase 4 / 5 子能力）
+13.6 決策流程（給每個 Phase 4 / 5 子能力）
flowchart TD
A[新功能需求] --> B{NVIDIA Kit base 有 extension?}
B -- "✓ 有" --> C{基礎設施門檻可接受?<br/>K8s/Nucleus/license}
@@ -3723,7 +3681,7 @@ 13.6 決策流程（給
→ 每次新增候選時，先依 §13.6 流程跑一遍，再決定 spec 內容。
- 查看 Markdown 原文
+ Markdown Source
# AI-BIM-governance：SaaS 路線圖規劃（2026-05）
> **文件性質**：roadmap / planning artifact（不是 OpenSpec change，不修改產品程式碼）
@@ -3759,6 +3717,8 @@ 13.6 決策流程（給
> **2026-05-12 更新（`worker-real-conversion-quality` archive 對齊）**：依 `openspec/changes/archive/2026-05-11-worker-real-conversion-quality/` 與現行 `openspec/specs/` 更新 **§1.2 / §1.3 / §1.4 / §2 / §4 / §5 / §6 / §7 / §9.8 / §10**。P0 #1 已 land 並歸檔：`_worker` 已具備真實 IFC→USDC adapter、USDC openability hard gate、real mapping quality metrics 與 single Kit/browser 截圖證據；mapping coverage 仍採 measure-first，尚未鎖 production baseline 門檻。
>
> **2026-05-12 更新（#2 GPU 容量等待）**：依使用者指示，`multi-artifact-kit-routing` / `streaming-multi-instance-orchestration` 的 `dedicated_instance` runtime 驗證改為 **等待 GPU 購買與部署後執行**。在至少兩個 GPU-backed Kit endpoints 可用前，roadmap 與 OpenSpec 只保留 control-plane contract / routing target，不把 dedicated multi-Kit runtime 視為進行中、passed 或 failed。
+>
+> **2026-05-12 更新（`worker-mapping-lineage-quality-baseline` archive 對齊）**：依 `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/` 與現行 `openspec/specs/` 更新 **§1.2 / §1.3 / §1.4 / §2 / §5 / §6 / §10**。原候選 #3 lineage API 與 #3A mapping quality baseline 已合併為同一 change 並歸檔：`_worker` 已具備 lineage query API、worker UI lineage / quality view、all-IFC-entity coverage 語意、`minimum_coverage_ratio=1.0` policy 與 storage batch verification helper；canonical 13-file real batch 仍未完成，因此 production baseline 尚未鎖定。
本文件目的是把使用者提供的兩張架構圖（v1 從 PoC 到 SaaS 的執行路線圖、v2 SaaS 級目標架構與落地順序）對照目前 repo 現況，產出**下一階段最小、可驗證、不擴散範圍**的 OpenSpec change 候選清單，並標出每個候選的優先級、風險、KPI 與 repo 邊界。
@@ -3802,15 +3762,15 @@ 13.6 決策流程（給
| Spec | 對應 v1 Phase | 對應 v2 Layer | 狀態 |
|---|---|---|---|
-| `worker-artifact-pipeline` | 1 | 3-B | ✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / `original_filename` / real IFC→USDC conversion quality |
+| `worker-artifact-pipeline` | 1 | 3-B | ✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / `original_filename` / real IFC→USDC conversion quality / lineage graph API / all-IFC-entity coverage policy |
| `worker-dev-ifc-source-selection` | 0/1 | 3-B | ✓ dev IFC source root + selected-source flow |
-| `worker-demo-upload-convert-ui` | 0/1 | 2 | ✓ Worker demo UI on 8005 |
+| `worker-demo-upload-convert-ui` | 0/1 | 2 | ✓ Worker demo UI on 8005；含 lineage / conversion quality view |
| `legacy-storage-conversion-retirement` | 1 | 3 | ✓ `_s3_storage` / `_conversion-service` 退役完成 |
| `review-session-request-lifecycle` | 2/3 | 3-A/C | ✓ created/active/closing/closed/failed + queued_for_instance + close vs release 分離 |
| `multi-artifact-kit-routing` | 3 | 3-C / 4 | ✓ artifact_bindings + kit_instance_bindings + same/dedicated/shared 三種 routing |
| `streaming-multi-layer-payload-loading` | 1/2 | 4 | ✓ multi-binding load + applied_mode 誠實回傳 |
| `session-first-review-viewer` | 2/3 | 2 | ✓ Viewer 從 review_request_id / session_id bootstrap |
-| `runtime-verification-evidence` | 0 | 6 | ✓ 證據分層（contract / real conversion / single-Kit / multi-Kit / stress） |
+| `runtime-verification-evidence` | 0 | 6 | ✓ 證據分層（contract / real conversion / storage batch baseline / single-Kit / multi-Kit / stress） |
| `runtime-verification-task-status` | 3 | 6 | ✓ checklist 語意：GPU / concurrent runtime items 不得因 blocker classification 被視為完成 |
| `documentation-source-of-truth` | cross-cutting | repo governance | ✓ workflow v3 / SaaS roadmap / README / OpenSpec specs 分工權威 |
@@ -3833,11 +3793,11 @@ 13.6 決策流程（給
real IFC→USDC root smoke: passed (89,394,282 bytes fixture; coverage_ratio=0.950556913882097)
single Kit/browser real worker USDC: passed (review_session_001a59d345ce; 1920×1080; non-black stream frame)
-# 2026-05-12 worker-mapping-lineage-quality-baseline（branch evidence，尚未 archive）
+# 2026-05-12 worker-mapping-lineage-quality-baseline（archived spec + validation evidence）
openspec validate --strict: passed
_worker store/converter/batch tests: 56 passed
_worker clean venv full tests: 94 passed, 1 skipped
-lineage API / UI / quality policy: implemented in change branch
+lineage API / UI / quality policy: archived into current specs
_worker dependency baseline: requirements pin fastapi/starlette/uvicorn to repo baseline
canonical storage dry-run: 13 IFC fixtures found; not converted; minimum_coverage_locked=false
real batch --limit 1: timed out after 600s; full baseline not locked
@@ -3851,7 +3811,7 @@ 13.6 決策流程（給
> - 2026-05-11 real conversion：`docs/verification/2026-05-11-worker-real-conversion-quality.md`
> - Single Kit/browser 截圖與 summary：`docs/verification/evidence/2026-05-11-worker-real-conversion-quality/`
>
-> **限制**：`worker-real-conversion-quality` 已解除 placeholder converter blocker，但該 evidence 仍採 measure-first；`worker-mapping-lineage-quality-baseline` 分支已加入 `minimum_coverage_ratio=1.0` / all-IFC-entity semantics 與 lineage API，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
+> **限制**：`worker-real-conversion-quality` 已解除 placeholder converter blocker；`worker-mapping-lineage-quality-baseline` 已將 `minimum_coverage_ratio=1.0` / all-IFC-entity semantics 與 lineage API 併入現行 specs，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
> **註（2026-05-12）**：`multi-artifact-kit-routing` 的 dedicated_instance runtime 不再列為既有分支驗證狀態；後續必須等 GPU 購買與部署完成、可提供至少兩個 GPU-backed Kit endpoints 後，才重新啟動驗證並更新 `runtime-verification-evidence`。
@@ -3868,6 +3828,7 @@ 13.6 決策流程（給
| `2026-05-08-fix-runtime-verification-task-status` | `runtime-verification-task-status`（新增） | OpenSpec runtime verification checklist 語意；GPU / concurrent runtime items 不得因 blocker classification 被視為完成；同步 PR #20 same-Kit primary／spectator stream evidence |
| `2026-05-11-align-workflow-v3-with-saas-roadmap` | `documentation-source-of-truth`（新增） | workflow v3 與 SaaS 路線圖互補不替代；文件分工調整必須走 OpenSpec change；雙向 cross-reference 必須持續成立 |
| `2026-05-11-worker-real-conversion-quality` | `worker-artifact-pipeline`、`runtime-verification-evidence`（MODIFY） | `_worker` real IFC→USDC adapter、openable `model.usdc` hard gate、real `ifc_index` / `usd_index` / `element_mapping`、one-to-many mapping schema、quality metrics、measure-first coverage report、single Kit/browser real worker artifact evidence |
+| `2026-05-12-worker-mapping-lineage-quality-baseline` | `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui`（MODIFY） | lineage graph API、stable derived/index/mapping artifact IDs、all-IFC-entity coverage denominator、`minimum_coverage_ratio=1.0` policy、warn reviewable / fail blocking readiness、storage batch evidence tier、worker UI lineage / quality view |
```txt
規格目錄約定：
@@ -3986,20 +3947,20 @@ 13.6 決策流程（給
| fake APIs 補齊 demo UI / 人工可觸發 review flow | `worker-demo-upload-convert-ui` | ✓ |
| health check / smoke test / 測試資料穩定化 | `runtime-verification-evidence` + `scripts/start-all`、`smoke-*.ps1` | ✓ |
-### Phase 1：`_worker` 收攏（最優先）— **狀態：✓ 主要紅星已解除；lineage / coverage baseline 分支實作中，real batch 未鎖定**
+### Phase 1：`_worker` 收攏（最優先）— **狀態：✓ 主要紅星已解除；lineage / coverage baseline 已歸檔，real batch 未鎖定**
| v1 路線圖項目 | 對應 spec | 狀態 |
|---|---|---|
| `_s3_storage` + `_conversion-service` → `_worker` | `legacy-storage-conversion-retirement` | ✓ |
| `_bim-control` 上傳 IFC 至 `_worker` | `worker-artifact-pipeline` Req1 | ✓ |
| `_worker` 啟動 conversion job、產出 USDC + mapping | `worker-artifact-pipeline` Req2/3 + real conversion requirements | ✓ real IFC→USDC adapter；USDC openability hard gate；one-to-many mapping；quality metrics |
-| 建立 artifact source / version / lineage 模型 | `worker-artifact-pipeline` Req4 + `worker-mapping-lineage-quality-baseline` | ✓ metadata 結構完成；branch 已實作 lineage graph API / worker UI；clean venv `_worker` full tests passed |
+| 建立 artifact source / version / lineage 模型 | `worker-artifact-pipeline` Req4 + `2026-05-12-worker-mapping-lineage-quality-baseline` | ✓ metadata 結構完成；lineage graph API / worker UI 已歸檔；clean venv `_worker` full tests passed |
**Gap**：
1. `worker-real-conversion-quality` 已於 `2026-05-11` archive：`_worker` 不再以 placeholder `model.usdc` 作為 ready conversion evidence；89 MB ignored repo-local IFC fixture 的 real conversion smoke 與 single Kit/browser evidence 已記錄於 `docs/verification/2026-05-11-worker-real-conversion-quality.md`。
-2. Mapping coverage 已由 `worker-mapping-lineage-quality-baseline` 分支改成 `minimum_coverage_ratio=1.0`、`coverage_denominator=source_ifc_entity_count`、所有 IFC entity 必須 materialize 為 USD prim 的語意；`warn` 可進 review、`fail` 阻擋 mapping readiness。尚未完成 canonical 13-file real batch，因此 production baseline **未鎖定**，issue → real prim baseline 也不得宣稱 passed。
-3. lineage 查詢 API 已由 `worker-mapping-lineage-quality-baseline` 分支實作 `GET /api/artifacts/{id}/lineage`，並優先沿用 `derived_artifact_ids` 作為 mapping/index stable IDs；clean venv 使用 `_worker/requirements.txt` 後 `_worker` full tests passed，global Python 的 `starlette 1.0.0` drift 仍視為本機環境問題。
+2. Mapping coverage 已由 `2026-05-12-worker-mapping-lineage-quality-baseline` archive 改成 `minimum_coverage_ratio=1.0`、`coverage_denominator=source_ifc_entity_count`、所有 IFC entity 必須 materialize 為 USD prim 的語意；`warn` 可進 review、`fail` 阻擋 mapping readiness。尚未完成 canonical 13-file real batch，因此 production baseline **未鎖定**，issue → real prim baseline 也不得宣稱 passed。
+3. lineage 查詢 API 已由 `2026-05-12-worker-mapping-lineage-quality-baseline` archive 納入 `GET /api/artifacts/{id}/lineage`，並優先沿用 `derived_artifact_ids` 作為 mapping/index stable IDs；clean venv 使用 `_worker/requirements.txt` 後 `_worker` full tests passed，global Python 的 `starlette 1.0.0` drift 仍視為本機環境問題。
### Phase 2：檢討閉環 — **狀態：✓ 已完成並驗證**
@@ -4184,7 +4145,7 @@ 13.6 決策流程（給
| **多 region / 跨地理 TURN 部署** | Layer 6 | 海外使用者 RTT 投訴 | ⏸ 等待業務接入 |
| **GitHub Actions / auto PR / test matrix 擴大** | Layer 6 | 開發團隊規模 ≥ 4 人 | ⏸ 等待業務接入 |
-> **與其他 Phase 的關係**：已歸檔 #1、候選 #2 / #3 / #4（P0–P1）與候選 #1A / #2A 是 Phase 4–5 範圍，**不受此凍結影響**。Phase 6 凍結僅作用於候選 #7 / #8 / #9 與上表細項。
+> **與其他 Phase 的關係**：已歸檔 #1 / #3 / #3A、候選 #2 / #4（P0–P1）與候選 #1A / #2A 是 Phase 4–5 範圍，**不受此凍結影響**。Phase 6 凍結僅作用於候選 #7 / #8 / #9 與上表細項。
---
@@ -4215,7 +4176,7 @@ 13.6 決策流程（給
| 6 | 建立 review-session-request → 分發 review session / kit instance | ✓ E2E 已驗證 | LOW |
| 7 | 發布到 streaming + AI review | ⚠ streaming 通；AI review 未實作 | MEDIUM |
-**結論（2026-05-12 對齊）**：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 `worker-real-conversion-quality` 解除。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline；該門檻與 failure policy 改由候選 **#3A `worker-mapping-quality-baseline`** 鎖定。
+**結論（2026-05-12 對齊）**：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 `worker-real-conversion-quality` 解除；lineage API 與 all-IFC-entity mapping quality policy 已由 `worker-mapping-lineage-quality-baseline` 歸檔。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline，直到 canonical storage real batch 通過並鎖定 evidence。
---
@@ -4244,7 +4205,7 @@ 13.6 決策流程（給
| **驗證紀錄** | `docs/verification/2026-05-11-worker-real-conversion-quality.md` + `docs/verification/evidence/2026-05-11-worker-real-conversion-quality/` |
| **建議 spec id** | `worker-real-conversion-quality` |
| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline`：real conversion / mapping / quality gates；MODIFY `runtime-verification-evidence`：real conversion metrics + single Kit real worker artifact evidence |
-| **剩餘限制** | Coverage 仍是 measure-first；尚未鎖 production 最低 mapping coverage hard gate。此限制改由候選 **#3A `worker-mapping-quality-baseline`** 承接，不重開 #1 |
+| **剩餘限制** | Coverage policy 已定義為 all-IFC-entity + `minimum_coverage_ratio=1.0`，但 canonical 13-file real batch 未完成；尚未鎖 production 最低 mapping coverage hard gate。不重開 #1 / #3 / #3A，後續補 evidence 即可 |
### 5.1 P0-hold（等待 GPU 購買部署）
@@ -4266,31 +4227,15 @@ 13.6 決策流程（給
### 5.2 P1（這月）
-#### 候選 #3：`worker-artifact-lineage-api`
+#### 已完成：候選 #3 / #3A 合併為 `worker-mapping-lineage-quality-baseline`
| 項目 | 內容 |
|---|---|
-| **目標** | 把現有 `metadata.json` 中 `parent_artifact_id` / `conversion_job_id` 整理成可查詢的 lineage graph API；worker UI 視覺化三層關係 |
-| **解決的 v1 phase / v2 layer** | Phase 1 / Layer 3-B |
-| **repo 邊界** | 只動 `_worker/`；UI 改動限於 `_worker/app/static/` |
-| **風險** | MEDIUM（API shape 設計影響後續 Layer 5 audit log） |
-| **KPI** | 1) `GET /api/artifacts/{id}/lineage` 回完整祖系 + 子代鏈；2) worker UI 顯示 source → derived → mapping 三層樹；3) 既有 worker pytest 全綠 |
-| **驗證指令** | `cd _worker && python -m pytest tests` + browser open `/ui/lineage` |
-| **建議 spec id** | `worker-artifact-lineage-api` |
-| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline` Req4 versioned object layout（補 lineage query semantics） |
-
-#### 候選 #3A：`worker-mapping-quality-baseline`
-
-| 項目 | 內容 |
-|---|---|
-| **目標** | 將 #1 archive 後保留的 measure-first mapping coverage 轉成可審查 baseline：定義最低 coverage threshold、material / prim fidelity smoke criteria、低 coverage 的 failure / warn policy，以及 issue → real prim highlight 可接受門檻 |
-| **解決的 v1 phase / v2 layer** | Phase 1 quality gate / Layer 3-B |
-| **repo 邊界** | 主要動 `_worker/` 與 verification docs；若需要 viewer smoke，只作 evidence consumer，不讓 viewer 接管 mapping ownership |
-| **風險** | MEDIUM（過早鎖門檻可能讓不同 IFC 類型誤 fail；需先用至少 2-3 個 fixture 校準） |
-| **KPI** | 1) `runtime-verification-evidence` 明確記錄 `minimum_coverage_locked=true` 的條件；2) `_worker` conversion quality report 區分 pass / warn / fail；3) issue highlight smoke 使用 real IFC GUID → USD prim path；4) baseline fixture evidence 不低於門檻 |
-| **驗證指令** | `cd _worker && python -m pytest tests` + real conversion smoke + single Kit/browser issue highlight smoke（有 GPU 時） |
-| **建議 spec id** | `worker-mapping-quality-baseline` |
-| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline` real mapping quality gate；MODIFY `runtime-verification-evidence` real conversion quality metrics |
+| **Archive** | `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/` |
+| **涵蓋原候選** | #3 `worker-artifact-lineage-api` + #3A `worker-mapping-quality-baseline` |
+| **已併入 specs** | `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui` |
+| **已完成** | lineage graph API、stable mapping/index derived artifact IDs、worker UI lineage / quality view、all-IFC-entity coverage denominator、`minimum_coverage_ratio=1.0` policy、warn reviewable / fail blocking readiness、storage batch helper |
+| **仍未宣稱完成** | canonical 13-file real batch 未完成；`minimum_coverage_locked=true` production baseline 與 issue → real prim verified evidence 尚未成立 |
#### 候選 #4：`coordinator-session-lifecycle-events-audit`
@@ -4376,7 +4321,10 @@ 13.6 決策流程（給
Archived / 已完成:
#1 worker-real-conversion-quality ✓ 已於 2026-05-11 archive
解除 IFC→USDC placeholder blocker；real worker-produced USDC 已有 single Kit/browser evidence
- 剩餘：coverage baseline 門檻仍是 measure-first，待後續 spec 鎖定
+ 剩餘：canonical storage real batch 未完成，production coverage baseline 未鎖定
+ #3/#3A worker-mapping-lineage-quality-baseline ✓ 已於 2026-05-12 archive
+ lineage API / worker UI / all-IFC-entity coverage policy 已併入 specs
+ 剩餘：canonical 13-file real batch 未完成，production coverage baseline 未鎖定
P0-hold (等待 GPU 購買與部署):
#2 streaming-multi-instance-orchestration ★★ ⏸ 等待 GPU 購買與部署後執行
@@ -4385,8 +4333,6 @@ 13.6 決策流程（給
roadmap 端：GPU capacity 到位後才重啟驗證並同步 §1.3 / §2 / §9.2
P1 (這月):
- #3 worker-artifact-lineage-api 收斂 lineage 為 query API
- #3A worker-mapping-quality-baseline 鎖定 #1 archive 後仍 measure-first 的 mapping coverage / issue highlight 門檻
#4 coordinator-session-lifecycle-events-audit 事件 schema 收斂（為 #6 webhook 鋪路；audit log 持久化屬 Phase 6 凍結）
P2 (下月):
@@ -4411,14 +4357,14 @@ 13.6 決策流程（給
```txt
#1 (✓ archived) ─┬─→ Kit GPU render 證據已解鎖
├─→ Phase 5 可用 real worker-produced USDC 作前提
- ├─→ #3A mapping coverage / issue highlight baseline 鎖門檻
- └─→ #3 lineage API 將 metadata lineage 變成可查詢圖
+ └─→ #3/#3A (✓ archived) lineage API + all-IFC-entity coverage policy
#2 (⏸ 等待 GPU 購買與部署)
─→ GPU-backed multi-instance routing 證據解鎖
─→ #2A (OVAS Helm 升級需要先在已部署 GPU capacity 上跑通多 Kit)
-#3 ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
+#3/#3A (✓ archived) ─→ 後續只剩 canonical storage real batch 與 issue highlight evidence
+ ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
#4 ─→ #6 mock webhook (P2 可探索)
─→ ⏸ #8 audit (Phase 6 凍結)
@@ -4434,7 +4380,7 @@ 13.6 決策流程（給
| # | 風險 | 緩解 |
|---|---|---|
-| R1 | #1 已選 IfcOpenShell + `usd-core` 作為 real IFC→USDC adapter external prerequisites，後續仍有 dependency / license / Windows runtime drift 風險 | 保持 adapter boundary，不讓 `_worker` contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。Coverage baseline 仍採 measure-first，待後續 spec 鎖最低門檻 |
+| R1 | #1 已選 IfcOpenShell + `usd-core` 作為 real IFC→USDC adapter external prerequisites，後續仍有 dependency / license / Windows runtime drift 風險 | 保持 adapter boundary，不讓 `_worker` contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。#3/#3A 已定義 all-IFC-entity coverage policy，但 canonical storage real batch 未完成前不得把 production baseline 標成 locked |
| R2 | 候選 #2 在 8 GB VRAM 下可能無法並行 2 個 Kit；最新狀態為等待 GPU 購買與部署後執行 | GPU 未購買部署前不執行 dedicated multi-Kit runtime 驗證，也不標 passed / failed / in-progress；重新啟動前需具備至少兩個 GPU-backed Kit endpoints，硬體門檻 24 GB VRAM 見 §9.2 |
| R3 | 規劃過早跳到 Phase 5/6，本機 demo 變不穩 | P0 / P1 全部 land 之前不啟動 #5 / #6 之後的候選；Phase 6 候選 #7 / #8 / #9 連同細項一律凍結至業務系統接入 |
| R4 | OpenSpec 在 main 上累積太多 untracked 變更 | 每個候選都走 `codex/openspec/<change-id>` branch + PR；本文件不算 OpenSpec change，是 plan |
@@ -4851,24 +4797,29 @@ 13.6 決策流程（給
- 對 `bim-review-coordinator` 與 `web-viewer-sample` 重跑 `npm ci`，確認 `tsx.cmd` / `vite.cmd` 存在。
- 以 `.\scripts\start-all.ps1 -SkipStreaming` 驗 8001 / 8005 / 8004 / 5173；這一步通過後，才把後續 OpenSpec / runtime evidence 的失敗視為功能或 spec 問題。
-2. **確認 #1 archive 對齊已完成，後續不再重開 `worker-real-conversion-quality`**：
+2. **確認 #1 與 #3/#3A archive 對齊已完成，後續不再重開已完成 change**：
- `#1 worker-real-conversion-quality` 已歸檔到 `openspec/changes/archive/2026-05-11-worker-real-conversion-quality/`。
- 現行 specs 已同步到 `worker-artifact-pipeline` 與 `runtime-verification-evidence`。
- - 下一步若要提升品質，不是重開 #1，而是另開 **#3A `worker-mapping-quality-baseline`**（mapping coverage / material fidelity / issue highlight 門檻）或 **#3 `worker-artifact-lineage-api`**（lineage API / UI）等更小 spec。
+ - `#3/#3A worker-mapping-lineage-quality-baseline` 已歸檔到 `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/`，並同步到 `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui`。
+ - 後續若要提升品質，不重開 #1 / #3 / #3A；改以 canonical storage batch completion 或 issue highlight evidence 作為下一個更小切片。
+
+3. **下一個 worker 品質工作：補 canonical storage 13-file real batch evidence**：
+ - 使用 `C:\Repos\active\iot\AI-BIM-governance\storage\*.ifc` 作為正式本機 fixture root。
+ - 先解決 89MB fixture `--limit 1` 超過 600s timeout 的 runtime / performance 問題，再擴到 13-file batch。
+ - 只有全批次 real conversion、USDC openability、lineage API、all-IFC-entity coverage 都通過時，才可把 `minimum_coverage_locked=true` production baseline 寫入 evidence。
-3. **暫停 `#2 streaming-multi-instance-orchestration`，等待 GPU 購買與部署後再執行**：
+4. **暫停 `#2 streaming-multi-instance-orchestration`，等待 GPU 購買與部署後再執行**：
- 在至少兩個 GPU-backed Kit endpoints 可用前，不啟動 dedicated multi-Kit runtime 驗證，也不把它標為進行中、passed 或 failed。
- GPU 購買與部署完成後，先依 §9.2 確認 24 GB VRAM 級 GPU capacity、distinct signaling / media port pair、Kit stream listener 與 browser evidence 儲存位置，再重新啟動驗證。
- 重啟驗證通過後，才更新 §1.3 / §2 Phase 3 / §9.2 與 `runtime-verification-evidence` §6.4 evidence。
- **MCP 補強**：驗證前用 `kit-mcp` `get_kit_extension_details("omni.kit.livestream.webrtc")` 確認 signalPort 49100 / streamPort 47999 設定與 NVIDIA 預設值一致；多 instance 時兩台需用不同 port pair。
-4. **挑一個 P1 候選啟動 OpenSpec explore**：
- - 推薦在 `#3 worker-artifact-lineage-api`、`#3A worker-mapping-quality-baseline` 與 `#4 coordinator-session-lifecycle-events-audit` 三選一。
- - 若要延續 #1 的 worker 成果並處理 archive 後的品質 gap，優先 `#3A`：把 mapping coverage / material fidelity / issue highlight 門檻從 measure-first 變成 baseline。
- - 若要強化 artifact traceability，選 `#3`：把 source → derived → mapping lineage 從 metadata 變成可查詢 API / worker UI。
+5. **下一個 P1 OpenSpec 候選以 `#4 coordinator-session-lifecycle-events-audit` 為主**：
+ - #3 / #3A 已完成並歸檔，不再列為候選池。
- 若要支撐後續 webhook / observability，選 `#4`：把 lifecycle events 收斂成 append-only event schema。
+ - 若要先補 worker evidence，不開新 spec，優先延續現行 `runtime-verification-evidence` 的 canonical storage batch evidence。
-5. **評估是否啟動 `#1A` / `#2A`（採用 NVIDIA reference impl，見 §12 / §13）**：
+6. **評估是否啟動 `#1A` / `#2A`（採用 NVIDIA reference impl，見 §12 / §13）**：
- 在啟動前，先依 §13 的決策框架評估「**自建 vs 採用 NVIDIA**」對應風險（依賴鎖定 / Nucleus 部署 / license / GPU 鎖定）。
- 若決定啟動 #1A：用 `kit-mcp` `get_kit_extension_details("omni.kit.collaboration.presence_layer")` 查 PresenceLayerAPI 22 個方法（`broadcast_local_bound_camera` / `enter_follow_mode` / `get_selections`）。
- 若決定啟動 #2A（OVAS spike，2026-05-08 17:00 補）：
@@ -4878,11 +4829,11 @@ 13.6 決策流程（給
4. **不變的部分**：`web-viewer-sample` UI、`_bim-control` / `_worker` data plane、Socket.IO collaboration 全部保留；OVAS 只取代「Kit container 啟動 / 調度」（§2 4.4 / 4.5 / 4.11）。
5. **避免的事**：不要把 OVAS image build 流程混進 `bim-streaming-server` 的單機 dev workflow；把 OVAS 部署放 `deploy/ovas/` 獨立目錄，Tier A 仍可走 `scripts/start-multi-kit.ps1` 自寫 KitInstancePool 路徑。
-6. **Phase 6 候選 #7 / #8 / #9 與 §2 Phase 6 細項一律暫不啟動**：
+7. **Phase 6 候選 #7 / #8 / #9 與 §2 Phase 6 細項一律暫不啟動**：
- 依使用者 2026-05-08 16:05 指示，這些細項目前 ⏸ 凍結，**等待公司業務系統接入**（SSO / IT 維運 / SLA / billing / 合約等）。
- 任何想解凍的提案，需在 PR description 引用該決策段落（本文件 §2 Phase 6 表 + §6 P3-frozen），並附上業務系統接入確認文件。
-7. **延後啟動 `#5` / `#6`**：
+8. **延後啟動 `#5` / `#6`**：
- `#5 ai-rule-carbon-result-contract` 與 `#6 notification-webhook-service` 是 P2 的入口 contract（mock 階段），但若 P0 / P1 還沒 land 就開，會是**範圍擴散風險**。
- production-grade 的 audit log persistence 與 webhook delivery 屬 Phase 6 凍結範圍（§2 Phase 6 表）。
diff --git a/docs/plans/AI-BIM-governance-saas-roadmap-2026-05.md b/docs/plans/AI-BIM-governance-saas-roadmap-2026-05.md
index ba7d0f479..6a4890b4a 100644
--- a/docs/plans/AI-BIM-governance-saas-roadmap-2026-05.md
+++ b/docs/plans/AI-BIM-governance-saas-roadmap-2026-05.md
@@ -33,6 +33,8 @@
> **2026-05-12 更新（`worker-real-conversion-quality` archive 對齊）**：依 `openspec/changes/archive/2026-05-11-worker-real-conversion-quality/` 與現行 `openspec/specs/` 更新 **§1.2 / §1.3 / §1.4 / §2 / §4 / §5 / §6 / §7 / §9.8 / §10**。P0 #1 已 land 並歸檔：`_worker` 已具備真實 IFC→USDC adapter、USDC openability hard gate、real mapping quality metrics 與 single Kit/browser 截圖證據；mapping coverage 仍採 measure-first，尚未鎖 production baseline 門檻。
>
> **2026-05-12 更新（#2 GPU 容量等待）**：依使用者指示，`multi-artifact-kit-routing` / `streaming-multi-instance-orchestration` 的 `dedicated_instance` runtime 驗證改為 **等待 GPU 購買與部署後執行**。在至少兩個 GPU-backed Kit endpoints 可用前，roadmap 與 OpenSpec 只保留 control-plane contract / routing target，不把 dedicated multi-Kit runtime 視為進行中、passed 或 failed。
+>
+> **2026-05-12 更新（`worker-mapping-lineage-quality-baseline` archive 對齊）**：依 `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/` 與現行 `openspec/specs/` 更新 **§1.2 / §1.3 / §1.4 / §2 / §5 / §6 / §10**。原候選 #3 lineage API 與 #3A mapping quality baseline 已合併為同一 change 並歸檔：`_worker` 已具備 lineage query API、worker UI lineage / quality view、all-IFC-entity coverage 語意、`minimum_coverage_ratio=1.0` policy 與 storage batch verification helper；canonical 13-file real batch 仍未完成，因此 production baseline 尚未鎖定。
本文件目的是把使用者提供的兩張架構圖（v1 從 PoC 到 SaaS 的執行路線圖、v2 SaaS 級目標架構與落地順序）對照目前 repo 現況，產出**下一階段最小、可驗證、不擴散範圍**的 OpenSpec change 候選清單，並標出每個候選的優先級、風險、KPI 與 repo 邊界。
@@ -76,15 +78,15 @@
| Spec | 對應 v1 Phase | 對應 v2 Layer | 狀態 |
|---|---|---|---|
-| `worker-artifact-pipeline` | 1 | 3-B | ✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / `original_filename` / real IFC→USDC conversion quality |
+| `worker-artifact-pipeline` | 1 | 3-B | ✓ 涵蓋 source intake / conversion job / versioned object layout / metadata callback / `original_filename` / real IFC→USDC conversion quality / lineage graph API / all-IFC-entity coverage policy |
| `worker-dev-ifc-source-selection` | 0/1 | 3-B | ✓ dev IFC source root + selected-source flow |
-| `worker-demo-upload-convert-ui` | 0/1 | 2 | ✓ Worker demo UI on 8005 |
+| `worker-demo-upload-convert-ui` | 0/1 | 2 | ✓ Worker demo UI on 8005；含 lineage / conversion quality view |
| `legacy-storage-conversion-retirement` | 1 | 3 | ✓ `_s3_storage` / `_conversion-service` 退役完成 |
| `review-session-request-lifecycle` | 2/3 | 3-A/C | ✓ created/active/closing/closed/failed + queued_for_instance + close vs release 分離 |
| `multi-artifact-kit-routing` | 3 | 3-C / 4 | ✓ artifact_bindings + kit_instance_bindings + same/dedicated/shared 三種 routing |
| `streaming-multi-layer-payload-loading` | 1/2 | 4 | ✓ multi-binding load + applied_mode 誠實回傳 |
| `session-first-review-viewer` | 2/3 | 2 | ✓ Viewer 從 review_request_id / session_id bootstrap |
-| `runtime-verification-evidence` | 0 | 6 | ✓ 證據分層（contract / real conversion / single-Kit / multi-Kit / stress） |
+| `runtime-verification-evidence` | 0 | 6 | ✓ 證據分層（contract / real conversion / storage batch baseline / single-Kit / multi-Kit / stress） |
| `runtime-verification-task-status` | 3 | 6 | ✓ checklist 語意：GPU / concurrent runtime items 不得因 blocker classification 被視為完成 |
| `documentation-source-of-truth` | cross-cutting | repo governance | ✓ workflow v3 / SaaS roadmap / README / OpenSpec specs 分工權威 |
@@ -107,11 +109,11 @@ _worker API tests: 32 passed, 1 skipped
real IFC→USDC root smoke: passed (89,394,282 bytes fixture; coverage_ratio=0.950556913882097)
single Kit/browser real worker USDC: passed (review_session_001a59d345ce; 1920×1080; non-black stream frame)
-# 2026-05-12 worker-mapping-lineage-quality-baseline（branch evidence，尚未 archive）
+# 2026-05-12 worker-mapping-lineage-quality-baseline（archived spec + validation evidence）
openspec validate --strict: passed
_worker store/converter/batch tests: 56 passed
_worker clean venv full tests: 94 passed, 1 skipped
-lineage API / UI / quality policy: implemented in change branch
+lineage API / UI / quality policy: archived into current specs
_worker dependency baseline: requirements pin fastapi/starlette/uvicorn to repo baseline
canonical storage dry-run: 13 IFC fixtures found; not converted; minimum_coverage_locked=false
real batch --limit 1: timed out after 600s; full baseline not locked
@@ -125,7 +127,7 @@ multi-artifact-kit-routing dedicated_instance runtime : 等待 GPU 購買與部
> - 2026-05-11 real conversion：`docs/verification/2026-05-11-worker-real-conversion-quality.md`
> - Single Kit/browser 截圖與 summary：`docs/verification/evidence/2026-05-11-worker-real-conversion-quality/`
>
-> **限制**：`worker-real-conversion-quality` 已解除 placeholder converter blocker，但該 evidence 仍採 measure-first；`worker-mapping-lineage-quality-baseline` 分支已加入 `minimum_coverage_ratio=1.0` / all-IFC-entity semantics 與 lineage API，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
+> **限制**：`worker-real-conversion-quality` 已解除 placeholder converter blocker；`worker-mapping-lineage-quality-baseline` 已將 `minimum_coverage_ratio=1.0` / all-IFC-entity semantics 與 lineage API 併入現行 specs，但 canonical 13-file real batch 尚未完成，因此不得宣稱 full production coverage baseline 已鎖定。
> **註（2026-05-12）**：`multi-artifact-kit-routing` 的 dedicated_instance runtime 不再列為既有分支驗證狀態；後續必須等 GPU 購買與部署完成、可提供至少兩個 GPU-backed Kit endpoints 後，才重新啟動驗證並更新 `runtime-verification-evidence`。
@@ -142,6 +144,7 @@ multi-artifact-kit-routing dedicated_instance runtime : 等待 GPU 購買與部
| `2026-05-08-fix-runtime-verification-task-status` | `runtime-verification-task-status`（新增） | OpenSpec runtime verification checklist 語意；GPU / concurrent runtime items 不得因 blocker classification 被視為完成；同步 PR #20 same-Kit primary／spectator stream evidence |
| `2026-05-11-align-workflow-v3-with-saas-roadmap` | `documentation-source-of-truth`（新增） | workflow v3 與 SaaS 路線圖互補不替代；文件分工調整必須走 OpenSpec change；雙向 cross-reference 必須持續成立 |
| `2026-05-11-worker-real-conversion-quality` | `worker-artifact-pipeline`、`runtime-verification-evidence`（MODIFY） | `_worker` real IFC→USDC adapter、openable `model.usdc` hard gate、real `ifc_index` / `usd_index` / `element_mapping`、one-to-many mapping schema、quality metrics、measure-first coverage report、single Kit/browser real worker artifact evidence |
+| `2026-05-12-worker-mapping-lineage-quality-baseline` | `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui`（MODIFY） | lineage graph API、stable derived/index/mapping artifact IDs、all-IFC-entity coverage denominator、`minimum_coverage_ratio=1.0` policy、warn reviewable / fail blocking readiness、storage batch evidence tier、worker UI lineage / quality view |
```txt
規格目錄約定：
@@ -260,20 +263,20 @@ OpenSpec archive 後，至少檢查：
| fake APIs 補齊 demo UI / 人工可觸發 review flow | `worker-demo-upload-convert-ui` | ✓ |
| health check / smoke test / 測試資料穩定化 | `runtime-verification-evidence` + `scripts/start-all`、`smoke-*.ps1` | ✓ |
-### Phase 1：`_worker` 收攏（最優先）— **狀態：✓ 主要紅星已解除；lineage / coverage baseline 分支實作中，real batch 未鎖定**
+### Phase 1：`_worker` 收攏（最優先）— **狀態：✓ 主要紅星已解除；lineage / coverage baseline 已歸檔，real batch 未鎖定**
| v1 路線圖項目 | 對應 spec | 狀態 |
|---|---|---|
| `_s3_storage` + `_conversion-service` → `_worker` | `legacy-storage-conversion-retirement` | ✓ |
| `_bim-control` 上傳 IFC 至 `_worker` | `worker-artifact-pipeline` Req1 | ✓ |
| `_worker` 啟動 conversion job、產出 USDC + mapping | `worker-artifact-pipeline` Req2/3 + real conversion requirements | ✓ real IFC→USDC adapter；USDC openability hard gate；one-to-many mapping；quality metrics |
-| 建立 artifact source / version / lineage 模型 | `worker-artifact-pipeline` Req4 + `worker-mapping-lineage-quality-baseline` | ✓ metadata 結構完成；branch 已實作 lineage graph API / worker UI；clean venv `_worker` full tests passed |
+| 建立 artifact source / version / lineage 模型 | `worker-artifact-pipeline` Req4 + `2026-05-12-worker-mapping-lineage-quality-baseline` | ✓ metadata 結構完成；lineage graph API / worker UI 已歸檔；clean venv `_worker` full tests passed |
**Gap**：
1. `worker-real-conversion-quality` 已於 `2026-05-11` archive：`_worker` 不再以 placeholder `model.usdc` 作為 ready conversion evidence；89 MB ignored repo-local IFC fixture 的 real conversion smoke 與 single Kit/browser evidence 已記錄於 `docs/verification/2026-05-11-worker-real-conversion-quality.md`。
-2. Mapping coverage 已由 `worker-mapping-lineage-quality-baseline` 分支改成 `minimum_coverage_ratio=1.0`、`coverage_denominator=source_ifc_entity_count`、所有 IFC entity 必須 materialize 為 USD prim 的語意；`warn` 可進 review、`fail` 阻擋 mapping readiness。尚未完成 canonical 13-file real batch，因此 production baseline **未鎖定**，issue → real prim baseline 也不得宣稱 passed。
-3. lineage 查詢 API 已由 `worker-mapping-lineage-quality-baseline` 分支實作 `GET /api/artifacts/{id}/lineage`，並優先沿用 `derived_artifact_ids` 作為 mapping/index stable IDs；clean venv 使用 `_worker/requirements.txt` 後 `_worker` full tests passed，global Python 的 `starlette 1.0.0` drift 仍視為本機環境問題。
+2. Mapping coverage 已由 `2026-05-12-worker-mapping-lineage-quality-baseline` archive 改成 `minimum_coverage_ratio=1.0`、`coverage_denominator=source_ifc_entity_count`、所有 IFC entity 必須 materialize 為 USD prim 的語意；`warn` 可進 review、`fail` 阻擋 mapping readiness。尚未完成 canonical 13-file real batch，因此 production baseline **未鎖定**，issue → real prim baseline 也不得宣稱 passed。
+3. lineage 查詢 API 已由 `2026-05-12-worker-mapping-lineage-quality-baseline` archive 納入 `GET /api/artifacts/{id}/lineage`，並優先沿用 `derived_artifact_ids` 作為 mapping/index stable IDs；clean venv 使用 `_worker/requirements.txt` 後 `_worker` full tests passed，global Python 的 `starlette 1.0.0` drift 仍視為本機環境問題。
### Phase 2：檢討閉環 — **狀態：✓ 已完成並驗證**
@@ -458,7 +461,7 @@ A：可以，但**不是把 #2 spec 換掉**：
| **多 region / 跨地理 TURN 部署** | Layer 6 | 海外使用者 RTT 投訴 | ⏸ 等待業務接入 |
| **GitHub Actions / auto PR / test matrix 擴大** | Layer 6 | 開發團隊規模 ≥ 4 人 | ⏸ 等待業務接入 |
-> **與其他 Phase 的關係**：已歸檔 #1、候選 #2 / #3 / #4（P0–P1）與候選 #1A / #2A 是 Phase 4–5 範圍，**不受此凍結影響**。Phase 6 凍結僅作用於候選 #7 / #8 / #9 與上表細項。
+> **與其他 Phase 的關係**：已歸檔 #1 / #3 / #3A、候選 #2 / #4（P0–P1）與候選 #1A / #2A 是 Phase 4–5 範圍，**不受此凍結影響**。Phase 6 凍結僅作用於候選 #7 / #8 / #9 與上表細項。
---
@@ -489,7 +492,7 @@ A：可以，但**不是把 #2 spec 換掉**：
| 6 | 建立 review-session-request → 分發 review session / kit instance | ✓ E2E 已驗證 | LOW |
| 7 | 發布到 streaming + AI review | ⚠ streaming 通；AI review 未實作 | MEDIUM |
-**結論（2026-05-12 對齊）**：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 `worker-real-conversion-quality` 解除。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline；該門檻與 failure policy 改由候選 **#3A `worker-mapping-quality-baseline`** 鎖定。
+**結論（2026-05-12 對齊）**：v1 路線圖「Phase 1 _worker 收攏」的最大紅星 blocker（placeholder IFC→USDC）已由 `worker-real-conversion-quality` 解除；lineage API 與 all-IFC-entity mapping quality policy 已由 `worker-mapping-lineage-quality-baseline` 歸檔。後續 Phase 4-6 可把 real worker-produced USDC 作為前提，但仍不得把 mapping coverage 視為 production baseline，直到 canonical storage real batch 通過並鎖定 evidence。
---
@@ -518,7 +521,7 @@ A：可以，但**不是把 #2 spec 換掉**：
| **驗證紀錄** | `docs/verification/2026-05-11-worker-real-conversion-quality.md` + `docs/verification/evidence/2026-05-11-worker-real-conversion-quality/` |
| **建議 spec id** | `worker-real-conversion-quality` |
| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline`：real conversion / mapping / quality gates；MODIFY `runtime-verification-evidence`：real conversion metrics + single Kit real worker artifact evidence |
-| **剩餘限制** | Coverage 仍是 measure-first；尚未鎖 production 最低 mapping coverage hard gate。此限制改由候選 **#3A `worker-mapping-quality-baseline`** 承接，不重開 #1 |
+| **剩餘限制** | Coverage policy 已定義為 all-IFC-entity + `minimum_coverage_ratio=1.0`，但 canonical 13-file real batch 未完成；尚未鎖 production 最低 mapping coverage hard gate。不重開 #1 / #3 / #3A，後續補 evidence 即可 |
### 5.1 P0-hold（等待 GPU 購買部署）
@@ -540,31 +543,15 @@ A：可以，但**不是把 #2 spec 換掉**：
### 5.2 P1（這月）
-#### 候選 #3：`worker-artifact-lineage-api`
-
-| 項目 | 內容 |
-|---|---|
-| **目標** | 把現有 `metadata.json` 中 `parent_artifact_id` / `conversion_job_id` 整理成可查詢的 lineage graph API；worker UI 視覺化三層關係 |
-| **解決的 v1 phase / v2 layer** | Phase 1 / Layer 3-B |
-| **repo 邊界** | 只動 `_worker/`；UI 改動限於 `_worker/app/static/` |
-| **風險** | MEDIUM（API shape 設計影響後續 Layer 5 audit log） |
-| **KPI** | 1) `GET /api/artifacts/{id}/lineage` 回完整祖系 + 子代鏈；2) worker UI 顯示 source → derived → mapping 三層樹；3) 既有 worker pytest 全綠 |
-| **驗證指令** | `cd _worker && python -m pytest tests` + browser open `/ui/lineage` |
-| **建議 spec id** | `worker-artifact-lineage-api` |
-| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline` Req4 versioned object layout（補 lineage query semantics） |
-
-#### 候選 #3A：`worker-mapping-quality-baseline`
+#### 已完成：候選 #3 / #3A 合併為 `worker-mapping-lineage-quality-baseline`
| 項目 | 內容 |
|---|---|
-| **目標** | 將 #1 archive 後保留的 measure-first mapping coverage 轉成可審查 baseline：定義最低 coverage threshold、material / prim fidelity smoke criteria、低 coverage 的 failure / warn policy，以及 issue → real prim highlight 可接受門檻 |
-| **解決的 v1 phase / v2 layer** | Phase 1 quality gate / Layer 3-B |
-| **repo 邊界** | 主要動 `_worker/` 與 verification docs；若需要 viewer smoke，只作 evidence consumer，不讓 viewer 接管 mapping ownership |
-| **風險** | MEDIUM（過早鎖門檻可能讓不同 IFC 類型誤 fail；需先用至少 2-3 個 fixture 校準） |
-| **KPI** | 1) `runtime-verification-evidence` 明確記錄 `minimum_coverage_locked=true` 的條件；2) `_worker` conversion quality report 區分 pass / warn / fail；3) issue highlight smoke 使用 real IFC GUID → USD prim path；4) baseline fixture evidence 不低於門檻 |
-| **驗證指令** | `cd _worker && python -m pytest tests` + real conversion smoke + single Kit/browser issue highlight smoke（有 GPU 時） |
-| **建議 spec id** | `worker-mapping-quality-baseline` |
-| **與既有 spec 關係** | MODIFY `worker-artifact-pipeline` real mapping quality gate；MODIFY `runtime-verification-evidence` real conversion quality metrics |
+| **Archive** | `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/` |
+| **涵蓋原候選** | #3 `worker-artifact-lineage-api` + #3A `worker-mapping-quality-baseline` |
+| **已併入 specs** | `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui` |
+| **已完成** | lineage graph API、stable mapping/index derived artifact IDs、worker UI lineage / quality view、all-IFC-entity coverage denominator、`minimum_coverage_ratio=1.0` policy、warn reviewable / fail blocking readiness、storage batch helper |
+| **仍未宣稱完成** | canonical 13-file real batch 未完成；`minimum_coverage_locked=true` production baseline 與 issue → real prim verified evidence 尚未成立 |
#### 候選 #4：`coordinator-session-lifecycle-events-audit`
@@ -650,7 +637,10 @@ A：可以，但**不是把 #2 spec 換掉**：
Archived / 已完成:
#1 worker-real-conversion-quality ✓ 已於 2026-05-11 archive
解除 IFC→USDC placeholder blocker；real worker-produced USDC 已有 single Kit/browser evidence
- 剩餘：coverage baseline 門檻仍是 measure-first，待後續 spec 鎖定
+ 剩餘：canonical storage real batch 未完成，production coverage baseline 未鎖定
+ #3/#3A worker-mapping-lineage-quality-baseline ✓ 已於 2026-05-12 archive
+ lineage API / worker UI / all-IFC-entity coverage policy 已併入 specs
+ 剩餘：canonical 13-file real batch 未完成，production coverage baseline 未鎖定
P0-hold (等待 GPU 購買與部署):
#2 streaming-multi-instance-orchestration ★★ ⏸ 等待 GPU 購買與部署後執行
@@ -659,8 +649,6 @@ P0-hold (等待 GPU 購買與部署):
roadmap 端：GPU capacity 到位後才重啟驗證並同步 §1.3 / §2 / §9.2
P1 (這月):
- #3 worker-artifact-lineage-api 收斂 lineage 為 query API
- #3A worker-mapping-quality-baseline 鎖定 #1 archive 後仍 measure-first 的 mapping coverage / issue highlight 門檻
#4 coordinator-session-lifecycle-events-audit 事件 schema 收斂（為 #6 webhook 鋪路；audit log 持久化屬 Phase 6 凍結）
P2 (下月):
@@ -685,14 +673,14 @@ P3-frozen (⏸ 等待公司業務系統接入；目前不規劃 OpenSpec spec):
```txt
#1 (✓ archived) ─┬─→ Kit GPU render 證據已解鎖
├─→ Phase 5 可用 real worker-produced USDC 作前提
- ├─→ #3A mapping coverage / issue highlight baseline 鎖門檻
- └─→ #3 lineage API 將 metadata lineage 變成可查詢圖
+ └─→ #3/#3A (✓ archived) lineage API + all-IFC-entity coverage policy
#2 (⏸ 等待 GPU 購買與部署)
─→ GPU-backed multi-instance routing 證據解鎖
─→ #2A (OVAS Helm 升級需要先在已部署 GPU capacity 上跑通多 Kit)
-#3 ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
+#3/#3A (✓ archived) ─→ 後續只剩 canonical storage real batch 與 issue highlight evidence
+ ─→ ⏸ #8 audit (Phase 6 凍結；待業務接入)
#4 ─→ #6 mock webhook (P2 可探索)
─→ ⏸ #8 audit (Phase 6 凍結)
@@ -708,7 +696,7 @@ P3-frozen (⏸ 等待公司業務系統接入；目前不規劃 OpenSpec spec):
| # | 風險 | 緩解 |
|---|---|---|
-| R1 | #1 已選 IfcOpenShell + `usd-core` 作為 real IFC→USDC adapter external prerequisites，後續仍有 dependency / license / Windows runtime drift 風險 | 保持 adapter boundary，不讓 `_worker` contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。Coverage baseline 仍採 measure-first，待後續 spec 鎖最低門檻 |
+| R1 | #1 已選 IfcOpenShell + `usd-core` 作為 real IFC→USDC adapter external prerequisites，後續仍有 dependency / license / Windows runtime drift 風險 | 保持 adapter boundary，不讓 `_worker` contract 綁死單一本機腳本路徑；缺 converter 或 USDC 不可開啟時必須 fail job，不得 fallback ready placeholder。#3/#3A 已定義 all-IFC-entity coverage policy，但 canonical storage real batch 未完成前不得把 production baseline 標成 locked |
| R2 | 候選 #2 在 8 GB VRAM 下可能無法並行 2 個 Kit；最新狀態為等待 GPU 購買與部署後執行 | GPU 未購買部署前不執行 dedicated multi-Kit runtime 驗證，也不標 passed / failed / in-progress；重新啟動前需具備至少兩個 GPU-backed Kit endpoints，硬體門檻 24 GB VRAM 見 §9.2 |
| R3 | 規劃過早跳到 Phase 5/6，本機 demo 變不穩 | P0 / P1 全部 land 之前不啟動 #5 / #6 之後的候選；Phase 6 候選 #7 / #8 / #9 連同細項一律凍結至業務系統接入 |
| R4 | OpenSpec 在 main 上累積太多 untracked 變更 | 每個候選都走 `codex/openspec/` branch + PR；本文件不算 OpenSpec change，是 plan |
@@ -1125,24 +1113,29 @@ B → C 觸發：
- 對 `bim-review-coordinator` 與 `web-viewer-sample` 重跑 `npm ci`，確認 `tsx.cmd` / `vite.cmd` 存在。
- 以 `.\scripts\start-all.ps1 -SkipStreaming` 驗 8001 / 8005 / 8004 / 5173；這一步通過後，才把後續 OpenSpec / runtime evidence 的失敗視為功能或 spec 問題。
-2. **確認 #1 archive 對齊已完成，後續不再重開 `worker-real-conversion-quality`**：
+2. **確認 #1 與 #3/#3A archive 對齊已完成，後續不再重開已完成 change**：
- `#1 worker-real-conversion-quality` 已歸檔到 `openspec/changes/archive/2026-05-11-worker-real-conversion-quality/`。
- 現行 specs 已同步到 `worker-artifact-pipeline` 與 `runtime-verification-evidence`。
- - 下一步若要提升品質，不是重開 #1，而是另開 **#3A `worker-mapping-quality-baseline`**（mapping coverage / material fidelity / issue highlight 門檻）或 **#3 `worker-artifact-lineage-api`**（lineage API / UI）等更小 spec。
+ - `#3/#3A worker-mapping-lineage-quality-baseline` 已歸檔到 `openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/`，並同步到 `worker-artifact-pipeline`、`runtime-verification-evidence`、`worker-demo-upload-convert-ui`。
+ - 後續若要提升品質，不重開 #1 / #3 / #3A；改以 canonical storage batch completion 或 issue highlight evidence 作為下一個更小切片。
+
+3. **下一個 worker 品質工作：補 canonical storage 13-file real batch evidence**：
+ - 使用 `C:\Repos\active\iot\AI-BIM-governance\storage\*.ifc` 作為正式本機 fixture root。
+ - 先解決 89MB fixture `--limit 1` 超過 600s timeout 的 runtime / performance 問題，再擴到 13-file batch。
+ - 只有全批次 real conversion、USDC openability、lineage API、all-IFC-entity coverage 都通過時，才可把 `minimum_coverage_locked=true` production baseline 寫入 evidence。
-3. **暫停 `#2 streaming-multi-instance-orchestration`，等待 GPU 購買與部署後再執行**：
+4. **暫停 `#2 streaming-multi-instance-orchestration`，等待 GPU 購買與部署後再執行**：
- 在至少兩個 GPU-backed Kit endpoints 可用前，不啟動 dedicated multi-Kit runtime 驗證，也不把它標為進行中、passed 或 failed。
- GPU 購買與部署完成後，先依 §9.2 確認 24 GB VRAM 級 GPU capacity、distinct signaling / media port pair、Kit stream listener 與 browser evidence 儲存位置，再重新啟動驗證。
- 重啟驗證通過後，才更新 §1.3 / §2 Phase 3 / §9.2 與 `runtime-verification-evidence` §6.4 evidence。
- **MCP 補強**：驗證前用 `kit-mcp` `get_kit_extension_details("omni.kit.livestream.webrtc")` 確認 signalPort 49100 / streamPort 47999 設定與 NVIDIA 預設值一致；多 instance 時兩台需用不同 port pair。
-4. **挑一個 P1 候選啟動 OpenSpec explore**：
- - 推薦在 `#3 worker-artifact-lineage-api`、`#3A worker-mapping-quality-baseline` 與 `#4 coordinator-session-lifecycle-events-audit` 三選一。
- - 若要延續 #1 的 worker 成果並處理 archive 後的品質 gap，優先 `#3A`：把 mapping coverage / material fidelity / issue highlight 門檻從 measure-first 變成 baseline。
- - 若要強化 artifact traceability，選 `#3`：把 source → derived → mapping lineage 從 metadata 變成可查詢 API / worker UI。
+5. **下一個 P1 OpenSpec 候選以 `#4 coordinator-session-lifecycle-events-audit` 為主**：
+ - #3 / #3A 已完成並歸檔，不再列為候選池。
- 若要支撐後續 webhook / observability，選 `#4`：把 lifecycle events 收斂成 append-only event schema。
+ - 若要先補 worker evidence，不開新 spec，優先延續現行 `runtime-verification-evidence` 的 canonical storage batch evidence。
-5. **評估是否啟動 `#1A` / `#2A`（採用 NVIDIA reference impl，見 §12 / §13）**：
+6. **評估是否啟動 `#1A` / `#2A`（採用 NVIDIA reference impl，見 §12 / §13）**：
- 在啟動前，先依 §13 的決策框架評估「**自建 vs 採用 NVIDIA**」對應風險（依賴鎖定 / Nucleus 部署 / license / GPU 鎖定）。
- 若決定啟動 #1A：用 `kit-mcp` `get_kit_extension_details("omni.kit.collaboration.presence_layer")` 查 PresenceLayerAPI 22 個方法（`broadcast_local_bound_camera` / `enter_follow_mode` / `get_selections`）。
- 若決定啟動 #2A（OVAS spike，2026-05-08 17:00 補）：
@@ -1152,11 +1145,11 @@ B → C 觸發：
4. **不變的部分**：`web-viewer-sample` UI、`_bim-control` / `_worker` data plane、Socket.IO collaboration 全部保留；OVAS 只取代「Kit container 啟動 / 調度」（§2 4.4 / 4.5 / 4.11）。
5. **避免的事**：不要把 OVAS image build 流程混進 `bim-streaming-server` 的單機 dev workflow；把 OVAS 部署放 `deploy/ovas/` 獨立目錄，Tier A 仍可走 `scripts/start-multi-kit.ps1` 自寫 KitInstancePool 路徑。
-6. **Phase 6 候選 #7 / #8 / #9 與 §2 Phase 6 細項一律暫不啟動**：
+7. **Phase 6 候選 #7 / #8 / #9 與 §2 Phase 6 細項一律暫不啟動**：
- 依使用者 2026-05-08 16:05 指示，這些細項目前 ⏸ 凍結，**等待公司業務系統接入**（SSO / IT 維運 / SLA / billing / 合約等）。
- 任何想解凍的提案，需在 PR description 引用該決策段落（本文件 §2 Phase 6 表 + §6 P3-frozen），並附上業務系統接入確認文件。
-7. **延後啟動 `#5` / `#6`**：
+8. **延後啟動 `#5` / `#6`**：
- `#5 ai-rule-carbon-result-contract` 與 `#6 notification-webhook-service` 是 P2 的入口 contract（mock 階段），但若 P0 / P1 還沒 land 就開，會是**範圍擴散風險**。
- production-grade 的 audit log persistence 與 webhook delivery 屬 Phase 6 凍結範圍（§2 Phase 6 表）。
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/.openspec.yaml b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/.openspec.yaml
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/.openspec.yaml
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/.openspec.yaml
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/design.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/design.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/design.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/design.md
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/proposal.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/proposal.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/proposal.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/proposal.md
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/specs/runtime-verification-evidence/spec.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/runtime-verification-evidence/spec.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/specs/runtime-verification-evidence/spec.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/runtime-verification-evidence/spec.md
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/specs/worker-artifact-pipeline/spec.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/worker-artifact-pipeline/spec.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/specs/worker-artifact-pipeline/spec.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/worker-artifact-pipeline/spec.md
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/specs/worker-demo-upload-convert-ui/spec.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/worker-demo-upload-convert-ui/spec.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/specs/worker-demo-upload-convert-ui/spec.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/specs/worker-demo-upload-convert-ui/spec.md
diff --git a/openspec/changes/worker-mapping-lineage-quality-baseline/tasks.md b/openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/tasks.md
similarity index 100%
rename from openspec/changes/worker-mapping-lineage-quality-baseline/tasks.md
rename to openspec/changes/archive/2026-05-12-worker-mapping-lineage-quality-baseline/tasks.md
diff --git a/openspec/specs/runtime-verification-evidence/spec.md b/openspec/specs/runtime-verification-evidence/spec.md
index a921c290f..474b221b0 100644
--- a/openspec/specs/runtime-verification-evidence/spec.md
+++ b/openspec/specs/runtime-verification-evidence/spec.md
@@ -104,22 +104,40 @@ quality gates is contract evidence only.
### Requirement: Real conversion evidence records quality metrics
-The workspace SHALL record real conversion quality metrics before treating a conversion as accepted evidence. Metrics MUST include fixture identity, fixture size, converter identity, duration, USDC openability, source IFC element count, USD prim count, mapped count, unmapped count, coverage ratio, and whether a minimum coverage baseline is locked. P0 evidence MUST use a measure-first policy: coverage report is required, but low coverage alone MUST NOT fail CI until a later baseline threshold is established.
+The workspace SHALL record real conversion quality metrics before treating a conversion as accepted evidence. Metrics MUST include fixture identity, fixture size, converter identity, duration, USDC openability, source IFC entity count, USD prim count, mapped entity count, unmapped entity count, coverage ratio, coverage status, lineage API status, and whether a minimum coverage baseline is locked.
-P0 evidence records coverage as observed data. It MUST NOT claim a minimum
-issue-to-real-prim baseline is locked until a later change adds the threshold as
-a hard gate.
+Evidence before threshold lock MUST use a measure-first policy: coverage report is required, but low coverage alone MUST NOT fail CI until the baseline threshold is established. Evidence after threshold lock MUST record `minimum_coverage_baseline_locked=true`, `minimum_coverage_ratio=1.0`, denominator policy for all source IFC entities, pass/warn/fail policy, and whether the current conversion satisfies issue-to-real-prim readiness.
#### Scenario: Large IFC fixture is converted
- **WHEN** a repo-local IFC fixture is converted by the real conversion path
-- **THEN** the evidence records fixture path or identifier, file size, converter identity, duration, resulting artifact URLs, USDC openability, and mapping coverage metrics
+- **THEN** the evidence records fixture path or identifier, file size, converter identity, duration, resulting artifact URLs, USDC openability, lineage API result, and mapping coverage metrics
#### Scenario: Mapping coverage is measured before threshold lock
- **WHEN** the real conversion path produces a coverage report before a minimum threshold is locked
- **THEN** the evidence records the observed coverage, keeps CI passing if the hard conversion checks passed, and does not classify minimum issue-to-real-prim coverage as verified
+#### Scenario: Mapping coverage is evaluated after threshold lock
+
+- **WHEN** the real conversion path produces a coverage report after a minimum threshold is locked
+- **THEN** the evidence records `minimum_coverage_ratio=1.0`, `coverage_denominator=source_ifc_entity_count`, `coverage_status`, policy diagnostics, and whether the conversion is accepted, warned, or failed by the locked baseline
+
+#### Scenario: Non-geometric entity coverage is recorded
+
+- **WHEN** a fixture contains non-geometric IFC entities such as property sets, type objects, relationship entities, project, site, building, or storey containers
+- **THEN** the evidence records whether those entities materialized as non-renderable USD prims and includes them in mapped/unmapped entity counts
+
+#### Scenario: Warning coverage remains reviewable
+
+- **WHEN** real conversion evidence records `coverage_status=warn`
+- **THEN** the evidence may classify the artifact group as reviewable with degraded mapping quality, but MUST NOT classify issue-to-real-prim baseline as verified
+
+#### Scenario: Lineage API is missing from conversion evidence
+
+- **WHEN** real conversion succeeds but the lineage API cannot return the source -> derived -> mapping graph for the converted artifact
+- **THEN** the evidence records conversion success separately and MUST NOT claim lineage visualization or traceability baseline passed
+
### Requirement: Single Kit render evidence uses real worker artifacts
Single Kit render evidence SHALL use `_worker` real conversion artifacts when validating the review-session path from IFC source to browser viewport. The evidence MUST include the conversion job ID and artifact group ID so the rendered stage can be traced back to the source IFC.
@@ -133,3 +151,38 @@ Single Kit render evidence SHALL use `_worker` real conversion artifacts when va
- **WHEN** real conversion succeeds but Kit/GPU/browser verification cannot run in the current environment
- **THEN** the evidence records conversion success and marks single Kit render evidence as `blocked` with the missing runtime prerequisite
+
+### Requirement: Batch storage IFC evidence calibrates mapping baseline
+
+Runtime verification evidence SHALL include a batch conversion evidence tier for repo-local `storage/*.ifc` fixtures before declaring the mapping coverage baseline locked. The evidence MUST identify the fixture glob, resolved root, fixture count, per-fixture conversion job IDs, per-fixture artifact group IDs, USDC openability, source IFC entity count, mapped/unmapped entity counts, coverage ratio, `minimum_coverage_ratio=1.0`, coverage status, lineage API status, and whether all required fixtures passed.
+
+The standard local Windows fixture glob is `C:\Repos\active\iot\AI-BIM-governance\storage\*.ifc`. In worktrees and CI-like local runs, the same requirement MAY resolve through `_worker` `dev_storage_root` as repo-local `storage/*.ifc`, but the evidence MUST record the resolved path or approved exception.
+
+#### Scenario: Full storage fixture batch passes
+
+- **WHEN** all required `storage/*.ifc` fixtures complete real IFC->USDC conversion with openable USDC, truthful mapping output, lineage API success, and every source IFC entity mapped to at least one real USD prim path
+- **THEN** the evidence records `minimum_coverage_locked=true`, `minimum_coverage_ratio=1.0`, `coverage_denominator=source_ifc_entity_count`, per-fixture metrics, and the batch status as `passed`
+
+#### Scenario: Storage fixture batch is incomplete
+
+- **WHEN** the fixture root is unavailable, contains no IFC files, or only a subset was intentionally run
+- **THEN** the evidence records `blocked` or `partial` with the missing prerequisite or subset reason and MUST NOT mark the production mapping baseline as locked
+
+#### Scenario: One fixture fails baseline
+
+- **WHEN** any required fixture fails conversion, USDC openability, truthful mapping checks, lineage API lookup, or locked coverage threshold
+- **THEN** the batch evidence records the failed fixture and reason, and the overall batch status is not `passed`
+
+### Requirement: Issue-to-real-prim evidence requires locked real mapping
+
+Runtime verification evidence SHALL only classify issue-to-real-prim highlight baseline as verified when the worker mapping is real, coverage baseline is locked, and the highlighted prim path can be traced from an issue's IFC GUID through `element_mapping.json` to `primary_usd_prim_path` or `usd_prim_paths`.
+
+#### Scenario: Issue highlight uses real mapping
+
+- **WHEN** a reviewer or smoke test highlights an issue whose IFC GUID appears in real mapping output with a valid primary USD prim path
+- **THEN** the evidence records the issue identifier, IFC GUID, mapped USD prim path, conversion job ID, artifact group ID, and `minimum_coverage_locked=true`
+
+#### Scenario: Issue highlight uses fallback or missing mapping
+
+- **WHEN** the highlighted issue path comes from fallback IDs, synthetic IDs, missing mapping, or an unlocked coverage baseline
+- **THEN** the evidence MUST NOT classify issue-to-real-prim baseline as verified, even if the browser or Kit interaction itself succeeds
diff --git a/openspec/specs/worker-artifact-pipeline/spec.md b/openspec/specs/worker-artifact-pipeline/spec.md
index 50aa781f8..cfc461a71 100644
--- a/openspec/specs/worker-artifact-pipeline/spec.md
+++ b/openspec/specs/worker-artifact-pipeline/spec.md
@@ -171,19 +171,101 @@ shapes for the same product.
### Requirement: Worker reports conversion quality before enforcing coverage gates
-`_worker` SHALL only mark an artifact group ready for review when the real conversion output passes hard quality gates. P0 hard gates MUST include USDC openability. Mapping coverage MUST be measured and reported when `generate_mapping=true`, but P0 CI and artifact readiness MUST NOT fail only because coverage is below an unstabilized baseline. After baseline stabilization, the minimum mapping coverage threshold MAY become a hard gate through a later spec update.
+`_worker` SHALL only mark an artifact group ready for review when the real conversion output passes hard quality gates. Hard gates MUST include USDC openability, renderable prim presence, non-placeholder output, and truthful mapping output when `generate_mapping=true`.
+
+Mapping coverage MUST be measured and reported when `generate_mapping=true`. Before a baseline is locked, `_worker` MUST continue to report coverage as observed data and MUST NOT fail CI only because coverage is below an unstabilized threshold. After baseline stabilization, `_worker` MUST expose a locked minimum coverage policy with `minimum_coverage_baseline_locked=true`, `minimum_coverage_ratio=1.0`, `coverage_denominator=source_ifc_entity_count`, `coverage_status`, and policy diagnostics.
+
+Coverage calculation MUST include every source IFC entity in the denominator. `_worker` MUST materialize every IFC entity as a USD prim with stable traceability back to the source IFC entity. IFC product / geometry entities SHOULD become renderable or highlightable USD prims when geometry exists. Non-geometric IFC entities, including project/site/building containers, type metadata, property sets, and relationship entities, MUST become non-renderable USD prims that preserve IFC class, entity identifier, GlobalId when present, Name when present, and relationship metadata when available. No IFC entity class may be excluded from coverage solely because it is not renderable.
+
+Every source IFC entity MUST map to at least one real USD prim path for `coverage_status=pass`. When coverage status is `warn`, `_worker` MAY keep the artifact group eligible for review-session creation as degraded quality, but MUST NOT classify issue-to-real-prim readiness as verified. When coverage status is `fail`, `_worker` MUST NOT claim mapping readiness or issue-to-real-prim highlight readiness.
#### Scenario: Hard quality gate passes
-- **WHEN** a conversion job produces an openable USDC and writes the required coverage report
+- **WHEN** a conversion job produces an openable USDC, renderable prims, non-placeholder output, and truthful mapping report
- **THEN** `_worker` marks the conversion job `succeeded`, returns derived artifact URLs, and includes coverage metrics in the result payload
-#### Scenario: Mapping coverage is measured below target during P0
+#### Scenario: Mapping coverage is measured before threshold lock
+
+- **WHEN** a conversion job produces an openable USDC and coverage report before a minimum threshold is locked
+- **THEN** `_worker` returns the coverage report with `minimum_coverage_baseline_locked=false`, does not fail CI only for low coverage, and does not claim that minimum issue-to-real-prim coverage has been verified
+
+#### Scenario: Mapping coverage passes locked threshold
+
+- **WHEN** every source IFC entity maps to at least one real USD prim path
+- **THEN** `_worker` returns `minimum_coverage_baseline_locked=true`, `minimum_coverage_ratio=1.0`, `coverage_denominator=source_ifc_entity_count`, `coverage_status=pass`, the applied denominator, and no coverage failure diagnostic
+
+#### Scenario: Mapping coverage falls into warning policy
+
+- **WHEN** a conversion job produces openable USDC and mostly truthful mapping, but one or more IFC entities cannot be mapped for a known, explicitly allowed degradation reason
+- **THEN** `_worker` returns `coverage_status=warn`, preserves artifact traceability, keeps the artifact group eligible for review-session creation, and reports that issue-to-real-prim highlight readiness is degraded rather than verified
+
+#### Scenario: Mapping coverage fails locked threshold
-- **WHEN** a P0 conversion job produces an openable USDC but observed mapping coverage is low
-- **THEN** `_worker` still returns the coverage report, does not fail CI only for low coverage, and does not claim that a minimum coverage baseline has been locked
+- **WHEN** any source IFC entity lacks a real USD prim mapping and the condition is not covered by an explicitly allowed warning policy
+- **THEN** `_worker` returns `coverage_status=fail`, records validation diagnostics, and MUST NOT mark mapping readiness or issue-to-real-prim highlight readiness as verified
#### Scenario: Quality metrics are exposed
- **WHEN** `GET /api/conversions/{conversion_job_id}/result` returns a conversion result with status `succeeded`
-- **THEN** the payload includes converter identity, conversion duration, source IFC element count, USD prim count, mapped count, unmapped count, coverage ratio, threshold status, and validation warnings when present
+- **THEN** the payload includes converter identity, conversion duration, source IFC entity count, USD prim count, mapped count, unmapped count, coverage ratio, `minimum_coverage_ratio`, denominator policy, baseline lock status, coverage status, and validation warnings when present
+
+#### Scenario: Non-geometric IFC entity materializes as USD prim
+
+- **WHEN** the source IFC contains non-geometric entities such as property sets, type objects, relationship entities, project, site, building, or storey containers
+- **THEN** `_worker` materializes each entity as a non-renderable USD prim with stable IFC traceability fields
+- **AND** those entities are included in `source_ifc_entity_count` and coverage calculation
+
+### Requirement: Worker exposes artifact lineage graph API
+
+`_worker` SHALL expose `GET /api/artifacts/{artifact_id}/lineage` for source, derived model, index, and mapping artifact identifiers that belong to the worker object layout. The response MUST normalize existing `metadata.json`, source artifact index, artifact group index, conversion job result, and derived artifact identifiers into a single lineage graph without making `_bim-control` read local files or become artifact byte authority.
+
+The lineage response MUST include `artifact_id`, `artifact_group_id`, `tenant_id`, `project_id`, `model_version_id`, `nodes[]`, `edges[]`, `root_source_artifact_id`, `conversion_job_ids[]`, `quality_metrics_summary`, and `diagnostics[]`. Nodes MUST identify source IFC, derived USDC, `ifc_index.json`, `usd_index.json`, `element_mapping.json`, and `metadata.json` when present. Every source, derived model, index, and mapping node MUST include a stable `artifact_id`. Derived model, index, and mapping node IDs MUST prefer the conversion result `derived_artifact_ids` values. Missing optional artifacts MUST be reported in `diagnostics[]` rather than causing a server error.
+
+#### Scenario: Derived artifact lineage is queried
+
+- **WHEN** a client calls `GET /api/artifacts/{artifact_id}/lineage` for a succeeded `model.usdc` artifact
+- **THEN** `_worker` returns a lineage graph linking the source IFC artifact to the conversion job, derived USDC, index files, mapping file, and metadata URL
+- **AND** the graph includes quality metrics summary for the conversion that produced the derived artifact
+- **AND** derived USDC, IFC index, USD index, and element mapping nodes use the stable artifact IDs from `derived_artifact_ids`
+
+#### Scenario: Mapping and index lineage are queried by stable ID
+
+- **WHEN** a client calls `GET /api/artifacts/{artifact_id}/lineage` using `derived_artifact_ids.ifc_index`, `derived_artifact_ids.usd_index`, or `derived_artifact_ids.element_mapping`
+- **THEN** `_worker` returns the same artifact group lineage graph and identifies the requested index or mapping node as the current artifact
+
+#### Scenario: Source artifact lineage is queried before conversion
+
+- **WHEN** a client calls `GET /api/artifacts/{artifact_id}/lineage` for an uploaded source artifact that has no succeeded conversion
+- **THEN** `_worker` returns a graph with the source node and diagnostics that derived model, mapping, and index artifacts are not ready
+
+#### Scenario: Unknown artifact lineage is rejected
+
+- **WHEN** a client calls `GET /api/artifacts/{artifact_id}/lineage` for an artifact identifier not present in worker indexes, artifact groups, conversion results, or metadata
+- **THEN** `_worker` returns `404` and does not fabricate lineage
+
+#### Scenario: Legacy metadata is missing lineage fields
+
+- **WHEN** `_worker` reads older metadata that lacks some lineage fields
+- **THEN** the lineage API returns the recoverable graph fields and records missing fields in `diagnostics[]` without failing the request
+
+### Requirement: Worker supports storage IFC batch quality verification
+
+`_worker` SHALL provide an implementation path for batch quality verification over repo-local `storage/*.ifc` fixtures. The Windows local fixture glob `C:\Repos\active\iot\AI-BIM-governance\storage\*.ifc` and the worktree-local `_worker` dev source root `../storage` SHALL be treated as the same fixture source class for local validation.
+
+The batch verification path MUST use existing worker artifact intake and selected-source conversion contracts unless a later production batch-job spec is opened. Each fixture result MUST record filename, relative path, size, source artifact ID, artifact group ID, conversion job ID, USDC openability, mapped count, unmapped count, coverage ratio, coverage status, lineage API status, duration when available, and failure or warning details.
+
+#### Scenario: Storage IFC fixtures are converted in batch
+
+- **WHEN** batch verification runs against a readable `storage/*.ifc` fixture set
+- **THEN** `_worker` creates distinct source artifacts and conversion jobs for each fixture through the worker artifact pipeline
+- **AND** the batch summary records per-fixture conversion quality and lineage API status
+
+#### Scenario: Storage fixture root is unavailable
+
+- **WHEN** the configured dev storage root is missing, unreadable, or contains no `.ifc` files
+- **THEN** batch verification reports `blocked` with the missing fixture prerequisite and MUST NOT claim that the coverage baseline is locked
+
+#### Scenario: Batch fixture has duplicate bytes
+
+- **WHEN** two fixture files have identical bytes but different filenames or relative paths
+- **THEN** `_worker` MUST preserve each fixture's `original_filename`, source artifact ID, conversion job ID, and lineage independently
diff --git a/openspec/specs/worker-demo-upload-convert-ui/spec.md b/openspec/specs/worker-demo-upload-convert-ui/spec.md
index bb6d146e9..3091aa87a 100644
--- a/openspec/specs/worker-demo-upload-convert-ui/spec.md
+++ b/openspec/specs/worker-demo-upload-convert-ui/spec.md
@@ -71,3 +71,34 @@ The worker demo UI SHALL remain scoped to artifact intake and conversion, and SH
- **WHEN** the worker demo UI renders
- **THEN** it MUST NOT provide issue editing, annotation editing, session lifecycle management, or WebRTC streaming controls
+
+### Requirement: Worker UI visualizes lineage and quality status
+
+The worker demo UI SHALL expose a lineage and conversion quality view for worker artifacts. The UI MUST use `_worker` APIs such as `GET /api/artifacts/{artifact_id}/lineage`, `GET /api/conversions/{conversion_job_id}/result`, and `GET /api/artifact-groups/{artifact_group_id}/readiness` rather than reading local files directly.
+
+The view MUST remain scoped to artifact intake, conversion observability, lineage, and quality evidence. It MUST NOT provide review issue editing, annotation editing, session lifecycle management, or WebRTC streaming controls.
+
+#### Scenario: User opens lineage for a converted artifact
+
+- **WHEN** a conversion job succeeds and the user opens its lineage view
+- **THEN** the UI displays source IFC, derived USDC, index artifacts, mapping artifact, stable artifact IDs, conversion job ID, artifact group ID, object URLs, metadata URL, and quality status
+
+#### Scenario: Quality status is visible
+
+- **WHEN** lineage API or conversion result returns quality metrics
+- **THEN** the UI displays coverage ratio, `minimum_coverage_ratio`, baseline lock status, `coverage_denominator=source_ifc_entity_count`, mapped/unmapped IFC entity counts, coverage status, and warnings or diagnostics when present
+
+#### Scenario: Warning quality remains reviewable
+
+- **WHEN** the lineage API or conversion result reports `coverage_status=warn`
+- **THEN** the UI keeps the review handoff available while clearly showing degraded mapping quality and MUST NOT label issue-to-real-prim readiness as verified
+
+#### Scenario: Lineage is incomplete
+
+- **WHEN** the lineage API reports missing mapping, missing derived artifact, legacy metadata gaps, or unavailable quality metrics
+- **THEN** the UI displays the incomplete state without hiding the source artifact or exposing absolute local filesystem paths
+
+#### Scenario: Review workflow remains outside worker UI
+
+- **WHEN** an artifact group is ready and lineage is visible in the worker UI
+- **THEN** the next review action still routes to `bim-review-coordinator` or the existing review viewer flow, and the worker UI does not manage review sessions