T-2808 — 診斷紀錄落點治理：記錄點清冊 + 程式層紀錄集中化

2026-08-11 產出。涵蓋三層落點現況散佈圖、scope 判準與去向對照、skill-issues 搬遷前後、Settings「SKILL IMPROVEMENT」那一列的 before／after（含 disabled／default／hover 三態）。純預覽，不動 renderer/ 與 main/。

用戶原話
「我發現有些 issue report 既然是放在 .pm 這應該也是個問題，.pm 是會隨專案被刪掉的，只有 uniflow 目錄才是管理這個程式的。」
「我的意思是這些 report 位置到底有沒有都集中，還是都很散。」
→ 查證結果：很散，分三層，而且沒有任何一處說得出全貌。下面就是那個全貌。

1 · 現況：紀錄散在三層

中央 app log 目錄

%APPDATA%/uniflow/logs（getAppLogDir()）
28 個項目 · 22 支 main 模組是 writer
tool-errors.jsonlhost-errors.jsonl stall.jsonlerror-reports/ manual-errors.jsonllatest.log schedule.logprocess-guard.jsonl shoulder-tap-trace.jsonlworkspace-lease-cleanup.jsonl skill-sync-*.log ×6triage-reports/

workspace .pm/

<每一個專案>/.pm/ ×45 個註冊 workspace
23 子目錄 + 13 個 loose json
skill-issues/tasks/goals/ review/report/spike/ conversation/data/progress-card/ shoulder-tap-inbox.jsonhandoff/ Opt/campaign/file-claims.json

workspace .pm/log/

<每一個專案>/.pm/log/
24 個項目 · 含 4 個死掉的影子檔
host-errors.jsonllatest.log previous.logschedule.log direct-main-receipts.jsonlfile-claim-events.jsonl leg-failures.jsonlremediation-receipts.jsonl dev-metrics/orchestrator/
program — 講 Uniflow 這支程式，跨專案共用 workspace — 講這個專案 conversation — 綁單一對話 死檔（同名影子，最後寫入 7/8–7/25）

兩個一眼可見的病：藍色（program）出現在 workspace 欄——講程式自己的紀錄卻寄生在專案裡；紅色四個名字在第一欄與第三欄同時存在——同名、一個活一個死，而死的那個沒有任何標記，grep 到就會拿七月的快照當現況。

2 · scope 判準與去向

scope判準：刪掉這個專案之後，這筆紀錄還有沒有意義？本單處置
program有 —— 講的是 Uniflow 這支程式本身集中到 app log 目錄。本單實搬 skill-issues 一項；其餘（error ledger／stall／manual report）本來就在那，只補登記入冊
workspace沒有 —— 講的是這個專案的內容留在 .pm/，只補入冊。tasks／goals／review／report 跟著專案一起消失是正確行為
conversation只在單一對話存活期間有本單只分類、不搬（conversation 目前就住 workspace 底下，搬遷屬另案）
tombstoned曾經有，現在沒人寫了標記，不刪。清冊記 lastWriteObserved，原目錄留指標檔

3 · skill-issues：搬遷前後

Before — 現況

量測值
註冊 workspace 數45
其中有 skill-issues 資料的1（只有 Uniflow 這個）
其餘 44 個打開 Settings兩顆按鈕 disabled（no-data）
同一個 skill 的檔案數2（spec-writer.jsonl 103 行 ＋ 00_UNIFLOW_spec-writer.jsonl 5 行）
SKILL.md 指向的 README26 支指向 .pm/skill-issues/README.md，scaffold 不建此檔
紀錄的對象是跨專案共用的 skill，落點卻跟著 active workspace 走。專案刪掉紀錄就消失，而且沒有任何地方會發現它消失過。前綴寫錯的那 5 行在報表裡被當成另一個 skill，cluster 被拆散、occurrences ≥ 3 的候選門檻因此漏判。

After — 本單提案

量測值
canonical 落點<app log>/skill-issues/ 單一份
可見範圍任何 workspace、甚至沒有 active workspace 都可用
既有 44 個 workspace 的資料開機一次性搬移＋依 iid 去重合併
檔名正規化擋在寫入點：appendIssue() 一律砍 00_UNIFLOW_ 前綴
legacy 目錄原檔 byte-identical 保留，新增 MIGRATED.md 指到新落點
搬遷冪等（receipt 判定，第二次開機不重跑）、永不刪檔、同 iid 內容衝突時兩筆都留並標 conflict，不自行選一份。正規化擋在寫入點而不是靠 26 支 SKILL.md 的文字約束——文字約束正是現在失效的那條線。

4 · Settings → SKILL IMPROVEMENT 那一列（不改 layout，只改行為與 caption）

Before · 在 45 個 workspace 裡有 44 個長這樣（disabled 態）

SKILL IMPROVEMENT
Skill Improvement Report
No skill issues recorded yet for this workspace.

After · default 態（任何 workspace 都可用，caption 直接說出東西存在哪）

SKILL IMPROVEMENT
Skill Improvement Report
每次開啟都會依當下的問題紀錄重新產生報告。
%APPDATA%\uniflow\logs\skill-issues

After · hover 態（按鈕邊框加深，版面不位移）

SKILL IMPROVEMENT
Skill Improvement Report
每次開啟都會依當下的問題紀錄重新產生報告。
%APPDATA%\uniflow\logs\skill-issues

依專案 i18n 分類：按鈕文字 Open Issues Folder／View Skill Report (HTML) 屬 A 類，兩個 bundle 都維持英文；caption 與 tooltip 屬 B 類，en 英文／zh-TW 中文。唯一新增的是那行灰色等寬字的 canonical 路徑——「東西到底存在哪」從此在 UI 上直接看得到，不用問 agent。不新增區塊、不新增按鈕、不改版面結構；Background Work 那一列依 2026-08-11 裁決不加（走 read-only MCP）。

5 · 讓「散不散」日後仍答得出來

機制作用
resources/config/record-points.json清冊 SSOT。每列：id／label／scope／resolver／relPath／writers／readers／retention／state／lastWriteObserved
RecordPointRegistry唯讀查詢與 canonical 路徑解析，不建目錄、不寫檔
雙向 parity test清冊上每一列 live 都有 writer，且 code 裡每個寫持久檔的模組都在冊。少一邊就紅

關鍵在雙向：只驗一邊的清冊會腐爛成一份沒人維護的文件——新增一個 writer 卻忘了登記時，測試必須紅，否則三個月後又回到「沒有任何一處說得出全貌」的原點。