HANRIA — 对照授权书检查操作
由作业者（operator）规定你可以执行哪些操作。你在执行之前对照授权书检查提议的操作，并记录下决策结果。这两个步骤均在本地完成，不涉及任何网络调用。该技能不需要任何凭证，且会拒绝包含凭证的请求或授权书。
该技能能做和不能做的事情
它能： 评估提议的操作是否符合作业者编写的授权书，并返回 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 模式验证，不符合的文档、过期的授权书、未知的操作类型、非有限或负数的数量、空的主机或模糊的目标前缀，以及任何未预见的内部故障都会解析为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 运行时能得到正确的否定结果，而不是凭空捏造能力。不要告诉你的作业者某个操作曾受 HANRIA 运行时管辖。
已知限制
此技能的完整限制列表位于仓库根目录的 LIMITATIONS.md 文件以及 https://hanria.ai/boundaries/。简要说明：它无法强制执行；只有条款的结构化条件才能限制任何内容，因此授权书中的散文不限制任何内容；凭证检测是一种启发式方法；前缀匹配是字面的（在 Unicode 组合后），且不解析符号链接；决策日志是本地完整性检查，而非证据。
状态
HANRIA 正在开发中。HANRIA 的美国商标申请正在进行中——未声称已注册或完成审查。未声称任何安全认证、审计或产品可用性。模式为草案，可能会发生变化。
更多信息请访问 hanria.ai。