chore: 统一本地服务器与远程仓库源码

- 合并 main 与 master 历史并以服务器结构为基线
- 保留迁移、数据保留、AWS 账单与部署安全能力
- 建立 SDD 规格和 CI 验证闭环

docs/specs/README.md

@@ -0,0 +1,105 @@
+# AIOps 规格驱动开发规范
+
+本目录保存会改变系统行为、接口、数据或运维方式的工程规格。规格的作用是让需求、实现、测试和发布使用同一套可验证契约。
+
+## 1. 适用范围
+
+按最高影响级别判定，不以改动行数判断：
+
+| 级别 | 范围 | 必需产物 |
+|------|------|----------|
+| S0 | 文案、格式、注释、无行为变化的机械修改 | 验证记录 |
+| S1 | 局部缺陷、内部重构、单模块小改动 | 任务计划中的问题、约束和验收标准 |
+| S2 | 新功能、跨模块流程、API、配置、数据模型变更 | `docs/specs/<domain>/<slug>.md` |
+| S3 | 权限、安全、账单、迁移、数据清理、生产部署 | S2 规格 + 风险、兼容、可观测、发布、回滚 |
+
+连续开发同一能力时更新已有规格，不重复创建。纯探索或评估可以先输出调研结论；一旦进入实现，必须补齐对应级别的规格。
+
+## 2. 事实与优先级
+
+规格必须基于仓库和运行环境的真实证据。发生冲突时按以下顺序处理：
+
+1. 用户当前明确需求与已确认决策。
+2. 已接受规格中的验收标准和契约。
+3. 安全、数据保护和生产变更规则。
+4. 自动化测试表达的现有行为。
+5. 当前实现与一般文档。
+
+当前实现与规格不一致时不得自行选择其一：先确认这是缺陷、兼容要求还是规格过期，然后更新规格中的决策记录。
+
+## 3. 生命周期
+
+规格状态使用：`Draft`、`Accepted`、`Implemented`、`Verified`、`Superseded`。
+
+1. **Discover**：定位入口、调用链、数据模型、权限、外部依赖、现有测试和工作区改动。
+2. **Specify**：定义目标和非目标，用 `FR-*`、`NFR-*`、`AC-*` 编号描述行为与验收。
+3. **Design**：明确模块边界、契约、失败路径、迁移、观测和回滚，记录关键取舍。
+4. **Implement**：小步实现并保持范围受控；新增发现通过规格的决策记录显式吸收。
+5. **Verify**：建立 `AC → 测试/检查 → 结果` 的可追踪关系，覆盖成功、失败和边界路径。
+6. **Deliver**：更新状态、列出变更、验证证据、部署结果、遗留风险与后续工作。
+
+用户需求已经足够明确时，维护者可将规格标记为 `Accepted` 并继续实现。只有未决选择会改变用户可见行为、数据安全、权限或部署风险时才需要等待确认。
+
+## 4. 规格质量要求
+
+### 4.1 需求必须可验证
+
+- 使用“当……时，系统必须……”描述行为，避免“优化一下”“尽量”“支持更多”等不可验证表述。
+- 每项功能需求使用 `FR-01` 编号，每项非功能需求使用 `NFR-01` 编号。
+- 每条验收标准使用 `AC-01` 编号，并给出输入、动作和可观察结果。
+- 非目标必须明确，防止实现阶段自然扩张范围。
+
+### 4.2 契约必须先于实现
+
+- HTTP/API：路径、方法、请求、响应、错误码、鉴权、幂等和分页口径。
+- 数据：表/字段、约束、索引、默认值、迁移顺序、回填、兼容窗口和回滚限制。
+- UI：入口、权限、加载/空/错误/禁用状态、响应式行为和中英文文案。
+- 任务/事件：触发方式、重试、超时、去重、并发、状态机和审计记录。
+- 外部系统：限流、超时、部分失败、降级、凭证边界和供应商差异。
+
+### 4.3 AIOps 领域约束
+
+- 金额：原币、报告币、汇率来源、生效时间、舍入精度和汇总维度必须明确。
+- 时间：时区、采样区间、自然日/月边界、数据截止时间和缺失数据处理必须明确。
+- 监控：指标单位、标签基数、采样频率、保留期、告警迟滞和恢复条件必须明确。
+- 自动化：执行身份、目标范围、危险操作确认、超时、取消、重试和审计必须明确。
+- AI：输入数据范围、提示上下文、置信度含义、不可用降级和结果免责声明必须明确。
+
+## 5. 验证门禁
+
+验证范围随风险扩大，但至少包括受影响模块：
+
+| 变更 | 最低验证 |
+|------|----------|
+| Go 后端 | 相关 `go test`、`go vet`、`go build` |
+| React 前端 | `tsc --noEmit`、目标 ESLint、生产构建、关键页面验证 |
+| Agent | `go test ./...`、`CGO_ENABLED=0 go build`、协议兼容检查 |
+| API/跨模块 | Handler/服务测试 + 前后端契约检查 + 关键流程验证 |
+| 数据库 | 各支持方言迁移测试、幂等性、备份与回滚演练说明 |
+| 生产部署 | `/version`、迁移状态、进程/日志、关键只读接口、回滚点 |
+
+不能运行的检查必须记录具体原因和残余风险。既有失败要区分是否由本次变更引入，不能静默忽略。
+
+## 6. 完成定义
+
+只有同时满足以下条件，规格才可标记为 `Verified`：
+
+- 所有 `FR-*` 已实现，所有 `AC-*` 都有通过证据。
+- API、数据、权限、审计、错误状态和兼容行为与规格一致。
+- 相关自动化测试、静态检查和构建通过。
+- S3 已验证备份、发布、健康检查和回滚路径。
+- 用户文档、运维文档、配置示例和规格状态已同步。
+- 未完成项和已知风险已显式记录，不用模糊措辞掩盖。
+
+## 7. 文件组织
+
+```text
+docs/specs/
+├── README.md
+├── _template.md
+├── cloud/billing-normalization.md
+├── monitor/site-probe-retention.md
+└── deploy/pipeline-jenkins.md
+```
+
+文件名使用小写短横线。规格中引用代码、API、迁移和测试的实际路径。重大方向被替代时保留原规格并标记 `Superseded`，不要删除决策历史。

docs/specs/_template.md

@@ -0,0 +1,88 @@
+# <规格名称>
+
+| 字段 | 内容 |
+|------|------|
+| 状态 | Draft |
+| 级别 | S2 / S3 |
+| 负责人 | Logan.Li |
+| 创建日期 | YYYY-MM-DD |
+| 最后更新 | YYYY-MM-DD |
+| 关联任务 | <链接或说明> |
+
+## 1. 背景与证据
+
+描述当前行为、问题和触发本变更的证据，引用实际代码、接口、日志或数据。
+
+## 2. 目标与非目标
+
+### 目标
+
+- <本次必须达成的结果>
+
+### 非目标
+
+- <明确不在本次处理的事项>
+
+## 3. 用户场景
+
+- 当 <角色> 在 <条件> 下执行 <动作> 时，系统必须 <可观察结果>。
+
+## 4. 需求
+
+### 功能需求
+
+- `FR-01`：<确定、可验证的行为要求>。
+
+### 非功能需求
+
+- `NFR-01`：<性能、安全、可靠性、兼容性或可维护性要求>。
+
+## 5. 设计与契约
+
+### 模块边界
+
+说明复用点、所有权和不应新增的重复能力。
+
+### API / 事件
+
+列出路径、方法、请求、响应、错误码、权限、幂等、超时与重试。
+
+### 数据与迁移
+
+列出字段、约束、索引、默认值、回填、兼容窗口、数据量影响和迁移版本。
+
+### UI / 交互
+
+列出入口、权限、加载、空、错误、禁用、响应式和国际化状态。
+
+## 6. 风险与可观测性
+
+| 风险/失败模式 | 防护或降级 | 观测信号 |
+|---------------|------------|----------|
+| <风险> | <处理方式> | <日志/指标/任务状态> |
+
+## 7. 验收标准
+
+- `AC-01`：给定 <前置条件>，当 <动作>，则 <可观察结果>。
+- `AC-02`：给定 <异常或边界条件>，当 <动作>，则 <失败行为或降级结果>。
+
+## 8. 验证追踪
+
+| 验收标准 | 测试或检查 | 结果 |
+|----------|------------|------|
+| AC-01 | `<命令、测试名或人工步骤>` | Pending |
+| AC-02 | `<命令、测试名或人工步骤>` | Pending |
+
+## 9. 发布与回滚
+
+说明发布顺序、配置/迁移前置条件、健康检查、备份、回滚步骤和不可逆事项。S3 必填。
+
+## 10. 决策记录
+
+| 日期 | 决策 | 原因与影响 |
+|------|------|------------|
+| YYYY-MM-DD | <决定> | <依据、取舍和影响范围> |
+
+## 11. 遗留事项
+
+- <不阻塞本次验收但需要后续跟踪的工作>

docs/specs/repository/source-reconciliation.md

@@ -0,0 +1,92 @@
+# 本地、生产服务器与远程仓库源码统一
+
+| 字段 | 内容 |
+|------|------|
+| 状态 | Accepted |
+| 级别 | S3 |
+| 负责人 | Logan.Li |
+| 创建日期 | 2026-08-05 |
+| 最后更新 | 2026-08-05 |
+| 关联任务 | 以 `/srv/aiops` 为主统一本地、服务器和 Git 远程仓库 |
+
+## 1. 背景与证据
+
+本地工作区位于 `main@7a16808`，服务器工作区位于 `master@f22e575`，两端分别与对应远程分支一致，但都有大量未提交改动。内容审计发现服务器有 131 个本地不存在的源码文件，本地有 12 个服务器不存在的近期工程文件，另有 39 个同路径文件内容不同。当前生产二进制包含部分本地独有后端能力，因此直接单向覆盖任一工作区都会造成代码或可复现性丢失。
+
+## 2. 目标与非目标
+
+### 目标
+
+- 以服务器源码结构和行为为主形成唯一可构建源码。
+- 保留本地独有且已验证或已进入生产二进制的功能，不丢失近期账单、迁移、数据保留和 CI 工程能力。
+- 让远程 `master` 与 `main`、本地工作区和服务器源码指向同一提交。
+- 保留变更前完整备份，并验证构建、测试、迁移和生产健康状态。
+
+### 非目标
+
+- 不提交生产 `config.yaml`、密钥、数据库、日志、备份、运行 PID 或历史二进制。
+- 不在本次整理业务数据或执行数据库清理。
+- 不改变生产运行参数和用户凭据。
+
+## 3. 需求
+
+### 功能需求
+
+- `FR-01`：统一提交必须包含服务器权威源码和本地独有的有效工程文件。
+- `FR-02`：远程 `master` 与 `main` 必须最终解析到同一提交。
+- `FR-03`：本地和服务器的受管源码必须与统一提交一致。
+- `FR-04`：生产配置和运行数据必须保留在 Git 管理范围之外或保持未被覆盖。
+
+### 非功能需求
+
+- `NFR-01`：任何覆盖、删除或分支更新前必须生成可验证备份。
+- `NFR-02`：统一源码必须通过后端、前端和 Agent 的最低构建门禁。
+- `NFR-03`：生产服务切换后 `/version`、迁移状态、进程和错误日志必须正常。
+
+## 4. 设计与边界
+
+从 `origin/master` 创建独立 Git worktree。将服务器源码复制到该工作区，排除 `.git`、数据库、配置密钥、日志、缓存、备份、构建产物和历史二进制；再合并本地独有功能文件与本规格。测试通过后创建单一整合提交，并以普通快进或带租约保护的方式更新远程分支。
+
+本地与服务器现有工作区在对齐前分别归档。对齐时仅重置受 Git 管理的源码；生产 `config.yaml`、数据库、日志、备份和运行文件保持不变。
+
+## 5. 风险与可观测性
+
+| 风险/失败模式 | 防护或降级 | 观测信号 |
+|---------------|------------|----------|
+| 服务器重构覆盖本地功能 | 隔离合并并保留本地独有文件，构建测试后才提交 | Git diff、测试结果 |
+| 误提交生产密钥或数据 | 明确排除运行配置、数据库、日志和备份，并审计提交文件 | `git status`、提交清单 |
+| 两个远程分支历史不同 | 先保存 bundle，再统一到经过验证的整合提交 | `git ls-remote` |
+| 生产源码与二进制不一致 | 用统一源码重建 Linux 二进制并核对版本 | `/version`、二进制 SHA-256 |
+
+## 6. 验收标准
+
+- `AC-01`：给定统一提交，`origin/master` 与 `origin/main` 返回相同提交哈希。
+- `AC-02`：给定统一提交，本地和服务器受管源码执行内容校验时没有差异。
+- `AC-03`：统一源码通过 Go 后端、Agent、TypeScript、ESLint 和生产前端构建检查。
+- `AC-04`：生产服务使用统一源码构建的 Linux 二进制启动，`/version`、迁移状态和日志正常。
+- `AC-05`：生产配置、数据库、日志和备份未进入提交且未被覆盖。
+
+## 7. 验证追踪
+
+| 验收标准 | 测试或检查 | 结果 |
+|----------|------------|------|
+| AC-01 | `git ls-remote origin refs/heads/main refs/heads/master` | Pending |
+| AC-02 | 双向 `rsync --dry-run --checksum --delete`（排除运行文件） | Pending |
+| AC-03 | `go test/go vet/go build`、`tsc`、ESLint、Vite build、Agent build | Pass（2026-08-05） |
+| AC-04 | Linux 构建、`/version`、`migrate status`、进程和日志检查 | Pending |
+| AC-05 | 提交文件审计与生产文件哈希/存在性检查 | Pending |
+
+## 8. 发布与回滚
+
+发布前保存本地和服务器源码归档、Git bundle、生产二进制及数据库现有备份。若统一源码验证失败，不更新远程分支或现有工作区。若生产切换失败，恢复上一二进制并保留统一提交供离线修复。远程分支更新使用预期旧哈希或 `--force-with-lease` 防止覆盖并发提交。
+
+## 9. 决策记录
+
+| 日期 | 决策 | 原因与影响 |
+|------|------|------------|
+| 2026-08-05 | 服务器源码为结构基线，本地独有有效能力采用合并而非删除 | 服务器包含较新的组件拆分，本地包含当前生产二进制所需的新能力 |
+| 2026-08-05 | 生产配置与运行数据不纳入源码一致性 | 防止泄密和破坏运行环境 |
+
+## 10. 遗留事项
+
+- 统一完成后应使用同一主分支开发，禁止继续在生产工作区直接形成长期未提交改动。