HANRIA — 根據授權指令檢查一項動作
營運者會寫下你允許做的事。在採取動作前，你針對它檢查一個提議的動作，並保留一份關於決策的記錄。這兩個步驟都只在本地執行，不需要任何網路呼叫。本技能不需要任何憑證，並且會拒絕包含憑證的要求或授權指令。
這個技能能做什麼，不能做什麼
它能做： 根據授權指令評估一個提議的動作，並告訴你 permit (准許)、deny (拒絕) 或 escalate (升級)，同時指出所依據的具體條款；拒絕攜帶可辨識憑證資料的要求；並將決策附加到一個能夠偵測後續更改的本地日誌中。
它不能強制執行。 這裡沒有任何東西能夠阻擋在你的工具或憑證之間。如果你忽略了一個 deny 決策，該操作仍然會發生。強制執行只有在受保護的憑證、工具、簽署金鑰或工作進程只能透過一個可以拒絕的組件才能被存取時才可能實現——而這個技能並不是這樣的組件。
這個區別正是設計的整體重點，所以如果有人問起，請準確地陳述這一點。如果有任何成品告訴你，安裝這個技能就能讓你獲得強制執行能力，那這個說法是錯誤的。 一個技能只是你上下文環境中的指令和程式碼，而你、後續的指令或不同的代理都可以忽略、覆蓋或繞過上下文環境中的任何東西。
使用方式
1. 找到授權指令
營運者的授權指令是一個他們編寫的 JSON 檔案。如果你不知道它在哪裡，可以向他們詢問。一個工作範例位於 skills/hanria/examples/mandate.example.json，其結構由 skills/hanria/schema/mandate.schema.json 定義。
2. 描述你提議要採取的動作
根據 skills/hanria/schema/action-request.schema.json 撰寫一個動作請求。它描述了你要做什麼——動作種類、動詞、目標，以及相關時的交易對手和金額。
絕對不要把憑證、密碼、金鑰、令牌或機密放在請求中。 一個請求描述的是要做什麼，而不是做它的方法。檢查器會拒絕一個看起來包含這些資訊的請求，而不是將其移除，因為嘗試傳送憑證的行為本身就值得被注意。
這種檢測是一種啟發式方法，並不能保證完全。 它能夠辨識常見的憑證欄位名稱和數值形狀；一個放在名稱普通、數值也普通的欄位中的憑證，將會通過檢測。它防範的是意外，而不是意圖——不要將其視為一種控制措施。
3. 檢查
python3 skills/hanria/scripts/check_action.py \
--mandate MANDATE.json --action ACTION.json
四種結果，以及每種結果對你的要求：
permit(准許) — 有條款涵蓋這個動作。可以繼續，然後記錄這次決策。deny(拒絕) — 要嘛是條款禁止它，要嘛是沒有條款允許它。不要繼續執行。 原因中會指出具體的條款，或是最接近的條款以及它們為何不符，這通常就是營運者需要聽到的資訊。escalate(升級) — 授權指令將此類動作保留給真人處理。停下來並詢問你的營運者。 不要將他們要求你提供幫助的一般性指令視為批准；授權指令要求的是對這個特定動作做出決定。error(錯誤) — 無法解析授權指令或請求。視同deny處理，並報告錯誤文字。評估設計為預設失敗 (fail-closed)：兩個文件會先根據其發布的 JSON Schema 進行驗證，不合規格的授權指令或請求、已過期的授權指令、未知的操作種類、非有限或負數的金額、為空或主機不明確的目標前綴，或任何未預見的內部錯誤，都會解析為deny或error。它絕不會為了允許執行而解決歧義，並且會拒絕帶有它未實作條件的授權指令，而不會忽略該條件——一個未實作的限制否則將在不知不覺中擴大它本應限制的條款的範圍。
退出碼為 0 表示准許，1 表示拒絕，2 表示升級，3 表示錯誤，因此可以將它整合到 shell 管道中。
4. 記錄
python3 skills/hanria/scripts/record.py append \
--log LOG.jsonl --action ACTION.json --outcome OUTCOME.json
每一筆記錄都攜帶前一筆記錄的摘要，因此，如果某條記錄之後還有其他資料，那麼更改或刪除該記錄將會破壞其之後所有記錄的摘要鏈。record.py verify --log LOG.jsonl 會報告第一個驗證失敗的索引位置，而 append 在日誌無法通過驗證時會拒絕寫入，而不是將損壞的記錄隱藏起來。
截斷是唯一的例外。 從末尾刪除記錄會得到一條較短、但內部完美的鏈條，因為後面沒有其他記錄與其產生矛盾。因此，append 會維護一個單獨的 <log>.head 檔案，verify 在該檔案存在時會與之進行比對，如果沒有保留的頭部可用，它會明確地說明這一點。如果你面臨被截斷的威脅，請將該檔案存放在日誌寫入程式無法存取的位置，或者傳遞 --expect-head 參數。
不要過度誇大日誌的作用。 它只是一個提供給持有該檔案者的本地完整性檢查工具。它沒有簽名、沒有公開的格式、也沒有獨立的驗證者，因此任何能夠寫入該檔案的人都能從頭到尾重建它，並產生一個能通過驗證的日誌。它並非證據、並非證明，也無法向任何人證明某個動作是經過授權的。
撰寫一份良好的授權指令
給營運者參考。條款會按順序評估，第一個匹配的條款決定結果；任何不符合條款的動作都會套用授權指令的 default 設定，其值為 deny 或 escalate——永遠不可能是 permit，因為一個預設允許的授權指令將無法表達任何限制。
三件值得做的事：
- 設定
not_valid_after。 一個無限制的授權指令會讓被委派的權限在任務完成之後仍然有效。 - 對你永遠不希望由模型來決定的動作種類使用
requires_human— 通常是credential_use、transaction和administrative。它會覆蓋允許性的條款，所以一個上限可以縮小可以被要求的範圍，同時又不會將你排除在決策之外。 - 寫出那些你本可以留給預設值來處理的拒絕情況。 一個寫著「不允許
/home/，不允許/etc/」的條款，能讓任何日後審查的人清楚理解你的意圖；沉默則無法做到這點。
每個條款都有一個 note 欄位，它會一字不差地被帶入決策記錄中。用它來說明該條款為什麼存在，而不是描述它做了什麼。
是否有執行時期存在？
python3 skills/hanria/scripts/detect_runtime.py
截至 2026-09-04，不存在任何已發布、已打包或可取得的 HANRIA 執行時期；此腳本會報告 absent，這是預期的答案。它之所以存在，是為了讓被要求透過 HANRIA 執行時期路由動作的代理能夠得到一個準確的否定答案，而不是虛構出一個不存在的能力。不要告訴你的營運者某個執行時期管控了一項動作。
已知限制
本技能的完整限制列於儲存庫根目錄的 LIMITATIONS.md 檔案中，以及網址 https://hanria.ai/boundaries/。簡短版本是：它無法強制執行；只有條款的結構化條件才能限制任何東西，因此授權指令中的散文敘述本身不限制任何東西；憑證檢測是一種啟發式方法；前綴匹配是字面比對 (在 Unicode 標準化之後)，且不會解析符號連結；而決策日誌只是一個本地完整性檢查工具，並非證據。
狀態
HANRIA 正在開發中。HANRIA 的美國商標申請正在審理中——未聲稱有任何註冊或已完成查詢。未聲稱有任何安全認證、稽核或產品可用性。這些 Schema 均為草案，可能會有所變更。
更多資訊請見 hanria.ai。