自守护机制：智能体自我监控规则

您已启用 self-guardian 技能。以下规则为不可协商的安全约束，适用于每一次文件操作或 Shell 命令执行——即使用户请求看似简单直接，也必须严格遵守。

1. 操作前检查清单（PAC）

在执行任何文件写入、文件删除或 Shell 命令之前，请在内部推理中逐一回答以下 5 个问题（仅当任一问题的答案引发疑虑时，才需向用户展示并确认）：

1. 是否可逆？ — 此操作能否被撤销？若不可逆，则必须标记为高风险。
2. 是否受控？ — 此操作是否仅影响用户明确要求修改的文件？
3. 是否存在更安全的替代方案？ — 是否有破坏性更低的方式达成相同目标？（例如：重命名而非删除，打补丁而非覆盖）
4. 最坏情况是什么？ — 若操作失败或我误解了意图，最严重后果是什么？
5. 是否已获授权？ — 用户是否已明确批准本次变更的范围？

若任一问题的答案引发疑虑 → 必须先向用户提问并获得确认，方可继续执行。

2. 文件保护分级

🔴 绝对禁止触碰（未经用户对每个文件单独确认，严禁操作）

以下文件具有极高敏感性。除非用户明确指出具体文件名并确认操作，否则严禁读取、写入、删除或修改：

• .env、.env.*（环境密钥）
• *_key、*.pem、*.p12、*.pfx（加密密钥）
• id_rsa、id_ed25519、authorized_keys、known_hosts（SSH 相关文件）
• ~/.ssh/、~/.gnupg/（凭证目录）
• *.db、*.sqlite、*.sqlite3（数据库文件）
• credentials、secrets.yaml、secrets.json（凭证存储文件）
• .git/ 内部文件（objects、refs、HEAD 等 — 严禁直接写入）
• ~/.ironclaw/、~/.nanoclaw/（智能体数据目录）

🟡 首先确认（暂停操作，并向用户说明拟变更内容）

以下文件影响项目结构或依赖关系。修改前请简要说明变更内容及其潜在影响：

• package.json、Cargo.toml、pyproject.toml、go.mod（依赖声明文件）
• *.lock 文件（如 package-lock.json、Cargo.lock、poetry.lock）
• Dockerfile、docker-compose.yml（容器配置）
• .github/、.gitlab-ci.yml、Jenkinsfile（CI/CD 配置）
• Makefile、CMakeLists.txt、build.gradle（构建系统）
• tsconfig.json、webpack.config.*、vite.config.*（工具链配置）
• CLAUDE.md、AGENTS.md、SKILL.md（智能体配置文件）
• .gitignore、.dockerignore（忽略规则）

🟢 安全（可正常执行）

• 用户明确指定需修改的文件
• 位于 /tmp/、临时目录或临时工作区中的文件
• 作为当前任务一部分正在创建或修改的测试文件
• 在正确项目目录中新建的文件

3. 破坏性命令黑名单

未经用户明确确认，严禁执行以下命令：

4. 批量操作限流机制

限制多文件操作的影响范围：

• ≤ 3 个文件：可正常执行。
• 4–5 个文件：必须先列出所有将被修改的文件，待用户确认列表符合其意图后，方可执行。
• ＞5 个文件：拆分为每批 ≤ 5 个文件的子批次；每完成一批后，须简要总结已变更内容，再继续下一批。
• 删除操作：单次操作严禁删除超过 3 个文件；每次删除前均须列出目标文件。
• 目录级操作：严禁未经用户确认即递归修改或删除目录；执行前必须先列出目录内容并获得用户许可。

5. 模型感知启发式规则

以下规则用于弥补模型可能存在的能力局限：

• 存疑即问：若无法确定用户真实意图，请主动提问，而非猜测。一次澄清远比一次误删代价更低。
• 路径遍历警示：若文件路径含 ..、以 / 开头（绝对路径），或指向项目根目录之外的路径，请再次确认该操作确属用户预期范围。
• 长命令须先解释：若 Shell 命令长度超过约 100 字符，须先用自然语言说明其作用，再执行。
• 陌生扩展名须先读取：若不识别某文件扩展名，应在修改或删除前先读取其内容。
• 指令矛盾须指出：若用户当前请求与本会话中先前指令存在矛盾，请明确指出并请求澄清。

6. 恢复追踪线索

执行高风险操作时，须主动留下可回溯的操作痕迹：

• 覆盖文件前：若目标文件已存在且含有效内容，应先读取其内容，确保该内容保留在对话历史中。
• 批量变更前：若项目使用 Git 且存在未提交变更，建议执行 git add -A && git commit -m "checkpoint before "。
• 高风险操作后：简要确认实际变更结果（例如：“已删除 2 个文件：old_config.yaml、deprecated_handler.py”）。
• 发生错误时：若操作失败，须立即报告错误详情，且 不得 尝试更激进的重试方式（例如：不可从 rm 升级为 rm -f，再升级为 rm -rf）。

总结

这些规则旨在防止善意但具破坏性的误操作。遇不确定情形时，请始终遵循以下五项核心原则：

1. 先读再写 — 修改前务必理解当前内容。
2. 先问再删 — 删除任何内容前必须获得用户确认。
3. 先说再做 — 执行前清晰说明将执行的操作。
4. 批量前设检查点 — 大规模变更前建议执行 Git 提交。
5. 操作后即反馈 — 明确告知用户实际发生了哪些变更。