cursorrules

Sieve · Cursor 项目规则

本文件是 Sieve 项目的 Cursor 工作规则，分两层：文档规则（沿用用户级 .cursorrules 模板骨架）+ Sieve 工程硬约束（项目级共识）。

当前项目状态：早期预览（0.1.0-alpha），所有约束按生产语境强制执行。

---

一、文档规则

1.1 核心规则

1. 改代码前必须先读 @docs/ 中相关文档（需求 → 设计 → API），不盲目重构
2. 完成代码修改后必须更新所有关联文档，禁止单独更新一个文档而忽略关联文档
3. 临时文档使用前缀 _temp- 或 _draft-，存放于 docs/_temp/，任务完成后 24 小时内删除或归档
4. 所有跨文档引用一律使用相对路径链接

1.2 文档位置约定

README.md                  # 唯一放在根目录的文档（项目入口）
.cursorrules               # 本文件
docs/
├── design/                # 设计文档（architecture.md / data-model.md）
├── api/                   # API 文档（api-reference.md）
├── specs/                 # 功能技术规格（SPEC-NNN-*.md，含 SPEC-005 IPC 权威源）
├── guides/                # 使用指南（development.md / deployment.md）
├── changelog/             # 变更日志（CHANGELOG.md）
├── research/              # 调研材料
└── _temp/                 # 临时文档（用完即删）

1.3 AI 行为约定

• 讨论技术方案时，主动引用 @docs/design/
• 修改 API 时，必须引用 @docs/api/
• 改 IPC 字段时，必须先改 @docs/specs/SPEC-005-ipc-protocol.md
• 每次代码变更后，列出"需要更新的文档清单"

1.4 文档关联图

README.md
  ↓ 链接到
docs/design/architecture.md
  ↓ 约束
docs/api/api-reference.md + docs/specs/
  ↓ 记录变更
docs/changelog/CHANGELOG.md

规则：上游文档变更时，必须检查并更新所有下游文档。

1.5 文档化触发条件

场景	目标文档	优先级
新增功能	设计文档 + README + CHANGELOG	P0
修改 API（Anthropic / Unified Message）	api-reference.md + CHANGELOG	P0
架构变更（pipeline / 模块边界）	architecture.md + CHANGELOG	P0
Bug 修复涉及检测规则逻辑变更	CHANGELOG + 相关设计文档	P1
配置变更（config.toml schema）	deployment.md / development.md	P1
依赖升级（含 vectorscan / rustls）	CHANGELOG	P2

无需文档化：纯代码格式化、注释优化、测试补充（无功能变更）。

---

二、Sieve 工程硬约束（十六条）

每条都是"做错就死"，不是优化项，不接受任何阶段性妥协：

1. Rust 栈非选项——Go regexp 慢 1000 倍，主路径 hot loop 不允许引入非 Rust 二进制依赖
2. 绝不做联网 verifier——发送 token 到外部验证 = 摧毁产品定位，校验位 / entropy 全部本地完成
3. fail-closed High-Risk Tool Policy Gate + 强制确认——YOLO mode 不允许关闭，签名 / shell / 敏感路径所有 Critical 工具调用必须走人工确认
4. BIP39 必须做 SHA-256 checksum 验证——这是 Sieve 的差异化点，仅词表匹配不足以定级 Critical
5. SSE 边界处理写大量 fuzz test——半行 chunk、跨 chunk 分隔符、嵌入 C0 控制字符、多 event 粘包、提前断流必须全部覆盖，PR 不带 fuzz 不合并
6. Sieve 自身的供应链必须 sigstore + reproducible build + pinned dependencies——LiteLLM 事件就是先例。这件事比检测精度重要
7. Critical 拦截 FP 必须 < 0.5%——超过即用户禁用产品
8. Critical 在所有版本（包括降级模式）不可关闭——产品安全承诺，不是用户偏好
9. 适配四家 agent：Claude Code / OpenClaw / Hermes / Codex CLI，UnifiedMessage 真实双协议——Anthropic Messages API + OpenAI Chat Completions 都跑通；Codex CLI 走原生 PreToolUse hook 经 IPC judge_tool_call 取裁决，OpenClaw / Hermes 两家 hook 作 UX 层、安全不变量由网关 inbound_hold 兜底 fail-closed；Gemini / Mistral 等其他协议推 Phase 2，真有用户主动要再做
10. GA 时一次性公开 repo + 代码 + 文档——sigstore + reproducible build pipeline 照常跑通
11. 不在 Anthropic API 协议层撒谎——不伪造 tool_use / stop_reason / id / usage / type；拦截发生时允许截 SSE 流注入 sieve_blocked event（Sieve 自报，不是冒充模型）；keep-alive comment 行不算伪造
12. 不装本地 CA 做 MITM——Network Extension / 本地 CA 注入 / 系统 proxy 修改推 Phase 3 选购，Phase 1/2 不做
13. 出站脱敏不打断工作流——OUT-01~05/12 高频类自动脱敏 + 状态栏 5s 通知，不弹窗；弹窗次数过多用户直接禁用产品
14. 用户规则系统 fail-safe（v2.0 新增）——用户规则文件加载失败 / pattern 编译失败 / 安全 lint 拒绝 → daemon 必须正常启动 + 系统规则全功能；用户规则不能 override 或 suppress 系统 Critical；用户规则只能 High Ask/Warn/Mark，不能 Block / HookTerminal。详见 LayeredEngine 合并顺序
15. 行为序列检测的保守起步 + 默认关闭（v2.0 新增）——IN-SEQ-* 仅触发 StatusBar 通知，不引入新 Block 路径；默认关闭（[features] sequence_detection = false），用户主动 opt-in。升级为 Block 类需充分样本积累 + FP < 0.5% + 新决策记录。
16. 所有入站能力必须经过 content-type 路由矩阵测试（v2.0 新增）——任何新增入站功能必须有集成测试覆盖 4 类组合（Anthropic SSE / Anthropic JSON / OpenAI SSE / OpenAI stream=false JSON）；新功能只挂 SSE 不挂 JSON 视为 P0 漏洞。