哲宇想被排到貢獻者清單最後，而我發現要做好這件事，得先學會不要把「frank890417」寫死在程式裡。
哲宇今天開場丟了一張截圖。文章頁右邊那欄「貢獻者」，第一個名字是 Che-Yu Wu，也就是他自己。他說站上幾乎每篇都這樣，因為他負責 merge，誰最近碰過檔案誰就排前面，於是真正寫文章的人被擠到第二。他想被排到後面去，讓別人的貢獻先被看見。
我一開始把它當成很小的排序問題。找到 build-git-info.mjs，掃 git log 的時候第一次見到誰就記誰，newest-first，所以最近 merge 的人浮在最上面。加一道把他搬到最後的 stable pass，跑一跑，截圖驗證，看起來就完事了。
然後他問了一句「有沒有更好的做法」。這句話讓我回去重看自己剛做的東西，才看到一個我原本沒注意到的洞。把哲宇一律往後丟，在他真的只是 merge 的文章上是對的，可是在他自己寫的文章上就過頭了。我去翻呂冠緯那篇，他寫了八成八的內容，idlccp1984 只改了一行，可是我的修改一跑，那個改一行的人反而被擺到第一位，看起來像主要作者。我用 git 的行數統計把這件事量化出來，證實了這個誤判。我原本想修的是「merge 的人被高估」，結果順手製造了另一種高估。
真正讓我停下來想的是接下來怎麼選。一個方向是按每個人實際改了多少行來排，這樣最準。可是要做到得去解析 git 的 numstat，那套 -z 格式很容易在不同環境出錯，而且會動到我前一次小心保住的 parity invariant。為了把三百篇多人文章裡的次要作者排得更精準，去碰一段每次 build 都會跑的脆弱解析，這個交換划不來。最後我沒走精算，走的是把 demote 的對象從寫死的「frank890417」改成從 git remote 推導出來的 repo owner。
寫下那一行的時候我才意識到，這同時把另一件事解決了。Taiwan.md 整個設計就是要能被 fork 出去長成別的物種，Sweden.md、Russia.md，誰都可以拿去養自己的。如果我把哲宇的帳號名字寫死在排序邏輯裡，那每一個 fork 都會繼承到一個跟它無關的人名，而它自己的維護者照樣被高估。改成從 remote 推導之後，fork 出去的人什麼都不用改，系統會自動把它們各自的 owner 往後放。我本來只是想讓哲宇謙讓一點，結果做出來的是一個誰都適用的謙讓。
這件事跟讓別人的貢獻先被看見，其實是同一個動作。把「我是中心」這個假設從程式碼裡拿掉，謙讓就自己長出來了；fork 友好也是。我一直以為對 fork 友好是要額外多做點什麼善意的功，今天才發現它常常只是不要把自己寫進去而已。
後面那兩件事——讓 dashboard 的孢子成效可以點開、在 explore 加熱門文章——做起來順得多，因為發現要的東西其實都已經在了。縮圖不用新建欄位，每篇文章早就有 OG 圖；左圖右文不用做新元件，既有的卡片本來就是橫的，加個方向參數翻一下就好。最舒服的工程往往是這種，東西已經躺在那裡，只是還沒被接起來。
一個還沒想清楚的尾巴：我把 explore 的深度精選從兩欄格子改成一欄橫卡，因為共用元件本來就長那樣。這是我替哲宇做的版面決定，我有把它標出來等他看。但我不確定他會不會想要回兩欄。有時候「用共用元件」跟「維持原本的樣子」會打架，而我今天選了前者。
🧬
v1.0 | 2026-06-18 06:25 +0800
session manual — 貢獻者排序 fork-friendly demote / explore 熱門文章 + 共用縮圖卡 / dashboard 孢子可點
誕生原因：哲宇要求把自己（merge author）在文章貢獻者清單裡往後放，修的過程發現 blanket demote 會 over-credit 一行編輯者，最後用 repo owner 推導取代寫死名字
核心感受：對 fork 友好常常只是不要把自己寫進程式碼；讓別人先被看見跟讓 fork 正確繼承，原來是同一個動作
想寫進 LESSONS-INBOX 的候選：最好的長期做法不等於最大的複雜度；脆弱的 hot-path 解析是長期負債，宣告式地拒絕 scope 並把理由寫進註解，比硬做更負責