memind/ENGINEERING_WORKFLOW_RULES.md

标准化开发测试发布约束

1. 仓库定位

1. 本仓库是 本机 Mac 开发仓库，不是生产目录。
2. 103 是正式运行目标，105 是入口/代理层，不是源码真相所在处；不允许把它当作可直接同步或可直接 SSH 改码的开发延伸。细则见 105 服务器变更规范。

2. 开发约束

1. 每次开发都必须形成本地 Git commit。
2. 一个 commit 只解决一类问题，避免把功能、环境、运维脚本混成一团。
3. 不允许长期堆积“只有自己知道用途”的未提交改动。
4. .env、账号、密钥、运行态数据不进入 Git。

3. 测试约束

1. 任何会发布的改动，至少要有最小可复现验证。
2. 只看首页 200 不算通过，必须验证本次功能真实路径。
3. 涉及数据结构变化时，必须写清楚兼容方式、回滚方式、补数据方式。

4. 发布约束

1. 本机不允许直接 rsync 到 103 或 105。
2. 禁止 SSH 登录 105 后直接修改业务源码（含 scripts/wechat-mp-menu.mjs 等）；必须先本地 commit，再按发布流程上线。详见 105 服务器变更规范。
3. Portal 生产与测试统一走“本机构建 runtime artifact -> 打包发布”，禁止在 103 解源码包后 npm install / npm run build。
4. Portal 唯一合法生产入口是 bash scripts/release-portal-runtime-prod.sh。
5. 发布来源必须是可追溯 commit，不允许从不明工作区直接出包。
6. 发布前必须有备份，发布后必须有健康检查和业务验收。

5. 文档约束

1. 端口、主机、运行目录、发布入口发生变化时，文档必须同次更新。
2. 如果一个事故已经查明根因，要把根因和排查入口写进仓库文档，而不是只留在聊天记录里。

6. 建议长期执行的附加规范

1. 发布前要求工作区可读：git status 不能混入无关改动。
2. 为每次正式发布保留 manifest、备份包路径、验证结果。
3. 涉及数据库、计费、用户空间、鉴权的改动，要额外保留一份业务验收清单。