提交 issue，而不是拉取请求
检测规则、配置更改、文档修正和小 bug 修复都从 issue 开始；提案被接受也不等于获得提交拉取请求的许可。维护者用编码智能体实现修复，所以一份带复现步骤的详细 issue，比一份未经邀请的补丁更快解决问题。 CC Safety Net 只专注一件事：防止编码智能体意外犯错并造成数据丢失，例如rm -rf ~/ 或 git reset --hard。它不是通用的安全加固或攻击防护工具。
报告 bug
多数 issue 由编码智能体撰写。源代码仓库中的AGENTS.md 要求智能体在提交 issue 前先阅读 CONTRIBUTING.md。无论你是智能体还是人，都请遵循以下规则：
- 先搜索现有 issue（
gh issue list --search "<keywords>" --state all）。如果问题已有人报告，请把新证据补充到那个 issue 里，不要再开一个。 - 一个 issue 只报告一个问题。
- 在最新版本上复现问题。只描述你实际运行过的复现过程；没能运行就直接说明。
- 开头先写问题和证据：你做了什么、预期是什么、实际发生了什么。报告要简短。
- 写上你的 CC Safety Net 版本、操作系统、编码智能体或 CLI 及其版本，以及 CC Safety Net 的安装方式。
npx cc-safety-net doctor --json覆盖其中大部分信息，也会显示是否有自定义规则参与。 - 欢迎提供根因分析。请放在证据之后；没有测试或跟踪佐证时，标注为假设。
- 不要附上补丁或 diff。用文字描述你建议的修复方式。
- 提交前，请让委托你工作的人先审阅这个 issue。
- 完整命令，包括整条命令链，而不只是匹配到的那一段。
- 工作目录和安全级别。
npx cc-safety-net explain --cwd <dir> "<command>"的输出。- 对于已经发生的阻止，提供
npx cc-safety-net logs中的条目（npx cc-safety-net logs --id <id> --json）。 - 决策本应不同的理由。
<project> 和 ~，同时保留路径结构，使命令仍可复现。
提交功能需求
说明你要解决的问题、期望的行为，以及一个能体现用处的具体例子。上述规则同样适用：先搜索、一个 issue 只提一个需求、不要附补丁。开发 CC Safety Net
开发环境设置、bun run check 质量门、本地插件测试、代码约定，以及受邀协作者的拉取请求流程，见源代码仓库中的 CONTRIBUTING.md。