Vincent5588 Wiki

Wiki Daily Log — 2026-05-03

閱讀時間約 15 分鐘

📅 2026-05-03 Wiki 異動日誌

摘要

操作影響頁面備註
Lint-Health 60/100（baseline）
Ingestadventure-tour/artifact: Weui-wxss / ColorUI補真缺概念 stub（draft）
Tool patchwiki/tools/lint.py加 inline-code skip → 消除 docstring FP
Updatewiki/maps/Wiki 儀表板.md, productivity/pattern/Claude Code 操作 Obsidian Vault.md包 backtick：2 條 raw FP
Updateclaude/system/Claude Code.md擴 god node：+ TOC / 4 模式 / Plugin 生態 / Session 速查
Ingestproductivity/system: Obsidian CLI新增 entity 記錄 obsidian CLI v1.12.7 + Claude Code 整合場景
Updatewiki/index.md, wiki/maps/PKM 索引.md, wiki/maps/戶外探險旅遊 索引.mdMOC 同步新 entity
Dry-runwiki/reports/notion-sync-staging/cli-dryrun-2026-05-03.json用 obsidian eval 拿全 vault link map（144 KB / 3245 resolved / 32 unresolved / 48 aliased）
Ingestwiki/concept: Notion Sync Hybrid 架構新 entity（draft）：v1.3.8 spec + 架構討論合一檔，引 dry-run 真實數字當佐證
Specwiki/_skill-staging/wiki-notion-sync-v1.3.8/TASKS.md從 spec 拆 15 個 task / 4 phases / ~6.5 hr。關鍵發現：v1.3.7 SKILL 沒 .py，v1.3.8 是 markdown + reference + 打包工作
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/references/OBSIDIAN_CLI_HELPER.mdT1 完成：3 個 eval snippet 寫好，Snippet 2 實測 160/191 stable
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/references/CLI_FALLBACK.mdT2 完成：4-state 決策樹 + 4 edge cases。Phase A 收工
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/SKILL.mdT3 完成：v1.3.7 baseline 進 staging，加 step 0 pre-check（77 行新增）
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/SKILL.mdT4 完成：step 2 改寫 hybrid + fallback 雙路徑（86 行新增；總 439 行）
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/SKILL.mdT5 完成：step 6 擴 6a/6b（102 行新增；總 541 行）。設計修訂：staging 邏輯放 step 6 比 step 5 更合理
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/SKILL.mdT6 完成：step 7 改寫 hybrid 套 staging + fallback 雙路（95 行；總 636 行）
Implementwiki/_skill-staging/wiki-notion-sync-v1.3.8/SKILL.mdT7 完成：step 11 cleanup（30 行；總 666 行）。🎉 Phase B 收工
Releasewiki/dist/karpathy-wiki-pattern-v1.3.9.pluginT8-T10 完成：plugin v1.3.9 release（104 KB / 50 files）。版本撞號改 1.3.9
UpdateCLAUDE.md, 2 entitiesT11+T12 完成：CLAUDE.md §0 加 v1.3.9；wiki-notion-sync 加版本歷程；Hybrid 架構 升 stable
ValidateT13 + T14productivity dry-run（37 entity / 283 link） + alias diff honest report（本 vault 0 alias 觸發）
NotionSyncT15 部分5/147 push 成功（Heptabase sample + 4 productivity entities）。剩 142 deferred to Cowork。Phase D 收尾

詳細

Lint baseline（早上）

跑 python3 wiki/tools/lint.py wiki，結果：

  • Health: 60/100
  • 1 orphan（Wiki 儀表板，預期）
  • 6 missing concepts（4 疑 false positive、2 真缺）
  • 6 god nodes（warn）
  • 0 collision ✅
  • 0 inferred-heavy ✅

Action 1 — 補真缺 stub

真缺補在
[[Weui-wxss]]wiki/entities/adventure-tour/artifact/Weui-wxss.md（draft）
[[ColorUI]]wiki/entities/adventure-tour/artifact/ColorUI.md（draft）

兩頁均含 vs Vant Weapp 對照、相關概念、外部 GitHub 連結。

Action 2 — 修 false positives

2a：patch wiki/tools/lint.py

extract_links() 前加 2 行 regex：

text = re.sub(r'```.*?```', '', text, flags=re.DOTALL)
text = re.sub(r'`[^`\n]+`', '', text)

→ 消除 docstring 例子（`[[entity]]` `[[wiki-link]]` 等）被當缺失概念。

2b：包 backtick

檔行動作
wiki/maps/Wiki 儀表板.md120[[X]] → `[[X]]`
wiki/entities/productivity/pattern/Claude Code 操作 Obsidian Vault.md108[[wikilink]] → `[[wikilink]]`

Action 3 — 擴 Claude Code god node

新增 4 個區塊（未刪改既有內容，47 條 backlink 全保留）：

  1. § 一頁地圖 — 給讀者快速 overview，10 條速查表
  2. § 4 種使用模式對照 — 互動 / Plan / Hooks 攔截 / Headless 對照表
  3. § Plugin / Skill 生態 — 跟 Cowork 共用 plugin 格式、.plugin 安裝、Marketplace
  4. § Session 管理速查 — /clear /compact --continue --resume 對照

預估 ratio 從 24.5 → 35+（脫離 god-node 警告）。

Bonus — 新 entity Obsidian CLI

觸發：使用者指出 obsidian CLI v1.12.7 已串好，要記錄「Claude Code 能做哪些事情」。

路徑：wiki/entities/productivity/system/Obsidian CLI.md（draft）

內容覆蓋：

  • 為什麼比裸 Read/Edit 強（wikilink resolver / frontmatter / daily / IPC live update）
  • 命令分類速查（讀取 / 搜尋 / 寫入 / frontmatter / daily / tasks / plugin / dev / eval）
  • 對 Claude Code 的賦能場景對照表
  • 限制 / 反模式 / 已知坑

建立的 backlink：

Bonus 2 — Notion Sync Hybrid 架構 spec（draft entity）

觸發：使用者問「用 CLI 做 NotionSync 跟之前差在哪」。

Step A：Dry-run via obsidian eval（144 KB JSON）：

指標值對 NotionSync 的意義
Resolved links3245全 vault 連結圖規模
Aliased entities48regex parser 抓不到的邊角
Distinct aliases93每個都是 v1.3.4 自寫 parser 可能踩雷
Unresolved links32比 lint 報的更全（Obsidian 看 PARA 路徑也算）

實例 alias 邊角：[[BASB]] → 打造第二大腦、[[Karpathy]] → Andrej Karpathy、[[/loop]] [[/schedule]] → loop 與 schedule 自動化、[[@bcherny]] → Boris Cherny。

Step B：Hybrid 架構 entity

路徑：wiki/entities/wiki/concept/Notion Sync Hybrid 架構.md（draft，spec + concept 合一檔）

核心對切：Read 側 Obsidian CLI / Write 側 Notion MCP。涵蓋：

  • 4 個痛點（Pass 2 卡 112、alias 邊角、NFC、stale push）
  • 架構 mermaid 圖
  • v1.3.8 spec API 變動表 + migration path（Phase 1 fallback / Phase 2 收技術債 / Phase 3 移除 fallback）
  • 反模式 / 限制（CLI IPC overhead、必須開 Obsidian、Notion 端 sync conflict）
  • 3 個待解 open question（eval timeout、id_map 持久化、Notion 端手改覆寫）

為什麼不直接 implement：v1.3.4 雖有債但 Notion 端可讀；先把 Obsidian CLI reflexes 練熟；下次推 Notion 時再開 v1.3.8。

MOC 同步

MOC變動
wiki/index.md戶外探險 entity 計數 20 → 22；首頁日期 → 2026-05-03；今日 daily 連結 → 2026-05-03
wiki/maps/戶外探險旅遊 索引.mdLib 選型段加 [[Weui-wxss]] / [[ColorUI]] 兩條
wiki/maps/PKM 索引.mdAI 整合工作流加 [[Obsidian CLI]]

Orphan Fix — Wiki 儀表板

發現：早上 lint 報 1 孤兒頁 Wiki 儀表板（type: map，存在 wiki/maps/）。

根本原因分析：

  • wiki/index.md 有提及儀表板，但 lint.py 只掃 wiki/entities/ + wiki/maps/，不掃 wiki/ 根目錄
  • 所以 wiki/log.md 或 wiki/index.md 的 backlink 對 lint 無效
  • 需要在被掃描的檔（maps/ 內）加 backlink

修復（二階段）：

  1. v1 (失敗)：在 wiki/log.md 頂部加「相關資源」section — lint 看不到
  2. v2 (成功)：在 wiki/maps/Wiki 索引.md 的「從哪開始」加第 5 項 [[wiki/maps/Wiki 儀表板]]

結果：lint 重跑 → orphans: 1 → 0 ✅

洞察：

  • lint 掃描範圍 = 計算 inlinks 的範圍
  • backlink 必須在被掃範圍內
  • ✅ 已寫進 CLAUDE.md §14「Lint 掃描範圍 = inlinks 計算範圍」小節（v1.3.5 新增）
    • 實戰陷阱：wiki/log.md / wiki/index.md backlink 對 lint 無效
    • 正確流程：修復孤兒頁須在 entities/ 或 maps/ 內加 backlink
    • 例外說明：map 頁面孤兒需同目錄檔指向

影響檔總清單

#檔動作
1wiki/entities/adventure-tour/artifact/Weui-wxss.md新建
2wiki/entities/adventure-tour/artifact/ColorUI.md新建
3wiki/entities/productivity/system/Obsidian CLI.md新建（bonus）
4wiki/tools/lint.pypatch
5wiki/maps/Wiki 儀表板.md1 行
6wiki/entities/productivity/pattern/Claude Code 操作 Obsidian Vault.md2 行（FP fix + Obsidian CLI 強連結）
7wiki/entities/claude/system/Claude Code.md擴 ~600 字 + 加 Obsidian CLI 強連結
8wiki/log.md+ 6 行
9wiki/index.md3 處更新
10wiki/maps/戶外探險旅遊 索引.md+ 2 條
11wiki/maps/PKM 索引.md+ 1 條

待做

  • 重跑 lint 確認 score 上升
  • Obsidian CLI 跟 Obsidian Dataview / karpathy-wiki-pattern 兩個推斷連結待人工確認升強
  • 5 個剩餘 god node（CLAUDE.md（專案手冊）/ Sub-agent / wiki-lint / wiki-query / 等第天花板）下次再擴
  • NotionSync Phase D 收尾：71 個 entity deferred（66 pending [69-134] + 5 retry [43-46, 52]）— staging 完整保留在 outputs/phaseD_staging/

NotionSync v1.3.9 Phase B+D — Cowork session（晚段）

接 T15 後繼續推剩 142 個 entity（filter 非 stable 後 140，扣 Phase B 5 = Phase D 135 個）。

結果：本 session 推 69 個 entity 上 Notion（Phase B 5 + Phase D 64）。剩 71 個 deferred 不繼續。

分階段：

階段動作結果
Phase A沙盒內計算 update_plan.json（沒動 Notion）140 entries / 934 link replacements / 17 unresolved bolds
Phase Breplace_content 推 5 個 sample（CLAUDE.md（專案手冊）/ 需求單生命週期 / 打造第二大腦 / wiki-ingest / 角色 HR Reviewer Approver）✅ 5/5；使用者驗證 OK
Phase D 主執行update_content batch 1-4（43 個）✅ 29 + ❌ 14（condensed page 沒 bold placeholder）
Phase D agent 1切 subagent 接手+6 success（49/135 累計）
Phase D agent 2第二個 subagent，全 replace_content+15 success（64/135 累計）
收工71 個 deferred使用者裁決下次再處理

核心洞察（給未來 Compounding 用）：

  1. Notion update_content mode 對 condensed page 失敗率 ~80%——validation_error 整個 call 拒絕，不會部分成功。replace_content 才可靠（83-100%）但 token cost 高。
  2. Cowork single-session 不適合 push >50 entity——主 thread + 2 個 subagent 共處理 69 個就用掉大半 context。下次應該 fork 多個 agent 或分批 session 跑。
  3. Page ID 漂移：agent 2 發現 phaseD_payloads.json 有 4 個 page_id 不對（indices 65-68），需 inline 從 notion-search 重新對 title 才修好。id_map.json 是 4-27 留下的，可能跟 v1.3.4 emoji-prefix title 修正後 page_id 沒一致更新。

規律建議（待寫進 v1.3.10 SKILL.md）：

  • step 5 加 condensed-page 偵測：先 fetch 一頁，若 content 長度 < 500 chars 視為 condensed，整個 batch 直接走 replace_content 不試 update_content
  • step 6b 在送出前用 notion-search 重新 verify 每個 title→page_id 對應（避免 stale id_map）
  • bulk push >50 entity 預設用 subagent fork pattern，main thread 只做協調

遺留 staging（給下次 session 用）：

  • outputs/phaseD_staging/phaseD_payloads.json（135 entries 完整 plan）
  • outputs/phaseD_staging/phaseD_fullcontent/*.md（135 個 fallback full content）
  • outputs/phaseD_staging/STATUS.json（前 43 個處理狀態）
  • outputs/AGENT_REPORT.md + outputs/AGENT_REPORT_FINAL.md（兩個 subagent 自己的紀錄）

下次直接從 phaseD_payloads.json[68:135] + retry list [43, 44, 45, 46, 52] 繼續，建議全 replace_content。

部署 §雷 10 修復——gsync 砍 .github/ day-one bug

發現契機：跑完 gsync 後 GitHub Actions 沒任何新 workflow run 觸發。

根本原因：~/scripts/vincent5588-gateway-sync.sh 用 rsync -a --delete，excludes 列了 .git/ 但沒列 .github/。vault 從來沒有 .github/（那是 CI/Quartz 配置，不該放 Obsidian 裡），所以每次 gsync --delete flag 都會砍掉本機 git repo 的 .github/ 整棵樹（含 workflows/deploy.yml + quartz-config/{quartz.config.ts, draftWarningBanner.ts, custom.scss}）。

為什麼 day-one bug 撐到現在才發現：

  1. v1.0 setup 是手動建 deploy.yml 在 ~/vincent5588-git/——那時還沒跑過 gsync，第一次 build 是過的
  2. 第一次 gsync 跑了之後 .github/ 就被砍——但當下沒馬上檢查 Actions tab
  3. 後續 gsync push 都成功，push 成功 ≠ Actions 觸發，但沒人在 log 加 Actions check
  4. 「沒看到網站更新」很容易被歸因為「我今天沒改 vault 內容」——quiet failure 永遠靜默

修復（outputs/restore_github.sh 一鍵）：

  1. 從部署紀錄 §附錄 B/C/D/E 抽出 4 檔還原到 ~/vincent5588-git/.github/
  2. 修 gsync 加 --exclude='.github/'（在 --exclude='.git/' 上方），原檔備份成 .bak
  3. commit + push → workflow #22 觸發 build

vault 紀錄補完：

  • Vincent5588_Wiki_部署紀錄.md §0 加 v1.2 row、§雷 10 全文（為何 day-one 沒抓到 + 短期 / 長期防呆）、§附錄 A 修正 + # NOTE 指 §雷 10
  • 經驗法則 3「文件即真理失效」加偵測信號：「應該觸發某 side effect 但沒觸發」也是 drift（quiet failure = silent drift）
  • 規則 F 可擴成「任何破壞性 flag (—delete / —force / rm -rf) 必須對應一份 exclusion list 並逐字 review」

Compounding 收穫：

信號是 / 不是 drift
「我改了東西但網站沒更新」⚠️ 也許不是「我沒推」，而是 Actions 沒跑
「pipeline log 全綠但結果不對」⚠️ pipeline 可能根本沒跑進關鍵 step
「文件寫得對、行為不對」⚠️ doc-vs-behavior drift（雷 9 變體）

Lint + Repair（10:57）

跑 wiki-lint：192 pages / 0 orphan / 0 missing / 0 collision / 5 god nodes（CLAUDE.md（專案手冊）/ Sub-agent / wiki-lint / wiki-query / 等第天花板，跟待做清單第 3 條同份）+ 7 low-inlink。整體健康。

跑 wiki-repair --plan-only：14 auto-fixable + 20 needs-review。

批准 apply 3 —— 只修第 3️⃣ 組「Heptabase export 路徑漂移」5 個 entity：

Entitysource 改動
productivity/pattern/索引卡片40-Resources/.../索引卡片（Indexing Card） → 40-Resources/.../Heptabase-Export-2026-04-27.../索引卡片（Indexing Card）
productivity/pattern/卡片大法同 pattern 加中間 export dir
productivity/pattern/文獻筆記同
productivity/pattern/靈感筆記同
productivity/pattern/關鍵字索引同

各檔 2 處替換（frontmatter source: + 內文 ### 來源出處）。

跳過：

  • 9 個 wiki-link 風格 broken sources（source: 寫成 [[basename]] 風格，repair 提議改成 wiki/entities/... 路徑——但 source 該指原始素材不是 wiki 自己，語意誤判候選，等人工釐清）
  • 15 個 ambiguous（empty cand 或多 cand）
  • 5 個 god nodes（review-only）

Report: REPAIR_20260503_1057

額外發現：規範同步缺口

執行 repair 時順便 verify vault 規範同步狀態，發現雷 10 洞察沒回灌 CLAUDE.md：

#應該補在內容
1CLAUDE.md §10 經驗法則 3加「quiet failure = silent drift」偵測信號
2CLAUDE.md §10 規則 F擴充「破壞性 flag (—delete / —force / rm -rf) 必須對應 exclusion list」
3CLAUDE.md §0加 v1.3.10 row 紀錄上 2 條

→ 待下次批准再寫（規則 E：show before write）。

Rules Sync — CLAUDE.md v1.3.10 + Welcome / README 同步（11:00 後）

使用者要求 verify CLAUDE.md / Welcome / README 是否都最新狀態。盤點發現 8 處過期：

CLAUDE.md 5 處：

  1. §3.3 line 171「wiki-repair 待建尚未存在」← plugin v1.3.1 起已存在（過期 6 天）
  2. §11 Quick Reference「批量修 wiki」row「待 wiki-repair 上線後改用」← 同上
  3. §11「批次升 stable」row「staging at wiki/_skill-staging/wiki-status-promote/」← v1.3.7 已打包進 plugin
  4. §10 經驗法則 3 觸發條件 → 加第 4 條「quiet failure / silent drift」（來源雷 10 — gsync 砍 .github/ 後 Actions 靜默失效）
  5. §10 規則 F → 加「廣義版：破壞性 flag 必對應 exclusion list」段（5 條 flag 對應表 + day-one 防呆 4 條）

Welcome.md 3 處：

  1. CLAUDE.md (v1.3.5) → (v1.3.10)
  2. Plugin 6 個 skill → 7 個（漏 wiki-status-promote）
  3. 規模 157 entities + 3 maps → 180 + 12

README.md 4 處：

  1. CLAUDE.md (v1.3.5) → (v1.3.10)
  2. plugin v1.3.5 → v1.3.9 (release) / v1.3.10 (vault patch)
  3. 版本表只到 v1.3.5，補 v1.3.6 / 7 / 8 / 9 / 10 五行
  4. 規模 + 健康度同步

最後加一筆 §0 row（v1.3.10）封箱。

反思（給未來 Compounding）

這次過期過頭——CLAUDE.md 主文件竟然落後 plugin 9 天（v1.3.5 vs 實際 v1.3.10）。應該每次 plugin / 部署紀錄改動都同步檢查 CLAUDE.md / Welcome / README——不能等到使用者問才回頭補。

→ 規律候選：「stable artifact 改動 ≥ 1 次 / 週時，每次同步 update 必含 CLAUDE.md §0 + Welcome / README 規模描述」。寫進規則 H 的延伸版本。下次再補。

← 回到 log | wiki

關係圖譜

反向連結