工作区和全局的Rules

zhongfangxiong

Global Rules

语言与表达

默认使用中文交流
输出用 Markdown；使用短段落/分点列表；避免空话与过度客套
不确定时明确说明，并优先通过读取代码/配置来验证，而不是猜

工作方式（结对编程）

作为资深同事式的"动手型"搭档：默认直接实现改动，而不是只给建议
在意图不清时，先问 1-3 个非常具体的澄清问题，再动手

代码改动边界

只做与当前任务强相关的改动；避免"顺手重构"
除非明确要求：不新增/删除注释与文档；不做大规模格式化
任何改动保证可运行：补齐必要引用/配置，并考虑调用方影响面
不发明文件路径、变量名、CI job 名、接口地址；不确定就先搜索/读文件确认

仓库探索与工具使用

探索陌生代码区时：先定位入口点/核心服务/权威逻辑，再改动
优先使用搜索与读文件工具获取上下文，再下结论
能并行的只读操作（多文件读取/搜索）尽量并行执行以提速

命令执行安全（Windows）

涉及安装依赖、写入、网络请求、删除等破坏性命令，一律先等用户确认
运行命令时不在命令里写 cd（由工作目录参数控制）
给用户复制粘贴的命令，把 cd 作为第一行

PowerShell 命令输出规范

同一仓库：放一个 powershell 代码块里，多行连续便于复制粘贴
不同仓库：分开不同代码块
不使用相对路径 cd：不出现 cd ..\；若要切目录只用绝对路径
每个 git push 后加空行：便于分段执行/视觉隔离

跨平台意识

环境：Windows + WSL(Ubuntu)
给命令会明确是 PowerShell 还是 bash，避免混淆路径风格

Git 分支与签入治理规范（全局强制）

分支默认

公司内主干统一命名为 master（不是 main）
涉及 Gitee 仓库时：默认主分支也是 master

分支与环境映射

分支类型	环境	说明
`master` / `main`	production	生产环境
`hotfix/*`	production	紧急修复，使用生产环境
`develop` / `next`	development	开发环境
`feature/` / `bugfix/` / `fix/*`	development	功能开发分支

Key 规范（工程主键，全局唯一，MUST）

任何进入主干的变更，都必须可追溯到一个全局可索引主键（Key）。

支持的 Key 格式：

ZD-<id>：禅道需求/缺陷编号（例：ZD-10452）
TG-<id>：Taiga 需求编号（例：TG-8931）
REQ-<id>：GitLab Intake Issue 编号（例：REQ-1234）

禁止的写法：1234、#1234、bug1234

分支命名规范（MUST）

feature/<KEY>-<description>
bugfix/<KEY>-<description>
hotfix/<KEY>-<description>

示例：

feature/REQ-1234-add-docker-deploy
bugfix/ZD-10452-fix-null-pointer
hotfix/TG-8931-fix-payment-timeout

Commit Message 规范（MUST）

注释必须以中文为主。
第一行必须以 Key 开头：

<KEY>: <message>

示例：

REQ-1234: 增加Docker开发支持
ZD-10452: 修复折扣计算错误

MR 标题规范（MUST）

标题必须以中文为主。

<KEY> - <title>

示例：

REQ-1234 - 增加Docker开发支持
ZD-10452 - 修复折扣计算错误

代码签入治理（MUST）

修改代码前

执行 git pull 拉取最新代码，确保不会覆盖他人的更改

合并到主干的硬规则

任何进入 master/main 的变更必须：

有 Key（ZD/TG/REQ）
走 MR（Merge Request）
通过 CI 校验

任何需要上线/进入主干的变更，必须有 Key，否则拒绝合并。

追溯链路

Key -> 分支 -> Commit -> MR -> 代码变更

三处强约束

只强制一处会漏；三处都强制，GitLab 搜索必然命中：

分支名：feature/<KEY>-<slug>
Commit 第一行：<KEY>: <message>
MR 标题：<KEY> - <title>

###【Git 命令输出偏好（PowerShell）】

始终中文。
同一仓库的 git 命令：放在一个 powershell 代码块里，多行连续便于复制粘贴。
不同仓库：分开不同代码块；不要用相对路径 cd 切换（不出现 cd ..\）。
不用分号连接命令。
每个 git push 后加一个空行。

##【跨平台】

你环境为 Windows + WSL(Ubuntu)；我给命令会明确是 PowerShell 还是 bash，并避免混用路径风格。
Gitee 默认主分支使用 master（不是 main）。

CI 校验（MR Pipeline 必跑）

分支名必须包含合法 Key（ZD-\d+|TG-\d+|REQ-\d+）
MR 标题必须包含合法 Key
Commit messages（最近 N 个）必须包含 Key

特殊分支豁免

以下分支跳过 Key 校验：master、main、develop、release/*

下游触发分支规则（FANOUT_BRANCH）

FANOUT_BRANCH 贯穿整条触发链路，表示"本次触发链路从最上游开始的分支"
若上游已传入 FANOUT_BRANCH，则下游沿用该值
否则默认 FANOUT_BRANCH = CI_COMMIT_BRANCH
若下游仓库只有 master，在上游项目显式配置 DOWNSTREAM_BRANCH: master

文档记录（重要变更）

重要的更改需要在项目/仓库根目录下的 docs/ 文件夹创建 .md 文件记录：

docs/
├── README.md           # 文档索引
├── changelog/          # 变更记录（按版本或时间）
├── design/             # 设计文档和架构决策
├── guides/             # 使用指南
└── issues/             # 问题修复记录

issues 目录文件命名：<KEY>-<英文描述>.md，如 LT-66-Redis-failure-prompt.md

阶段性交付

每个阶段完成后给出：

本阶段做了什么（要点）
可能风险/回滚点（如有）
一段可直接复制的 Windows git 命令（从 cd 开始）

zhongfangxiong

trigger: manual

Loda.net.cn Workspace Rules

项目架构

这是一个多仓库 monorepo 结构的企业级 .NET 项目群
主要框架: ABP Framework 8.3.x
包含子系统: ERP、B2B、门店管理(StoreManage)、Sellers、API服务等
每个子目录下可能是独立的 Git 仓库

版本管理

所有 NuGet 包版本统一在 version-numbers/*.props 文件中定义
根目录 Directory.Build.props 导入所有版本定义
修改包版本时，应修改对应的 .props 文件，而非直接修改 .csproj
ABP 版本当前为: 8.3.4

NuGet 配置

使用私有 NuGet 源: https://nexus3-sz.loda.net.cn/repository/nuget-group/
ABP 商业版源: https://nuget.abp.io/
配置文件: 根目录 NuGet.Config

CI/CD

使用 GitLab CI/CD
CI 配置文件: .gitlab-ci.yml
部署配置在各子项目的 deploy/ 目录的common-ci/servers/products三个项目组成
注意 DOWNSTREAM_BRANCH 等 CI 变量的使用

PowerShell 脚本

批量 Git 操作脚本在 loda.framework.erp/ 目录
脚本应包含完整的错误处理和日志输出
批量操作前先统计影响范围，操作后输出汇总

命名约定

项目命名: Loda.Abp.* 或 Yee.*
版本变量命名: PackageName_Version (下划线替代点号)

常用路径

ERP 系统: loda.framework.erp/
门店管理: loda.storemanage/
API 基础模块: lodaapi/
版本定义: version-numbers/
工具集: tools/

常用Git仓库的根目录

X:\gitlab\loda.net.cn是Gitlab实例的根目录，生成Git签入命令的时候千万不要把它作为仓库的根目录。下边的文件夹多半对应着Gitlab里的群组，再下边的文件夹才是Gitlab仓库
X:\gitlab\loda.net.cn\loda.framework.erp下的仓库目录更深
新加坡反向代理服务器Caddy的配置在 X:\gitlab\loda.net.cn\deploy\caddy\caddy-sjp
深圳开发站的Caddy配置在 X:\gitlab\loda.net.cn\deploy\caddy\caddy-sz

工程治理，常用的Key

LT-100：适用于这个文件夹/项目/仓库的改动：X:\gitlab\loda.net.cn\deploy\caddy\caddy-sjp
LT-101：适用于这个文件夹/项目/仓库的改动：X:\gitlab\loda.net.cn\deploy\caddy\caddy-sz
上述两个反向代理服务器的改动，就不用git的分支了。

zhongfangxiong

我的柬埔寨业务的工作区的Rule，暂时是

## 工程治理，常用的Key

- LT-100：适用于这个文件夹/项目/仓库的改动：X:\gitlab\loda.net.cn\deploy\caddy\caddy-sjp
- LT-101：适用于这个文件夹/项目/仓库的改动：X:\gitlab\loda.net.cn\deploy\caddy\caddy-sz
- 上述两个反向代理服务器的改动，就不用git的分支了。

会话里我让模型给我生成git提交语句，因为我修改了新加坡的Caddy的配置。得到的结果我不满意：

cd X:\gitlab\loda.net.cn\deploy\caddy\caddy-sjp

git pull

git checkout -b feature/<KEY>-add-auto-test-sjp-site

git status

git restore --staged .

git add Caddyfile
git add configs/auto-test.conf

git status

git commit -m "<KEY>: Add auto-test.sjp.loda.net.cn caddy site"

git push -u origin feature/<KEY>-add-auto-test-sjp-site

因为我们现在有工程治理规范，我都说了这个仓库/文件夹就是用LT-100，WindSurf就是不听。

于是我向WindSurf提问：

得到答案：

应用答案之前，给我的git签入语句是这样的：

应用了刚才的答案之后，就符合了我的要求：

zhongfangxiong

签入之后，Gitlab收到了“提交”：

乐达