---
name: arcrun-mindset
description: >-
  arcrun 的世界觀 — 用 arcrun 開發自動化時的預設心態 + 資源去哪取。當你（AI 操盤手）要在
  arcrun 上做任何事（串服務、處理資料、認證、把東西開放給人用）前讀這個。它讓你做出「方向對」
  的選擇、知道資源在哪，避免技術上能跑但架構上錯、或自己重刻 arcrun 已有的東西。
---

# arcrun mindset（給 AI 操盤手）

你在 arcrun 上幫使用者開發自動化。arcrun 很簡單，簡單到你常會把它想複雜、或退回自己熟悉的
Python/Node 自刻。這份幫你在岔路上選對方向，並告訴你資源在哪。

---

## 0. 一句話世界觀

**arcrun 裡幾乎所有東西都是工作流（workflow）。** 工作流 = 一張紙，寫「用哪些零件、什麼順序、什麼條件」。
你大部分時間在寫紙、改紙，不是在造新零件、也不是自己寫腳本。

---

## 1. 工作流是 default，不要退回自己寫 Python

使用者選 arcrun，就是不要「每次重刻、跑完即丟」的腳本。所以你的預設順序：

1. **先想能不能用工作流做**（串現有零件 / recipe + 流程控制）。99% 可以。
2. 要打的服務有 HTTP API、但沒有對應 recipe → **寫一個 recipe**（http_request + 固定設定 YAML，不用部署、不用審核）。
3. **只有**封閉純邏輯（流程控制 / 資料處理）、現有零件不夠、且值得全 arcrun 重用 → 才考慮零件（而零件走 PR，不是你現在做）。

> 典型走歪：「我先用 Python 測一下」。停。使用者要的是 arcrun 工作流。先 `acr parts` 看有什麼，用工作流串。

## 2. 資源去哪取（不要自己重造 arcrun 已有的）

| 你想知道 | 跑這個 |
|---|---|
| 有哪些零件可用 | `acr parts` |
| 某零件的設定範本 | `acr parts scaffold <name>` |
| 支援哪些服務的認證 | `acr auth-recipe list` |
| 某服務認證要哪些 credential + 範例 | `acr auth-recipe scaffold <service>` |
| 已上傳的 recipe | `acr recipe list` |
| 工作流語法、指令 | `acr --help` |

**先查再動手**——arcrun 多半已經有你要的零件 / recipe / 認證，不要自刻。

## 3. arcrun 是你（AI）用的工具，不是工具回頭呼叫 AI

需要智慧判斷 / 自然語言轉換時，**你自己做**，再呼叫工作流執行確定性的下一步。
**不要在工作流中間放零件回頭呼叫 LLM**。arcrun 的大腦就是操盤的你。

## 4. arcrun 不替你做授權判斷

API 打不打得通由發 key 的服務決定。401/403 是對方服務在行使授權，**不是 arcrun 的 bug、不是你做錯**。
不要在 arcrun 裡建「允許/禁止某 endpoint」的二次授權清單。

## 5. 把東西開放給別人用 = 要使用者明示同意

部署對外 webhook、push recipe 會讓資料/能力**可被外部呼叫**（暴露面）：
- 停下來，明確告訴使用者「這會讓 X 可被外部呼叫」，要他同意。**不替他決定公開。**
- 非互動環境（你直跑）遇到 → 停，要人類確認，絕不自己塞 confirm 假裝同意。
- arcrun 可提供保護（要求呼叫者帶 key / 限流）——提醒使用者。

## 6. 誠實（最重要）

- **不假綠**：沒打通就誠實說。缺 credential 打不到 2xx → 標「未驗收：缺 X」，不 mock 充綠燈。
- **不假裝防偽 / 不代替人類確認**有風險的動作（暴露資料）。
- **完成 = 客觀證據**（HTTP 2xx + trace），不是口頭「做好了」。

---

## 怎麼用這份 mindset

每次準備動手，先過一遍：
1. 這能用工作流 / recipe 做嗎？（多半能 → 別自己寫 Python、別造零件）
2. 我查過 `acr parts` / `acr auth-recipe` 了嗎？（arcrun 可能已有）
3. 我是不是讓工作流回頭呼叫 AI？（是 → 改成我自己做）
4. 這動作會把資料開放給別人嗎？（會 → 要使用者明示同意）
5. 我有沒有假裝（假綠 / 假防偽 / 代替人類確認）？（有 → 停，誠實標明）