lanyuanxiaoyao
93ad66bc45
- requirements: 强制至少一次用户确认；潜在冲突与待解决问题必须当场确认并归入对应章节，不得残留开放问题/TBD/待确认 - design/plan: 移除模板中'待确认事项''开放问题'章节；阶段职责改为遇到分歧或上游不完整时暂停并回退，不在本阶段向用户发起决策型提问 - apply: 所有需要用户决策的偏离统一通过 blocker.md 出口，由 blocker-revise 决定回退到哪一层 - 全局: 在 requirements instruction 头部新增'阶段职责原则'，明确用户主动参与集中在 requirements 阶段
71 lines
2.3 KiB
Markdown
71 lines
2.3 KiB
Markdown
## 代码库探索
|
||
|
||
<!-- 记录 requirements.md 未覆盖的技术探索发现，作为后续设计的依据。如果 requirements.md 中已有充分的探索结果，在此引用并仅补充缺失部分。 -->
|
||
|
||
### 已有代码与模式
|
||
|
||
<!-- 记录与本次变更相关的现有代码、组件、工具函数、架构模式；requirements.md 已覆盖则写“见 requirements.md”；无相关现有代码则写“无” -->
|
||
|
||
### 依赖状态
|
||
|
||
<!-- 记录相关依赖的安装状态、版本约束；requirements.md 已覆盖则引用；未安装的依赖需标注 -->
|
||
|
||
### 开发规范约束
|
||
|
||
<!-- 记录项目规范、代码风格、命名约定、架构模式等对设计的约束；无特殊约束则写“无” -->
|
||
|
||
## 整体方案
|
||
|
||
### 架构概览
|
||
|
||
<!-- 描述本次变更涉及的模块、组件或流程如何组织和协作，用概要方式说明为什么该方案满足 requirements.md -->
|
||
|
||
### 关键交互流程
|
||
|
||
<!-- 如果变更涉及模块间交互、API 调用、数据流变化或状态转换，在此描述关键路径；无则写“无” -->
|
||
|
||
## 目标 / 非目标
|
||
|
||
**目标：**
|
||
<!-- 记录本次技术设计要达成的目标 -->
|
||
|
||
**非目标：**
|
||
<!-- 记录明确不在范围内的内容 -->
|
||
|
||
## 关键决策
|
||
|
||
<!-- 引用 requirements.md 中已确认的技术决策，仅补充 requirements.md 未覆盖的实现层决策（如具体 API 设计、数据结构、代码组织方式） -->
|
||
|
||
| 决策 | 来源 | 理由 |
|
||
| ---- | ---- | ---- |
|
||
| <!-- 决策 --> | <!-- requirements.md T1 / 本阶段新增 --> | <!-- 理由或补充说明 --> |
|
||
|
||
## 影响范围
|
||
|
||
<!-- 记录会受影响的模块、文件、配置、接口、文档、流程或外部依赖 -->
|
||
|
||
| 范围 | 变更类型 | 原因 |
|
||
| ---- | -------- | ---- |
|
||
| <!-- 范围 --> | <!-- 新增 / 修改 / 删除 / 验证 --> | <!-- 原因 --> |
|
||
|
||
### 关键实现路径
|
||
|
||
<!-- 按优先级列出 plan.md 应首先处理的核心文件、模块或流程；简单变更可写“同上” -->
|
||
|
||
## 依赖与约束
|
||
|
||
<!-- 记录依赖限制、兼容性约束、项目规则、质量门禁和禁止事项 -->
|
||
|
||
- 依赖：
|
||
- 兼容性：
|
||
- 质量门禁：
|
||
- 禁止事项：
|
||
|
||
## 风险 / 权衡
|
||
|
||
<!-- 格式：[风险] -> 缓解措施 -->
|
||
|
||
## 验证方向
|
||
|
||
<!-- 概要说明本次变更应从哪些角度验证，作为 plan.md “验证策略”的输入 -->
|