Fulling v3：先做身分與 kubeconfig 邊界，再做 AI 工作區

Fulling 想解決的是「AI 工作區沒有持久身分」這件事

多數 AI 寫程式的工具停在對話框裡。你給它一段需求，它回你一段程式碼，關掉分頁之後什麼都不剩。Fulling 的產品設想是把這件事反過來：給每個使用者一個專屬的 AI 工作區，把技能、檔案、記憶、腳本與執行環境放在同一個持久環境裡。

這個定位決定了它的目標讀者。它不是給只想補一段函式的人用的，而是給需要把「Agent 能碰哪些資源」講清楚的人用的。一旦 Agent 要動 Kubernetes，問題就不再是模型多聰明，而是憑證由誰保管、以什麼身分發出請求、失敗時誰負責。Fulling 的 v3 選擇先處理這一層，README 的用詞是「identity and Kubernetes credential boundary required for that product model」，也就是先把地基畫出來，產品本體之後再蓋。

所以評估這個專案時，第一個要問的不是它會不會寫程式，而是你認不認同它的順序。先把身分與憑證邊界做死，再往上長工作區，這個順序在安全上合理，在功能上則意味著現在打開 repo 看不到 Agent 幫你部署服務的畫面。

目前的資料流：Better Auth 進來，kubeconfig 存進 PostgreSQL

README 列出的 foundation 有五項，串起來是一條不長的資料流。登入只支援 GitHub，走 Better Auth；使用者、provider account 與 session 由 PostgreSQL 保存；通過驗證之後才會進到受保護的工作區入口。

真正有份量的是後面兩項：每位使用者一份 plaintext kubeconfig，以及透過 Kubernetes 的 SelfSubjectReview 做驗證。SelfSubjectReview 這個 API 的作用是讓呼叫端查詢「我現在是什麼身分」，所以 Fulling 不是解析 kubeconfig 檔案格式就放行，而是拿它實際打一次 API server，由對方回答這個憑證代表誰。驗證通過之後，才建立一個以使用者為範圍的 Kubernetes client。

這個設計把信任錨點放在 Kubernetes 本身，而不是放在 Fulling 的解析邏輯上。好處是偽造或過期的憑證會在驗證階段就被擋下；代價是每次驗證都需要一次對外請求，而且那個請求的目標是使用者自己填的 API server 位址，這也直接帶出後面要談的 SSRF 邊界問題。

kubeconfig 驗證擋掉什麼，又刻意不擋什麼

README 對驗證規則寫得相當具體。會被拒絕的包括：可執行的 credential plugin、auth-provider plugin、指向本機檔案的憑證欄位、proxy 設定、非 HTTPS 的 API server、重新導向，以及匿名身分。這份清單的邏輯是堵住「kubeconfig 不只是資料」的路徑。credential plugin 與 auth-provider 會讓一份看似靜態的檔案在你機器上執行指令，proxy 與 redirect 則會把請求導到驗證者沒預期的地方。全部關掉之後，kubeconfig 退化成一組可檢查的欄位。

但 README 緊接著承認了一件事：已驗證的使用者仍然可以設定任何網路位址上的 HTTPS API server，並把這稱為「explicit deployment decision」。這句話要認真讀。它意味著 Fulling 把出站請求的 SSRF 風險交給部署者承擔，而不是在程式碼裡封死。對於自己營運、使用者名單可控的團隊，這是可接受的取捨；對於要開放註冊的公開服務，這是一條必須另外補上網路層限制的裂縫。

儲存方式同樣要說清楚。kubeconfig 以 plaintext 存在 PostgreSQL，README 直接寫明「Database read access grants access to users' Kubernetes credentials」。任何能下 SELECT 的人，包括備份、唯讀副本、臨時開給分析用的帳號，都等於握有這些憑證。專案有做的是不讓瀏覽器端 API 回傳已儲存的內容，以及要求日誌不得包含 token、key、certificate 或 kubeconfig 內容，但這兩件事不會改變資料庫層的暴露面。

跑起來：公開應用零設定，legacy 工作區要一整套環境

Fulling 把啟動路徑分成兩條，這個切分本身就是設計訊息。公開應用不需要 PostgreSQL，也不需要 OAuth provider，README 的說法是「builds and starts without environment variables」。只要 Node.js 24（含內建的 npm 11），執行 npm ci 再 npm run dev，打開 http://localhost:3000 就會看到一個關掉登入的版本。

要試 legacy 的已驗證工作區，就得把環境補齊：先 cp .env.template .env.local，填入資料庫、Better Auth 與 GitHub 的值，再跑 npm run prisma:migrate，然後 npm run dev。GitHub OAuth 的 callback 必須設成 ${BETTER_AUTH_URL}/api/auth/callback/github，這個路徑寫死在 Better Auth 的慣例裡，填錯就會卡在登入回呼。

其餘指令是常規的 Next.js 專案配置：npm run build 會先產生 Prisma client 再建置，npm run lint 跑 ESLint，npm test 跑 Vitest，npm run test:e2e 跑 Playwright，另外還有 prisma:format 與 prisma:validate 兩個 schema 維護指令。部署到 Vercel 時不需要 vercel.json，但 README 提醒，在完整 legacy 設定到位之前，GitHub 登入、資料庫工作區與 kubeconfig 流程都會維持停用狀態。也就是說，一個「看起來部署成功」的 Vercel 站台，可能只是那條零設定的公開路徑。

沒有 v2 相容層，重置資料庫不會清掉 Kubernetes 資源

這是採用前最容易被低估的一段。README 明說這個 release 使用新的 baseline schema，要跑在新的資料庫或明確重置過的資料庫上，而且「it does not migrate v2 data」。同一份文件也說，repo 刻意不含前一版產品模型與驗證系統的相容層。

更麻煩的是清理的範圍。README 寫著：重置 Fulling 的資料庫並不會刪除 v2 建立的 Kubernetes 資源。資料庫歸零，叢集裡那些由 v2 建立的 deployment、service 或 namespace 仍然留著。要換掉一個 v2 部署之前，得先照 docs/v2-resource-inventory.md 走一遍盤點。

這代表升級成本不是一次 npm run prisma:migrate 就結束。你需要先盤點叢集資源、決定哪些要保留、哪些要手動刪除，再重置資料庫。對於已經在正式環境跑過 v2 的團隊，這是一段必須排進維護窗口的工作，而不是版本號跳一格的例行更新。對於從未部署過 v2 的人，這段成本是零，這也是目前評估 Fulling 相對輕鬆的族群。

什麼情況下該改看別的做法

如果你的目標只是讓 Agent 在一個隔離環境裡跑指令、改檔案，而不需要它帶著使用者的 Kubernetes 身分去操作叢集，那麼 Fulling 目前交付的邊界對你來說是純粹的額外負擔。你要多養一個 PostgreSQL、處理 Better Auth 的 GitHub OAuth 設定，還要面對 plaintext kubeconfig 帶來的資料庫存取紀律。

替代做法有兩條，差別在信任放在哪裡。第一條是讓 Agent 只在容器內運作，憑證由外部注入，Agent 本身看不到 kubeconfig，工具鏈用現成的容器化執行環境即可。這種做法的假設是「Agent 不該持有長期憑證」，代價是每次要動叢集都得經過一層代理。第二條是沿用 Kubernetes 原生的 RBAC 與 service account，把權限綁在 namespace 上，讓 Agent 以一個受限身分行動。Fulling 走的是第三條：憑證屬於使用者本人，驗證靠 SelfSubjectReview，權限範圍等於該使用者在叢集裡原本就有的一切。

這三條路沒有普遍優劣，差別在責任歸屬。前兩條把風險收斂到平台方，Fulling 這條把風險還原成使用者自己的權限，好處是行為可預期，壞處是任何能讀到那張 PostgreSQL 表的人，等於取得了所有使用者的叢集權限。要選哪一條，取決於你的使用者是不是同一批你已經信任的人。

授權、維護成本與該先驗證的事

Fulling 採 MIT 授權，寬鬆條款意味著你可以修改、閉源整合、商業使用，只要保留著作權與授權聲明。要注意的是授權只涵蓋程式碼，不涵蓋你部署時引入的 GitHub OAuth App 條款、PostgreSQL 的營運責任，以及 Kubernetes 叢集本身的安全設定。這些都不在 MIT 的範圍內，本文也不構成法律意見。

維護成本的形狀由版本節奏看得出來。v1.0.0 在 2026 年 1 月發布，標記為 MVP；v2.0.0 在 5 月；v3 的 foundation 則對應到 8 月的最後一次推送。README 反覆使用「legacy authenticated workspace」來描述 v2 那條路徑，並說 v3 是新基準線。這種節奏下，把 v3 當成穩定平台來投資是有風險的，比較合理的期待是跟著它的架構文件走，等 Workspace Runtime 的所有權模型定案。

真的要動手，先做這幾件可驗證的事：讀 docs/architecture.md 確認目標 Workspace 模型與你需求的距离；照 docs/github-oauth-verification.md 用一個真實的 OAuth 應用跑一次驗證；照 docs/v2-resource-inventory.md 盤點叢集裡既有的 v2 資源；最後，把 PostgreSQL 的讀取權限收斂到最小，因為 README 已經明講，能讀資料庫就等於能拿到使用者的 Kubernetes 憑證。這四件事做完，你對 Fulling 能不能進你的環境就會有具體答案，而不是靠版本號猜。

編輯結論

如果你要的是一個已經能自動寫完整個全端專案並部署到 Kubernetes 的 Agent，Fulling 現在還不是那個東西，README 自己說 v3 只提供身分與 Kubernetes 憑證邊界，Workspace Runtime 仍在 docs/architecture.md 的目標階段。若你的團隊正在自建 AI 工作區，且願意接手一個沒有 v2 相容層、需要對新資料庫執行 npm run prisma:migrate 的基準線，這個 repo 的 kubeconfig 驗證規則值得先讀。動手前先確認三件事：docs/v2-resource-inventory.md 裡 v2 留下的 Kubernetes 資源清單，docs/github-oauth-verification.md 的 OAuth 驗證流程，以及誰有 PostgreSQL 讀取權限，因為那等於誰握有使用者的 Kubernetes 憑證。

官方來源

1. FullAgent/fulling on GitHub
2. License: MIT
3. Project website
4. README
5. Releases