# 维护与自动同步

## 沟通与范围

- 用中文大白话，先给结论；区分本地代码、GitHub main、Release 包和用户实际安装版本。
- 不修改无关应用、浏览器页面、VPN/TUN 或用户凭据。
- GitHub 状态以当次核验为准；本地引用和历史记录不能代替在线检查。

## 已启用的同步规则

用户已授权以下流程，不需要在用户确认修好后另问一次“是否推送”：

1. 修改本次问题涉及的源码，运行 `pnpm run check`，按问题需要做运行验证。
2. 将实际效果交由用户确认。“修好了”“现在正常了”等明确针对本次修复的反馈才算确认；测试通过、沉默和对未来方案的同意不算运行确认。
3. 确认后审阅差异，列出本次修改及其构建产物的具体文件。执行 `pnpm run sync -- --confirmed --message "fix: 描述本次修复" --files 文件1 文件2 ...`。脚本重新检查后提交并推送 main。
4. 核实远端提交和对应 GitHub Actions，报告提交编号及检查状态。不要把“已推送”说成“云端检查通过”。

`--confirmed` 表示维护者已收到用户确认，脚本不会读取聊天，也不会在后台监视文件。没有确认时可以修复和检查，但不能用该开关跳过用户确认。

仅修改维护脚本、文档或检查流程时，本次用户对该维护工作的明确授权即可用于同步，不要求用户重测皮肤界面。

脚本拒绝已有暂存内容、其他未纳入的改动、本地与远端不一致、检查失败和错误仓库。遇到这些情况先核实并隔离或处理，不强推、不自动重写历史。推送异常时先查询远端是否已经包含该提交；本地提交保留，核实后才重试。

## 发布版本

普通同步只推送代码，触发 Check。新安装包需另外更新版本和 CHANGELOG，检查版本号与 `v版本号` 标签一致，再按用户对发布的授权推送该标签，核实 Release 完成及资产存在。仅修改维护工具不提升插件版本、不创建发布标签。