权限规则

用 permissionRules 的 allow / ask / block 决定对 shell 命令放行、要求审批或拒绝，规则位置与示例。

权限规则控制匹配的 shell 命令是否无需审批直接运行、需要审批或被阻止。每条规则指定一个有序的命令前缀，以及验证其匹配行为的示例。它们取代了已弃用的 commandAllowlist、commandDenylist、commandBlocklist（旧列表仍被尊重，无需立刻迁移）。迁移前要确认组织已启用权限规则且你的 Droid 版本支持；检查规则文件只校验内容，不会启用规则执行。

决定	胜出时发生什么
`allow`	命令不经命令审批提示直接运行；hooks 和沙箱限制等其他控制仍然适用
`ask`	在受权限检查的执行中要求审批，即使 High 自主级别也一样；这不是硬性禁止，`--skip-permissions-unsafe` 会跳过确认
`block`	无审批通道地拒绝命令，包括跳过权限提示时

没有策略匹配时由常规会话审批、自主级别和风险处理决定（预览里报告为 no-match）。跨设置来源解析规则 ID 后，匹配的 block 优先于 ask，ask 优先于 allow。位置决定范围：~/.factory/settings.json（个人）、<project>/.factory/settings.json（项目共享）、嵌套的 .factory/settings.json（文件夹规则）、与它们并列的 settings.local.json（本地覆盖）、企业控制（组织策略）；项目和文件夹规则需要工作区受信；规则 ID（如 project/git-push）只是命名约定，不是范围选择器。示例：提交推送前要求审批：

{
  "permissionRules": {
    "version": 1,
    "rules": [
      {
        "id": "project/git-push",
        "decision": "ask",
        "reason": "Review remote Git changes before pushing.",
        "match": { "prefix": ["git", "push"] },
        "tests": {
          "match": ["git push origin main"],
          "noMatch": ["git status", "git log --oneline"]
        }
      }
    ]
  }
}

规则匹配的是这种命令写法，而不是推送的所有方式（例如 git -C /repo push 参数顺序不同），要测试团队实际使用的写法。tests 里的 match/noMatch 示例用来验证规则行为。