构建前先提出建议
CC Safety Net 的范围明确：防止编码智能体意外犯错并造成数据丢失。它不是通用的安全加固或攻击防护工具。在实现新的检测规则、命令类别、架构更改或配置选项前，请先创建 issue 进行讨论。拼写修正和有明确解决方案的小 bug 修复可以直接提交拉取请求。设置开发环境
- Bun 1.4.0：必需的构建和测试运行时，也是唯一受支持的包管理器（安装指南）。它已在
package.json的packageManager字段中固定版本。 - Node.js 18 或更高版本：构建产物受支持的运行时。运行已发布的 CLI 或插件不需要 Bun。
- Claude Code 或 OpenCode：仅当你要在本地加载并测试插件时需要。构建项目或运行测试套件不需要它们。
bun run check 是唯一的质量门。它依次运行 Biome lint 和格式检查、TypeScript 类型检查、knip 死代码检测、jscpd 重复检测、带覆盖率统计的测试套件，以及覆盖率阈值检查。完成更改后运行一次，不必分别运行各个子命令。创建拉取请求前，请确认它无错误通过。
迭代过程中也可以单独运行这些命令：
测试本地插件
先构建，再加载本地插件来测试真实的阻止行为：- Claude Code：禁用任何已安装的 safety-net 插件，退出 Claude Code，然后在仓库根目录运行
claude --plugin-dir .。 - OpenCode：将
~/.config/opencode/opencode.json中的plugin[]数组指向已构建的file://.../cc-safety-net/dist/index.js，删除 npmcc-safety-net条目以避免冲突，然后重启 OpenCode。运行/status，并确认插件名称显示为dist。
git checkout -- ':(exclude,top)**' 必须被阻止。如果保护未生效，该 pathspec 也不会选中任何文件。
遵循代码约定
样式指南
- 除非代码确实可组合或可复用，否则将代码保留在一个函数中。
- 避免使用
try/catch、any类型和else分支。优先使用提前返回。 - 优先使用函数式数组方法（
flatMap、filter、map），不要使用for循环；对filter使用类型守卫，以便下游保留类型推断。 - 优先使用
const，不要使用let；使用三元表达式或提前返回，不要重新赋值。 - 直接内联只使用一次的值，不要为其命名，并避免不必要的解构。
范围纪律
过度工程是本项目最常见的失败模式。只做满足需求的最小更改。任何额外内容都必须对应一种具体故障。每项检查都必须能在实际使用中证伪。在出现第一个真实条目前，不要预先构建 schema、验证器、注册表或测试框架。流程要求应写进文档，不要用代码强制执行。Knip
绝不在knip.ts 的 ignoreIssues 中添加条目。当 knip 标记未使用的导出时，请修复根本原因：删除或取消导出确实无用的代码；使用 /** @internal */ JSDoc 注释标记仅用于测试的导出（knip 以 --production 模式运行，因此排除测试文件）；从 barrel 文件中删除未使用的名称。
准备拉取请求
- 代码遵循上述约定。
bun run check通过且没有错误。- 为新规则添加测试，覆盖率至少为 90%。
- 在本地至少用一个受支持的智能体测试过，例如 Codex、Claude Code、Gemini CLI、GitHub Copilot CLI、Kimi Code 或 Pi。安装页面列出了全部十三个智能体。
- 在需要时更新文档（
README.md、AGENTS.md）。 - 不更改
package.json中的版本。
package.json 或 plugin.json 中的版本。
获取开发帮助
bunx cc-safety-net doctor验证你的环境配置。bunx cc-safety-net explain "<command>"逐步显示命令的分析过程。- 查看源代码仓库中的
CLAUDE.md或AGENTS.md，了解架构和约定；在审查代码前阅读REVIEW.md。 - 查看
src/analyzer/中的现有实现，了解代码写法；查看tests/helpers.ts，了解测试工具。 - 遇到 bug 或有功能需求时，请创建 issue。