# Wishlist

這個檔案記錄討論到但還不直接實作的想法，避免干擾，後續再來排入。

## Code 零件

目前的想法是，用戶發現有一個工作無法用現成零件產出，就建立一個新的零件投稿，測試通過 gherkin 就 publish。

這表示流程比較慢，跟其他的零件不符，例如：
- 打 API 時用內建 http request 零件 + recipe，一個抵多個。
- 內建 credential 零件 + recipe，一個零件可以連到各個服務的 auth。
- 按照此邏輯，code 也可以內建 code 節點 + recipe，一個零件可以做多種任務。

例如我要一個把 Logseq outliners md 讀入，轉成 json 輸出的功能，實際上 Logseq 用戶不多，我不一定需要 publish 它。

或是因為某些機密的理由，用戶不想 publish 他的處理邏輯。

此時有個簡單的 code 節點可以寫簡單的 JS 當 recipe，而 code 寫在資料庫中與 code 節點分離，如果他要 publish 就直接 publish 這個 recipe 即可。

### 架構決策備忘（實作時請讀）

code 零件的 JS recipe **不在 WASM 內部執行**，而是由 code 零件（TinyGo WASM）將 recipe 字串透過 host function 傳遞給外部執行環境。arcrun 的 host 是 Cloudflare Workers isolate（V8），本身就是沙箱，不需要在 WASM 內嵌入 QuickJS 或 javy，也不需要引入 Rust。這與 http_request 零件 + recipe 的模式完全一致：零件本身是穩定的能力抽象（WASM），recipe 是存在 RECIPES KV 的可替換邏輯字串。

JS recipe 可用的 API 範圍為 Cloudflare Workers 標準 Web API（ES2023、fetch、crypto、TextEncoder 等），但 code 零件語意上應為純計算節點（無 network），實作時可考慮用 Proxy 遮蔽 fetch 等 I/O API，初期自用階段可暫時跳過此限制。第三方 lib 的問題留待實作時再決定白名單策略（預注入 lodash-es、dayjs、yaml 等到 global scope 即可覆蓋九成用例）。