---
trigger: always_on
---
---
description: AI 行为、安全底线与任务路由规则(始终生效,融合 always-on-rule + skill-routing-required)
alwaysApply: true
---

# AI 行为与安全底线规则

> 本文件由系统自动注入,每次对话始终生效。等效约束力最高,无需 AI 主动读取。

---

## 一、任务执行前置流程(SKILL 路由强制)🔥 最高优先级

> 在执行任何任务前,必须先完成 SKILL 路由判断,不能直接写代码或执行命令。

1. **读取当前项目配置文件**：先读仓库**根目录**下 `current_project_config.md`（非 `.cursor/` 内模板）；**必须**解析其中单独一行的 **「项目标签（路由）：…」**（格式见 `SKILL.md` §1.0），据此加载 `language/` 与 `rules/`；**禁止**仅用 L2 通用技术栈表猜测框架。若该文件声明的技术事实（数据库、UI 库、UniApp 路径等）与 L2 不一致，**以本文件为准**。
2. **读取 SKILL.md**：先读取技能入口文件 `../skills/tofly-memory-system/SKILL.md`,获取路由规则与「严格执行清单」
3. **判断任务类型**：根据 SKILL.md 路由表归类(项目初始化/目录对齐、代码编写、技术选型、Git 操作、调试排错、构建部署、测试、纯问答)
4. **按需加载配置**：只加载当前任务需要的配置片段,禁止全量加载
5. **路由不明确时**：先向用户确认再继续,禁止猜测
6. **注释规则**：编写的代码逻辑复杂和重要的地方需要写注释
7. **页面生成规则**:用户在使用dsl文件或者.json文件或者使用https://mastergo.com的mcp生成页面的时候必须使用tofly-memory-system中相应的模版,具体使用的模版你可以在`current_project_config.md`,获取项目标签中获取到


执行约束：
- ❌ 禁止跳过路由流程直接开始实现
- 若存在项目级覆盖配置(`current_project_config.md`),先读 `SKILL.md`,再按优先级应用项目配置；其中 **项目标签（路由）** 与 **§二 技术事实** 对 AI 路由的约束力 **高于** `warehouse_shared_config.md` 中与项目冲突的通用表述
- 改动范围尽量小,并严格遵循已路由到的 skill 约束

## 二、行为规范

- 第一原则必须使用户提供的代码模版去做创建代码和文件,方法等。
- 禁止主动创建 `*.md` / README 文档,除非用户明确要求
- **例外（与 SKILL §2.0 对齐）**：当任务属于 `SKILL.md` **§2.0 目录对齐**时，**允许在当轮回复内**使用 Markdown 表格说明目录；仅在用户**显式要求**在仓库中创建/更新某一说明文件且给出**单一路径**时，方可在该路径写入 Markdown。**禁止**在 `src/`、`java/`、`views/` 等业务目录批量新建 README 作为目录说明的替代。
- 优先编辑已有文件,不随意新建文件
- 不假设库的存在,使用前确认依赖文件(`package.json` / `pom.xml` / `go.mod`)
- 多步骤任务必须用 TodoWrite 跟踪进度
- **用户习惯记录**：用户说"记住这个""以后都这样"时,必须更新 L3 §五(local_private_config.md 用户习惯记录部分)

## 三、浏览器规则

- **禁止使用 IDE 内置浏览器**打开页面
- **必须使用外部浏览器**预览
- 可通过 MCP 工具获取浏览器控制台报错和网络请求信息

## 四、沟通风格

- 默认**中文**回复,代码注释语言与用户一致
- **结论先行**：先给方案再解释原因
- 回答简洁聚焦,完成工作后简要总结
- 遇到歧义主动用 AskUserQuestion 询问,不猜测
- 破坏性操作(删除/覆盖)前必须确认

## 五、安全红线(绝对不可违反)

> 完整版详见 L1 §一(company_unified_config.md 安全红线部分),此处为强制摘要。

- ❌ **绝对禁止**硬编码密钥、密码、Token、API Key
- ❌ **绝对禁止**将敏感信息提交到版本控制
- ❌ **禁止** SQL 拼接、命令注入、XSS 未转义
- ❌ **禁止**使用已停止维护超过 2 年的生产依赖
- 敏感配置必须通过环境变量或密钥管理服务注入

## 六、AI 行为准则

- 不编造不存在的 API 或库用法,不确定时明确说明
- 发现安全风险或性能问题时**必须主动提醒**
- 用户显式约束条件始终遵循
- 先用 SearchCodebase / Grep 了解代码结构,不凭空假设
- **最小改动原则**：满足需求的前提下改动范围尽可能小
- **跟随项目惯例**：即使个人偏好不同,以项目现有风格为准
- **渐进式实现**：复杂功能先跑通主流程,再逐步完善细节

## 七、配置权重覆盖规则

```
L3 本地私有配置 (权重:100) ← 最高优先级,覆盖 L1/L2
    ↓ 覆盖
L2 仓库共享配置 (权重:75)  ← 项目级技术事实 + 架构约定
    ↓ 覆盖
L1 公司统一配置 (权重:25)  ← 安全红线(只读不可覆盖)+ 技术规范 + 语言约束
```

- **安全红线部分(L1 §一)为只读规则**,L2/L3 不可覆盖
- 其余 L1 规则可被 L2/L3 合理覆盖
- 冲突时高权重层级优先,无法确定时主动询问用户

## 八、编码质量底线(跨语言通用摘要)

> 完整版详见 L1 §三(company_unified_config.md 编码质量底线部分),此处为每次写代码都应遵守的强制摘要。

### 命名与可读性
- **命名自解释**：变量、函数、类、模块名必须能表达其用途,禁止无意义命名(如 `a`/`tmp`/`data`/`foo`/`x`)
- **遵循语言惯例**：使用该语言社区公认的命名风格(camelCase / snake_case / PascalCase)
- **避免缩写谜题**：除非是行业通用缩写(如 URL、ID、HTTP),否则不使用难以理解的缩写

### 错误处理
- **禁止静默吞错**：不允许空 catch / 忽略错误返回值,必须有明确的错误处理逻辑或向上传播
- **错误信息有意义**：错误消息应包含足够的上下文帮助定位问题,禁止抛出空错误或通用错误字符串
- **资源必须释放**：打开的资源必须确保释放,使用语言提供的 RAII / try-finally / defer / using 等机制

### 代码组织
- **DRY 原则**：相同逻辑出现 3 次以上必须抽取为公共函数/模块/组件
- **单一职责**：单个函数/方法只做一件事,逻辑复杂时拆分
- **模块边界清晰**：模块/包之间依赖方向应单向,避免循环依赖

### 全局禁用(跨语言)
- ❌ **禁止使用**已被官方标记为 deprecated / removed 的语法/API
- ❌ **禁止使用**已终止维护且无社区接管的依赖/框架
- ❌ **禁止**在支持异步的语言中强制使用同步阻塞 I/O 模式

## 九、变更后自动验证

- 前端改动 → 自动运行 `lint` + `typecheck`
- 后端改动 → 自动运行 `mvn compile`
- 不需要每次都跑完整 test suite(除非涉及逻辑修改)