ADR-018: 以 server 實作為錨點反向建立 Domain Model 與 API Spec
ADR 編號: 018 狀態: 提議中 (Proposed) 提案日期: 2026-10-01 決策日期: — 最後修訂: 2026-10-04 決策者: 團隊 peer review：設計方向兩輪通過；P0、P1 成果各三輪通過；P2 成果兩輪通過、試點回饋修訂兩輪通過；P3 待審閱 範圍:
/domain-model、/api-spec、Domain Model 與 API Spec 的來源標示、授權欠帳、m-depends-on.md、m-dev-guardrails.md
摘要
部分從 appfuse scaffold 的應用沒有完整依方法論開發：Prototype 手動實作後 promote 到 web，server 也手動實作並完成整合，但缺少 Roadmap、Epic、US 與 SBE。這些應用無法使用框架提供的 API Spec 文件、Bruno API 測試，也無法讓 RPT 對接 Domain Model，因為現行流程都從文件出發。
server 模組是業務邏輯的核心。本提案讓這類應用以 server 實作為錨點，從程式碼反向建立 Domain Model 與 API Spec，並標示其來源為「實作現況」而非「設計契約」。如此可先完成 server 的文件化與 API 測試，RPT 也能依 ADR-017 經 Domain Model 連接 server；之後補建 US／SBE 時，再逐步把現況文件確認為契約。
審閱結論
2026-10-01 經兩輪 peer review 通過設計方向。第 1 輪 4 條意見（3 major、1 minor）皆已修訂處置，無不採納項目：補上 source／version 分立與下游守門（D1.1）、可重現錨點（D1.2）、Bruno 產出語意（D1.3），並補文檔站側邊欄。原待決點 2～4 因此收斂為決定。
通過範圍僅限本 ADR 與文檔站索引。 本次通過不解鎖任何規則、skill 或工具的修改：P0～P3 各階段實作須另行送審；ADR 狀態維持 Proposed，全部階段通過後才改為 Accepted。待決點 1（Domain Model 路徑）於 P0 定案。
背景
現行能力與缺口
| 能力 | 現況 | 缺口 |
|---|---|---|
/api-spec 反向萃取 | 可從單一 Controller 產生 .md 與 .bru | 一次一個 Controller；產出不標示來源；只有 anyRequest().authenticated() 的端點會阻擋文件定案；不連結 Domain Model；業務規則無 US 時全為 TODO |
/domain-model | 四條路徑皆從 Roadmap、Epic、US／SBE 或需求材料出發 | 沒有從 entity 建立的路徑 |
正向 /api-spec 遇到既有 .md | 合併同資源的端點 | 分不出哪些內容是照現況寫的、哪些是設計過的；實作錯誤可能被當成契約，後續 E2E 反而保護錯誤 |
| Bruno collection 說明 | 測試帳號說明寫死為參考實作 seed 的統一密碼 | 不適用於自有 seed 的應用 |
既有不一致：Domain Model 路徑
/domain-model 寫入 specs/domain-model.md（/impl、/next、/assess、/analyze、/impact 亦讀此路徑），但 m-depends-on.md、/api-spec 範本與 /us 的 depends_on 引用 design/domain-model.md，參考實作的實際檔案也位於 design/。反向文件化需要 API Spec 與 RPT 確實連到 Domain Model，因此必須先統一路徑。
決策
D1：來源標示
反向產生的內容標示 source: implementation，代表「描述實作現況」；人確認為設計契約後改為 source: design。未標示者視為 design（既有文件相容）。
| 產出 | 標示位置 |
|---|---|
API Spec .md | frontmatter，含錨點（D1.2） |
| Domain Model | 各實體區段（同一份文件可混合兩種來源），含錨點 |
Bruno .bru | 見 D1.3 |
source: implementation 的內容不得被靜默改寫成 design：正向模式遇到時須逐資源或逐實體詢問「確認為契約」「依設計修訂」或「保留現況」。
D1.1：source 與 version 是兩個獨立維度
| 維度 | 回答的問題 | 值 | 由誰改變 |
|---|---|---|---|
version（m-doc-version.md） | 文件是否經審閱定案 | reference／draft／published | /assess 完成 A/B 修訂後依 Step 10.2 推進 published |
source（本 ADR） | 文件描述的是現況還是設計契約 | implementation／design | 只有人明示確認才由 implementation 轉 design |
/assess 可評估實作錨定的 Domain Model 與 API Spec；此時 published 的意義是「文件經審閱、正確描述現況」，不會把 source 轉成 design。
下游守門（P1 前置，於補建流程定案前暫行）：把 API Spec 或 Domain Model 當成設計輸入的 consumer——/impl、/e2e-script、/uat-script、/code-review、/api-spec 正向模式——遇到所依據的資源或實體為 source: implementation 時，不論 version 為何，一律停止並說明，提示先確認為 design 或修訂。實作錨定的文件因此不滿足 m-dev-guardrails.md 的 server 階段必要輸入。授權矩陣完整與否不影響此判定。
D1.2：可重現的錨點
錨點必須能還原萃取當時讀到的內容：
- 只從已提交的內容萃取：萃取範圍內任一檔案與 HEAD 不同（含未追蹤檔）即停止，提示先提交。不從含未提交修改的工作樹產生文件。
- 記錄實際讀取的全部來源：commit SHA，加上萃取所依據的每個檔案路徑與其 git blob SHA。範圍不只 Controller 與 entity，還包含 DTO、service（狀態轉換）、security 設定（授權矩陣）、enum 等實際讀取的檔案。
- blob SHA 可從 repo 還原當時內容，也讓 D5 的偏離偵測精確到檔案。
D1.3：Bruno 產出的語意
.bru 可脫離 .md 獨立執行，且 /api-spec 把 Bruno 定位為契約守門。因此反向產生的 Bruno 須自帶來源與未確認狀態：
- 資源
folder.bru的 docs 區段註明source: implementation、錨點 commit，以及對應.md與授權欠帳清冊的連結。 - 每支 request 的 docs 區段註明「實作現況，未確認為契約」；屬授權欠帳的端點另註明欠帳。
- 在確認為
design前，這些 request 的執行結果只代表「現況可運作」，不構成正式契約、E2E 或 UAT 的驗收證據。
D2：涵蓋範圍
反向產生的 Domain Model 涵蓋應用業務域，加上已安裝 feature 的 referenceDomains（應用已接管的可運行業務用法，例如報表 job）。範圍依 server 模組 .claude/features.json 推導，不手列。框架 skeleton 與 structuralDomains（帳號與權限）只在「平台實體」一節列摘要與框架文件連結，不逐一建模。
D3：/domain-model 新增路徑 E：從 server 實作建立
- AI 從 entity、enum、關聯、驗證註解與 service 中的狀態轉換整理候選實體、屬性、狀態機。
- 仍採 Level 2 對話式確認：業務名稱、術語表、哪些欄位只是技術細節，由人判斷。程式碼只是初稿來源，不一次性生成。
- 範圍可為單一業務域或整個 server 模組。
D4：/api-spec 反向模式擴充
- 批次範圍：可指定業務域或整個 server 模組，不必逐一指定 Controller。
- 連結 Domain Model：
depends_on引用對應實體。 - 授權欠帳清冊：未完成明確分類的端點不阻擋
.md與.bru產生；清冊列於該資源文件、連結自 Bruno（D1.3），並以 follow-up 追蹤。依m-api-authorization.md，授權矩陣不完整的 API Spec 仍不得作為/e2e-script產生 server 測試的依據；授權完整但仍為source: implementation者，依 D1.1 同樣不得作為設計輸入。 - Bruno 測試帳號：說明改由專案 seed 推導，不寫死參考實作的帳號。
D5：偏離偵測
實作錨定的文件以程式碼為準。重新執行反向萃取時，依 D1.2 記錄的 blob SHA 比對各來源檔至今的差異，列出新增、刪除或改變的端點、欄位、關聯，供人決定更新文件；source: design 的內容只回報偏離，不自動改寫。
D6：與後續方法論的銜接（本 ADR 只定原則）
- RPT：依 ADR-017，adapter 依賴 Domain Model；
source: implementation的實體可被 RPT 引用。 - 補建 US／SBE：可引用實作錨定的文件，如實記錄既有行為屬追溯補建，不因此讓既有實作回退階段；只有實際改變需求才走
m-change-management.md。補建的完整流程（含起始階段）另立決策。
考量的方案
| 方案 | 結論 | 理由 |
|---|---|---|
| A. 維持現況，要求先補 US／SBE | 不採用 | 已上線的應用無法先取得 API 文件與測試，補文件成本過高而擱置 |
| B. 實作錨定反向文件化，標示來源（本提案） | 採用 | server 文件化與測試可先落地；來源標示避免現況被誤當契約 |
| C. 反向產生後直接視為設計契約 | 不採用 | 實作錯誤會被 E2E 保護；違反文檔先行的語意 |
| D. 另建獨立的「現況文件」目錄 | 不採用 | 與正式 Domain Model／API Spec 分家，RPT 與後續 US 需引用兩套文件，轉為契約時還要搬移 |
分階段實施
| 階段 | 內容 | 審閱 |
|---|---|---|
| P0 | 統一 Domain Model 路徑（specs/ 與 design/），含既有下游的遷移說明 | 方法論 peer review |
| P1 | 來源標示、source／version 分立與下游守門、可重現錨點、Bruno 語意（D1）；/api-spec 反向批次、Domain Model 連結、授權欠帳清冊、Bruno 帳號（D4） | 同上 |
| P2 | /domain-model 路徑 E（D2、D3） | 同上 |
| P3 | 偏離偵測（D5） | 同上 |
每階段通過後才進行下一階段；全部通過後本 ADR 改為 Accepted。
待決點
Domain Model 統一到哪個路徑：P0 決定統一到design/，見「P0 實作裁決」。
第 1 輪審閱後，原待決點「實作錨定文件的
version」由 D1.1 決定（/assess可定案，published不改變source）；「能否滿足 server 階段必要輸入」由 D1.1 下游守門決定（暫行不滿足）；「錨點粒度」由 D1.2 決定（commit SHA 加逐檔 blob SHA）。
P0 實作裁決
2026-10-01 經三輪 peer review 通過（第 1 輪 3 major、1 minor；第 2 輪 1 major；皆修改落實，無不採納項目）。
- 位置：統一到
design/domain-model.md（多檔design/domain-model/）。理由為depends_on慣例、/api-spec、/us與參考實作的實際檔案皆已在design/；參考實作先前已遷移，只是方法論未跟上。 - 共用解析程序：位置規則只在
/domain-model「位置、解析與舊路徑遷移」定義一次。讀取方與引用產生方一律依此解析：完整盤點新單檔、新多檔、舊單檔、舊多檔四個候選；兩個以上並存即停止；單檔讀相關區段，多檔讀overview.md與相關epic-{N}.md。 - 引用只指向實際存在的檔案：依實體實際定義所在的檔案產生引用；只有舊路徑時引用舊檔，由遷移統一改寫。初稿曾規定一律寫新路徑，會產生不存在的依賴並使
/impact失去追蹤（第 2 輪 R2-01 更正）。 - 多檔遷移的引用映射：多檔搬到
design/domain-model/後，既有指向單檔design/domain-model.md#X的引用仍不存在，須依實體映射至overview.md或epic-{N}.md；無法映射者列為未完成，未完成清單為空且驗證通過才算遷移完成（第 1 輪 R1-03 更正初稿「遷移後即可解析」的錯誤宣稱）。 - 過渡策略：
/domain-model遇舊路徑先建議遷移，拒絕則不寫入；其他讀取方照常讀取並提示遷移，不阻擋。 - 不做：不在框架端直接遷移下游；不保留雙路徑長期相容；不改 Domain Model 與 Data Models 的抽象層級區分。
- 待追蹤：
/next／/analyze是否主動偵測舊路徑（FU-114）；下游 florae-g1、ict 的遷移（FU-115）。
P1 實作裁決
2026-10-01 經三輪 peer review 通過（第 1 輪 4 major、1 minor；第 2 輪 2 major、1 minor；皆修改落實，無不採納項目）。
source的定義位置：放在m-doc-version.md新增的「來源維度」節，與version同屬文件生命週期 metadata；各 skill 引用該節，不另立 rule。- 錨點路徑基準：
source_anchor.files一律相對 Git 根目錄（git -C {serverModule} rev-parse --show-toplevel），狀態檢查、取 blob、還原皆以git -C {repoRoot}執行。初稿未定義基準，在模組目錄以模組相對路徑取 blob 會失敗（第 1 輪 R1-04 實測）。 - 寫入前的來源判定：
/api-spec對每個資源在寫入任何.md／.bru前判定處置；跳過或停止的資源兩種產出都不寫。初稿在 Bruno 已寫出後才判定（R1-01）。 - backfill 順序與來源分流：Step 0.3 只對齊 collection 層級；業務 backfill 改為 Step 0.4，必須在逐資源來源判定之後執行（R2-01）。從
implementation文件補產的 Bruno 必須帶來源、錨點、未確認與欠帳標示（R1-02）。 - 領域解析：依 feature catalog 的
businessLayout與實際 Controller 位置判定；feature/{featurePkg}/依盤點工具既有規則（套件為 ID 去連字號）反查 catalog feature ID（R1-03、R2-02）。 - 授權欠帳分流：反向文件中只有 catch-all 的端點與缺少的控制列入欠帳清冊，不阻擋現況文件與 Bruno；
design文件與下游實作、測試產生的檢查維持原要求（R1-05、R2-03）。 - 下游守門：
/impl、/e2e-script、/uat-script、/code-review、/api-spec正向模式遇source: implementation停止；/assess的published不改變source。 - 遷移補強：P0 在 ict 實測發現的五點（FU-118）併入
/domain-model遷移步驟。 - 不做：路徑 E 屬 P2、偏離偵測屬 P3；不修改
m-api-authorization.md。 - 待追蹤：既有、未標示來源但實為反向萃取的 API Spec 如何處置（FU-119，已於下節裁決）。
P1 補充：早期反向文件的缺錨點補標（FU-119）
2026-10-01 經兩輪 peer review 通過（第 1 輪 2 major，皆修改落實）。
- 問題：來源維度建立前由反向萃取產生、未標
source的 API Spec，依「未標示視為design」會被下游當成契約。盤點時 nbsos 18 份中 15 份、ict 29 份中 24 份、tms 13 份中 2 份內文提到反向萃取；舊版/api-spec從未有固定來源標記，寫法各異，無法機械判定。P1 規定反向萃取遇design文件停止，因此也無法直接重新萃取。 - 裁決（方案 A）：
/api-spec --adopt-legacy一次性補標。經人逐份確認後只改 frontmatter（source: implementation、source_anchor: {status: missing, adopted}），內容不動；授權欠帳標「未盤點」；下游守門與 Bruno 證據限制照常適用，只是無法偏離偵測。 - 所屬 server 逐份確認：補標不定位 Controller，須逐份判定文件所屬 server；多候選（例如多個 server 有相同 URL 與 method）或無法推測時由人指定，只在確認的 server collection 內比對 Bruno（第 1 輪 R1-01）。
- 缺錨點的 Bruno：任何為補標文件產生或補產的 Bruno（含一般 backfill）標示「缺錨點、授權欠帳未盤點」，不得以目前 HEAD 或推測值冒充歷史錨點（第 1 輪 R1-02）。
- 補完錨點：日後可依一般反向萃取重新產生；重新產生前先列出無法從程式碼還原的人工內容，由人決定保留方式。
- 不採用：補標後立即重新萃取（會覆蓋人工補充內容）；只提醒不處理（守門仍擋不到）；以字樣比對自動補標。
P2 實作裁決
2026-10-02 經兩輪 peer review 通過（第 1 輪 3 major、1 minor，皆修改落實，無不採納項目）。同輪併入 FU-121 的 Bruno 端點比對規則。
- 明示觸發：路徑 E 只由
/domain-model --from-server [<serverModule>] [--domain <D>...]進入，不自動推測；不可與epic-<N>併用。 - 涵蓋範圍（D2）：沿用模組的 feature 盤點工具（
--business-targets搭配空的--preserve-domains，即業務殘餘加全部referenceDomains），不另寫推導；工具版本過舊缺少參數時停止回報。skeleton、structuralDomains與 feature core 只列於「平台實體」節。沒有 feature catalog 時改依m-reference-code.md路徑 B 慣例。帶@reference-surface的域預設不納入，建議先 prune 或 retarget；路徑 E 不移除標記，不執行 Step 5.5。 - Level 2 對話（D3）：程式碼只是初稿；澄清順序為統一語言 → 屬性（排除技術欄位）→ 生命週期。狀態機只採明確的轉換邏輯，找不到時只列狀態值。
- 錨點：沿用 D1.2 與
/api-spec的 Git 路徑基準，只從已提交內容萃取，逐檔確認 commit、逐實體記錄{repoRelPath}@{blobSHA}。 - 與既有模型併存：新實體標為
implementation；既有implementation實體確認後才重新產生；design實體不改寫，只列差異（比對 blob 屬 P3）。 - 多檔命名
domain-{D}.md：沒有 Epic 的功能模組獨立成檔。讀取方一併接上：/domain-model路徑 C 全域讀寫、路徑 D 依 Glob 與 USdepends_on定位實體所在檔案並就地更新、不在epic-{N}.md重複定義（第 1 輪 R1-01）；/assess全域評估、/impl載入表、/us引用範例、m-depends-on.md；/impact只經depends_on追蹤，不列入 Epic 隱含規則；手動 Docusaurus sidebar 一併登錄（R1-04）。 - Bruno 端點比對（FU-121）：
/api-spec新增共用比對節，供 backfill、推測所屬 server、補標三處引用。端點路徑相對於所在小節的 basePath；支援`METHOD /path`寫法；文件的{name}與:name視為同一種變數（R1-02，既有文件採:id寫法），可對應 Bruno 的變數或字面值；Bruno 的字面 ID 視為變數，文件字面段不對應 Bruno 變數；多個候選並列時列為待確認。 - 不能標
folder.bru的資料夾：資料夾內有未文件化的 request 時不標 folder；每支已對應的 request 自帶來源、錨點（缺錨點時寫補標日期）、設計文檔連結與授權欠帳四行，不構成契約、E2E、UAT 證據的限制不變，未對應的 request 不加標示（R1-03）。 - 不做：偏離偵測屬 P3；
/next、/analyze不讀功能模組檔，本輪不改，另以 follow-up 評估。 - 待追蹤：nbsos 試點（FU-117）。
P2 補充：nbsos 試點回饋
2026-10-02 在 nbsos 試點（FU-117）：以路徑 E 建立 specimen 域 Domain Model（11 個實體），並反向萃取初檢資料、陽性轉介兩份 API Spec，連到該模型。試點得 10 項發現，修訂經兩輪 peer review 通過（第 1 輪 1 major、1 minor；第 2 輪 1 minor 只修簡報文字；無不採納項目）。
- 範圍推導（Step E1）：各層只差大小寫的同名套件視為同一域，域名採 controller 套件寫法，與
/api-spec的{domain}一致；只含列舉、值物件的共用套件不是業務域，預設隨使用處歸入。 - 檔案策略：路徑 E 無既有模型時，依未限縮的完整範圍決定單檔或多檔，不依本次
--domain範圍判斷。全文統一多檔門檻為「實體 > 15 或功能模組 > 3」，功能模組指 Epic，路徑 E 無 Epic 者指業務域。原策略表寫「且」，與遷移規則不一致（第 1 輪 R1-02）。 - 萃取規則（Step E3）：業務規則追到 service 實際呼叫點，寫明套用的路徑與時機；只有註解、列舉方法或常數依據者列待確認。註解有寫但沒有實作的行為列 TODO，不建模。沒有狀態欄位、狀態由欄位推導時，由人選擇畫狀態機或只寫規則。試點中曾因只讀列舉註解，把補助方式的套用時機寫反，萃取 API 時才發現並更正。
- 重新產生時保留人工內容：重新產生
implementation內容前，不論錨點完整或缺錨點，先列出程式碼推不出的人工內容，由人逐項決定保留、改寫或移除；只更新萃取的結構與錨點，不因缺少 US 以 TODO 取代已確認內容。共通原則寫入m-doc-version.md，/domain-model與/api-spec（{preservedContent}）各自引用。原本只規定缺錨點補標文件，第 1 輪 R1-01 擴及完整錨點文件。 - 連結既有反向文件：補標文件不改內容，Domain Model 建立後仍不會連過去。路徑 E 的報告列出「待連結的 API Spec」，建議重新萃取。
- Bruno backfill 範圍：反向萃取以單一 Controller 或
--domain為輸入時，只補同域的缺口，其餘列為「範圍外缺口」；正向模式與--module維持全量。P1 只規定 backfill 在逐資源來源判定之後，未規定範圍，第 1 輪裁決接受此收窄。 - 範本：
/api-spec、/us的depends_on註解補上domain-{D}.md（P2 漏改）。 - 不做：重跑時自動找出變更屬 P3 偏離偵測，本次的人工內容保留規則是其前提。遷移改寫使 UAT 證據失效（FU-123）屬 ADR-016。
- 待追蹤：RPT 對接試點（FU-117）。
P2 補充：RPT 對接試點
2026-10-03 延續 FU-117，以同一份實作錨定 Domain Model 對接兩份獨立 RPT。業務欄位與計數由使用者提供的需求書、訪談及逐項確認決定；實體、旗標與參考代碼的映射依既有 implementation 錨點核對。本輪未改變 D6 政策，也未把 Domain Model 或反向 API Spec 轉為 design。
- D6 可直接使用：RPT 可引用 implementation 實體建立 adapter，無須先補齊 US／SBE。產品端點、授權、稽核與 job 仍由引用 RPT 的 US 承接；獨立報表驗證不推進 US 或 Sprint 階段。
- 安裝版本是能力前提：下游原 pin 的 framework JAR 未含公開報表 API，需升級至已發布的
4.0.0-alpha.22；server 與兩個 host pin 一致，應用明示加入 PDFBox 3.0.8。獨立 renderer 組合不需要 provision report job feature。 - 取數與資料粒度：adapter 在 SQL 套用 UUID 範圍、收件日半開區間、編號起迄、初檢 N/C 類別與上限加一；容量按原始血片筆數判定，不能按機構彙總列數。登記表用純值投影，避免 materialize 複檢的 EAGER 原初檢關聯；不 JOIN 疾病明細。H2 同時含範圍內外資料，驗證日期邊界、缺號四類實際計數、10,000／10,001、代碼解析與缺值。
- 業務語意不能由欄名推定：原樣張「哺乳」與實作
isNotBreastfed方向相反，經人確認改印「未哺乳（NPO）」；民國樣張改依需求西元年；初檢雙行補訪談欄位。這些決策落在 RPT，未改寫來源實體或反向文件。 - 驗證與接受分開：報表、adapter 與架構共 31 項測試通過，八份合成 PDF 共 11 頁及脫敏 JUnit、來源／字型指紋保存於下游帳本。自動 verified 不代表真人版面、正式資料、產品授權或實紙驗收；當前八份 PDF 的真人接受尚待回覆。來源或產物變更後須重新核對，不能沿用參考實作四份 PDF 的接受。
本輪沒有發現需要修改 ADR-018／ADR-017 核心政策的缺口；既有 implementation 錨點已足以支持獨立 RPT adapter 對接。產品整合與正式資料環境驗收在試點外，FU-117 先保留至本輪版面接受與證據收尾。
P2 補充：RPT 試點完成紀錄（2026-10-04）
以上 2026-10-03 紀錄保留當時的決策與待接受狀態；後續以原樣張建立 HTML＋CSS，經使用者確認後才實作正式採用版 PDF。最終 nbsos RPT-001 revision 5、RPT-002 revision 3 改採民國年及原主表欄位，不加補充資料；「未哺乳（NPO）」仍依已確認的旗標方向顯示。這些後續採用決策取代前一輪的西元年與補欄方案，不改寫 implementation 實體或反向 API Spec。
- 完成證據：兩份 HTML 版面包已接受；下游升級已發布的
4.0.0-alpha.24後，20261004T111423Z九份合成 PDF 共 11 頁，由使用者明示「確認」，兩個docs/testing/reports/RPT-{001,002}/evidence.json均為layout-accepted、html-accepted、無 stale。新接受綁定該批精確 PDF，不追認 2026-10-03 原批次八份 PDF。 - 自動驗證：報表 47 項全數通過，server 完整測試 463 通過／1 既有 skip，兩個 host 各 1 項通過；獨立重跑九份 PDF bytes 相同，與 alpha.23 的 11 頁渲染一致。
- 審閱與提交：
20261004-nbsos-report-pilot與框架20261004-report-reproducibility均經第 2 輪 peer review 通過並 close；下游成果已以0a196aca提交並推送 main。FU-117 完成歸檔，FU-127 只剩框架訂單 RPT-001 的 HTML／新版 PDF 證據。 - 政策與邊界：D6 與 ADR-018 核心政策不變。產品端點、授權、稽核、非同步 job、正式 DB 與實紙驗收不在試點範圍；受控版面包的一般登錄限制仍由既有 FU-126 承接。
相關文檔
變更歷史
| 日期 | 內容 |
|---|---|
| 2026-10-04 | 補充 nbsos HTML／PDF 接受、alpha.24 可重現性驗證與已提交現況；保留 10-03 歷史，FU-117 完成，未改核心政策 |
| 2026-10-03 | 補充 RPT 對接試點實證與驗證邊界；未改核心政策，真人版面接受待回覆 |
| 2026-10-01 | 初稿（Proposed），送 peer review |
| 2026-10-01 | 第 1 輪修訂：新增 D1.1（source／version 分立與下游守門，更正 /assess 已支援兩種文件）、D1.2（只從已提交內容萃取、逐檔 blob SHA 錨點）、D1.3（Bruno 帶來源與未確認狀態，執行結果不構成驗收證據）；待決點 2～4 改由上述決定 |
| 2026-10-01 | 設計方向第 2 輪審閱通過；新增「審閱結論」節，狀態維持 Proposed |
| 2026-10-01 | P0 成果三輪審閱通過；新增「P0 實作裁決」，狀態維持 Proposed |
| 2026-10-01 | P1 成果三輪審閱通過；新增「P1 實作裁決」，狀態維持 Proposed |
| 2026-10-01 | FU-119 兩輪審閱通過；新增「P1 補充：早期反向文件的缺錨點補標」 |
| 2026-10-02 | P2 成果（含 FU-121）兩輪審閱通過；新增「P2 實作裁決」，狀態維持 Proposed |
| 2026-10-02 | nbsos 試點回饋修訂兩輪審閱通過；新增「P2 補充：nbsos 試點回饋」 |