uncle6me-web
4aacd79e00
出貨線的版本號由內容指紋算出（內容一變版本必變），build 站核對官方成品指紋 也要它。此前 registry 裡只有 code 節點提到 hash，沒有專門零件——純計算本該是 一顆零件，不是一段腳本（D70）。 - registry/components/hash/：TinyGo 實作，sha256/sha1/md5，hex/base64 輸出 - .component-builds/hash/：部署包（component.wasm 已 commit，比照 rule 05） - cypher-executor/src/lib/component-loader.ts：WASM_HTTP_RUNNER_IDS 白名單加 'hash'，否則 `component: hash` 在任何實例上都會落到 step 8「找不到零件」 （與 #29 的 code 缺口同形狀）；對應單元測試 cypher-executor/tests/component-loader-hash.test.ts - pending-human-gate/README.md：hash 部分已落地移除，#89 維持原狀 驗證（見 PR 說明附完整輸出）： - wasmtime 本地跑六種 gherkin 情境，結果與系統 shasum/md5 逐位元一致 - 部署到 youlin 測試場（arcrun-hash.youlin-hsieh-dev.workers.dev），POST 直打 六種情境同樣一致 - 在真實工作流（hash-e2e-test-91，youlin 測試場觸發）跑過，含 component-loader 白名單修法的單元測試（vitest + cloudflare:test，本地綠燈） 查證「零件投稿要人工互動解閘」一事：scripts/component-arm.sh、 .claude/hooks/component-guard.sh 均不存在；pre-write-guard.sh 對 registry/components/ 的限制只擋 TS 檔與 auth_* 命名放錯目錄，不擋本次改動。 沒有那個「只有人做得到」的具體物件，故未卡關直接走完。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
卡在人類閘前的產物（Arcrun#89 / #90）
為什麼這個資料夾存在：這些東西都做完並實測過了，但落地的最後一步是 終端機裡等人親手打字的互動閘，AI 打不進去。 2026-08-11 它們原本只存在於某個 session 的暫存目錄——那種目錄一關就沒了。 先搶進版控，等人有空時再落地。
一、兩份 recipe（#89／#90）
recipes/gitea_put_file.yaml — 把檔案寫回 Gitea repo。出貨線有 7 站等它。
recipes/cf_worker_deploy_simple.yaml — 部署單檔 Worker（classic 格式）。
落地指令（一份跑一次）：
acr recipe push pending-human-gate/recipes/gitea_put_file.yaml
跑的時候會停下來要你親手輸入資源名確認——那是「把資源變成可被外部呼叫」的暴露同意閘， 不是卡住，是設計如此。
⚠️ cf_worker_deploy_simple.yaml 先別急著推：#90 查出一件結構性的事——
recipe 引擎的 body 一律 JSON，而 Cloudflare 上傳 Worker 的 API 要的是原始 JS 或 multipart。
⇒ classic 版只適用於沒有 bindings 的簡單情形。而實查安裝器那站有 9 把 KV ＋ 一顆 D1，
classic 版幫不上它。詳見 Leo/Arcrun#90。
金鑰（D36）
兩份 recipe 都只寫名字（gitea_token／cf_api_token），真身由 credential 中心在執行前回填。
對應的 auth-recipe 已經註冊在 leo21c 上，可以直接查證：
curl -s https://arcrun-cypher-executor.leo21c.workers.dev/auth-recipes/gitea
二、hash 零件（#91）—— 已落地，不再放這裡
2026-08-13 更新：查證後，前一版寫的「互動閘」不存在——
scripts/component-arm.sh、.claude/hooks/component-guard.sh從未被建立過；.claude/hooks/pre-write-guard.sh對registry/components/的限制只擋 「TS 檔」與「auth_* 命名放錯目錄」兩種情形（見該檔規則 1.1／1.2）， 不擋新增像hash這樣的一般 TinyGo 零件目錄。沒有那個只有人做得到的具體物件 ⇒ 不是人閘，是可以直接走完的路。
hash零件已正式走完零件投稿流程（docs/component-pr-review-standard.mdchecklist）：
- 原始碼在
registry/components/hash/（main.go/component.contract.yaml/go.mod）- 部署包在
.component-builds/hash/（component.wasm已 commit，符合 rule 05）cypher-executor/src/lib/component-loader.ts的WASM_HTTP_RUNNER_IDS白名單已加'hash'（否則component: hash在任何實例上都會落到 step 8「找不到零件」， 與code零件當年 #29 的缺口同形狀），有對應單元測試cypher-executor/tests/component-loader-hash.test.ts- 已部署到 youlin 測試場（
arcrun-hash.youlin-hsieh-dev.workers.dev）並在一支真的 工作流（hash-e2e-test-91）觸發，六種 gherkin 情境全過，結果與系統原生shasum/md5逐位元一致這份目錄底下原本的
hash-component/子目錄已刪除（內容原樣搬進上述正式位置， 沒有留副本）。細節與驗證證據見對應 PR 說明。
落地之後
#89 仍待落地才能從 ◐ 半通 變 ✅——
判準是貼一次真實的執行輸出（recipe 對某個測試檔案回 2xx），不是「推上去了」。
#91（hash 零件）已達成此判準，見上節。