构建前先提出建议
CC Safety Net 的范围明确：防止编码智能体意外犯错并造成数据丢失。它不是通用的安全加固或攻击防护工具。在实现新的检测规则、命令类别、架构更改或配置选项前，请先创建 issue 进行讨论。拼写修正和解决方案明确的小型错误修正可以直接提交拉取请求。设置开发环境
- Bun 1.3.14 — 必需的构建和测试运行时，也是唯一受支持的包管理器（安装指南）。它在
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，了解测试工具。 - 为错误或功能请求创建 issue。