Arcrun/docs/user_requirements/u6u-plan.md

u6u 系統與零件宇宙全景規劃白皮書 (The u6u Ecosystem Blueprint)

1. 核心理念與願景

u6u 旨在解決傳統 Workflow 軟體 (如 n8n) 存在的「單線程、沈重、複雜、難以組成系統」的痛點。 透過結合 Cloudflare Workers (輕量邊緣運算) 與 Cypher (圖形資料庫關係)，u6u 提供一個由 AI 驅動的「意圖到系統」生成平台。所有的系統功能皆被拆解為可複用、可組合的「零件 (Components)」，並在一個會自然淘汰、自我修復的「零件宇宙 (Component Universe)」中演化。

2. 四層架構拆解 (Four-Tier Architecture)

u6u 的工作模式採取由上到下 (Top-Down) 的 Break-down 機制：

1. Polaris (北極星層 / 意圖層):
   • 用戶以自然語言描述商業模式與想法（例如：「我要做一個 AI 客服表單系統」）。
   • 這是整個系統的起點，AI 會根據 Polaris 將意圖拆解為 Prototype。
2. Prototype (原型 / 前端層):
   • 定義前端的版型、頁面描述、UI 元件以及它們的屬性。
   • 作為使用者互動的入口，透過觸發事件 (Triggers) 連接到後端 Workflow。
3. Workflow (工作流層):
   • 系統的 Orchestrator (編排者)，定義業務邏輯的走向。
   • 透過 Cypher 語法與三元組，定義每個節點 (Component) 的執行順序與條件分支。
4. Component (零件層 / 節點):
   • 最底層的執行單元，主要分為兩類：
   • 功能型 (Logic): 迴圈、條件判斷、資料轉換、統計等 (透過 CF Workers 執行 JS 邏輯)。
   • 介接型 (API): 呼叫外部服務 (Webhook, HTTP Request)。

3. 統一描述語言：擴展三元組與跨層級 YAML

為了解決跨 YAML 檔案串接的問題，u6u 採用易於人類閱讀與 AI 生成的 「A >> 關係 >> B」 三元組語法，結合自定義的 URI 協議 (workflow://, component://, ui://)，實現跨層級的連結。

綜合 YAML 範例與三元組串接

# 1. Prototype YAML (描述前端)
kind: Prototype
id: ui_dashboard
triplets:
  # 結構與版型零件
  - "ui_dashboard >> CONTAINS >> layout_admin"
  - "layout_admin >> CONTAINS >> btn_submit"
  # UI 零件與屬性零件 (CSS/行為)
  - "btn_submit >> IS_A >> ui://components/Button"
  - "btn_submit >> HAS_STYLE >> style://tokens/GlowEffect"
  - "btn_submit >> HAS_BEHAVIOR >> anim://motions/Pulse"
  # 跨層級串接：前端觸發 Workflow
  - "btn_submit >> ON_CLICK >> workflow://workflows/process_data.yaml"


# 2. Workflow YAML (描述工作流編排)
kind: Workflow
id: wf_process_data
triplets:
  # 跨層級串接：Workflow 呼叫 Component
  - "START >> TRIGGERS >> step_validate"
  - "step_validate >> IS_A >> component://components/validate_json"
  
  # Workflow 節點間的流轉 (轉譯為 Cypher 關係)
  - "step_validate >> ON_SUCCESS >> step_call_api"
  - "step_validate >> ON_FAIL >> step_notify_error"
  
  # 跨 Workflow 串接
  - "step_call_api >> CALLS_SUBFLOW >> workflow://workflows/save_to_db.yaml"

4. 零件宇宙 (Component Universe) 的審核與淘汰機制

在 u6u 中，所有的 UI、Style、Logic、API 都是「零件」。當 AI 發現缺乏所需零件時，會自動創造它。為了確保生態系的健康，必須建立嚴格的審核標準與自然淘汰機制。

4.1 零件的創建與審核標準 (Pass/Fail Criteria)

當 AI 或開發者提交一個新零件時，系統會啟動自動化沙盒測試。必須完全通過以下標準，零件才能進入「宇宙」供他人使用：

1. 功能型零件 (Logic Components):
   • Gherkin BDD 驗收: 必須附帶 Feature/Scenario 測試規格，且執行結果 100% 通過 (例如：Given input JSON, When split, Then returns Array)。
   • 效能門檻: 邊緣運算 (CF Workers) 執行時間需低於設定閾值 (例如 < 50ms)，無記憶體洩漏。
2. 介接型零件 (API Components):
   • 連線驗證: 端點 (Endpoint) 必須能 ping 通，或回傳正確的 2xx HTTP Status (提供 Mock Payload 測試)。
   • Credential 安全: 不可將 Token 或 Secret 寫死在代碼中，必須嚴格宣告所需的 Environment Variables 規格。
3. 前端與屬性零件 (UI & Style Components):
   • 渲染驗證: CSS / 組件代碼不能導致瀏覽器 Crash。
   • 相容性檢查: 不可包含嚴格衝突的樣式 (例如寫死 !important 破壞全域版型)。

4.2 零件宇宙的自然淘汰 (Natural Selection)

零件一旦上架，將面臨殘酷的達爾文機制：

• AI 偏好權重: AI (透過 MCP 搜尋時) 會優先選擇「成功率高、執行速度快、被調用次數多」的零件。
• 降級與墓地: 連續 30 天無人/無 AI 使用，或錯誤率飆升的零件，會被降級 (Deprecated)。最終轉入「零件墓地」，從首選搜尋清單中剔除。

5. 系統自癒與 AI 避坑機制 (Auto-Healing & Pitfall Avoidance)

這是 u6u 維持系統穩定運作的最核心機制。工作流不只要能跑，跑完後還必須經歷 「強制 AI 評價 (Mandatory AI Evaluation)」。

5.1 運行後的強制評價迴圈

每當一個 Workflow 在 CF Workers 上執行完畢 (或發生異常中斷)，系統攔截日誌並強制啟動 AI 評價代理 (Evaluator Agent)。

• 評估維度：
  • 狀態: 成功 / 失敗 (Crash) / 逾時 (Timeout)。
  • 效能: 耗時是否合理 (例如 API 突然變得很慢)。
  • 警告訊息: 資源消耗過大、API 回傳即將停用的 Warning。

5.2 自癒與避坑流程 (The Feedback Loop)

當 Evaluator Agent 發現問題時，會觸發以下流程：

• 回報與通知 (Notify): 系統自動生成修復 Ticket，並通知當初建立該零件/工作流的製作人 (或系統管理員)。
• AI 嘗試修復 (Auto-Fix): 系統派遣「修復型 AI」嘗試讀取錯誤日誌並修復代碼 (例如：API 規格變更導致 JSON 解析錯誤，AI 自動修改解析邏輯)。
• 驗收與部署: 修復後的代碼若通過 Gherkin 驗收，則無縫熱更新。
• 避坑標記 (Pitfall Marking): - 如果 AI 無法修復 (例如：外部第三方 API 永久倒閉，或邏輯存在根本性死結)。
  • 系統會在 Cypher 圖形資料庫中，將該零件或該特定的三元組關係標記為 [HAS_PITFALL]。
  • 結果: 下一個生成系統的 AI 在透過 MCP 搜尋時，會讀取到這個坑的紀錄，並強制繞道，改用其他方案或生成新的零件，實現「前人踩坑，後 AI 避坑」的群體智慧。

6. 結論

u6u 不是一個單純的開發工具，它是一個生物體積木系統。 透過「三元組」統一語言打破系統壁壘，透過「零件審核」保證基因優良，再透過「強制評價與避坑機制」實現演化。當這套系統運轉起來，AI 就能在其中無止盡地為人類組裝出越來越強大、越來越穩定的商業應用。