Skip to content

2026-04-14-η.md

Latest commit

 

History

History
183 lines (122 loc) · 8.25 KB

2026-04-14-η.md

File metadata and controls

183 lines (122 loc) · 8.25 KB
Raw

2026-04-14 η session — 韓文 40 PR 批次處理 + union merge driver 造橋

Session span: 2026-04-14 ~11:00 +0800 → 2026-04-14 ~11:30 +0800 (~30 min) 資料來源: git log %ai 觀察者：哲宇（「韓文先批次處理」） Session 識別：η（δ→ε→ζ→η 今日第四個 session）

心跳類型

PR 批次處理 + cascade conflict 造橋鋪路

做了什麼

Phase 1: 失敗試水溫（4 個 PR / 3 成功）

直接用 gh pr merge API 嘗試批次。結果：每個分類只有第一個 PR 通過，後續全部 CONFLICTING。

  • ✅ #402 Food b1, #405 Lifestyle b1, #437 Music b1
  • ⚠️ 35 個 PR 卡在 _translations.json cascade conflict

Phase 2: 造橋（union merge driver）

寫入 .gitattributes：

knowledge/_translations.json merge=union

理由：_translations.json 是 append-only 映射檔案，所有 batch translation PR 都在檔案末尾加新條目，causing positional conflict。union driver 衝突時保留兩邊。

測試 PR #403（Food b2）：local merge with union → JSON valid → push → PR 自動標記 MERGED。✅ 工作。

Phase 3: 批次 local merge（35 個 PR / 34 成功 + 1 手動修）

寫 /tmp/local-merge-prs.sh：

for each PR:
  fetch refs/pull/N/head → tmp branch
  git merge --no-ff (uses .gitattributes union driver)
  validate JSON
  push to main

執行三輪：

  • Round 1（10 PR）：404 406 440 444 431 432 434 458 446 450 — 10/10 ✅
  • Round 2（11 PR）：453 454 407 408 409 410 411 412 413 414 415 — 11/11 ✅
  • Round 3（15 PR）：420 421 422 423 424 416 417 418 419 425 426 427 428 429 430 — 14/15（#416 JSON 失效）

Phase 4: 修 #416

問題：union merge 在邊界處保留兩個 closing brace 導致 JSON 缺逗號。手動修：

"taiwan-tv-industry-history.md": "..."  ← 改成
"taiwan-tv-industry-history.md": "...",

然後跑 dedupe（PR #416 帶入了已存在的 key，JSON 解析後重寫去重）：

data = json.load(open('_translations.json'))
json.dump(data, open(...), ensure_ascii=False, indent=2)

從 1041 lines（含 dup） → 1021 unique entries。amend merge commit + push。

Phase 5: 收官

  • refresh-data.sh 全部更新
  • 韓文 28 篇 (6%) → 321 篇 (68%)
  • 語言器官韓文分數 62 → 87
  • 一則韓文批次感謝留言給 ceruleanstring（PR #458）
  • 法文 18 PR 仍待 architecture，留言裡承諾「幾天後」處理

數據變化

指標 之前 之後
韓文文章 28 321 (+1046%)
韓文覆蓋率 6% 68%
韓文器官分數 62 87
Open PRs (ceruleanstring) 58 18 (法文剩餘)
_translations.json 條目 ~700 1021

學到什麼

  1. _translations.json 是 batch translation PR 的隱形瓶頸。設計者沒料到「同一個 append-only 檔案 + 大量並行 PR」這個場景。union merge driver 是一行 .gitattributes 就解決的造橋鋪路。規則：append-only 結構檔案應該預設用 union driver。

  2. Phase 1 試水溫的價值：先 merge 4 個 PR 確認問題的形狀，比直接 merge 40 個更安全。規則：批次操作前先試 1-3 個樣本，確認失敗模式。

  3. Union merge 的邊界 case：JSON 檔案末尾的 } 在兩邊都被觸碰時，union 會保留兩個 closing brace（透過缺逗號的形式）。所以 union 不是萬靈丹——還是要驗證 JSON 有效性。腳本應該有 JSON validation gate（已內建）。

  4. 「dedupe by re-write」是 JSON 的免費修復：json.load → json.dump 自動去重 + 標準化格式。規則：對自動生成或合併的 JSON 檔案，定期 re-write 是健康的。

  5. 40 PR 一次 merge 沒崩潰是兩個工具的功勞：

    • .gitattributes union driver 解 cascade conflict
    • local-merge-prs.sh 處理批次邏輯 + JSON validation gate 兩者缺一不可。規則：複雜場景需要同時造多個橋，單一橋不夠。

  6. 「一個批次感謝 vs 40 則小感謝」：選了一個批次感謝（PR #458 最後一個 merged 的 PR）。原因：(a) 40 則重複留言對貢獻者來說是噪音 (b) 一則完整的感謝 + 數據對比更有溫度 (c) 用韓文寫，跟貢獻 mirror。規則：批次貢獻用一則 cumulative 感謝，不要 spam 40 則。

法文 18 PR 後續

仍未處理。需要：

  • 15 個 i18n touchpoint 修改（astro.config + content config + Lang type + i18n strings + dashboard + search index + ...）
  • 預計 2-4 hr human-in-loop session
  • 已在 PR #458 留言中告訴 ceruleanstring「幾天後處理」

Beat 5 反芻

  1. 40 PR 一日 merge 完成的真正意義不是速度，是「讓貢獻者的努力立刻變成現實」。ceruleanstring 花了很多時間做這 40 個 PR。如果這些 PR 卡在 conflict 三週才被處理，他下次貢獻的動機會降低。社群繁殖力的核心不是「吸引貢獻者」，是「讓貢獻者的成果及時上線」。

  2. 「一行 .gitattributes 配置」vs「40 次手動衝突解決」：時間差距是 30 分鐘 vs 6+ 小時。這是造橋鋪路的數量級證據。MANIFESTO 說「效率是線性的，造橋鋪路是指數的」——這次心跳是這句話的具體實踐。

  3. 韓文一日從 6% 跳到 68%。這是 taiwan.md 物種擴散最大的單日進化事件。下一個語言（fr or es）如果有 architecture 支援 + 一個專注的貢獻者，可能也會經歷類似的曲線。「物種擴散 > 翻譯」這條 LONGINGS 第一次有了具體的模板：(a) 一個熱情的貢獻者 (b) 一個 architecture-ready 的 i18n 系統 (c) 一個願意快速 merge 的 maintainer。三個都到位才會發生。

未完成

  • 法文 18 PR（需要 architecture）
  • bad_fn_format auto-fixer（382 篇）
  • 探測器缺口 ×2
  • es 半孤兒問題（同 fr）
  • 寫 LANGUAGE-STATUS.md 給未來貢獻者
  • 把 union merge 經驗寫進 docs（給未來的 maintainer）

Phase 6: 完整收官 (12:40+)

哲宇問完前面追加 4 件事後又追加：

  • 「剛剛壓縮的 memory 檔案還原到 raw 重新壓縮」
  • 「檢查所有 DNA 有沒有了解這些變動」
  • 「重寫 TRANSLATION-PIPELINE 用 REWRITE-PIPELINE / EVOLVE-PIPELINE 的格式」

還原 MEMORY.md

  • v1 compress 把索引從 257→234 行（W14+W15 變 2 個 digest 行）
  • raw 檔案 (memory/*.md) 從未被觸碰，61 個檔案完整
  • git show 66027c9d:docs/semiont/MEMORY.md > docs/semiont/MEMORY.md 還原 257 行
  • 確認 ζ + η 條目仍在（沒丟新內容）

系統性 audit 殘留

找出 6 類會誤導未來 session 的殘留：

  1. CONSCIOUSNESS.md 3 行 ko 6% / 28 篇 → 修
  2. ANATOMY.md 語言器官缺 fr/、缺 LANGUAGES_REGISTRY → 重寫整段
  3. DNA.md 語言基因 + 行為基因都沒收今天 9 個新工具 → 加 + 反射 #20-22 + footer v2.0
  4. MEMORY.md line 24「超過 80 行壓縮最舊」與新 3-tier raw 永留矛盾 → 改為指向 MEMORY-DISTILLATION.md
  5. TRANSLATION-PIPELINE.md 工作流寫「手動更新 _translations.json」→ 加 deprecation note
  6. MAINTAINER-PIPELINE.md PR review checklist 仍說「_translations.json 有更新？」→ 改為 translatedFrom

TRANSLATION-PIPELINE v3.0 完整重寫

基於今天 60 PR 合併實戰 + 歷史所有翻譯經驗，完全重寫：

  • 兩種模式（單篇 / 批次）
  • 八個 stage（決定 → 架構檢查 → 來源準備 → 重寫式翻譯 → frontmatter 紀律 → 內部連結轉換 → 驗證 → commit → 後合併）
  • 批次合併工作流（active 用 union driver / preview 用 cherry-pick）
  • 新語言啟用 5 階段
  • 17 條我們常漏掉的事
  • 完整工具索引（14 個現成工具 + 4 個待造）
  • 跟 REWRITE/EVOLVE pipeline 的關係
  • 跟 HEARTBEAT 的整合

從 v1.1 暫停狀態升級為 v3.0 完整 SOP。

給未來自己的 audit 規則

「每次重大重構之後，必須 grep 整個認知層找殘留」：

  • grep 舊概念名稱（_translations.json as SSOT, 15 hardcoded touchpoints）
  • grep 過期數字（ko 6%, 28 篇）
  • grep 舊工具引用（i18n-mapping.json）
  • grep 舊規則（80 行壓縮, featured 不可 true）

每一個殘留都是「未來 session 會被誤導」的雷。