pdlc-arch

# 架构分析 <!-- @include templates/prompts/iron-law.md（已内联于下方，无需另读） --> ⛔ **IRON LAW · 不可违反的硬门禁** 以下规则为**不可协商**的执行约束： 1. **文件必须落盘**：所有带编号（功能ID / 缺陷ID）的文档，必须作为实际文件写入磁盘，不可仅在对话中输出。 2. **阶段必须落章**：每个阶段完成后必须在状态机 `docs/.pdlc-state/<feature-id>.json` 追加 history，不可跳过。 3. **测试必须存在**：进入 `/pdlc-implement` 前，对应测试必须存在且处于红灯状态。违反则中止。 4. **自检必须执行**：段二自检为强制步骤，不得以"已经很好了"为由跳过。 5. **防循环**：段三修复为单次，不递归。无法自动修复的问题记录到报告，继续往下走。 6. **状态必推进**：成功执行某 phase 后 `current_stage` 必须变更。收尾时若发现 `current_stage` 未推进，视为失败并报错，**不得静默返回**（防止外层循环拿滞后的状态空转烧额度）。唯一例外：命中人工点主动 block 时，`current_stage` 保持不变但必须写 `last_phase_result.ok=false` + `blocked_reason`。 **违反任一条 = 立即中止当前命令，输出违规详情，等待人工介入。** <!-- @include-end templates/prompts/iron-law.md --> 对当前项目架构进行全面分析，输出架构评估报告。 ## 分析维度 ### 1. 服务拆分合理性 - 各微服务的职责边界是否清晰 - 是否存在循环依赖 - 服务粒度是否合适（过大/过小） - 数据归属是否明确 ### 2. 通信机制 - 服务间通信方式（同步REST/gRPC、异步消息队列） - 是否存在分布式事务问题 - 接口版本管理策略 - 错误传播和容错机制 ### 3. 数据架构 - 数据库拆分策略（每服务独立数据库 vs 共享） - 数据一致性方案 - 缓存策略 - 数据备份与恢复 ### 4. 可观测性 - 日志规范（结构化日志、链路追踪ID） - 监控指标（RED指标：Rate/Errors/Duration） - 告警策略 - 分布式追踪 ### 5. 可扩展性 - 水平扩展能力 - 负载均衡策略 - 容量规划 ## 工作流程 > **架构总览是 surface 型产物**：`docs/ARCHITECTURE.md` 描述"系统当前长什么样"，**就地覆盖更新**，不按日期累积多份文件。演进历史靠 `git log docs/ARCHITECTURE.md` 追溯。这与 per-feature 的 `docs/02_design/architecture/F-xxx-arch.md`（ledger 型，记录"为某个 feature 为什么改架构"）分工互补。 1. 扫描 `backend/` 和 `frontend/` 下的所有服务和应用 2. 阅读 `docs/02_design/architecture/` 下的 per-feature 架构 ledger（若有） 3. 分析代码中的依赖关系和调用链路 4. **遗留检测**：若发现旧版按日期命名的 `*-arch-analysis.md`（散落在 `docs/02_design/ar...