文件解析遷移：其他類型與原生 consumers
狀態：P2-5 設計已通過第 2 輪審閱（2026-10-19，受審 revision
r2-ab16fccf66eeb394）；實作已通過第 2 輪審閱（2026-10-20，受審 revisionr2-6e4865a564799b15，審閱者 ada@leandev.io）；未下行。實作與審閱結論見 §11。 依據：ADR-023、文件解析與索引規格 §1、設計類遷移、驗證類遷移；追蹤 FU-142。
1. 範圍與設計選擇
本期涵蓋 /br、/transcribe、/rfc、/rfc-intake、/progress、/sprint、/follow-up、/presentation-design、/design-language，以及使用其文件的 readers。只遷移位置取得與人類閱讀入口，保留各工具的文件內容、確認、進度及驗證語意。依本設計另行實作及送審。
| 面向 | 本稿方案 |
|---|---|
| 一般文件 | BR、Sprint、進度總覽、follow-up、應用端 RFC 與提交稿使用 resolve；逐字稿按用途分成可解析的 Markdown 類型 |
| 原生 consumers | BR parser／prepare-apply 與 progress 原生更新器一起改接，不只替換 SKILL.md 的目錄文字 |
/tmp 人類交付 | RFC 脫敏提交稿預設改為 docs 模組內的受控快照；AI prompt、程序輸出與工具中間檔維持暫存 |
| 簡報 | 新套件預設落在 docs 模組的 static；以 manifest 定位原生套件，保留舊位置、版次與接受指紋 |
| 設計語言 | Storybook 仍是權威與人類閱讀入口，registry 只分類原生來源及衍生物，不複製一份 docs 權威 |
| 框架 RFC | /rfc-intake 仍依框架站的 multi-instance 規範定位；不假裝目前只支援 classic docs 的 resolver 已能接管框架站 |
不處理 UAT／report retention、ADR-020 儲存選擇、P3 寫入 hook 或 FU-144 查詢效能優化。P2 全部通過後才統一 publish。
2. 候選 registry
候選從 78 類增至 88 類，增加 12 種可查詢範本；只在審閱證據保留候選 JSON，不修改 canonical 或下游投影。下列形狀是預設，實際路徑以 resolver 輸出為準。
2.1 BR、進度與 RFC
| 類型 | 預設路徑（相對 docs 模組） | key／參數 |
|---|---|---|
br | docs/requirements/business-requirements/BR-{br}.md | br，原生正整數至少三位，不接受別種補零別名 |
br-coverage（新增） | docs/requirements/business-requirements/BR-{br}.br-coverage.json | br |
sprint | docs/specs/progress/sprints/sprint-{sprint}.md | sprint，保留既有 raw 數字字串 |
progress-index | docs/specs/progress/README.md | singleton |
follow-ups | docs/specs/progress/follow-ups.md | singleton |
rfc | docs/rfcs/{rfcId}.md | rfcId，完整 YYYY-MM-DD-kebab-slug |
rfc-submission | docs/rfcs/submissions/{rfcId}.md | rfcId |
br 由整個目錄縮為單層 *.md，locate 嚴格解析 BR-{br}.md，保留舊 specs/business-requirements locate；README 仍屬 section-index。專用目錄內其他 Markdown（例如壞命名）仍會成為無法解析的候選並停止，不因縮小 paths 被當成沒有 BR。查得 legacy BR 只代表能定位，原生「先遷移舊 BR」閘門仍成立，不因此當成可直接接受的現行 BR。
另增無範本的 br-us-sources，匹配 docs 樹內 *.br-sources.json；其路徑永遠由已解析的 US以 with_suffix('.br-sources.json') 推導，再 classify 核對。這是原生同檔 sidecar 契約，不能任意 relocation 為另一個檔。
BR 兩種 JSON 是由明示確認更新的持久資料快照（role=data、change=versioned、retention=with-source、git tracked），不是不可變的逐事件檔案。registry 不代替其原生 schema、來源摘要或操作者檢查，也不新增清理規則。
2.2 逐字稿與會議來源
| 新增類型 | 預設根目錄 |
|---|---|
interview-transcript | docs/requirements/interviews/ |
requirements-meeting-transcript | docs/requirements/meetings/ |
design-meeting-transcript | docs/design/meetings/ |
general-meeting-transcript | docs/meetings/ |
四者範本均為根目錄下 {collection}/{name}.md，key 為 collection＋name；參數接受中文、空白與原始 Unicode，仍受 safe_value 的單一安全路徑元件限制。不以檔名推論來源內容已是逐字稿、需求已確認或已獲存取授權。同名來源在不同 collection 可並存；不同用途由不同類型隔離。
新 Markdown 類型 priority 5，section-index priority 10 保留目錄頁；既有 requirements-transcript／meeting-transcript 保留為來源區域的廣泛分類，承接非 Markdown 原件與舊資料，不加範本。候選沒有宣稱任意深度目錄皆可解析；新 writer 使用單一 collection，既有不合形狀的檔案列出 RS-UNPARSED，以專案層類型／locate 或經確認的搬移處理，不自動改名。
舊 docs/specs/transcripts 沒有用途資訊，不推定為需求訪談。新寫入前另盤點舊資料是否有本次 collection／檔名的候選；有候選即呈現原路徑，讓人選擇沿用該對象或依用途遷移，不默默建立第二份。沿用時保留明示路徑並 classify；遷移先核對 BR sources locator、入向連結與原始材料身分，不修改 identity／revision 來恢復新鮮度。
2.3 原生套件與模組來源
| 新增類型 | 定位與責任 |
|---|---|
presentation-manifest | static/presentations/{kind}/{packageId}/{revision}/manifest.yaml；key 為三參數，kind=templates／decks，revision=v1 起的原生版次 |
presentation-package | static/presentations 下的套件檔案；asset-index，git tracked、downstream exclude，原生契約管理成員 |
design-language-source | 已登錄模組的 src/design-system/identity-discovery/**、src/design-system/design-language/**；workspace 分類、權威仍屬原生契約 |
design-language-generated | 已登錄模組的 generated 目錄及兩份 .claude/rules 衍生檔；derived／generator，聲明原生來源，不允許人工覆寫 |
manifest 的 legacy locate 為 workspace presentations/{kind}/{packageId}/{revision}/manifest.yaml。套件根取 manifest 的 parent；不為 assets、PPTX、PDF、每個版型另寫一套組路徑或目錄範本。將 workspace presentations 與上述精確模組目錄加入 scan roots，不擴張為掃全部 src。
presentation-manifest 與 presentation-package 均明訂 distribution: site，不依賴省略欄位的預設值。這是本次審閱已接受的發布範圍：新預設根下的完整套件供團隊隨站台取用，包括未 accepted 的草稿版次；接受狀態不作發布篩選。標準建置的實際內容與體積影響見 §6.1；本輪不部署或改寫部署環境。
自訂 --output 或專案已採用路徑須保留原操作對象；在 workspace 內以專案層登錄 manifest 的真實 locate，不能忽略指定位置另建套件。workspace 外的來源／匯出沿明示檔案處理，不宣稱它已受 registry／git／網站託管；若要成為專案正式套件，先提出明確的納管方案。新建自訂根須先有可產生該路徑的專案層類型；沒有時列出納管選項並停止，不忽略 --output 改寫到預設位置。新預設不觸發既有套件的自動搬移。
3. BR 原生接線
3.1 發現、識別與取號
br_model.py、br_trace.py 共同使用現有 P2-4 doc_locations.py 橋接（同批方法論載入，不新增 registry parser 或 canonical fallback）。--docs 的公開輸入仍是 docs 內容根；向上定位 workspace，再核對 inventory 與投影。每個 CLI 操作共用位置 context，寫前失效，失敗不取舊成功。
library用br --list取得現行／legacy 候選；對每份以實際路徑、classify 的 br 參數、kind、frontmatter id 核對。專用位置判定由 registry 類型取代字面目錄前綴，語意 parser 不變。find_br保留穩定 BR ID；新 BR、既有 BR 與 coverage 分別以 resolve 取得實際路徑。畸形候選、重號、legacy 未遷移、缺投影仍拒絕。next-id保留「現存＋Git 歷史最大值＋1」及不可回收語意，具體演算法與缺口處置見下文；不能只把當前--list當成全部歷史。us_snapshot、direct_us改以已解析 US／完整清單與 classify 判定角色，coverage 的 specifications／recorded_us 也不能再靠startswith('specs/user-stories/')。BR 依賴與 fragment 判定也以實際類型取代目錄前綴，BR 不接受 fragment 的限制不變。其他已遷移設計／測試來源用其實際類型；原本可採用的未遷移來源保持原範圍，不因 resolver 變更縮掉覆蓋。
原生 next-id 與確認狀態仍是權威；skill 不能自行按檔案數取號、手工 hash，或以 resolve 成功宣稱 current／confirmed／full。
歷史取號規則：在 Git repo 根執行 git log --all --full-history -m --root --format= --name-only -z --no-renames，不傳任何目錄 pathspec。按 NUL 分割原始路徑 bytes，取 basename，以 ASCII 完整比對 BR-([0-9]+)\.md 並取數值；現存 resolver 候選的原生合法 ID 也加入集合。--full-history -m --root 保留完整遍歷、merge 各 parent 差異及根提交，涵蓋只在 merge commit 新增的號碼；--no-renames 讓搬移以刪除／新增兩端列出；刪除檔與仍可由任何本機 ref 到達的歷史均參與。原路徑與歷史內容不改寫、不以今日 locate 過濾。歷史同名檔一律保守保留編號，即使缺 kind／id、內容損壞或不在 BR 目錄，也不回收；這可能跳號，但不讓內容驗證造成號碼再利用。現存 BR 的 kind／id 與歧義檢查仍須通過，歷史保留號碼不代表該檔是有效 BR。結果為聯集最大值加一，至少補足三位；歷史檔的其他補零寫法保留相同數值，不產生別名。
gitHistory: true 僅表示本機現有 refs 的可達歷史成功枚舉且 repo 非 shallow，不保證未 fetch 的遠端、已刪 ref 或不可達物件曾用的編號。先檢查 repo、--is-shallow-repository 與 refs；有效且無 refs 的新 repo 視為歷史空集。Git 不可用／非 repo、shallow、命令非零、缺物件或路徑／數字解析失敗，均為無法可靠確認上界，回 gitHistory: false 與原因、已知最大值，不能把已知候選宣稱為安全新號。此時 draft 不自動配號或寫檔；沿原明示確認流程，呈現缺口，由人核對其他編號來源並確認保留上界（不得小於已知最大值），再由原生工具計算下一號並留下確認脈絡。若人已知有未納入 refs 的編號，也走此流程；revise 保留既有 ID，不因歷史查詢失敗重新取號。
3.2 prepare／apply 與相容性
prepare 的 target、來源 inventory、coverage／ack sidecar 全部使用已解析路徑；plan 雜湊加入有效 common／project registry、inventory、bridge 與 resolver 程式指紋。apply 寫前重新發現並核對相同 plan；registry、來源集合或路由變更即拒絕，不把新路徑套進舊批准。原同目錄 temporary file＋atomic replace 保留。
同一路徑、同一內容的既有 BR／US／sidecar，semantic-v1 projection、generator、schema 與 current／stale 等判定應不變。本期不升級它們來製造新批准，不批次重寫快照。真正搬移或變更引用依原生流程重新核對；metadata／語意來源的區別仍按 BR 契約。
無 BR 的 consumer 先用標準函式庫的 docs resolver 盤點；確實存在／引用 BR 時才載入原 BR 隔離 Python 環境。不能為純位置查詢強迫無 BR 專案安裝 YAML／Markdown 相依，也不能因 BR helper 缺少相依而降級成手工驗證。
4. Sprint／進度與 consumers
progress/scripts/update.py、progress/execution-contract.json 與 canonical SKILL.md 同步更新：
- 由 workspace inventory 定位 docs 模組，解析 progress-index、完整 sprint 清單、US 與可選 feature-list，不以固定目錄是否存在判斷就緒。
- Sprint raw key 與整數身分分開；按原規則比較整數編號，同整數多份拒絕，不因
1／01或 relocate 後改名而選錯。新建用原 Sprint 編號規則；既有檔保留其 raw key 與路徑。 find_sprint_entry、最新 Sprint 選取與 README 更新使用分類參數及實際連結，不從 relocated basename 猜 Sprint 身分。US 的 track 從實際 US 讀取；缺檔處置維持原流程，不自行補 US。- 單步前進、UI／headless、reference 拒絕、舊表格 canonical fallback、work/ 分支寫入禁止、UAT 全 surface 閘門與部分寫入回復均不變。位置錯誤必須停止，不能經 canonical fallback 改用舊固定路徑繞過。
- plan 的 inventoryHash 納入 registry／inventory／位置工具及實際查詢清單；apply 重算後才寫。不能只雜湊已找到的檔案，遺漏新增 Sprint、重新分類或位置設定變更。
/sprint 以清單執行原 reference 優先與新編號決策；Epic／US／SBE／Feature List 一律讀實際文件，寫 Sprint 與 progress-index 的連結也由兩檔實際路徑計算。唯讀前置不建立空目錄。
/follow-up 對 singleton 定位，編號仍取 active＋archive 最大值＋1，優先旗標、完成移入 archive、詳述與 next 的提醒語意不變。查詢不建檔；首次新增才建立成果並 register。
連帶盤點 /next、/work（含 progression reference）、/us、/br progress 等 Sprint／follow-up readers，統一使用此清單與實際路徑；不得讓更新器已支援 relocate，但只讀總覽仍掃舊目錄。
4.1 /work 共享進度保護集
實作時須同批修改 .claude/rules/m-work.md「工作分支與進度隔離」、.claude/skills/work/SKILL.md 的 submit／merge 與 references/progression.md 的共用驗證；固定目錄清單改為以下契約，不能只將 /work 當 reader。設計審閱當時只修訂本稿；後續實作已同批接線這三份執行契約，見 §11。
| 操作 | 用於解析保護集的受審快照 |
|---|---|
| submit | 本輪 source 基線：送出前凍結完整來源快照的 registry／inventory／檔案集合，包含 staged、工作樹與新增檔；產生 sourceSHA 後重算核對，內容改變須重驗 |
| merge | 本輪最新 target 基線 baseSHA 的 registry／inventory／檔案集合；不採用來源分支修改後的設定取代目標基線 |
保護集為該快照中 sprint、progress-index、feature-list 三類解析出的全部實際路徑，包含 common／專案層 locate、legacy、所有 Sprint，不能只保護最新 Sprint 或 request 指向的檔案。registry／inventory／工具來自明確快照，在隔離位置唯讀解析，不拿 live 工作樹去替代基線；保存快照 SHA／指紋與路徑清單供核對。缺投影、解析失敗、歧義或越界即停止送審／合併，不退回固定路徑。
完整交付差異仍按既有 merge-base 規則排除合法繼承；把新增、修改、刪除、改名的舊／新兩端與保護集比對，並用基線類型的 paths／locate 規則檢查新增路徑，避免只列現存文件而漏掉新增 Sprint。另聯集差異起點快照的同三類路徑及規則，避免來源同時移除 locate／改 registry 將待保護變更隱藏；位置設定本身也須審閱。不得以來源分支新設定縮小 target 保護集。任何成員修改命中即拒絕，commit／push／merge 前皆須完成對應守衛。target 或 source 變動時重算，不沿用舊清單。
follow-ups 維持刻意不在共享進度保護集；搬移後同樣允許依原授權記錄欠帳，仍要處理並行新增 ID 重號。整合端只有 receipt 能證明的本次逐階進度更新可按既有契約排除；這不豁免成員修改，也不改變 UAT／正式進度的寫入時機。
5. 逐字稿、RFC 與暫存
5.1 transcribe
用途與 collection／檔名的既有互動不變；根目錄選擇改為 §2.2 的類型。完整與 partial 稿都先 resolve，實際寫入成功才建立目錄、依用途處理導覽並 register。中文、空白、同名不同 collection、既有稿更新與原覆寫決策需走查。分段音檔、CSV、續作與 Gemini 操作仍沿原原件／暫存契約，不將錄音或敏感原件自動複製到公開 static。
5.2 rfc
draft／revise／checklist／list／submit 共享 rfc resolve／list；外部明示檔案保留該檔，classify 不改寫操作對象。RFC 狀態機、七維度、脫敏及明示交付選擇不變。
submit 的脫敏提交稿預設改以 rfc-submission resolve 寫入受控、git-tracked 的提交快照。--keep-submission 保留相容，明示使用時得到同一目的地，不再以它區分 /tmp；同 id 既有快照呈現差異，沿原已授權 submit 流程更新，git 保存歷史。原稿與提交稿仍不同檔、不互相當替身。更新 Decision Log／status 與提交稿失敗時如實報告，不宣稱已交付框架或自動寄送。
清單只列 rfc，不混入 submissions；新頁 register，網站公開範圍與脫敏要求仍生效。受限材料不能因預設目的地而變成可公開內容。
5.3 框架 rfc-intake 的明確例外
目前 resolver 的 docs 模組來自 project inventory，docs-site bundle 只支援 classic docs/。框架 appfuse-docs 是 docs-web／docs-server 等 multi-instance，沒有假造的 application docs 投影。
本期保留 /rfc-intake 按框架 native 的 docs instance／scope 目錄與 metadata 定位、更新該 instance 的 llms 索引；讀入使用者指定提交稿時保留來源。補上「框架站不呼叫 application resolve/register」的明確分流及入口核對，不能為了統一字樣去更動 project.json、公開範圍或將框架 RFC 複製進 app-docs。若要統一框架 resolver，另提 multi-instance 工具設計。
5.4 /tmp 命中的處置
| 命中 | 處置 |
|---|---|
| RFC submission | 人要讀、要交付的 Markdown，依 §5.2 移到受控提交稿 |
| RFC／intake／assess 的 AI prompts 與子程序 output | AI 中間資料，保留暫存；人審結論按原流程落正式稿／assessment／peer-review |
| deploy HTTP probe、upgrade 套件／CHANGELOG 擷取、scaffold smoke log | 工具中間資料，保留暫存，不以此建立人類文件 |
| BR prepare／payload JSON、local Design Language plan | 原生交易輸入，不是人的批准 SoT，維持現有暫存與明示確認流程 |
保留暫存不是允許把正式交付藏在 output；真正請人確認的成果仍使用各 owner 的網站／附件入口。不將每份內部 prompt 存進團隊文件，不新增無限保存政策。
6. 簡報、設計語言與個人便條紙
6.1 presentation-design
新預設 outputRoot 為 docs 模組的 static/presentations；以 manifest resolve 找到套件位置，再沿原生契約保存 guidelines／brief、可編輯檔、PDF、必要 assets 及 manifest。接受的 revision 不原位修改、來源與 artifacts 指紋、逐頁渲染及可編輯性驗證不變；套件可定位不代表 accepted。
網站以原生套件的 PDF／附件入口供人閱讀，不將 PPTX 轉成 MDX，也不在 docs 正文複製第二份 guidelines／brief 權威。素材探索使用既有已遷移的 US／System Context 等實際路徑；品牌只消費有效 adopted Design Language。
發布範圍與體積：兩個類型選 site，因完整套件是團隊可下載、續編與比對版本的持久交付物。標準 build／build:docs-only 將 static/presentations 下各版次的 manifest、guidelines／brief、PPTX、PDF 與 assets 原樣複製到輸出，包含探索中／尚未接受的版次；presentation: hidden 只影響呈現，不排除 manifest 發布。下載檔案不因 asset-index 自動成為全文搜尋文件。體積按所有保留版次的實際檔案 bytes 累加；同素材跨版重複、PPTX 內嵌圖與外部 assets 都會佔空間，建置複製成本、輸出／部署容量及傳輸量會隨之增加，不宣稱去重、壓縮或 accepted-only 篩選。
目前九 workspace 的 manifest 樣本為 0，尚無實際新套件可供估算，不能以本輪文件建置大小推論未來簡報負擔。實作驗證須用含草稿／接受兩版與非空 assets 的 fixture，列出每版及總輸入／輸出 bytes，證明全套進入標準建置且原 bytes 不變；實際套件建立時回報版次與總量，部署仍由人類依交付範圍另行決定。本期不設配額、壓縮或自動清理，也不為限制體積刪除歷史接受版次。workspace legacy 或自訂外部根不因 distribution: site 自動複製進 static，網站可達性仍須逐一揭露。
舊 workspace 套件依 legacy 定位並揭露網站尚不可達；經確認需要納管時整包處理相對引用與指紋，不靜默搬移或沿用已改變的接受紀錄。自訂路徑按 §2.3；不自動修改 ignore／LFS，不藉此選定 ADR-020 的原樣張儲存方案。
6.2 design-language
保留 Storybook canonical Stories／Documents／metadata、runtime refs、identity discovery 與全部 generated artifacts 的原位置及工具驗證。registry 的分類與 scan 讓它們可被識別，不讓 resolve/register、docs-site apply 或 framework publish 取得編輯權。人類使用該模組已核對的 Storybook 頁面，入口由原生 compiler／狀態提供；衍生 Markdown 不變成新 SoT。
6.3 handoff
維持審閱裁決的 personal／workspace／hidden／local-only .claude/handoff.md，不將個人便條紙轉為團隊 docs 或持久批准紀錄。/next 仍先處理 handoff，再依 follow-up 與就緒度建議工作；不因「所有人類文件」的概括字樣改寫此生命週期。本稿將其列為明確邊界，沒有偷偷遷移或刪除便條紙。
7. 已遷移設計類的 readers
先逐節盤點 /assess、/analyze、/impl、/next、/impact、/us，再核對其他引用者：
- Persona 的前置／候選改為 persona list；顯示名稱依 P2-3 不直接作參數。
- Domain Model 依
/domain-model的四候選與缺概覽契約；刪除「Domain Model 沿用現行規則」之類會繞回固定路徑的指令。 - API Spec／System Context 等以已遷移類型取得實際路徑；直接指定檔案與 fragment 保留原操作對象。
- BR 及新 Sprint 文件依本稿接線；文件內容、評估分類、業務規則、階段判定與人工批准流程不變。
- 保留具體結構圖／worked examples、原生輸出與歷史說明中合理的路徑；逐筆判讀搜尋命中，不以全域字串替換或零命中作完成標準。
8. 盤點證據與實作驗證
設計審閱時的候選經正式 registry loader／lint 與 resolver engine 唯讀驗證，並在隔離 fixture 投影後執行實際 CLI；當時證據只證明分類／範本可行。後續原生接線與回歸見 §11，不將設計檢查冒充原生或真人驗收。
| 設計預檢 | 結果 |
|---|---|
| 候選 registry | 88 類，lint 0 issue；12 種範本新建＋既有，共 24 個 CLI 路由檢查 |
| 邊界 | 非正規 BR 參數、越界 collection 拒絕；legacy presentation、同名不同 collection、4 種原生資料／來源分類核對 |
| 九 workspace | 108 次候選類型列舉，無無法解析／重複 key；所有目標投影 SHA 不變。既有樣本：15 Sprint、6 progress-index、8 follow-ups、4 RFC、170 訪談區 Markdown |
| 真實覆蓋限制 | 訪談區含整理後需求稿與逐字稿；檔名可解析不代表內容已確認。BR／coverage／簡報 manifest 在目前 fleet 無既有樣本，依隔離 fixture 驗證，須另補原生實作回歸 |
實作必須另外完成：
- BR 全套既有測試及 relocated BR／US／coverage、舊目錄停止、缺投影、同編號歧義、prepare 後 registry／inventory 變更、零寫入拒絕；原 bytes／projection／快照狀態相容。歷史取號另驗刪除／改名／其他 ref／merge-only 新增、已移除 locate 的目錄、非 BR 內容同名檔與補零、unborn repo、shallow／Git 失敗、已知最大值及人工確認上界，不可靠時零寫入。
- progress 原生 plan/apply：relocated Sprint／README／US／Feature List、同整數 raw key、work 分支、UAT／✅ 閘門、位置變更 stale plan、部分寫入回復；更新 execution-contract 與 Codex adapters。
- sprint／follow-up／next／work／BR progress 同一組 relocated fixture，新增與唯讀查詢皆不漏文件，維持原判定及優先順序。
/work submit用 source、merge用 target 基線，逐一驗三類 relocated／legacy 文件的新增、修改、刪除、改名均被攔；來源刪 locate／改 registry 不能縮小保護集、target 前進須重算、缺投影或歧義拒絕且不推送；合法繼承及 receipt 更新不誤攔，relocated follow-ups 仍可記錄並檢查重號。同步核對 m-work／work／progression 三份契約及 adapters。 - transcribe 完整／partial、中文空白與同名不同 collection、legacy 候選、深層未知檔、來源 locator／入向連結、錄音／CSV 不被發布。
- RFC 原稿／提交稿隔離、查無零寫入、脫敏與網站；框架 intake native 入口仍可用，不能改寫 application inventory 冒充支援。
- 簡報新預設、legacy／自訂路徑、多版次與同 id 歧義、套件成員／指紋／accepted 保留、PDF／可編輯成果可讀；兩類明訂 site，草稿及接受版的全部成員隨標準建置輸出，逐版／總 bytes 與雜湊核對，legacy 外部根不自動發布；DL 新 scan 分類與原生 drift／authority 邊界，實際網站入口核對。
- 六個指定 readers 與其連帶 consumers 逐節走查；registry R12、fleet、docs-only 建置、標準 preview-only 排除、register --check／llms lint、adapter audit→sync→validate 與差異檢查。
9. 送審選擇與預計實作檔案
第一輪裁決採用：① BR 原生識別改接 registry，同時保留全部語意與批准契約；② 四個用途 Markdown 子類與 legacy 明示選取；③ RFC 提交稿預設持久受控；④ 簡報新套件預設 static、舊套件保留，以明訂發布範圍為條件；⑤ Storybook／框架 multi-instance 的明確邊界。handoff 已裁定維持 personal／workspace／hidden／local-only。第二輪已接受 R1-02 的兩類明訂 site，包含草稿版次與全部套件成員，理由及體積影響見 §6.1，④ 的條件已滿足。本設計作為後續實作依據；本工作樹的後續實作變更見 §11，仍待實作審閱；下游沿各自已核准版本，不提前 publish。
預計修改 registry／doc-locations／相關 rule 索引、§4.1 指定的 m-work／work／progression 三份契約、九個 writer 的 SKILL.md 與必要 references、BR 兩個 native 檔案、progress 原生更新器與 execution-contract、六個指定 readers 及盤點確有影響的 Sprint／BR consumers、回歸 fixture 與 adapters。參考實作投影仍須經 docs-site audit→plan→apply；不手改受管投影。動態附件的 owner、驗證器與人工接受保留。
10. 設計審閱結論與後續
2026-10-19 第 2 輪通過（受審 revision r2-ab16fccf66eeb394；審閱者 ada@leandev.io），1 條 major、2 條 minor 全部處置，無 open／declined：
- R1-01：依 §4.1，以 submit 的 source／merge 的 target 基線 registry 解析三類共享進度保護集，包含 legacy／專案層 locate；新增、刪改名與設定縮小皆納入守衛，follow-ups 維持例外。m-work／work／progression 必須於實作同批修改並驗證。
- R1-02：接受 presentation-manifest／presentation-package 明訂 site，包含草稿及所有保留版次的全部成員。§6.1 揭露建置複製、容量與重複素材累加；原生接受與發布範圍分開，實作須核對每版／總 bytes，部署仍由人類另行決定。
- R1-03：依 §3.1，全 repo 可達歷史不按今日目錄篩選，以 basename 數字保守保留編號，含 merge-only 新增；不可靠歷史停止自動配號，揭露已知上界並由人核對。隔離 Git 設計實驗 7 組、47 條命令通過，不能替代原生回歸。
§9 五項選擇與 handoff personal／workspace／hidden／local-only 邊界均已採用。候選為 88 類、12 種範本，24 個新建／既有 CLI 路由檢查及九 workspace 的 108 次列舉通過，目標投影未改；這些是設計可行性證據，不代表新原生接線、套件建置或人工驗收完成。
下一步依 §8 實作與驗證後另送實作審閱；設計通過時正式 registry 為 78 類；實作狀態見 §11。P2-6 retention／ADR-020、P3 與 FU-144 保持各自待辦；ADR-023 維持 Proposed，P2 全部通過後才統一 publish。本節所記的設計結案只保存通過設計與實作要求；後續實作見 §11，沒有推送或下行。
11. 實作接線與審閱結論（2026-10-20）
- canonical registry 與參考實作投影已增至 88 類、12 種新範本；投影透過 docs-site plan／apply 更新受管基線，不手改或下行。br-us-sources／package／DL 原生來源保持無範本，owner 與批准責任不轉移。
- BR model／trace 共用 P2-4 的位置橋接；library／US／coverage 及依賴角色改用 resolver／classify，parse 仍核對 kind／id，semantic-v1、generator 1.1.0 與確認 schema 不變。prepare/apply 綁定 registry／inventory、完整 BR／US／coverage 集合與工具；JSON 重新載入亦核對同一快照。歷史取號依 §3.1 執行，不可靠時 id=null／CLI 非零；人工上界以 --reserved-upper-bound／--by／--basis 明示並回傳確認脈絡。
- progress 原生 updater 與 execution-contract 改以 inventory、完整 Sprint／US 清單及 singleton 路徑 plan/apply。raw key 與整數 Sprint 身分分開；README 用真實相對連結，位置失敗不走 canonical fallback。work/ 禁寫、UAT 全軌閘門與部分寫入回復維持原契約。
- m-work／work／progression 同批加入受審快照保護。唯讀 protected.py 使用正式 loader／resolver；submit 核對 WORKTREE 及 INDEX，merge 核對 target，均聯集 merge-base。新增／刪改名兩端、同數值 Sprint、symlink、缺投影與設定縮小皆驗證；follow-ups 例外不變。工具不 stage、commit、push 或執行來源分支腳本。依 R1-01，merge 從 target 基線的可信 checkout 啟動，匯入 docs／resolve 前核對自身 protected.py 與 docs-site/scripts 全部非 test_ Python 工具檔集合及 bytes 等同 target Git blobs；缺檔、新增或內容不同即拒絕，完成前重驗，不能直接在已併入來源工具修改的 integrate worktree 執行。
- 九個 writers、六個指定 readers 與實際受影響的 roadmap／epic／feature-list、SBE、code-review／e2e-script、scaffold-module 已逐節改接。保留對話、內容品質、原生驗證與人工批准；零 BR 先由標準函式庫查位置再決定是否載入 BR runtime。RFC 人類提交稿預設持久，AI prompts／中間檔仍暫存；框架 intake 的 multi-instance 分流明列。逐字稿完整／partial 分別定位，舊稿／深層未知檔及搬移處置明列。
- 簡報由 manifest parent 定套件；兩類 site、草稿及全版本成員發布與容量影響落回 skill／output-contract。依 R1-02，新 revision 從完整清單篩出同一 (kind, packageId)，revision 去 v 取整數最大值加一，空集合從 v1 起，不受其他套件或 kind 影響。--output／legacy 保留原對象，原生接受與指紋不改；Storybook source／generated 只分類，沒有第二份 docs 權威。
實作釐清
classify／--list 增加 additive metadata legacyLayer，區分 common 舊域與 project.extendCommon locate；不改 legacy boolean 或重寫既有批准。重複宣告 common 舊 pattern 仍歸 common，不能藉擴充繞過 BR 舊域閘門。
Feature List／follow-ups 的精確 singleton priority 提至 20，避免 relocate 到 docs 內容根時被 priority 10 的 section-index 遮蔽而誤認查無；其餘型別與 BR README 分類維持原狀。新增 WORKTREE 已還原但 INDEX 仍含保護修改／獨有 locate 的對抗性 fixture，防止只看工作樹漏檢。
實作驗證
目前完成：BR 66 項、progress 既有 17 項及 relocated 4 項、共享進度守衛第 2 輪全套 17 項、docs 48／resolve 63／update 29／exchange 40／runtime 27／其他類型 9 項，以及隔離標準站台建置。套件 fixture 的兩個 synthetic 版次共 10 檔、294＋291＝585 bytes，輸入／輸出及 HTTP 取回逐檔一致；preview-only 排除且 RFC 提交稿已索引。這只證明發布／傳輸，不代表 opaque PPTX/PDF fixture 的可編輯性、渲染或真人接受。
九 workspace 共 108 次唯讀列舉無解析錯誤／重複 key，目標投影前後 SHA 相同；50 個 SKILL.md＋13 份原生／契約來源保留命中與 SHA 供逐節走查，不以零命中作完成標準。第 1 輪在 uat/scripts 執行 python3 -m unittest discover -p 'test_*.py'，346 項全部 OK、exit 0（1365.579 秒，含 test_doc_locations 16 項）。Codex adapter audit→sync→validate 後為 clean，13 AGENTS／63 skills；正式文件／站台建置已通過。第 2 輪僅修改 work 守衛與簡報套件版次指令；新增測試逐一驗證來源改動 5 個工具時在匯入前拒絕且零寫入、可信 target 工具仍能審來源成果、target 增刪工具檔集合拒絕，work 全套 17 項通過（35.026 秒）。BR／progress／UAT／docs-site 受測來源未變，保留第 1 輪回歸，不宣稱第 2 輪重跑。
實作通過第 2 輪審閱（受審 revision r2-6e4865a564799b15，審閱者 ada@leandev.io），兩項 minor（R1-01、R1-02）均已處置，無 open／declined。下一步為 P2-6 設計與審閱；P2 全部通過後才統一 publish。P2-6／ADR-020、P3、FU-144 仍各自待辦，ADR-023 維持 Proposed；本輪未 commit／push、下行或部署。