一個可以構建其上的基礎。

每個產品都要重複的活

新產品始於一個具體問題。但它的頭幾週往往沒那麼具體：會話、工作區記錄、訂閱狀態、後臺任務與郵件投遞。這些部件必須先協同起來，產品才能做任何有用的事——每一件在抽象層面都是已解決的問題，在具體層面都是整合風險。

supastack 給這些重複的工作安了家。Next.js Web 應用與 Expo 移動應用共享底層基礎設施的 TypeScript 包。目標是讓這些邊界足夠易懂，使產品能夠配置它們而不必繼承別人的領域模型。

沒有哪一件孤立地看是難的。成本藏在它們的協同裡——必須變成權益的支付、必須變成工作區範圍的會話、必須在合上的筆記本之後存活的任務。產品很少敗在缺一個功能上，它們敗在接縫上。

為什麼值得一次把它建好

主張共享基礎設施，不是說這些活配不上你，而是說這些重複的活值得被認真做一次。在共享模組裡實現好的工作區邊界，能保護建在它之上的每個產品。同樣的邊界若由每個產品臨時拼湊，就會變成一組各有微妙而危險差異的“差不多”。

它還把維護集中起來。供應商 API 會變，認證庫會演進，計費語義會漂移。當這些變化落在一個地方——套件的模組檔案跟著記錄它們——一次修復就能傳播開，而不是每個專案重新學一遍。而當你為單個產品權衡這筆交換時，用腳手架還是從零開始把同樣的推理用在了買與造的決定上。

共享基礎設施也把評審集中了起來。住在同一個地方的邊界可以被狠狠地測一遍——反向用例、重放的事件、跨租戶的嘗試——而不是指望五份重新實現各自都恰好寫對。這也是套件在測試套件上投入的部分原因：在共享程式碼上維持信心，比在每個專案裡重新贏得它便宜。

每個模組只承擔一項職責

身份確定誰在發請求。工作區決定這個人能訪問哪些記錄。計費記錄支付狀態，而許可權回答某項能力是否可用。把這些關注點分開，可以防止一次支付成功的跳轉被當成授權決定。

同樣的紀律適用於後臺任務。共享的 JobRunner 契約只承諾 enqueue、status 與 cancel，工作流行為歸 Trigger.dev 所有。一個小介面的價值在於邊界清晰可見；把重試或排程藏進通用方法只會讓系統更難推理。

Better Auth 回答身份。Postgres 與 Drizzle 保管記錄。Stripe 或 Lemon Squeezy 上報支付狀態。沒有哪個被要求對別的模組的職責抖機靈——接縫窄到可以推理——而一個地基的可信度，至多等於它接縫的可信度。

為產品留出空間

獲客工作流、檔案編輯器與研究助手可以使用相同的身份與計費模組，但它們的記錄、語言與工作流仍然不同。產品專屬邏輯屬於使用方的程式碼庫，通過配置接入基礎。

這種分離也是務實的維護決策。工作區隔離的修復應當可複用；某個產品評估潛在客戶方式的變更，不應成為其他所有產品的新需求。

這就是地基與皮膚的區別。皮膚給你一套可以保留或換掉的外觀。地基給你承重的決定——誰擁有身份、記錄如何劃界、支付在哪裡變成訪問——產品構建於其上，而不是繞著它走。專案結構指南標出了一者結束、另一者開始的位置。

從一條完整流程開始

先跑本地參考流程：登入、檢視許可權、提交任務、讀取結果。fake 與本地介面卡讓確定性測試無需付費供應商請求即可走通這條路徑——五分鐘快速上手端到端地跑了一遍。之後再配置你的產品真正需要的生產整合。

本地驗收與生產驗收回答的是不同問題。通過的本地測試確立的是受控條件下的應用行為；真實的認證持久化、供應商投遞、部署與裝置行為仍需各自的驗證。隨著產品成長，始終保持這種區分可見。

地基的名字是慢慢掙來的：掙在第二個比第一個更快交付的產品裡，掙在只修一個模組而不是五個程式碼庫的維護日里。這就是 supastack 背後的賭注——也是每個模組被要求的及格線。

這套思路背後的問題

這套思路下面墊著幾個問題，值得坦率地回答。

• supastack 是模板還是框架？ —— 一個由模組組成、模組之間靠契約連線的地基。產品程式碼住在 Starter Core 之外，通過配置接入，所以平臺可以更新而不必 fork 你的功能。
• 共享基礎設施不會讓產品變得千篇一律嗎？ —— 共享的只有管道。記錄、工作流和語言都留在產品程式碼庫裡——客戶真正看得到的那些部分仍然是你的。
• 產品自己的程式碼從哪裡開始？ —— 從只有它才有的記錄與工作流開始。地基負責認證使用者、限定資料範圍；它不知道“潛在客戶”是什麼。
• 為什麼是 monorepo？ —— 這樣 Web、移動端和桌面端應用才能和底下的包一起變化：一個型別系統、一道測試關卡、倉庫之間沒有漂移。
• 如果我只需要 Web 應用呢？ —— 你買的是地基；移動端和桌面端是可以採用也可以無視的端面。沒有什麼強迫你釋出不需要的應用。