jsharness 1.0.0

package/.harness/docs/team-guidelines/arch-team.md

@@ -0,0 +1,811 @@
+# 架构与技术方案组 Harness 使用规范
+
+> **适用角色**: 架构师、技术负责人、高级工程师、方案设计师  
+> **对应 Agent**: 方案设计师 Agent (solution-designer) + 闸门总控 Agent (gate-controller)  
+> **模型档位**: Standard（方案设计）/ Strong（闸门评估）  
+> **参考契约**: `.harness/agents/solution-designer/contract.yaml` + `.harness/agents/gate-controller/contract.yaml`  
+> **核心产出**: 设计文档 / API 定义 / ADR 决策记录 / 可行性报告  
+
+---
+
+## 一、角色定位：你是技术方向的掌舵人
+
+### 1.1 双重身份
+
+```
+┌──────────────────────────────────────────────────┐
+│            架构/技术负责人的双重身份                │
+├────────────────────┬─────────────────────────────┤
+│  📐 方案设计师       │  🚧 闸门总控                  │
+│  (Solution Designer)│  (Gate Controller)           │
+├────────────────────┼─────────────────────────────┤
+│ 输出技术方案         │ 评估可行性                    │
+│ 定义接口和数据模型    │ 识别和分类风险                │
+│ 做技术选型决策        │ 做 PASS/BLOCK/HOLD 裁决      │
+│ 撰写 ADR            │ 保护系统安全性和稳定性         │
+│ 指导开发实现         │ 把控技术债务                  │
+└────────────────────┴─────────────────────────────┘
+```
+
+**重要原则**：
+- 方案设计师负责「怎么做好」，闸门总控负责「能不能做」
+- 两个角色应由不同人员担任，避免自我审查
+- 闸门裁决具有强制力，方案设计师必须服从 BLOCK 结论
+
+### 1.2 绝对禁止做的事
+
+| # | 禁止行为 | 适用角色 | 后果 |
+|---|---------|---------|------|
+| 1 | **在不做可行性评估的情况下批准高风险方案** | 闸门总控 | 事故追责 |
+| 2 | **BLOCK 裁决不给解除条件** | 闸门总控 | 裁决无效 |
+| 3 | **方案设计不考虑 dev-map 现有约定** | 方案设计师 | 打回重做 |
+| 4 | **接口定义不够详细就让开发开始** | 方案设计师 | 开发返工 |
+| 5 | **技术选型不做对比分析就直接决定** | 方案设计师 | 需要 ADR 补充 |
+| 6 | **出于个人偏好否决可行方案** | 闸门总控 | 申诉复核 |
+| 7 | **忽略安全红线通过方案** | 两者均适用 | 安全事故连带责任 |
+
+---
+
+## 二、方案设计师工作规范
+
+### 2.1 ② 方案设计阶段 — 标准工作流
+
+```
+收到需求文档 + 验收标准
+    │
+    ▼
+① 深度阅读需求（理解业务目标和约束）
+    │
+    ▼
+② 研究 dev-map（现有架构、模式、约束）
+    │
+    ▼
+③ 技术调研（新技术/新方案需要 POC）
+    │
+    ▼
+④ 设计方案（架构 + 接口 + 数据模型）
+    │
+    ▼
+⑤ 编写设计文档（design-{id}.md）
+    │
+    ▼
+⑥ 编写 API 定义（api-definition.yaml）
+    │
+    ▼
+⑦ 编写数据模型设计（data-model.md）
+    │
+    ▼
+⑧ 如有新技术决策 → 编写 ADR
+    │
+    ▼
+⑨ 影响面分析和风险评估
+    │
+    ▼
+⑩ 自审后提交 → 进入闸门评估
+```
+
+### 2.2 设计文档模板
+
+```markdown
+# 技术设计文档: {任务名称}
+
+## 元信息
+- **文档版本**: v1.0
+- **作者**: {姓名}
+- **日期**: YYYY-MM-DD
+- **关联需求**: requirements-{id}.md
+- **状态**: 草稿/评审中/已批准/已废弃
+
+## 1. 背景与目标
+
+### 1.1 业务背景
+{为什么要做这个功能？解决什么业务问题？}
+
+### 1.2 技术目标
+{技术上要达成什么？性能？可用性？可扩展性？}
+
+### 1.3 约束条件
+- 时间约束: {上线时间要求}
+- 资源约束: {人力/硬件/预算}
+- 兼容性约束: {必须兼容的系统/浏览器}
+- 技术债务约束: {需要同时处理的技术债}
+
+## 2. 整体架构设计
+
+### 2.1 架构图
+```mermaid
+graph TB
+    subgraph Frontend["前端层"]
+        A[页面组件]
+        B[状态管理]
+        C[API Client]
+    end
+    
+    subgraph Backend["后端层"]
+        D[Controller]
+        E[Service]
+        F[Repository]
+    end
+    
+    subgraph Data["数据层"]
+        G[(MySQL)]
+        H[(Redis)]
+    end
+    
+    A --> B --> C --> D --> E --> F --> G
+    E --> H
+```
+
+### 2.2 技术选型（如有新技术）
+| 选型项 | 选择方案 | 替代方案 | 选择理由 |
+|-------|---------|---------|---------|
+| 状态管理 | Zustand | Redux Toolkit | 更轻量，适合当前规模 |
+| ... | ... | ... | ... |
+
+> 详细选型分析见 ADR-{编号}
+
+### 2.3 模块划分
+| 模块 | 职责 | 涉及文件 |
+|-----|------|---------|
+| auth | 认证授权 | src/features/auth/** |
+| user | 用户管理 | src/features/user/** |
+
+## 3. 接口设计
+
+### 3.1 API 定义（详见 api-definition.yaml）
+
+### 3.2 数据流
+```mermaid
+sequenceDiagram
+    participant FE as 前端
+    participant API as API Gateway
+    participant SVC as 业务服务
+    participant DB as 数据库
+    
+    FE->>API: POST /api/users
+    API->>SVC: createUser(req)
+    SVC->>DB: INSERT INTO users...
+    DB-->>SVC: 用户数据
+    SVC-->>API: UserDTO
+    API-->>FE: 201 + UserResponse
+```
+
+## 4. 数据模型设计
+
+### 4.1 ER 图 / 表结构
+（详见 data-model.md）
+
+### 4.2 状态机（如有）
+```mermaid
+stateDiagram-v2
+    [*] --> Pending: 创建
+    Pending --> Active: 激活
+    Active --> Suspended: 暂停
+    Suspended --> Active: 恢复
+    Active --> [*]: 关闭
+```
+
+## 5. 关键实现逻辑
+
+### 5.1 核心算法/流程
+{用文字描述关键的实现思路，不含具体代码}
+
+### 5.2 异常处理策略
+| 异常类型 | 处理方式 | 用户提示 |
+|---------|---------|---------|
+| 参数校验失败 | 400 + 错误详情 | 请检查输入 |
+| 未授权 | 401 | 请先登录 |
+| 并发冲突 | 409 + 重试提示 | 请稍后重试 |
+| 服务不可用 | 503 + 降级策略 | 服务繁忙 |
+
+## 6. 影响面分析
+
+### 6.1 影响的现有模块
+| 模块 | 影响类型 | 影响程度 | 兼容措施 |
+|-----|---------|---------|---------|
+| 用户模块 | 接口变更 | 高 | 版本化 API |
+| 订单模块 | 数据依赖 | 中 | 数据迁移脚本 |
+
+### 6.2 需要同步修改的内容
+- [ ] 前端路由配置
+- [ ] API 文档
+- [ ] 数据库迁移脚本
+- [ ] dev-map 更新
+
+## 7. 安全考虑
+
+### 7.1 认证与授权
+- 接口鉴权方式: JWT Bearer Token
+- 权限控制: RBAC（角色：admin/user/guest）
+- 敏感操作: 需要二次确认/MFA
+
+### 7.2 数据安全
+- 敏感字段加密: 密码 bcrypt、手机号脱敏
+- 传输加密: HTTPS 强制
+- 日志脱敏: 不记录敏感字段原文
+
+### 7.3 安全测试要求
+- [ ] OWASP Top 10 检查
+- [ ] 权限越权测试
+- [ ] SQL 注入/XSS 测试
+
+## 8. 性能考量
+
+### 8.1 性能目标
+| 指标 | 目标值 | 测量方法 |
+|-----|-------|---------|
+| API P99 响应时间 | < 200ms | APM 监控 |
+| 页面首屏加载 | < 1.5s | Lighthouse |
+| 并发支持 | 100 QPS | 压测工具 |
+
+### 8.2 优化策略
+- 缓存策略: Redis 热点数据缓存
+- 数据库优化: 索引设计 + 查询优化
+- 前端优化: 懒加载 + 虚拟滚动
+
+## 9. 测试策略
+
+### 9.1 单元测试要点
+- 核心业务逻辑 100% 覆盖
+- 工具函数 90%+ 覆盖
+
+### 9.2 集成测试要点
+- API 契约测试
+- 数据库事务测试
+
+### 9.3 E2E 测试要点
+- 核心用户路径全覆盖
+
+## 10. 部署计划
+
+### 10.1 部署步骤
+1. 数据库迁移执行
+2. 后端服务灰度发布
+3. 前端资源部署
+4. 全量切流量
+
+### 10.2 回滚方案
+- 前端: CDN 版本回退
+- 后端: K8s 回滚到上一版本
+- 数据库: 回滚 migration（如需要）
+
+## 11. 风险与缓解
+
+| 风险 | 概率 | 影响 | 缓解措施 | 负责人 |
+|-----|------|------|---------|-------|
+| 技术方案复杂度高 | 中 | 高 | 先做 POC 验证 | {姓名} |
+| 第三方 API 变更 | 低 | 中 | 抽象适配层 | {姓名} |
+| 数据迁移量大 | 中 | 中 | 分批迁移 + 验证 | {姓名} |
+
+## 12. 开放问题
+（如有未解决的问题，在此列出）
+- [ ] 问题1：{描述} — 决策截止：{日期}
+- [ ] 问题2：{描述} — 决策截止：{日期}
+
+---
+
+## 附录
+- A. API 完整定义: api-definition.yaml
+- B. 数据模型: data-model.md
+- C. ADR 列表: ADR-XXX
+```
+
+### 2.3 API 定义规范（OpenAPI YAML 格式）
+
+```yaml
+openapi: 3.0.3
+info:
+  title: {任务名称} API
+  version: 1.0.0
+  description: {简述}
+
+paths:
+  /api/v1/users:
+    get:
+      operationId: listUsers
+      summary: 获取用户列表
+      tags:
+        - Users
+      parameters:
+        - name: page
+          in: query
+          required: false
+          schema:
+            type: integer
+            minimum: 1
+            default: 1
+        - name: pageSize
+          in: query
+          required: false
+          schema:
+            type: integer
+            minimum: 1
+            maximum: 100
+            default: 20
+      responses:
+        '200':
+          description: 成功
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserListResponse'
+        '401':
+          $ref: '#/components/responses/Unauthorized'
+        '500':
+          $ref: '#/components/responses/InternalServerError'
+
+    post:
+      operationId: createUser
+      summary: 创建用户
+      tags:
+        - Users
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateUserRequest'
+      responses:
+        '201':
+          description: 创建成功
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '400':
+          $ref: '#/components/responses/BadRequest'
+        '409':
+          description: 用户已存在
+
+components:
+  schemas:
+    UserResponse:
+      type: object
+      required:
+        - id
+        - username
+        - email
+        - createdAt
+      properties:
+        id:
+          type: string
+          format: uuid
+          example: "550e8400-e29b-41d4-a716-446655440000"
+        username:
+          type: string
+          minLength: 3
+          maxLength: 32
+          pattern: "^[a-zA-Z0-9_]+$"
+        email:
+          type: string
+          format: email
+        createdAt:
+          type: string
+          format: date-time
+
+    CreateUserRequest:
+      type: object
+      required:
+        - username
+        - email
+        - password
+      properties:
+        username:
+          type: string
+          minLength: 3
+          maxLength: 32
+        email:
+          type: string
+          format: email
+        password:
+          type: string
+          minLength: 8
+          format: password
+          description: 至少8位，包含大小写字母和数字
+
+    UserListResponse:
+      type: object
+      properties:
+        data:
+          type: array
+          items:
+            $ref: '#/components/schemas/UserResponse'
+        pagination:
+          $ref: '#/components/schemas/PaginationInfo'
+
+  responses:
+    Unauthorized:
+      description: 未授权
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/ErrorResponse'
+    BadRequest:
+      description: 请求参数错误
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/ErrorResponse'
+    InternalServerError:
+      description: 服务器内部错误
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/ErrorResponse'
+
+    ErrorResponse:
+      type: object
+      properties:
+        code:
+          type: string
+        message:
+          type: string
+        details:
+          type: array
+          items:
+            type: string
+    PaginationInfo:
+      type: object
+      properties:
+        page:
+          type: integer
+        pageSize:
+          type: integer
+        total:
+          type: integer
+        totalPages:
+          type: integer
+```
+
+### 2.4 ADR（Architecture Decision Record）模板
+
+```markdown
+# ADR-{编号}: {决策标题}
+
+## 状态
+{提议/已采纳/已废弃/已被替代}
+
+## 上下文
+{描述驱动这个决策的情况和问题}
+
+## 决策
+{我们决定了什么，简洁明了}
+
+## 备选方案
+
+### 方案 A: {名称}
+- 优点: ...
+- 缺点: ...
+
+### 方案 B: {名称} ← 选中
+- 优点: ...
+- 缺点: ...
+
+### 方案 C: {名称}
+- 优点: ...
+- 缺点: ...
+
+## 理由
+{为什么选择了方案 B 而不是其他方案}
+
+## 后果
+### 正面影响
+...
+
+### 负面风险
+...（以及如何缓解）
+
+### 中立
+...
+
+## 相关决策
+- ADR-{编号}: {相关决策}
+
+---
+- **决策日期**: YYYY-MM-DD
+- **决策人**: {姓名}
+- **参与者**: {相关人员名单}
+```
+
+---
+
+## 三、闸门总控工作规范
+
+### 3.2 ③ 闸门评估阶段 — 标准工作流
+
+```
+收到需求文档 + 设计文档
+    │
+    ▼
+① 全面阅读需求 + 设计
+    │
+    ▼
+② 运行 Gate 快速检查（如有）
+    │
+    ▼
+③ 可行性评估
+    │
+    ├─ 技术可行性
+    ├─ 资源可行性
+    ├─ 时间可行性
+    └─ 风险可行性
+    │
+    ▼
+④ 风险识别与分类
+    │
+    ├─ 阻塞风险（BLOCK 条件）
+    ├─ 暂停风险（HOLD 条件）
+    └─ 一般风险（需缓解措施）
+    │
+    ▼
+⑤ 做出裁决
+    │
+    ├── PASS → 进入开发实现
+    ├── BLOCK-to-design → 打回方案设计修改
+    ├── BLOCK-to-requirements → 打回需求澄清
+    ├── BLOCK-cancel → 取消需求
+    └── HOLD → 暂停等待
+    │
+    ▼
+⑥ 输出可行性报告 + 裁决决定
+```
+
+### 3.3 裁决标准详述
+
+#### PASS（放行）—— 必须满足全部条件
+
+| # | 条件 | 检查方式 |
+|---|------|---------|
+| 1 | 无阻塞风险 | 风险评估表 |
+| 2 | 所有中高风险都有缓解措施 | 风险缓解计划 |
+| 3 | 验收标准清晰可测 | 需求文档审查 |
+| 4 | 技术方案覆盖所有需求 | 设计 vs 需求对照 |
+| 5 | 安全红线无违反 | 安全检查清单 |
+| 6 | 资源估算合理 | 工作量评估 |
+| 7 | 无根本性架构冲突 | 架构评审 |
+
+#### BLOCK（阻止推进）—— 任一即触发
+
+##### BLOCK-to-design（方案有问题）
+
+| 触发条件 | 示例 |
+|---------|------|
+| 方案存在明显的架构缺陷 | 单点故障无冗余设计 |
+| 性能目标在技术上无法达成 | 要求 1ms 响应但网络延迟就有 10ms |
+| 安全设计有重大遗漏 | 无认证机制的设计 |
+| 技术选型缺乏论证 | 引入全新技术栈但无 POC |
+
+**必须附带解除条件**：
+```markdown
+## BLOCK 裁决: 方案需修改
+
+### 裁决理由
+方案中使用 WebSocket 做实时推送，但在移动端弱网环境下
+可靠性不足，且没有离线消息队列机制。
+
+### 解除条件
+1. 补充离线消息存储 + 重连恢复机制的设计
+2. 或者改为 SSE + 轮询降级的混合方案
+3. 补充弱网环境下的测试策略
+
+### 重新评估触发条件
+修改完成后重新提交闸门评估
+```
+
+##### BLOCK-to-requirements（需求有问题）
+
+| 触发条件 | 示例 |
+|---------|------|
+| 需求本身矛盾或不可实现 | 同时要求"实时"和"零延迟"但无预算上专用通道 |
+| 需求范围不清导致无法评估 | "做一个好的搜索功能"太模糊 |
+| 验收标准不可测试 | "用户体验好"不是可测的标准 |
+| 商业目标与技术现实冲突 | "一周内从零搭建一个淘宝" |
+
+##### BLOCK-cancel（根本不可行）
+
+| 触发条件 | 示例 |
+|---------|------|
+| 技术上永远不可能 | 违反物理定律的需求 |
+| 资源永远不可能满足 | 需要 100 人月但只有 2 人 |
+| 与战略方向根本冲突 | 要做的产品公司已经决定不做 |
+
+#### HOLD（暂停等待）
+
+| 触发条件 | 典型场景 | 等待什么 |
+|---------|---------|---------|
+| 需要 POC 验证 | 引入未知的新技术 | POC 结果 |
+| 等待外部审批 | 涉及第三方合同 | 审批结果 |
+| 等待资源到位 | 核心开发人员被借调 | 人员释放 |
+| 优先级调整 | 有更高优先进来了 | PM 确认优先级 |
+
+### 3.4 可行性报告模板
+
+```markdown
+# 可行性评估报告: {任务名称}
+
+## 基本信息
+- **任务ID**: TASK-YYYY-NNN
+- **闸门评估人**: {姓名}
+- **评估日期**: YYYY-MM-DD
+- **裁决结果**: ✅ PASS / 🚫 BLOCK / ⏸️ HOLD
+
+## 一、需求理解确认
+
+### 1.1 业务目标
+{确认理解的业务目标}
+
+### 1.2 核心需求清单
+| # | 需求 | 优先级 | 复杂度 | 方案覆盖 |
+|---|------|-------|-------|---------|
+
+### 1.2 疑点记录（如有）
+{对需求的疑问和假设}
+
+## 二、方案评审
+
+### 2.1 架构合理性评估
+- [ ] 整体架构清晰合理
+- [ ] 模块划分粒度适当
+- [ ] 接口定义完整准确
+- [ ] 数据模型设计合理
+- [ ] 符合 dev-map 现有约定
+
+### 2.2 技术选型评估
+| 选型项 | 方案选择 | 评价 | 风险 |
+|-------|---------|------|------|
+| ... | ... | ... | ... |
+
+### 2.3 扩展性与可维护性
+- [ ] 支持未来可能的扩展方向
+- [ ] 代码组织便于维护
+- [ ] 技术债务可控
+
+## 三、风险评估
+
+### 3.1 风险清单
+| ID | 风险描述 | 概率 | 影响 | 等级 | 缓解措施 | 负责人 |
+|----|---------|------|------|------|---------|-------|
+| R1 | ... | 高/中/低 | 高/中/低 | 高/中/低 | ... | ... |
+
+### 3.2 阻塞风险（BLOCK 条件）
+（如有，详细列出）
+
+### 3.3 技术债务评估
+- 现有技术债务是否会影响此方案？
+- 此方案是否会增加新的技术债务？
+
+## 四、资源评估
+
+### 4.1 工作量估算
+| 阶段 | 估时 | 人力 | 依赖 |
+|-----|------|------|------|
+| 方案设计 | X天 | X人 | - |
+| 开发实现 | X天 | X人 | 设计完成 |
+| 测试验证 | X天 | X人 | 开发完成 |
+| **总计** | **X天** | | |
+
+### 4.2 资源缺口（如有）
+| 资源类型 | 需求 | 现状 | 缺口 | 解决方案 |
+|---------|------|------|------|---------|
+
+## 五、安全评估
+
+### 5.1 安全检查清单
+| 检查项 | 状态 | 备注 |
+|-------|------|------|
+| 认证机制完备 | ✅/❌ | |
+| 授权控制合理 | ✅/❌ | |
+| 数据加密传输 | ✅/❌ | |
+| 敏感数据保护 | ✅/❌ | |
+| 注入防护 | ✅/❌ | |
+| 依赖安全 | ✅/❌ | CVE 检查结果 |
+| 日志脱敏 | ✅/❌ | |
+
+### 5.2 合规要求（如有）
+- GDPR / 等保 / PCI-DSS 等
+
+## 六、裁决结论
+
+### 裁决: ✅ PASS / 🚫 BLOCK / ⏸️ HOLD
+
+### 裁决理由
+{详细的书面理由}
+
+### 解除/下一步条件（BLOCK/HOLD 时必填）
+{如果 BLOCK 或 HOLD，必须给出明确的解除条件}
+
+### 风险告知
+{向 PM 和团队明确传达的关键风险}
+
+---
+
+**签署**
+- 闸门评估人: _______________ 日期: _______
+```
+
+---
+
+## 四、dev-map 维护责任
+
+### 4.1 架构组的特殊维护义务
+
+除了常规的代码同步更新外，架构组还负责：
+
+| 维护项 | 频率 | 内容 |
+|-------|------|------|
+| ADR 记录 | 每次技术决策时 | 记录决策背景、选项、理由 |
+| overview.md 更新 | 架构变更后 | 更新技术栈总览和架构图 |
+| decisions.md 维护 | 每次决策后 | 追加新的 ADR 索引 |
+| 架构原则文档 | 季度 Review | 更新设计原则和最佳实践 |
+
+### 4.2 架构治理
+
+每季度执行架构 Review：
+- [ ] 技术债务盘点
+- [ ] 架构偏离度检查（实际 vs 设计）
+- [ ] 技术栈健康度评估
+- [ ] dev-map 准确性抽查
+- [ ] Rule/Skill 配置优化
+
+---
+
+## 五、绩效考核关联指标
+
+| 指标 | 目标值 | 权重 | 数据来源 |
+|-----|-------|------|---------|
+| 方案设计质量（开发返工率） | 返工率 < 10% | 20% | 开发反馈 |
+| 闸门裁决准确性（漏判率） | 漏判率 < 5% | 25%（关键） | 线上故障追溯 |
+| ADR 覆盖率（重大决策记录率） | 100% | 10% | ADR 抽查 |
+| 技术债务控制 | 不超过阈值 | 15% | 技术债务盘点 |
+| 文档质量（下游满意度） | ≥ 4.0/5.0 | 15% | 开发/QA 问卷 |
+| 安全评估完整性 | 100% | 15%（一票否决） | 安全审计 |
+
+---
+
+## 六、常用命令与工具
+
+```bash
+# === Workflow 校验 ===
+node .harness/workflow/validate.js              # 检查流程完整性
+
+# === Gate 检查（闸门评估时使用）===
+node .harness/gate/index.js                     # 完整质量门禁
+node .harness/gate/index.js --report            # 生成报告（用于评估参考）
+node .harness/gate/index.js --save-baseline     # 项目基线建立时
+
+# === 参考文档 ===
+cat .harness/agents/solution-designer/contract.yaml  # 方案设计契约
+cat .harness/agents/gate-controller/contract.yaml    # 闸门契约
+cat .harness/rules/global/security-baseline.md       # 安全红线
+cat .harness/dev-map/decisions.md                     # ADR 决策记录
+cat .harness/dev-map/overview.md                       # 架构总览
+```
+
+---
+
+## 七、架构师自查清单
+
+### 方案设计提交前
+- [ ] 设计文档覆盖了所有需求点
+- [ ] API 定义足够详细（可供开发和测试直接使用）
+- [ ] 数据模型完整（含索引、约束）
+- [ ] 影响面分析全面
+- [ ] 风险识别充分且有缓解措施
+- [ ] 安全考虑到位
+- [ ] 技术选型有对比分析（如有新选型）
+- [ ] dev-map 现有约定已参考和遵循
+- [ ] ADR 已编写（如有新决策）
+- [ ] 工作量估算合理
+
+### 闸门评估做出裁决前
+- [ ] 需求和设计都已仔细阅读
+- [ ] 风险评估已覆盖所有维度
+- [ ] 安全检查清单已逐项确认
+- [ ] 资源评估已考虑
+- [ ] 裁决理由充分且书面化
+- [ ] BLOCK/HOLD 时解除条件明确
+- [ ] 无个人偏好干扰客观判断
+
+---
+
+*本规范是架构和技术方案组在 Harness 体系中的完整操作指南。请记住：你的每一个决策都直接影响系统的长期健康。*