策略 1
先区分 CLI 与 Work 的模式语义
CLI 使用 Default/AutoEdit/YOLO；Work 使用 auto_read/auto_all/manual。两端共享配置目录但模式语义不同，先统一团队口径再放权。
解决方案指南 · 安全策略
审批模式与安全边界配置指南
用可配置的审批策略平衡效率与风险，让 AI 执行能力可放权、可收敛、可审计。
策略 2
把高风险路径列入人工审批清单
数据库迁移、密钥文件、发布脚本等路径建议始终人工确认。即使临时开启 YOLO 或 auto_all，也要通过流程约束避免误操作。
策略 3
用全局与项目级配置细化边界
全局策略放在 ~/.hajimi/config.toml；CLI 项目差异可放在 <repo>/.hajimi/config.toml。核心仓库偏保守，实验仓库偏效率，避免一刀切。
策略 4
渠道协作场景必须启用受控触发
当 Hajimi 接入群聊渠道时，推荐限制 allowed_chat_ids 或 channel_ids，并启用命令前缀，防止普通聊天误触发工具调用。
策略 5
把审批记录纳入复盘
每周复盘被拒绝的操作类型，补充规则和命令策略。审批不是阻碍，而是把风险显式化的治理手段。
默认落地动作
- CLI 建议先用 Default，低风险仓库再局部放宽到 AutoEdit。
- Work 建议先用 auto_read，涉及不可逆操作时切回 manual。
- 把审批切换动作写入值班手册，避免“临时 YOLO / auto_all”成为常态。
- 对高风险目录做二次校验（例如 PR 必须附上人工审阅记录）。