docs(registry): seed 10 examples + 5 skills (LI SDD M3.1 + M3.3)

對應 .agents/specs/llm-interface/ Milestone 3.1 + 3.3。

registry/examples/ — 10 個可直接 push 的 workflow 範本：
  starter:    webhook-to-http
  common:     cron-watcher, llm-classify, rag-search-answer, daily-digest
  external:   email-summary (gmail+claude+telegram), pdf-to-blocks,
              github-issue-bot
  advanced:   parallel-fanout (trigger_workflow fan-out),
              error-retry (try_catch+wait pattern)

  每個含：workflow.yaml（可直接 push）+ description.md（解決什麼問題 /
  改成你自己的 / 學到什麼）+ tags.json（搜尋用）

registry/skills/ — 5 個 AI playbook（markdown）：
  build_watcher_workflow            — cron + filter + trigger 模式
  debug_paused_workflow             — claude_api callback paused 怎麼追
  migrate_http_to_trigger_workflow  — 從 self-fetch 換 trigger_workflow
  rag_with_arcrun                   — KBDB + claude_api 組裝 RAG
  add_new_wasm_component            — TinyGo 寫 + 部署全流程

兩者差異：
  examples = 可直接拿來改的 YAML
  skills = 面對 X 問題該怎麼想 + 該用哪個 example

兩者後續：CI 自動同步進 KBDB（type=workflow-example / type=agent-skill），
MCP arcrun_search_examples / arcrun_list_skills 走 KBDB semantic search。
（CI sync 是 M3.4 工作）

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

registry/examples/error-retry/description.md

@@ -0,0 +1,38 @@
+# error-retry
+
+## 解決什麼問題
+外部 API 偶發 500 / timeout 是常態。寫死「打一次就放棄」太脆弱。
+這個 pattern 提供標準 retry chain：失敗 → 等 5 秒 → 重試一次 → 還失敗才通知人。
+
+## 怎麼觸發
+```bash
+curl -X POST https://cypher.arcrun.dev/webhooks/named/error_retry/trigger \
+  -d '{
+    "api_key":"ak_xxx",
+    "target_url":"https://flaky-api.example.com/endpoint",
+    "payload":{"x":1},
+    "workflow_name":"my_workflow"
+  }'
+```
+
+## 改成你自己的
+- `wait_a_bit.seconds` 改延遲（指數 backoff：5, 15, 45 秒）
+- 串更多 retry 節點（generic 寫 3-4 次足夠）
+- `final_fail_notify` 換 email / pagerduty / slack 等
+- 加 `if_control` 判斷 error 類型（4xx 不重試、5xx 重試）
+
+## 為什麼這 pattern 重要
+- arcrun 的 `ON_FAIL` 邊是宣告式 error handling，比寫 try/catch 直觀
+- `wait` 零件不消耗 CPU（cypher-executor 排程 sleep 後恢復），比 setTimeout 健康
+- 失敗最終要通知人，不能默默吞 — 通知本身也是 workflow 的責任
+
+## 變體
+- **Circuit breaker**：3 次連續失敗 → 寫 KBDB `circuit:open` flag → 後續 trigger 直接跳過
+- **Dead letter queue**：失敗的 input 寫 KBDB type=dlq-input，方便事後手動重跑
+- **Idempotency key**：retry 時帶同樣的 request_id，避免下游重複處理
+
+## 學到什麼
+- `ON_FAIL` 邊：節點失敗時走哪條
+- `wait` 零件：宣告式 delay，不阻塞 worker（推到 paused-resume）
+- `{{node_id.error}}` 取得失敗節點的錯誤訊息
+- 把「最終失敗通知」當 workflow 一部分，不靠系統外部 monitoring

registry/examples/error-retry/tags.json

@@ -0,0 +1 @@
+["error-handling", "retry", "wait", "try-catch", "robustness", "advanced"]

registry/examples/error-retry/workflow.yaml

@@ -0,0 +1,43 @@
+name: error_retry
+description: try_catch + wait + retry 模式：外部 API 偶發掛掉時自動重試
+
+flow:
+  - "input >> ON_SUCCESS >> try_call"
+  - "try_call >> ON_SUCCESS >> done"
+  - "try_call >> ON_FAIL >> wait_a_bit"
+  - "wait_a_bit >> ON_SUCCESS >> retry_call"
+  - "retry_call >> ON_SUCCESS >> done"
+  - "retry_call >> ON_FAIL >> final_fail_notify"
+
+config:
+  try_call:
+    component: http_request
+    url: "{{input.target_url}}"
+    method: POST
+    body_json:
+      payload: "{{input.payload}}"
+
+  wait_a_bit:
+    component: wait
+    seconds: 5
+
+  # 第二次嘗試。生產環境通常 retry 2-3 次配指數 backoff
+  retry_call:
+    component: http_request
+    url: "{{input.target_url}}"
+    method: POST
+    body_json:
+      payload: "{{input.payload}}"
+      _retry: 1
+
+  done:
+    component: comp_passthrough
+    # 純記錄成功，下游若需要可繼續鏈
+
+  final_fail_notify:
+    component: telegram
+    chat_id: "{{secret.LEO_TELEGRAM_CHAT_ID}}"
+    text: |
+      ⚠️ workflow {{input.workflow_name}} 兩次重試都失敗
+      target: {{input.target_url}}
+      last error: {{retry_call.error}}