docs: 增加工单与原型双门禁 (#19)

Development-Workflow.-.md

@@ -7,6 +7,48 @@
 - Git 保存源码、与特定代码版本强绑定的文档，以及 Wiki 的本地镜像。
 - 本地 `docs/` 仅供浏览和审查，不是长期文档编辑入口。
 
+## 工单与设计证据双门禁
+
+开始正式实现前依次判断“是否需要工单”和“需要什么设计证据”。原型确认不能代替方案、工单、安全检查或技术验证；工单存在也不能绕过原型确认。
+
+### 先判断是否需要工单
+
+只有纯界面显示文案同时满足以下全部条件时，才可以免工单、免原型：
+
+- 只修改用户看到的组件显示名称、按钮文字、标题、提示语或其他文案；
+- 不改变业务含义、操作流程、权限、状态、接口、数据和验收结果；
+- 不涉及法律条款、安全提示、支付、金额、单位或其他高风险含义；
+- 不修改国际化键、代码组件名、类名、变量、API 字段、数据库字段或其他程序标识符；
+- 不造成明显布局、截断、换行、可访问性或支持平台问题；
+- 有任何不确定时不使用豁免。
+
+豁免修改只执行与受影响界面相称的最小检查，确认文字正确且没有明显布局或可访问性问题，然后停止。只要任一条件不满足，或涉及用户行为、样式布局、交互和导航，就建立单元任务工单。
+
+### 再判断设计证据
+
+| 修改类型 | 最低设计证据 | 正式编码门禁 |
+|---|---|---|
+| 纯显示文案且满足全部豁免条件 | 无原型 | 完成最小界面检查即可 |
+| 现有界面的小范围样式或布局调整 | 标注截图或低保真线框图；没有设计不确定性时说明复用的现有规范 | 工单确认设计证据后编码 |
+| 新组件但复用现有设计体系 | 组件状态、错误和边界说明；按需提供低保真图 | 工单确认状态和复用边界后编码 |
+| 新页面、独立用户功能、重大交互或导航变化 | Quant-UX 或其他合适工具制作的可审阅原型 | 用户确认原型和文字需求后才能编写生产代码 |
+| 后端、接口、数据处理或定时任务 | 架构、API、数据、状态或流程设计 | 用户确认技术方案后编码，不制作无意义的 UI 原型 |
+| 恢复既有确认行为的 Bug | 原设计、已确认截图、复现步骤或现有验收证据 | 确认是恢复而不是改变行为后修复 |
+
+采用最低成本、足以让用户确认的证据，不为了形式制作高保真原型。草稿原型可以用于需求讨论；草稿需要写入 Git/Wiki、多人协作或单独实施时，应建立设计任务。草稿原型和临时技术验证都不能直接作为生产实现。
+
+### 记录和重新确认
+
+需要设计证据的工单必须记录：
+
+- 原型或设计的链接、Git 路径或对应事实来源；
+- 版本、revision 或确认日期；
+- 状态：无、草稿、已确认或已废弃；
+- 确认人和确认时间；
+- 本次确认覆盖的页面、组件、流程和边界；
+- 不需要 UI 原型时采用的技术设计，或无需任何原型的原因。
+
+页面结构、主要流程、状态、权限、异常处理或验收结果变化时，先更新原型或文字需求并重新确认，再继续正式编码。只读技术检查可以在确认前进行；确需可行性代码验证时，必须由用户明确同意，隔离为不可进入生产的技术验证，不得悄悄扩展成正式实现。
 ## 一次任务怎样完成
 
 ### 1. 讨论