全局约束是 AI 执行任务前必须遵守的底线。
它不解决“具体需求怎么写代码”，而是先规定什么能做、什么不能做、什么时候要先说明、什么时候必须停下来确认。
1. 修改前先说清楚
除非用户明确要求直接修改，否则 AI 修改前必须先给出简要方案：
- 修改目标是什么。
- 影响范围有哪些。
- 准备怎么改。
- 如何验证。
如果涉及多个文件或多个模块，还要先列出预计影响文件。
这条规则的目的不是拖慢执行，而是避免 AI 在没有边界判断时直接动手。
2. 先读上下文，再改代码
AI 不能只凭需求关键词猜仓库或路径。
开始前至少要确认：
- 当前项目根目录在哪里。
- 当前项目是否属于 Qmai 国际前端体系。
- 当前文件属于哪个系统、模块和业务边界。
- 是否需要联查基座、组件库、公共业务页或打印项目。
如果当前工作区看不到相关仓库，只能说明缺少上下文，不能猜本机路径。
3. 跨仓影响要先分析
这些场景不能只看当前页面：
| 场景 | 需要关注 |
|---|---|
| 菜单、登录、头部、侧栏、容器、微应用挂载 | console-vue-international |
| 多仓库共享组件、选择器、表格、上传、弹窗、组件样式 | vue-kylin-international |
| 公共业务页、公共配置、打印模板、票据模板 | common-vue-international |
| 打印插件、桥接、国际打印代码、打印通用入口 | operation |
4. 代码改动保持最小
AI 实现时遵守：
- 保持当前文件和模块已有风格。
- 不主动引入新依赖、新范式或新目录结构。
- 不做无关重构。
- 不删除错误处理、异常捕获或兼容逻辑。
- 不把临时需求名写进长期变量名。
一个需求只做一个可验证闭环，不把历史治理混进来。
5. 接口规则
如果接口文档路径包含 /sellers，默认按 /assistant 进行接口定位、联调和代码映射，除非用户明确要求保持原样。
涉及 sellerId 的接口入参、路由参数或函数透传参数时，默认不需要前端主动传递。后端会从登录态中解析。
历史代码已有 sellerId 时，不顺手治理；只有当前需求明确要求、联调确认或它已经导致问题时再处理。
6. UI、i18n 和 RTL
只要任务涉及 UI、UX、页面布局、组件视觉、后台视觉规范、长文本或 RTL，就必须先读 UI 详细设计规范。
实现时还要遵守：
- 可见文案走项目既有 i18n 方案。
- 不把中文、英文或临时文案硬编码进模板。
- 样式考虑长文本和 RTL。
- 共享组件问题优先评估组件库，不在多个业务仓库复制补丁。
7. 飞书内容先读取，再判断
用户提供飞书链接时，AI 的第一步是读取内容，再判断目标系统和仓库。
业务任务中的读取链路是：
MCP -> lark-cli -> 浏览器兜底只有三条链路都失败、权限不足或内容不可读时，才说明阻塞原因。
注意：规则中心安装或接入不属于业务内容读取，不使用浏览器或 Chrome。
8. Git 和发布不能越界
未经用户明确要求，AI 不执行：
git commitgit push- 发布或部署
国际需求开发默认从目标仓最新 pre 切出 feature/* 分支，不能直接在 pre 上改需求代码。
发布不属于默认主流程。只有任务明确进入发布或部署阶段时，才应用发布规则。
普通国际仓发布到 OPMS 平台必须走本地配置文件和 opms_release.py 脚本，不使用浏览器或 Chrome 控制发布平台。
部署 pre 的固定顺序是：
当前任务分支 -> merge 到 pre -> push origin/pre -> OPMS 部署 branch/pre不能直接部署 feature 分支，也不能把 master、main、tag 作为普通国际仓 pre 环境发布 ref。
9. 最小自查
AI 每次交付前至少自查：
- 是否明确目标系统和目标仓库？
- 是否读了必要的职责清单或 UI 规范？
- 是否只改了当前需求相关文件？
- 是否说明了验证方式？
- 是否没有擅自提交、推送或发布？
- 是否把不确定处标成“需确认”？