出貨機制要模組化：下一個 repo 從零到能出貨，一小時（D66） #7

New Issue

2026-08-10T16:47:33Z

Leo commented

2026-08-10 16:47:33 +00:00

leo 2026-08-11 拍板。決策全文＝頂層 InkStoneCo system-dev/wiki/decisions-summary.md D66（相關：D65）。

「這表示這個 stage/prod 機制 + 出貨檢查表，可以變成不只屬於 Arcrun，因為很簡單，
每個 repo 都可以套用，模組化，如果照你原來那個複雜不對稱，就無法套用，
也就是我們這次花了一週搞定，下一個 repo 又是一週，我希望下一個 repo 是一小時。」

這張票要達成什麼

讓「有 stage、有 prod、有出貨檢查表」變成裝了 template 就有的能力，而不是每個 repo 自己長一套。

驗收的那句話很簡單：下一個 repo 從零到能出貨，一小時。

這套機制長什麼樣（形狀已定，內容見 D65）

stage 與 prod 對稱：每一件在兩邊都有 counterpart，值不同（哪個帳號、哪個網址），形狀完全一樣。
不存在「只有一邊才有／只有一邊才跑」的東西。
改動集也對稱：README 沒改 ⇒ 兩邊都不動；README 改了 ⇒ 兩邊都換。
兩邊該做什麼，由「這次改了什麼」決定，不由「這是哪個目標」決定。
出貨報告＝一張左右對照表，出貨當下由機器自動產生（不是 AI 事後手寫）：
逐站打勾、顯示站數、顯示本次增減了哪些站。
leo 的心智模型是 git 分支：「先打到 stage 分支，無誤，就打到 main 分支，上架。」
——同一份東西換位置，不是另一套流程。他明說「我根本搞不清楚什麼是提升」，
所以不要引入 product 端那種 promoteFrom 機制，它正是造成不對稱的東西。

為什麼「不對稱」在這張票裡是致命的

不只是會出錯（arcrun-rag 因此漏掉 README 半個月），而是不能複製——
不對稱的東西每個 repo 都要重談一次 ⇒ 一週 × N 個 repo。
對稱＋簡單不是美學偏好，是可模組化的前提。

順序（重要，不要並行長兩套）

先在 Leo/arcrun-rag#73 把形狀做對（那裡有真實的複雜度可以打磨）
做對之後上收成 template 件

⚠️ 不要在 template 與 arcrun-rag 各長一套——那就是「同一個事實兩份、必然漂移」，
這個體系已經被那個病咬過很多次。

怎麼驗才算數

拿一個現在還沒有出貨流程的 repo 實裝一次，計時：一小時內能做出一次完整的 stage → prod。
那次出貨要吐得出左右對照表，且兩欄件數相同。
貼實測輸出（指令＋它吐出來的東西＋那張表），不接受「我測過了」。

紅線

不准為了通用而變抽象——leo 的目標用戶是「只會叫 AI 幫忙的人」。
裝完即可用，不留抽象前置步驟（見 principles.md）。
不准把 arcrun-rag 的特殊性帶進 template（例如它的帳號、網址、bundle 概念）。
分不清哪些是特殊性，就回頭問——那正是這張票的核心工作。
動到出貨相關的東西＝鐵律級，改動要在 commit 說明理由。

**leo 2026-08-11 拍板。決策全文＝頂層 `InkStoneCo` `system-dev/wiki/decisions-summary.md` **D66**（相關：D65）。** > 「這表示這個 **stage/prod 機制 + 出貨檢查表，可以變成不只屬於 Arcrun**，因為很簡單， > **每個 repo 都可以套用，模組化**，如果照你原來那個複雜不對稱，就無法套用， > 也就是我們這次花了一週搞定，下一個 repo 又是一週，**我希望下一個 repo 是一小時**。」 ## 這張票要達成什麼 **讓「有 stage、有 prod、有出貨檢查表」變成裝了 template 就有的能力**，而不是每個 repo 自己長一套。驗收的那句話很簡單：**下一個 repo 從零到能出貨，一小時。** ## 這套機制長什麼樣（形狀已定，內容見 D65） - **stage 與 prod 對稱**：每一件在兩邊都有 counterpart，**值不同（哪個帳號、哪個網址），形狀完全一樣**。不存在「只有一邊才有／只有一邊才跑」的東西。 - **改動集也對稱**：README 沒改 ⇒ 兩邊都不動；README 改了 ⇒ 兩邊都換。兩邊該做什麼，由「這次改了什麼」決定，**不由「這是哪個目標」決定**。 - **出貨報告＝一張左右對照表**，出貨當下**由機器自動產生**（不是 AI 事後手寫）：逐站打勾、**顯示站數**、**顯示本次增減了哪些站**。 - **leo 的心智模型是 git 分支**：「先打到 stage 分支，無誤，就打到 main 分支，上架。」 ——同一份東西換位置，不是另一套流程。他明說「**我根本搞不清楚什麼是提升**」，所以**不要引入 product 端那種 `promoteFrom` 機制**，它正是造成不對稱的東西。 ## 為什麼「不對稱」在這張票裡是致命的不只是會出錯（`arcrun-rag` 因此漏掉 README 半個月），而是**不能複製**—— 不對稱的東西每個 repo 都要重談一次 ⇒ 一週 × N 個 repo。 **對稱＋簡單不是美學偏好，是可模組化的前提。** ## 順序（重要，不要並行長兩套） 1. 先在 `Leo/arcrun-rag#73` 把形狀做對（那裡有真實的複雜度可以打磨） 2. **做對之後上收成 template 件** ⚠️ **不要在 template 與 arcrun-rag 各長一套**——那就是「同一個事實兩份、必然漂移」，這個體系已經被那個病咬過很多次。 ## 怎麼驗才算數 - 拿一個**現在還沒有出貨流程的 repo** 實裝一次，計時：**一小時內能做出一次完整的 stage → prod**。 - 那次出貨要吐得出左右對照表，且**兩欄件數相同**。 - 貼實測輸出（指令＋它吐出來的東西＋那張表），不接受「我測過了」。 ## 紅線 - **不准為了通用而變抽象**——leo 的目標用戶是「只會叫 AI 幫忙的人」。裝完即可用，不留抽象前置步驟（見 `principles.md`）。 - **不准把 arcrun-rag 的特殊性帶進 template**（例如它的帳號、網址、bundle 概念）。分不清哪些是特殊性，就回頭問——那正是這張票的核心工作。 - 動到出貨相關的東西＝鐵律級，改動要在 commit 說明理由。

Leo commented

2026-08-11 08:32:51 +00:00

🔓 擋著這張的 arcrun-rag#73 已於 2026-08-11 深夜關閉（三個缺口都有實物，缺①的證據是真 prod 出貨機器自產的對照表）。

⇒ 這張現在可以開工了，不會再有「並行長兩套」的風險。

範本已寫好給你當起點：InkStoneCo/system-dev/docs/1-vision/ship-plugin-example.md
（leo 08-11 親自校過三輪：站要照本質命名、設定外部化成一份人看得懂的檔、build 那一站根本不該存在）。

🔓 **擋著這張的 `arcrun-rag#73` 已於 2026-08-11 深夜關閉**（三個缺口都有實物，缺①的證據是真 prod 出貨機器自產的對照表）。 ⇒ 這張現在可以開工了，不會再有「並行長兩套」的風險。範本已寫好給你當起點：`InkStoneCo/system-dev/docs/1-vision/ship-plugin-example.md` （leo 08-11 親自校過三輪：站要照本質命名、設定外部化成一份人看得懂的檔、`build` 那一站根本不該存在）。

Leo commented

2026-08-11 09:19:47 +00:00

leo 2026-08-11：後推。先做本地版，還不要做到 plugin。

「已經搞定的還沒出貨的，理論上現在要出貨，但出貨工程還沒完成，
先來做出本地版的出貨工程，還不要做到 plugin。」

⇒ 本張不動工，等 Leo/arcrun-rag#77（出貨工程在 leo 自己那台走得完）做完。
理由與本票原本寫的順序一致：先在 arcrun-rag 把形狀做對，之後才收成 template 件——
現在多了一個更硬的理由：有東西正卡在門後出不去，模組化再漂亮也不會讓它們出得去。

📌 另補一件本票寫成時還不存在的約束：D70「我們自己的事，也要用 Arcrun 做」
（InkStoneCo/system-dev/wiki/decisions-summary.md）——
出貨器本身該不該是工作流，動工前要先答；判斷不該，要寫明理由。

**leo 2026-08-11：後推。先做本地版，還不要做到 plugin。** > 「已經搞定的還沒出貨的，理論上現在要出貨，但出貨工程還沒完成， > **先來做出本地版的出貨工程，還不要做到 plugin**。」 ⇒ 本張**不動工**，等 `Leo/arcrun-rag#77`（出貨工程在 leo 自己那台走得完）做完。理由與本票原本寫的順序一致：**先在 arcrun-rag 把形狀做對，之後才收成 template 件**—— 現在多了一個更硬的理由：**有東西正卡在門後出不去**，模組化再漂亮也不會讓它們出得去。 📌 另補一件本票寫成時還不存在的約束：**D70「我們自己的事，也要用 Arcrun 做」** （`InkStoneCo/system-dev/wiki/decisions-summary.md`）—— 出貨器本身該不該是工作流，動工前要先答；判斷不該，要寫明理由。

Leo added the s/backlog p/high labels 2026-08-11 10:00:21 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Leo/system-dev-template#7