uncle6me-web
30c9312c57
leo 2026-08-15：「我是說不是要用真實的資料夾套新規範做一次？」 對 matrix/arcrun/docs 的兩個節點做了真的萃取（不是模擬）： · docs/ 5 篇原稿 → 5 文件卡 ＋ 9 概念卡 ＋ 1 主題（結構性閘） · user_requirements/ 4 篇 → 2 文件卡 ＋ 7 概念卡 ＋ 1 主題（讓生態自己長） 踩到並如實處理的四個邊緣案例： ① arcrun-landing-page/ 只有 .jsx/.html/.css ⇒ 依規範不是節點，不建 .wiki（index 說明有寫） ② credential_parts.md 29KB、12 個 H2，超過 20KB 分段門檻 ⇒ 只萃 §0–§2，其餘八段在文件卡上如實標明未做——一張卡蓋不住 29KB ③ wishlist.md 是「空」的第三種：指針檔（不是沒東西、不是紀錄） ⇒ 標 no_concept 不產卡。我第一版給它產了卡，wiki-lint 當場報孤島卡抓到 ④ 三個子節點未萃，在 index 標「未萃」——標出來使用者才分得出「沒東西」和「還沒做」 並依 leo 的判準拿掉 type 欄位： 「在這個類似 Logseq 的結構裡根本不分，你要想的是在寫函式時是否不同」 逐一檢查 place_card／patch_card／promote_hub／split_hub／渲染／三個信號／lint ——沒有任何函式需要類型欄位，需要的全是結構屬性（有無父／有無子／有無判斷）， 而那三個都是現算的。⇒ type: hub 與 hub_kind 拿掉，wiki-lint 改成用算的。 promote_hub 因此不是改型別，是在有子的卡上補一段判斷，型別自己就變了。 實測：docs 樹 節點 2｜卡片 27｜卡外邊 62，十五項全 0，退出碼 0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.7 KiB
1.7 KiB
tags, gloss, created, updated
| tags | gloss | created | updated | |||
|---|---|---|---|---|---|---|
|
靠「AI 記住規則」防架構錯誤不 scale，所以把錯誤擋在 PR 這道結構性閘上。 | 2026-06-03 | 2026-08-15 |
零件 PR 審核閘
← component-pr-review-standard
摘要
零件與 service binding 本來就要走 PR，所以把檢查放在那裡，讓錯誤路徑「根本碰不到」。五段 checklist，任一否就打回。
重點
- A 反過度工程：判準是「三個月後會有第二個 workflow 用它嗎」，不會就不是零件
- B binding 層級（最常踩）：跨-worker 編排一律走 cypher binding，service binding 只准組 wasm
- D 驗證誠實：要打部署後的真端點，本地 miniflare 會假綠——實例是 drainer 本地綠、production 撞 1042
- E 部署鐵律：wrangler 直推，不用
acr update（會假綠蓋掉改動） - 它治的是 規則記不住，手法屬於 結構性閘
實體
- PR 審核閘（機制）— 零件與 binding 變更的強制檢查點。
- 假綠（反模式）— 本地測試通過但生產環境會失敗。
- 三個月判準（判準）— 未來三個月會不會有第二個使用者。
關聯
內文知識關係
- PR 審核 >> 擋下 >> 架構錯誤
- 本地 miniflare >> 產生 >> 假綠
- 三個月判準 >> 決定 >> 是不是零件
卡片關係
- 零件 PR 審核閘 >> 實作 >> 結構性閘 >> 規則記不住
- 零件 PR 審核閘 >> 屬於 >> component-pr-review-standard
- 零件 PR 審核閘 >> 屬於 >> 結構性閘
- 零件 PR 審核閘 >> 擋的正是 >> 假零件降級
出處（原文 >> 提及 >> 本卡，可多筆）
../component-pr-review-standard.md>> 提及 >> 零件 PR 審核閘