用途：为长时间运行的 ralph 或 jeo 自动化工作流提供跨平台权限配置，减少反复审批弹窗，同时避免“到处全放开”。核心原则是只在有边界的项目或一次性沙箱内放宽自动化，并显式封锁密钥与破坏性命令。
主要能力：把各平台权限拆成三层——设置（选择仓库安全预设或仅沙箱 YOLO 预设）、规则（仅限仓库写入、密钥/路径拒绝清单、Tier 1 检查点条件）、钩子（支持预工具拦截的平台强制执行危险边界，否则退回审批策略加提示契约）。还定义动态检查点：Tier 1 始终阻止（rm -rf、git reset --hard、git push --force、DROP TABLE、sudo、.env*/secrets/** 访问、生产环境变更）；Tier 2 警告（npm publish、docker push、非强制 git push、数据库迁移）；Tier 3 自动允许（文件读写、测试、本地构建、lint）。
使用方式：先划定自动化边界，列出必须封锁的文件与命令，判断是普通仓库还是一次性沙箱；再按平台选一个设置预设（Claude Code 用项目 .claude/settings.json，bypassPermissions 仅限隔离沙箱；Codex CLI 优先用官方审批与沙箱模型，旧 permissions.allow/deny 仅作兼容；Gemini CLI 只信任项目根目录，无真正全局 YOLO）；规则层单独写入仓库说明、团队文档或钩子脚本；随后运行 ralph 或 jeo 的 plan-execute-verify 循环并验证输出，临时配置用后回滚。执行契约：边界检查 -> 设置预设 -> 规则契约 -> ralph 运行 -> 验证 -> 清理或回滚。
适用场景：同一仓库需同时配置 Claude Code、Codex CLI、Gemini CLI；需要共享安全模型；需要区分日常自动化与真正 YOLO 模式。
限制：Codex CLI 的 notify 为回合后触发、不阻断，OpenCode 无钩子，只能依赖 approval_policy 与提示契约；Gemini CLI 无全局 YOLO。平台权限模型变化快，升级 CLI 后需重新核对官方文档。具体模板见 references/permission-profiles.md。