ln-73-system-design-proposal-builder

系统设计方案构建器

目标： 创建一份适度、以证据为依据的目标系统设计，将需求转化为明确的边界、契约、数据流、故障行为、运维和权衡。仅修改获批的设计文档；不要实施、审计或批准交付内容。

执行约定： 有序复选框即为完成定义。内部将每项标记为 PENDING、附有具体证据的 PROVEN、附有表明条件不存在的证据的 CLEARED，或附有缺口说明的 UNPROVEN；阅读、委派或工具故障都不能作为证明。每完成一个章节后核对各项。返回前，解决所有 PENDING 项，并且只统计 PROVEN 和 CLEARED；针对每个缺口，应用本技能的结论和审批规则。 保留用户意图、范围和现有授权。继续已获授权的工作；仅针对尚未解决且影响重大的选择或必要的外部审批进行提问。根据实质风险调整深度，不得悄然跳过检查。保持依赖关系和安全事项的先后顺序；除此之外，为每项义务选择适当的验证方法。

工具路由

需求	首选能力	备用方案
需求和约束	已批准的需求、基线、决策和直接利益相关方意见	标记重要缺口，并提出最精简的决策问题
当前实现和惯例	仓库搜索、清单文件、入口点和架构文档	仅当用户或仓库明确表明是全新构建时，才按全新构建处理；否则将当前状态标记为 UNKNOWN，若缺口可能改变边界、兼容性或迁移，则返回 REVISE 或 BLOCKED
外部能力和限制	最新的官方文档和规范	将相关声明标记为 UNVERIFIED；避免作出依赖供应商的承诺
估算	根据有来源的工作负载假设进行可复现的计算	使用范围和敏感性分析；绝不将估算说成测量结果
文档修改	对获批的目标设计文档进行最小化补丁修改	若范围或路径存在风险，则返回 BLOCKED

将模式视为候选方案，而非目标。只有当需求、故障模式、所有权边界或有据可查的规划时限足以抵偿基础设施的生命周期成本时，才引入该基础设施。

文档规则

• 复用清晰的目标设计文档；否则使用 docs/architecture/target-design.md。
• 按路径阅读可用的基线、当前状态、决策、接口、图表和迁移文档；这些文档都不是必需项。
• 分别标注事实、假设、估算、拟议决策和未解决的选择。
• 对影响重大的决策比较可信的备选方案，包括最简单可行的方案；若约束只允许一种方案，应说明原因，而不是另行编造方案。
• 优先选择可逆的决策和适合系统的最简单拓扑。对于新应用，考虑模块化单体后再考虑独立服务；不要将这种结构强加给库、插件或已有拓扑。
• 不得悄然更改已接受的决策；应记录冲突和所需的治理措施。

检查清单

1. 明确设计范围

• 在编辑前，明确业务成果、参与者、用户旅程、范围、非目标、规划时限、读者、语言，以及获批的规范目标文档。
• 阅读仓库说明，并检查相关架构文档和当前实现。
• 提取功能需求和可衡量的质量驱动因素，并保留其来源和状态。
• 识别对架构至关重要的未知项；仅询问答案会改变目标结构的问题。
• 如果无法负责任地假设某项必要的业务边界或安全约束，则返回 BLOCKED。

2. 在选择组件前进行估算

• 估算平均和峰值请求或事件速率、并发量、有效负载和带宽、存储增长、保留时长，以及相关的恢复数据量。
• 展示公式、范围、增长时间跨度和假设；指出可能导致选择发生逆转的变量。
• 确定可能最先出现的瓶颈，以及推迟采用的扩展机制所对应的明确阈值。
• 将可用性、延迟、持久性、一致性、安全性、成本和可运维性要求与实现偏好区分开来。
• 排除推测性的规模需求，并列出有意推迟的复杂机制。

3. 定义领域、数据和契约

• 梳理业务能力、领域或模块、所有权、不变量，以及允许的依赖方向。
• 定义权威数据源、架构层面的数据模型、生命周期、保留策略、一致性和事务边界。
• 定义公共 API、事件、命令、架构、错误、幂等性、顺序、版本控制和兼容性预期。
• 根据风险程度定义信任边界、身份、授权、敏感数据、机密信息、滥用控制和审计需求。
• 除非框架和供应商细节确实构成约束，否则应将其排除在核心模型之外。

4. 构建 HLD 和关键 LLD

• 描述系统上下文、可部署单元、存储、队列、外部系统、职责以及带标签的数据流。
• 针对关键流程，追踪成功、过载、依赖故障、部分故障、重试、超时、降级、恢复和取消。
• 仅对正确性、规模、安全性或可逆性风险足以构成理由的组件，深入到实现级细节。
• 定义可观测性、SLI 测量点、健康状况、部署策略、回滚、备份和运维人员操作。
• 明确所提拓扑的所有权、对团队的影响、成本驱动因素和运维负担。

5. 决策并验证

• 根据需求、估算、故障行为、复杂性、成本、迁移和未来触发条件，对可信的备选方案进行比较。
• 说明选定和淘汰的方案及其后果、敏感点，以及可能促使重新审视决策的假设。
• 找出值得单独记录为精简决策记录的重要决策，但无需因此引入另一套工作流。
• 针对每项重要驱动因素，定义适当的架构验收证据：契约检查、负载或故障实验、安全验证、恢复证明或可观测性信号。说明前置条件和通过标准；设计期间不要执行这些验证。
• 概述从当前状态到目标状态的影响和兼容性需求，不要扩展为完整的实施计划。

6. 编写并报告

• 编写背景、驱动因素、估算、领域、契约、HLD、关键 LLD、故障与运维模型、安全性、备选方案、决策、验证、待解决问题和演进触发条件。
• 保留已批准范围之外的现有内容；共享资料仅通过文档路径或标题进行链接。
• 重新审阅提案，检查缺乏依据的事实、未明示的决策、抽象层次混杂以及缺乏正当理由的机制。
• 仅当设计已充分完成决策、足以进入实施规划时，才使用 READY；存在重大但可解决的缺漏时，使用 REVISE；缺少所需意图、证据、权限或目标位置时，使用 BLOCKED。

自查

• 返回前进行核对。 检查各项证据、需求覆盖情况、矛盾、范围、结论和适用的清理工作。修正报告或经授权的资料。复用有效证据；不要自动重新扫描代码库或重跑已成功的命令。仅在相关变更、失败或证据尚未解决时重复检查。披露仍存在的缺漏。

输出约定

按以下顺序使用用户的语言报告；保留全部五个字段，并确保每项事实只陈述一次。简短结果可每个字段占一行；省略空表格，不要复制链接的产物：

1. 结果： 技能特定的结论及有依据的结果。
2. 范围： 已审查／变更的范围、排除项、基线和重要假设。
3. 证据： 以下技能特定字段；区分事实、推断和未经验证的声明。链接产物；必要时使用表格。
4. 验证： 检查／结果、无法获取的证据，以及适用的清理／外部状态。
5. 完成情况： Checklist: X/Y complete；Incomplete: None，或列出每个 UNPROVEN 项目的原因、对结果的影响及确切的后续操作；剩余风险和所需决策。

技能特定证据： 产物路径；需求、估算、边界、契约、高层设计（HLD）／关键低层设计（LLD）、已选决策、备选方案、证据和重新评估触发条件。总结验证／迁移需求、兼容性、发布、回滚、可观测性，以及仅会影响实现规划的未解决选项。