Leo/Arcrun

Files

T

Leo 13b01328c1 docs: add SDD specs + user requirements + tests

- .agents/specs/: spec-driven-dev docs for arcrun MVP, auth-recipe,
  credential-primitives-wasm (active refactor), landing-page,
  sdk-and-website, u6u-core-mvp, u6u-platform-evolution.
- .agents/steerings/tech.md: detailed tech stack rationale.
- docs/user_requirements/: long-form requirements incl. credential
  primitives, pages spec, py strategy analysis.
- tests/: end-to-end harness scaffolding.

These are the durable context backing CLAUDE.md's SDD protocol.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-04-20 17:48:24 +08:00

6.1 KiB

Raw Blame History

u6u 智慧前端與工匠 AI 開發藍圖 (v4.0)

一、核心設計理念：意圖導向的雙面畫布

u6u 的前端不是傳統的平面繪圖板，而是一個類似 Android Studio 或 Figma 的**「結構化標籤編輯器」。畫布上的每一個元件（Web Component），本質上都是一個「意圖發射器 (Intent Emitter)」**。前端只負責「長得好看」與「收集人類動作」，後端全權負責「業務邏輯」。

人機協作的「雙向同步」

AI 詠唱修改： 人類說「把按鈕改醒目一點」，CEO AI 在背景將 <u6u-btn color="blue"> 修改為 <u6u-btn color="neon-red">，畫面瞬間更新。
人類手動覆寫： 人類覺得 AI 調的紅色太暗，直接在右側屬性面板 (Properties Panel) 點選色碼器，底層 HTML 屬性隨之改變。AI 也能「看見」這個改變，從中學習人類的審美偏好。

二、畫布介面設計與運作機制

1. 正反面翻轉機制 (The "Flip" Interface)

每個 UI 零件在畫布上都有「一體兩面」：

正面 (UI 視圖)： 顯示 HTML 渲染的視覺結果（按鈕、溫度計、圖表）。人類可以在此調整 CSS 屬性、對齊方式與主題顏色。
反面 (邏輯視圖)： 點擊「翻面」按鈕後，會進入底層的工作流設定。這裡使用 u6u 的自定義 Cypher 視覺化語法（例如 >> 符號）。
- 範例： [ UI_Button: "緊急停機" ] >> (Intent: emergency_stop) >> [ WASM: gsheets_create ]

2. 智慧容器與區域感知 (Smart Zone Awareness)

為了消滅傳統 iPaaS（如 n8n）最痛苦的「手動變數綁定」，u6u 畫布具備「區域感知」能力。

底層邏輯（獨立元件）： 畫布上的 TextInput 與 Button 都是各自獨立的原子元件。
麻瓜體驗（智慧表單）： 當使用者將這兩個元件拖入同一個排版容器（例如 <u6u-card>）時，系統會自動建立上下文關聯。當按下按鈕並觸發 Webhook 時，按鈕會自動打包同容器內所有輸入框的值一併送出：
{
"intent": "query_attendance",
"payload": { "employee_id": "A1234" } // 自動從旁邊的 TextInput 抓取
}

使用者完全不需要理解「表單傳值」或「變數綁定」，拖拉組合即生效。

3. 多重事件插槽與靜態屬性 (Multi-Event Slots)

一個前端元件可以具備多種觸發行為，系統透過介面將「視覺」與「後端邏輯」徹底分流：

靜態視覺註釋： 例如 mouseover 顯示提示。使用者只需在屬性面板輸入 Tooltip 文字，底層僅修改 HTML 屬性 <u6u-btn tooltip="...">，不消耗任何伺服器資源或 Webhook。
動態意圖綁定： 在「反面」邏輯視圖中，使用者可以針對不同事件綁定不同的工作流：
- ⚡ When: 點擊 (onClick) ➡️ [ 綁定至 Webhook A：送出查詢 ]
- ⚡ When: 獲得焦點 (onFocus) ➡️ [ 綁定至 Webhook B：載入歷史紀錄 ]

4. 智慧上下文替換 (Smart Contextual Substitution)

當主管在畫布上對著一個已連接 Webhook 的「按鈕」點擊右鍵選擇「替換元件」時：

系統讀取反面的 Cypher 連線，發現需要發射一個 trigger 意圖。
系統過濾 KBDB 零件宇宙，只顯示相容的 UI 零件（如下拉選單、開關）。不具備 trigger 能力的元件（如純文字標籤）會被自動隱藏，確保替換後系統絕對不會報錯。

三、原子化組裝與極致解耦：CEO AI 與工匠 AI 的分工

當企業主管提出需求：「我需要一個『輸入工號即可查詢員工打卡紀錄』的工具」時，這在 u6u 中並不是一個單一零件，而是一個由多個「原子零件」構成的工作流 (Workflow)。

1. CEO AI 的動態組裝 (Macro Assembly)

面對需求，大腦 AI (CEO AI) 會快速從 KBDB 挑選現成積木進行組合：

前端 Prototype 組合： <u6u-text-input> + <u6u-btn> + <u6u-text-field>。
後端 Pseudo Code 組合： webhook_receiver >> check_kbdb(template_name, value)。
AI 會自動用 Cypher 將前端的表單意圖連線到後端工作流。對不懂程式的主管來說，前端就是 Prototype，翻面的 Cypher 就是 Pseudo Code，整套系統瞬間組合完畢。

2. 工匠 AI (Forge AI) 的原子生產線

只有當現有零件庫缺乏特定原子時，機甲才會喚醒工匠 AI 進行開發。

解耦哲學： 後端零件開發時，根本不需要管前端零件長什麼樣子（是按鈕還是輸入框）。只要前端送來的 JSON 它能吃，就是合法的候選零件。

Step 1: 規格定義 (Interface Contract)
工匠 AI 只在乎接收與回傳的 JSON 格式。
Step 2: 打造純粹的邏輯黑箱 (後端 TinyGo WASM)
工匠 AI 撰寫 Go 程式，編譯成 .wasm。絕對純粹的後端邏輯，沒有任何介面程式碼。
Step 3: 獨立的前端零件生產 (若需要)
獨立生成 Web Component（如 <u6u-3d-pie-chart>），只負責接收特定 JSON 來渲染畫面。
Step 4: 註冊與編目 (Cataloging into KBDB)
新積木註冊到圖資料庫，未來的 CEO AI 即可將其與任何既有的前端或後端元件進行無限的叉積組合。

四、架構總結與終極產品體驗

這套前端架構讓 u6u 成為一個**「表裡如一」的系統，成功創造了「麻瓜的 ERP 幻覺」**：

使用者不需要知道什麼是「前後端分離」、什麼是「API 串接」。他們只是覺得：

拖拉了一個溫度計。
翻面把「數值更新」連線到「機台感測器」。
拖拉了一個紅按鈕放在旁邊。
翻面把「點擊」連線到「發送 Line 警報」。

在十分鐘的「繪圖」過程中，沒有寫一行程式碼，也沒有設定任何變數。但透過前端 Web Components 的視覺封裝、智慧容器的自動資料打包，以及後端 TinyGo WASM + Cypher 的無縫承接，他們在不知不覺中，就搭建出了一套具備微服務架構、高擴展性、且可部署至極限邊緣的企業級系統。

6.1 KiB Raw Blame History Unescape Escape