docs: localize template README

.agents/INDEX.md

@@ -0,0 +1,59 @@
+# 中国电信研发项目初始化目录
+
+将本目录与项目根目录的 `AGENTS.md` 一起复制到新项目根目录。支持 `.agents/skills` 的 Codex、OpenCode 等 Agent 会发现 `telecom-rd-standards`；其他 Agent 应按 `AGENTS.md` 直接读取该技能。
+
+## 目录契约
+
+| 路径 | 用途 | 使用时机 |
+| --- | --- | --- |
+| `AGENTS.md` | 项目级红线与加载规则 | 每个新 Agent 或新任务开始 |
+| `skills/telecom-rd-standards/SKILL.md` | 完整工作流与审查输出要求 | 新项目、设计、审查、交付或涉及规范的任务 |
+| `skills/telecom-rd-standards/references/01-09-*.md` | 按功能加载的操作规范 | 按下表选择；高风险变更必须加载 |
+| `skills/telecom-rd-standards/references/standards-map.md` | 原文索引 | 输出规范结论、高风险变更或条款争议时 |
+| `references/quick-guides/` | 高频速查摘要 | 实现或日常自查 |
+| `skills/telecom-rd-standards/references/source-documents/` | 脱敏 Markdown 原文整理版 | 规范结论、C 级别、阻断/整改项和强制条款核验；争议时回查原始 DOCX |
+
+## 复用与核验
+
+同一任务内可复用已读取且未变更的文件，无需重复全量阅读。任务范围、目标 C 级别、技术栈、数据敏感性、外部接口或部署方式变化时，重新按矩阵选择。
+
+普通小范围实现先读相关速查指南；涉及安全、密钥、鉴权、数据库权限、外部接口、CI/CD、制品或部署时，必须读取对应功能规范。仅在输出 `规范要求`、C 级别结论、阻断/整改项，处理高风险变更、发生条款争议，或功能规范明确要求时，核验对应原文。
+
+## 高频速查指南
+
+| 文件 | 范围 |
+| --- | --- |
+| `01-overall-rd-standard.md` | 研发流程、角色、交付与评审 |
+| `02-python-coding.md` / `03-frontend-coding.md` | Python 与前端编码 |
+| `04-database-design.md` | 数据库设计与 SQL |
+| `05-code-management.md` | 仓库、分支、提交和版本 |
+| `06-artifact-management.md` / `07-pipeline-management.md` | 制品、溯源和 CI/CD |
+| `08-test-management.md` / `09-security.md` | 测试、缺陷和安全 |
+| `10-deployment.md` / `11-requirements-management.md` | 部署与需求追踪 |
+| `12-rd-cloud-interoperability.md` / `13-development-checklist.md` | 研发云集成与日常自查 |
+
+## 任务—规范选择矩阵
+
+| 任务 | 首先读取的功能规范 | 需要核验的原文（触发时） |
+| --- | --- | --- |
+| 新建项目、服务、模块或目录结构 | `01-project-init-and-architecture.md` | 01、03、04、08、12 |
+| 需求、验收、变更或追踪 | `02-requirements-and-traceability.md` | 03、04 |
+| Python 或前端编码、代码审查 | `03-code-standards.md` | 03、06/07、12 |
+| 表、字段、索引、SQL、迁移或数据库权限 | `04-database-and-data-model.md` | 04、05、12 |
+| REST/OpenAPI、OAuth、研发云或数据接入 | `05-api-and-rd-cloud-integration.md` | 12、20-24 |
+| 安全、密钥、认证、依赖或安全扫描 | `06-security-and-secrets.md` | 03、09、12 |
+| Git、仓库、分支、提交、评审或版本 | `07-repository-and-change-management.md` | 03、04、08 |
+| CI/CD、制品、组件、SBOM、晋级或发版 | `08-ci-artifacts-and-release.md` | 08-10、12 |
+| 测试、缺陷、部署、验证或回退 | `09-testing-and-deployment.md` | 03、10、11、13 |
+
+功能规范只负责缩小阅读范围；所有 `规范要求`、C 级别结论和阻断/整改项均必须回到对应原文的章节和 C 级别核验。
+
+## 原文编号
+
+`00` 为发布通知；`01-13` 为软件研发规范体系；`20-24` 为研发云互联互通试行规范。原文整理版使用稳定的 ASCII Markdown 文件名，中文全称保留在文件正文及 `standards-map.md` 中；条款争议、版式、表格和模板以工作区 `规范文档/` 的原始 DOCX 为准。
+
+## 维护规则
+
+1. 修改原文、速查摘要或技能时，同步检查 `standards-map.md` 与本索引。
+2. 原文优先于速查摘要；速查摘要优先于个人经验。
+3. 不在多个位置复制同一条强制要求；在索引中链接到唯一来源。

.agents/references/quick-guides/01-overall-rd-standard.md

@@ -0,0 +1,83 @@
+# 01-总体规范
+
+## 1. 研发工作流
+
+软件研发过程包含 6 大工作流：
+
+```
+需求 → 分析与设计 → 实现(编码) → 测试 → 发布和部署 → 配置和变更管理
+```
+
+## 2. 项目角色
+
+| 角色 | 职责 |
+|------|------|
+| **项目经理** | 项目整体管理、进度控制、资源协调 |
+| **产品经理** | 需求定义、产品规划 |
+| **需求工程师** | 需求调研、分析、编写、跟踪 |
+| **架构师** | 技术选型、架构设计 |
+| **开发工程师** | 编码实现、单元测试 |
+| **测试工程师** | 测试方案、用例编写、执行测试 |
+| **配置管理员** | 代码/制品/文档版本管理 |
+| **QA 工程师** | 质量保证、过程审计 |
+
+## 3. 各工作流交付成果
+
+| 工作流 | 交付物（C1 必选） |
+|--------|-------------------|
+| 需求 | 《软件需求规格说明书》、《需求追踪表》 |
+| 分析与设计 | 《概要设计说明书》（C1）、《详细设计说明书》（C2） |
+| 实现 | 源代码、单元测试代码 |
+| 测试 | 《测试方案》、《测试用例》、《测试报告》、《缺陷追踪表》 |
+| 发布和部署 | 部署计划、实施方案、回退方案 |
+| 配置管理 | 配置项清单、变更记录 |
+
+## 4. 开发模式
+
+- **【推荐 C2】** 采用迭代式开发，推荐 2-4 周为一次迭代
+- **【强制 C1】** 每个迭代需建立功能、需求和测试用例间的双向追踪关系
+- **【强制 C1】** 迭代结束需建立基线，进行版本打标
+
+## 5. 配置和变更管理
+
+- **【强制 C1】** 源码、需求文档、设计文档、测试用例纳入配置管理
+- **【强制 C1】** 所有配置项必须存储在电信内部服务器，不得使用外部云存储
+- **【强制 C2】** 需求、迭代、测试用例、代码版本、制品版本、产品版本间建立双向追踪
+- **【强制 C1】** 源码、制品、发行版本必须维护可回溯性
+
+## 6. 评审要求
+
+### 评审方式
+- **预评审**：提前 3 个工作日申请，≥50% 评审成员反馈预评审结果
+- **会议评审**：正式会议评审，输出评审记录和缺陷汇总
+- **离线评审**：邮件/平台分发材料，限时提交评审结果
+
+### 评审通过标准
+| 结论 | 说明 |
+|------|------|
+| **通过** | 无背离需求的缺陷，少量细微修改 |
+| **有条件通过** | 少量重要缺陷，修正后不影响主要结构，经评审专家确认即可 |
+| **不通过** | 较多重要缺陷或修改影响主要结构，需重新评审 |
+
+## 7. 技术栈要求
+
+- **【强制】** 新项目 100% 使用天翼云底座、统一技术组件
+- **【强制】** 技术选型须符合《中国电信软件开发统一技术栈要求(试行版)》
+- **【推荐 C0】** 优先复用统一制品库中已有自主研发组件
+- **【强制 C1】** 编码工作在云电脑内进行，所有代码不出研发云
+- **【强制 C4】** 系统/模块间接口调用参照 OpenAPI 规范
+
+## 8. 域名规则
+
+共享代码/组件域名格式：
+```
+cn.chinatelecom.<分公司/专业公司缩写>.<自定义名称>
+```
+
+## 9. 质量度量指标
+
+代码质量扫描需获取以下指标：
+- 阻断级问题数量、严重级问题数量
+- 可靠性评级、安全性评级、可维护性评级
+- 代码重复率
+- 行覆盖率、分支覆盖率

.agents/references/quick-guides/02-python-coding.md

@@ -0,0 +1,106 @@
+# 02-Python 编码规范
+
+> 以 PEP8 为基础，结合中国电信实际整理
+
+## 1. 命名规范
+
+### 包和模块
+- **【强制】** 包命名全小写
+- **【推荐】** 通过功能命名
+- **【推荐】** 模块名全小写，多单词用下划线连接
+
+### 类
+- **【强制】** 驼峰命名（大写开头：`ClassName`）
+- **【推荐】** 接口已文档化时可用函数命名风格
+
+### 函数
+- **【推荐】** 全小写，下划线连接单词（`do_something`）
+- **【强制】** 单下划线 `_` 开头 = protected 模块函数
+- **【强制】** 双下划线 `__` 开头 = 类内私有
+
+### 变量
+- **【强制】** 全小写，下划线连接
+- **【强制】** 单下划线开头 = protected，双下划线开头 = 类内私有
+- **【推荐】** 全局变量适用函数命名规范
+
+### 常量
+- **【推荐】** 全大写 + 下划线（`MAX_SIZE`）
+
+### 异常类
+- **【推荐】** 若抛出错误，异常名加 `Error` 后缀
+
+### 通用原则
+- **【推荐】** 名字使用英文单词，不能用拼音
+- **【推荐】** 3~30 个字母，不超过 4 个单词
+- **【强制】** 命名不能和关键字冲突
+
+---
+
+## 2. 注释规范
+
+### 文件注释
+- **【强制】** 使用文档字符串（三个双引号）
+- **【参考】** 应包含：描述(Description)、作者(Author)、版本(Version)、日期(Date)、记录(Record)
+
+### 类注释
+- **【强制】** 类定义下必须有文档字符串
+- **【推荐】** 有公共属性时，文档中应有 Attributes 段
+
+### 函数注释
+- **【强制】** 外部可见函数必须有文档字符串（非常短小/简单明了的除外）
+- **【强制】** 文档字符串应描述做什么、输入/输出
+- **【参考】** 使用 Args / Returns / Raises 格式
+
+### 通用注释原则
+- **【推荐】** 有效注释量 ≥ 30%
+- **【强制】** 避免装饰性内容，保持简洁；避免行尾注释
+- **【强制】** 复杂分支流程必须注释
+- **【推荐】** 代码质量不高但能运行用 `# TODO:`；有隐患用 `# FIXME:`
+
+---
+
+## 3. 格式规范
+
+### 缩进
+- **【强制】** 4 个空格，禁止混用空格和 Tab
+
+### 换行
+- **【推荐】** 每行 ≤ 80 字符（导入语句和 URL 除外）
+
+### 空行
+- **【强制】** 顶层函数/类之间 2 个空行
+- **【强制】** 类中方法之间 1 个空行
+
+### 导入
+- **【强制】** 每个导入独占一行（`import` 开头时）
+- **【强制】** 导入顺序：标准库 → 第三方库 → 应用指定
+- **【推荐】** 推荐绝对路径导入
+- **【强制】** 禁止隐式相对导入（如 `import bench`）
+- **【推荐】** 可使用显式相对导入（`from . import bench`）
+
+### 字符串
+- **【强制】** 避免循环中用 `+` 或 `+=` 累加字符串（用 `join`）
+- **【推荐】** 同一文件内单/双引号保持一致
+
+### 空值比较
+- **【推荐】** 使用 `if foo is None:` 而非 `if foo == None:`
+
+### 空格
+- **【推荐】** 二元运算符两侧各一个空格
+- **【强制】** 函数名和参数列表的 `(` 之间不加空格
+- **【推荐】** 逗号、分号、冒号前面不加空格
+
+### 关系运算
+- **【强制】** 常量在左、变量在右（如 `if None is foo:`）
+
+---
+
+## 4. 安全编码（与安全分册交叉）
+
+- **【强制】** 禁止在日志中保存口令、密钥
+- **【强制】** 禁止使用私有/弱加密算法（必须用 SM4/SM2/SM3）
+- **【强制】** 口令哈希存储必须加入盐值（至少 8 字节随机数，迭代 50000+ 次）
+- **【强制】** 禁止硬编码敏感信息
+- **【强制】** 使用强随机数（`secrets` 模块或 `os.urandom`）
+- **【强制】** 类型变量定义统一放在 `import` 之后
+- **【强制】** 类变量放在类注释之后、所有类函数之前

.agents/references/quick-guides/03-frontend-coding.md

@@ -0,0 +1,131 @@
+# 03-前端编码规范
+
+## 1. HTML
+
+### 文档结构
+- **【强制】** 使用 HTML5 DOCTYPE
+- **【推荐】** 指定 `<html lang="...">`
+- **【推荐】** 使用 UTF-8 编码（`<meta charset="utf-8" />`）
+- **【推荐】** 移动端设置 viewport
+
+### 资源加载
+- **【推荐】** CSS 在 `<head>` 引入，JS 在 `</body>` 前引入
+- **【推荐】** 引入 CSS/JS 无需指定 type
+
+### 页面标题
+- **【强制】** 必须有且仅有 1 个 `<title>`
+
+### 编码风格
+- **【推荐】** 2 个空格缩进
+- **【强制】** HTML 注释中不允许出现任何敏感信息
+- **【强制】** 标签名统一小写
+- **【推荐】** 自闭合标签结尾加斜线
+
+### 属性
+- **【强制】** 属性值用双引号
+- **【推荐】** Boolean 属性不添加取值
+- **【推荐】** 自定义属性以 `data-` 为前缀
+
+---
+
+## 2. CSS
+
+### 文件引用
+- **【强制】** 一律使用 `<link>` 引入外部样式
+- **【推荐】** 不要在 `<style>` 块中使用 `@import`
+
+### 命名
+- **【强制】** 由字母、中划线、数字组成，不能以数字或中划线开头
+- **【强制】** 禁止拼音与英文混合，禁止中文
+- **【参考】** 不依据表现形式命名，依据内容/功能命名
+- **【强制】** 缩写后仍能保持原单词意思
+
+### 编码风格
+- **【强制】** 所有声明以分号结尾
+- **【推荐】** 2 个空格缩进
+- **【推荐】** 选择器和 `{` 之间保留一个空格
+- **【推荐】** `:` 和属性值之间保留一个空格
+- **【推荐】** 单行不超过 100 字符
+
+### 属性
+- **【参考】** 不要使用 id 选择器
+- **【推荐】** 不使用 `!important`
+- **【推荐】** 十六进制统一小写
+- **【推荐】** 属性声明顺序：定位 → 盒模型 → 文字排版 → 外观 → 其他
+
+---
+
+## 3. JavaScript
+
+### 变量
+- **【强制】** 使用 `const` 或 `let`，禁止 `var`
+
+### 字符串
+- **【强制】** 使用单引号或反引号
+- **【推荐】** 模板字符串代替拼接
+
+### 比较
+- **【强制】** `===` 和 `!==` 代替 `==` 和 `!=`
+
+### 函数
+- **【强制】** 不要定义 `arguments` 参数
+- **【强制】** 不要用 `Function` 构造函数
+- **【强制】** 不要在块中声明函数
+- **【强制】** 不使用 `arguments` 对象，用 `...` 替代
+- **【推荐】** 使用默认参数语法
+- **【参考】** 圈复杂度 ≤ 10，认知复杂度 ≤ 15
+
+### 数组/对象
+- **【推荐】** 字面语法创建
+- **【强制】** `map/filter/reduce` 等回调必须有 return
+- **【推荐】** 使用 `...` 展开运算符
+
+### 模块
+- **【推荐】** 使用 ES6 modules
+- **【强制】** 禁止重复 import 同一模块
+- **【强制】** import 放到模块最上方
+- **【强制】** 禁止 default import 与其他 export 同名，禁止自引用、循环引用
+
+### 代码风格
+- **【强制】** 2 个空格缩进
+- **【推荐】** 添加尾随分号
+- **【推荐】** 文件最大行数 1000，函数最大行数 80
+- **【推荐】** 单行最大字符数 100
+
+### 命名
+- **【强制】** 避免单字母名
+- **【参考】** 变量/函数用小驼峰（camelCase），类用大驼峰（PascalCase）
+
+---
+
+## 4. TypeScript
+
+### 类型声明
+- **【强制】** interface/type 中成员分隔符统一用分号
+- **【强制】** 类型声明时冒号前无空格、冒号后一个空格，箭头前后各一个空格
+- **【强制】** 优先使用 `Interface` 而非 `type`
+- **【强制】** interface 和 type 定义时必须声明成员类型
+- **【推荐】** 简单数组用 `T[]`，复杂类型用 `Array<T>`
+- **【强制】** 禁止无意义的 void 类型
+
+### 类
+- **【参考】** 为类成员声明可访问类型（public/private/protected）
+- **【推荐】** 字面量属性用 `readonly` 而非 getter
+
+### 变量
+- **【强制】** 不得使用 `var`
+- **【推荐】** 优先用 `const`，必要时用 `let`
+- **【推荐】** 如非必要不使用 `any`
+- **【参考】** 优先使用 `undefined`，避免 `null`
+
+### 断言
+- **【强制】** 类型断言使用 `as Type` 语法
+
+### 枚举
+- **【参考】** 使用联合类型替代枚举，避免在新代码中使用枚举
+
+### 其他
+- **【强制】** 禁止使用三斜杠 `///` 导入
+- **【强制】** 禁止使用 `namespace`
+- **【强制】** 重载函数写在一起
+- **【强制】** 即使是单行语句，if/else/for/while 不得省略大括号

.agents/references/quick-guides/04-database-design.md

@@ -0,0 +1,144 @@
+# 04-数据库设计规范
+
+> 涵盖通用规范及 MySQL、PostgreSQL、TiDB、UDAL 四种主流数据库
+
+---
+
+## 一、通用设计规范
+
+### 命名规范
+
+| 对象 | 规则 |
+|------|------|
+| **库名** | 【强制】仅字母/数字/下划线，全小写，≤32字符，禁止关键字 |
+| **表名** | 【强制】仅字母/数字/下划线，全小写，`t_` 开头，≤32字符 |
+| **字段名** | 【强制】全小写，下划线分隔，≤32字符，禁止关键字 |
+| **索引** | 【推荐】非唯一=`idx_字段1_字段2`，唯一=`uidx_字段1_字段2`，全小写 |
+| **用户名** | 【推荐】`库名_app`（生产）、`库名_read`（只读）、`库名_monitor`（监控） |
+| **临时表** | 【强制】`tmp` 开头 + 日期后缀 |
+| **备份表** | 【强制】`bak` 开头 + 日期后缀 |
+
+### SQL 设计规范
+
+- **【强制】** 创建表时所有表和字段必须添加注释
+- **【强制】** 禁止使用外键（业务端实现）
+- **【强制】** SELECT/UPDATE/DELETE 的 WHERE 条件列必须添加索引（低基数列除外）
+- **【强制】** WHERE 条件索引列禁止数学运算和函数运算
+- **【强制】** 禁止 LIKE `%xxx` 前缀模糊匹配
+- **【强制】** 禁止在开发代码中使用 TRUNCATE TABLE
+- **【强制】** DELETE/UPDATE 必须带 WHERE 条件
+- **【强制】** SELECT 语句必须指定具体字段，禁止 `SELECT *`
+- **【强制】** SQL 语句禁止隐式转换
+- **【推荐】** 事务要简单，多事务小事务原则
+- **【推荐】** 避免超过 3 张表关联
+- **【推荐】** IN 操作集合元素控制在 500 个以内
+
+### 流程规范
+
+- **【强制】** DDL 操作至少提前 1 天向 DBA 申请
+- **【强制】** 批量读写超过 5 万条记录必须通知 DBA
+- **【强制】** 业务高峰期禁止大批量更新（超 10 万条）/ALTER 表/创建索引
+- **【强制】** 禁止从开发/测试环境直连生产数据库
+- **【强制】** 严禁在从库执行 SELECT 以外的语句
+- **【强制】** 禁止在主库执行导出操作
+- **【强制】** 生产数据导出到非生产环境需脱敏处理
+- **【强制】** 创建用户时限制登录主机（IP/网段），禁止 `%`
+- **【强制】** 密码复杂度 ≥ 16 位，包含大小写+特殊字符
+- **【推荐】** 生产表结构应设有主键
+- **【推荐】** 对超 100 万行大表修改结构须 DBA 审核，低峰期执行
+
+### 设计范式
+- 逻辑模型满足第三范式即可
+- 物理模型可适当增加数据冗余以提高查询性能
+
+---
+
+## 二、PostgreSQL 开发规范
+
+### 对象命名
+- **【强制】** DB name 与 table name ≤ 64 位
+- **【强制】** 对象名仅小写字母、数字、下划线
+- **【推荐】** 主键索引 `pk_` 开头，唯一索引 `uidx_` 开头，普通索引 `idx_` 开头
+- **【推荐】** 不同业务用不同 database 区分，默认使用 public schema
+
+### 设计规范
+- **【强制】** 创建表结构时需考虑对应索引
+- **【强制】** 多表 join 列需保证列名和数据类型一致
+- **【强制】** 表结构类型与应用程序定义一致
+- **【推荐】** 字符编码 UTF-8，时间使用 UTC
+- **【强制】** 避免使用触发器
+- **【强制】** 大表（>10GB 或 >1000 万行）考虑分区
+- **【强制】** 频繁使用的大对象需定时删除
+
+### 查询规范
+- **【强制】** 禁止 `SELECT *`
+- **【强制】** 使用 `count(*)` 而非 `count(col)` 或 `count(1)`
+- **【强制】** 避免向客户端返回大量数据
+
+### 稳定性
+- **【强制】** 避免长事务（会造成垃圾膨胀）
+- **【强制】** 程序必须有重连机制
+- **【强制】** 使用合理的隔离级别
+- **【强制】** 高并发下务必使用连接池
+- **【强制】** OLTP 高峰期拒绝长 SQL、大事务、大批量
+
+---
+
+## 三、MySQL 开发规范
+
+### 对象设计
+- **【强制】** INT 不使用 unsigned 无符号属性
+- **【强制】** 自增用 8 字节 BIGINT
+- **【强制】** 字符集使用 UTF8MB4
+- **【强制】** 日期使用 DATETIME 类型
+- **【强制】** 敏感字段需加密（动态盐 + 非固定加密算法 + 多轮加密）
+
+### 数据操作
+- **【强制】** 禁用 `UPDATE/DELETE ... LIMIT`
+- **【强制】** 禁用关联子查询
+- **【强制】** 禁用 `INSERT ... ON DUPLICATE KEY UPDATE`
+- **【强制】** 禁用联表更新
+- **【强制】** 生产环境禁止使用 hint
+
+### 查询优化
+- **【推荐】** SELECT 建议 UNION ALL（不超过 5 个子句）
+- **【强制】** DML 语句必须有 WHERE 条件，且使用索引查找
+- **【推荐】** order by/group by/distinct 尽量利用索引
+
+---
+
+## 四、TiDB (HTAP) 开发规范
+
+### 核心约束
+- **【强制】** 单行数据 ≤ 6 MB，单表字段 ≤ 60 个
+- **【强制】** 单个事务默认 ≤ 100 MB，大事务需拆分（每 100~500 行一批）
+- **【强制】** 建表使用 utf8mb4 编码
+- **【强制】** 禁止 `SELECT *`
+- **【强制】** 高并发交易场景，单语句关联表 ≤ 2 张；分析场景 ≤ 10 张
+- **【强制】** 自增列仅保证唯一，不保证连续/有序
+
+### 分区表
+- **【强制】** 查询条件必须包含分区字段
+- **【推荐】** 分区记录数控制在十亿级别
+
+---
+
+## 五、UDAL 开发规范
+
+### 核心约束
+- **【强制】** 对象名仅小写字母、数字、下划线，≤ 32 位
+- **【强制】** 表必须设置主键
+- **【强制】** 禁止使用外键、分区表、存储过程、函数、触发器、视图
+- **【强制】** 字符集仅 utf8/utf8mb4
+- **【强制】** 存储引擎必须为 InnoDB
+
+### 查询规范
+- **【强制】** 查询必须带 WHERE 条件，尽量使用分片键
+- **【推荐】** 避免跨分片 Join/Union
+- **【强制】** 关联表分片算法和拆分节点必须一致
+
+### 数据操作
+- **【强制】** 禁止不带 WHERE 的 Update/Delete
+- **【强制】** 禁止 Truncate table
+- **【强制】** 禁止 Update/Delete 带 LIMIT 或 ORDER BY
+- **【强制】** 禁止更新分片键值

.agents/references/quick-guides/05-code-management.md

@@ -0,0 +1,108 @@
+# 05-代码管理规范
+
+## 1. 代码仓库设置
+
+### 管理工具
+- **【强制 C1】** 必须使用 Git 管理代码
+
+### 命名规范
+- **【强制 C1】** 名称仅使用英文字母、数字、中划线（`-`）；首字符仅为字母
+- **【强制】** 禁止使用下划线 `_` 和特殊字符
+- **【强制 C1】** 项目内全部仓库命名规则必须一致（全驼峰/全大写/全小写选一种）
+
+### 必要文件
+- **【强制 C1】** 每个项目必须有 `README.md`（包含工程介绍、结构说明、文档地址）
+- **【强制 C1】** 除文档仓库外，必须有 `.gitignore`
+
+### 仓库划分
+- **【强制 C1】** 核心代码和非核心代码分库管理
+- **【强制 C1】** 每个仓库仅使用一种技术栈
+- **【推荐 C0】** 每个仓库不超过 5 个微服务
+
+### 仓库大小
+- **【强制 C1】** 每个仓库不超过 1GB
+
+### 权限设置
+- **【强制 C1】** 遵循权限最小化原则
+- **【强制 C1】** 仅项目负责人/管理员可创建仓库
+- **【强制 C1】** 离职/离开团队必须收回权限
+- **【强制 C1】** 仓库管理员不超过 3 人
+- **【强制 C1】** 禁止外协开发人员设为仓库管理员
+- **【推荐 C0】** 严格控制 master/develop 分支写权限
+
+---
+
+## 2. 分支设置
+
+### 必要分支
+- **【强制 C1】** 必须有主干分支（master）
+
+### Git Flow 工作流（推荐 C0）
+
+| 分支类型 | 名称格式 | 说明 |
+|----------|----------|------|
+| 主干分支 | `master` | 对外稳定发布版本 |
+| 开发分支 | `develop` | 包含全部最新特性 |
+| 紧急修复 | `hotfix-*` | 以 master TAG 为基础修复 |
+| 集成测试 | `release-*` | 以 develop 为基础，验收后合入 master |
+| 功能分支 | `feature-*` | 以 develop 为基础，完成后删除 |
+
+### 代码评审
+- **【强制 C3】** 所有提交必须经过代码评审
+- **两种模式**：单分支 code review 或多分支 merge request
+
+---
+
+## 3. 开发人员操作规范
+
+### 用户信息设置
+- **【强制 C1】** 须与远端仓库账号、邮箱一致
+- "【强制 C1】** 密码不少于 8 位，包含数字、大小写字母及特殊符号
+
+### Commit 规范
+- **【强制 C1】** 保持清晰的 commit 历史
+- **【强制 C1】** 推送前合并精简 commit（一个任务不超过 5 个 commit）
+
+### Commit Message 格式（C3）
+```
+type(scope): subject
+%workItemId
+```
+
+| type | 含义 |
+|------|------|
+| `feat` | 新功能 |
+| `fix` | 修复 bug |
+| `docs` | 文档变更 |
+| `style` | 代码格式 |
+| `refactor` | 重构 |
+| `perf` | 性能优化 |
+| `test` | 增加测试 |
+| `build` | 构建工具变更 |
+| `revert` | 撤销提交 |
+| `chore` | 辅助工具变动 |
+
+示例：`%1011 fix(core): set a to b`
+
+### 代码文件约束（C0）
+- **【强制】** 不允许提交含数据库账号、密码等敏感信息的文件
+- **【强制】** 不允许提交与项目无关的二进制文件
+- **【强制】** 单个文件不超过 10MB
+- **【强制】** 第三方依赖包必须引用制品库，不得直接放入仓库
+- **【强制】** 不允许提交 pdf/doc/ppt/xls/压缩包/音视频等文件
+
+---
+
+## 4. 代码版本管理
+
+### 版本号
+- **【强制 C1】** 发布版本必须打 tag
+- **【强制 C2】** 版本号格式：`X.Y.Z`（主版本.次版本.修订号）
+  - 主版本号：不兼容的 API 修改
+  - 次版本号：向下兼容的功能新增
+  - 修订号：向下兼容的问题修正
+- **【强制 C1】** 制品版本号与代码版本号一致
+
+### 版本信息
+- **【强制 C3】** Tag Message 记录版本日期、说明
+- **【强制 C3】** Release Notes 记录 feature、fixed、关联任务

.agents/references/quick-guides/06-artifact-management.md

@@ -0,0 +1,78 @@
+# 06-制品管理规范
+
+## 1. 制品全生命周期
+
+```
+开发构建 → 安全扫描 → 存储管理 → 测试 → 部署
+```
+
+### 总体原则
+- 源代码及需求来源可追溯
+- 制品安全质量可管控
+- 存储管理安全可靠
+- 制品唯一可信（部署 = 测试通过版本）
+- 操作及流转日志可审计
+
+## 2. 开发构建
+
+- **【强制 C1】** 开发构建须连接统一制品库，第三方依赖从统一制品库代理下载
+- **【强制 C1】** 构建制品必须上传到统一制品库
+- **【强制 C3】** 制品须收集构建信息（构建时间、人员、工具、第三方依赖）
+- **【强制 C3】** 制品须通过元数据关联代码仓库、分支、commit id
+- **【强制 C4】** 制品须进一步关联对应需求或缺陷
+
+## 3. 安全扫描
+
+- **【强制 C3】** 制品关联源代码质量及安全扫描信息
+- **【强制 C4】** 根据扫描结果确定制品能否进入测试
+- **【强制 C2】** 制品关联第三方组件安全漏洞扫描
+- **【强制 C2】** 存在高中危漏洞且可修复时必须在开发阶段修复
+- **【强制 C3】** 制品关联第三方组件许可协议扫描
+
+## 4. 存储管理
+
+### 仓库类型选择
+| 场景 | 仓库类型 |
+|------|----------|
+| 云原生应用 | docker 仓库（镜像）+ helm 仓库（配置） |
+| 直接部署安装 | generic 仓库 |
+| 项目构建依赖 | 对应类型：maven/npm/go/pypi |
+
+### 仓库命名格式
+```
+项目名[-子项目名]-生命周期-制品类型-仓库类型
+```
+示例：`myproject-snapshot-maven-local`
+
+生命周期：snapshot（开发快照）/ release（生产发布）
+
+### 权限与审计
+- **【强制 C1】** 设置严格的访问权限（管理员、读写、只读三类）
+- **【强制 C2】** 上传/下载/修改/删除必须留痕，日志保存 ≥ 6 个月
+
+## 5. 版本管理
+
+- **【强制 C1】** 制品版本号与源代码版本号保持一致
+- **【强制 C1】** 开发测试阶段使用快照版本（SNAPSHOT）
+- **【强制 C1】** 快照版本测试完成后发布正式版本做回归测试
+- **【强制】** 正式版本号不允许覆盖升级
+
+### 制品晋级
+- **【强制 C3】** 测试和安全检查通过后从快照仓库自动晋级到发布仓库
+- **【强制 C4】** 晋级到生产仓库前可增加人工审核
+
+### 清理
+- **【强制 C1】** 快照仓库最多保留 10 个版本
+- 生产发布仓库已部署版本建议永久保存
+
+## 6. 第三方组件管理
+
+- **【强制 C1】** 统一制品库作为第三方组件依赖源
+- **【强制 C2】** 通过 SCA 工具对第三方组件进行安全扫描
+- **【强制 C4】** 制定第三方组件使用规范：黑名单拦截、基线管控、新增组件审批
+
+## 7. 制品溯源
+
+- **【强制 C3】** 制品元数据包括：构建信息、关联源码、安全扫描结果、测试结果
+- **【推荐 C0】** 收集制品软件物料清单（SBOM）
+- **【推荐 C0】** 通过 SBOM 快速定位有安全漏洞的组件

.agents/references/quick-guides/07-pipeline-management.md

@@ -0,0 +1,70 @@
+# 07-流水线管理规范
+
+## 1. 配置要求
+
+### 命名规范
+- 流水线名称：英文小写字母 + 数字 + 中划线 `-`，字母开头
+- 建议格式：`{业务名称}-{模块名称}-{语言}`
+- 示例：`srdcloud-usercenter-java`
+- **【强制】** 禁止使用 `test`、`demo` 等意义不明字样
+
+### 步骤命名
+- 可由小写字母、数字、中文组成
+- 根据实际用途命名，禁止无意义名称
+
+### 其他
+- **【强制】** 流水线属于单个项目组，不允许跨项目使用
+- **【强制】** 运行环境必须和开发环境保持一致
+
+## 2. 触发类型
+
+| 类型 | 说明 |
+|------|------|
+| 手动触发 | 开发人员手动触发 |
+| 定时触发 | 按定时规则自动触发 |
+| 事件触发 | 代码库/制品库事件触发（如代码提交、代码合入、代码更新） |
+
+## 3. 流水线阶段内容
+
+### 持续集成（CI）
+1. **获取代码** — 流水线对代码库具有下载权限
+2. **单元测试** — 人工静态检查 + 动态执行跟踪
+3. **代码检查** — 代码安全扫描（安全漏洞）+ 代码质量扫描（编码违规）
+4. **编译构建** — 源码编译成目标文件并打包
+5. **制品构建** — 制作成最终可运行文件
+6. **上传制品** — 上传到统一制品库
+
+### 持续交付
+1. 执行测试用例
+2. 部署测试环境
+3. 测试环境测试
+4. 部署预生产环境
+5. 预生产环境测试
+
+### 持续部署
+1. 灰度发布
+2. 卡点检查
+
+## 4. 按流水线类型推荐内容
+
+| 流水线类型 | 触发事件 | 推荐内容 |
+|------------|----------|----------|
+| VerifyCI | 代码提交评审 | 构建 + 单元测试 + 质量扫描 |
+| MergeCI | 代码合入 | 构建 + 制品上传 |
+| ReleaseCI | release 分支代码更新 | 安全漏洞扫描 |
+| 测试任务 | 代码更新 | 自动测试任务 |
+
+## 5. 分级要求（按能力等级）
+
+| 内容 | C1 | C2 | C3 | C4 |
+|------|:--:|:--:|:--:|:--:|
+| 代码获取 | ● | ● | ● | ● |
+| 编译构建 | ● | ● | ● | ● |
+| 单元测试 | ○ | ● | ● | ● |
+| 代码质量扫描 | ○ | ● | ● | ● |
+| 代码安全扫描 | ○ | ● | ● | ● |
+| 制品上传 | ○ | ○ | ● | ● |
+| 自动化测试 | ○ | ○ | ● | ● |
+| 自动部署 | ○ | ○ | ○ | ● |
+
+（● 必选 ○ 可选）

.agents/references/quick-guides/08-test-management.md

@@ -0,0 +1,85 @@
+# 08-测试管理规范
+
+## 1. 角色与职责
+
+| 角色 | 职责 |
+|------|------|
+| **测试负责人** | 制定测试方案/计划、组织评审、把控进度 |
+| **测试执行人** | 编写测试用例、执行测试、记录缺陷 |
+| **研发人员** | 修复缺陷、配合回归验证 |
+| **产品经理** | 缺陷延期处理决策 |
+
+## 2. 测试流程
+
+```
+测试计划 → 测试准备 → 测试执行 → 测试总结
+```
+
+### 测试计划阶段
+- 测试人员全程参与需求分析与评审
+- 从测试角度评估需求可行性、可测性
+- 制定测试方案/计划：确定范围、策略、工作量、资源、风险
+- 组织测试方案评审
+
+### 测试准备阶段
+- 设计测试用例/脚本（覆盖业务场景、系统功能、条件分支、边界值）
+- 组织测试用例评审
+- 按需部署测试环境并验证
+
+### 测试执行阶段
+- 依据测试计划逐一执行
+- 不通过则记录于缺陷管理工具
+- 根据测试充分性判断是否需要增加测试内容
+
+### 测试总结阶段
+- 测试结果分析
+- 输出测试报告
+- 测试文档归档
+
+## 3. 测试分级
+
+| 级别 | 对象 | 目的 |
+|------|------|------|
+| **单元测试** | 可独立编译的模块 | 检查功能/性能/接口 |
+| **集成测试** | 模块间接口 | 验证已集成软件是否符合设计 |
+| **系统测试** | 完整系统 | 验证真实环境下的系统需求符合性 |
+| **验收测试** | 完整系统（用户环境） | 确定是否接收该软件 |
+
+## 4. 缺陷管理
+
+### 缺陷类别
+需求缺陷、架构缺陷、设计缺陷、编码缺陷、测试缺陷、集成缺陷
+
+### 缺陷严重等级
+| 等级 | 说明 |
+|------|------|
+| 致命 | 导致系统崩溃、安全漏洞 |
+| 严重 | 影响主要功能 |
+| 一般 | 影响非核心功能 |
+| 轻微 | 不影响功能，建议性改进 |
+
+### 缺陷优先级
+立即解决 → 优先解决 → 一般 → 较低
+
+### 缺陷处理流程
+```
+提交缺陷 → 确认缺陷 → 修复缺陷 → 缺陷验证 → 关闭
+                                  ↓ 失败
+                              重新指派修复
+```
+关闭后可激活（复现时）
+
+## 5. 测试环境划分
+
+根据不同测试活动目的划分环境，也可多个测试活动共用同一环境。
+
+## 6. 分级测试验收要求
+
+| 项目级别 | 单元测试 | 集成测试 | 系统测试 | 验收测试 |
+|----------|:--------:|:--------:|:--------:|:--------:|
+| C4（战略级） | ● | ● | ● | ● |
+| C3（国家级） | ● | ● | ● | ○ |
+| C2（省级） | ● | ● | ○ | ○ |
+| C1（创新探索） | ● | ○ | ○ | ○ |
+
+（● 必选 ○ 可选/视情况）

.agents/references/quick-guides/09-security.md

@@ -0,0 +1,141 @@
+# 09-安全规范
+
+> **最重要分册之一**，涵盖安全原则、开发规范、扫描要求
+
+---
+
+## 一、软件安全基本原则
+
+### 安全设计原则
+- **默认拒绝** —— 无授权即不允许访问
+- **开放设计** —— 安全不依赖机制保密，依赖密钥/口令
+- **特权分离** —— 细分特权分给多个主体；禁止 root 远程访问
+- **最小特权** —— 每个程序/用户仅拥有完成任务所需最小权限
+- **最少公共机制** —— 共享机制降到最少
+- **完全仲裁** —— 授权检查覆盖每个访问操作
+- **零信任** —— 假设用户/外部部件都不安全
+- **访问控制** —— 严禁用用户输入参数作为访问控制依据；使用 RBAC；基于角色展示前端页面
+
+### 会话管理原则
+- Session ID 必须足够随机且无法预测
+- 含敏感信息的会话必须 SSL 加密
+- **权限变动时必须重新生成 Session ID**
+- 同一用户尽量只允许一个会话存在
+- 建议尽可能缩短会话寿命
+
+### 缓存管理原则
+- 所有缓存数据必须设置过期时间
+- 要求强一致性的系统不能使用缓存
+- 预防缓存雪崩/缓存穿透
+
+### 安全开发原则
+- **输入验证** —— 所有输入都需安全验证；**所有输入必须在服务端验证**
+- **客户端不可信任** —— 敏感数据从服务端获取，不直接使用客户端身份信息
+- **错误消息** —— 仅显示一般错误信息，不暴露系统/网络/应用敏感信息
+- **URL 加密传输** —— URL 中敏感信息应加密
+- **注释代码** —— 不能包含敏感信息
+- **最小化** —— 输入信息最小化、返回信息最小化，错误信息对用户屏蔽
+- **失败终止** —— 不符合验证的数据直接终止，不修正继续
+
+### 安全部署原则
+- **【强制】** 禁用 root 权限运行业务应用；不要在容器内以 root 运行
+- **【强制】** 创建服务专属账号启动服务
+- **【强制】** Linux 下避免文件权限设为 777
+- **【强制】** 防火墙默认禁止所有域间流量
+- **【强制】** 为临时安全策略设置生效时间段
+- 记录日志、定期审计
+
+### 禁止弱口令
+- 长度 ≥ 8 位
+- 包含数字、小写字母、大写字母、特殊符号 4 类中至少 3 类
+- 口令与用户名无相关性
+- 更换默认出厂口令
+- 避免键盘排序密码
+
+---
+
+## 二、通用安全开发规范
+
+| 编号 | 规则 | 级别 |
+|------|------|:----:|
+| 1 | 禁止在日志中保存口令、密钥和其他敏感数据 | **强制** |
+| 2 | 禁止使用私有或弱加密算法 | **强制** |
+| 3 | 口令哈希存储必须加入盐值 | **强制** |
+| 4 | 禁止将敏感信息硬编码在程序中 | **强制** |
+| 5 | 使用强随机数（禁止 `java.util.Random`） | **强制** |
+| 6 | 禁止在生产环境保留任何后门程序 | **强制** |
+
+### 推荐加密算法
+| 类型 | 推荐算法 | 最低密钥长度 |
+|------|----------|:----------:|
+| 对称加密 | SM4 | 128 位 |
+| 非对称加密 | SM2 | 256 位 |
+| 数字签名 | SM2 | — |
+| 摘要算法 | SM3 | — |
+
+### 盐值（Salt）要求
+- 至少 8 字节，由安全随机数产生
+- 每个存储入口盐值不同
+- 推荐进行 50000 次哈希迭代（有性能限制时至少 5000 次）
+
+---
+
+## 三、Java 安全开发规范（关键项）
+
+| 规则 | 说明 |
+|------|------|
+| **SQL 注入防护** | 使用参数化查询（`PreparedStatement`），禁止拼接用户输入 |
+| **XML 注入防护** | 白名单校验 + 使用安全的 XML 库 |
+| **命令注入防护** | 系统命令做白名单限制 |
+| **XSS 防护** | 前端输出必须安全过滤/正确转义 |
+| **文件上传** | 校验文件扩展名 + 大小限制 |
+| **URL 跳转** | 白名单验证 URL 参数 |
+| **异常处理** | 禁止抛出敏感数据信息；不允许忽略异常；不允许抛出 RuntimeException/Exception/Throwable |
+| **序列化** | 不要序列化未加密敏感数据（用 `transient`）；避免内存泄漏；反序列化避免恶意代码 |
+| **I/O 操作** | 临时文件及时删除；避免在共享目录操作文件；避免外部进程阻塞在 I/O 流 |
+| **密码存储** | 建议用字符数组存储密码（非 String） |
+
+### 输入验证核心规则
+1. **【强制】** 禁止对用户输入未过滤的参数进行 SQL 拼接
+2. **【强制】** 禁止对用户输入未过滤的参数进行 XML 拼接
+3. **【强制】** 禁止用户输入未经校验的系统命令作为入参
+4. **【强制】** 禁止向前端输出未经安全过滤的数据
+5. **【强制】** 禁止上传未经安全校验的文件
+6. **【强制】** 页面跳转 URL 参数做白名单验证
+7. **【强制】** 禁止向 `Runtime.exec()` 传递不可信数据
+
+---
+
+## 四、代码安全扫描要求
+
+### 扫描时机
+- **【强制 C1】** 软件上线发布前必须进行源代码安全扫描
+- **【强制 C2】** 开发期间提交代码评审时需进行代码质量扫描
+- **【强制 C3】** 代码安全扫描缺陷处理、审计、代码安全基线
+
+### 扫描类型
+| 类型 | 说明 |
+|------|------|
+| SCA | 软件成分分析 |
+| SAST | 静态应用安全测试 |
+| DAST | 动态应用安全测试 |
+| SonarQube | 代码质量扫描 |
+
+### 安全评估分级
+- 阻断级问题 → 必须修复才能上线
+- 严重级问题 → 必须修复
+- 一般级问题 → 建议修复
+- 轻微级问题 → 可选修复
+
+---
+
+## 五、研发云平台安全要求
+
+- **【强制】** 系统接入须提供安全扫描、漏洞扫描、渗透测试报告
+- **【强制】** API 对接使用 TLS 1.3+，敏感数据应用层加密（AES-256）
+- **【强制】** 页面集成通过 iframe 须用 HTTPS + 公网可信证书
+- **【强制】** CSP 头严格限制 iframe 来源，添加 sandbox 属性
+- **【强制】** 链接跳转实施白名单机制
+- **【强制】** 日志保留至少 6 个月
+- **【强制】** 具备安全事件应急处置预案
+- **【禁止】** 研发云与接入系统间禁止批量同步：用户信息、项目信息、用户角色和权限

.agents/references/quick-guides/10-deployment.md

@@ -0,0 +1,77 @@
+# 10-部署管理规范
+
+## 1. 部署流程
+
+```
+部署准备 → 部署审批 → 部署任务设置 → 部署执行 → 部署验证
+```
+
+## 2. 部署准备
+
+### 测试工作
+- **【强制 C1】** 部署前完成上线测试工作，符合测试准入准出要求，提交测试报告
+
+### 需提供的信息和文档
+
+**版本及关联信息**
+- **【强制 C1】** 应用/产品版本信息
+- **【强制 C3】** 对应的需求及编号
+- **【强制 C1】** 制品版本及各制品对应的代码版本
+
+**部署计划和实施方案**
+- **【强制 C1】** 部署计划、实施方案：操作步骤、执行脚本、回退方案、数据备份方案
+
+**其他**
+- 配置参数、数据初始化要求
+- 资源和权限申请
+
+## 3. 部署审批
+- **【强制 C1】** 完成准备后发起审批流程
+- 研发平台侧流程应通过系统或手工对接生产平台侧
+
+## 4. 部署任务设置
+
+### 命名规范
+- 小写字母 + 数字 + 中划线 `-`，小写字母开头
+- 建议格式：`{业务名称}-{模块名称}-{服务名称}-{环境}`
+- 示例：`srdcloud-usercenter-web-pro`
+- **【强制 C3】** 部署任务针对单个项目，不允许跨项目使用
+
+### K8S 部署任务
+- 使用 YAML 文件描述部署资源
+- **【强制】** 镜像明确具体版本号，**禁止使用 `latest`**
+- 资源配置不得超过命名空间限制
+
+### 主机部署任务
+- 使用 tgz 压缩包，包含：
+  - `deploy/init.sh` — 初始化准备
+  - `deploy/start.sh` — 服务启动
+  - `deploy/stop.sh` — 服务停止
+  - `deploy/monitor.sh` — 监控服务
+  - `deploy/clean.sh` — 停止并清理
+
+## 5. 部署执行
+- 生产环境部署选择手动触发（需每次审批）
+- 其他环境可通过流水线触发
+
+## 6. 部署验证
+- 通过事先准备好的用例验证部署正确性、完整性、服务可用性
+
+## 7. 部署环境
+
+### 环境类型
+
+| 环境 | 说明 |
+|------|------|
+| **云网环境** | 集团 IT 和业务上云环境（集团云网运营部统筹管理） |
+| **私有环境** | 各单位自行管理的部署环境 |
+
+### 云网环境要求
+- 符合生产环境相关要求
+- 提供同步研发云制品库到本地制品库的接口
+- 能接收研发云平台侧部署任务并执行
+
+### 私有环境要求
+- 必须支持 K8S 部署或主机部署之一
+- 必须能访问研发云制品库拉取制品
+- 能接收部署任务并执行（特殊网络情况可离线部署）

.agents/references/quick-guides/11-requirements-management.md

@@ -0,0 +1,75 @@
+# 11-需求管理规范
+
+## 1. 需求开发过程
+
+```
+制定计划 → 需求调研 → 需求分析 → 需求评审 → 用户确认 → 需求变更 → 需求跟踪 → 需求验收
+```
+
+### 各阶段产出物
+
+| 阶段 | 产出物 |
+|------|--------|
+| 需求调研 | 《需求调研记录》、《客户访谈记录》 |
+| 需求分析 | 《软件需求规格说明书》、原型 |
+| 需求评审 | 《评审记录表》、修订后的文档 |
+| 用户确认 | 确认单/邮件/签字留档 |
+| 需求变更 | 变更申请 → CCB 评审 → 修订文档 |
+| 需求跟踪 | 《需求跟踪表》持续更新 |
+| 需求验收 | 验收确认单 |
+
+## 2. 需求分析准则
+
+### 分析维度
+- **合理性**：是否细化到设计人员可直接实现的程度
+- **可行性**：成本、性能角度评估
+- **优先级**：高（本次必须）→ 中（可下版本）→ 低（资源允许时）
+- **产品线关系**：新增 / 待优化 / 共性 / 特例
+- **质量**：清晰明确、完整、一致、可验证、可跟踪
+
+### 不同类型需求细化要求
+
+| 类型 | 细化要求 |
+|------|----------|
+| **查询统计类** | 明确查询条件、查询结果、统计口径 |
+| **性能类** | 明确响应时间、用户数、并发数、吞吐量、资源利用率 |
+| **流程类** | 流程图 + 关键环节说明 |
+| **外部接口类** | 接口协议、字段名称、备选值、约束条件、性能指标 |
+| **业务数据类** | 输入条件、计算逻辑、输出结果 |
+
+## 3. 需求编号规则
+
+```
+[系统标识]_（模块标识）_[编号](_二级编号)
+```
+- 系统标识和模块标识用英文或拼音缩写
+- 未确定需求前加 `TBD_` 前缀
+
+## 4. 需求状态跟踪
+
+| 状态 | 说明 |
+|------|------|
+| 新需求 | 用户提出需求申请 |
+| 需求已确认 | 已被分析且用户已确认 |
+| 已开发 | 开发完成提交测试 |
+| 已测试 | 功能测试和回归测试通过 |
+| 已上线 | 发布上线，用户认可 |
+| 已验收 | 用户验收通过，可关闭 |
+
+## 5. 需求变更
+
+### 流程
+```
+变更申请 → 评估审批（CCB） → 制定计划并执行 → 验证发布
+```
+
+### 关键点
+- **【强制】** 客户变更需书面提交（单位盖章或领导签字）
+- **【强制】** 一周内答复变更申请结果
+- 变更视为新需求，按本规范重新执行需求开发流程
+
+## 6. 内部/外部评审
+- **内部评审**：项目经理组织，需求/开发/测试/QA/配置共同参与
+- **外部评审**：通知用户发起，需求确认
+- 评审通过后上传配置库，邮件通知相关人员
+- 项目经理组织需求讲解和澄清

.agents/references/quick-guides/12-rd-cloud-interoperability.md

@@ -0,0 +1,116 @@
+# 12-研发云平台互联互通
+
+> 研发云平台与外部系统的集成规范
+
+---
+
+## 一、互联互通方式（5 类）
+
+| 方式 | 说明 |
+|------|------|
+| **系统接入** | 外部平台与研发云集成，单点登录、界面跳转/集成 |
+| **能力开放** | 通过 OpenAPI 及消息事件订阅向外部开放平台能力 |
+| **数据开放** | 提供研发效能类数据（系统级/组织级） |
+| **数据接入** | 外部平台研发过程数据同步到研发云 |
+| **服务接入** | 脚手架等服务接入研发云 |
+
+---
+
+## 二、系统接入
+
+### 认证方式（三种）
+1. **天翼认证** — 按天翼认证系统要求
+2. **云认证** — 按云认证系统要求
+3. **研发云认证** — 通过 OIDC/OAuth2.0 协议
+
+### 集成方式
+- **界面跳转**：研发云菜单点击跳转
+- **界面集成**：iframe 嵌入，使用 `postMessage` 通信
+
+```javascript
+window.postMessage({
+  valueType: "xxx", // 双方约定事件名称
+  data: {},         // 具体参数
+}, "*");
+```
+
+### 系统接入安全要求
+- 系统接入须提交安全扫描、漏洞扫描、渗透测试报告
+- 集成页面须使用 HTTPS + 公网可信证书
+- CSP 头严格限制 iframe 来源
+- 链接跳转实施白名单机制
+
+---
+
+## 三、OpenAPI 能力开放
+
+### 鉴权方式
+| 方式 | 适用场景 |
+|------|----------|
+| **平台级鉴权** | 使用"外部用户账号"，SHA256 + Base64 签名 |
+| **用户级鉴权** | OAuth 获取 auth_token，通过 `id_token` 传递 |
+
+### 已开放的能力模块
+用户管理、安全中心、版本中心、部署中心、测试中心、代码库、流水线、敏捷管理、文档空间、问需管理、我的工作、Wiki、自研工作项、数据中台、组件广场、Codefree、制品中心、资源中心
+
+### 平台级鉴权格式
+```
+Header:
+  srdcloud-user-account: <外部账号>
+  time-stamp: <时间戳>
+  authorization: SHA256({account},{timestamp},{secret}) 再 Base64
+```
+
+---
+
+## 四、数据开放与接入
+
+### 数据开放范围
+- 基本对象维度信息（组织、项目、用户）
+- 研发过程效能度量明细数据
+- 效能度量汇总模型数据
+- 研发成果数据（专利等）
+- **不涉及**源代码文件、制品内容
+
+### 数据订阅方式
+| 方式 | 说明 |
+|------|------|
+| DCOOS（云桥） | 推送至 DCOOS 地址 |
+| HTTPS/HTTP | 仅组织级，推荐 HTTPS |
+| Kafka | 需 1124VPN，JDK 11+ |
+
+### 数据接入方式
+- 通过消息中心（CloudEvents 格式）
+- 通过其他中心（如测试中心，按业务要求）
+
+---
+
+## 五、消息事件订阅
+
+### 已开放事件
+| 中心 | 事件 |
+|------|------|
+| 用户中心 | 账号开通、密码重置 |
+| 代码中心 | 代码库变更 |
+| 集成中心（流水线） | 配置变更、任务执行状态、错误日志 |
+| 安全中心 | Sonar 扫描结果 |
+| 部署中心 | 资源部署对象删除事件 |
+
+---
+
+## 六、网络对接方案
+
+| 方案 | 适用条件 |
+|------|----------|
+| CN2-1124 直通 | 主机可直接访问 CN2-1124 VPN |
+| CN2-1124 代理 | 有服务器同时接入 CN2-1124 和本地内网 |
+| SASE 打通 | 不能直接访问 CN2-1124，但可访问公网 |
+
+---
+
+## 七、安全运营
+
+- 重大安全事件：边处置、边报告
+- 重大安全风险：及时排查、整改、反馈
+- 日志保留 ≥ 6 个月
+- **【禁止】** 研发云与接入系统间批量同步用户信息、项目信息、用户角色和权限

.agents/references/quick-guides/13-development-checklist.md

@@ -0,0 +1,98 @@
+# 13-快速检查清单
+
+> Python 开发日常自查
+
+---
+
+## 开工前 Check
+
+- [ ] 代码在云电脑内编写（**代码不出研发云**）
+- [ ] 技术选型符合统一技术栈要求
+- [ ] Git 仓库已创建，`.gitignore` 已配置
+- [ ] 需求文档已评审通过
+
+---
+
+## 编码中 Check
+
+### Python 编码
+- [ ] 命名：类用驼峰，函数/变量全小写+下划线
+- [ ] 缩进：4 个空格，无 Tab
+- [ ] 每行 ≤ 80 字符
+- [ ] 导入顺序：标准库 → 第三方 → 应用
+- [ ] 禁止隐式相对导入
+- [ ] 函数有文档字符串（Args/Returns/Raises）
+- [ ] `if foo is None:` 而非 `== None`
+- [ ] 禁止循环中用 `+` 拼接字符串
+- [ ] 常量在左、变量在右
+
+### 安全
+- [ ] 无硬编码密码/密钥
+- [ ] 口令哈希已加盐（盐 ≥ 8 字节随机数，≥ 50000 次迭代）
+- [ ] 使用强随机数
+- [ ] 日志不输出敏感信息
+- [ ] 用户输入已验证（服务端验证）
+- [ ] 错误消息不暴露系统信息
+- [ ] 无后门代码/调试入口
+
+### 数据库
+- [ ] 表名/字段名全小写+下划线
+- [ ] 表和字段已添加注释
+- [ ] 无外键
+- [ ] WHERE 条件列有索引
+- [ ] 无 `SELECT *`
+- [ ] DELETE/UPDATE 带 WHERE 条件
+- [ ] 无隐式类型转换
+- [ ] DDL 已提前通知 DBA
+
+---
+
+## 提交前 Check
+
+### Git
+- [ ] Commit message 格式：`type(scope): subject` + `%workItemId`
+- [ ] 已精简合并 commit（≤ 5 个）
+- [ ] 无敏感信息（密码/密钥/账号）
+- [ ] 无二进制文件 > 10MB
+- [ ] 无 PDF/DOC/压缩包/音视频
+- [ ] 第三方依赖来自制品库（非直接提交）
+
+### 测试
+- [ ] 单元测试已编写
+- [ ] 测试覆盖率达标
+- [ ] 无致命/严重缺陷未关闭
+
+---
+
+## 流水线 Check
+
+- [ ] 代码质量扫描通过（无阻断/严重级问题）
+- [ ] 代码安全扫描通过
+- [ ] 构建成功
+- [ ] 制品已上传统一制品库
+
+---
+
+## 部署前 Check
+
+- [ ] 测试报告已提交
+- [ ] 部署计划/实施方案已准备
+- [ ] 回退方案已准备
+- [ ] 制品已从快照版本转为正式版本
+- [ ] K8S 镜像未使用 `latest` 标签
+- [ ] 部署审批已通过
+
+---
+
+## 安全红线（一票否决）
+
+| 问题 | 后果 |
+|------|------|
+| 代码中包含硬编码密码/密钥 | 禁止上线 |
+| 使用弱加密算法（MD5/DES/SHA1） | 禁止上线 |
+| 日志打印用户密码/敏感信息 | 禁止上线 |
+| 存在高危安全漏洞未修复 | 禁止上线 |
+| 未通过代码安全扫描 | 禁止上线 |
+| 代码存储在外部云服务 | 违规 |
+| 未经审批部署到生产环境 | 违规 |
+| 直接连接生产数据库 | 违规 |

.agents/scripts/convert-source-documents-to-md.ps1

@@ -0,0 +1,143 @@
+[CmdletBinding()]
+param(
+    [string]$SourceDirectory = (Join-Path $PSScriptRoot '..\skills\telecom-rd-standards\references\source-documents'),
+    [switch]$Replace
+)
+
+$ErrorActionPreference = 'Stop'
+$sourceDirectory = (Resolve-Path $SourceDirectory).Path
+$titles = @{
+    '00-issue-notice' = '关于印发中国电信软件研发规范（修订版）的通知'
+    '01-capability-classification' = '中国电信软件研发规范分级分类实施指导意见（修订版）'
+    '02-rd-standards-revision-overview' = '软件研发系列规范修订介绍'
+    '03-overall-rd-standard' = '中国电信软件研发规范总体规范（修订版）'
+    '04-requirements-management' = '中国电信软件研发规范需求管理分册（修订版）'
+    '05-database-design' = '中国电信软件研发规范数据库设计分册（修订版）'
+    '06-python-coding' = '中国电信软件研发规范编码规范（Python 分册）'
+    '07-frontend-coding' = '中国电信软件研发规范编码规范（前端分册）'
+    '08-code-management' = '中国电信软件研发规范代码管理分册（修订版）'
+    '09-artifact-management' = '中国电信软件研发规范制品管理分册（修订版）'
+    '10-pipeline-management' = '中国电信软件研发规范流水线管理分册（修订版）'
+    '11-test-management' = '中国电信软件研发规范测试管理分册（修订版）'
+    '12-security' = '中国电信软件研发规范安全分册（修订版）'
+    '13-deployment' = '中国电信软件研发规范部署管理分册'
+    '20-rd-cloud-overview' = '研发云平台互联互通规范总册（试行稿）'
+    '21-rd-cloud-system-access-auth' = '研发云互联互通规范系统接入技术规范（用户认证和资产授权）（试行稿）'
+    '22-rd-cloud-data-open-access' = '研发云互联互通规范数据开放和接入技术规范（试行稿）'
+    '23-rd-cloud-openapi' = '研发云互联互通规范能力开放技术规范（OpenAPI 接口）（试行稿）'
+    '24-rd-cloud-scaffold-service' = '研发云互联互通规范服务接入技术规范（脚手架服务）（试行稿）'
+}
+
+function Test-StructuralLine([string]$Line) {
+    return $Line -match '^(\d+(\.\d+){0,4}\s+\S+|第[一二三四五六七八九十]+[章节]|[一二三四五六七八九十]+、|\d+[)）]|[-*•]\s+|[A-Za-z][)）]\s+|[{}\[\]`]|"|//)'
+}
+
+function Join-Paragraph([string]$Left, [string]$Right) {
+    if ([string]::IsNullOrEmpty($Left)) { return $Right }
+    if ($Left -match '[A-Za-z0-9]$' -and $Right -match '^[A-Za-z0-9]') { return "$Left $Right" }
+    return "$Left$Right"
+}
+
+function Write-Buffer([System.Collections.Generic.List[string]]$Output, [string]$Buffer) {
+    if (-not [string]::IsNullOrWhiteSpace($Buffer)) {
+        $Output.Add($Buffer)
+        $Output.Add('')
+    }
+}
+
+$txtFiles = Get-ChildItem -LiteralPath $sourceDirectory -File -Filter '*.txt'
+if ($txtFiles.Count -eq 0) {
+    throw "No TXT documents found in $sourceDirectory."
+}
+
+foreach ($txtFile in $txtFiles) {
+    $baseName = [System.IO.Path]::GetFileNameWithoutExtension($txtFile.Name)
+    $title = $titles[$baseName]
+    if (-not $title) { $title = $baseName }
+    $output = [System.Collections.Generic.List[string]]::new()
+    $output.Add("# $title")
+    $output.Add('')
+    $output.Add('> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。')
+    $output.Add('')
+
+    $buffer = ''
+    $skipAuthorMetadata = $false
+    $skipContactLines = 0
+    foreach ($rawLine in Get-Content -LiteralPath $txtFile.FullName) {
+        $line = ($rawLine -replace '[\u00A0\t]+', ' ' -replace '\s{2,}', ' ').Trim()
+
+        if ($skipContactLines -gt 0) {
+            $skipContactLines--
+            continue
+        }
+        if ($line -match '^(规范编制人员|编制人员)(：|:)?') {
+            Write-Buffer $output $buffer
+            $buffer = ''
+            $output.Add('> 编制人员信息已移除。')
+            $output.Add('')
+            $skipAuthorMetadata = $true
+            continue
+        }
+        if ($skipAuthorMetadata) {
+            if ($line -match '^(版本变更历史|目录|\d+(\.\d+){0,4}\s+\S+)') {
+                $skipAuthorMetadata = $false
+            } elseif ([string]::IsNullOrWhiteSpace($line)) {
+                continue
+            } else {
+                continue
+            }
+        }
+        if ($line -match '^(评审人员|传阅人员|审阅人员|审核人员)[:：]') {
+            Write-Buffer $output $buffer
+            $buffer = ''
+            $output.Add('> 评审与传阅人员信息已移除。')
+            $output.Add('')
+            continue
+        }
+        if ($line -match '联系人[:：]?$' -or $line -match '^如有问题.*联系人') {
+            Write-Buffer $output $buffer
+            $buffer = ''
+            $output.Add('> 联系方式已移除。')
+            $output.Add('')
+            $skipContactLines = 2
+            continue
+        }
+
+        $line = $line -replace '(?<!\d)1[3-9]\d{9}(?!\d)', '[手机号已脱敏]'
+        $line = $line -replace '(?i)[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}', '[邮箱已脱敏]'
+        $line = $line -replace '张三', '示例创建人'
+
+        if ([string]::IsNullOrWhiteSpace($line)) {
+            Write-Buffer $output $buffer
+            $buffer = ''
+            continue
+        }
+
+        if (Test-StructuralLine $line) {
+            Write-Buffer $output $buffer
+            $buffer = ''
+            if ($line -match '^(\d+(\.\d+)*)\s+(.+)$' -and $line -notmatch '【强制】') {
+                $depth = ([regex]::Matches($Matches[1], '\.').Count + 2)
+                $depth = [Math]::Min($depth, 6)
+                $output.Add(('#' * $depth) + ' ' + $line)
+            } elseif ($line -match '^(第[一二三四五六七八九十]+[章节]|[一二三四五六七八九十]+、)') {
+                $output.Add('## ' + $line)
+            } else {
+                $output.Add($line)
+            }
+            $output.Add('')
+            continue
+        }
+
+        $buffer = Join-Paragraph $buffer $line
+    }
+    Write-Buffer $output $buffer
+
+    $markdownPath = Join-Path $sourceDirectory "$baseName.md"
+    [System.IO.File]::WriteAllText($markdownPath, (($output -join [Environment]::NewLine).TrimEnd() + [Environment]::NewLine), [System.Text.UTF8Encoding]::new($false))
+    if ($Replace) {
+        Remove-Item -LiteralPath $txtFile.FullName
+    }
+}
+
+Write-Output "Converted $($txtFiles.Count) TXT documents to Markdown. Replace=$Replace"

.agents/scripts/validate-agent-starter.ps1

@@ -0,0 +1,84 @@
+[CmdletBinding()]
+param(
+    [string]$ProjectRoot = (Resolve-Path (Join-Path $PSScriptRoot '..\..')).Path
+)
+
+$ErrorActionPreference = 'Stop'
+$agentsDir = Join-Path $ProjectRoot '.agents'
+$skillDir = Join-Path $agentsDir 'skills\telecom-rd-standards'
+$sourceDir = Join-Path $skillDir 'references\source-documents'
+$mapPath = Join-Path $skillDir 'references\standards-map.md'
+$guideDir = Join-Path $agentsDir 'references\quick-guides'
+$functionalReferenceNames = @(
+    '01-project-init-and-architecture.md',
+    '02-requirements-and-traceability.md',
+    '03-code-standards.md',
+    '04-database-and-data-model.md',
+    '05-api-and-rd-cloud-integration.md',
+    '06-security-and-secrets.md',
+    '07-repository-and-change-management.md',
+    '08-ci-artifacts-and-release.md',
+    '09-testing-and-deployment.md'
+)
+$requiredPaths = @(
+    (Join-Path $ProjectRoot 'AGENTS.md'),
+    (Join-Path $agentsDir 'INDEX.md'),
+    (Join-Path $skillDir 'SKILL.md'),
+    $mapPath,
+    $sourceDir,
+    $guideDir
+)
+
+$missing = $requiredPaths | Where-Object { -not (Test-Path -LiteralPath $_) }
+if ($missing) {
+    throw "Missing required paths: $($missing -join '; ')"
+}
+
+$sourceFiles = Get-ChildItem -LiteralPath $sourceDir -File -Filter '*.md'
+if ($sourceFiles.Count -ne 19) {
+    throw "Expected 19 source documents; found $($sourceFiles.Count)."
+}
+
+$invalidSourceNames = $sourceFiles | Where-Object { $_.Name -notmatch '^[0-9]{2}-[a-z0-9-]+\.md$' }
+if ($invalidSourceNames) {
+    throw "Non-standard source filenames: $($invalidSourceNames.Name -join ', ')"
+}
+
+$legacyTextFiles = Get-ChildItem -LiteralPath $sourceDir -File -Filter '*.txt'
+if ($legacyTextFiles) {
+    throw "Legacy TXT source documents remain: $($legacyTextFiles.Name -join ', ')"
+}
+
+$standardsMap = Get-Content -LiteralPath $mapPath -Raw
+$unindexedSources = $sourceFiles | Where-Object { $standardsMap -notmatch [regex]::Escape($_.Name) }
+if ($unindexedSources) {
+    throw "Source documents missing from standards map: $($unindexedSources.Name -join ', ')"
+}
+
+$guideFiles = Get-ChildItem -LiteralPath $guideDir -File -Filter '*.md'
+if ($guideFiles.Count -ne 13) {
+    throw "Expected 13 quick guides; found $($guideFiles.Count)."
+}
+
+$index = Get-Content -LiteralPath (Join-Path $agentsDir 'INDEX.md') -Raw
+$unindexedGuides = $guideFiles | Where-Object { $index -notmatch [regex]::Escape($_.Name) }
+if ($unindexedGuides) {
+    throw "Quick guides missing from index: $($unindexedGuides.Name -join ', ')"
+}
+
+$missingFunctionalReferences = $functionalReferenceNames | Where-Object {
+    -not (Test-Path -LiteralPath (Join-Path $skillDir "references\$_"))
+}
+if ($missingFunctionalReferences) {
+    throw "Missing functional references: $($missingFunctionalReferences -join ', ')"
+}
+
+$skill = Get-Content -LiteralPath (Join-Path $skillDir 'SKILL.md') -Raw
+$unlinkedFunctionalReferences = $functionalReferenceNames | Where-Object {
+    $skill -notmatch [regex]::Escape($_) -or $index -notmatch [regex]::Escape($_)
+}
+if ($unlinkedFunctionalReferences) {
+    throw "Functional references missing from SKILL.md or INDEX.md: $($unlinkedFunctionalReferences -join ', ')"
+}
+
+Write-Output "Agent starter is valid: 19 source documents, 13 quick guides, and 9 functional references are indexed."

.agents/skills/telecom-rd-standards/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: telecom-rd-standards
+description: 按中国电信软件研发规范起草、规划、审查和改进软件项目。用于新项目立项与技术方案、代码审查、架构、数据库、接口、安全、测试、CI/CD、仓库、制品、部署审查，以及研发云互联互通或 OpenAPI 集成；当任务提及中国电信、研发规范、研发云、C1-C4、代码审查、项目方案、合规或交付治理时使用。
+---
+
+# 中国电信软件研发规范
+
+以本包内原始 DOCX 对应的脱敏 Markdown 整理版为导航依据。不得臆造强制控制，也不得把 C0 建议默认为强制要求。
+
+## 按需加载与复用
+
+1. 先阅读项目根目录的 `AGENTS.md`，再按 `INDEX.md` 的任务—规范选择矩阵最小化加载；不得为普通小改动通读全部规范。
+2. 新项目、设计、审查、交付或需要作出规范结论的任务，加载本技能和对应功能规范；普通小范围实现或自查，先读取相关速查指南。
+3. 安全、密钥、鉴权、数据库权限、外部接口、CI/CD、制品和部署变更，无论范围大小都加载相应功能规范。
+4. 仅在标记 `规范要求`、给出 C 级别结论、提出阻断/整改项、处理高风险变更、遇到条款争议，或功能规范明确要求时，核验对应原文及章节；争议、表格、模板和版式回查原始 DOCX。
+5. 在同一任务中复用已读取且未变更的内容；任务范围、目标 C 级别、技术栈、数据敏感性、外部接口或部署方式变化时，重新选择并补充加载。
+
+## 建立基线
+
+1. 明确任务类型：项目起草、代码审查、设计审查、交付审查或研发云集成。
+2. 明确项目类别和目标能力等级；未分级项目暂按 C1，并要求项目负责人最终确认。C0 为最佳实践建议，C1-C4 为逐级增强的要求。
+3. 明确语言/框架、数据存储、部署目标、外部接口、数据敏感性以及是否使用研发云。
+4. 按任务加载下面对应的功能规范；需要作出规范结论或处理高风险事项时，通过 [规范原文索引](references/standards-map.md) 核验相应原文的章节和 C 级别。摘要与原文冲突时以原文为准。
+5. 遵守保密要求：项目代码和文档属于中国电信内部资料，不得放入互联网暴露的存储、处理或传输工具。
+
+## 新项目起草
+
+先进行简要的结构化方案设计：
+
+1. 写明业务目标、用户、成功度量、约束和非目标。
+2. 列出假设、未知项、风险、数据分类和依赖；只追问会影响架构、安全、成本或交付的未知项。
+3. 存在真实取舍时，给出 2-3 个方案，并从合规、安全、可运维性、交付成本和可逆性比较，推荐一个方案并说明理由。
+4. 将选定方案转为可合规交付的计划：角色、需求追踪、设计产物、仓库和分支、测试、安全扫描、制品追溯/SBOM、流水线门禁和部署审批/回退。
+5. 输出决策记录和初始待办；每个待办包含负责人、验收条件、关联需求、风险和目标版本。
+
+需求与交付物使用 [生命周期检查清单](references/lifecycle-checklists.md) 中的流程和模板。每个需求都应能追溯到设计、代码、测试、发布和部署。
+
+所有方案项标记为 `规范要求`、`工程建议` 或 `待确认`。只有原文明确支持的控制才能标为规范要求，且必须保留来源章节和 C 级别；不得把架构偏好、工具惯例或未经核验的数值阈值写成中国电信要求。
+
+## 按功能加载规范
+
+只读取与任务匹配的文件，再按其列出的原文核验：
+
+- 新项目、架构或模块结构：[01-project-init-and-architecture.md](references/01-project-init-and-architecture.md)
+- 需求、变更、验收或追踪：[02-requirements-and-traceability.md](references/02-requirements-and-traceability.md)
+- Python 或前端实现/审查：[03-code-standards.md](references/03-code-standards.md)
+- 表结构、SQL、迁移或数据库账号：[04-database-and-data-model.md](references/04-database-and-data-model.md)
+- REST/OpenAPI、外部系统或研发云：[05-api-and-rd-cloud-integration.md](references/05-api-and-rd-cloud-integration.md)
+- 安全、密钥、鉴权、依赖或部署加固：[06-security-and-secrets.md](references/06-security-and-secrets.md)
+- 仓库、分支、提交、版本或评审流程：[07-repository-and-change-management.md](references/07-repository-and-change-management.md)
+- CI/CD、制品、组件、SBOM 或发版：[08-ci-artifacts-and-release.md](references/08-ci-artifacts-and-release.md)
+- 测试、缺陷、部署、验证或回退：[09-testing-and-deployment.md](references/09-testing-and-deployment.md)
+
+## 审查工作
+
+审查证据而不是意图：检查实际差异、配置、流水线、测试结果、部署方案和相关文档。
+
+按下列顺序输出：
+
+| 优先级 | 含义 | 输出格式 |
+| --- | --- | --- |
+| 阻断 | 违反原文强制控制，或造成重大安全/发布风险 | `【阻断】[C级别] 问题 — 证据 — 原文章节 — 必须整改项` |
+| 需整改 | 未达到项目目标 C 级别的控制 | `【需整改】[C级别] 问题 — 证据 — 原文章节 — 整改项` |
+| 建议 | C0 改进项或其他非强制实践 | `【建议】问题 — 收益 — 建议动作` |
+| 通过/不适用 | 控制已有证据或不在范围内 | 简明说明证据或理由 |
+
+代码审查优先检查：日志中的密钥和敏感数据、硬编码凭据、弱/私有加密、输入输出校验、授权、错误暴露、会话、第三方依赖风险；再检查语言规范、仓库/提交/分支、测试和追溯。结论必须引用原文和章节，不得仅凭文件名宣称合规。
+
+设计、数据库、接口、流水线、制品或部署审查，先读取相应功能规范与 [生命周期检查清单](references/lifecycle-checklists.md)，对有争议或高影响控制再核验完整原文。
+
+## 研发云与外部集成
+
+使用 [研发云集成要点](references/rd-cloud-integration.md) 处理 OAuth、平台/用户级授权、OpenAPI、数据订阅和脚手架服务。不得在输出中暴露密钥、客户端凭据、账号密钥、令牌或签名头；按原文落实最小权限、审批账号、时间戳/防重放和网络传输控制。
+
+## 交付格式
+
+每次输出结尾说明：目标 C 级别（或“待确认”）、审查范围、阻断/整改项、建议、证据缺口和最小下一步。新项目还要包含选定方案、决策记录和首批合规里程碑。

.agents/skills/telecom-rd-standards/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "中国电信研发规范"
+  short_description: "面向中国电信软件项目的研发规范起草、代码审查和交付治理流程"
+  default_prompt: "使用 $telecom-rd-standards 按中国电信研发规范审查该项目。"

.agents/skills/telecom-rd-standards/references/01-project-init-and-architecture.md

@@ -0,0 +1,40 @@
+# 项目启动与架构规范
+
+## 触发条件
+
+新建项目、服务、仓库、重大模块，或建立架构/设计基线前读取。
+
+## 优先核验原文
+
+- `01-capability-classification.md`：C1-C4 的适用范围。
+- `03-overall-rd-standard.md`：第 2、3、4.1、4.4、4.8 章和第 6 章模板。
+- `04-requirements-management.md`：需求在范围内时读第 2-5 章。
+- `08-code-management.md`：创建仓库时读第 2 章。
+- `12-security.md`：接受架构前读第 2 章。
+
+## 规范要求
+
+1. 确认项目类别和目标 C 级别；未分级项目只可临时按 C1，并记录待确认事项。
+2. 定义业务目标、用户、范围、非目标、成功标准、数据分类、依赖、风险、角色和交付里程碑。
+3. 建立需求、设计、评审、配置与变更、实现、测试、发布部署等可追溯工作流。
+4. 实现前完成相应架构/设计评审，并按总体规范使用需求、概要设计、详细设计、测试方案和测试用例模板。
+5. 在选择认证、授权、数据、日志、缓存和网络方案前应用安全设计原则。
+
+## 工程建议
+
+- 明确划分领域逻辑、应用编排、基础设施/适配器、接口层、配置、迁移、测试和运行材料。
+- 首期优先采用模块化单体；只有独立部署、扩缩容、团队边界或故障隔离确有需要时再拆分服务，并记录取舍与回退方案。
+- 将架构图、接口/数据契约、威胁模型和运行假设随项目版本管理。
+
+以上是工程建议，不是中国电信规定的目录名称或框架选型。
+
+## 审查证据
+
+- 项目分类与 C 级别决定。
+- 范围、决策、风险记录和角色分工。
+- 已评审的需求与架构/设计文档。
+- 仓库链接、初始基线及需求追踪关系。
+
+## 使用边界
+
+报告强制问题时必须引用原文章节和 C 级别；不得从总体规范推导出某种微服务、包结构或目录布局是强制要求。

.agents/skills/telecom-rd-standards/references/02-requirements-and-traceability.md

@@ -0,0 +1,31 @@
+# 需求与追踪规范
+
+## 触发条件
+
+需求调研、编写、评审、验收、变更、追踪，或将开发任务关联到需求前读取。
+
+## 优先核验原文
+
+- `04-requirements-management.md`：第 2-5 章。
+- `03-overall-rd-standard.md`：第 3.3、4.3、4.8 章和第 6.1-6.9 节模板。
+
+## 规范要求
+
+1. 覆盖需求调研、分析、文档、评审、验收、变更和追踪全过程。
+2. 使用原文规定的编号格式：`[系统标识]_（模块标识）_[编号](_二级编号)`。
+3. 每项需求应可验证，明确范围、业务规则、数据/接口影响、非功能要求、验收条件、负责人和状态。
+4. 需求变更按申请、评估/审批、计划执行、发布验证的流程处理，并保留变更轨迹。
+5. 维护需求到设计、代码/变更、测试用例/结果、制品/版本、部署的双向链接。
+
+## 工程建议
+
+- 在追踪表旁维护简短决策记录，写明假设、被否决方案和风险接受情况。
+- 开发前为工作项补齐验收条件和验证责任人。
+
+## 审查证据
+
+客户/调研记录、需求说明书或模块需求、评审与验收记录、需求/变更台账、追踪矩阵及关联测试证据。
+
+## 使用边界
+
+工单标题、功能描述或代码注释不能替代完整需求记录；宣称达到某个 C 级别前必须核验原文。

.agents/skills/telecom-rd-standards/references/03-code-standards.md

@@ -0,0 +1,30 @@
+# 代码规范
+
+## 触发条件
+
+编写或审查 Python、前端代码前读取。代码接收输入、处理数据、鉴权、日志、调用外部服务或操作文件时，同时读取 `06-security-and-secrets.md`。
+
+## 优先核验原文
+
+- Python：`06-python-coding.md` 第 2 章。
+- 前端：`07-frontend-coding.md` 中适用的 HTML/CSS/JavaScript/TypeScript 章节。
+- 通用实现：`03-overall-rd-standard.md` 第 4.5 节；`12-security.md` 的通用及对应语言章节。
+
+## 规范要求
+
+- 按对应语言原文核验命名、注释、文档字符串、格式、导入和表达式规则。
+- Python 重点核验包/模块与变量小写、类命名、文档字符串、注释、缩进、导入、字符串、空值比较和空白规则。
+- 前端重点核验 HTML 文档/title/敏感注释，CSS 命名与声明，以及 JavaScript/TypeScript 的导入、变量、相等判断、流程控制和模块规则。
+- 不得混用语言规范。本包未包含 Java、Go、C/C++、Android 编码分册；缺少对应原文时必须标记为语言专项证据缺口。
+
+## 工程建议
+
+在本地和 CI 中自动执行格式化、静态检查、类型检查和针对性单元测试；保持公开接口小而清晰，将副作用隔离在边界，并使用显式错误路径和已校验的数据契约。
+
+## 审查证据
+
+变更差异、格式化/静态检查/类型检查结果、单元测试结果、适用扫描结果，以及带原文章节的评审结论。
+
+## 使用边界
+
+仅当语言原文或安全原文明确规定时才可判定为强制；框架偏好和代码风格偏好应标为工程建议。

.agents/skills/telecom-rd-standards/references/04-database-and-data-model.md

@@ -0,0 +1,31 @@
+# 数据库与数据模型规范
+
+## 触发条件
+
+新建或修改数据库、库表字段、索引、SQL、迁移、大对象、查询、事务或数据库账号前读取。
+
+## 优先核验原文
+
+- `05-database-design.md`：第 2 章及第 3 章中匹配的数据库引擎章节。
+- `12-security.md`：适用的访问控制、敏感数据、日志和部署控制。
+- `04-requirements-management.md`：数据变化影响需求或验收时读取。
+
+## 规范要求
+
+- 按原文执行库、表、字段、索引、用户命名规则；通用规则明确时，应使用小写和下划线并避免不适当关键字。
+- 审查模型设计、注释、字段类型、关联字段类型一致性、快速增长数据的清理机制及数据库引擎专项要求。
+- 使用 BLOB/TEXT、外键、临时/备份对象、分区等场景前，核验原文是否要求 DBA 评估或审批。
+- 审查 SQL 安全和性能：必要条件、条件列索引、避免隐式转换、避免无条件更新/删除和原文禁止的查询模式。
+- 按最小权限管理数据库访问，防止敏感数据和凭据进入代码或日志。
+
+## 工程建议
+
+将迁移与服务一起版本化，并测试迁移/回退路径；运行账号与迁移/管理账号分离；对关键查询审查执行计划。
+
+## 审查证据
+
+已评审的数据模型、DDL/迁移、回退方案、必要的 DBA 审核、关键 SQL/索引审查、账号权限矩阵和测试结果。
+
+## 使用边界
+
+以选定数据库引擎的章节为准；不得未经核验将某一数据库的专属规则推广到其他数据库。

.agents/skills/telecom-rd-standards/references/05-api-and-rd-cloud-integration.md

@@ -0,0 +1,34 @@
+# 接口与研发云集成规范
+
+## 触发条件
+
+设计或审查 REST/OpenAPI、外部系统集成、研发云 SSO/OAuth、研发云 OpenAPI、数据订阅/查询/接入或脚手架服务时读取。
+
+## 优先核验原文
+
+- 通用接口安全：`12-security.md` 第 2 章及适用语言/Web 章节。
+- 研发云范围和流程：`20-rd-cloud-overview.md` 第 4-5 章。
+- SSO/OAuth 与资源授权：`21-rd-cloud-system-access-auth.md` 第 3-5 章。
+- 数据订阅/查询/接入：`22-rd-cloud-data-open-access.md` 第 2-3 章。
+- 研发云 OpenAPI：`23-rd-cloud-openapi.md` 第 2-3 章。
+- 脚手架服务：`24-rd-cloud-scaffold-service.md` 第 3-4 章。
+
+## 规范要求
+
+- 明确接口负责人、调用方、数据分类、授权边界、请求/响应契约、错误行为、版本兼容、超时/重试/幂等和审计要求。
+- 校验不可信输入，服务端执行授权，避免敏感输出和错误暴露，并落实原文规定的安全传输要求。
+- 对研发云接口使用该接口对应的审批账号和授权模型；原文要求时分别核验项目与资产权限。
+- 外部账号密钥、OAuth 客户端凭据、令牌、签名密钥和授权头不得进入代码、示例、日志或审查输出。
+- 数据连接应完成原文的订阅/账号/网络前提；脚手架服务应核验时间戳、随机数/防重放、签名、回调、部署和发版关联要求。
+
+## 工程建议
+
+发布接口契约和变更记录，增加契约测试，并为不兼容变更指定调用方影响负责人。
+
+## 审查证据
+
+已批准的接口/数据契约、授权矩阵、账号/项目/资产审批、网络放通与连通性测试，以及脱敏的请求响应、审计和错误处理测试。
+
+## 使用边界
+
+不得把一个研发云接口的鉴权方式直接复用于其他接口；实现前必须阅读对应原文章节和当前接口文档。

.agents/skills/telecom-rd-standards/references/06-security-and-secrets.md

@@ -0,0 +1,31 @@
+# 安全与密钥规范
+
+## 触发条件
+
+所有新服务、模块、接口、数据模型、部署、代码审查、依赖升级、发布或安全整改均应读取。
+
+## 优先核验原文
+
+- `12-security.md`：第 2-4 章和匹配的语言/Web 子章节。
+- `03-overall-rd-standard.md`：第 5 章及适用的实现/评审章节。
+- `09-artifact-management.md`：涉及制品或依赖时读第 2.3、4、5 节。
+
+## 规范要求
+
+- 在适用处落实默认拒绝/失败安全、最小权限、特权分离、完全仲裁、零信任、会话/缓存和访问控制原则。
+- 校验不可信输入，将客户端视为不可信，避免不安全错误暴露，落实原文规定的安全传输和失败终止。
+- 禁止在日志中写入口令、密钥、令牌或敏感数据；禁止硬编码敏感信息和使用弱/私有加密；口令哈希应加盐；使用强随机数；生产/发布分支不得保留后门。
+- 在服务端/资源边界实施授权；按对应语言或 Web 章节防护文件、命令、反序列化、上传和跳转；按要求扫描代码与依赖。
+- 落实部署最小权限、日志/审计和弱口令控制。
+
+## 工程建议
+
+维护威胁模型、密钥清单、依赖升级负责人和安全例外台账；使用批准的密钥管理，并在合并和发版前自动执行密钥/依赖扫描。
+
+## 审查证据
+
+威胁模型、授权矩阵、扫描报告及整改/例外记录、密钥管理配置、脱敏日志、审计证据和发版审查记录。
+
+## 使用边界
+
+只能引用与实现语言相符的安全子章节；不得将 Java 专属示例作为 Python 的强制控制。

.agents/skills/telecom-rd-standards/references/07-repository-and-change-management.md

@@ -0,0 +1,31 @@
+# 仓库与变更管理规范
+
+## 触发条件
+
+创建或配置仓库、授予权限、选择分支、提交、打标签、代码评审或管理变更/版本时读取。
+
+## 优先核验原文
+
+- `08-code-management.md`：第 2-5 章。
+- `03-overall-rd-standard.md`：第 4.2、4.2.1、4.5.4、4.8 节。
+- `04-requirements-management.md`：需求驱动变更时读第 4 章。
+
+## 规范要求
+
+- 使用 Git；按第 2 章设置一致且可识别的仓库名称/描述、必要文件、范围/大小和角色权限。
+- 遵循最小权限，人员离开时回收权限；原文要求时保护核心代码。
+- 采用项目目标 C 级别对应的分支和评审方式，不得将 C0 建议升格为强制要求。
+- 遵循适用的用户身份、提交、代码文件、版本、标签和版本描述规则。
+- 将代码变更关联到需求/变更记录，保留评审和配置管理证据。
+
+## 工程建议
+
+在平台支持时使用受保护分支、必需检查、代码所有者和小而聚焦的变更；将架构/运行变化及回退说明放在同一评审变更集中。
+
+## 审查证据
+
+仓库设置、README、忽略规则、权限导出、分支策略、提交/评审/合并记录、标签/版本和关联工作项。
+
+## 使用边界
+
+判定分支、评审、提交或版本规则为强制前，必须核验代码管理原文中的具体 C 级别。

.agents/skills/telecom-rd-standards/references/08-ci-artifacts-and-release.md

@@ -0,0 +1,32 @@
+# CI、制品与发版规范
+
+## 触发条件
+
+创建或修改构建任务、CI/CD 流水线、依赖源、制品、镜像、包仓库、版本、SBOM、晋级或发版自动化时读取。
+
+## 优先核验原文
+
+- `10-pipeline-management.md`：第 2-3 章，目标级别门禁读第 3.4 节。
+- `09-artifact-management.md`：第 2-5 章。
+- `08-code-management.md`：源码版本对齐读第 5 章。
+- `12-security.md`：适用扫描控制。
+
+## 规范要求
+
+- 按流水线原文配置名称、运行环境、触发方式、评审/测试/部署路径和目标 C 级别动作。
+- 按要求收集源码版本、构建元数据、质量/安全扫描、组件安全/许可证扫描和制品信息。
+- 使用批准/统一的制品与依赖源，落实制品访问控制，并在目标级别保留访问/审计证据。
+- 遵循快照/正式版本、追溯、晋级、清理、第三方组件和 SBOM 的适用规则。
+- 对齐发版版本、源码标签/说明、测试证据、批准制品和部署记录。
+
+## 工程建议
+
+保证构建可复现、固定依赖版本、仅缓存批准来源，缺失必要证据时失败关闭；可使用 VerifyCI、MergeCI、ReleaseCI 和测试流水线作为起点，但具体必需步骤以第 3.4 节和项目 C 级别为准。
+
+## 审查证据
+
+流水线定义与成功记录、构建元数据、扫描报告、依赖/许可证结果、适用 SBOM、制品坐标/晋级历史，以及发版审批与版本关联。
+
+## 使用边界
+
+不得在原文或平台政策未规定时，将某个 CI 产品、扫描器或流水线阶段表述为强制。

.agents/skills/telecom-rd-standards/references/09-testing-and-deployment.md

@@ -0,0 +1,31 @@
+# 测试与部署规范
+
+## 触发条件
+
+规划或执行测试、处理缺陷、准备发布、配置部署、审批部署、生产验证或设计回退时读取。
+
+## 优先核验原文
+
+- `11-test-management.md`：第 2-8 章。
+- `13-deployment.md`：第 2-3 章。
+- `03-overall-rd-standard.md`：第 4.6-4.7 节和第 6.8-6.9 节模板。
+- `10-pipeline-management.md`：自动化测试/部署时读取相应路径。
+
+## 规范要求
+
+- 按测试流程完成计划、评审、准备、执行、分析、报告和归档。
+- 选择并留存适用的单元、集成、系统、验收测试证据，按原文验收标准和缺陷流程闭环。
+- 部署前准备测试证据、版本/关联信息、部署计划与实施方案、所需文档、审批、任务详情、执行证据和验证。
+- 按云网或私有环境的实际目标应用环境要求，以及适用的 K8S 或主机部署任务规则。
+
+## 工程建议
+
+定义回退触发条件、备份恢复验证、部署后冒烟检查、监控告警负责人和限时回退决策人；高影响变更应在生产窗口前演练恢复。
+
+## 审查证据
+
+已评审的计划/用例/脚本、环境就绪、执行结果、测试报告、缺陷、验收记录，以及部署包、审批、任务配置、版本/制品关联、发布日志、验证和回退证据。
+
+## 使用边界
+
+流水线成功不代表部署就绪；必须分别核验测试、审批、环境和部署证据。

.agents/skills/telecom-rd-standards/references/lifecycle-checklists.md

@@ -0,0 +1,33 @@
+# 研发生命周期检查清单
+
+本清单仅用于定位和审查提示；所有强制结论必须在列出的原文中核验。
+
+## 新项目与需求
+
+- 确认项目分类、目标 C 级别、角色、范围、成功指标、数据敏感性和交付里程碑。
+- 记录调研、需求编号、验收条件、追踪、评审、验收、变更申请/审批和变更验证。来源：需求管理分册。
+- 准备适用的需求规格、概要设计、详细设计、测试方案和测试用例。来源：总体规范第 6 章模板。
+
+## 架构、代码与数据库
+
+- 检查最小权限、零信任/访问控制、适用的默认拒绝和失败安全、输入校验、安全错误处理、会话/缓存和日志。
+- 拒绝源码或日志中的密钥、弱/私有加密、未加盐口令哈希、生产后门和基于不可信客户端的授权。
+- 对已提供原文的 Python、前端执行语言规范；其他语言需先获得对应分册，否则标记专项合规证据缺口。
+- 检查数据库对象/索引命名、模型、SQL 安全、查询/索引性能、事务和模式变更。
+
+## 仓库与变更
+
+- 使用 Git；检查仓库命名/描述、README、`.gitignore`、权限、离组回收、分支、评审、提交、标签和版本。
+- 核验评审证据和需求/工作项关联，不能只看审批标签。
+
+## 构建、制品与流水线
+
+- 定义构建/运行环境，记录源码修订、构建元数据、质量/安全扫描、第三方组件和许可证扫描。
+- 按要求使用统一制品库，保留访问/审计、快照/正式版本、追溯、晋级、清理和适用 SBOM 证据。
+- 检查流水线/步骤命名、触发、评审合入、测试部署路径及目标 C 级别门禁；适用时检查 VerifyCI、MergeCI、ReleaseCI 和测试流水线。
+
+## 测试与发布部署
+
+- 检查测试计划、需求分析、已评审用例/脚本、环境、执行、结果分析、报告、归档和缺陷闭环。
+- 覆盖适用的单元、集成、系统和验收测试，并执行原文的验收标准。
+- 部署前检查版本/关联信息、计划/实施方案、所需文档、审批、任务设置、执行、验证和异常/回退安排。

.agents/skills/telecom-rd-standards/references/rd-cloud-integration.md

@@ -0,0 +1,20 @@
+# 研发云集成要点
+
+实施或审查前必须读取对应试行规范；接口、账号流程和端点可能更新。
+
+## 身份与 OpenAPI
+
+- 研发云支持天翼认证、云认证和研发云 OAuth 外部系统单点登录；OAuth 服务支持授权码、隐式、密码和客户端凭据模式，应为客户端类型选择获批且风险最低的模式。
+- OpenAPI 可能采用平台级外部账号或用户级授权；涉及项目资产时，原文可能要求项目级授权及关联账号拥有项目管理员角色。
+- `client_secret`、外部账号密钥、access token、id token、授权/签名头均为敏感信息，应使用批准的密钥管理，且不得出现在代码、日志、示例或审查输出。
+
+## 数据连接
+
+- 数据订阅可使用 DCOOS、HTTP(S) 或 Kafka；适用时优先 HTTPS，并完成双方网络策略/白名单和连通性验证。
+- Kafka 订阅有运行环境和网络前提，必须以当前原文为准。
+- 使用原文规定的 CloudEvents 或接口专用数据结构，明确数据负责人、范围、保存、授权和失败/重试策略。
+
+## 脚手架服务
+
+- 跨系统调用按原文签名：校验时间戳有效期、拒绝重复随机数、重算并比对签名，失败即拒绝。
+- 规划获批基础设施部署、适用的 Kubernetes 支持、数据库脚本、监控/日志接入、ARM 兼容，以及完整的工作项、代码、制品和安全发版关联。

.agents/skills/telecom-rd-standards/references/source-documents/00-issue-notice.md

@@ -0,0 +1,35 @@
+# 关于印发中国电信软件研发规范（修订版）的通知
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+关于印发中国电信软件研发规范（修订版） 实施要求的通知
+
+为进一步规范研发活动、提升研发水平，开展有组织的研发，建设高水平的研发队伍，推动研发数字化转型，在《中国电信软件研发规范（试行稿）》（ 中国电信科创业〔2022〕 6 号） 的基础上，集团公司充分结合试行期间各单位所提相关建议 ，组织更新了软件研发系列规范并完善了研发规范落地实施的配套管理流程，现印发各单位，请遵照执行。
+
+## 一、主要修订内容
+
+（一） 进一步完善实施指导意见 。 落实《关于印发中国电信研发项目管理办法的通知》（ 中国电信〔2023〕276 号）要求，细化研发项目分类分级管理要求，明确软件研发能力适用项目范围，优化各级研发能力管理原则、定义及要求（详见附件 1）。（二）进一步规范软件研发流程 。在总体规范及各分册系列规范中增加项目分类分级实施要求，增加“部署管理”分册，完善研发过程中部署准备、审批、任务设置及执行验证等各环节实施要求。（三）进一步强化技术栈统一 。落实《中国电信软件开发统一技术栈要求(试行版)》（ 中国电信科创〔2023〕1 号）要求，软件系统的技术选型须符合组件清单要求。
+
+（四）进一步规范研发过程安全管控 ，有效保护软件资产 。落实《关于印发中国电信代码安全管理实施指引(试行)的通知》 （ 中国电信〔2022〕383 号）、《关于推进研发云两级运营及启用云电脑开展研发活动的通知》（ 中国电信科创业[2023]13 号）相关要求，规范代码安全管理及研发工具。
+
+## 二、下一步工作安排
+
+请各单位规范执行小组认真阅读系列规范具体修订内容（参考附件 2-12）并组织本单位内部执行到位。一是确保研发过程安全可控，所有研发活动均在研发云进行 ，全面使用云桌面开展研发，所有代码不出研发云；二是推进技术栈统一落地，各单位新项目坚决 100%使用天翼云底座、统一技术组件 ，2024 年完成50%规模推广存量项 目的迁移；三是加强研发云深度使用，2024 年研发云深度使用率、用户活跃率及开发规范性均需达80%。集团公司将定期组织开展各单位研发项目的规范执行情况的检查与通报。
+
+> 联系方式已移除。
+
+附件：1. 中国电信软件研发规范分类分级实施指导意见（修订版）2.软件研发系列规范修订介绍3. 中国电信软件研发总体规范（修订版）4.规范-需求管理分册（修订版）5.规范-数据库设计分册（修订版）
+
+### 6.1 规范-编码规范(Java 分册)（修订版）
+
+### 6.2 规范-编码规范(Python 分册)（修订版）
+
+### 6.3 规范-编码规范(C_C++分册)（修订版）
+
+### 6.4 规范-编码规范(前端分册)（修订版）
+
+### 6.5 规范-编码规范(Go lang 分册)（修订版）
+
+### 6.6 规范-编码规范(Android 分册)（修订版）
+
+7.规范-代码管理分册（修订版）8.规范-制品管理分册（修订版）9.规范-流水线管理分册（修订版）10.规范-测试管理分册（修订版）11.规范-安全分册（修订版）12.规范-部署管理分册

.agents/skills/telecom-rd-standards/references/source-documents/01-capability-classification.md

@@ -0,0 +1,23 @@
+# 中国电信软件研发规范分级分类实施指导意见（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+附件 1
+
+中国电信软件研发规范分级分类实施指导意见 （修订版）
+
+基于《中国电信软件研发规范分级分类实施指导意见》 （试行版），结合当前阶段中国电信软件项 目 已逐步统一至研发云平台中开展研发活动 ，集团公司进一步完善软件研发规范及分级分类实施指导意见 ，基于研发能力分级进行研发过程管控，适应不同研发能力团队，不同类型项 目的需求 ，为各项 目 团队深度使用研发云平台开展研发规范实施 ，加强资源投入，提升研发水平给出明确指引。
+
+## 一、围绕能力分级实施研发规范
+
+（一） 规范总体内容概述中国电信软件研发规范体系包括总体规范、需求管理分册、编码规范（7 个分册）、代码管理分册、制品管理分册、流水线管理分册、测试管理分册、安全分册和部署管理分册共 15 册。软件研发总体规范用于规定软件研发过程的总体要求，包括总体原则，项目角色设置，交付成果、开发过程及安全等等， 同时作为各分册的索引。软件需求管理分册制定研发过程中需求开发和管理的要求 ，包括需求的调研、分析、编写、评审、变更、验收等
+
+阶段的规范要求。软件编码规范对软件开发过程进行有效的编码规范管理 ，使得最终的软件产品具有良好的风格和统一的结构 ，提高代码可读性和可维护性，减少缺陷。目前包括 Java、C/C++、 Python、Go lang、Web 前端（HTML/CSS/JavaScript/TypeScript）、 Android 、 数 据 库 （ 通 用 /MySQL/PostgreSQL/TiDB/UDAL/TeleDB4XXX）,后续会持续丰富和完善。代码管理分册制定代码仓库设置、开发模式、代码提交、操作规范及代码版本管理等要求。制品管理分册制定制品全生命周期管理、制品版本、制品第三方组件管理、制品溯源管理等方面的要求。流水线管理分册制定流水线配置、流水线包含步骤、以及流水线的触发类型等方面的要求。测试管理分册制定测试流程、测试文档、缺陷管理、验收标准等方面的要求。安全分册制定代码安全管理、质量管理、评估方法等方面的要求。部署管理分册制定研发平台侧的部署管理流程和要求，包括在进行部署之前需要完成的准备工作，部署审批流程，部署任务设置及部署执行等方面。附件包含各分册涉及的文档模板 ，根据规范要求使用或作为参考。
+
+（二）研发能力分级定义说明软件研发能力分为 C0-C4，其中 C0 为业界最佳实践建议，不做强制要求，其它C1-C4 级别逐级增强。定义如下表。软件研发总体规范、需求管理分册、代码管理分册、制品管理分册、流水线管理分册、测试管理分册和部署管理分册均按如下能力级别提出分级要求。
+
+（三）研发项 目 分级能力要求各类研发项目的研发能力要求如下：（1）研发链项 目、战略级项 目、核心能力级重大攻关项 目，要求满足 C4 级能力要求；（2） 国家项 目、核心能力级重点研究项 目，要求满足C3 级能力要求；（3）专业能力级项 目、省级重点项 目，要求满足C2 级能力要求；（4）创新探索级项目和其他未评级项 目，要求满足C1级能力要求。
+
+## 二、使用研发云平台开展研发规范实施
+
+基于软件系列规范（试行版）在研发云平台落地实施和效能改进的基础上 ，本次修订规范要求将持续在研发云平台进行固化。集团公司将定期开展研发项目实施过程的规范性检查 ，检查结果纳入各单位研发上云考核。请各单位组织研发项 目 团队 ，按照研发上云及分级分类管理最新要求，规范研发过程、规范研发工具。研发云平台提供的支持工具与本次下发规范内容的对应关系如下。 同时 ，项 目 团队使用研发云提供的【文档空间】进行开发文档在线协作、技术资料管理和知识沉淀；使用【仪表板】进行研发效能度量和持续改进工作；使用【组件广场】进行统一技术组件使用和成果共享工作。

.agents/skills/telecom-rd-standards/references/source-documents/02-rd-standards-revision-overview.md

@@ -0,0 +1,71 @@
+# 软件研发系列规范修订介绍
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+软件研发规范修订介绍
+
+规范编写团队
+
+规范修订概况
+
+研发全流程规范的优化完善
+
+o 新增部署管理分册规范研发平台侧对于生产环境部署的相关流程和要求部署前需完成准备工作，提交相关材料生产环节部署上线须经过审批规范自动化部署的操作流程o 其他规范主要修订内容规范总册，对整体流程和分册描述进行了修订完善：
+
+• 补充完善部署管理的相关要求，覆盖研发全流程
+
+• 完善分级分类管理原则定义及要求， 明确各类项目的研发能力级别要求
+
+• 实现过程补充代码/组件的域名规则
+
+代码管理分册， 明确代码与需求关联的要求 ，完善研发过程数据关联制品管理分册， 明确第三方组件的使用须符合集团相关发文要求测试管理分册
+
+• 完善测试各阶段内容及要求
+
+• 进一步明确各类项目分级实施的测试验收条件
+
+• 优化单元测试覆盖要求
+
+安全分册优化：
+
+• 优化会话原则（一个用户同一时刻保留一个session）
+
+• 增加客户端不可信任原则
+
+• 参考海南的安全管理规范完善访问控制原则
+
+规范具体修改（一） 总体规范
+
+根据9个公司反馈的意见，并补充部署管理相关要求，调整12处内容o 研发流程补充部署管理的相关要求， 实现端到端流程的规范补充部署环节的管理要求，包括部署流程 、在不同环境的部署要求等补充部署环节的交付件要求补充针对产品部署的评审要求o 补充部署相关的分级分类管理原则， 明确各类项目的研发能力级别要求软件研发能力分级定义补充部署相关要求明确软件研发能力适用项目要求o 明确编码工作需在云电脑内进行，所有代码不出研发云o 研发流程整合集团其他部门相关发文要求企业数据的使用和研发，参照《中国电信〔2022〕 121号 关于进一步推进数据共享和知数用数相关工作的通知》相关规定执行软件研发过程使用的组件须符合《中国电信软件开发统一技术栈要求(试行版)》（中国电信科创〔2023〕 1 号）代码管理须满足《中国电信代码安全管理实施指引(试行)》相关要求 。o 实现环节补充代码/组件的域名规则对共享代码/组件的域名进行统一定义，保证使用规范，避免冲突域名格式：cn.chinatelecom .<分公司/专业公司缩写>.<自定义名称>
+
+4
+
+规范具体修改（二） 代码管理与制品管理
+
+根据集团相关要求以及规范试行期运营意见， 调整3处内容
+
+代码管理代码管理须满足《中国电信代码安全管理实施指引(试行)》相关要求。明确代码与需求关联的要求 ，完善研发过程数据关联根据使用情况修正数据提交格式
+
+制品管理明确第三方组件的使用须符合集团相关发文要求，统一制品库统一代理清单内的第三方组件下载源
+
+Commit message是版本关联和追溯的基础数据，填写要求从原来的C0改为C3考虑使用中的特殊情况，将commit message的数据格式修正为以“% ”开头和间隔
+
+规范具体修改（三） 测试管理
+
+根据3个公司反馈以及组内讨论意见， 调整8处内容对规范大纲重新梳理和优化完善测试各阶段内容及要求优化测试流程各阶段划分完善各测试阶段的主要工作内容规划完善分级测试要求补充各类测试的准入条件和准出条件进一步明确各类项目分级实施的测试验收条件优化原测试准则章节，聚焦测试内容，提出测试验收标准优化分级分类测试验收标准采纳试运行阶段分公司的反馈建议，考虑各语言具体实施情况不同，优化单元测试要求缺陷管理补充完善缺陷类别6
+
+规范具体修改（四） 安全分册
+
+根据2个公司反馈以及组内讨论意见， 调整4处内容o 优化完善访问控制原则根据海南分公司提出的反馈意见，参考海南安全管理规范对访问控制等安全原则进行优化
+
+• 2.1.8会话管理原则，增加“ 限制同一用户的会话数，尽量同一用户只允许一个会话存在 ”要求
+
+• 增加2.2.2 客户端不可信任原则：
+
+• 所有输入都必须在服务端进行验证，确保输入数据安全可信
+
+• 对于客户端请求，标识用户身份等的敏感数据须从服务端获得 ，不应直接使用客户端传输的身份信息
+
+o 取消具体扫描工具的相关说明采纳试运行反馈意见 ，安全规范作为通用的安全指导 ，不限制使用扫描工具
+
+> 联系方式已移除。

.agents/skills/telecom-rd-standards/references/source-documents/03-overall-rd-standard.md

@@ -0,0 +1,215 @@
+# 中国电信软件研发规范总体规范（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+附件3
+
+中国电信软件研发规范总 体 规 范 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步提升全集团的软件研发水平，实现软件分级分类管理，编制中国电信软件研发规范体系， 用于指导和规范全集团的软件研发过程， 提升软件质量。下图为中国电信软件研发规范体系结构：
+
+软件研发总体规范用于规定软件研发过程的总体要求，包括总体原则、项目角色设置 、交付成果 、开发过程及安全等等， 同时作为各分册的索引。
+
+软件需求管理规范制定研发过程中需求开发和管理的要求，包括需求的调研、分析 、编写 、评审 、变更 、验收等阶段的规范要求。软件编码规范对软件开发过程进行有效的编码规范管理，使得最终的软件产品具有良好的风格和统一的结构， 提高代码可读性和可维护性， 减少代码缺陷。代码管理规范制定代码仓库设置 、开发模式 、代码提交 、操作规范及代码版本管理等要求。制品管理规范制定制品全生命周期管理 、制品版本 、制品第三方组件管理、制品溯源管理等方面的要求。流水线管理规范制定流水线配置、流水线步骤、流水线触发类型等方面的要求。测试管理规范制定测试流程、测试文档、缺陷管理、验收标准等方面的要求。部署管理规范制定软件产品部署到生产环境时的要求，包括部署准备、部署审批流程 、部署任务设置及部署执行等方面。安全规范制定代码安全管理 、质量管理 、评估方法等方面的要求。
+
+### 1.2 文档结构
+
+本规范由文档说明、总体要求、软件研发阶段及交付成果、项目组织和角色、软件开发过程 、附件等部分构成， 各章节的主要内容如下：第 1 章文档说明，对规范的编制、文档结构、使用范围、起草单位、解释权、版权和本规范用到的术语进行说明。第 2 章总体要求， 对规范的编制原则进行说明。第 3 章软件研发工作流、角色和交付成果，对研发过程涉及的各个工作流（阶段）， 涉及的角色及职责， 以及每个工作流应交付的成果进行描述。第 4 章软件开发过程，对软件研发的模式，涉及的工作流，包括配置和变更、需求 、设计 、实现 、测试 、发布和部署等进行说明。第 5 章软件安全要求， 规范中国电信软件安全研发流程。第 6 章为相关附件， 包括质量指标及解释， 各类交付件模板。
+
+### 1.3 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+## 2 总体要求
+
+### 2.1 总体原则
+
+1. 体系化原则：构建一个全面的软件研发规范体系，覆盖软件研发流程的需求、分析和设计 、实现 、测试 、部署发布以及配置管理等工作流。2. 分级规范原则： 中国电信软件研发处于发展阶段，各项目团队处于不同的能力水平，各类项目的要求也不尽相同，需要基于研发能力分级进行研发过程的管控，定义适合不同级别研发能力的规范要求，适应不同研发能力的团队，不同类型项目的需求， 同时为各项目团队提升研发水平给出明确指引。软件研发能力分为C0-C4， 其中 C0 为业界最佳实践建议， 不做强制要求，其它 C1-C4 级别逐级增强 。定义如下：
+
+软件研发能力的适用项目要求：C4 级， 适用于研发链项目 、战略级项目 、核心能力级重大攻关项目；C3 级， 适用于国家项目 、核心能力级重点研究项目；C2 级， 适用于专业能力级项目 、省级重点项目；C1 级， 适用于创新探索级项目和其他未评级项目。软件研发总体规范 、需求管理分册 、代码管理分册 、制品管理分册 、流水线管理分册 、测试管理分册和部署管理分册均按上述能力级别提出分级要求。3. 可检查可度量原则： 围绕研发效能提升制定规范要求， 明确需要采集的度量数据 。 中国电信研发云平台作为研发规范的实施支撑平台，按照分级分类实施原则， 逐步实现规范检查和度量指标获取的完全自动化。4. 安全保密原则： 严格落实集团安全保密要求，软件研发过程相关的文档和代码等均属于电信内部资料， 不得通过暴露在互联网的媒体、平台 、工具等进行存储 、处理和传输。
+
+## 3 研发工作流 、 角色和交付成果
+
+### 3.1 软件研发工作流
+
+软件研发过程主要包括以下几个工作流： 需求 、分析和设计 、实现 、测试、发布和部署 、配置和变更管理。
+
+### 3.2 项目角色设置
+
+研发项目角色设置及相关职责说明：
+
+### 3.3 交付成果
+
+各工作流需要相应交付的成果如下表：
+
+## 4 软件开发过程
+
+软件开发过程中的主要工作内容及相互之间的关系的示意图如下：
+
+本规范按照上述软件研发工作内容进行组织。涉及企业数据的使用和研发，参照《中国电信〔2022〕121 号 关于进一步推进数据共享和知数用数相关工作的通知》相关规定执行。
+
+### 4.1 软件开发模式
+
+为更快暴露项目的风险，应对需求的变化，建议采用迭代式开发模式（C2），推荐 2-4 周为一次迭代（C0） 。每个迭代需要建立功能、需求和测试用例之间的双向追踪关系，迭代结束应建立基线，并按照代码管理和制品管理的要求对代码和组件进行版本打标 。（C1）
+
+### 4.2 配置和变更管理
+
+配置管理通过执行版本控制、变更控制等规程， 以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性，从而保证软件项目生成的产品在软件生命周期中的完整性和一致性。（1） 标识变化；（2） 控制变化；（3）保证变化被适当地实现；
+
+（4） 向可能有兴趣的人员报告变化。
+
+需要纳入配置管理的内容：（1） 属于产品组成部分的工作成果， 例如源代码 、需求文档 、设计文档、测试用例等； （C1）（2）在管理过程中产生的文档例如各种计划 、 监控报告等 。（C2）项目所有配置项必须存储在电信内部服务器上，不得使用外部公共云存储等服务 。（C1）项目需要在需求 、迭代 、测试用例 、代码版本 、制品版本和产品版本之间建立双向追踪关系 。（C2）源代码管理详细要求见《中国电信软件研发规范-代码管理分册》；需求变更控制详细要求见《中国电信软件研发规范-需求管理分册》；缺陷管理详细要求见《中国电信软件研发规范-总体规范》的 5.5.7 节。
+
+#### 4.2.1 版本管理
+
+源代码、制品和产品的发行版本必须维护可回溯性 。制品的版本号应与对应源代码的版本号保持一致。详细要求见《中国电信软件研发规范-代码管理分册》和《中国电信软件研发规范-制品管理分册》 。（C1）
+
+### 4.3 需求
+
+需求阶段的主要目的通过建立客户需求和软件开发过程一致的协调，让客户和软件开发小组共同理解系统业务，并在功能和非功能各方面达成共同理解和一致意见。需求管理规范用于需求的调研、分析、编写、评审、变更、验收等阶段的规范要求。项目应制定需求的管理和变更流程。在经过需求评审完成需求定义后，需要建立基线， 管理和控制需求项的变更， 使需求项的变更受控 、可追溯 。（C1）
+
+项目应对需求状态进行跟踪， 以维持需求与项目开发计划、后续各项工作成果之间的双向追溯性 。（C1）需求是项目开展其它活动的基础。需求管理的交付件是软件分析设计和测试的主要依据之一。详细要求见《中国电信软件研发规范-需求管理分册》。
+
+### 4.4 分析设计
+
+软件分析和设计是把需求转化为软件系统的重要环节，软件设计的优劣在根本上决定了软件系统的质量。软件系统的技术选型须符合《中国电信软件开发统一技术栈要求(试行版)》（中国电信科创〔2023〕 1 号）， 新项目采用《中国电信软件开发组件清单》 内统一组件， 存量项目按文件要求实施。软件设计通常可以分为概要设计和详细设计。概要设计的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、总体结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等， 为程序的详细设计提供基础。详细设计的目的是说明一个软件系统各个层次中的每个程序（每个模块或子程序） 和数据库系统的设计考虑， 为程序员编码提供依据。项目需要提供概要设计文档（C1） 和详细设计文档（C2） 。 内容如上所述，可参考附件模板 。设计说明书的内容需要跟系统同步更新（C1） 。
+
+### 4.5 实现
+
+#### 4.5.1 编码要求
+
+编码工作需在云电脑内进行， 所有代码不出研发云 。（C1）编码需要关注代码风格，保证代码的简洁 、可读性和可靠性（C1） 。各种语言编码规范要求详细见《中国电信软件研发规范-编码规范分册》。系统/模块间的接口调用参照 OpenAPI（https://www.openapis.org/） 的相关要求（C4） 。编码规范和安全规范的要求分为三个级别： 强制 、推荐和参考。
+
+n 【强制】： 必须遵守的规范 。违反此类规范会给项目带来安全或性能风险， 产生相关漏洞 。亦或造成产品质量 、可维护性等方面的问题。n 【推荐】： 建议遵守的规范 。在强制级别的基础上结合最佳实践, 考虑到易理解 、易掌握,给开发编码更大的空间,如果没有更好的显著理由,建议遵守。n 【参考】： 可选择遵守的规范 。此类规范通常为解决某问题的一种最佳实践, 可能受具体场景的变化影响,不排除有更好的改良版。编码需要遵循代码安全性要求（C1）， 详细见《中国电信软件研发规范-安全分册》。代码需要进行单元测试，并且测试覆盖率需根据语言及项目类型的不同达到一定的要求（C1） 。详细要求见《中国电信软件研发规范-测试分册》。各种不同编程语言的命名规范按照各个编码分册的要求，如果涉及到使用域名对代码进行组织的， 例如 java 的 package 名称，使用 cn.chinatelecom .<分公司/专业公司缩写>.<自定义名称>,分公司/专业公司缩写见《附件 13-组件域名管理规则》。
+
+#### 4.5.2 代码质量扫描要求
+
+代码质量扫描在软件开发过程中为代码提供质量管控，对源代码进行静态扫描， 检测代码中存在的质量 BUG 、安全缺陷 、语言风格等质量问题并提供修复建议，分析代码的重复率、复杂度与单元测试覆盖率，帮助项目团队从开发阶段了解代码风险和存在的质量问题， 从而进行持续改进。代码质量扫描根据检测结果中问题的类型和严重程度，获取阻断级问题数量、严重级问题数量、可靠性评级、安全性评级、可维护性评级、重复率、行覆盖率和分支覆盖率等代码质量度量指标，作为项目质量评估的重要数据来源。具体的扫描规则和指标解释参见附件《代码质量扫描规则与指标解释》。软件开发期间， 项目团队在提交代码评审时， 需进行代码质量扫描， 以获取代码的质量度量指标 。（C2）
+
+#### 4.5.3 代码安全扫描要求
+
+源代码安全分析技术通过对软件的源代码静态的语义分析、结构分析、数据流分析、控制流分析、缓冲区及配置分析等技术手段来发现其中潜在的风险，可识别在开发期间软件源代码的安全漏洞和质量问题并提供修复指导，可有效帮助开发人员消除代码中的缺陷， 为软件的信息安全保驾护航。在软件开发期间、软件上线发布前应进行源代码安全扫描， 并达到相应软件开发能力的分级要求，确保软件系统上线前尽可能减少代码缺陷，降低信息安全风险， 实现前置安全防护的目标 。（C1）安全扫描基本要求（C1） ,详细见《中国电信软件研发规范-安全分册》。代码安全扫描结果评估与定级（C2） ,详细见《中国电信软件研发规范-安全分册》。代码安全扫描缺陷处理、缺陷审计、代码安全基线（C3）,详细见《中国电信软件研发规范-安全分册》。
+
+#### 4.5.4 代码管理要求
+
+代码管理规定软件项目版本管理的对象、存储目录、分支、权限 、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性 。 代码管理须满足《中国电信代码安全管理实施指引(试行)》相关要求。项目的源代码必须纳入代码版本控制系统进行管理 。（C1）项目需要制定代码分支管理过程，使用基于 Git 的代码版本管理工具 。（C1）对于发布版本，需要在主分支上打上版本标签，版本命名符合规范要求。（C1）详细要求见《中国电信软件研发规范-代码管理分册》。
+
+#### 4.5.5 软件制品管理
+
+制品管理从制品版本 、基线 、制品库分类分级管理 、制品晋级 、制品清理、制品下载等过程阐述了具体的操作，使得对制品的管理更加标准化、具体化。包括制品名称命名规范， 制品版本命名规范， 制品清理策略等。
+
+研发过程中使用的第三方制品必须从统一制品仓库获取。第三方制品的引入和使用须符合《中国电信软件开发统一技术栈要求(试行版)》（中国电信科创〔2023〕
+
+## 1 号） 。（C1）
+
+项目在开发功能时需要查看统一制品库是否有满足需求的自主研发组件，优先考虑复用已有组件 。（C0）详细要求见《中国电信软件研发规范-制品管理分册》。
+
+#### 4.5.6 流水线管理
+
+流水线管理的目标是规范项目组对流水线的使用。项目组应根据自身项目等级， 遵照该管理办法正确使用流水线以及合理配置流水线的各项信息。流水线的内容如下图所示：
+
+项目根据项目类型等因素选择适合的流水线内容。详细要求见《中国电信软件研发规范-流水线管理分册》。
+
+#### 4.5.7 缺陷管理
+
+软件开发过程中需要对缺陷进行分级管理（C1） 。根据缺陷对系统的影响，分为四级： 致命 、严重 、一般和轻微。项目需要制定缺陷管理流程，包括争议处理，设置缺陷处理优先级，对缺陷进行闭环管理（C1） 。每个迭代需要记录缺陷的标题 、类型 、等级 、优先级 、处理人 、测试人员、测试环境 、状态 、修复时间等信息。详细要求见《中国电信软件研发管理规范-测试管理分册》的第 6 节。
+
+### 4.6 测试
+
+软件测试类型主要包括单元测试、集成测试 、系统测试和验收测试 。其中单元测试由开发人员进行， 其他类型测试活动由项目的测试人员执行。测试活动的输入包括经过评审后的项目总体计划（不包含在本规范中），《软件需求规格说明书》和《概要设计说明书》。测试过程包含以下几个活动：（1）测试方案编写：项目测试负责人根据项目总体计划，编写《测试方案》，安排测试进度， 分配测试人员等；（2）测试需求分析： 测试工程师理解项目具体需求， 并参与项目需求评审；（3） 用例编写： 测试工程师根据《软件需求规格说明书》 、《概要设计说明书》编写《集成测试用例》 、《系统测试用例》 、《性能测试用例》；（4） 测试实施： 根据测试用例进行测试， 记录结果并编写测试报告。测试计划和测试用例必须经过评审， 评审通过后由项目经理批准确认。测试规范为软件测试工作提供详细的指引，指导测试工程师完成测试阶段工作 。详细要求见《中国电信软件研发规范-测试管理分册》。
+
+### 4.7 发布和部署
+
+产品部署的目的是用来为确保最终用户可以正常使用软件项目、产品而进行的活动。产品部署环节是指将产品，包括配置文件、用户手册、帮助文档等进行收集 、打包 、安装 、配置 、发布 、 回滚的过程。部署管理明确研发项目部署到生产环境时，在研发平台侧的相关流程和要求，包括在进行部署之前需要完成的准备工作，部署审批流程，部署任务设置及部署执行等方面。
+
+研发项目在生产平台侧部署的相关流程和要求，按照对应生产平台的相关规定执行。
+
+### 4.8 评审
+
+软件研发阶段的评审是由一组有资格的人员对软件设计和开发的输出进行评价，以判断确定研发过程的输出能否实现软件产品预先定义的规格，同时通过评审标识出与规格和标准的偏差， 识别潜在问题和风险。评审的方式主要有以下三种：l 预评审： 至少提前 3 个工作日申请评审， 同时将评审材料发给评审参加人员预审，评审人员在会审前反馈问题，填写评审反馈表。有效的预评审应有不少于 50%的评审成员反馈预评审结果。l 会议评审：通过组织正式评审会议，对阶段工作成果或交付物进行评审，评审参加人员发现、讨论、确认问题和缺陷。会议评审会输出评审记录、评审缺陷汇总， 相关材料应所有评审人员签字确认。l 离线评审：通过邮件或平台工具组织，将评审材料分发给评审参加人员，评审人员采用离线的方式审查材料，在要求的时限内提交评审结果，输出评审记录 、评审缺陷汇总。研发过程中里程碑交付成果的评审要求如下：
+
+评审通过标准：l 通过： 不需要对产品进一步的确认 。未发现导致产品背离需求的缺陷，只有少量细微的缺陷需要作者修正。l 有条件通过：有少量的重要缺陷，但是修改这些缺陷不会对工作产品的主要结构造成实质性的影响。修正后的工作产品需要经评审专家确认后，即通过评审。l 不通过：有较多的重要缺陷，或者修改缺陷会对工作产品的主要结构造成实质性的影响。由责任人修改后，评审组织者需要重新组织评审活动；由评审组织者决定， 是否对被评审对象的全部进行评审。
+
+## 5 软件安全要求
+
+安全性是软件产品的一个关键需求。在软件开发的各个阶段都应当考虑安全性， 并且为关键的应用程序和敏感信息的应用程序提供更高级别的安全性。软件开发安全规范规范中国电信软件安全研发流程，提升研发人员安全编码意识和安全威胁防范能力，指导开发人员在保证系统安全性的情况下完成系统开发，从而有助于在编码阶段减少安全漏洞的产生，在部署阶段可以规避常见的安全问题， 提升整体软件或系统的安全防护能力。详细要求见《中国电信软件研发规范-安全分册》。
+
+## 6 附件
+
+### 6.1 《客户访谈记录表》模板
+
+附件1 -客户访谈记录模板.xlsx
+
+### 6.2 《需求追踪表》模板
+
+附件2-需求追踪表模板.xlsx
+
+### 6.3 《需求追踪表 （变更） 》模板
+
+附件3-需求追踪表（变更）模板.xlsx
+
+### 6.4 《单个模块需求文档》模板
+
+附件4-单个模块需求文档模板.xlsx
+
+### 6.5 《软件需求规格说明书》模板
+
+附件5-软件需求规格说明书模板.doc
+
+### 6.6 《概要设计说明书》模板
+
+附件6-概要设计说明书模板.doc
+
+### 6.7 《详细设计说明书》模板
+
+附件7-详细设计说明书模板.doc
+
+### 6.8 《测试方案》模板
+
+附件8-测试方案模版.docx
+
+### 6.9 《测试用例》模板
+
+附件9-测试用例模板.xlsx
+
+6.10《缺陷追踪表》模板
+
+附件1 0-缺陷追踪表模板.xlsx
+
+6.11《测试报告》模板
+
+附件1 1 -测试报告模板.doc
+
+6.12《代码质量扫描规则与指标解释》
+
+附件12-代码质量 扫描规则与指标解释
+
+6.13《组件域名管理规则》

.agents/skills/telecom-rd-standards/references/source-documents/04-requirements-management.md

@@ -0,0 +1,167 @@
+# 中国电信软件研发规范需求管理分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范需求管理分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+iii
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+本规范制定中国电信软件研发项目的需求管理要求，包括需求的收集、分析、编写、评审、变更、验收等，用以指导和要求项目团队的需求开发活动，实现对需求的闭环管理和全程跟踪。保证客户和软件开发小组对产品业务的理解达成一致意见，包括系统需求和软件运行性能需求的共识，确保交付物符合约定的功能和质量要求。根据规范要求项目团队应编制清楚、完整、一致、可测试的《软件需求规格说明书》、《单个模块需求文档》、《需求追踪表》等，确保需求管理的规范性和可回溯性。
+
+### 1.2 文档结构
+
+本规范由文档说明、需求管理过程、需求管理、需求变更、需求跟踪和附件构成， 各章节的主要内容如下：第 1 章节文档说明，对规范的编制、文档结构、适用范围、起草单位、解释权 、版权和本规范用到的术语进行说明。第 2 章需求管理过程， 对需求开发过程及涉及的角色与职责进行说明。第 3 章需求管理，对需求调研、需求分析、需求评审和需求验收各个阶段进行描述。第 4 章需求变更，对需求变更的申请、评估、审批、制定计划并执行、验证进行说明。第 5 章需求跟踪， 规范需求跟踪的流程和要求。第 6 章为相关附件。
+
+### 1.3 适用范围
+
+1
+
+本规范适用于中国电信的软件研发项目在项目生命周期中的设计、实现、测试以及产品发布的需求跟踪活动 。重点有以下几方面：（1） 本规范适用于传统 、敏捷 、预研 、小微等生命周期模型。（2） 本规范适用于项目启动初期， 对整个项目所有需求的开发过程， 同时也适用于在项目进行过程中， 用户临时新增需求的开发过程。（3） 需求管理是一个循环往复的过程，在日常项目中需求多是迭代获取的，随着项目的进展，需求逐步增加、逐步细化，在项目开发阶段，对既有需求的补充， 如需求开发 、需求变更， 都作为新需求处理， 同样适用本规范。（4） 本规范适用于中国电信C1 能力级别项目， 即适用于所有项目。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+2
+
+3
+
+## 2 需求管理过程
+
+### 2.1 需求开发过程
+
+（1） 制定需求开发计划需求工程师依据需求范围，配合项目经理制定需求开发计划，明确需求总体交付时间 、需求调研范围 、干系人清单。（2） 需求调研需求调研是需求收集的一种，调研后生成《需求调研记录》或《客户访谈记录》。（3） 需求分析需求工程师从整体进行分析，阐述项目背景与目标，理解客户要解决什么问题，有怎样的期望， 由用户需求转化为软件需求，软件设计师可依据软件需求进行设计、编码等工作。根据各层次需求，需求工程师依据实际业务制作原型。此阶段的需求成果物主要为《软件需求规格说明书》和原型。（4） 需求评审需求工程师提交《需求跟踪表》 、《软件需求规范说明书》给项目经理， 由项目经理组织需求评审，评审后输出《评审记录表》（无固定格式，项目方可根据实际情况自行拟定）、评审后修订的《需求跟踪表》、评审后修订的《软件需求规格说明书》。（5） 用户确认需求将整理好的业务需求、软件需求、原型图与客户进行确认，形成用户确认单 、用户签字的需求文档或用户回复的确认邮件、或其他可作为确认凭证的留档文件，做到需求收集过程留痕即可。（6） 需求变更当形成基线后，仍有可能出现较多的需求变更，需对变更的需求进行有效管理。项目经理提交变更申请，经 CCB 评审同意后，需求工程师输出修改后的《软件需求规格说明书》。（7） 需求跟踪4
+
+需求追踪在于保证干系人、项目组始终就项目需求达成统一一致的视图。需求工程师在所有需求管理阶段， 结合各阶段主要交付物， 更新《需求跟踪表》，将需求 、关联文档和发布版本进行关联。（8） 需求验收需求验收即检验产品相关需求是否符合用户方要求，是否符合发布条件。需求工程师对版本实现的功能逐一检查， 以避免开发出来的内容与定义存在偏差。
+
+### 2.2 过程流程图
+
+1. 需求开发过程流程图
+
+5
+
+2. 需求变更过程流程图
+
+6
+
+### 2.3 角色与职责
+
+7
+
+8
+
+9
+
+## 3 需求管理
+
+需求管理包括需求调研 、需求编写 、需求评审和验收各个阶段的管理。
+
+### 3.1 需求调研
+
+需求调研是为实现项目目标而定义并记录干系人的过程 。需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求， 以便日后进行测量。收集需求旨在定义和管理客户期望。成本、进度和质量规划都要在需求基础上进行，需求是工作分解结构的基础。
+
+#### 3.1.1 收集需求
+
+收集需求的工具与技术有：用户访谈 、问卷调查、竞品分析、现场观摩、原型法 、联合开发和头脑风暴等 。常用的如下：（1） 竞品分析需求工程师收集市场上同类产品的相关资料，采取迭代的方式获取系统需求。（2） 与干系人沟通用户访谈的一种，由需求工程师直接到用户的工作场所邀请用户及相关人员召开产品需求调研会议， 也可通过线上或线下直接交流系统需求。
+
+#### 3.1.2 记录需求
+
+需求工程师根据客户处直接获得需求与收集的相关资料，完成《客户访谈记录》并要求客户确认， 确认信息留档备查。
+
+### 3.2 需求分析及编写规范
+
+10
+
+对已完成的《客户访谈记录》应进行汇总分析、划定优先级及每项范围，形成初步的《需求跟踪表》， 以便后续进行需求状态跟踪。对汇总的需求应进行评审分析， 形成《软件需求规格说明书》。
+
+#### 3.2.1 需求分析准则
+
+需求问题识别是从系统角度理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件及需求应达到的标准 。需求包括： 功能需求(做什么) 、性能需求(要达到什么指标) 、环境需求(如机型,操作系统等) 、可靠性需求(不发生故障的概率） 、接口需求 、安全保密需求 、用户界面需求 、资源使用需求(软件运行是所需的内存， CPU 等) 、开发进度需求 、预先估计以后系统可能达到的目标等。需求分析人员应负责对收集和归纳的需求进行进一步的分析， 主要包括：（1） 分析需求细化合理性： 确定需求是否细化到合理程度， 可作为设计人员进行设计实现的有效依据， 若需要细化， 则进一步调研和归纳。（2） 分析需求可行性：综合成本、性能等因素，分析每项需求实施的可行性，剔除掉不可行的需求；需求实现有风险的，通过风险管理过程进行风险识别和控制。（3） 分析需求优先级： 对需求按高 、 中 、低的优先级进行分类， 优先级是对需求进行裁减或开发工作安排的重要依据。高： 关键的功能特性，不实现意味着无法满足客户的需求。必须在本次项目开发中实现。中： 重要的功能特性， 不实现可能会影响产品的销售和客户满意度 。在时间、资源的压力下， 可以考虑在产品的下一个版本中实现。低： 有用的功能或性能的提高， 不实现不会对产品产生实质性影响， 在时间、资源允许的情况下， 可以考虑在产品的某一版本中实现。（4） 分析需求与产品线关系： 如果项目属于某个产品线， 要求分析并标识功能需求与产品线功能之间的关系， 是新增的 、待优化的 。产品经理/项目经理应分析、评估此需求属于特例，还是共性问题，并根据分析结果，决定作为特定项目需求， 还是整个产品需求来进行管理。11
+
+（5） 分析确认各需求描述是否清晰明确、完整、相互一致、可验证、可跟踪。且根据开发和测试过程中提出的需求缺陷进行进一步判断。（6） 分析所归纳的需求是否与合同/立项任务书及附件相一致，若不一致，要提请项目经理注意和处理。上述分析将作为编制或修订《软件需求规格说明书》或《单个模块需求文档》及相关文件的依据。
+
+#### 3.2.2 编写需求文档
+
+在新项目启动初期，针对整个项目的整体需求，要求需求分析人员按照模板要求编写《软件需求规格说明书》（根据需求，在需求调研和需求归纳时形成文稿并循环修订） ，包括： 整体描述、功能需求 、非功能需求、接口需求等。为便于审核，如果模版中某一特定部分不适用，在原处保留标题，并注明该项不适用。在项目执行过程中，针对用户临时提出的，或部分新增的模块需求，要求需求分析人员按照模板要求编写单个模块需求文档，主要包括：需求背景描述、用户业务功能需求 、非功能需求 、接口需求等。《软件需求规格说明书》中每个需求都要唯一编号，编号参考需求编号规则。需求分析的其它成果，包括需求的优先级、与产品线功能的关系、需求功能点细化结果等， 要求体现在需求书中 。“优先级 ”属性可应用在一个需求点上，也可以应用在一个完整的功能模块上。对于不同类型的需求， 需求细化的程度也不相同。查询统计类需求：须明确查询条件、查询结果以及详细的统计口径。统计口径需要描述到用户或者测试 、实施人员可以验证查询结果是否正确；涉及性能的需求：应该明确性能指标要求，如响应时间、系统用户数、在线用户数 、并发用户数 、吞吐量 、资源利用率等。对于涉及多个岗位流程操作的需求：需要通过流程图来直观展现，至少包括流程图和关键环节说明。外部接口类需求，必须有明确的接口规范，至少包含接口协议字段名称、备选值 、约束条件 、接口性能指标。业务数据类需求， 必须明确输入条件 、计算逻辑和输出结果。12
+
+需求小组在对整份需求书的完整性、一致性进行分析的基础上修订《软件需求规格说明书》。
+
+### 3.3 需求评审
+
+内部评审： 由项目经理负责组织，安排需求工程师、开发工程师、测试工程师 、QA 工程师 、配置工程师等相关干系人， 对《软件需求规格说明书》描述的需求功能的正确性、完整性、清晰性等内容达成一致意见，并更新《需求跟踪表》中需求状态跟踪内容。在内部评审过程中，需求跟踪内容是内部评审的完整性检查点之一。《软件需求规格说明书》编写完毕之后，必须通知用户，发起外部评审，进行需求确认 。如有修改意见， 需求分析人员根据意见对《软件需求规格说明书》或《单个模块需求文档》及其附件进行修改，重新提交用户确认。需求确认可保证需求相关文档的质量， 确保与用户 、产品负责人之间能达成一致理解。需求人员完成需求用户确认后，将《软件需求规格说明书》或《单个模块需求文档》，上传至配置库，并邮件通知相关人员。项目经理组织需求人员给项目组的开发 、测试和实施人员进行讲解 、澄清最终需求。
+
+### 3.4 需求验收
+
+项目经理组织开发、测试人员对澄清后的《软件需求规格说明书》展开开发、测试任务，该过程要求从需求完整性、需求合规性、需求对既有系统的影响等多个方面，验证需求文档描述是否准确，如果发现需求不完整或存在错误，可提交需求缺陷， 需求分析人员修改完善该需求。需求分析人员收到缺陷后，可以重新针对某条需求进行需求调研、需求分析，修改需求文档后重新请用户确认， 将需求缺陷反馈给提出人员进行验证。需求通过测试后， 项目经理组织需求工程师 、QA 工程师 、配置工程师等内部需求干系人，基于《软件需求规格说明书》描述内容进行功能性验证，若符合说明书描述内容， 则内部验收通过； 反之需提交开发 、测试人员进行需求修复。内部验收通过后，项目经理组织开发、配置人员进行上线发布；根据前期与用户约定的里程碑验收周期和验收版本，项目经理确定是否邀请用户参与上线验13
+
+收。用户参照评审通过的《软件需求规格说明书》，依次验证系统功能的完整性和可用性，并反馈验收确认单（项目用户可根据项目实际情况拟定确认单格式）。
+
+14
+
+## 4 需求变更
+
+需求变更控制在《软件需求规格说明书》评审通过后，管理和控制已评审通过需求项的变更， 使需求项在变更情况下是受控的 、可追溯的。从可行性、方便性、可维护性的角度考虑，如果变更在项目可控范围内，则将该变更作为新需求进行处理； 如果变更影响较大， 则提请 CCB 审核， 如果审核通过，则作为新需求进行处理。变更不可避免， 因而必须强制实施某种形式的变更控制。
+
+### 4.1 变更申请
+
+有需求变更时，变更提出者应向项目经理提出变更申请，项目经理评估变更影响范围，对项目进度、成本的影响。若变更需求是客户提出的，则客户侧的联系人需将变更内容书面给项目经理，客户要有单位盖章或领导签字，无论变更处理结果如何，项目经理须在一周内把变更申请结果答复给变更发起方，对于电子版的变更申请，需存放在配置库的指定路径下，对于纸质的变更申请，必须按照规定的存放办法存放。
+
+### 4.2 需求评估 、 审批
+
+需求变更应由CCB 负责评估 、上级主管进行审批， 变更结果通知客户和相关干系人。变更评估内容可从涉及变更的配置项、估计工时、成本、可能的风险以及影响范围等角度考虑， 评估 、审批结果应记录到《需求跟踪表（变更） 》。
+
+### 4.3 制定计划并执行
+
+对于审批同意的需求变更，应将该变更视为一个新需求。需求人员按照本规范要求， 编写《软件需求规格说明书》或《单个模块需求文档》并与用户确认。15
+
+项目经理制应定变更工作计划（变更配置项名称及版本、变更进度安排、变更实施人 、变更验证方式）， 项目组依据计划实施变更。
+
+### 4.4 验证发布变更
+
+需求人员应输出更新后的《软件需求规格说明书》或《单个模块需求文档》变更请求审批表。对于需求配置项，配置工程师应更新《软件需求规格说明书》，并将变更控制表纳入配置库，通知相关受影响人员（包括客户），对于变更范围内的相关修订记录必须记录在配置项变更控制表中直至问题全部关闭。
+
+16
+
+## 5 需求跟踪
+
+需求追踪的目的，在于保证干系人、项目组始终就项目需求达成统一一致的视图；需求追踪的原则，是要保证需求全覆盖，且计划可控。项目组通过维护需求追踪列表来标识需求状态转换，有利于项目整体管控，便于随时掌握项目整体进展。
+
+## 1 、需求编号遵循规则如下： [系统标识]_（模块标识）_[编号](_二级编号)
+
+（1） []中的内容表示必选， ()中的内容表示可选。（2） 系统标识和模块标识应采用英文缩写或拼音缩写。（3）每个项目可以根据项目的实际情况确定需求编号规则 。需求编号规则要方便于追踪到需求。（4）对于未能确定的需求，可以考虑在编号前加上“TBD_ ”，表示待确定。
+
+## 2 、需求应包含以下流程状态：
+
+（1） 新需求： 用户提出需求申请。（2） 需求已确认： 该需求已被分析， 用户已经确认该需求。（3） 已开发： 开发组完成系统功能开发， 提交测试。（4） 已测试： 测试组完成系统功能测试 、 回归测试， 达到发布现场条件。（5） 已上线： 系统功能已经发布上线， 用户已经认可该功能 。该需求现在被认为完成。（6） 已验收： 该需求用户侧已验收通过， 可作为需求关闭的标识。
+
+## 3 、需求追踪列表填写规范
+
+（1） 需求阶段列表的填写需求分析人员负责接收用户或产品线的业务需求申请，并记录到《需求追踪表》中，填写需求名称、用户期望上线时间等内容，需求状态标记为“新需求 ”；需求分析人员完成需求分析，并提请用户确认需求后，将该需求状态更新为“需求已确认 ”， 并填写功能需求编号 、功能需求内容描述等内容。（2） 软件开发 、测试阶段列表的填写开发人员应根据《软件需求规格说明书》， 编制详细设计文档， 开发完成并提交测试后， 将程序文件名记录到需求追踪表， 需求状态更新为“ 已开发 ”。17
+
+测试人员应根据需求编写软件测试用例，并将测试用例编号记录到需求追踪列表中。测试人员进行功能测试和回归测试，所有已发现问题均已验证通过，确保没有功能需求被疏漏，确保非功能需求符合要求，更新需求追踪列表中状态为“ 已测试 ”。（3） 版本发布阶段列表的填写需求测试通过后， 实施人员应向用户申请现场发布， 发布成功后， 更新《需求追踪表》， 记录实际上线时间 、上线版本号。版本发布上线后， 需求人员 、实施人员应与用户联系，通知用户进行功能确认 。用户认可该功能后， 填写需求状态项为“ 已上线 ”， 该需求追踪过程结束。（4） 用户验收阶段列表的填写上线后， 应通知用户在生产环境进行测试验收，若验收通过， 则需求分析人员在需求追踪表中更新需求状态为“ 已验收 ”。
+
+18

.agents/skills/telecom-rd-standards/references/source-documents/05-database-design.md

@@ -0,0 +1,961 @@
+# 中国电信软件研发规范数据库设计分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范数据库设计分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步提升软件开发中的数据库设计和数据库操作流程规范化水平，提高数据库系统稳定性，编制本数据库设计分册，用于指导和规范全集团的数据库设计工作， 提升软件质量。
+
+### 1.2 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.3 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.4 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.5 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.6 名词解释
+
+1
+
+2
+
+3
+
+## 2 数据库设计规范
+
+### 2.1 命名规范
+
+#### 2.1.1 库名命名
+
+1) 【强制】库名只能含有字母 、数字和下划线“_ ”三类字符。
+
+2) 【强制】库名必须使用小写字母， 用下划线“_ ”分割。
+
+3) 【强制】库名禁止超过 32 个字符， 须见名知意。
+
+4) 【强制】库名禁止使用数据库特殊关键字命名。
+
+5) 【强制】 临时库库名必须以 tmp 开头， 以创建人的简拼字母和日期为后缀。
+
+6) 【强制】备份库库名必须以 bak 开头， 以创建人的简拼字母和日期为后缀。
+
+#### 2.1.2 表名命名
+
+1) 【强制】表名只能含有字母 、数字和下划线“_ ”三类字符。
+
+2） 【推荐】表名必须使用小写字母， 用下划线“_ ”分割， 普通业务表以 t_开头（或有意义的简写）_+table_name。
+
+3） 【强制】表名禁止超过 32 个字符， 须见名知意。
+
+4） 【强制】表名禁止使用数据库特殊关键字命名。
+
+5） 【强制】 临时表表名必须以 tmp 开头， 以创建人的简拼字母和日期为后缀。正例： 示例创建人在 2022 年 4 月 21 日建了一张临时表， tmp_xxxxxxx_zs20220421
+
+6） 【强制】备份表表名必须以 bak 开头， 以创建人的简拼字母和日期为后缀。正例： 示例创建人在 2022 年 4 月 21 日建了一张备份表， bak_xxxxxxx_zs20220421
+
+#### 2.1.3 字段名命名
+
+1）【强制】字段名必须使用小写字母， 用下划线“_ ”分割。 4
+
+2）【强制】字段名禁止超过 32 个字符， 须见名知意。
+
+3）【强制】字段名禁止使用数据库特殊关键字命名。
+
+#### 2.1.4 索引命名
+
+1) 【推荐】非唯一索引必须以 idx_字段 1_字段 2 命名。
+
+2) 【推荐】 唯一索引必须以uidx_字段 1_字段 2 命名。
+
+3) 【强制】索引名称必须全部小写。
+
+#### 2.1.5 用户名命名
+
+1） 【推荐】生产业务用户名推荐： 库名_app。
+
+2） 【推荐】生产只读用户名推荐： 库名_read。
+
+3） 【推荐】线下研发查询账号用户名推荐： 库名_devread。
+
+4） 【推荐】监控用户名推荐： 库名_monitor。
+
+5） 【推荐】大数据抽数用户名推荐： 库名_dataextract。
+
+6） 【推荐】大数据推数用户名推荐： 库名_dataimport。
+
+7） 【推荐】DBA 管理员用户名推荐： 库名_dbaadmin。
+
+8） 【推荐】备份用户名推荐： 库名_bakadmin。
+
+#### 2.1.6 设计范式
+
+在数据库设计中，满足第一范式是最基本要求，一般说来，数据库的逻辑模型满足第三范式即可，在物理模型和持久化时就不一定要遵循第三范式，而会增加一定的数据冗余以提高查询性能。
+
+5
+
+### 2.2 SQL 设计规范
+
+#### 2.2.1 库 、表 、字段 、索引 SQL 设计规范
+
+1) 【强制】创建表时， 所有表和字段都必须添加注释。
+
+2) 【强制】禁止使用 BLOB 、TEXT 类型的字段， 如果要使用提前找 DBA 进行评估审核。
+
+3) 【强制】作为表间连接关系的字段，数据类型必须保持严格一致，避免索引无法正常使用。
+
+4) 【强制】快速增长的表， 比如充值记录 、订单记录， 必须考虑清理机制。
+
+5) 【推荐】对表结构多列变更用逗号分隔， 而不是写多条变更语句。
+
+正例： ALTER TABLE xxx ADD COLUMN name VARCHAR(100),MODIFY COLUMN address VARCHAR(1000),CHANGE COLUMN comment VARCHAR(200);#这样数据库只做一次数据复制；#如果写成多条， 每变更一次复制一次数据。反例： ALTER TABLE stu ADD COLUMN sex CHAR(1) NULL comment '性别' AFTER age;
+
+6) 【强制】禁止使用外键， 如果要使用提前找 DBA 进行评估审核。
+
+说明：外键用来保护参照完整性，可在业务端实现。对父表和子表的操作会相互影响， 降低可用性。
+
+7) 【强制】SELECT、UPDATE、DELETE 语句的 WHERE 条件列必须添加索引，
+
+除了一些低基数列可以不加。说明： 低基数列指一些选择性低的列， 例如“性别 ”、”状态 ”等。
+
+8) 【强制】不在 WHERE 条件的索引列进行数学运算和函数运算，这会导致无法使用列索引。
+
+正例： WHERE id +1 = 5 可以改成 WHERE id = 5 - 1。反例： SELECT offer_inst_id,offer_id, owner_cust_id,status_cd
+
+6
+
+WHERE commodity_type IN ('40','50') AND status_cd = '1000'AND offer_inst_id > 95050740400 AND To_days(Now()) - To_days(exp_date) >= 1#To_days( EXP_DATE )， 字段使用函数， 不能走索引。
+
+9) 【强制】禁止使用前缀是%的 LIKE， 如果确实必要需增加审批程序。
+
+说明：在 SQL 中尽量不使用 LIKE。即使使用也要禁止使用前缀是%的 LIKE 匹配， 因为索引文件具有 B Tree 的最左前缀匹配特性， 如果左边的值未确定，那么无法使用此索引。反例：SELECT cust_id,cust_code WHERE cust_name LIKE ‘%ja% ’;正例： SELECT cust_id,cust_code WHERE cust_name LIKE ‘ja% ’;
+
+10) 【强制】禁止在开发代码中使用TRUNCATE TABLE 语句。
+
+说明： TRUNCATE TABLE 可能会造成生产的性能事故和安全事故 。整表数据删除时，TRUNCATE 比 DELETE FROM 速度快，且使用的系统和事务日志资源少，但 TRUNCATE 执行不当有可能造成事故，且需要 create 和 drop 两个权限，故不建议在应用开发代码中使用此语句 。如果是 PXC 复制架构的环境， 严禁使用 truncate， 以免产生集群锁。
+
+11) 【强制】DELETE FROM 、UPDATE 语句， 必须带 WHERE 条件。
+
+说明：MySQL 任何复制架构严禁在业务高峰期使用没有 where 条件的 delete from语句一次性删除所有数据， 需分批删除 。delete from删掉的大表数据， 应选业务空闲期， 整理表碎片， 回收存储空间。
+
+12) 【强制】SQL 语句不可以出现隐式转换， 查询条件需要保证数据类型一致。说明： 隐式转换， 比如： int 同 char 进行比较。
+
+13) 【推荐】SQL 语句尽可能简单， 复杂 SQL 可拆分多个简单 SQL。
+
+14) 【推荐】事务要简单，整个事务的更新记录数不要太大，时间长度不要太长，要及时提交（多事务， 小事务原则） 。
+
+7
+
+15) 【推荐】避免使用反向查找， 如 NOT IN。
+
+16) 【推荐】避免超过 3 张表做关联， 如果要超过需提前找 DBA 进行评估审核。
+
+17) 【推荐】IN 操作能避免则避免， 若实在避免不了， 需要仔细评估 IN 后边的集合元素数量， 控制在 500 个之内。
+
+18) 【推荐】核心业务超过 100 毫秒的查询就是慢查询， 需要优化 SQL 脚本。
+
+### 2.3 流程规范
+
+#### 2.3.1 概述
+
+1) 【强制】所有的建表操作需要提前告知建该表的目的和当前使用的 sql 以及该表使用的相关业务场景。
+
+2) 【强制】所有的建表需要确定建立哪些索引后才可以建表上线。
+
+3) 【强制】所有的改表结构 、加索引操作都需要将涉及到所改表的查询 sql 需提前告知 DBA。
+
+4) 【强制】DDL 操作，必须至少提前一天向 DBA 发起申请， 由 DBA 对操作内容和时间进行评估。
+
+5) 【强制】批量读取 、刷新 、导入 、导出数据， 超过 5 万条记录， 必须提前通知 DBA 协助观察。
+
+6) 【强制】禁止有 super 权限的应用程序账号存在。
+
+7) 【强制】严禁在业务高峰期大批量更新（超过 10 万条数据） 、插入或查询数据库。
+
+说明： 如有违反极易造成生产事故。
+
+8) 【强制】严禁在业务高峰期 ALTER 表结构。
+
+说明： 如有违反极易造成生产事故。
+
+9) 【强制】严禁在业务高峰期创建索引。
+
+说明： 如有违反极易造成生产事故。
+
+10) 【强制】严禁在业务高峰期更新索引统计信息（ANALYZE TABLE 表名） 。说明： 如有违反极易造成生产事故。
+
+8
+
+11) 【强制】严禁在业务高峰期整理表碎片。
+
+说明： 如有违反极易造成生产事故。
+
+12) 【强制】业务高峰期 DDL 变更，必须提前向 DBA 发起申请， 由 DBA 对操作内容和时间进行评估。
+
+13) 【强制】数据库慢查询语句必须一周内完成整改。
+
+14) 【强制】禁止随意在生产环境进行数据库压力测试， 压力测试必须提前向DBA 发起申请， 由 DBA 对操作内容和时间进行评估。
+
+15) 【强制】禁止从开发环境 、测试环境数据库直接连接生产环境数据库。
+
+16) 【推荐】发布到生产的表结构应设有主键。
+
+17) 【强制】严禁在任何复制架构的从库上执行 select 以外的其他语句， 严禁任何写操作的发生。
+
+18) 【强制】严禁在任何复制架构的主库上执行导出操作（比如 MySQLdump 等），只能在从库执行。
+
+19) 【强制】禁止在生产环境发布大事务 SQL 。代码中发现有大事务的， 应及时拆分或者采用其他方式避免。
+
+20) 【强制】数据库账户用途要明确， 不能存在非法的账户。
+
+21) 【强制】创建用户的时候限制用户的登录主机，主机使用 IP 地址或 IP 网段，禁止使用主机名或%。
+
+22) 【强制】初始化数据库后删除无密码的用户， 删除测试库。
+
+23) 【强制】为每个用户设置满足密码复杂度不低于 16 位的包含大小写特殊字符的密码。
+
+24) 【强制】定期清理不需要的用户， 非平台业务类的账号要定期修改密码。
+
+25) 【强制】脚本涉及账户 、 口令等重要信息的脚本不得随意泄漏和传播 。脚本需项目专人统一保存， 并进行版本管理 。上线前需做到同行评审。
+
+26) 【强制】生产数据库导出到非生产环境的， 需要经过流程报备， 并对敏感数据进行脱敏处理。
+
+27) 【推荐】定期监控数据库数据目录空间使用率。
+
+28) 【推荐】对于程序连接数据库的账号只授予能满足需要的最小权限。
+
+说明：程序使用数据库账号只能在一个 DB 下使用，不准跨库程序使用的账9
+
+号， 原则上不准有 drop 权限。
+
+29) 【推荐】对于超过 100 万行的大表或者核心表进行表结构更改，须经过 DBA审核， 并在业务低峰期执行。
+
+30) 【推荐】数据变更时， 如删除和修改记录， 删除整张表， 要先 select， 校验操作的数据， 确认数据无误， 并备份原始数据， 准备好回滚方案后， 才能执行生产变更。
+
+31) 【推荐】数据库账户新增或已存在账户的权限调整均需要经过流程审批、并录入系统。
+
+10
+
+## 3 主流数据库开发规范
+
+### 3.1 PostgreSQL 开发规范
+
+本规范适用于 PostgreSQL 12.3 及以前所有内核版本，同样也适用于 TeleDB4PG
+
+#### 3.1.1 对象名称规范
+
+1) 【推荐】DB Name（数据库名）与 service name（业务名）保持一致， 是所有基础设施的名称
+
+2) 【强制】DB name 与 table name 需要注意长度限制， 不能超过 64 位
+
+3) 【强制】DB 内的对象名只能使用小写字母 、数字 、下划线， 不能使用其他字符
+
+4) 【强制】query 中的别名只能使用小写字母 、数字 、下划线， 不能使用其他字符
+
+5) 【推荐】主键索引应以 pk_ 开头，唯一索引必须以uidx_字段 1_字段 2 命名，非唯一索引必须以 idx_字段 1_字段 2 命名，不足以区分时可以增加表名等辅助信息
+
+6) 【推荐】不同业务的数据以 database 进行区分， 默认都使用 public schema，以方便开发人员与其他数据库使用习惯兼容
+
+7) 【推荐】建议所以可以添加comment 的地方均添加comment， 且以英文描述
+
+#### 3.1.2 对象设计规范
+
+1) 【推荐】PG 中最常用的是数字 、字符 、时间类型 。设计时应尽可能选择合适的数据类型， 能用数字， 就不用字符串 。能用限定长度的varchar 类型，就不用大对象类型 。使用正确的数据类型， 可以匹配数据库的索引， 操作符和函数， 可以提高数据的查询效率。
+
+2) 【强制】在创建表结构时， 需要考虑创建对应的索引， 避免全表扫描。
+
+11
+
+3) 【强制】多个 table 中相同的列， 或者进行 join 的列， 需要保证列名一致，数据类型一致。
+
+4) 【推荐】Btree索引的字段不建议超过 2000 字符， 如果超过， 建议使用函数索引或分词索引。
+
+5) 【强制】表结构中定义的数据类型，必须与应用程序中的定义一致， 表之间的校对规则一致， 避免报错或无法使用索引的情况发生。
+
+6) 【推荐】考虑全球化需求，所有字符存储和表示，均以 UTF-8 编码。所有数据内与时间相关的数据， 时区均为 UTC 时间， 最好使用 int 或 bigint 存储秒或毫秒 。业务程序可以根 据需求， 进行前端显示的时区转换。
+
+7) 【强制】PG 中应尽量避免触发器的使用， 这会使数据处理和数据库迁移逻辑复杂， 不便于调试。
+
+8) 【强制】有定时海量数据需要归档和删除的表， 应考虑表按时间列分区， 归档后清理时， 不 要使用 delete， 而是用 drop 或 truncate 清理对应表。
+
+9) 【强制】未使用的大对象，一定要定时删除部分数据，否则大对象就会一直在数据库中， 占用内存导致内存泄露。
+
+10) 【推荐】对于大型文本类数据进行查询时， 要尽量避免 like %xxx% 的模糊匹配 。如果实在有类似需求， 可以考虑在 PG 中建立 gin 索引， 或者使用专门的 ES 等搜索系统。
+
+11) 【强制】对于频繁使用的大表（大小超过 10GB， 或者记录数超过 1000 万）应考虑进行分区， 保证单表比较小， 可以提升查询效率 、更新的效率 、创建索引的效率 、备份恢复的效率等
+
+#### 3.1.3 大对象设计规范
+
+1) 【强制】PG 在设计表结构时， 建议尽量规划好， 避免后续经常添加新列，
+
+或者修改数据类型。某些操作可能会触发表的重写， 例如添加新列并有默认值， 修改字段的类型。
+
+2) 【强制】如果用户不好规划结构， 可以考虑使用 jsonb 类型存储用户数据。
+
+3) 【强制】Jsonb 类型的存储内容需要合理规划， 对于经常需要查询的 value，也可以创建单个字段或 多个字段的 btree索引， 提高查询性能。
+
+12
+
+4) 【推荐】使用 jsonb 修改数据时， 建议使用 jsonb_set 函数， 同时区分好如果修改对象上一级是否存在， 修改对象不存在时， 是否需要新增。
+
+5) 【强制】 对于 jsonb 中的对象，不要存放过多数据。如果数据过多， 会影响查询和更改性能 。可以考 虑规划存放不同数据在多个列， 或多个表中。
+
+6) 【强制】如果 jsonb 中查询对象不是一个 value， 而是一个集合， 则需要将集合根据范式设计， 拆分到新表中， 避免查询时扫描所有的 jsonb 数据。
+
+7) 【推荐】对于 jsonb 中一些需要进行检索的内容， 可以考虑创建 gin 索引。
+
+#### 3.1.4 查询规范
+
+1) 【强制】PG 在查询数据时，要在 select 后写明需要查询的所有列名，不要返回不使用的任何字段， 不要使用 select * ， 这样会查询过多内容， 也可能出现程序匹配错误。
+
+2) 【强制】PG 在查询时， 一定要考虑查询返回数据量， 避免一次 SQL 返回过多数据， 影响查询性能和网络。
+
+3) 【强制】在统计数量时， 应使用 count(*)， 而不用 count(col_name)， 或者count(1)。
+
+4) 【强制】在 count 多列列名时， 必须使用括号 count(col1,col2,col3)。
+
+5) 【强制】在查询中应清楚 NULL 值的含义和使用， NULL 值不是任意一个确定的值，NULL 与任意值逻辑判断都返回 NULL。例如在 count(distinct col)中，只计算非 NULL 列的不重复结果， NULL 列不会被计算。
+
+6) 【强制】应避免向客户端返回大量的数据, ETL 程序除外 。若返回数据量过大， 应考虑需求是否合理。
+
+#### 3.1.5 数据操作规范
+
+1) 【强制】PG 数据订正时， 删除和修改数据时， 要先 select， 避免误删除， 要确认无误后才能提交执行。
+
+13
+
+2) 【强制】大批量删除和更新数据时， 不要在一个事物中完成， 建议分批次操作， 避免一次产生较多 垃圾和日志， 对系统资源和相关系统产生不好的影响。
+
+3) 【强制】大批量数据入库，可以使用 copy 语法，或者 insert into table value(),(),();的方式， 提高写入速度。
+
+4) 【强制】DDL 操作与其他可能获取大锁的操作（如 vacuum full，create index）可以设置锁等待， 防止堵塞与 DDL 锁相关的所有 query。
+
+5) 【强制】 可以使用 explain 查询 SQL 的执行计划， 使用 explain analyze 就会实际执行 SQL 并显示对 应的执行计划。
+
+6) 【强制】 创建 index 时，为了并行创建，不阻塞其他 DML，可以添加 create index concurrently 关 键字。
+
+7) 【强制】 如果 PG 实例配置了 standby，并且使用了 slot，则必须监控 stadnby实例的延时和slot 的状 态， 否则可能会造成主库 XLOG 不断堆积， 占满空间而产生问题
+
+#### 3.1.6 稳定性规范
+
+1) 【强制】PG 中应避免长事务， 长事务会造成垃圾膨胀。
+
+2) 【强制】PG 在代码中写分页逻辑时，如果count 为 0 应直接返回，避免执行后续的分页语句。
+
+3) 【强制】两阶段提交的事务，要及时提交或回滚，否则可能导致数据库膨胀。
+
+4) 【强制】在高并发场景下， 务必使用程序的连接池，否则性能会很低下 。如果程序没有连接池， 可以考虑使用 pgpool-II 或 pgbouncer 中间件。
+
+5) 【强制】程序务必要有重连机制， 如果没有重连机制，一个长期空闲的链接可能会被强制断开， 数据库高可用切换后， 程序也可能有问题。
+
+6) 【强制】必须使用合理的隔离级别， 不要越级使用隔离级别， 以满足业务需求为准。
+
+7) 【强制】高峰期对大表添加新列时， 建议先不加默认值， 避免rewrite， 后面再用业务逻辑添加默认值。
+
+14
+
+8) 【强制】 自增字段建议使用序列， 根据情况选择 2 字节 、4 字节或 8 字节。禁止使用触发器产生序列。
+
+9) 【强制】线上表结构的变更， 包括添加字段 、索引等， 应尽量在业务低峰期执行。
+
+10) 【强制】OLTP 系统在业务高峰期或高并发期间， 应拒绝长 SQL 、大事务、大批量。
+
+11) 【强制】冷热数据要进行分离，尽量保证线上实例只存在有限的经常查询的数据
+
+#### 3.1.7 索引优化规范
+
+1) 【强制】访问 PG 的查询 SQL 应进行查询优化， 尽量避免全表扫描， 首先要考虑在 where, order by,group by 的列上， 建立索引 。 查询特别多的 SQL 要考虑满足覆盖索引。
+
+2) 【强制】应尽量避免在 where 子句中使用 != 或 <> 操作符，这种不等于会让 PG 放弃索引， 使用全表扫描。
+
+3) 【强制】索引应该建在选择性高的字段或小字段上，选择性低的字段 、大的文本字段一级超长字段不应建索引。
+
+4) 【强制】复合索引要符合最左原则，将选择性最好的字段作为第一个列， 其他非第一个字段的列， 如果经常会有查询用到， 也需要创建单独的索引。
+
+5) 【强制】频繁进行数据操作的表， 不要建立太多的索引， 因为索引会降低数据操作的性能， 增大数据操作的成本。
+
+6) 【强制】对于 btree 索引、hash 索引、gin 索引、gist 索引、BRIN 索引要根据不同的索引特点和适用场景进行合理选择和使用。
+
+7) 【强制】对于无用的索引要及时删除，无用的索引不仅会导致更新数据的代价变大， 还可能产生错误的执行计划。
+
+8) 【强制】所有的新程序的表结构和 SQL 在上线前最好与 DBA 确认是否都有索引再上线到生产环境。
+
+### 3.2 MySQL 开发规范
+
+15
+
+本规范适用于 MySQL5.7 和 8.0 版本， 同样也适用于 TeleDB4MySQL。
+
+#### 3.2.1 对象名称规范
+
+l 库名命名
+
+1) 【强制】库名只能含有字母 、数字和下划线“_ ”三类字符。
+
+2) 【强制】库名必须使用小写字母， 用下划线“_ ”分割。
+
+3) 【强制】库名禁止超过 32 个字符， 须见名知意。
+
+4) 【强制】库名禁止使用数据库特殊关键字重名。
+
+5) 【强制】 临时库库名必须以 tmp 开头， 以创建人的简拼字母和日期为后缀。
+
+6) 【强制】备份库库名必须以 bak 开头， 以创建人的简拼字母和日期为后缀。
+
+l 表名命名
+
+1) 【强制】表名只能含有字母 、数字和下划线“_ ”三类字符。
+
+2) 【强制】表名必须使用小写字母， 用下划线“_ ”分割， 普通业务表以 t_开头（或有意义的简写）_+table_name。
+
+3) 【强制】表名禁止超过 32 个字符， 须见名知意。
+
+4) 【强制】表名禁止使用数据库特殊关键字命名。
+
+5) 【强制】 临时表表名必须以 tmp 开头， 以创建人的简拼字母和日期为后缀。正例： 示例创建人在 2022 年 4 月 21 日建了一张临时表， tmp_xxxxxxx_zs20220421
+
+6) 【强制】备份表表名必须以 bak 开头， 以创建人的简拼字母和日期为后缀。正例： 示例创建人在 2022 年 4 月 21 日建了一张临时表， bak_xxxxxxx_zs20220421
+
+l 字段名命名
+
+1) 【强制】字段名必须使用小写字母， 用下划线“_ ”分割。
+
+2) 【强制】字段名禁止超过 32 个字符， 须见名知意。
+
+3) 【强制】字段名禁止使用数据库特殊关键字命名。
+
+l 索引命名
+
+1) 【推荐】非唯一索引必须以 idx_字段 1_字段 2 命名。
+
+2) 【推荐】 唯一索引必须以uidx_字段 1_字段 2 命名。
+
+3) 【强制】索引名称必须全部小写。
+
+l 用户名命名16
+
+1) 【推荐】生产业务用户名推荐： 库名_app。
+
+2) 【推荐】生产只读用户名推荐： 库名_read。
+
+3) 【推荐】线下研发查询账号用户名推荐： 库名_devread。
+
+4) 【推荐】监控用户名推荐： 库名_monitor。
+
+5) 【推荐】大数据抽数用户名推荐： 库名_dataextract。
+
+6) 【推荐】大数据推数用户名推荐： 库名_dataimport。
+
+7) 【推荐】DBA 管理员用户名推荐： 库名_dbaadmin。
+
+8) 【推荐】备份用户名推荐： 库名_bakadmin。
+
+#### 3.2.2 对象设计规范
+
+1) 【强制】INT 类型不使用 unsigned 无符号属性。
+
+2) 【强制】 自增用 8 字节 BIG INT， 不要使用 4 字节 INT。
+
+3) 【强制】字符集使用 UTF8MB4 字符编码， 不推荐 GBK 、UTF-8 等其他字符集。
+
+4) 【强制】 日期类型用 DATETIME 类型， 需要精确到毫秒用 DATETIME(6)，不要使用 INT 、TIMESTAMP。
+
+5) 【强制】类型 JSON 可用于存储非结构化数据，典型场景为用户标签，不要将 JSON 用于频繁更新的字段场景。
+
+6) 【推荐】对于日志类的流水表 、报警表 、 日志表， 可以使用压缩设计， 提升存储效率。
+
+7) 【强制】类别设计， 用 ENUM+CHECK 约束， 不要使用 INT 类型的设计。
+
+8) 【强制】敏感字段需加密，如账户密码、信用卡号等存储使用：动态盐 + 非固定加密算法（MD5/AES256 等） + 多轮加密， 不要简单使用 MD5 算法加密。
+
+9) 【推荐】若业务只是简单的 SET、GET 请求，可考虑将其转化为Memcached的 KV 访问方式， 减少 SQL 解析的开销。
+
+10) 【强制】InnoDB 和 MyISAM 存储引擎表，索引类型必须为 BTREE；MEMORY表可以根据需要选择 HASH 或者 BTREE 类型索引。
+
+17
+
+11) 【推荐】在建立索引时， 多考虑建立联合索引， 并把区分度最高的字段放在最前面 。 区分度可由 select count(distinct col_name)计算得出。
+
+12) 【推荐】建表或加索引时，保证表里互相不存在冗余索引。若表里已经存在key(a, b)， 则 key(a)为冗余索引， 需要删除。
+
+#### 3.2.3 大对象设计规范
+
+1) 【推荐】建议对表里的blob 、text 等大字段， 垂直拆分到其他表里， 仅在需要读这些对象的时候才去 select。
+
+2) 【强制】对于超过 100W 行的大表进行 alter table， 必须经过 DBA 审核， 并在业务低峰期执行 。alter table 会产生表锁， 期间阻塞对于该表的所有写入，对于业务可能会产生极大影响。
+
+#### 3.2.4 查询规范
+
+1) 【强制】SELECT 语句必须指定具体字段名称， 禁止写成*。
+
+2) 【推荐】SELECT 语句不建议 UNION， 推荐 UNION ALL， 并且 UNION 子句个数限制在 5 个以内。
+
+3) 【推荐】in值列表限制在 500 以内， 减少底层扫描。
+
+4) 【推荐】查询时，一定要考虑查询返回数据量，避免一次 SQL 返回过多数据。
+
+5) 【强制】在统计数量时， 应使用 count(*)或 count(1)， 而非 count(col_name)。
+
+6) 【强制】 除静态表或小表（100 行以内）， DML 语句必须有 where 条件， 且使用索引查找。
+
+7) 【推荐】减少使用较为耗费 CPU 的 order by、group by、distinct，建议将排序放到程序端去做。
+
+8) 【推荐】order by、group by、distinct 这些 SQL 尽量利用索引直接检索出排序好的数据 。如 where a=1 order by 可以利用 key(a, b)。
+
+9) 【推荐】包含了 order by 、group by 、distinct 这些查询的语句， where 条件过滤出来的结果集建议保持在 1000 行以内。
+
+10) 【推荐】在多表 join 的 SQL 里， 保证被驱动表的连接列上有索引。
+
+18
+
+11) 【推荐】SELECT 字段 FROM 表 a where limit c1,c2 这里 c1 很大例如几
+
+十万 、几百万时， 会产生潜在的性能问题， 可以结合子查询为查询提速。
+
+#### 3.2.5 数据操作规范
+
+1) 【强制】禁用 update|delete t1 … where a=XX limit XX; 这种带 limit 的更新语句， 可能会导致主从不一致， 导致数据错乱。
+
+2) 【强制】禁止使用关联子查询， 如 update t1 set … where name in(select name from user where…); 效率较低。
+
+3) 【推荐】建议不使用 procedure、function、trigger、views、event、外键约束等消耗数据库资源和降低数据库实例可扩展性的语句， 在程序端实现。
+
+4) 【强制】禁用 insert into …on duplicate key update …，高并发环境下会造成主从不一致。
+
+5) 【强制】禁止联表更新语句， 如 update t1,t2 where t1.id=t2.id…。
+
+#### 3.2.6 稳定性规范
+
+1) 【推荐】insert into …values(XX),(XX),(XX) … 。XX 的值不要超过 5000 个， 值过多容易引起主从同步延迟。
+
+2) 【强制】事务里批量更新数据需要控制数量，进行必要的sleep，做到少量多次。
+
+3) 【强制】生产环境禁止使用 hint， 如 sql_no_cache， force index， ignore key， straight join 等。
+
+4) 【推荐】写入和事务发往主库， 只读 SQL 发往从库。
+
+5) 【强制】SELECT|UPDATE|DELETE|REPLACE 要有 WHERE 子句，且 WHERE子句的条件必需使用索引查找。
+
+#### 3.2.7 索引优化规范
+
+1) 【强制】无需设置单表行数 、列数限制。
+
+2) 【推荐】在核心业务中， 使用索引覆盖技术， 提升索引查询性能； 19
+
+3) 【强制】对类似 WHERE a = ? ORDER BY b 这样的查询， 一定要创建（a、 b） 组合索引， 这样可以避免一次额外排序， 提升查询性能。
+
+4) 【推荐】MySQL 的查询基于成本而不是规则，若发现 SQL 执行计划发生变化， 先分析数据特点 、索引创建是否合理。
+
+5) 【推荐】对于 OLTP 业务，一定要做好索引的设计和索引覆盖的考虑（不考虑分布式数据库场景）； 对于 OLAP 业务中的大数据量的关联， 建议使用大数据产品， 如 Hive 、Spark 等产品。
+
+6) 【强制】上线前必须确认编写的子查询不能是关联子查询，若发现关联子查询， 改写子查询为 JOIN 或其他方式。
+
+7) 【推荐】不推荐使用分区表， 考虑分区表唯一的应用场景是： 需要定期清理历史流水类数据。
+
+8) 【强制】业务上线或新版本发布前， DBA 一定要进行所有 SQL Review， 确保 SQL 走索引，否则不予上线，或由业务以邮件等正式方式，通知 DBA 该SQL 不会引起线上事故， 业务方承担后续责任。
+
+9) 【强制】DBA 每天要对数据库进行巡检，及早发现慢查询或潜在数据库风险，将任何潜在问题尽早抛出， 否则后续自己承担相关责任。
+
+### 3.3 HTAP 开发规范
+
+本规范适用于 TiDB 5.4 及以前所有内核版本， 同样也适用于 TeleDB4HTAP。
+
+#### 3.3.1 对象名称规范
+
+1) 【推荐】命名建议使用具有意义的英文词汇， 词汇中间以下划线分隔。
+
+2) 【强制】命名只能使用英文字母 、数字 、下划线。
+
+3) 【强制】避免用关键字或保留字如 group， error， rank 等作为对象名。
+
+4) 【推荐】建议所有的数据库对象使用小写字母。
+
+5) 【强制】所有的数据库对象的命名请注意标识符长度硬限制。
+
+20
+
+#### 3.3.2 数据库命名规范
+
+1) 【强制】按照业务模块 、产品线和访问权限隔离需求来创建数据库， 如： 基础信息库（basicinfo_db） 、认证中心库（certifycenter_db） 。
+
+2) 【推荐】建议数据库名称不要超过 16 个字符。
+
+#### 3.3.3 表命名规范
+
+1) 【强制】同一业务或者模块的表尽可能使用相同的前缀，表名称尽可能表达含义。
+
+2) 【强制】多个单词以下划线分隔， 不推荐超过 32 个字符。
+
+3) 【推荐】建议对表的用途进行注释说明， 以便于统一认识， 如： 临时表
+
+（tmp_t_crm_relation_0425） 、备份表（bak_t_crm_relation_20170425） 、业
+
+21
+
+务运营临时统计表（tmpst[业务代码][创建人缩写][日期]） 、账期归档表（t_crm_ec_record_YYYY[MM][DD]） 。
+
+4) 【强制】不同业务模块的表单独建立 DATABASE， 并增加相应注释。
+
+5) 【强制】只支持将 lower-case-table-names 值设为 2，即数字字典中记录的名区分大小写， 匹配查找表名时不区分大小写。
+
+#### 3.3.4 字段命名规范
+
+1) 【强制】字段命名需要表示其实际含义的英文单词或简写。
+
+2) 【推荐】建议各表之间相同意义的字段应同名， 并且一定使用相同的字段类型。
+
+3) 【强制】字段也尽量添加注释，枚举型需指明主要值的含义，如“0 - 离线， 1 - 在线 ”。
+
+4) 【强制】布尔值列命名为 [is_描述]。如 member 表上表示为 enabled 的会员的列命名为 is_enabled。
+
+5) 【推荐】字段名不建议超过 32 个字符。
+
+#### 3.3.5 索引命名规范
+
+1) 【推荐】主键索引： pk_表名_字段 1_字段2。存在多个字段时， 多个字段名简写用下划线分隔。
+
+2) 【推荐】 唯一索引： uidx_表名_字段 1_字段2 。存在多个字段时， 多个字段名简写用下划线分隔， 不足以区分时可以增加表名等辅助信息。
+
+3) 【推荐】普通索引：idx_表名_字段 1_字段2。存在多个字段时，多个字段名简写用下划线分隔。
+
+4) 【强制】多单词组成的字段名， 使用能代表意义的缩写。
+
+22
+
+#### 3.3.6 对象设计规范
+
+##### 3.3.6.1 表的设计
+
+1) 【强制】表需要有主键或者非空唯一索引， 能与各项复制工具更好地兼容。
+
+2) 【强制】业务表使用自增主键时， 字段类型推荐使用 bigint unsigned， 最大值可达 18446744073709551615。
+
+3) 【强制】出于性能考虑， 应避免存储超宽表，数据长度过大的字段应拆分存储到独立的数据表，单行数据大小不能超过 6 MB。建议单表字段数不超过 60个， 单行数据大小不超过 64K。
+
+4) 【推荐】不推荐使用复杂的数据类型， 如 blob 或者 json。
+
+5) 【强制】进行 join 的关联字段， 数据类型保证一致， 避免隐式转换。
+
+6) 【强制】不能以范式作为唯一标准或者指导，在设计过程中， 需要从实际需求出发，以性能提升为根本目标来展开设计工作。为了提升性能减少表关联，可以适当保存冗余数据做反范式设计。
+
+7) 【强制】表对象的设计请注意单个 Table 的限制 。
+
+. Columns 的最大限制可通过 table-column-count-limit 修改。. Indexs 的最大限制可通过 index-limit 修改。23
+
+##### 3.3.6.2 字段的设计
+
+1) 【推荐】所有整数类型的字段推荐只使用 INT 或者 BIGINT。
+
+2) 【推荐】BIGINT 定义中不推荐添加长度。
+
+3) 【推荐】推荐使用 INT(10) UNSIGNED 存储 IPv4 格式 IP 地址。
+
+4) 【推荐】浮点类型推荐使用 DECIMAL 。
+
+5) 【强制】 时间字段使用时间日期类型， 不要使用字符串类型存储。
+
+6) 【强制】所有只需要精确到天的字段全部使用 DATE 类型， 而不应该使用TIMESTAMP 或者 DATETIME 类型。
+
+7) 【强制】所有需要精确到时间(时分秒)的字段均使用 DATETIME， 不要使用TIMESTAMP 类型。
+
+8) 【推荐】仅当字符数量可能超过 20000 个的时候，才建议使用TEXT 类型来存放字符类数据。所有使 TEXT 类型的字段建议和原表进行分拆，与原表主键单独组成另外一个表进行存放。
+
+9) 【推荐】当使用宽字段类型（如 Text、MediumBlob、MediumText） 时， 需注意读取并发度， 以控制内存使用预防 OOM 。
+
+10) 【推荐】不建议使用 ENUM 、SET 类型， 尽量使用 TINYINT 来代替。
+
+##### 3.3.6.3 字符集
+
+1) 【强制】建表时只使用默认的 utf8mb4 编码。
+
+2) 【推荐】utf8mb4 的默认排序规则为 utf8mb4_bin（区分大小写）， 支持
+
+utf8mb4_general_ci（不区分大小写）， 但是需要集群部署时配置新的排序规则框架（new_collations_enabled_on_first_bootstrap 设置为 true） 。
+
+##### 3.3.6.4 列的自增属性
+
+1) 【强制】列的自增属性仅保证唯一， 仅能保证在单个计算节点中自增， 不保证多个计算节点中自增，不保证自动分配的值的连续性。业务不应该依赖自
+
+24
+
+增属性的连续性和有序性， 如记录的插入顺序排序应按照记录的创建时间。带有自增属性的列出现空洞和跳跃插入的现象是正常现象。
+
+2) 【强制】不要在语句中显式指定具有自增属性的列的值，由数据库自动分配，否则可能会出现值重复冲突。
+
+3) 【强制】允许移除列的 AUTO_INCREMENT 属性， 但是请谨慎评估， 移除该属性后不可恢复。
+
+##### 3.3.6.5 创建 、删除表规范
+
+1) 【强制】表的建立在遵循表命名规范前提下，如果业务应用内部封装建表删表语句，需要增加判断逻辑，防止业务流程异常中断。例如：create table if not exists table_name 或者 drop table if exists table_name 语句建议增加 if 判断，避免应用侧由于表的改动造成的异常中断。
+
+2) 【强制】不支持 create table as select 语法， 需要改写为表结构复制 create table like … 和将数据写入的 insert into select … 的组合语句。
+
+##### 3.3.6.6 变更表规范
+
+1) 【强制】不支持单条 ALTER TABLE 语句中完成多个操作，不能在单个语句中添加多个列或索引， 需要更换成多个单个列或索引的操作。
+
+2) 【强制】不支持对字段类型的有损修改或修改为超集。
+
+##### 3.3.6.7 视图使用规范
+
+1) 【推荐】支持为应用程序建立专门的视图而不必非要应用程序直接访问数据表。
+
+2) 【强制】视图不可更新，不支持 UPDATE、INSERT、DELETE 等写入操作。
+
+25
+
+##### 3.3.6.8 分区表规范
+
+1) 【推荐】当数据需要按时间进行归档清理时，可按某个业务时间段对表进行分区， 对分区进行 truncate 操作满足数据清理要求。
+
+2) 【强制】按时间进行分区表的粒度应该将分区记录数控制在十亿级别，不应该配置太小， 如日分区， 也不应太大， 如年分区。
+
+3) 【强制】在分区表上进行查找时， 查找条件必须包含分区字段的查找条件。分区表的二级索引属于分区内索引，需要先通过分区裁剪的方式，定位到具体分区后再经过二级索引回表查找。
+
+#### 3.3.7 查询规范
+
+##### 3.3.7.1 大事务处理
+
+1) 【强制】单个事务的总大小默认不超过 100 MB， 最大支持 10 GB， 实际的单个事务大小限制还取决于服务器剩余可用内存的大小， 执行事务时 TiDB进程的内存消耗大约是事务大小的 6 倍以上。
+
+2) 【强制】应做好事务执行的内存容量评估。注意执行事务时 TiDB 进程的内存消耗大约是事务大小的 6 倍以上， 事务设置过大， 或者 Batch 过高， 会导致 tidb-server OOM。
+
+3) 【强制】为了使性能达到最优， 需要对大事务按某个业务维度进行拆分，每100～500 行提交一个事务。
+
+##### 3.3.7.2 SELECT * 使用规范
+
+1) 【强制】禁止使用 SELECT * 进行查询 。建议按需求选择合适的字段列， 杜绝直接 SELECT * 读取全部字段， 减少网络带宽消耗， 有效利用覆盖索引。
+
+26
+
+##### 3.3.7.3 分页查询 order by 语法使用规范
+
+1）【强制】分页查询语句需要带有排序条件， 除业务排序条件外还应包含主键或者其他唯一键以保证分页稳定， 规避没有业务排序字段或者一个业务排序字段值匹配多条记录导致结果集不稳定； 常规分页语句写法(start:起始记录数,page_offset:每页记录数)： select * from table_a t order by gmt_modified
+
+desc,pk limit start， page_offset。
+
+##### 3.3.6.1 group by 语法使用规范
+
+1) 【强制】select 字段中不得引用未在 group by 子句中声明的非聚集字段，即不得使用 MySQL non-full group by 语法; 以下的语句是不被允许的， select class,stuname,max(score) as max_score from score group by class。
+
+##### 3.3.7.4 多表关联查询规范
+
+1) 【强制】多表关联应该显式使用 join子句，避免漏掉关联条件， 造成笛卡尔积。
+
+2) 【强制】嵌套 SQL 语句应该为不同表指定不同别名。
+
+3) 【强制】高并发交易场景， 单条语句关联表不超过两张， 使用执行计划为 IndexJoin 的多表关联语句，外表建立了正确的条件过滤索引，内表建立了正确的关联和条件过滤索引。
+
+4) 【强制】低并发的分析场景， 单条语句关联表不超过 10 张， 其中亿级表不超过 2 张 。需要注意 tidb_mem_quota_query 参数指定的单条语句内存使用限制， 默认是 1GB， 生产建议不超过 16 GB。
+
+#### 3.3.8 数据操作规范
+
+27
+
+##### 3.3.8.1 防范写入热点创建规范
+
+1) 【强制】对于写入量非常大的表，应当通过应用性能压测等方法在测试环境模拟表的热点情况。
+
+2) 【强制】通过以下三种手段进行配置， 规避表的主键写入热点 。 避免连续自增主键的设计， 建议采用雪花算法生成 UUID 主键； 主键是非整数的表或者启用 alt-primarykey=true 配置后创建的所有表， 使用
+
+SHARD_ROW_ID_BITS 语法创建基于 rowid 的分片方案， 例如： CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4 或 ALTER TABLE t SHARD_ROW_ID_BITS = 4; 创建按照 Hash 或 Range 分区表避免热点。
+
+##### 3.3.8.2 数据删除规范
+
+1) 【强制】删除表中全部的数据时， 使用 TRUNCATE 或者 DROP 后重建方式，不要使用 DELETE 。以上几种数据删除方法执行后，都不会立即释放空间，需要等待 数据库后台的 GC (garbage collection) 和 Compaction 机制对空间回收后重新利用。
+
+2) 【强制】对于按范围进行部分数据的删除， 如果超过大事务的限制， 可以参考以下窗口函数的方法， 分成批量小任务进行数据的删除；
+
+a. 将数据按照主键排序， 然后调用窗口函数 row_number() 为每一行数据生成行号，接着调用聚合函数按照设置好的页大小对行号进行分组，最终计算出每个分组的行号的最小值和最大值。MySQL [demo]> select min(t.serialno) as start_key, max(t.serialno) as end_key, count() as page_size from ( select , row_number () over (order by serialno) as row_num from tmp_loan ) t group by floor((t.row_num - 1) / 50000) order by start_key;
+
+| start_key | end_key | page_size |
+
+| 200000000 | 200050001 | 50000 | | 200050002 | 200100007 | 50000 | 28
+
+| | | || 201900019 | 201950018 | 50000 | | 201950019 | 201999003 | 48985 |
+
+## 40 rows in set (1.51 sec)
+
+b. 借助计算好的分组信息，使用 serialno between start_key and end_key 操作每个分组的数据， 实现高效数据删除或者更新。
+
+#### 3.3.9 稳定性规范
+
+1) 【强制】所有的建表操作需要提前告知 DBA 该表涉及的查询 SQL。
+
+2) 【强制】所有的建表需要确定建立哪些索引后才可以建表上线。
+
+3) 【强制】所有的改表结构、加索引操作都需要将涉及到所改表的查询 SQL 发出来告知 DBA 等相关人员。
+
+4) 【强制】在建新表加字段之前， 建议开发人员提前发出给 DBA 评估 、优化和审核。
+
+5) 【强制】批量导入 、导出数据必须提前通知 DBA 协助观察。
+
+6) 【强制】大批量统计更新， 如临时统计， 应避开高峰期并通知 DBA。
+
+7) 【强制】推广活动或上线新功能必须提前通知 DBA 进行流量评估。
+
+8) 【强制】及时处理已下线业务的 SQL。
+
+#### 3.3.10 索引优化规范
+
+1) 【强制】选择区分度大的列建立索引，不在低基数列上建立索引，例如：“性别 ”， “是否是 XXX ”。
+
+2) 【强制】单张表的索引数量控制在 5 个以内， 避免冗余索引。
+
+3) 【推荐】索引中的字段数建议不超过 5 个。
+
+4) 【强制】 唯一索引建议由 3 个或更少的字段组成。
+
+29
+
+5) 【强制】不应在频繁更新的列上创建索引。
+
+6) 【强制】应该将使用频率高的，经常被点查使用的列排在复合索引靠前的位置， 将经常进行范围查询的列排在后面。
+
+7) 【推荐】很长的 VARCHAR 字段建立索引时， 指定索引长度， 没必要对全字段建立索引， 根据实际文本区分度决定索引长度即可， 例如
+
+idx_table_name (name(10))。
+
+8) 【强制】定期删除一些长时间未使用过的索引。
+
+9) 【强制】ORDER BY，GROUP BY，DISTINCT 的字段需要添加在索引的后面，形成覆盖索引。
+
+10) 【强制】新的 select,update,delete 上线， 都要先执行 explain 命令， 观察执行计划是否有异常情况发现， 以确保索引的正确性。
+
+11) 【推荐】不建议在 where 条件索引列上使用函数， 会导致索引失效， 如lower(email)。
+
+12) 【推荐】使用 like 模糊匹配， % 不要放首位， 会导致索引失效 。业务语句中使用 like 查找字符串不使用 % 放首位，或者使用时结合其他有效的约束条件。
+
+### 3.4 UDAL 开发规范
+
+本开发规范适用于 UDAL 所有内核版本。
+
+#### 3.4.1 对象名称规范
+
+本部分适用对象包括库 、表 、表字段 、全局序列 、用户 、角色。
+
+1) 【强制】对象名只能使用小写字母 、数字 、下划线， 不能使用其他字符。
+
+2) 【强制】对象名长度不超过 32 位。
+
+3) 【强制】库名 、表名 、字段名禁止和数据库特殊关键字重名， 须见名知意。
+
+#### 3.4.2 对象设计规范
+
+1) 【强制】 自增列必须为 int 或 bigint 类型。
+
+30
+
+2) 【强制】表必须设置主键。
+
+3) 【推荐】列设置非空且有默认值。
+
+4) 【强制】禁止使用外键。
+
+5) 【强制】禁止使用分区表。
+
+6) 【强制】建表时禁止使用除 utf8,utf8mb4 之外的字符集。
+
+7) 【强制】建表指定的存储引擎必须为 Innodb。
+
+8) 【强制】禁用存储过程 、函数 、触发器 、视图。
+
+#### 3.4.3 大对象设计规范
+
+1) 【强制】禁止在 BLOB 、CLOB 等字段类型存储超过 16M 的内容。
+
+2) 【强制】禁止单条表数据超过 16M。
+
+#### 3.4.4 查询规范
+
+1) 【强制】查询语句必须带 where 条件， 避免广播查询， 查询条件尽量使用到分片键， 如无法使用分片键， 应考虑非分片键和分片键之间建立切片索引。
+
+2) 【推荐】尽量避免跨分片 Join查询语句。
+
+3) 【推荐】尽量避免跨分片 Union查询语句。
+
+4) 【强制】关联表使用的分片算法必须一致，关联表数据拆分的节点必须相同，关联查询 SQL 上必须带有分片键字段的关联。
+
+5) 【强制】和全局表做关联， 要保证非全局表所在的节点有对应全局表。
+
+6) 【推荐】在查询数据时， 要在 select 后写明需要查询的所有列名， 不要返回不使用的任何字段， 不要使用 select * ， 这样会查询过多内容， 也可能出现程序匹配错误。
+
+7) 【推荐】在查询时，一定要考虑查询返回数据量，避免一次 SQL 返回过多数据， 影响查询性能和网络。
+
+#### 3.4.5 数据操作规范
+
+1) 【强制】Update/Delete 语句不带 where 条件。 31
+
+2) 【强制】禁止使用 Truncate table 语句。
+
+3) 【强制】禁止 Update/Delete 语句带 limit 条件 。 因为可能会导致主从不一致。
+
+4) 【强制】禁止 Update/Delete 语句带 order by 条件。
+
+5) 【强制】禁止更新分片键值。
+
+6) 【强制】禁止在 BLOB 或 BINARY 字段中存储大文件内容。
+
+7) 【推荐】尽量避免广播语句。
+
+8) 【推荐】Insert/Update/Delete 语句尽量避免跨分片执行。
+
+9) 【推荐】使用全局序列替换数据库的自增序列。
+
+10) 【推荐】如果要执行跨节点 update/delete 语句， 建议在执行前开启分布式事务， 保障跨节点操作的数据一致性。
+
+11) 【推荐】根据业务和安全实际需求， 设置相应的 DDL 及 DML 审计规则， 设置 IP 黑白名单。
+
+#### 3.4.6 稳定性操作规范
+
+1) 【推荐】尽量避免使用分布式事务 。如果要执行跨节点 update/delete 语句，建议在执行前开启分布式事务， 保障跨节点操作的数据一致性。
+
+2) 【推荐】应用程序尽量使用数据库连接池或者有重连机制。
+
+3) 【推荐】表结构的变更，包括添加字段、索引等，应尽量在业务低峰期执行。
+
+4) 【推荐】OLTP 系统在业务高峰期或高并发期间， 应拒绝长 SQL 、大事务、大批量。
+
+#### 3.4.7 索引优化规范
+
+本部分索引特指 UDAL 提供的切片索引， 即非分片键和分片键之间的索引。
+
+1) 【强制】切片索引必须准确设置 one2one 或类型 one2many。
+
+2) 【强制】在 one2one类型的索引中， 索引对应的数据记录必须是一对一的关系， 如果有一条索引键对应多条被索引键的情况， 会引起数据丢失。
+
+3) 【强制】在 one2many 类型的索引中， 如果一个索引键对应了多条被索引键，那这些被索引键必须是彼此不同的 。否则会引起数据丢失。
+
+32
+
+4) 【强制】应该避免使用 float/double/year/date/time/datetime/timestamp 类型的字段作为索引键/被索引键，否则容易出现索引失效的问题 。（因为缓存中存储的是不带格式的原始数据，前端查询条件中可能使用的是有格式的数据 。例如字段类型是double， 那么缓存中存储的数据可能是 1.0， 此时前端查询条件只有使用 1.0 时才能命中索引， 如果是 1 或者 1.00 都会导致索引失效） 。
+
+5) 【强制】禁止一次执行过大的数据库更新操作（比如： 对千万级别的表直接执行全表更新或者全表删除操作） 。
+
+6) 【强制】one2many 类型索引中，一条索引键对应 2-3 条被索引键为宜，禁止出现一条索引键对应百万或者千万级别被索引键的情况。
+
+7) 【强制】索引键/被索引键不能过长， 禁止出现索引键/被索引键为长度上千的中文字符串的情况。
+
+33

.agents/skills/telecom-rd-standards/references/source-documents/06-python-coding.md

@@ -0,0 +1,293 @@
+# 中国电信软件研发规范编码规范（Python 分册）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范编码规范 （Python 分册） （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为了让不同编码习惯的开发者更好的协作配合， 并且形成良好的基础编码规范与风格， 提高代码安全性 、健壮性 、可读性， 本规范以 PEP8 为基础， 整理了工作中常见的不规范操作， 对 Python 项目开发编码过程进行规范化约束。
+
+### 1.2 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.3 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.4 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.5 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.6 名词解释
+
+PEP 8 约定了 Python 的推荐代码规范， 基于 Guido 和 Barry 的Python 代码风格规范改编而成。
+
+## 2 Python 开发规范
+
+### 2.1 命名规范
+
+#### 2.1.1 概述
+
+1) 【推荐】名字应该能够标识事物的特性， 并且与业务挂钩。
+
+2) 【推荐】名字应该使用英文单词， 而不能为拼音。
+
+3) 【推荐】名字可以有两个或三个单词组成， 但不应多于 4 个， 控制在 3至 30 个字母以内。
+
+4) 【强制】命名不能和关键字冲突。
+
+#### 2.1.2 包和模块命名
+
+1) 【强制】包命名采用全小写命名。
+
+2) 【推荐】通过功能命名。
+
+3) 【推荐】模块命名应短小， 并且全为小写， 如果需要多单词增加可读性，
+
+使用下划线进行拼接。
+
+#### 2.1.3 类命名
+
+1) 【强制】类命名采用驼峰命名约定， 大写字母开头， 各个单词首字母大写。
+
+2) 【推荐】 当接口已文档化且主要是用作调用时， 也可以使用函数的命名风格约定。
+
+#### 2.1.4 函数命名
+
+1) 【推荐】 函数命名都是小写， 必要时使用下划线连接各单词提高可读性。
+
+2) 【推荐】只有当已有代码风格已经是混合大小写时， 为了保留向后兼容性才使用混合大小写。
+
+3) 【强制】用单下划线(_)开头表示模块函数是 protected 的。
+
+4) 【强制】用双下划线(__)开头的实例方法表示类内私有。
+
+#### 2.1.5 变量命名
+
+1) 【强制】变量名都是小写， 多单词使用下划线连接。
+
+2) 【推荐】类型变量名称通常应使用简短的驼峰命名， 建议将后缀_co 或_contra 添加到用于声明相应的协变和逆变的行为， 例
+
+如:from typing import TypeVar
+
+VT_co = TypeVar('VT_co'， covariant=True)KT_contra = TypeVar('KT_contra'， contravariant=True)
+
+3) 【强制】类型变量的定义统一放在 import 之后。
+
+4) 【强制】类变量统一放在类注释之后， 所有类函数之前。
+
+5) 【推荐】全局变量： 适用于函数的命名规范。
+
+6) 【强制】用单下划线(_)开头表示模块变量是 protected 的。
+
+7) 【强制】用双下划线(__)开头的实例变量表示类内私有。
+
+#### 2.1.6 常量命名
+
+1) 【推荐】全部使用大写并且下划线将单词分开。
+
+#### 2.1.7 异常命名
+
+1) 【推荐】 由于异常实际上也是类， 因此类命名的约定也适用与异常 。不同的是， 如果异常实际上是抛出错误的话， 异常名后应该加上“Error ”的后缀。
+
+### 2.2 注释规范
+
+#### 2.2.1 概述
+
+1) 【推荐】一般情况下源程序的有效注释量必须在 30%以上。
+
+2) 【强制】避免使用装饰性内容， 保持注释的简洁。
+
+3) 【强制】注释信息不仅要包括代码的功能， 还应给出原因， 不要为注释而注释。
+
+4) 【强制】注释不能嵌套。
+
+5) 【强制】避免使用行尾注释。
+
+6) 【推荐】生成开发文档的需要用中文编写。
+
+7) 【推荐】如果需要注释的内容太多， 需附加文档进行说明， 注释时加上"参见《 ****》"。
+
+8) 【强制】复杂的分支流程必须注释。
+
+9) 【推荐】代码质量不高但能正常运行， 或者还没有实现的代码用# TODO:声明。
+
+10) 【参考】存在错误隐患的代码用# FIXME:声明。
+
+#### 2.2.2 程序文件注释
+
+1) 【强制】采用文档字符串的形式进行注释（三个双引号的形式） 。
+
+2) 【参考】应该包含如下：
+
+# 文件描述 （Description）： 描述此类的作用；# 作者 （Author）： 创建者或者修改者名；# 版本 （Version）： 创建或者修复时的编号， 需要自行在 bug 管理系统中创建 bug 号， 使用 bug 号进行命名（若无 bug 管理工具的临时办法： 如无 bug 号， 从 1 开始， 修改时依次增加）；# 日期（Date）： 创建或者修改时的日期， 使用“ - ”进行年月日分割；# 记录（Record）： 创建或者修改的工作内容描述；
+
+#### 2.2.3 类注释
+
+1) 【强制】类应该在其定义下有一个用于描述该类的文档字符串。
+
+2) 【推荐】如果你的类有公共属性(Attributes)， 那么文档中应该有一个属性(Attributes)段， 并且应该遵守和函数参数相同的格式。
+
+#### 2.2.4 函数和方法注释
+
+下文所指的函数,包括函数 、方法 、 以及生成器。
+
+1) 【强制】一个函数必须要有文档字符串， 除非它满足以下条件之一:
+
+a) 外部不可见
+
+b) 非常短小
+
+c) 简单明了
+
+2) 【强制】文档字符串应该包含函数做什么， 以及输入和输出的详细描述 。通常不应该描述“ 怎么做 ”， 除非是一些复杂的算法 。 当开发人员调用该函数时， 文档字符串应该提供足够的信息， 而无需看代码 。对于复杂的代码， 在代码旁边加注释会比使用文档字符串更有意义。
+
+3) 【参考】 关于函数的几个方面应该在特定的小节中进行描述记录， 这几个
+
+方面如下文所述 。每节应该以一个标题行开始. 标题行以冒号结尾 。 除标题行外， 节的其他内容应被缩进 2 个空格。
+
+4) 【参考】Args:
+
+列出每个参数的名字,并在名字后使用一个冒号和一个空格,分隔对该参数的描述 。如果描述太长超过了单行 80 字符,使用 2 或者 4 个空格的悬挂缩进(与文件其他部分保持一致) 。描述应该包括所需的类型和含义 。如果一个函数接受*foo(可变长度参数列表)或者**bar (任意关键字参数),应该详细列出*foo 和**bar。
+
+5) 【参考】Returns: (或者 Yields: 用于生成器)
+
+描述返回值的类型和语义 。如果函数返回 None， 这一部分可以省略。
+
+6) 【参考】Raises:
+
+列出与接口有关的所有异常。
+
+#### 2.2.5 块注释和行注释
+
+1) 【强制】块注释一般写在对应的代码之前， 并且和对应的代码有同样的缩进级别。
+
+2) 【强制】块注释的每一行都应该以#和一个空格开头（除非该文本是在注释内缩进对齐的） 。
+
+3) 【强制】块注释中的段落应该用只含单个#的一行隔开。
+
+#### 2.2.6 行内注释
+
+1) 【参考】尽量少用行内注释。
+
+2) 【参考】行内注释是和代码语句写在一行内的注释 。行内注释应该至少和代码语句之间有两个空格间隔， 并且以#和一个空格开始。
+
+### 2.3 格式规范
+
+#### 2.3.1 概述
+
+1) 【强制】代码未写， 文档先行 。注释必须按照统一的范式编写。
+
+2) 【强制】 关系运算必须常量在左 、变量在右。
+
+3) 【强制】不许使用复杂的运算表达式， 必要时添加括号而不依赖于优先级。
+
+#### 2.3.2 缩进
+
+1) 【强制】缩进使用 4 个空格， 空格是首选的缩进方式。
+
+2) 【强制】禁止混用空格和 Tab。
+
+#### 2.3.3 换行
+
+1) 【推荐】每行代码的最大长度不该超过 80 个字符， 以下情况除外：
+
+a) 长的导入模块语句
+
+b) 注释里的 URL
+
+#### 2.3.4 空白行
+
+1) 【强制】使用 2 个空行来分隔最外层的函数(function)和类(class)定义。
+
+2) 【强制】使用 1 个空行来分隔类中的方法(method)定义。
+
+3) 【推荐】在函数内使用空行（尽量少） 使代码逻辑更清晰。
+
+#### 2.3.5 对齐
+
+1) 【强制】不要用空格来垂直对齐多行间的标记， 因为这会成为维护的负担(适用于:， #， =等)。
+
+2) 【推荐】续行应该与包裹元素对齐， 要么使用圆括号 、方括号 、花括号在
+
+内的隐式行连接来垂直对齐， 要么使用悬挂行缩进对齐。垂直对齐：
+
+#### 2.3.6 库的导入
+
+1) 【强制】每个导入应该独占一行。
+
+2) 【强制】使用 import 开头的导入， 一行只能导入一个库， 禁止使用逗号分开导入多个库。
+
+3) 【推荐】使用from import 形式的导入， 一行只能导入一个库， 特殊情况下可以使用逗号分开导入多个库。
+
+4) 【强制】导入总应该放在文件顶部， 位于模块注释和文档字符串之后， 模块全局变量和常量之前 。导入应该按照从最通用到最不通用的顺序分组：
+
+a) 标准库的导入
+
+b) 第三方库的导入
+
+c) 应用程序指定导入
+
+5) 【推荐】推荐使用绝对路径导入， 如果包导入时系统没有正确的配置（比如包里的一个目录在 sys.path 里的路径之后）， 使用绝对路径会更具可读性（至少能提供错误信息）：
+
+6) 【强制】 隐式相对 imports 是禁止使用的。
+
+显示导入和隐式导入说明假设有如下包结构：
+
+# 隐式相对导入， 是禁止使用的import bench# 显式相对导入
+
+from . import bench
+
+7) 【推荐】显式的相对 imports 也是一种可以接受的方式， 标准库代码应当一直使用绝对 imports， 避免复杂的包布局。
+
+from . import sibling from .sibling import example
+
+#### 2.3.7 字符串
+
+1) 【强制】避免在循环中用+和+=操作符来累加字符串。
+
+主要原因：1． 字符串是不可变的， 每一次的赋值， 原来引用的对象没有及时被删除（系统有机制回收内存， 但是不及时）， 增加内存负担；2． 随着字符串的累加， 长度越来越长， 写入的时间也逐渐增加， 所以如果循环规模比较大， 效率就明显下降。
+
+2) 【推荐】在同一个文件中， 保持使用字符串引号的一致性 。使用单引号 ’或者双引号"之一用以引用字符串， 并在同一文件中沿用。
+
+#### 2.3.8 空值比较
+
+1) 【推荐】使用 if foo is None: 形式来比较空值。
+
+#### 2.3.9 表达式和语句中的空格
+
+1) 【推荐】 以下情况避免无关的空格：
+
+i. 在括号或大括号内
+
+ii. 在尾随逗号和后面的右括号之间
+
+iii. 在逗号， 分号或冒号前面正例:if x == 4: print x， y; x， y = y， x反例:if x == 4 : print x ， y ; x ， y = y ， x
+
+iv. 紧接在开始函数调用的参数列表的开括号之前正例:spam(1)反例:spam (1)
+
+v. 紧接在索引或切片的左中括号之前
+
+vi. 在一个赋值（或其他）运算符前后多于一个空格
+
+2) 【参考】其他建议
+
+i. 总是围绕这些二元运算符在两侧使用一个空格正例:x = 1 y = 2 long_variable = 3反例:x = 1 y = 2 long_variable = 3
+
+ii. 用于指示关键字参数或默认参数值时， 不要在=符号周围使用空格

.agents/skills/telecom-rd-standards/references/source-documents/07-frontend-coding.md

@@ -0,0 +1,511 @@
+# 中国电信软件研发规范编码规范（前端分册）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范编码规范 （前端分册） （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+1. 文档说明
+
+### 1.1 编制说明
+
+软件行业的高速发展， 对软件开发者的综合素质要求越来越高， 不仅仅是编程知识点，其他维度知识点也会影响最后的交付质量，本文档以开发前端项目角度，详细描写了前端的代码规范，分别从 HTML、CSS、JavaScript、TypeScript、四个方面入手，并且每个章节进行了详细划分，方便读者能快速定位，规范自己的代码， 提高项目代码质量。
+
+### 1.2 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.3 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.4 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.5 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.6 名词解释
+
+2. 前端研发规范
+
+2.1. HTML 编码规范
+
+2.1.1. 文档类型
+
+1) 【强制】使用 HTML5 DOCTYPE。
+
+2.1.2. 语言
+
+1) 【推荐】指定 html 标签上的 lang 属性。
+
+2.1.3. 元数据
+
+1) 【推荐】使用 UTF-8 字符编码。
+
+声明一个明确的字符编码， 可以让浏览器更快速高效地确定适合网页内容的渲染方式。由于历史原因， 不同浏览器采用了不同的字符编码 。但对于新业务，如无特殊要求， 统一使用 UTF-8 字符编码， 以便统一。在 HTML 中使用 <meta charset="utf-8" /> 声明文档的编码方式：
+
+2) 【推荐】页面提供给移动设备使用时， 需要设置 viewport。
+
+2.1.4. 资源加载
+
+1) 【推荐】引入 CSS 和 JavaScript 时无需指定 type 。 根据 HTML5 规范，引入 CSS 和 JavaScript 时通常不需要指明 type， 因为 text/css 和
+
+text/javascript 分别是他们的默认值。
+
+2) 【推荐】在 head 标签内引入 CSS， 在 body 结束标签前引入 JS。
+
+在 <body></body> 中指定外部样式表和嵌入式样式块可能会导致页面的重排和重绘， 对页面的渲染造成影响 。 因此， 一般情况下， CSS 应在<head></head> 标签里引入。
+
+2.1.5. 页面标题
+
+1) 【强制】页面需要指定 title 标签， 有且仅有 1 个。
+
+2.1.6. 编码风格
+
+1) 【推荐】统一使用 2 个空格缩进， 不要使用 4 个空格或 tab 缩进。
+
+2) 【强制】在 HTML 注释代码中， 不允许出现任何敏感信息。
+
+3) 【推荐】单行注释， 需在注释内容和注释符之间需留有一个空格， 以增强可读性。
+
+4) 【推荐】多行注释， 注释符单独占一行， 注释内容 2 个空格缩进。
+
+2.1.7. 标签
+
+1) 【强制】标签名统一使用小写。
+
+2) 【推荐】不要省略自闭合标签结尾处的斜线，且斜线前需留有一个空格。
+
+2.1.8. 属性
+
+1) 【强制】属性值使用双引号， 不要使用单引号。
+
+2) 【推荐】不要为 Boolean 属性添加取值。
+
+XHTML 需要每个属性声明取值，但是 HTML5 并不需要。一个元素中Boolean 属性存在即表示取值 true， 不存在则表示取值 false
+
+3) 【推荐】 自定义属性的命名： 以 data- 为前缀。
+
+2.1.9. 语义化
+
+1) 【参考】尽量根据语义使用 HTML 标签。
+
+2.2. CSS 编码规范
+
+2.2.1. 文件引用
+
+1) 【强制】一律使用link 的方式调用外部样式。
+
+2) 【推荐】 不要在 <style> 块中使用 @import； 不要在页面中使用 <style> 块。
+
+2.2.2. 命名-组成元素
+
+1) 【强制】命名必须由字母 、 中划线或数字组成且不能以数字或中划线开头。
+
+2) 【强制】不允许使用拼音与英文的混合命名， 更不允许直接使用中文的方式； 禁止同一个含义的内容， 在同一个应用中出现多种不同的单词与翻译。
+
+2.2.3. 命名-词汇规范
+
+1) 【参考】不依据表现形式来命名。
+
+2) 【参考】可根据内容来命名， 可根据功能来命名。
+
+2.2.4. 命名-缩写
+
+1) 【强制】保证缩写后还能较为清晰保持原单词所能表述的意思。
+
+2) 【推荐】使用业界熟知的或者约定俗成的来定义 CSS 类名。
+
+2.2.5. 编码风格
+
+1) 【强制】所有声明都应该以分号结尾， 不能省略。
+
+2) 【推荐】使用 2 个空格缩进， 不要使用 4 个空格或 tab 缩进。
+
+3) 【推荐】选择器和 { 之间保留一个空格。
+
+4) 【推荐】属性名和 : 之前无空格， : 和属性值之间保留一个空格。
+
+5) 【推荐】> 、+ 、~ 、|| 等组合器前后各保留一个空格。
+
+6) 【推荐】在使用 , 分隔的属性值中， , 之后保留一个空格。
+
+7) 【推荐】注释内容和注释符之间留有一个空格。
+
+8) 【推荐】声明块的右大括号 } 应单独成行。
+
+9) 【推荐】属性声明应单独成行。
+
+10) 【推荐】单行代码最多不要超过 100 个字符。
+
+11) 【参考】使用多个选择器时， 每个选择器应该单独成行。
+
+12) 【参考】声明块内只有一条语句时， 也应该写成多行。
+
+13) 【参考】注释行上方需留有一行空行， 除非上一行是注释或块的顶部。
+
+2.2.6. 选择器
+
+1) 【参考】不要使用 id 选择器。
+
+id 会带来过高的选择器优先级， 使得后续很难进行样式覆盖（继而引发使用 !important 覆盖样式的恶性循环） 。
+
+2) 【参考】属性选择器的值始终用双引号包裹。
+
+2.2.7. 属性和属性值
+
+1) 【推荐】使用尽可能短的十六进制值。
+
+2) 【推荐】不要使用 !important 重写样式。
+
+3) 【推荐】十六进制值统一使用小写字母（小写字母更容易分辨） 。
+
+4) 【推荐】长度值为 0 时， 省略掉长度单位。
+
+5) 【参考】保留小数点前的 0。
+
+6) 【参考】属性声明的顺序。
+
+相关联的属性声明最好写成一组， 并按如下顺序排序：
+
+## 1 定位： 如 position 、left 、right 、top 、bottom 、z-index
+
+## 2 盒模型： 如 display、float、width、height、margin、padding、border
+
+## 3 文字排版： 如 font 、color 、line-height 、text-align
+
+## 4 外观： 如 background
+
+## 5 其他属性
+
+2.3. JavaScript 编码规范
+
+2.3.1. 对象
+
+1) 【推荐】使用字面语法来创建对象。
+
+2) 【推荐】使用对象方法的缩写。
+
+3) 【推荐】 使用属性值的缩写。
+
+4) 【参考】避免直接调用 Object.prototype 的方法。
+
+避免直接调用 Object.prototype 的方法， 例如 hasOwnProperty、 propertyIsEnumerable 、isPrototypeOf。这些方法可能会被对象上的属性覆盖， 导致错误。
+
+5) 【推荐】使用扩展运算符...处理对象，替代 Object.assgin 方法，来进行对象的浅拷贝。
+
+2.3.2. 数组
+
+1) 【推荐】使用字面语法来创建数组。
+
+6) 【强制】某些数组方法的回调函数中必须包含 return 语句。
+
+以下数组方法：map, filter, from , every, find, findIndex, reduce, reduceRight, some, sort 的回调函数中必须包含 return 语句， 否则可能会产生误用或错误。一个常见的误用是， 本该用 forEach 的场景却用了 map：
+
+7) 【推荐】使用扩展运算符 ... 处理数组。
+
+ES6 提供了扩展运算符 ...， 可以简化一些数组操作。数组复制：
+
+将类数组结构（有 Iterator 接口的对象）转换为数组：
+
+数组拼接：
+
+用 ... 替代 apply
+
+特殊的，遍历可迭代对象时，使用 Array.from 而不是 ...， 以免创建一个临时数组：
+
+2) 【推荐】使用解构获取数组元素。
+
+2.3.3. 解构
+
+1) 【推荐】在访问和使用对象的多个属性的时候使用对象的解构。
+
+2) 【推荐】对于多个返回值， 推荐使用对象解构而不是数组解构。
+
+2.3.4. 字符
+
+1) 【强制】使用单引号和反引号定义字符串。
+
+2) 【推荐】单行最大输入数 100。
+
+3) 【推荐】文件最大行数 1000。
+
+4) 【推荐】 函数最大行数 80。
+
+5) 【推荐】拼接字符串使用模版字符串。
+
+6) 【推荐】模版字符串可以加入表达式。
+
+2.3.5. 方法
+
+1) 【强制】永远不要定义一个参数为arguments,这将会优于每个函数给定范围的 arguments 对象。
+
+2) 【强制】不要用 Function 构造函数创建函数。
+
+使用 new Function 创建函数会像 eval() 方法一样执行字符串，带来安全隐患。
+
+3) 【强制】不要在块中使用函数声明。
+
+在非函数块（如 if、while 等） 中， 不要使用函数声明：
+
+4) 【参考】使用函数表达式替代函数声明。
+
+5) 【强制】不要使用 arguments 对象。
+
+不要使用 arguments 对象， 使用剩余参数操作符 ... 代替。ES6 提供了 rest 操作符 ...， 与 arguments 相比可以更清晰地聚合函数的剩余参数 。此外， ... 得到的是一个真正的数组， 而 arguments 得到
+
+的则是类数组结构。
+
+6) 【推荐】使用默认参数语法。
+
+7) 【参考】 函数的复杂度不应过高。
+
+圈复杂度不超过 10。认知复杂度不超过 15。
+
+8) 【强制】将立即执行函数表达式（IIFE） 用小括号包裹。
+
+2.3.6. 箭头函数
+
+1) 【推荐】 当你需要用匿名函数的时候， 使用箭头函数来替代他。
+
+2) 【推荐】箭头函数编码风格。
+
+箭头函数参数的小括号 、函数体的大括号在某些时候可以省略，这可能导致风格的不统一， 因此需要规范其编码风格。l 函数体风格当函数体只包含一条 return 语句时， 可以省略函数体大括号和return， 以使代码更简洁。我们推荐使用这个 ES6 提供的语法糖， 它可以让书写和阅读更简洁。但你也可以选择始终加上大括号和 return， 以方便后续在函数体内增加语句。
+
+当 return 的内容为对象或者有多行时， 需要用小括号包裹：
+
+l 函数参数风格当函数只有一个参数， 且函数体为 return 简写语法时， 可以省略包裹参数的小括号以使代码更简洁。
+
+我们建议仅在这种情况下省略包裹参数的小括号，其余情况都不要省略小括号 。但你也可以选择始终加上小括号， 以方便后续可能要增加参数。
+
+2.3.7. 类和构造器
+
+1) 【推荐】尽量使用 class 来避免操作 prototype。
+
+2) 【推荐】使用 extends 语句进行类的继承。
+
+extends 是用于原型继承的内建方法， 不会破坏 instanceof。
+
+3) 【强制】避免不必要的 constructor。
+
+ES6 class 会提供一个默认的 constructor， 空 constructor 或者只调用父类的constructor 是不必要的。
+
+2.3.8. 模块
+
+1) 【推荐】使用 ES6modules 而非其他非标准的模块系统。
+
+2) 【强制】不要用多个 import 引入同一模块。
+
+3) 【强制】import 语句需要放到模块的最上方。
+
+4) 【强制】禁止 default import 的名字跟文件内的其他 export 命名相同。
+
+5) 【强制】禁止引用自身。
+
+6) 【强制】禁止循环引用。
+
+7) 【参考】import 语句的排序。
+
+import 语句建议按以下规则排序：先 import 第三方模块， 再 import 自己工程里的模块先 import 绝对路径， 再 import 相对路径
+
+2.3.9. 迭代器和发生器
+
+1) 【参考】尽量使用 JavaScript 高阶函数来替代 for-in 和 for-of
+
+需要迭代运算时，应优先使用 JS 提供的高阶函数，减少直接使用 for 循环（包括 for-in 和 for-of） 。如使用 map() / every() / filter() / find() / findIndex() / reduce() / some() / ... 来迭代数组， 使用 Object.keys() / Object.values() / Object.entries() 方法来迭
+
+代对象。
+
+2) 【强制】不要使用发生器， 因为它们不适配es5。
+
+2.3.10. 属性
+
+1) 【强制】访问属性时使用点符号。
+
+2) 【强制】访问变量属性时， 使用[]表示法。
+
+2.3.11. 变量
+
+1) 【强制】使用 const 或者 let 来定义变量，避免因创建全局变量而污染全局命名空间。
+
+2.3.12. 比较运算符和符号
+
+1) 【强制】使用 === 和 !== 来替代 == 和 !=
+
+非严格相等运算符（== 和 !=）会在比较前将被比较值转换为相同类型，对于不熟悉 JS 语言特性的人来说， 这可能造成不小的隐患。因此，一般情况下我们应该使用严格比较运算符（ === 和 !==）进行比较 。如果要比较的两个值类型不同，应该显性地将其转换成相同类型再进行严格比较，而不是依赖于 == 和 != 的隐式类型转换。
+
+2) 【强制】避免嵌套的三元表达式。
+
+3) 【强制】避免不必要的三元表达式。
+
+2.3.13. 块
+
+1) 【推荐】 当有多行代码块的时候， 使用大括号包裹。
+
+2) 【强制】不要使用空代码块。
+
+3) 【强制】对于非空代码块， 采用 Egyptian Brackets 风格。
+
+对于非空的代码块， 大括号的换行方式采用 Egyptian Brackets 风格，具体规则如下：左大括号 { 前面不换行， 后面换行右大括号 } 前面换行右大括号 } 后面是否换行有两种情况：如果 } 终结了整个语句， 如条件语句 、函数或类的主体， 则需要换行如果 } 后面存在 else、catch、while 等语句， 或存在逗号、分号、右小括号（)）， 则不需要换行
+
+2.3.14. 控制语句
+
+1) 【强制】switch 语句中的 case 需要以 break 结尾。
+
+2) 【参考】控制语句的嵌套层级不要过深。
+
+控制语句的嵌套层级不要超过 4 级， 否则将难以阅读和维护：
+
+3) 【强制】for 循环中的计数器应朝着正确方向移动。
+
+当 for 循环中更新子句的计数器朝着错误的方向移动时，循环的终止条件将永远无法达到，这会导致死循环的出现。这时要么是程序出现了错误，要么应将for 循环改为 while 循环。
+
+2.3.15. 注释
+
+1) 【推荐】使用/**...*/来进行多行注释。
+
+2) 【推荐】使用 // 进行单行注释。
+
+3) 【强制】注释内容和注释符之间需要有一个空格。
+
+2.3.16. 代码风格
+
+1) 【强制】使用 2 个空格缩进。
+
+2.3.17. 逗号
+
+1) 【强制】逗号不能放在行首。
+
+2.3.18. 分号
+
+1) 【推荐】添加尾随分号 。。
+
+2.3.19. 命名规范
+
+1) 【强制】避免单字母的名字 。使用有意义 、能描述功能的名字。
+
+2) 【参考】文件名： 使用小写字母命名。
+
+考虑到部分操作系统（如 Windows, MacOS） 下文件系统大小写不敏感， 推荐使用 - 连接 。 例如： hello-world.js。
+
+3) 【参考】使用小驼峰（camelCase） 命名原始类型 、对象 、函数 、实例。
+
+4) 【强制】使用大驼峰（PascalCase） 命名类和构造函数。
+
+5) 【参考】命名不要以下划线开头或结尾。
+
+2.3.20. 存取器
+
+1) 【强制】不要使用 JavaScript 的 getters/setters 方法， 因为它们会导致意外的副作用， 并且更加难以测试 、维护和推敲 。 相应的， 如果你需要存取函数的时候使用 getVal() 和 setVal('hello')。
+
+2.4. TypeScript 编码规范
+
+2.4.1. 代码风格
+
+1) 【强制】interface/type 类型中使用一致的成员分隔符分号。
+
+2) 【强制】块开始和结束不能空行。
+
+3) 【推荐】TS/TSX 在文件中字符串字面量使用单引号或反引号包裹。
+
+4) 【推荐】 加号 + 连接的两侧同为数字或同为字符串。
+
+数字与字符串的连接往往会导致一些预期外的问题。
+
+5) 【强制】 即使 if/else/for/while 的语句只有一句， 也不得省略大括号。
+
+6) 【强制】类型声明时应正确添加空格间距。
+
+TypeScript 类型声明周围添加合适的间距可以有效的提升代码可读性，我们约定：冒号前无空格， 冒号后保留一个空格箭头前后都保留一个空格
+
+7) 【强制】禁止使用三斜杠语法 /// 导入文件。
+
+三斜杠语法已经被废弃， 声明文件（d.ts） 以外禁止使用。
+
+2.4.2. 类
+
+1) 【参考】为类成员声明可访问类型。
+
+2) 【参考】类成员建议以固定的先后顺序排列。
+
+类的静态方法 / 属性（static） 优先于实例的方法 / 属性（instance）；属性（field） 优先于构造函数（constructor）， 优先于方法（method）；公开的成员（public） 优先于受保护的成员（protected）， 优先于私有的成员（private）；
+
+3) 【推荐】如果类的属性是一个字面量， 则推荐使用只读属性 readonly 而不是 getter。
+
+类上所有返回「字面量」的 getter 方法， 都推荐使用 readonly 修饰符来代替， 包括字符串 、数字等。
+
+2.4.3. 接口
+
+1) 【强制】优先使用 Interface 编写。
+
+2) 【推荐】接口中的方法使用属性的方式定义。
+
+3) 【推荐】避免定义空的接口类型。
+
+4) 【强制】interface 和 type 定义时必须声明成员的类型。
+
+2.4.4. 模块
+
+1) 【推荐】使用 ES2015 import 语法引入模块。
+
+2.4.5. 重载
+
+1) 【强制】重载函数写在一起以提高可读性。
+
+2.4.6. 声明
+
+1) 【推荐】简单数组类型的定义使用 T[]， 复杂类型使用 Array<T>。
+
+简单类型（数字、字符串、布尔等）请使用 T[] 或 readonly T[] ，其他复杂类型（联合 、交叉 、对象 、函数等）请使用 Array<T> 或 ReadonlyArray<T>。
+
+2) 【推荐】初始化为 number/string/boolean 的变量或参数应避免显式的类型声明。
+
+Ts 会主动帮我们推导出类型， 显式声明会导致代码冗余。
+
+3) 【强制】禁止无意义的 void 类型。
+
+void 类型代表「无」或函数「不返回任何值」， 隐式未定义类型代表函数返回「未定义的值 undefined」， 所以 void 类型无法与除了 never 外的其他类型做联合 、交叉。
+
+2.4.7. 注释
+
+1) 【推荐】使用 TypeScript 注释指令时需跟随描述说明。
+
+2.4.8. 断言
+
+1) 【推荐】禁止使用容易混淆的非空断言。
+
+在相等运算符之前增加非空断言容易与不等于混淆， 所以不建议使用。
+
+2) 【强制】类型断言必须使用 as Type。
+
+2.4.9. 命名空间
+
+1) 【强制】禁止使用 namespace 来定义命名空间。
+
+自定义 TypeScript 模块（module） 和命名空间（namespace） 已经不再推荐使用，首选 ES2015 的模块语法来导入导出。此规则仍然允许定义外部的模块或命名空间。
+
+2.4.10. 变量
+
+1) 【强制】不得使用 var 声明变量。
+
+2) 【推荐】只使用const 声明变量，在 const 无法有效涵盖的场景，可按需使用let。
+
+3) 【推荐】如非必要，不能使用 any 类型标注，使用 any 将会失去 Typescript的类型检查功能 。一般而言， 仅限于与第三方 Javascript 库联合使用， 且无对应定义时可使用 any。
+
+4) 【参考】一般而言，建议使用 undefined，如非必要，不要使用 null；对于 Vue组件成员初始值，若使用 undefined 可能会导致响应式故障， 可使用初始值代替 。如初始值无意义， 可使用 null。
+
+2.4.11. 枚举
+
+1) 【参考】使用联合类型替代枚举， 如非必要， 避免在新代码中使用枚举。

.agents/skills/telecom-rd-standards/references/source-documents/08-code-management.md

@@ -0,0 +1,167 @@
+# 中国电信软件研发规范代码管理分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范代码管理分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步提升全集团的代码管理水平，实现代码分级分类管理，集团编制了软件研发规范--代码管理分册， 用于指导和规范全集团使用代码仓库管理代码，规范代码开发过程， 提升代码质量。
+
+### 1.2 文档结构
+
+本规范由文档说明 、代码仓库设置 、分支设置 、开发人员操作规范和代码版本管理等部分构成， 各章节的主要内容如下：第 1 章文档说明， 对编制目的 、文档结构 、使用范围 、起草单位 、解释权、版权和本规范用到的术语进行了说明。第 2 章代码仓库设置，对代码管理工具、代码仓库命名规范、代码仓库必要文件 、代码仓库划分 、仓库大小和权限设置相关要求进行了说明。第 3 章分支设置，对必要分支、git flow工作流分支、代码评审相关要求进行了说明。第 4 章开发人员操作规范，对用户信息设置、代码提交规范、代码文件约束等相关要求进行了说明。第 5 章代码版本管理，对版本号管理、版本号格式、版本描述信息相关要求进行了说明。
+
+### 1.3 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+## 2 代码仓库设置
+
+### 2.1 管理工具 （C1）
+
+项目组必须使用 git 管理代码 。代码管理须满足《中国电信代码安全管理实施指引(试行)》相关要求。
+
+### 2.2 命名规范
+
+#### 2.2.1 代码仓库命名 （C1）
+
+代码仓库名称是同一项目/子项目下代码仓库的唯一标识， 代码仓库名称在代码仓库创建之后无法修改，为便于识别，代码仓库名称必须能明确体现代码所属模块或微服务。代码仓库命名规则如下：l 代码仓库名仅使用英文大小写字母（A-Z 、a-z） 、数字（0-9） 、 中划线（-）u 不使用下划线（ _）u 不使用特殊字符l 代码仓库名第一个字符仅使用字母u 首字符不使用数字l 项目内全部代码仓库的命名规则必须要保持规则一致性， 例如： 全部为驼峰模式/全大写字母/全小写字母
+
+#### 2.2.2 代码仓库描述 （C1）
+
+代码仓库描述是声明代码仓库用途的描述信息，使用简洁明了的文字进行描述。l 代码仓库简要描述不得超过 80 字符。
+
+l 代码仓库描述应包含代码仓库所属项目的项目编号 、项目名称和子项目名称。
+
+### 2.3 代码仓库必要文件 （C1）
+
+l 每个项目都需要README.md 文件， README.md 文件中需要包含工程的基本介绍， 工程结构的概要说明及工程文档的存放地址或者链接。l 除文档说明类型仓库， 所有代码仓库都必须包含.gitignore 文件， 放在代码仓库的根文件夹中， 控制 git 仓库排除跟踪的文件。
+
+### 2.4 代码仓库划分
+
+代码仓库是中国电信研发项目的重要数字资产，应对代码仓库进行拆分，避免无关人员访问代码仓库 。 同时， 代码仓库是 devops 流程的基础， 为使 devops流程顺利进行， 也应对代码仓库进行拆分：l 安全管控： 核心代码和非核心代码分库管理， 应严格控制访问核心代码的人员， 避免核心代码泄露 。（C1）l 技术栈： 每个代码仓库仅使用一种技术栈， 如 java maven 、Python 、go、 node.js 等 。（C1）l 微服务： 每个代码仓库不超过 5 个微服务 。（C0）
+
+### 2.5 仓库大小 （C1）
+
+l 原则上， 每个代码仓库不超过 1G。
+
+### 2.6 权限设置
+
+#### 2.6.1 用户角色
+
+代码仓库需要设置仓库管理员（C1） 、分支开发人员（C1） 、分支管理员（C0） 、分支评审人员（C0） 、分支只读人员（C0） 五种角色， 角色权限说明如下表：
+
+#### 2.6.2 权限管控要求
+
+l 仅项目/子项目负责人或项目/子项目管理员具有创建代码仓库的权限。 （C1）l 权限设置必须遵循权限最小化原则， 根据项目需求设定项目组开发人员访问指定代码仓库和具体分支， 分配用户角色， 避免开发人员越权使用代码仓库 。（C1）l 在人员离职 、离开团队的情况下， 必须收回代码仓库权限 。（C1）l 每个代码仓库， 代码仓库管理员不超过 3 人 。（C1）l 禁止设置外协开发人员为代码仓库管理员 。（C1）l 代码仓库管理员应定期梳理代码仓库的权限分配情况， 并及时对权限进行合理调整， 保证权限最小化原则 。（C0）l 严格控制master 和 develop 分支的写权限， 仅允许项目负责人 、小组长等人员推送代码到远程平台代码仓库的master 和 develop 分支 。（C0）l 远程仓库，普通分支由仓库管理员来创建，开发人员只能创建个人分支。 （C0）
+
+## 3 分支设置
+
+远程平台代码仓库是开发人员协同开发的交互中心，应规范设置远程平台代码仓库的分支。
+
+### 3.1 必要分支 （C1）
+
+代码仓库必须具有主干分支（master） 。
+
+### 3.2 git flow 工作流分支 （C0）
+
+代码仓库的默认分支必须为固定分支，不允许把临时分支设为代码仓库的默认分支。
+
+#### 3.2.1 固定分支
+
+代码仓库的固定分支包括主干分支（master） 和开发分支（develop） 。
+
+主干分支 （master）用于存放对外稳定的发布版本，代码库有且只有一个主干分支，作为代码库的基线版本， 同时用来发布生产 tag 版本。master 分支仅允许团队专家访问，不允许普通开发人员直接对master 分支代码进行修改和提交，普通开发人员若要合入代码到master 分支，必须发起合并请求（merge request）， 由 master 角色人员进行评审后合入。master 分支在每次生产版本发布后， 必须打上 tag。
+
+开发分支 （develop）所有最终完成的开发任务，相应的代码都要合并到此分支。此分支上应包含全部最新特性，可以随时发布可测试的（指能编译通过的、部署后可运行起来的，具备测试条件的） 版本。
+
+#### 3.2.2 临时分支
+
+代码仓库的临时分支包括紧急修复分支（hotfix-*）、集成测试分支（release-*）和功能分支（feature-*） 。l 同一代码仓库下的全部分支的命名方式要保持仓库内规则一致性， 全部为驼峰模式/全大写字母/全小写字母l 一项目/子项目下的全部代码仓库的分支命名规则也需保持一致性
+
+紧急修复分支 （hotfix-*）软件正式发布以后，出现需要紧急修复的 bug，以发布的 TAG（master 分支）为基础创建 hotfix分支，进行 bug 修补，验证后将相关提交合并入master 分支和develop 分支。集成测试分支 （release-*）该分支以 develop 分支为基础创建， 在一个的迭代计划的功能开发完成时，把 develop 分支提交合入到 release 分支做集成测试，测试出的 bug 在 release 分支上进行修复， 验收通过后， 提交合并入 master 和 develop。特性功能分支 （feature-*）该分支是开发人员为了开发某种功能， 以 develop 分支为基础创建， 开发完成后， 将相关提交合并入 develop 分支， 完成后删除该分支。
+
+### 3.3 代码评审 （C3）
+
+开发人员的提交必须经过代码评审，可选择单分支代码评审（code review）和多分支代码评审（merge request） 二种评审模式中的任意一种或同时使用二种。
+
+#### 3.3.1 单分支代码评审 （code review）
+
+对于启用代码评审流程的分支， 开发人员推送代码到远程平台代码仓库时，每个提交均需走评审流程， 可结合流水线对代码进行代码安全扫描并返回评分，评审人员对代码进行评审。代码安全评分且人工评审通过的提交合入远程平台代码仓库， 保障代码质量。开发人员推送代码后，在评审人员合入之前，其他开发人员无法拉取本次提交的代码。
+
+#### 3.3.2 多分支代码评审 （merge request）
+
+合并请求可以实现同一个代码仓库不同分支之间在线合并代码，当前分支人员向目标分支发起合并请求，由目标分支管理员或仓库管理员评审后合入代码到目标分支 。使用场景如下：l 特性分支开发人员向开发分支发起合并请求merge request， 由开发分支管理人员或仓库管理员合入。l 开发分支开发人员向集成测试分支起合并请求merge request， 由集成测试分支管理人员或仓库管理员合入。l 集成测试分支测试人员向主干分支和开发分支发起合并请求 merge request， 由主干分支管理员和开发分支管理员或仓库管理员合入。l 修复分支开发人员向主干分支和开发分支发起合并请求merge request，由主干分支管理员和开发分支管理员或仓库管理员合入。
+
+## 4 开发人员操作规范
+
+### 4.1 用户信息设置 （C1）
+
+l 用户信息设置是代码提交的身份验证信息以及度量统计数据的账号信息，须与远端仓库账号 、邮箱保持一致。用户信息设置示例：git config --global user.name zhangsan git config --global user.name [邮箱已脱敏]l 用户密码须不少于 8 位， 且包含数字 、大小写字母及特殊符号。
+
+### 4.2 代码提交规范
+
+#### 4.2.1 commit 的产生 （C1）
+
+l 保持清晰的 commit 历史， 保证每次 commit 操作都是有意义的。l 推送 commit 到远程平台代码仓库之前必须对本地 commit 进行精简合并。原则上， 一个任务不能推送超过 5 个 commit 到远程平台代码仓库。
+
+#### 4.2.2 commit message 规范 （C3）
+
+提交代码应与迭代开发任务关联，代码提交的 commit message 用以关联迭代开发任务或者需求， commit message 须遵循以下格式：type（scope） : subject%workItemId注意格式中的空格及符号l workItemId（可选）： 工作项 ID 数字部分， 以%号开头， 空格结尾 。可放置于提交日志中的任何位置 。可支持多个 ID 串联， 以%号间隔。如： %workItemId1%workItemId2 l type（必选）： commit 的类别， 可使用以下标识：
+
+u feat : 新功能u fix : 修复 bug u docs : 文档改变u style : 代码格式改变u refactor : 某个已有功能重构u perf : 性能优化u test : 增加测试u build : 改变了 build 工具 如 grunt 换成了 npm u revert : 撤销上一次的 commit u chore : 构建过程或辅助工具的变动l scope（可选）： 用于说明 commit 影响的范围， 比如数据层 、控制层、视图层等等， 视项目不同而不同。l subject（必选）： commit 的简短描述commit 示例：%1011 fix（core） : set a to b
+
+### 4.3 代码文件约束 （C0）
+
+提交到代码仓库的文件约束要求如下：l 提交到代码仓库的文件不允许出现数据库账号 、密码等敏感信息。l 不允许提交与项目代码无关的二进制文件。l 提交到代码仓库的单个文件不超过 10M。l 代码的第三方依赖包必须引用制品库的， 不允许把依赖包直接放到代码仓库， 特别是开源项目， 例如 Android 系统。l 不允许提交 pdf/doc/ppt/docx/pptx/xls/xlsx 或压缩包 、音视频等类型文件。
+
+## 5 代码版本管理
+
+代码版本号（Tag） 是代码仓库的一个标记， 是指向某个提交（commit） 的指针， 用于发布版本的管理。
+
+### 5.1 版本号管理 （C1）
+
+发布代码版本时，必须为发布版本的提交打上版本号（tag） ，流水线编译构建生成制品时， 使用代码版本号作为制品的版本号。对于代码配置文件中有版本定义（version） 的， 版本号（tag）必须与配置文件中的版本号（version）保持一致。
+
+### 5.2 版本号格式 （C2）
+
+版本发布时，版本号必须符合版本格式：X.Y.Z（主版本号.次版本号.修订号）。版本号递增规则如下：l 主版本号： 当做了不兼容的 API 修改， 或者大的版本发布；l 次版本号： 当做了向下兼容的功能性新增；l 修订号： 当做了向下兼容的问题修正。如有需要， 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号 ”的后面， 作为延伸。例子：l 1.0.0-alpha， 1.0.0-beta l 1.0.0-alpha+001 、1.0.0+20130313144700 、1.0.0-beta+sha.5114f85
+
+### 5.3 版本描述信息
+
+版本描述信息应包括迭代任务的工作项 ID 及其描述信息， 详细描述本次迭代版本解决的需求和缺陷。
+
+#### 5.3.1 标签信息 （C3）
+
+标签信息（Tag Message）是管理维度的要求，用于维护版本基线，记录版本日期 、说明信息等。
+
+#### 5.3.2 版本说明 （C3）
+
+版本说明（Release Notes） 是业务维度的要求， 记录本次 Tag 中具体包含的版本内容， 包括： feature 新功能 、fixed 修复内容， 关联的任务 、需求等信息。

.agents/skills/telecom-rd-standards/references/source-documents/09-artifact-management.md

@@ -0,0 +1,179 @@
+# 中国电信软件研发规范制品管理分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范制品管理分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+中国电信软件开发的成果以软件制品呈现，软件制品是中国电信重要的数字资产。只有具备规范的开发构建、安全扫描、存储管理、测试及部署的过程管理，并且配套进行全生命周期的元数据信息收集，才能形成安全可靠、可高效部署及成果可复用的数字资产。为了规范中国电信软件开发过程，制定本分册制品管理规范。软件制品从提供方式分为中国电信自主研发产生的制品和外购商业软件制品，本规范主要针对自主研发产生的制品，包含内部研发单位及外协单位研发产生的制品。
+
+### 1.2 文档结构
+
+本规范由文档说明 、制品全生命周期管理 、制品版本管理 、制品依赖的第三方组件管理及制品溯源管理等部分构成， 各章节的主要内容如下：第 1 章文档说明， 对编制目的 、文档结构 、使用范围 、起草单位 、解释权、版权和本规范用到的术语进行了说明。第 2 章制品全生命周期管理，对制品在开发构建 、安全扫描、存储管理 、测试及部署等全生命阶段的相关要求进行了说明。第 3 章制品版本管理，对制品版本、制品晋级及制品清理等要求进行了说明。第 4 章制品依赖的第三方组件管理，对制品依赖的第三方组件来源、安全扫描 、规范使用等要求进行了说明。第 5 章制品溯源管理，对制品元数据信息收集、制品软件物料清单等进行了说明。
+
+### 1.3 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+## 2 制品全生命周期管理
+
+### 2.1 制品全生命周期管理总体要求
+
+中国电信软件研发的输出成果是制品，研发目标是软件制品上线运行，为客户提供预期服务。软件制品的质量及交付效率是中国电信软件研发的重要衡量指标之一。为了保证交付上线的软件制品质量，必须从制品开发构建、安全扫描、存储管理 、测试及部署等全生命阶段进行规范化管理。为了实现制品的准确、及时交付，必须伴随制品生命周期流转收集必要的元数据信息， 以便实现制品标准化流转及自动化交付。制品全生命周期管理应遵循如下总体原则：构建制品的源代码及需求来源可追溯制品的安全质量可管控制品的存储管理安全可靠制品应唯一可信， 保证部署上线的制品即测试通过的制品制品操作及流转日志可审计
+
+### 2.2 开发构建
+
+#### 2.2.1 开发环境管理 （C1）
+
+制品开发构建无论是本地开发构建还是采用流水线协同开发构建，均须连接统一制品库进行第三方依赖组件下载，由统一制品库代理官方的第三方组件下载源。对于构建过程中需要依赖的二方组件，需上传到统一制品库进行管理，确保通过统一制品库管控所有的二方组件 、三方组件。开发构建生成的制品必须上传到统一制品库进行管理。开发环境应将项目下载依赖及上传构建制品的仓库地址指向统一制品库。
+
+#### 2.2.2 制品关联开发构建关键信息
+
+开发构建的制品必须收集构建信息，构建信息至少包括构建时间、构建人员、构建名称 、构建工具 、引用的第三方依赖等 。(C3)开发构建的制品必须通过元数据关联代码仓库 、分支 、commit id 等信息，以便进行制品代码溯源及研发效能度量 。（C3）开发构建的制品应根据所关联的代码信息进一步关联到对应的需求或缺陷等 。（C4）
+
+### 2.3 制品安全扫描管理
+
+#### 2.3.1 制品关联源代码质量及安全扫描信息
+
+制品应通过元数据关联源代码质量及安全扫描信息，以便根据代码质量及安全扫描结果对制品的流转进行自动化处理 。(C3)根据源代码质量及安全扫描结果，结合企业安全管控策略，确定制品能否进入存储管理环节及测试环节 。（C4）
+
+#### 2.3.2 制品关联第三方组件安全扫描信息
+
+制品应关联第三方组件安全漏洞扫描信息，以便根据制品第三方组件安全扫描结果对制品的流转进行自动化处理 。(C2)对于存在高中危风险漏洞问题的制品，当存在可修复的组件版本时，必须在开发阶段完成漏洞问题的修复；当暂无可修复组件版本时，应根据企业安全管控策略， 确定制品能否进入测试及部署环节 。（C2）
+
+#### 2.3.3 制品关联第三方组件许可协议信息
+
+制品必须关联第三方组件许可协议扫描信息，以便管控制品依赖的第三方组件符合开源协议要求 。(C3)支持制定本企业合规的开源许可协议，结合企业开源合规管控策略，确定制品能否进入测试及部署环节 。（C4）
+
+### 2.4 存储管理
+
+#### 2.4.1 通过统一制品库管理 （C1）
+
+开发构建的制品必须通过统一制品库进行存储管理。项目团队应根据开发语言、构建工具、部署方式及制品的开发周期设置合适的项目制品仓库， 统一存储管理项目构建制品。根据制品开发周期， 建议创建开发快照仓库和部署发布仓库。制品仓库类型的设置应遵循以下原则：对于云原生应用制品， 建议创建 docker 仓库存储管理 docker 镜像制品，创建 helm 仓库存储管理 helm 配置文件。对于直接部署安装的制品，建议创建 generic仓库，并设置简洁清晰的目录存储制品。对于作为项目构建依赖的制品，建议创建相应的制品类型仓库进行管理，比如 java 采用 maven，nodejs 采用 npm，Go 采用 go 等， 以实现不同构建工具正确索引 、上传及下载制品需求。项目制品仓库的命名格式， 应遵循如下规范：
+
+项目名-[子项目名]-生命周期-制品类型-仓库类型项目名：使用项目英文标识，仅限英文大小写字母（A-Z、a-z）、数字（0-9），且不能使用数字开头。子项目名： 当区分子项目管理制品仓库时出现， 格式要求同项目名。生命周期： 开发快照仓库使用 snapshot， 生产发布仓库使用 release。制品类型：表示制品包类型，遵循通用的包类型命名方式，比如docker、maven、 npm 、go 、pypi 、gems 、generic 等。仓库类型： 项目本地制品仓库使用 local， 项目虚拟制品仓库使用virtual。
+
+#### 2.4.2 制品访问权限管理 （C1）
+
+项目团队必须对项目制品仓库设置严格的访问权限，管控团队成员上传、修改 、删除及下载制品的操作。针对项目制品仓库应设置管理员、读写人员及只读人员等不同角色权限，满足项目管理员 、开发人员 、测试人员 、运维人员的使用需求。
+
+#### 2.4.3 制品访问日志审计 （C2）
+
+制品上传、下载、修改、删除必须留痕记录， 日志至少应记录操作人员、操作时间 、制品名称 、发起操作请求的客户端 IP 地址 、操作类型等。制品访问日志记录必须至少保存 6 个月。
+
+### 2.5 测试阶段
+
+测试阶段的制品必须从统一制品库获取 。（C1）制品必须关联制品在各阶段的测试结果，以便根据制品在各阶段的测试结果确定制品是否晋级 。（C4）
+
+### 2.6 部署阶段
+
+部署阶段的制品必须从统一制品库获取。只有安全检查及测试通过的制品才能部署到生产环境 。（C1）制品必须关联部署环境信息、部署时间及部署人员等信息，以便对部署到生产系统的制品进行溯源管理 。（C4）
+
+## 3 制品版本管理
+
+### 3.1 制品版本管理
+
+#### 3.1.1 制品的版本号 （C1）
+
+软件制品的版本号应该与源代码的版本号保持一致。对于代码中有明确version 定义版本的， 制品版本号与代码中version相同。代码中无version定义版本号的，代码分支有 tag 表示版本号情况，制品版本号与对应代码分支的 tag 相同。代码中无version定义版本号的，代码分支也没有 tag 情况，则构建或打包制品的版本号应遵循代码的 tag 格式原则。
+
+#### 3.1.2 制品快照版本 、正式版本的使用 （C1）
+
+开发测试阶段应该使用快照版本（SNAPSHOT 版本）， 更利于开发调试。快照版本在测试完成之后，应发布正式版本的制品进行回归测试。回归测试通过后才允许发布到生产环境。制品的正式版本号不允许覆盖升级， 确保每个发布部署的制品版本可追溯。
+
+#### 3.1.3 制品版本追溯 （C3）
+
+发布上线的制品必须可追溯到源代码版本（commit id），应通过制品的元数据关联构建信息 、构建代码的 commit id。
+
+发布上线的制品应通过制品文件与制品元数据的紧密关联，实现版本研发全过程及状态的追溯。
+
+### 3.2 制品晋级管理
+
+开发构建的制品应随着生命周期的流转进行制品晋级，确保制品从开发构建到测试 、上线发布的唯一可信性， 从而保证系统上线部署的成功率。
+
+#### 3.2.1 制品自动晋级 （C3）
+
+制品应根据在生命周期各阶段收集的元数据信息及晋级策略进行制品的自动晋级，实现一次构建多次使用。制品应在各阶段测试及安全检查通过后从开发快照仓库晋级到生产发布仓库。
+
+#### 3.2.2 制品审核晋级 （C4）
+
+根据项目管控需要，在晋级到生产发布仓库前，可增加项目经理人工审核流程， 审核通过后才允许发布到生产发布仓库。
+
+### 3.3 制品清理管理 （C1）
+
+对于长期未使用的制品，应按版本、时间进行手动或自动清理，避免无效的制品文件占用制品库空间。对于开发快照仓库的制品， 应当限制版本数量， 最多不超过 10 个。对于生产发布仓库，针对已部署到现网的版本，建议永久保存， 以便进行版本对照与追踪。
+
+## 4 制品依赖的第三方组件管理
+
+### 4.1 使用统一的依赖源 （C1）
+
+项目团队应使用统一制品库作为第三方组件的依赖源。制品库应统一代理第三方组件的官方下载源，包括《中国电信软件开发组件清单》，组件的引入和使用应符合《中国电信软件开发统一技术栈要求(试行版)》（中国电信科创〔2023〕 1号） 。
+
+### 4.2 对第三方组件进行安全扫描 （C2）
+
+制品应该通过软件成分分析（SCA）工具进行制品安全扫描和许可协议分析。制品安全扫描工具需要展示第三方组件安全漏洞扫描详情，包括存在问题的组件名称 、版本 、 问题描述 、严重性等级 、CVSS 评分 、CVE 信息及对制品的影响路径等。
+
+### 4.3 制定第三方组件的使用规范 （C4）
+
+需要制定第三方组件的使用规范,应包含如下几个方面：对禁用的第三方组件， 应设置黑名单拦截。对需要管控的第三方组件， 应设置基线范围来进行管控。项目层面新增的第三方组件需要项目负责人进行审批。
+
+## 5 制品溯源管理
+
+为保证软件交付的质量， 必须在制品的生命周期过程中收集必要的元数据。元数据应伴随制品文件保存在统一制品库。制品元数据分为两类：制品本身的元数据 、制品的软件物料清单。
+
+### 5.1 制品元数据信息收集
+
+#### 5.1.1 制品本身的元数据 （C3）
+
+制品本身的元数据应包括以下几类：
+
+#### 5.1.2 制品的评分体系
+
+制品评分包括： 系统评分和用户评分。
+
+##### 5.1.2.1 制品的系统评分（C0）
+
+系统评分主要针对一方库制品和二方库制品，系统评分是按照既定规则对制品生命周期过程的一个综合评价 。评分应包含以下几点：通过统一制品库来发布符合代码质量扫描规范经过代码评审环节符合单元测试覆盖率/成功率指标是测试环境通过的可信制品是否存在安全漏洞运行时的动态指标， 如启动耗时， 启动时内存消耗等二方库制品的被引用数
+
+##### 5.1.2.2 制品的用户评分（C0）
+
+用户评分主要是针对二方库制品，使用方应对二方库制品给出用户评分和建议， 从而来推动二方库制品的持续改进 。评分应包含以下几点：接口设计是否合理依赖组件的多少 、依赖组件的深度
+
+### 5.2 制品软件物料清单收集
+
+大多数软件制品都包含一系列复杂的第二方组、第三方组件，软件物料清单(SBOM)是软件的组件列表，其中关键信息包括组件名称、供应商、版本号和许可证信息等。
+
+#### 5.2.1 确定软件使用的物料清单 （C0）
+
+在制品的构建阶段， 应基于制品包管理器（maven 、npm 等）查询依赖的第二方组件 、第三方组件， 从而获取软件物料清单。需要注意的是，制品引用的第二方组件常常引用其他的第三方组件，制品的SBOM 必须在依赖关系图中尽可能深入地枚举组件。同时还应提供依赖组件的分层信息， SBOM 中的每个组件都应该有自己对应的 SBOM。
+
+#### 5.2.2 判断软件物料清单中的第三方组件是否安全 （C0）
+
+1.能够支持通过 SBOM 快速定位到制品的第三方组件，并结合安全扫描工具来快速定位第三方组件是否有漏洞。2.当有新的安全漏洞时， 能够支持通过漏洞（或有漏洞的第三方组件）结合SBOM 来快速定位到有安全风险的制品， 并进行相关整改。

.agents/skills/telecom-rd-standards/references/source-documents/10-pipeline-management.md

@@ -0,0 +1,131 @@
+# 中国电信软件研发规范流水线管理分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范流水线管理分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步提升全集团的流水线使用水平， 实现持续集成 、持续部署， 集团编制了软件研发规范—流水线分册， 用于指导和规范全集团研发人员使用流水线， 实现持续集成 、持续部署的能力。
+
+### 1.2 文档结构
+
+本规范由文档说明 、项目过程中使用流水线的适用原则 、流水线执行的动作要求构成， 各章节的主要内容如下：第 1 章文档说明， 对编制目的 、文档结构 、使用范围 、起草单位 、解释权、版权和本规范用到的术语进行了说明。第 2 章项目过程中使用流水线的适用原则， 对流水线使用原则 、流水线命名规范 、步骤命名规范 、流水线触发类型分类进行了说明。第 3 章流水线执行的动作， 对流水线执行动作的种类 、流水线执行动作内容推荐及流水线执行动作要求进行了说明。
+
+### 1.3 适用范围
+
+本规范适用于指导中国电信软件研发工作。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+## 2 项目过程中使用流水线的适用原则
+
+### 2.1 流水线配置要求
+
+流水线的信息， 需按照以下规范进行配置：l 流水线必须属于单个项目组， 不允许跨项目使用流水线；l 流水线的命名要求做到简洁明了， 以便度量考核。
+
+#### 2.1.1 流水线命名规范
+
+流水线应当由英文小写字母（a-z） 、数字（0-9） 、 中划线（-） 组成， 且第一个字符仅允许使用字母。流水线名称不可使用“test ”、“demo ”等意义不明的字样， 可以使用{业务名称}-{模块名称}-{语言}这种名字标识 。通过流水线名字， 可以快速确认流水线用途。示例： “srdcloud-usercenter-java ”
+
+#### 2.1.2 步骤命名规范
+
+步骤名称可以由小写字母（a-z） 、数字（0-9） 、 中文组成。步骤名称不可使用“test ”、“demo ”等意义不明的字样 。应该根据每个步骤的具体用途作为步骤命名。示例： “Maven 构建 ”、“质量扫描 ”、“Java-Build ”
+
+#### 2.1.3 流水线运行环境要求
+
+流水线上运行的构建等步骤的执行环境必须和开发环境保持一致。
+
+### 2.2 流水线的触发类型
+
+流水线的触发类型定义为以下几种：
+
+1.手工触发——指开发人员登录集成工具手动触发流水线2.定时触发——指流水线由一个定时规则进行触发3.事件触发——指流水线由代码库或制品库的一些动作 、事件触发， 这些动作 、事件主要包括以下几种：
+
+### 2.3 项目过程
+
+项目过程中， 根据项目组选取不同的开发模式以及测试 、部署模式， 需要按照要求配置流水线。
+
+#### 2.3.1 代码评审流程
+
+项目开发过程中， 若项目组启用代码评审流程， 需要根据评审流程设置VerifyCI 流水线以及 MergeCI 流水线至少两条流水线。其中 VerifyCI 流水线与的触发类型需使用“代码提交评审 ”事件， MergeCI流水线的触发类型需使用“代码合入 ”事件。
+
+#### 2.3.2 不启用代码评审流程
+
+项目开发过程中， 若项目组不启用代码评审流程， 需要设置至少一条流水线 。其中该流水线的触发类型需使用“代码更新 ”事件。
+
+#### 2.3.3 测试过程
+
+项目测试过程中， 项目组需设置至少一条流水线触发测试任务， 触发类型可按需选择。
+
+#### 2.3.4 部署过程
+
+项目部署过程中， 项目组需设置至少一条流水线触发部署任务， 触发类型可按需选择。
+
+## 3 流水线执行的动作要求
+
+### 3.1 流水线整体流程图
+
+### 3.2 流水线包含的内容
+
+#### 3.2.1 持续集成
+
+1. 获取代码： 流水线的基础单元就是对代码进行才做， 因此流水线要对代码库具有下载的权限。2. 单元测试： 单元测试是开发者编写的一小段代码， 用于检验被测代码的一个很小的 、很明确的功能是否正确 。单元测试的实现方式包括： 人工静态检查 、动态执行跟踪两种。3. 代码检查（质量扫描）： 包括代码安全扫描和代码质量扫描 。代码安全扫描检查源代码缺陷是否会造成安全漏洞问题， 而代码质量扫描检查编码是否存在违规。4. 编译构建： 编译构建是指把软件的源代码编译成目标文件,并把配置文件和资源文件等打包的过程。
+
+5. 制品构建： 制品可能是一个包 、一个二进制文件或者一个 docker 镜像 。制品构建就是将编译构建的产出物制作成最终程序能够运行的文件过程。6. 上传制品： 将制品构建的制品上传到统一制品库中进行集中管理。
+
+#### 3.2.2 持续交付
+
+1. 执行测试用例： 可调用“测试管理 ”分册的测试任务能力， 或将一些比较复杂或者可以通过自动化脚本执行的用例通过接口进行调用， 可以自动完成某些测试 。大大节省测试人员的时间成本。2. 部署测试环境： 测试用例完成后， 可以将制品自动化部署到测试环境 。详细可见“部署 ”分册。3. 测试环境测试： 测试人员在测试环境进行用例测试 。如果发现测试 bug，要及时反馈给开发人员 。待开发人员修改完成并通过执行测试用例后， 测试人员再次进行测试。4. 部署预生产环境： 预生产环境和生产系统的同步性更高， 几乎一样 。有些测试， 比如需要大数据量的， 用预生产环境看程序性能比用测试环境（一般情况下数据会较少） 会更准确。5. 预生产环境测试： 在预生产环境中进行测试通过后， 准备部署正式生产环境。
+
+#### 3.2.3 持续部署
+
+1. 灰度发布： 是值一种平滑过渡的发布方式 。灰度发布可以保证整体系统的稳定， 在初始灰度的时候就可以发现 、调整问题， 以减少其影响度。2. 卡点检查： 通常是以集群方式进行部署 。发布后要在部署的集群进行人工检查或者 api 调用等方式对服务验证和测试 。经过验证通过后， 才能进行下一个集群的部署更新。
+
+### 3.3 流水线内容推荐
+
+项目过程中会配置多条 、多种用途的流水线 。本小节会根据流水线的用途、
+
+所在的分支 、项目所采用的开发流程等因素， 推荐该条流水线需要包括的内容。本小节内容非强制要求。
+
+#### 3.3.1 VerifyCI 流水线
+
+VerifyCI 流水线与代码评审流程有关， 在“代码提交评审 ”时触发。VerifyCI 流水线的作用一般是检查本次提交的代码是否可以正常构建， 执行代码的单元测试以及使用 SonarQube 工具进行代码扫描生成质量报告。
+
+#### 3.3.2 MergeCI 流水线
+
+MergeCI 流水线与代码评审流程有关， 在“代码合入 ”时触发 。MergeCI 流水线的作用一般是对本次代码进行构建， 并将构建产物推送至制品库。
+
+#### 3.3.3 ReleaseCI 流水线
+
+ReleaseCI 流水线， 一般会由代码库的 release 分支的“代码更新 ”事件自动触发， 这条流水线的作用一般用于对代码进行安全漏洞扫描。
+
+#### 3.3.4 测试任务流水线
+
+测试任务流水线， 可以对代码库的某个分支的“代码更新 ”事件自动触发，该条流水线执行自动测试任务。
+
+### 3.4 按能力等级划分流水线内容要求
+
+在项目过程中， 整体项目的流水线需具备以下内容（如某条流水线包括“制品上传 ”内容， 则视为该项目具有“制品上传 ”的内容）， 见下表（其中○代表可选， ●代表必选）

.agents/skills/telecom-rd-standards/references/source-documents/11-test-management.md

@@ -0,0 +1,185 @@
+# 中国电信软件研发规范测试管理分册（修订版）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范测试管理分册 （修订版）
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步提升全集团的软件质量保障， 规范软件测试过程 、测试组织 、测试文档、测试缺陷和测试技术等管理，明确软件测试过程中的测试准则和方法，特制定本测试管理规范， 用于指导和规范全集团的软件测试过程。
+
+### 1.2 文档结构
+
+本规范由文档说明、总体要求，测试准则、软件流程、缺陷管理等部分构成，各章节的主要内容如下：第 1 章节-文档说明， 综述本文档的整体编制说明。第 2 章节-角色与职责， 对测试过程中的角色与工作职责进行描述。第 3 章节-测试流程， 主要描述测试各个过程中的工作要求。第 4 章节-分级测试要求， 基于研发流程对测试进行分阶段说明。第 5 章节-测试验收标准， 主要描述不同项目级别的测试验收要求。第 6 章节-缺陷管理， 主要描述软件缺陷的处理流程要求。第 7 章节-测试异常处理， 主要描述测试异常的处理流程要求。第 8 章节-软件环境划分， 主要描述测试环境各阶段的划分。
+
+### 1.3 适用范围
+
+本规范适用于指导中国电信研发项目软件测试工作的总体要求以及单元测试 、集成测试 、系统测试 、验收测试等测试活动的具体要求。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+## 2 角色与职责
+
+根据被测试软件的不同级别，软件测试的人员组织可能有所不同，从相对完整和严格的要求而言，软件测试组织主要包括如下工作角色。同时也可能存在一个人可以承担多个角色，一个角色也可以由多个人共同承担的情况，具体角色人员及其职责如下：
+
+## 3 测试流程
+
+### 3.1 总体流程
+
+软件测试贯穿项目的整个生命周期，为规范各测试活动，把控各环节的质量，各级别、类型的测试应遵循本章测试流程要求。测试流程分为测试计划、测试准备 、测试执行 、测试总结四个阶段， 具体流程描述如下：
+
+### 3.2 测试计划阶段
+
+#### 3.2.1 测试需求分析
+
+测试人员应全程参与需求分析与评审的过程， 并从测试角度，评估软件需求的可行性 、可测性， 充分了解需求， 明确需求的详细测试范围。
+
+#### 3.2.2 测试方案/计划设计
+
+测试方案/计划是指导测试过程的纲领性文件，在此阶段，测试负责人应以测试需求为基础， 制定详细的项目测试方案/计划， 为测试的执行提供依据。需求评审通过后， 由测试负责人根据需求内容， 确定测试范围和测试策略、估算测试工作量与资源、规划测试安排及进度，并对测试过程中存在的风险进行评估等， 输出测试方案。在测试流程中，测试负责人应按照标准制定合适的测试方案或测试计划并组织评审以验证其可行性。
+
+#### 3.2.3 测试方案/计划评审
+
+测试负责人完成测试方案或测试计划的撰写后，应组织产品经理、研发人员等相关项目成员进行测试方案评审，确保测试方案的可行性。评审结束后，负责将评审结果以及测试方案同步至所有相关人员。
+
+### 3.3 测试准备阶段
+
+#### 3.3.1 测试用例/脚本设计
+
+测试需求及方案确认后， 测试执行人员应根据需求内容和测试的类型，完成测试用例或测试脚本的设计编写，测试用例或测试脚本应尽可能覆盖需求涉及的业务场景 、系统功能 、条件分支 、边界值等。
+
+#### 3.3.2 测试用例/脚本评审
+
+测试人员完成测试用例或测试脚本的设计编写后， 应组织（项目经理、研发人员等相关项目成员）进行测试用例或测试脚本的评审，确保测试用例或测试脚本的正确性 、可行性和充分性。
+
+#### 3.3.3 测试环境准备/部署
+
+项目进入提测阶段后，测试人员可依据项目实际情况判断是否需要自行部署项目的测试环境；如需部署，测试人员应按照项目部署文档完成测试环境的配置部署并对环境加以验证。
+
+### 3.4 测试执行阶段
+
+在测试执行过程中，测试人员应依据测试计划以及通过评审的测试用例或测试脚本， 逐一执行 。在执行过程中， 测试人员应认真观察并如实记录测试过程、测试结果和发现的问题。测试人员的主要工作有以下两方面：
+
+（1） 根据每个测试用例/脚本的期望测试结果 、实际测试结果和评价准则判定该测试用例/脚本是否通过 。如果不通过,测试人员应认真分析情况﹐ 将问题记录于缺陷管理工具中，并告知相对应的研发人员让其进行确认与修复 。（缺陷管理具体流程见 6 缺陷管理）（2）当所有的测试用例/脚本都执行完毕,测试人员应根据测试的充分性要求和失效记录﹐ 确定当前的测试工作是否充分,是否需要增加新的测试内容 。如需增加测试内容， 则应进行测试用例/脚本的补充， 直至测试项达到预期要求(具体要求见 3.3.1 测试用例/脚本设计 、3.3.2 测试用例/脚本评审)， 此外， 增加的测试内容需记录在册， 用于后续的项目复盘或总结分析。
+
+### 3.5 测试总结阶段
+
+#### 3.5.1 测试结果分析
+
+测试执行结束后， 测试人员应根据需求规格说明书 、测试计划 、测试执行结果、缺陷清单等作为依据，对本次测试的需求整体内容进行系统的分析测评，是否达到需求目的， 满足测试准出规范。
+
+#### 3.5.2 测试报告撰写
+
+测试报告是产品需求测试阶段的最终文档产出物，测试报告记录测试的过程与结果，对发现的问题和缺陷进行分析，为软件存在的质量问题提供依据， 同时为软件的验收和交付打下基础。
+
+#### 3.5.3 测试归档
+
+软件测试文档是测试过程的重要组成部分， 提供了测试过程的记录和证据，测试归档根据 4.2 节测试准出要求， 测试工作结束后，对测试过程中涉及到各种标准文档进行归档， 保存测试组织资产。
+
+## 4 分级测试要求
+
+为保障软件测试质量，对于较大型的软件测试应实施分级管理，通常软件测试级别分为： 单元测试、集成测试、系统测试、验收测试。项目组应根据项目任务书， 并结合实际需要， 制定各阶段的测试内容及准入准出标准。
+
+### 4.1 单元测试
+
+单元测试的对象是可独立编译或汇编的程序模块 、软件构件或软件中的类（统称为模块），其目的是检查每个模块能否正确地实现设计说明中的功能、性能 、接口和其他设计约束等条件， 发现模块内可能存在的各种差错。
+
+### 4.2 集成测试
+
+集成测试的目的是检查模块之间， 以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
+
+### 4.3 系统测试
+
+系统测试的对象是完整的、集成的计算机系统， 系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发合同规定的要求。
+
+### 4.4 验收测试
+
+验收测试的目的是在真实的用户（或系统）工作环境下检验完整的软件系统是否满足软件开发技术合同（或软件需求规格说明）规定的要求。其结论是软件的需方确定是否接收该软件的主要依据。
+
+## 5 测试验收标准
+
+测试准出标准是指结束当前版本的测试工作所需满足的条件。
+
+## 6 缺陷管理
+
+本章节内容定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性， 以保证项目研发质量。
+
+### 6.1 缺陷描述
+
+缺陷的描述主要包含以下要素： 缺陷标题 、缺陷类型 、缺陷严重等级 、缺陷优先级、缺陷状态、缺陷复现步骤、测试人员、缺陷解决人、解决方案、解决日期等（具体信息可详见附件《缺陷追踪表模板》）
+
+#### 6.1.1 缺陷类别
+
+根据引发该缺陷的根源进行分类， 缺陷类别可分为需求缺陷、架构缺陷、设计缺陷 、编码缺陷 、测试缺陷 、集成缺陷。
+
+#### 6.1.2 缺陷严重等级
+
+根据缺陷导致的后果严重度， 缺陷严重等级一般可分为四类： 致命 、严重、一般 、轻微。
+
+#### 6.1.3 缺陷优先级
+
+缺陷优先级一般可分为四类： 立即解决 、优先解决 、一般 、较低。
+
+#### 6.1.4 缺陷状态
+
+缺陷主要包括以下状态：
+
+### 6.2 缺陷处理流程
+
+#### 6.2.1 提交缺陷
+
+测试人员在发现缺陷后，应对缺陷的类型、复现步骤、影响范围、严重等级、处理优先级等信息进行分析，确认（与测试负责人、研发负责人确认或自主确认）缺陷的修复人，记录缺陷信息于缺陷清单中交予缺陷修复人员或在缺陷管理工具中记录并指派给对应修复缺陷的研发人员。
+
+#### 6.2.2 确认缺陷
+
+研发人员在接收到缺陷后， 应对缺陷的信息进行确认， 确认无误后， 可依据缺陷确认的结果对缺陷进行处理。
+
+#### 6.2.3 修复缺陷
+
+研发人员在确认缺陷完毕后，应依据缺陷的优先级对缺陷进行修复，修复完成并更新系统后，应更新缺陷的状态并告知对应的测试人员进行缺陷的回归验证。如研发人员因各种原因在短期内无法对缺陷进行修复的，可与产品经理进行协商， 是否能对缺陷进行延期处理。
+
+#### 6.2.4 缺陷验证
+
+测试人员在接收到缺陷已修复的信息时，应按照缺陷复现步骤，对原有缺陷进行回归验证，并根据验证结果，验证成功则关闭缺陷，验证失败则重新记录失败原因并将缺陷指派给研发人员进行修复。
+
+#### 6.2.5 缺陷激活
+
+缺陷关闭后，状态并非一成不变，在遇到复现情况时，可激活已关闭的缺陷。
+
+## 7 测试异常处理
+
+### 7.1 测试暂停/恢复
+
+在测试过程中遇到严重错误或不可抗因素影响导致无法进行测试活动时，允许暂停测试活动， 直至符合测试恢复原则。
+
+### 7.2 测试争议处理
+
+当对测试结果出现争议时，应依据争议的原因， 区分在不同情况下的最终决策者。
+
+## 8 测试环境划分
+
+测试环境是测试工作中非常重要的一环，稳定和可控的测试环境，可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。根据测试活动目的不同， 会区分出不同的软件环境， 生产实践中， 也会存在将多个测试活动都在同一套环境上进行的情况，各项目根据实际需求视情况而定。

.agents/skills/telecom-rd-standards/references/source-documents/13-deployment.md

@@ -0,0 +1,127 @@
+# 中国电信软件研发规范部署管理分册
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+中国电信软件研发规范部署管理分册
+
+中国电信集团有限公司
+
+## 2023 年 12 月
+
+i
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+iii
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+为进一步规范全集团的软件产品的部署，明确部署过程中的要求和流程，特制定本部署管理规范， 用于指导和规范全集团的软件部署过程。
+
+### 1.2 文档结构
+
+本规范由文档说明、部署管理和部署环境要求等部分构成，各章节的主要内容如下：第 1 章节-文档说明， 综述本文档的整体编制说明。第 2 章节-部署管理，规定部署流程，部署前的准备工作，部署审批、部署任务设置及部署执行各环节的要求第 3 章节 -部署环境要求， 对云网环境和私有环境下 K8S（CCSE） 及主机部署环境进行规范要求。
+
+### 1.3 适用范围
+
+本规范适用于研发项目部署到生产环境时在研发平台侧的相关流程和要求 。项目部署在生产平台侧的相关流程和要求， 按照对应生产平台的相关规范执行。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信集团公司。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信集团公司。
+
+### 1.6 版权
+
+本规范的版权属于中国电信集团公司。
+
+### 1.7 名词解释
+
+无
+
+## 2 部署管理
+
+### 2.1 部署流程
+
+应用/产品部署分为四个步骤：a. 部署准备： 完成部署所需的前置工作， 包括测试 、准备相关信息和文档等；b. 部署审批： 项目组发起部署申请流程， 提交部署所需相关信息和文档，由项目经理及相关管理方进行审批；c. 部署任务设置： 根据不同部署环境和部署类型的要求， 进行部署任务的创建和设置d. 部署执行： 根据部署任务执行部署动作e. 部署验证： 部署完成后， 使用用例验证部署的正确性以及服务的可用性
+
+### 2.2 部署准备
+
+#### 2.2.1 测试工作
+
+部署前应完成项目的上线测试工作，符合测试规范的准入和准出要求， 并提交相应测试报告 。（C1）
+
+#### 2.2.2 部署需提供的相关信息和文档
+
+在进行应用/产品部署前， 需要提供以下信息和文档。
+
+##### 2.2.2.1 版本及关联信息
+
+必须提供该次部署对应的应用/产品版本信息 。（C1）应提供对应本次部署应用/产品对应的需求及相应编号 。（C3）
+
+应提供应用/产品版本对应的（多个）制品的版本、以及各制品对应的代码版本 。（C1）
+
+##### 2.2.2.2 部署计划和实施方案
+
+应提供部署计划， 以及实施方案， 包括操作步骤说明、相关的执行脚本 、回退方案及数据备份方案等 。（C1）
+
+##### 2.2.2.3 其它信息和文档
+
+根据部署的应用/产品，提供部署所需的配置参数、数据初始化要求及相应的初始化版本；根据部署的生产环境不同，提供部署所需要的资源和权限申请，准备生产平台所需的其它材料， 详细见对应生产平台的部署规范及相关要求。
+
+### 2.3 部署审批
+
+在完成部署准备工作后，项目组应发起应用部署审批流程。需要提供的信息见 2.2.1 和 2.2.2 节； （C1）研发平台侧的流程应通过系统或手工对接生产平台侧的上线部署流程，整个流程完成后才可以执行上线部署动作。
+
+### 2.4 部署任务设置
+
+应用/产品使用部署任务进行自动化部署， 配置好部署任务后可自动执行部署流程相关的脚本 。部署任务针对单个项目， 不允许跨项目使用 。 （C3）
+
+#### 2.4.1 部署任务命名规范
+
+部署任务的标识应当有明确的意义，可以通过部署任务名称，快速确认部署任务的用途 。建议格式为{业务名称}-{模块名称}-{服务名称}-{环境}；部署任务的标识应当由英文小写字母（a-z） 、数字（0-9） 、 中划线（-）
+
+组成， 且以小写字母开头；示例： “srdcloud-usercenter-web-pro ”。
+
+#### 2.4.2 部署任务描述
+
+部署类型分为两种类型：K8S 环境（含集团CCSE）和主机环境（含虚拟机）；根据部署类型的不同， 部署任务也分为 K8S 部署任务和主机部署任务两种类型。
+
+##### 2.4.2.1 K8S 部署任务
+
+K8S 的部署任务使用 Yaml 文件描述部署相关的资源，格式符合 K8S 资源描述的要求；其中， 部署使用的镜像应明确其具体版本号， 禁止使用latest； 部署任务中配置的资源不得超过所指定命名空间的资源限制。
+
+##### 2.4.2.2 主机部署任务
+
+主机部署任务使用 tgz 形式的压缩包 。解压后应包括以下目录和文件： deploy/init.sh， 初始化准备工作脚本。deploy/start.sh， 服务启动脚本。deploy/stop.sh， 服务停止脚本。deploy/monitor.sh， 监控服务的脚本。deploy/clean.sh， 停止服务并清理部署包。
+
+### 2.5 部署执行
+
+部署任务的执行方式包括手动触发和流水线触发两种。部署至生产环境时，需每次进行审批等操作，因此应选择手动触发部署任务的方式 。部署任务完成审批后， 再采取手动触发的方式， 执行部署任务。
+
+### 2.6 部署验证
+
+部署执行完成后， 通过事先准备好的用例对应用/产品进行测试， 验证部署
+
+是否正确 、完整， 是否可以提供正常服务。
+
+## 3 部署环境要求
+
+### 3.1 部署环境概述
+
+本节描述生产环境的类型 、部署类型以及相关要求。应用和产品部署的生产环境分为两种类型：云网环境和私有环境。云网环境指集团 IT 和业务上云的生产环境 。其他非云网环境统称为私有环境。云网环境： 集团云网运营部统筹管理的环境， 如 IT 上云和业务上云环境。私有环境： 各单位自行管理的部署环境。
+
+### 3.2 云网环境要求
+
+研发项目在云网环境部署， 必须符合生产环境相关要求。云网环境应提供同步研发平台制品库到云网环境本地制品库的接口；云网环境应能接收研发平台侧发送的部署任务并执行。
+
+### 3.3 私有环境要求
+
+私有环境必须支持两种部署类型之一： K8S 部署或主机部署；私有环境必须能访问研发平台侧的制品库拉取制品；私有环境应能接收研发平台侧发送的部署任务并执行部署任务。因网络环境等特殊情况下可以拉取制品后进行离线部署。

.agents/skills/telecom-rd-standards/references/source-documents/20-rd-cloud-overview.md

@@ -0,0 +1,691 @@
+# 研发云平台互联互通规范总册（试行稿）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+研发云平台互联互通规范
+
+总 册
+
+中国电信股份有限公司研究院研发云平台运营中心
+
+## 2025 年 5 月
+
+版本变更历史
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+本规范旨在明确研发云平台与外部系统之间的互联互通要求，确保双方在技术实现、数据交换、安全管理和用户体验等方面达成一致，指导开发、测试和运维团队进行系统集成，提高集成效率，降低集成风险，确保系统的稳定运行和用户体验的连贯性。
+
+### 1.2 文档结构
+
+本规范由文档说明、总体要求、组织分工、互联互通方式及管理流程，互联互通安全要求、附件等部分构成，各章节的主要内容如下：第 1 章文档说明，对规范的编制、文档结构、使用范围、起草单位、解释权、版权和本规范用到的术语进行说明；第 2 章总体要求，对规范的编制原则进行说明；第 3 章组织、分工和职责，说明在研发云互联互通涉及的各个组织，以及他们在互联互通中的分工和职责；第 4 章平台互联互通方式，描述外部系统及服务与研发云互联互通的方式，包括在系统和服务集成、能力使用以及数据交互等；第 5 章互联互通管理流程，描述在互联互通的申请、实施及运营维护方面相关的流程和管理要求；第 6 章网络对接方案，描述研发单位现有开发测试资源接入研发云的网络接入方案，研发单位可以根据自己的具体情况选择其中一种方式接入；第 7 章互联互通安全要求，描述为保障互联互通后的系统以及数据的安全性，对实现技术、实施方案以及管理上的安全要求；附件包括在互联互通实施过程中涉及的申请模板、流程指引等内容。
+
+1
+
+### 1.3 适用范围
+
+本规范适用于研发云平台与外部系统及服务的集成，能力开放、数据交换等场景。
+
+### 1.4 起草单位
+
+本规范的起草单位是中国电信股份有限公司研究院研发云平台运营中心。
+
+### 1.5 解释权
+
+本规范解释权属于中国电信股份有限公司研究院研发云平台运营中心。
+
+### 1.6 版权
+
+本规范的版权属于中国电信股份有限公司研究院研发云平台运营中心。
+
+### 1.7 名词解释
+
+## 2 总体要求
+
+### 2.1 总体原则
+
+1. 标准化与规范化原则：所有集成接口和数据交换应遵循标准化的协议和格式，如 OpenAPI、OIDC 等。数据格式应统一，例如使用 JSON 或XML。这有助于确保不同系统之间的兼容性和互操作性2. 安全性与隐私保护原则：在集成过程中，必须确保数据的安全性和用户的隐私。这包括使用加密协议（如 HTTPS）、身份验证和授权机制（如 OAuth2、JWT）、以及数据加密存储。3. 高可用性与容错性原则：集成系统应具备高可用性和容错能力，确保在部分系统故障时，整个系统仍然可以正常运行。4. 以用户为中心的设原则：在制定系统对接方案时，需要始终以用户为中心，确保用户体验的连贯性和一致性。这包括简化用户操作流程、提供清晰的反馈信息、优化界面设计以及确保系统的响应速度。
+
+## 3 组织、分工和职责
+
+### 3.1 集团科技创新部
+
+集团科技创新部是研发云互联互通的统筹管理部门，主要职责：（一）指导研发云互联互通规范的编写，统筹推进研发云互联互通的工作实施，协调解决互联互通中的问题；（二）负责研发云集团级数据需求审批。
+
+### 3.2 研究院
+
+研究院是研发云互联互通在研发云平台方的实施和运维单位，主要职责：（一）制定研发云平台互联互通规范，按需配合完成互联互通的方案设计、流程及审批、方案实施、网络拉通实施等工作；（二）负责研发云平台总体安全工作，制定平台安全运营管理实施细则并组织落实执行，对互联互通系统接入的安全性进行评估。所有的系统接入、服务接入、数据开放、数据接入工作必须在保证网络安全、数据安全的前提下进行；（三）建立和完善专业化服务团队，负责研发云平台互联互通涉及的研发、体系建设及运营支撑等工作；响应集团内部互联互通需求，经对应级别的审批方审批后进行需求对接工作；（四）制定研发云平台运营维护管理实施细则并组织落实执行，持续建设完善研发云平台安全防护能力，确保研发云平台稳定与数据资产安全；（五）制定研发云互联互通系统安全/运营联动机制，与接入系统共同对发生的安全事件、故障问题进行联动处置，保障研发云平台与互联互通系统的安全稳定运行。
+
+### 3.3 互联互通对接方
+
+集团各部门、各省公司、专业公司、直属单位，及集团内规模化系统平台是研发云平台互联互通需求方，同时集团各部门、各省公司、专业公司、直属单位5
+
+也是研发云平台互联互通涉及到本组织负责的（组织、项目、人员维度）系统接入、服务接入及数据开放审批方、数据接入需求的主要实施方。主要职责：（一）按照规范提出明确、合规的互联互通需求，包括系统/服务/数据接入及数据开放需求；协助研发云团队完成互联互通运营工作，满足各类互联互通方式在服务能力、安全性等方面的要求，审批涉及到本组织负责的（组织、项目、人员维度）系统和服务接入、数据开放及接入需求；（二）承担接入系统/服务的网信安全责任，遵循研发云安全运营管理实施细则，定期开展安全巡检、安全漏洞扫描、安全审计及风险评估并及时进行加固整治，保障接入系统/服务的安全；（三）承担开放数据的数据安全性，保证从研发云获取、存储、使用数据过程的安全性；保证数据开放需求数据用途与申请时描述的用途一致，若需要超出申请时的用途，需要重新申请，经审批通过后实施变更；（四）承担接入系统/服务的维护职责，遵循研发云运营维护管理实施细则，负责接入系统/服务的可用性日常巡检、变更申请及操作、故障处理，保障接入系统/服务的稳定运行；（五）依据研发云互联互通系统安全/运营联动机制，配合制定接入系统/服务的故障及安全联动应急预案及相关预案的演练与实施，配合接入系统/服务的故障及安全事件联动处置，在规定的时间内及时处置各类异常事件；（六）负责接入系统/服务的用户使用支持，解决用户使用问题，保障用户使用体验。
+
+## 4 平台互联互通方式
+
+与研发云互联互通的方式包括以下 5 类，外部系统与研发云互联互通可能同时涉及到以下类型的多种：（一）系统接入系统接入是指外部平台与研发云进行集成，提供单点登录能力，实现平台的链接跳转或界面集成等。（二）能力开放
+
+6
+
+能力开放是指研发云平台通过 OpenAPI 及消息事件订阅机制，向外部系统开放平台能力、数据以及平台事件，从而实现外部系统对研发云平台的集成与自动化操作、以及系统间数据交互等场景。（三）数据开放数据开放主要提供研发效能类数据，为需求方提供研发过程管理依据，主要应用场景包括 2 类：
+
+1）系统级数据开放：适用于集团层面为实现某种业务目标，将研发云组织、项目、用户维度相关数据融入集团级规模化平台系统的场景，通常为定制化全集团级别的数据范围；
+
+2）组织级数据开放：各级单位为响应集团各项要求、加强本单位研发过程属地化管理，将研发类数据深度融合本单位研发管理平台的场景；
+
+（四）数据接入数据接入主要应用场景包括 3 类：
+
+1）省专公司将本地部署的测试或部署平台的过程数据同步到研发云，形成完成的研发流程数据视图；
+
+2）特殊项目（例如保密项目）的研发过程数据同步到研发云；
+
+3）系统接入等场景下，第 3 方平台向研发云汇聚该平台的研发过程及指标数据；
+
+（五）服务接入合作方通过标准化方式将自己开发的服务快速接入研发云平台，实现业务功能拓展，丰富研发云平台能力。目前接入的服务类型包括脚手架服务。脚手架服务用于生成项目的初始代码结构，包括目录结构、配置文件和基础代码模板，帮助开发者快速开始开发工作。
+
+### 4.1 系统接入
+
+系统接入可以有以下 3 种方式：链接跳转：点击链接跳转到对接系统，再登录对接系统。这个只适用于电信外部，账号不与研发云互通的系统的对接；7
+
+单点登录：通过 OpenID Connect 等协议，实现跨平台的身份验证和授权；界面集成：在单点登录的基础上，通过功能页面的集成与整合，实现跨系统间功能的统一呈现，提升用户体验。
+
+#### 4.1.1 单点登录
+
+研发云平台支持天翼认证、云认证及研发云账号密码登录三种方式的单点登录。
+
+1）天翼认证
+
+外部系统与研发云的认证对接基于天翼认证进行对接单点登录，对接规范按照天翼认证认证系统要求
+
+2）云认证
+
+外部系统与研发云的认证对接基于云认证进行对接单点登录，对接规范按照云认证认证系统要求
+
+3）研发云认证
+
+外部系统通过 OIDC 协议与研发云对接认证。
+
+#### 4.1.2 界面集成方式
+
+在单点登录的基础上，提供 2 种集成方式：界面跳转和界面集成
+
+1）界面跳转
+
+用户登录研发云后，点击外部系统跳转菜单跳转进入相应系统。对接单点认证后，与研发云门户产品经理确认系统跳转菜单位置，经过领导确认后排期上线。
+
+2）界面集成
+
+在研发云系统内嵌入外部系统功能页面，用户登录研发云后，在研发云的同一界面下完成相应的功能流程，无跳转体验。
+
+8
+
+页面集成通过 iframe 嵌入的方式集成，研发云与外部系统共同完成集成产品设置，包括菜单设置等。产品确认后研发云门户前端配置应用子系统嵌入外部系统链接。页面集成对于外部系统的要求如下：1. 由外部系统提供对应的前台菜单集合和链接2. 由外部平台提出打开对应菜单链接的其他要求，例如替换链接中的某些参数、新增某些参数/标识等3. 外部平台和研发云页面之间的通信要求，统一使用 postMessage 进行页面之间的通信。具体格式如下：window.postMessage({valueType: "xxx", // 双方约定事件名称data: {}, // 具体参数
+
+}, "*");
+
+#### 4.1.3 访问研发云资源
+
+在用户使用对接系统功能时，可能需要将对接系统的产出，例如代码、制品等资产同步到研发云系统，或者从研发云拉取到对接系统。涉及研发云的资源主要包括：> 代码库> 制品库> 组件广场利用在用户认证授权过程中获取的 Token 访问研发云资源。研发云在生成 access/id token 的时候，将对资源访问的动态密码放到 ID token（JWT）的 payload 里。对接系统接收到 token 后，解析出 token 中的动态密码。后续使用动态密码访问资源系统
+
+1) 用户授权后，用户中心根据授权情况去各个资源中心获取动态密码；各资源中心提供获取动态密码的接口；
+
+9
+
+2) 用户中心将获取的动态密码编码到 ID Token（JWT 格式）的 payload 中，并返回给对接系统；
+
+3) 对接系统对 ID Token 进行解析，取出动态密码，用于后续访问研发云资源；
+
+4）资源中心负责对其颁发的动态密码的访问权限及生命周期的管理。动态密码的初始有效期由各资源中心确定，同时，各个资源中心按自身的产品规划，可提供延长、终止 token 有效期等功能。
+
+### 4.2 能力开放
+
+#### 4.2.1 OpenAPI
+
+研发云平台提供标准化 OpenAPI 接口，面向客户第三方平台提供的研发云应用能力开放服务，包括用户管理、敏捷能力、共享文档、Wiki、流水线等能力开放。旨在帮助用户调用研发云的应用能力，实现对研发云平台的集成与自动化操作。
+
+##### 4.2.1.1 应用场景
+
+场景（一）：打通项目立项及需求同步，避免在两个系统重复操作客户自身的 PMS 系统，计划与研发云对接，打通项目立项，建立项目团队，以及将需求同步到研发云工作项。这个场景可使用研发云提供的项目/用户以及工作项的能力接口去实现相关流程。场景（二）：从获取研发云项目文档数据进行考核为检查各项目组的过程文档是否齐备，符合中国电信软件研发规范的要求，客户的 PMS 管理系统计划定期对各项目组的文档进行抽检。抽检的原则是检查项目文档是否包含某些要求的关键字。这个场景可使用研发云的项目/用户，以及文档，wiki 等应用接口实现。场景（三）：研发云 CI 能力与客户自有 CD 能力的整合
+
+10
+
+客户自身的综合研发系统，想借用研发云 CI 的能力，实现代码协同和编译构建，然后将构建的成品镜像使用自身的 CD 系统部署到目标环境中。这个场景可使用研发云的 CI 相关的能力开放实现。
+
+##### 4.2.1.2 鉴权实体
+
+第三方平台在调用研发云能力开放接口时，根据不同的接口，有以下 2 种方式：1. 平台级别的认证鉴权。使用预先申请的“外部用户账号”作为接口鉴权实体。外部帐号需由第三方平台向研发云平台申请。第三方平台，如果其业务也与机构相关，应根据机构申请多个外部用户帐号，同时应具备多个外部用户账号的管理能力：可根据每个对话所服务的对象不同而选择正确的外部用户账号作为接口调用的鉴权参数。2. 用户级别的认证鉴权。使用当前登录用户的授权信息去访问相关资源。在用户和研发云 oauth 单点登录过程中，由用户中心统一生成 auth_token并通过 id_token 返回给外部应用。调用接口时，在 header 中添加 auth_token作为鉴权参数。具体流程参考研发云互联互通规范-系统接入技术规范（用户认证和资产授权）。
+
+##### 4.2.1.3 能力开放目录
+
+OpenAPI 可按能力类型和能力归属产品模块两种方式分类。在此按照能力的类型可以划分为机构级、项目非资产级和项目资产级三类（分册将按能力归属产品模块分类详述）。
+
+#### 4.2.2 消息事件订阅
+
+研发云事件能力开放是研发云平台面向各组织提供的消息事件订阅服务。各组织的“ 能力开放管理员”可以设置第三方推送地址，订阅研发云已开放的事件，如流水线配置变更事件、代码库变更事件、安全中心 Sonar 扫描结果通知事件等，并在内部平台进行二次处理后实现对应的消息事件通知。
+
+##### 4.2.2.1 已开放的事件
+
+已开放的应用中心和事件● 用户中心：用户在账号开通、密码重置● 代码中心：代码库变更● 集成中心（流水线）：配置变更、 流水线任务执行状态更新、错误日志推送● 安全中心：Sonar 扫描结果● 部署中心：云网集群资源部署对象删除事件12
+
+##### 4.2.2.2 事件订阅权限要求
+
+● 账号需具有“能力开放管理员”角色权限。● 所属组织需加入组织白名单。
+
+##### 4.2.2.3 事件订阅推送方式选择
+
+每个组织仅支持选择一种推送方式： DCOOS（云桥）、HTTPS/HTTP。a）DCOOS（云桥）接入说明支持推送数据至 DCOOS 地址，DCOOS 注册及使用介绍参考“DCOOS(云桥)使用介绍” ，更多问题请咨询云桥平台支撑团队。注意事项：注册 api 时须选择集团 eop，1.0 环境。设置 DCOOS 方式时，除需填入地址外，还需从 DCOOS 平台获取 AppID、 AppKEY 填入后，方可保存设置。b）HTTPS/HTTP 接入说明仅组织级数据订阅支持 HTTPS/HTTP 形式，基于数据安全要求，推荐HTTPS。接口地址开发完成并填入地址后，即可准备接收已订阅数据推送服务。注意，以下情况可能会导致地址无法推送，保存不成功：1.地址对应的服务无法正常访问（网络未放通或服务异常）2.地址对应的服务没有参照研发云消息事件接收开发指南实现
+
+##### 4.2.2.4 事件订阅网络配置
+
+DCOOS：只需订阅方打通与 DCOOS 网络即可；HTTPS/HTTP：需要告知研发云平台支撑人员订阅服务 IP 地址，由研发云放通出口网络策略。同时，订阅方服务侧也需要放通研发云的出口 IP（出口 IP联系研发云支撑团队获取）。
+
+13
+
+### 4.3 数据开放
+
+研发云数据开放目前面向各单位支持组织级数据订阅（订阅本组织研发过程数据）、系统级数据订阅（面向集团规模化系统提供定制化数据订阅服务）或数据查询接口、取数试算阶段提供人工取数服务。
+
+#### 4.3.1 数据开放范围和开放对象
+
+## 一、研发云平台数据开放范围：
+
+（一）基于研发云平台的基本对象的维度信息数据：组织、项目、用户等基本信息维度表；（二）基于研发云平台的研发过程效能度量明细数据：代码提交记录、工作项变更记录、部署任务执行记录、流水线构建记录等明细表；（三）基于研发云平台的效能度量汇总模型数据：项目、用户维度汇总指标等；（四）基于研发云平台的研发成果数据：专利等相关数据；注意：（一）数据开放不涉及源代码文件、制品等内容，由相应中心负责该资产的开放范围、开放方式及权限控制等；（二）研发云除特殊情况外，不对外开放从其他第三方平台获取的数据。
+
+## 二、研发云平台数据开放对象：
+
+（一）对象一：集团及下属组织：原则上仅面向集团本部各部门及中心、省公司、直属专业公司提供数据开放，范围以外的下级组织需向上级组织沟通获取研发云数据。原则上各组织仅可订阅归属为本组织相关研发云数据。若存在超出归属为本组织的数据需求，需向数据范围对应级别的审批方提出申请，审批通过后开放。（二）对象二：集团内规模化的平台系统：原则上，仅面向集团统筹建设的规模化平台系统开放数据，如原子能力平台、人才云等。研发云经数据范围对应级别的审批方（见 5.3.2）审批通过后按需开放需求数据。
+
+14
+
+#### 4.3.2 数据开放形式
+
+按需支持 3 种数据开放形式：（一）研发云提供数据查询接口方式：适用于单次查询结果量不超过 50 条、单次应答传输数据量小于 1MB 的场景。视具体情况可以通过以下两种方式接入：1.通过研发云能力开放-应用能力开放提供，按照研发云应用能力开放专区指引接入2.通过 DCOOS 提供，按照 DCOOS 能力开放指引接入
+
+（二）需求方进行研发云数据订阅方式：对于需求方需要获取数据进行二次开发、个性化数据分析，且需要的数据量较大，当数据变更时需要及时更新的场景，可以采用数据订阅方式。同时，研发云可以提供 Java SDK，便于需求方调用，实现数据自动入库。需求方可以通过以下 3 种方式订阅数据：1.DCOOS 方式当需求方具备接入 DCOOS 网络条件时，提供数据接收接口并注册到 DCOOS，研发云调用需求方 DCOOS 接口推送数据。2.HTTP/HTTPS 方式当需求方不具备接入 DCOOS 网络条件时，可以提供基于 Http/https 的数据接收接口，研发云调用需求方接口推送数据。3.Kafka 方式研发云开放 Kafka 集群，为需求方开通专属消息队列的订阅权限，需求方可按需要消费消息获取所需要的数据。
+
+（三）人工取数方式对于暂时无法通过方式一、方式二获取，且有迫切需求的，需求方可按流程向数据范围对应级别的审批方提出数据需求申请（见 5.3.2），经审批后，由研发云团队人工的方式实施取数。
+
+15
+
+对于同一需求，需要多次取数的情况，首次提交申请时需说明取数频率周期。后续每次取数需提申请。若人工取数方式进入常态化阶段，需考虑变更为自动化取数方式，以减少不必要的人力资源消耗。
+
+### 4.4 数据接入
+
+数据接入适用于集团在推进系统数据融通及研发类数据深度融合研发云平台的场景，旨在为数据接入研发云数据中台提供统一的标准与整体要求，确保数据的规范性、一致性与可管理性。例如统一技术栈 Apaas 数据，MSS 相关数据，因特殊原因限制无法在研发云平台上开展活动涉及的相关数据，例如独立部署功能所产生的数据。
+
+#### 4.4.1 接入数据模型
+
+对应研发云数据中台的汇总模型和明细模型，与研发云的实体关联的数据，如项目、人员、组织维度的汇总数据以及明细数据。
+
+#### 4.4.2 接入方式
+
+研发云平台提供统一的能力开放接口，以 OpenAPI 方式给外部系统使用。 OpenAPI 接入技术要求详见《5 研发云互联互通规范-能力开放技术规范(OpenAPI 接口)》。
+
+#### 4.4.3 接口规范
+
+外部系统数据（包括研发活动指标和数据）可根据需要接入研发云。数据接入研发云时，根据对接的内部系统可细分，主要差异在于接口格式。a. 通过消息中心接入b. 通过其他中心接入
+
+16
+
+##### 4.4.3.1 通过消息中心接入
+
+部署数据等的接入是通过消息中心实现的。研发云平台定义了统一的 CloudEvents 格式的消息数据规范。外部系统基于统一数据规范，调用研发云数据推送能力开放接口（OpenAPI），向研发云推送相关业务数据。数据接收流程涉及 3 类系统级对象：外部系统数据发送方（以下简称：发送方），研发云消息中心（以下简称：消息中心），研发云数据接收方（以下简称：接收方）。消息中心，作为研发云接收外部系统消息数据的统一入口，负责数据类型注册管理、数据格式校验、数据接收、暂存、分发。消息中心对外提供 2 个标准的数据推送能力开放接口：单消息推送和批量消息推送。接口通过研发云能力开放专区对外提供，并同时注册到 DCOOS。发送方，根据自身系统与研发云的网络联通条件，选择订阅研发云能力开放专区或者 DCOOS 的数据推送接口（订阅接口具体流程，详见研发云能力开放专区或者 DCOOS 文档），与接收方预先协商消息数据格式，调用消息中心开放接口，实时推送或者批量推送数据，当调用接口失败（即，HTTP 状态码非
+
+200），要负责重新推送，以保证数据能最终推送成功。
+
+接收方，负责处理能力开放接口的接入数据，或向消息中心注册需要接收的消息数据类型，并订阅和处理消息数据。
+
+##### 4.4.3.2 通过其它中心接入
+
+例如测试数据的接入。详细参见《5 研发云互联互通规范-能力开放技术规范(OpenAPI 接口)》。
+
+### 4.5 服务接入
+
+17
+
+合作方通过标准化方式将自己开发的服务快速接入研发云平台，实现业务功能拓展，丰富研发云平台能力。目前支持的主要内容是脚手架接入。脚手架服务从模板快速灵活的生成各类搭配的项目初始化代码库。
+
+## 5 互联互通管理流程
+
+外部系统与研发云互联互通过程中，涉及到接入、账号密码申请等管理流程，以下章节描述各种互联互通方式相关的管理流程。所有流程均使用研发云问需系统进行。
+
+### 5.1 系统接入
+
+外部系统接入研发云，需要完成系统接入审批流程和系统接入上线流程。
+
+#### 5.1.1 系统接入审批流程
+
+外部系统接入研发云前，需要提交相关资料，进行接入审批，审批完成后，获取用于接入联调和测试的 client id、client secret 等信息。
+
+流程描述：
+
+18
+
+1. 外部系统接口人发起审批流程，需要填报接入研发云所需的相关信息及附上相关资料：
+
+a) 外部系统的介绍（功能、使用、界面）
+
+b) 外部系统使用前端技术
+
+c) 外部系统维护所需的架构设计文档，包括部署架构、网络交互架构、服务清单等
+
+d) 拟采用的认证方式（天翼认证、云认证、研发云认证）
+
+e) 其它相关信息和资料
+
+i. 外部系统接口信息（包括 URL，IP 端口等）ii. 按需提供交互架构、数据等设计方案、数据库初始化/升级等脚本2. 产品经理接收到申请后，组织开发团队完成初步的系统接入设计，包括以下内容：
+
+a) 系统入口
+
+b) 菜单、界面布局等
+
+c) 按需完成系统交互架构、数据交互情况、服务部署规划等设计说明
+
+3. 产品经理完成设计后，提交运维和安全团队会审4. 运维和安全团队根据系统集成需求和设计进行初审，评估可行性和可能存在的问题，会审后提交项目经理审批5. 项目经理审批后，提交用户中心（菜单）与运维团队（网络）进行配置6. 用户中心配置接入生产系统所需的 client id/client secret，通过邮件点对点发送给外部系统联系人；运维团队进行网络配置（通过沟通群直接与用户沟通验证）；7. 返回流程审批及处理结果
+
+#### 5.1.2 系统接入上线流程
+
+外部系统完成接入的开发联调后，在正式接入生产系统前需要提交上线申请。
+
+19
+
+流程：1. 外部系统接口人提交上线要求的相关资料，包括：
+
+a) 系统漏洞扫描、渗透测试报告
+
+b) 安全保密协议、服务保障 SLA 协议等协议签订/盖章材料
+
+c) 安全事件应急处理预案与安全运维联系人信息
+
+d) 数据安全保护措施和保护能力评估报告，涉及重要和核心模块数据交互的接入方，还应提供权威的第三方机构的安全测评报告
+
+e) 接入研发云系统的测试报告
+
+f) 网络放通所需信息（对端系统 IP 端口等）
+
+2. 产品经理进行资料完备性审核后，提交运维团队和安全团队进行审核3. 运维团队和安全团队进行安全性检查（同一流程环节即可，没有先后关系）后，提交项目经理审批4. 项目经理审批后，提交用户中心（菜单）与运维团队（网络）进行配置5. 用户中心配置接入生产系统所需的 client id/client secret，通过邮件点对点发送给外部系统联系人；运维团队进行网络配置（通过沟通群直接与用户沟通验证）；6. 返回流程审批及处理结果
+
+### 5.2 能力开放
+
+#### 5.2.1 OpenAPI
+
+20
+
+OpenAPI 由新增和使用两个场景形成完整的管理流程。
+
+##### 5.2.1.1 新增 OpenAPI
+
+现有 OpenAPI 无法满足需求方时，可参考新增 OpenAPI 的整体开发流程实现新增 OpenAPI 的及时上线1. 需求方可向研发云产品团队提出 OpenAPI 新增需求；2. 研发云产品团队评估需求是否纳入规划；a. 若评估通过将纳入规划b. 若评估不通过告知需求方原因3. 研发云开发团队将纳入规划的 OpenAPI 需求排期开发；4. 研发云团队完成上线后告知需求方已实现。
+
+##### 5.2.1.2 申请使用 OpenAPI
+
+现有 OpenAPI 可满足需求时，参考申请 OpenAPI 使用流程进行调用1. 需求方所在组织的能力开放管理员通过能力开放页面发起申请应用能力使用评审2. 研发云运营团队审批评审a. 若评审通过后将为需求方开通账号与权限
+
+21
+
+b. 若不通过将说明原因告知需求方3. 需求方调用 OpenAPI
+
+#### 5.2.2 消息事件订阅
+
+消息事件订阅时，需求方需查看该事件是否已开放。已开放事件，需求方具有权限后即可订阅；未开放事件，需求方需提出需求申请，研发云团队进行需求评估。
+
+##### 5.2.2.1 事件已开放
+
+1. 需求方可根据指引查看是否具有以下订阅权限；a. 能力开放管理员b. 所在组织在组织白名单列表2. 需求方根据需求订阅对应事件，并进行测试、二次开发和集成。
+
+##### 5.2.2.2 事件未开放
+
+1. 事件未开放时，需求方可由单位接口人在研发云问需系统提交事件需求；
+
+22
+
+2. 研发云团队将评估该需求是否实现；a. 若实现，研发云团队将该需求排期、开发、测试、上线。上线后将在问需系统向问需提出人同步上线情况b. 若不实现，将在问需系统说明原因告知需求提交人3. 需求方调用新上线的消息事件。
+
+### 5.3 数据开放
+
+#### 5.3.1 数据开放流程
+
+数据开放流程按数据开放形式分不同流程。
+
+##### 5.3.1.1 数据查询接口方式
+
+需求方需将数据需求描述清晰（具体字段、数据权限范围等）向数据范围对应级别审批方申请数据需求，经审批通过后开展数据对接工作。1. 研发云应用能力开放
+
+1) 研发云团队将数据接口发布到研发云应用能力开放专区；
+
+2) 需求方按照应用能力开放专区指引申请开通接口访问。
+
+2. DCOOS 能力开放
+
+1) 研发云团队将数据接口注册到 DCOOS；
+
+2) 需求方在 DCOOS 提出订购数据接口的申请；
+
+3) 研发云团队在 DCOOS 批准订购申请；
+
+4) 需求方接入 DCOOS 进行调测。
+
+##### 5.3.1.2 数据订阅方式
+
+面向不同数据开放对象及场景，数据订阅流程分别为：
+
+1.组织级数据订阅场景：面向集团各部门、各省公司、专业公司、直属单位提供本组织研发云数据订阅，该场景需求方需使用“组织级数据订阅管理”应用进行数据订阅：
+
+1) 数据准备：研发云按各单位提出的问需准备可订阅数据表清单，在研发云能力开放专区发布数据开放表；
+
+2) 数据订阅管理应用白名单开通申请：数据订阅管理应用初次使用需开通白名单访问，数据需求组织向研发云邮件申请开通“数据订阅管理” 白名单。研发云审批后开通；
+
+3) 角色开通：数据需求组织在企业管理后台为本组织数据订阅实施人员开通本组织“ 能力开放管理员”角色；
+
+4) 设置订阅方式：数据需求组织按需选择数据订阅推送方式，DCOOS、 HTTPS/HTTP 或 Kafka；
+
+5) 订阅数据：数据订阅推送方式成功设置后，数据需求组织按需选择要订阅的数据表，开启推送。订阅数据过程中，如遇问题应及时响应并关闭推送。若要订阅超出本组织负责的数据范围，需要提出申请，通过后开通。
+
+2.系统级数据订阅场景：面向集团内规模化的平台系统提供个性化跨组织数据订阅，该场景需求方需使用“系统级数据订阅管理”应用进行数据订阅：
+
+1) 需求系统对接人需将数据需求描述清晰（具体字段、数据权限范围等）提出申请，由数据范围对应级别的审批方审批；
+
+2) 需求审批通过后，研发云根据数据需求准备数据表的开发；
+
+3) 需求系统选择数据订阅方式：DCOOS、HTTPS/HTTP 或 Kafka，做相关开发准备工作；
+
+4) 订阅数据：需求系统做好数据订阅接收准备，双方测试联调后，正式接收数据推送。订阅数据过程中，如遇问题应及时响应并关闭推送。
+
+##### 5.3.1.3 人工取数方式
+
+1) 需求方对接人明确数据需求：具体字段、数据权限范围等；
+
+24
+
+2) 需求方对接人提出申请，由数据范围对应级别的审批方审批；
+
+3) 需求审批通过后由研发云实施，确保数据安全的情况下，数据文件加密的方式交付需求方。
+
+#### 5.3.2 数据范围级别及审批原则
+
+数据开放需求均需与集团层面现有业务场景强关联，有明确的集团层面业务对接人，具体审批原则：
+
+### 5.4 数据接入
+
+25
+
+本规范旨在明确数据接入的全过程管理要求，确保数据接入工作的安全性、合规性和高效性。流程涵盖需求提出、对接方式确定、审批、实施、网络申请、账号申请、上线、监控与维护等环节。
+
+#### 5.4.1 数据接入流程
+
+1. 需求提出
+
+### 1.1 数据需求：
+
+- 数据接入需求方提出数据接入需求，明确数据来源、数据类型、数据量、数据频率等。
+
+- 数据接入需求方提交需求文档，包括需求背景、需求内容、需求预期效果等。
+
+1.2. 确定对接方式
+
+- 数据接入方与研发云根据需求文档，确定数据接入的对接方式，如消息中心
+
+- 数据接入方与研发云制定对接方案，包括对接频率、数据格式、数据校验规则等
+
+1.3. 数据安全与合规性评估
+
+- 在确定需求和接方式的同时，数据接入方与研发云进行数据安全与合规性评估
+
+- 评估内容包括数据加密、数据脱敏、数据访问控制、数据隐私保护、数据使用许可、数据跨境传输等。
+
+2. 审批
+
+- 数据接入需求方提交对接需求及方案，由研发云运营小组、数据安全小组、数据中台及集团科创研发管理处进行审批。
+
+- 审批内容包括对接方式的可行性、数据安全、数据合规性等。
+
+3. 实施
+
+### 3.1 开发
+
+27
+
+- 审批通过后，数据接入需求方与研发云开始实施数据接入。
+
+- 实施内容包括开发对接接口、配置网络环境、测试对接效果等。
+
+### 3.2 网络申请
+
+- 根据对接方案，数据接入方与研发云申请必要的网络资源。
+
+- 网络申请内容包括 IP 地址、端口、网络带宽等。
+
+3.3. 账号申请
+
+- 根据对接方案，数据接入方与研发云申请必要的账号资源。
+
+- 账号申请内容包括账号类型、账号权限、账号有效期等。
+
+4. 数据质量验证评估
+
+- 在实施和上线前，数据接入方配合研发云数据中台进行最终数据质量的验证及评估。
+
+- 评估内容包括数据完整性、数据准确性、数据一致性等。
+
+## 5 上线运营
+
+### 5.1 上线
+
+- 实施完成后，数据接入方与研发云进行数据接入的上线。
+
+- 上线内容包括部署对接接口、配置网络环境、测试对接效果等。
+
+5.2. 监控
+
+- 在上线后，研发云进行数据接入的监控。
+
+- 监控内容包括数据接入频率、数据接入量、数据接入错误率等。
+
+5.3. 维护
+
+- 在上线后，数据接入方及研发云共同进行数据接入的维护。
+
+28
+
+- 维护内容包括数据接入故障处理、数据接入性能优化、数据接入版本升级等。
+
+## 6 下线
+
+- 下线流程经需求方提出，经集团审批后执行，包含数据归档或删除，网络/账号资源、服务等相关资源回收。
+
+### 5.5 服务接入
+
+#### 5.5.1 脚手架接入流程
+
+各单位的脚手架服务需按照以下标准流程进行接入：
+
+1）申请接入
+
+■ 各单位向研发云平台提出脚手架集成开发与接入申请（研发云问需）■ 审核通过后，研发单位与相关开发人员需与研发云签订数据安全协议
+
+2）代码开发
+
+■ 研发人员需遵循《6 研发云互联互通规范-服务接入技术规范（脚手架服务）》进行代码开发■ 开发后并在本地完成自测，并进行安全评估
+
+3）联调测试
+
+■ 研发单位向研发云申请进行集成测试，以及产品安全相关评估报告（产品无中高危漏洞与安全风险）■ 经研发云评估集成产品符合准入要求后，由研发云配合分配测试部署资源、指导协助完成部署与联调测试
+
+29
+
+4）上线生产
+
+■ 产品功能集成测试通过后，由研发单位提出生产上线申请，申请材料需同步提交运维所需的文档材料（部署架构、服务清单等）、更新相关安全评估报告、签订产品运营服务保障协议
+
+5）更新维护
+
+■ 产品上线生产后，由研发单位与研发云按照约定的分工职责和质量要求开展日常运营与迭代升级工作
+
+### 5.6 安全运营
+
+#### 5.6.1 重大安全事件应急处置流程
+
+重大安全事件是指已经发生的严重影响业务、对利益及声誉构成较严重威胁和影响的安全事件。主要包括：重要基础设施遭受攻击导致服务中断，设备被渗透控制，恶意程序传播，用户个人信息以及企业核心数据等批量泄露，以及其他严重安全事件。重大安全事件应按照以下步骤开展应急处置工作：I. 接入方监测到接入方系统或研发云平台发现重大安全事件后，应立即按照本单位制定应急预案进入应急状态，根据“边处置、边报告” 的原则，启动应急处置工作，并及时通过工单、电话、短信、邮件等方式向研发云报告；研发云平台监测到研发云平台或接入方系统发现重大安全事件后，研判重大安全事件影响范围，针对可能遭受影响接入方系统，应及时通过工单、电话、短信、邮件等方式告知相关接入方。II. 接入方和研发云双方应按照应急预案，对重大安全事件的类型、特点和原因进行分析研判，采取控制攻击源、过滤攻击流量、修补漏洞、查杀病毒、关闭端口、启用备份数据、暂时关闭相关系统等应急处置措施，以及防止发生次生、衍生事件的必要措施。对于大规模用户信息泄露事件，还应当及时告知受影响的用户，并告知用户减轻危害的措施。
+
+30
+
+III.重大安全事件应急处置期间，接入方和研发云双方应及时沟通重大安全事件处置进展情况。IV. 重大安全事件应急处置结束后，接入方应将应急处置报告发给研发云报备。
+
+#### 5.6.2 重大安全风险处置流程
+
+重大安全风险是指有可能引发接入方系统或研发云平台发生重大安全事件的风险隐患。重大安全风险主要包括：可能被利用的网络安全重大漏洞、开源组件或平台中可能存在的仆后门程序”、监测到的可能攻击或被植入病毒木马、重大威胁情报、不受控的软硬件供应商，以及其他可能导致重大安全事件的风险隐患。重大安全风险应按照以下步骤开展处置工作：I. 研发云对集团公司、研究院主管部门通报、第三方公司发布的重大风险预警，迅速组织评估危害程度和影响范围，按照应急预案开展处置，及时组织消除研发云平台安全风险，并研判重大安全风险影响范围，针对可能遭受影响接入方系统，及时向相关接入方反馈风险排查结果、整改计划、整改处置结果。II. 接入方对集团公司、研究院主管部门、研发云通报、第三方公司发布的重大风险预警，应按照应急预案开展处置，及时组织消除接入方系统安全风险，并及时向研发云报告风险排查结果、整改计划、整改处置结果。
+
+## 6 网络对接方案
+
+方案旨在解决研发单位现有开发测试资源接入研发云的问题，实现存量项目研发基础设施环境与研发云 CD 部署的全面对接。研发基础设施环境涵盖研发单位的开发、 测试及生产部署环境。依据各研发单位部署资源的网络条件，提供了以下几种网络打通方案供选择。研发单位资源网络环境主要分为三种类型，第一种类型是研发单位侧所有主机都可以直接访问 CN2-1124 网络；第二种类型是研发单位侧有一台主机可以同
+
+31
+
+时接入 CN2-1124 网络和本地内网；第三种类型是不能直接访问 CN2-1124，但可以访问互联网。对于第一种网络，研发单位的主机可以直接通过 CN2-1124 网络访问研发云平台，无需额外网络施工。对于第二种网络，需要在那台同时接入 CN 2-1124 网络和本地网络的主机上安装 Nginx 代理，通过代理接入研发云。对 于第三种网络类型，需在研发单位侧部署 SASE 网关，通过 SASE 网关叠加互联网实现对研发云平台的访问。
+
+### 6.1 通过 CN2-1124 直通
+
+采用本方案的前提条件：研发单位的开发、测试、生产部署环境能访问 CN2- 1124VPN 地址。
+
+研发单位侧主机直接访问研发云平台的 1124VPN 地址。
+
+### 6.2 通过 CN2-1124 中间代理
+
+采用本方案的前提条件：研发单位有一台服务器可同时接入 CN2-1124VPN 和本地内网环境
+
+研发单位侧主机通过 CN2-1124 Nginx 代理机接入研发云（代理机需研发单位提供域名证书并在各环境统一做域名解析，避免终端请求报证书错误以及自行配置 hosts 解析的问题）。
+
+### 6.3 通过 SASE 打通
+
+采用本方案的前提条件：研发单位的开发、测试、生产部署环境能访问公网当研发单位的主机不能直接访问研发云 1124VPN 地址时，采用 SASE 打通方案， SASE 打通 分为单向、双向、二级代理三种类型，其中双向、二级代理两种方式是在单向基础上额外再加一个 Nginx 实现研发云和研发单位资源的反代转发。
+
+#### 6.3.1 SASE 单向打通
+
+主要功能单向打通即可，可用于门户访问、代码/制品拉取、部署/测试代理安装等功能。研发单位资源需要配置路由策略将访问研发云（10.158.231.0/26）的流量全部转发到 SASE 代理节点（建议直接在每个环境的出口网关上配置，避免每台主机添加路由策略）
+
+#### 6.3.2 SASE 双向打通
+
+在单向基础上增加实现流水线专用节点接入、本地镜像同步推送（需要研发云服务端访问用 户侧主机资源）。在 SASE 单向打通的基础上，在 SASE 客户端所在的同一台主机上部署 nginx 代理 ，代理研发单位侧的主机端口，实现反向访问。
+
+#### 6.3.3 SASE 二级代理开放
+
+对于研发单位资源分散的部署环境（部署环境和 SASE 客户端不在同一网络)，在 SASE 客户端节点部署 nginx 代理，代理研发云平台开放给研发单位访问（必须通过白名单控制访问，研发云是内网系统，不允许直接公网代理开放访问。二级代理需研发单位提供域名证书并在各环境统一做域名解析，避免终端请求报证书错误以及自行配置 hosts 解析的问题）
+
+## 7 互联互通安全要求
+
+研发云平台系统间交互集成，接入方系统需满足以下安全管理要求。
+
+### 7.1 基本安全要求
+
+34
+
+1) 接入方应加强接入系统安全开发与运维工作，系统开发遵循安全开发规范，持续开展 SCA、SAST、DAST 等安全测试，定期扫描组件漏洞，及时修复或升级漏洞
+
+2) 接入方应提供接入系统的系统代码安全扫描、漏洞扫描、渗透测试报告，并交予研发云平台（结论部分）审核存档，对于相关报告中涉及的漏洞或安全风险应完成整改后再开展对接工作
+
+3) 在接入系统正常运营服务期间，接入方应对系统新增发现的安全漏洞及时修复
+
+4) 接入方应定期以及在大的系统升级后对系统进行全面安全评估，接入方对提供的评估材料和结论的真实性负责
+
+5) 接入方应具备日志审计与监控能力，记录所有系统操作，对异常事件实时监控与告警，保留日志至少 6 个月，并定期开展审计工作
+
+6) 接入方与研发云平台双方需遵守集团、研究院和研发云制定的数据安全制度规程，加强身份认证与授权管理，确保数据在采集、传输、存储等全生命周期中的安全管理和防护
+
+7) 接入方与研发云平台双方均应具备相应的安全事件应急处置预案，若发生系统被攻破、数据资产泄露、网络跳转攻击等安全事件时应第一时间通知对方安全联系人，进行必要的安全防护处置动作
+
+8) 在发生安全事故后，接入方与研发云平台双方应共同评估事故原因，确定责任归属，并据此采取相应的补救措施和责任追究
+
+### 7.2 API 对接安全要求
+
+1) 接入方应提供 API 技术安全相关文档，研发云基于文档，针对 API 进行渗透测试和漏洞验证
+
+2) 接入方系统与研发云平台系统间交互接口应使用传输加密和安全的通信协议。数据传输必须采用 TLS 1.3 及以上协议加密，敏感数据（如用户凭证、代码仓库密钥）需额外应用应用层加密（如 AES-256）。API 必须鉴权
+
+35
+
+3) 接入方系统应采取输入验证与输出过滤措施，防范 SQL 注入、XSS 等漏洞；并使用 OpenAPI 规范定义接口，避免暴露敏感信息
+
+### 7.3 页面集成安全要求
+
+1) 接入方系统功能页面通过 iframe 嵌入研发云，接入方页面须使用https协议与公网可信证书，避免影响研发云平台用户体验（浏览器会弹出安全风险提醒）
+
+2) 研发云平台配置 CSP 头，严格限制 iframe 来源 ，在 iframe 标签中添加 sandbox 属性，限制其 XSS 执行能力
+
+3) 研发云平台使用 CORS(跨域资源共享)严格限制来源域 ， 禁止配置Access-Control-Allow-0rigin:*,并对敏感操作(如文件上传)实施预检请求校验
+
+### 7.4 链接跳转安全要求
+
+1) 跳转合法性验证:所有外部链接跳转需实施白名单机制，禁止动态拼接未经验证的 URL，防范开放重定向(0pen Redirect)攻击
+
+2) 来源可信度验证: 服务器端使用 HTTP 协议头 Referrer Policy 和CSP(Content Security Policy)限制跳转来源域, 并通过数字签名(如JWT)验证跳转请求的完整性
+
+3) 用户风险提示:跳转至外部系统前，需明确提示用户目标域名的变更，并提供风险确认机制(如二次弹窗验证)
+
+### 7.5 单点登录(SS0)安全要求
+
+1) 身份联合审计: 记录 SS0 全流程日志，支持跨系统溯源审计，确保身份行为可追踪
+
+2) 防钓鱼与令牌劫持: 强制启用 HTTPS，禁用明文传输;针对移动端场景需防范通过恶意 App 窃取令牌
+
+36
+
+### 7.6 功能交互安全要求
+
+1) 接入方应明确数据交互范围、应用场景、交互方式，涉及数据采集应遵循合法必要、最小必要原则，涉及数据交互的应与研发云签订数据安全责任协议
+
+2) 接入方应提供数据安全保护措施和保护能力评估报告，涉及重要和核心模块数据交互的接入方，还应提供权威的第三方机构的安全测评报告。
+
+3) 涉及重要和核心模块数据采集的接入方，应具备数据全生命周期各环节的保护措施，落实数据安全五防，数安保护等级不低于研发云的数安等级要求
+
+4) 接入系统因自身安全问题导致研发云平台用户数据或其它资产数据泄露应承担相应安全责任
+
+### 7.7 其他安全要求
+
+按照网信安相关要求，研发云平台与接入方系统之间禁止批量同步以下数据：
+
+1) 用户信息；
+
+2) 项目信息；
+
+3) 用户角色和权限等信息。
+
+## 8 附件
+
+### 8.1 数据开放和接入流程指引模板
+
+#### 8.1.1 https://docs.srdcloud.cn/docs/iLFuvmdSldTmjTGE/ 《数据中台数据需求接入方流程 SOP-2025》
+
+#### 8.1.2 https://docs.srdcloud.cn/docs/UDnVSIxgKT0CHhgA/ 《数据开放-系统级数据开放数据需求申请模板》
+
+37
+
+#### 8.1.3 https://docs.srdcloud.cn/docs/m4kMLgKM6ZUOdpqD/ 《系统级数据开放-需求方接口人处理流程指引》
+
+#### 8.1.4 https://docs.srdcloud.cn/docs/zazLsJ7n44UtQabm/ 《数据开放-人工取数需求申请模板》
+
+#### 8.1.5 https://docs.srdcloud.cn/docs/9lPJ96tnp9Vv08oP/ 《数据开放-组织级数据开放数据需求申请模板》
+
+### 8.2 能力开放-OpenAPI 申请操作指引
+
+https://docs.srdcloud.cn/docs/VMAPVjDa8BFpZGqg/《附件 8.2 能力开放-OpenAPI 申请操作指引》
+
+### 8.3 能力开放-“ 消息事件订阅”操作指引
+
+https://docs.srdcloud.cn/docs/2wAlXK6ZENTW9gAP/ 《附件 8.3 “消息事件订阅”操作指引》
+
+### 8.4 集成方单位数据安全承诺书模板
+
+https://docs.srdcloud.cn/docx/rp3OVnoPaESoYBAm/《附件 8.4 关联方单位数据安全承诺书（样例）.docx》
+
+### 8.5 集成方个人数据安全承诺书模板
+
+https://docs.srdcloud.cn/file/gXqmeyDpPvCrJ8qo/ 《附件 8.5：关联方人员数据安全承诺书（样例）.docx》
+
+### 8.6 系统接入-第三方应用接入申请表
+
+附件 8.6：系统接入-第三方应用接入申请表
+
+38

.agents/skills/telecom-rd-standards/references/source-documents/21-rd-cloud-system-access-auth.md

@@ -0,0 +1,369 @@
+# 研发云互联互通规范系统接入技术规范（用户认证和资产授权）（试行稿）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+研发云平台互联互通规范
+
+系统接入技术规范（用户认证和资产授权）
+
+中国电信股份有限公司研究院研发云平台运营中心
+
+## 2025 年 5 月
+
+1
+
+版本变更历史
+
+2
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+### 1.2 适用范围
+
+### 1.3 起草单位
+
+### 1.4 解释权
+
+### 1.5 版权
+
+### 1.6 名词解释
+
+## 2 概述
+
+1
+
+在集团研发生态系统持续构建过程中，研发云平台与外部系统进行集成，以实现数据共享、功能协同或流程自动化。这里外部系统是指项目在研发过程中需要使用的外部系统，不包括与项目完成后需要部署的生产系统的对接。研发云平台支持天翼认证、云认证及研发云账号密码登录三种方式的单点登录。
+
+1）天翼认证
+
+外部系统与研发云的认证对接基于天翼认证进行对接单点登录，对接规范按照天翼认证认证系统要求
+
+2）云认证
+
+外部系统与研发云的认证对接基于云认证进行对接单点登录，对接规范按照云认证认证系统要求
+
+3）研发云认证
+
+外部系统通过 Oauth 协议与研发云对接认证。
+
+以上三种认证方式，均可在研发云上为外部系统提供跳转入口实现简单的单点登录跳转。其中研发云认证可基于外部系统的需求，提供界面集成、资产授权的更深入的对接和整合。本文的主要提供研发云认证的 OAuth 协议及系统集成、资产授权的相关技术说明。
+
+## 3 OAuth 鉴权服务
+
+OAuth 鉴权服务，名为 OAuthServer，是本平台中专门用于 OAuth 协议鉴权的服务。本章介绍 OAuth 服务的设计要点以及接口定义。本服务支持获取研发云代码仓库及项目制品库资产的访问令牌。
+
+### 3.1 协议流程
+
+2
+
+OAuthServer 连同相关的前端授权页面配合实现了整个平台中对 OAuth 鉴权的协议栈，其在整个平台中的角色以及和外部应用的关系如下图所示：
+
+OAuthServer 服务按照 RFC 6749 协议标准，实现了 OAuth2.0 的四种鉴权模式，分别为：授权码（authorization-code）、隐藏式（implicit）、密码式（password）、客户端凭证（client credentials）。在上述 4 种 OAuth2.0 的认证鉴权模式中，授权码（authorization-code）、隐藏式（implicit）这两种模式需要本平台提供前端页面配合实现。OAuthServer 服务通过 client_id 和 client_secret 字段值对申请 OAuth 认证的外部应用进行身份检查。
+
+### 3.2 Token 类型和生成
+
+按照 RFC6749 规范的规定，OAuthServer 支持 access token 和 id-token 两种token。Access token 是发送到外部应用的，用于访问资源服务的鉴权token，id-token对 部 分 用 户 进 行 JWT 加 密 后 的 用 户 信 息 内 容 。 OAuthServer 服 务 会 在/oauth/access_token 的接口处理中，同时生成 access token 和 id_token，并返回给3
+
+外部应用。对于 access token，根据 RFC6750，OAuthServer 服务支持 bearer 类型的 token。 OAuthServer 对 token 的生成采用 jwt 协议对令牌内容进行签名，从而得到生成的 token 字串。Access token 所签名的内容包括：
+
+OAuthServer 在 tokengenerator 文件的 GenerateToken 方法中实现 access token的生成，将上述表格的内容使用 client_id 对应的外部应用的 client_secret 对这些内容进行签名，从而得到 access token 字串。
+
+另外根据 RFC7519 进行jwt 安全加密。Access token 所签名的内容包括：
+
+### 3.3 接口定义
+
+#### 3.3.1 前端跳转地址
+
+1）Authorize 请求
+
+接口说明请求 AuthorizationCode 或者隐藏模式下请求 Token 4
+
+接口方法Get接口地址http://server:port/login/oauth/authorize消息体
+
+返回响应HTTP 状态码 : 301
+
+重定向访问5
+
+重定向地址：Authorize 请求中的 redirect_uri 地址HTTP 结构：
+
+2）参数示例
+
+重定向访问GET https://www.srdcloud.cn/login/oauth/authorize Parameters:response_type : "code",client_id: "2423402bb71a1t5k7hbwssd2", state："string",redirect_uri: "https://test.com/auth"scope: "projectId:12"
+
+重定向返回GET https://test.com/auth Parameters:code: "HgC4EfdqVC4ZiOPSjk", state: "string",
+
+#### 3.3.2 后端接口
+
+6
+
+##### 3.3.2.1 请求 Token
+
+1）接口说明
+
+请求生成 access token。本接口向外部应用以及本平台前端授权页面开放，用于向本平台获取 access token。
+
+这个接口是 OAuth2.0 的 4 种模式统一的接口，兼容 4 种模式的请求 access token 操作，根据每种模式的不同，所携带的请求参数也不同。
+
+接口方法Post接口地址http://server:port/api/usercenterbackend/login/oauth/access_token消息体
+
+7
+
+返回响应
+
+1）如无redirect_url，或者出现其他错误无法重定向，直接返回响应HTTP 状态码 : 200
+
+响应编码方式：application/x-www-form-urlencoded; charset=utf-8正常响应结构:
+
+id token 包含：8
+
+asset 结构：
+
+9
+
+错误响应结构：
+
+2）参数示例
+
+入参POST https://www.srdcloud.cn/api/usercenterbackend/login/oauth/access_token Request Body (application/json):
+
+{
+
+"grant_type": "authorization_code",
+
+"client_id": "2423402bb71a1t5k7hbwssd2",
+
+"client_secret": "220943643b24uUOYMYWhsWh012osSJI7lVavs8bqmDUQ4Az" , "code":"HgC4EfdqVC4ZiOPSjk"
+
+}
+
+返回示例POST https://www.srdcloud.cn/api/usercenterbackend/login/oauth/access_token Response Body (application/x-www-form-urlencoded):
+
+{
+
+"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbGllbnRfaWQiOiI yNDIzNDAyYmI3MWExdDVrN2hid3NzZDIiLCJleHAiOjE3MzQxNTMyODMsIm lzcyI6IjEwIiwic2NvcGUiOiJwcm9qZWN0SWQ6MTIiLCJ0b2tlblR5cGUiOiJiZWFy ZXIifQ.bEkdU4aqq_aabjSE9F0STJD2ytFwg8J2JJnhBA1PR9Q",
+
+"expires_in": "86400",
+
+10
+
+"id_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZF90b2tlbiI6eyJsb2dp biI6InRlc3RVc2VyIiwiZW1haWwiOiJ0ZXN0VXNlckBjaGluYXRlbGVjb20uY24iL CJhdXRoX3Rva2VuIjoiZGRiNzJkY2ItNDE5NC00ZmNhLTgyNDUtMGM5NGE0N ThhYzdiIiwiYXNzZXRzIjpbeyJhc3NldF9uYW1lIjoidGVzdDIwMjQwNjE3YS9iIiwi YXNzZXRfdHlwZSI6IkNvZGVSZXBvc2l0b3J5IiwiYXNzZXRfYXV0aCI6Ik1hbm FnZXIiLCJhc3NldF91cmwiOiJodHRwczovL3R1dzFAZGV2LWNvZGUuc3JkY2xv dWQuY24vYS90ZXN0MjAyNDA2MTdhL2IiLCJhc3NldF90b2tlbiI6ImppWUs5dHl kSTZZOFlGZkFpYVZ4RnlaYmRzTU9WTnUzOUxQVCtDNCtTWiIsImV4cGlyZX NfaW4iOiIxNzM0MDgyMDczIn0seyJhc3NldF9uYW1lIjoidGVzdDIwMjQwNjE3Y S9jIiwiYXNzZXRfdHlwZSI6IkNvZGVSZXBvc2l0b3J5IiwiYXNzZXRfYXV0aCI6I k1hbmFnZXIiLCJhc3NldF91cmwiOiJodHRwczovL3R1dzFAZGV2LWNvZGUuc3J kY2xvdWQuY24vYS90ZXN0MjAyNDA2MTdhL2MiLCJhc3NldF90b2tlbiI6Impp
+
+WUs5dHlkSTZZOFlGZkFpYVZ4RnlaYmRzTU9WTnUzOUxQVCtDNCtTWiIsImV 4cGlyZXNfaW4iOiIxNzM0MDgyMDczIn0seyJhc3NldF9uYW1lIjoidGVzdDIwMjQ wNjE3YS9hYSIsImFzc2V0X3R5cGUiOiJDb2RlUmVwb3NpdG9yeSIsImFzc2V0X2 F1dGgiOiJNYW5hZ2VyIiwiYXNzZXRfdXJsIjoiaHR0cHM6Ly90dXcxQGRldi1jb2 RlLnNyZGNsb3VkLmNuL2EvdGVzdDIwMjQwNjE3YS9hYSIsImFzc2V0X3Rva2 VuIjoiamlZSzl0eWRJNlk4WUZmQWlhVnhGeVpiZHNNT1ZOdTM5TFBUK0M0K 1NaIiwiZXhwaXJlc19pbiI6IjE3MzQwODIwNzMifSx7ImFzc2V0X25hbWUiOiJ0ZX N0MjAyNDA2MTdhLXJlbGVhc2UtY29jb2Fwb2RzLWxvY2FsIiwiYXNzZXRfdHl wZSI6IkxvY2FsQXJ0aWZhY3RSZXBvc2l0b3J5IiwiYXNzZXRfYXV0aCI6ImFkb WluIiwiYXNzZXRfdXJsIjoiaHR0cHM6Ly9kZXYtc3JkYXJ0LnNyZGNsb3VkLmN uL2NvY29hcG9kcy90ZXN0MjAyNDA2MTdhL3Rlc3QyMDI0MDYxN2EtcmVsZ WFzZS1jb2NvYXBvZHMtbG9jYWwiLCJhc3NldF90b2tlbiI6ImI4ODZmOTJhN2M 0ZWQyMTU2YTk0MWMzZTQ2NzFlYTYzIiwiZXhwaXJlc19pbiI6IjE3MzQwODI wNzMifSx7ImFzc2V0X25hbWUiOiJ0ZXN0MjAyNDA2MTdhLXNuYXBzaG90L WNvY29hcG9kcy1sb2NhbCIsImFzc2V0X3R5cGUiOiJMb2NhbEFydGlmYWN0U mVwb3NpdG9yeSIsImFzc2V0X2F1dGgiOiJhZG1pbiIsImFzc2V0X3VybCI6Imh0d HBzOi8vZGV2LXNyZGFydC5zcmRjbG91ZC5jbi9jb2NvYXBvZHMvdGVzdDIwM 11
+
+jQwNjE3YS90ZXN0MjAyNDA2MTdhLXNuYXBzaG90LWNvY29hcG9kcy1sb2N hbCIsImFzc2V0X3Rva2VuIjoiYjg4NmY5MmE3YzRlZDIxNTZhOTQxYzNlNDY3 MWVhNjMiLCJleHBpcmVzX2luIjoiMTczNDA4MjA3MyJ9XSwicHJvamVjdF9uY W1lIjoiYXBhYXNUZXN0UHJvamVjdCIsInByb2plY3Rfcm9sZSI6IjEifX0.RAbWb GiCA3PSjrjP36XYdS_u4Mh5gmN9Lmoj1-FZDig" ,
+
+"token_type":"bearer"
+
+}
+
+jwt 加密头域
+
+{
+
+"alg": "HS256",
+
+"typ": "JWT"
+
+}
+
+Id—token 解析内容
+
+{
+
+"id_token": {
+
+"login": "testUser",
+
+"email": "[邮箱已脱敏]",
+
+"auth_token": "ddb72dcb-4194-4fca-8245-0c94a458ac7b",
+
+"assets": [
+
+{
+
+"asset_name": "test20240617a/b",
+
+"asset_type": "CodeRepository",
+
+"asset_auth": "Manager",
+
+"asset_url": "https://[邮箱已脱敏]/a/test20240617a/b",
+
+"asset_token": "jiYK9tydI6Y8YFfAiaVxFyZbdsMOVNu39LPT+C4+SZ", "expires_in": "1734082073"
+
+},
+
+12
+
+{
+
+"asset_name": "test20240617a/c",
+
+"asset_type": "CodeRepository",
+
+"asset_auth": "Manager",
+
+"asset_url": "https://[邮箱已脱敏]/a/test20240617a/c",
+
+"asset_token": "jiYK9tydI6Y8YFfAiaVxFyZbdsMOVNu39LPT+C4+SZ", "expires_in": "1734082073"
+
+},
+
+{
+
+"asset_name": "test20240617a/aa",
+
+"asset_type": "CodeRepository",
+
+"asset_auth": "Manager",
+
+"asset_url": "https://[邮箱已脱敏]/a/test20240617a/aa",
+
+"asset_token": "jiYK9tydI6Y8YFfAiaVxFyZbdsMOVNu39LPT+C4+SZ", "expires_in": "1734082073"
+
+},
+
+{
+
+"asset_name": "test20240617a-release-cocoapods-local",
+
+"asset_type": "LocalArtifactRepository",
+
+"asset_auth": "admin",
+
+"asset_url": "https://dev-
+
+srdart.srdcloud.cn/cocoapods/test20240617a/test20240617a-release-cocoapods-local",
+
+"asset_token": "b886f92a7c4ed2156a941c3e4671ea63",
+
+"expires_in": "1734082073"
+
+},
+
+{
+
+"asset_name": "test20240617a-snapshot-cocoapods-local",
+
+"asset_type": "LocalArtifactRepository",
+
+"asset_auth": "admin",
+
+13
+
+"asset_url": "https://dev-
+
+srdart.srdcloud.cn/cocoapods/test20240617a/test20240617a-snapshot-cocoapods-local",
+
+"asset_token": "b886f92a7c4ed2156a941c3e4671ea63", "expires_in": "1734082073"
+
+}
+
+],
+
+"project_name": "apaasTestProject",
+
+"project_role": "1"
+
+}
+
+}
+
+##### 3.2.2.2 请求用户信息
+
+1）接口说明
+
+使用 access_token 获取用户信息接口方法GET接口地址http://server:port/api/usercenterbackend/user头部Authorization：bearer [access_token]返回响应HTTP 状态码: 200响应编码方式：application/json; charset=utf-8
+
+14
+
+错误响应结构：HTTP 状态码: 401响应编码方式：application/json; charset=utf-8
+
+2）参数示例
+
+GET https://www.srdcloud.cn/api/usercenterbackend/user Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbGllbnRfaWQi OiIyNDIzNDAyYmI3MWExdDVrN2hid3NzZDIiLCJleHAiOjE3MzQxNTQwNzMs ImlzcyI6IjEwIiwic2NvcGUiOiJwcm9qZWN0SWQ6MTIiLCJ0b2tlblR5cGUiOiJiZW FyZ5XIifQ.MryoXA18ov_gAGv8plY7BMQCm52bGDvyIVoShk1m7984123 Content-Type: application/json
+
+返回POST https://www.srdcloud.cn/api/usercenterbackend/user Response Body (application/json):
+
+{
+
+"id":10,
+
+"login":"testUser",
+
+"user_key":"",
+
+15
+
+"company":"中国电信集团",
+
+"email":"[邮箱已脱敏]", "mobile":"[手机号已脱敏]",
+
+"created_at":"2024-02-29 14:46:35", "updated_at":"2024-11-28 09:22:44" }
+
+## 4 系统集成方式
+
+在单点登录的基础上，提供 2 种集成方式：系统跳转和界面集成
+
+### 4.1 系统跳转
+
+用户登录研发云后，点击外部系统入口跳转进入相应系统。对接单点认证后，与研发云门户产品经理确认系统跳转菜单位置，经过领导确认后排期上线。
+
+### 4.2 界面集成
+
+在研发云系统内嵌入外部系统功能页面，用户登录研发云后，在研发云的同一界面下完成相应的功能流程，无跳转体验。
+
+页面集成通过 iframe 嵌入的方式集成，研发云与外部系统共同完成集成产品设置，包括菜单设置等。产品确认后研发云门户前端配置应用子系统嵌入外部系统链接。
+
+页面集成对于外部系统的要求如下：■ 由外部系统提供对应的前台菜单集合和链接
+
+16
+
+■ 由外部平台提出打开对应菜单链接的其他要求，例如替换链接中的某些参数、新增某些参数/标识等■ 外部平台和研发云页面之间的通信要求，统一使用 postMessage 进行页面之间的通信。
+
+具体格式如下window.postMessage({valueType: "xxx", // 双方约定事件名称data: {}, // 具体参数
+
+}, "*");
+
+## 5 用户访问对接系统资源
+
+用户使用对接系统资源，根据对接系统分配资源的方式，分为 2 种：● 按用户：按用户维度访问对接系统资源。用户登录后即可使用对接系统分配给用户的资源；● 按项目：对接系统按项目分配资源。这种情况下，需要增加额外的步骤使用对接系统资源：■ 同步研发云项目到对接系统。需要具备相应管理权限的用户在研发云平台将研发云平台项目同步到对接系统（在对接系统新建或映射）■ 同步用户授权到对接系统。需要具备相应管理权限的用户在研发云平台将研发云用户授权信息同步到对接系统
+
+以上需要对接系统提供同步项目及授权用户的接口，同时研发云需要进行项目和授权用户同步功能的开发。
+
+### 5.1 对接系统访问研发云资源
+
+17
+
+在用户使用对接系统功能时，可能需要将对接系统的产出，例如代码、制品等资产同步到研发云系统，主要涉研发云以下的资源：● 代码库● 制品库● 组件广场
+
+1）手工配置资源访问权限
+
+用户在对接系统上手工配置资源的访问权限，例如用户名和密码等。
+
+这种方式存在以下问题：
+
+● 体验不佳，用户需要手工配置资源地址、密码等；密码变更时，需要在所有相关系统上修改；● 安全性不佳，资源地址和密码是静态配置，在用户登出系统后该配置仍然长期有效；● 如果采用 API 方式访问资源，存在访问范围过大的问题，外部系统可通过 API 获取用户所有的资源信息
+
+2）使用 OAuth 授权方式访问资源
+
+利用在用户认证授权过程中获取的 Token 访问研发云资源。
+
+研发云在生成 access/id token 的时候，将对资源访问的动态密码放到 ID token （JWT）的 payload 里。对接系统接收到 token 后，解析出token 中的动态密码。后续使用动态密码访问资源系统。具体过程如下：
+
+18
+
+● 用户授权后，用户中心根据授权情况去各个资源中心获取动态密码；各资源中心提供获取动态密码的接口；● 用户中心将获取的动态密码编码到 ID Token（JWT 格式）的 payload 中，并返回给对接系统；● 对接系统对 ID Token 进行解析，取出动态密码，用于后续访问研发云资源；资源中心负责对其颁发的动态密码的访问权限及生命周期的管理。动态密码的初始有效期由各资源中心确定，同时，各个资源中心按自身的产品规划，可提供延长、终止 token 有效期等功能。
+
+以上协议详细流程见本文 “3 OAuth 鉴权服务“。
+
+### 5.2 研发云资源授权的粒度
+
+1）代码中心：按照代码仓库的权限，不再细分到分支一级
+
+2）制品中心：按照用户权限，不再细分
+
+19

.agents/skills/telecom-rd-standards/references/source-documents/23-rd-cloud-openapi.md

@@ -0,0 +1,707 @@
+# 研发云互联互通规范能力开放技术规范（OpenAPI 接口）（试行稿）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+研发云互联互通规范
+
+能力开放技术规范（OpenAPI 接口）
+
+中国电信股份有限公司研究院研发云平台运营中心
+
+## 2025 年 5 月
+
+1
+
+2
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+5
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+本规范服务对象为中国电信集团及下属各级单位
+
+### 1.2 适用范围
+
+中国电信集团范围内，其中 3.15 章节介绍的组件广场的内容仅对原子能力平台开放；3.17 章节介绍的制品中心、3.18 章节介绍的资源中心和 3.19 章节介绍的部署中心(Ⅱ) 的内容仅对 aPaaS 开放
+
+### 1.3 起草单位
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.4 解释权
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.5 版权
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.6 名词解释
+
+1
+
+## 2 概述
+
+在调用研发云能力开放接口时，根据不同接口，存在两种不同的认证鉴权方式：
+
+1）平台级别的认证鉴权。使用预先申请的“外部用户账号”作为接口鉴权实体。
+
+2）用户级别的认证鉴权。使用当前登录用户的授权信息去访问相关资源。
+
+其中用户管理、安全中心、版本中心、部署中心（部分，即 3.4 中展示的接口）、测试中心、代码库、流水线、敏捷管理、文档空间、问需管理、我的工作、 Wiki、自研工作项、数据中台、组件广场、Codefree 采用平台级别的认证鉴权机制。制品中心、资源中心、部署中心（部分，即 3.19 中展示的接口）采用用户级别的认证鉴权机制。
+
+### 2.1 平台级别的认证鉴权
+
+研发云应用能力开放使用者，一般基于其自身的第三方平台的使用需要，向研发云申请外部用户账号。第三方平台应该根据其自身用户的服务范围确定所需要使用的研发云外部用户账号。由于外部用户账号是跟机构关联，因此，如果第三方平台自身的业务也是跟组织机构相关的话，应该为其服务的不同机构申请不同的外部用户账号。这就是说，第三方平台应该具备多个外部用户账号的管理能力，并且根据每个对话所服务的对象不同而选择正确的外部用户账号作为接口调用的鉴权参数。研发云应用能力调用的 host 地址为：https://www.srdcloud.cn
+
+#### 2.1.1 账号与鉴权
+
+能力开放专区首页、详情页申请使用能力入口，选择应用能力，用户可以填写应用能力使用申请单。申请提交后，研发云管理员将发起账号需求进一步沟通并对申请进行审批。审批通过后，研发云管理员将在后台开通好外部用户账号并通过邮件通知申请人。2
+
+#### 2.1.2 外部用户账号项目权限
+
+有部分应用能力接口，如项目/用户管理、文档搜索等接口，是以项目为单位进行授权的。每个外部用户账号都是挂靠到一个组织机构下的，对于所属的组织结构以及子机构下的项目访问权，有两种类型:● 按机构默认授权：外部用户账号拥有所属机构及子机构下所有项目的访问权，包括已有和新增项目；● 按项目单独授权：外部用户账号需要被授权了的（账号所属机构下的）项目才有访问权；由于对项目的操作需要企业管理员权限，因此外部用户账号需要关联一个企业管理员账号，所管理的企业管理员账号为匿名账号，在账号开通申请时提供。外部用户账号属于上述哪种类型，需要该账号的使用客户单位和研发云联系人线下沟通，由系统管理员在后台设定。
+
+#### 2.1.3 外部用户账号资产权限
+
+在一些应用的开放能力中，涉及到需要对项目中的资产进行操作，在这种场景下，需要对外部用户账号进行项目资产管理授权。外部用户账号对一个项目资产的访问权限，是通过其关联的实名账号约束的，且要求与外部用户账号管理具有目标项目的项目管理员角色。举个例子，如果一个第三方平台需要针对项目 A 调用流水线创建接口，流水线是项目资产，因此该第三方平台调用流水线创建接口所使用的外部用户账号，所绑定的实名账号，必须得是项目 A 的项目管理员。调用接口创建的流水线，创建者显示的为外部用户账号关联的实名账号。
+
+#### 2.1.4 外部用户账号鉴权
+
+第三方平台在调用研发云应用能力接口时，需要携带外部用户账号鉴权信息，鉴权信息的格式如下：3
+
+上 表 中 ， authorization 字 段 是 对 {srdcloud-user-account },{time- stamp},{secret}字串进行 SHA256 加密后，再进行 Base64 处理后得到的字串。注意 srdcloud-user-account、time-stamp 和 secret 三个字段值之间需要采用“, ”号隔开。srdcloud-user-account, secret 值由研发云分配提供，每个外部账号都有其专用的 secret 值。time-stamp 值由第三方进行设置。
+
+#### 2.1.5 第三方平台使用原则
+
+研发云应用能力开放使用者，一般基于其自身的第三方平台的使用需要，向研发云申请外部用户账号。第三方平台应该根据其自身用户的服务范围确定所需要使用的研发云外部用户账号。由于外部用户账号是跟机构关联，因此，如果第三方平台自身的业务也是跟组织机构相关的话，应该为其服务的不同机构申请不同的外部用户账号。这就是说，第三方平台应该具备多个外部用户账号的管理能力，并且根据每个对话所服务的对象不同而选择正确的外部用户账号作为接口调用的鉴权参数。
+
+### 2.2 用户级别的认证鉴权
+
+在用户和研发云 oauth 单点登录过程中，由用户中心统一生成 auth_token并通过 id_token 返回给外部应用。调用接口时，在 header 中添加 auth_token作为鉴权参数。具体流程参考研发云互联互通规范-系统接入技术规范（用户认证和资产授权）。
+
+## 3 能力开放目录
+
+本章节将根据各 OpenAPI 归属的产品模块详述已开放的清单目录
+
+4
+
+### 3.1 用户管理
+
+#### 3.1.1 接口清单
+
+#### 3.1.2 接口文档
+
+### 3.2 安全中心
+
+#### 3.2.1 接口清单
+
+5
+
+#### 3.2.2 接口文档
+
+### 3.3 版本中心
+
+#### 3.3.1 接口清单
+
+#### 3.3.2 接口文档
+
+在线地址：版本中心能力开放接口说明
+
+### 3.4 部署中心( Ⅰ )
+
+#### 3.4.1 接口清单
+
+6
+
+#### 3.4.2 接口文档
+
+### 3.5 测试中心
+
+#### 3.5.1 接口清单
+
+7
+
+#### 3.5.2 接口文档
+
+测试中心能力开放接口文档（v1.3.0）最新文档信息见研发云能力开放专区
+
+### 3.6 代码库
+
+8
+
+#### 3.6.1 接口清单
+
+#### 3.6.2 接口文档
+
+### 3.7 流水线
+
+#### 3.7.1 接口清单
+
+#### 3.7.2 接口文档
+
+9
+
+### 3.8 敏捷管理
+
+#### 3.8.1 接口清单
+
+#### 3.8.2 接口文档
+
+在线地址：敏捷管理（旧版工作项）能力开放接口说明
+
+### 3.9 文档空间
+
+#### 3.9.1 接口清单
+
+10
+
+#### 3.9.2 接口文档
+
+### 3.10 问需管理
+
+#### 3.10.1 接口清单
+
+11
+
+#### 3.10.2 接口文档
+
+参见“能力开放专区-问需管理“https://www.srdcloud.cn/capopenzone/ability/detail/30/- 1/b3c8edc3cf908763e198f037febda126?projectVersionId=650
+
+### 3.11 我的工作
+
+#### 3.11.1 接口清单
+
+#### 3.11.2 接口文档
+
+在线地址：我的工作能力开放接口说明12
+
+### 3.12 Wiki
+
+#### 3.12.1 接口清单
+
+#### 3.12.2 接口文档
+
+### 3.13 自研工作项
+
+#### 3.11.1 接口清单
+
+13
+
+#### 3.11.2 接口文档
+
+在线地址：自研工作项能力开放接口说明
+
+### 3.14 数据中台
+
+#### 3.14.1 接口清单
+
+#### 3.14.2 接口文档
+
+### 3.15 组件广场
+
+#### 3.15.1 接口清单
+
+14
+
+#### 3.15.2 接口文档
+
+### 3.16 codefree
+
+#### 3.16.1 接口清单
+
+#### 3.16.2 接口文档
+
+https://www.srdcloud.cn/helpcenter/content?id=1295409758673600512
+
+15
+
+### 3.17 制品中心
+
+#### 3.17.1 接口清单
+
+#### 3.17.2 接口文档
+
+（1）查询项目制品库列表
+
+接口说明查询项目中当前用户有权限的制品库列表
+
+是否支持项目外多项目授权：否接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactRepo/v1/artifactRep
+
+os消息头域auth-token:****** // 参考 1.用户中心鉴权功能消息体
+
+16
+
+返回响应
+
+17
+
+ArtifactRepoVO 结构说明：
+
+18
+
+（2） 获取制品列表（镜像树）
+
+接口说明查询指定制品库和路径下包含的镜像树。
+
+是否支持项目外多项目授权：是接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/image/ names/tree消息头域auth-token:****** // 参考 1.用户中心鉴权功能19
+
+消息体
+
+返回响应
+
+ImageNamesTreeVO 结构说明：
+
+ImageNameNodeVO 结构说明：
+
+20
+
+（3）查制品库包含的镜像目录
+
+接口说明列举当前 Docker 制品库包含的镜像目录以及当前制品库要同步的远程库。
+
+是否支持项目外多项目授权：是接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/docker/ catalog消息头域auth-token:****** // 参考 1.用户中心鉴权功能消息体返回响应
+
+21
+
+DockerImagesVO 结构说明：
+
+SynchronizeRepoKeyRegistryVO 结构说明
+
+22
+
+（4）查询部署制品
+
+接口说明查询部署制品，用于查询 docker、generic 和 helm 类型的制品，返回结果是一个列表，支持拼成一颗树形。是否支持项目外多项目授权：否接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/search/ deploy/artifacts消息头域auth-token:****** // 参考 1.用户中心鉴权功能
+
+消息体
+
+23
+
+返回响应
+
+DeployArtifactVO 结构说明：
+
+（5）获取制品下载地址
+
+接口说明获取制品的下载链接。
+
+是否支持项目外多项目授权：是接口方法24
+
+GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/artifact
+
+Url/{repoKey}消息头域auth-token:****** // 参考 1.用户中心鉴权功能
+
+消息体
+
+返回响应
+
+UrlDTO 结构说明：
+
+25
+
+（6） 列举镜像目录包含的所有镜像 tag
+
+接口说明列举镜像目录包含的所有镜像 tag
+
+是否支持项目外多项目授权：是接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/docker/ tags/list消息头域auth-token:****** // 参考 1.用户中心鉴权功能
+
+消息体
+
+26
+
+返回响应
+
+DockerImagesTagsVO 结构说明：
+
+DockerImagesTagVO 结构说明：
+
+27
+
+（7） 获取镜像同步状态
+
+接口说明获取镜像同步状态
+
+是否支持项目外多项目授权：是接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/batch/v1/synchronize/statu
+
+s消息头域auth-token:****** // 参考 1.用户中心鉴权功能
+
+消息体
+
+28
+
+返回响应
+
+SynchronizeStatusVO 结构说明：
+
+（8） 设置元数据
+
+接口说明设置制品的元数据
+
+是否支持项目外多项目授权：是接口方法PUT
+
+29
+
+接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/properti
+
+es消息头域auth-token:****** // 参考 1.用户中心鉴权功能消息体
+
+30
+
+31
+
+返回响应
+
+（9） 获取制品目录
+
+接口说明获取制品目录
+
+是否支持项目外多项目授权：是接口方法GET接口地址https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/fileList/{
+
+repoKey}消息头域32
+
+auth-token:****** // 参考 1.用户中心鉴权功能消息体
+
+返回响应
+
+FileListDTO
+
+33
+
+ArtifactFileDTO
+
+（10） 获取制品的 artifactUri（中台提供的 uri）
+
+接口说明获取制品的 artifactUri
+
+是否支持项目外多项目授权：是接口方法GET接口地址
+
+34
+
+https://test.srdcloud.cn/api/artifactbackend/outer/artifactmanager/v1/artifact
+
+Uri消息头域auth-token:****** // 参考 1.用户中心鉴权功能消息体
+
+返回响应
+
+35
+
+ArtifactUriVO
+
+### 3.18 资源中心
+
+#### 3.18.1 接口清单
+
+#### 3.18.2 接口文档
+
+（1）查询有权限的 CCSE 集群
+
+接口说明查询对应用户在项目中有管理权限的 CCSE 集群接口方法GET 36
+
+接口地址https://test.srdcloud.cn/api/resourcebackend/project-res-ext/v1/list-ccse消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+返回响应
+
+Entity 结构说明
+
+37
+
+（2）查询 CCSE 集群下有权限的命名空间
+
+接口说明查询对应用户在项目中有管理权限的命名空间接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/project-res-ext/v1/list-
+
+namespace消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+返回响应
+
+38
+
+Namespace 结构说明：
+
+（3）查询 CCSE 集群下有权限的主机标签
+
+接口说明查询对应用户在项目中有管理权限的主机标签接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/project-res-ext/v1/list-label消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+39
+
+返回响应
+
+Label 结构说明：
+
+（4）查询 CCSE 集群下有权限的镜像仓库
+
+接口说明查询对应用户在项目中有管理权限的镜像仓库
+
+40
+
+接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/project-res-ext/v1/list-harbor消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+返回响应
+
+Habor 结构说明：
+
+41
+
+（5）查询命名空间下的 PVC 列表
+
+接口说明查询命名空间下的 pvc 列表接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/namespace-ext/v1/list-pvc消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+返回响应
+
+42
+
+PVC 结构说明：
+
+（6）查询命名空间下的 Secret 列表
+
+接口说明查询命名空间下的 Secret 列表接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/namespace-ext/v1/list-secret消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体
+
+返回响应
+
+43
+
+Secret 结构说明：
+
+（7）查询命名空间下的 ConfigMap 列表
+
+接口说明查询命名空间下的 ConfigMap 列表接口方法GET接口地址https://test.srdcloud.cn/api/resourcebackend/namespace-ext/v1/list- configmap消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体44
+
+返回响应
+
+ConfigMap 结构说明：
+
+### 3.19 部署中心（ 聂）
+
+#### 3.19.1 接口清单
+
+45
+
+#### 3.19.2 接口文档
+
+（1）新增 CCSE 集群 yaml 步骤类型的部署任务
+
+接口说明项目用户增加集群类型为 CCSE，任务步骤为 YAML 类型的部署任务接口方法POST接口地址https://test.srdcoud.cn/api/dcbackend/srdtask/v1/ext/deploytasks消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体Node 结构说明：
+
+46
+
+DeployObject 结构说明:
+
+YamlFile 结构说明:
+
+返回响应
+
+请求示例
+
+**请求头 header**
+
+auth-token：********
+
+47
+
+**请求体**
+
+```json
+
+{
+
+"name": "ccseyamltask",
+
+"displayName": "ccse-yaml-任务",
+
+"nodes": [
+
+{
+
+"nodeName": "步骤 1",
+
+"serviceNodeId": "1",
+
+"nsId": "2",
+
+"deployObjects": [
+
+{
+
+"deployObjectName": "deployment1",
+
+"files": [
+
+{
+
+"fileName": "deploy.yaml",
+
+"yamlContent": "apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: nginx-deployment\n labels:\n app: nginx\nspec:\n replicas: 3\n
+
+selector:\n matchLabels:\n app: nginx\n template:\n metadata:\n labels:\n app: nginx\n spec:\n containers:\n - name: nginx\n image: nginx:1.21.6\n ports:\n - containerPort: 80"48
+
+}
+
+]
+
+}
+
+]
+
+}
+
+]
+
+}
+
+```
+
+响应示例
+
+```json
+
+{
+
+"optResult": 0,
+
+"msg": "",
+
+"id": 1
+
+}
+
+```
+
+（2）修改 CCSE 集群 yaml 步骤类型的部署任务
+
+接口说明项目用户修改集群类型为 CCSE，任务步骤为 YAML 类型的部署任务接口方法PUT接口地址
+
+49
+
+https://test.srdcoud.cn/api/dcbackend/srdtask/v1/ext/deploytasks/{id}消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体返回响应
+
+请求示例**路径参数** "id": 1
+
+**请求头 header**auth-token：********
+
+**请求体**
+
+```json
+
+{
+
+"name": "ccseyamltask",
+
+50
+
+"displayName": "ccse-yaml-任务",
+
+"nodes": [
+
+{
+
+"nodeName": "步骤 1",
+
+"serviceNodeId": "1",
+
+"nsId": "2",
+
+"deployObjects": [
+
+{
+
+"deployObjectName": "deployment1",
+
+"files": [
+
+{
+
+"fileName": "deploy.yaml",
+
+"yamlContent": "apiVersion: apps/v1\nkind:
+
+Deployment\nmetadata:\n name: nginx-deployment\n labels:\n app:nginx\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx\n template:\n metadata:\n labels:\n app: nginx\n spec:\n containers:\n - name: nginx\n image: nginx:1.21.6\n ports:\n
+
+- containerPort: 80"
+
+}
+
+]
+
+}
+
+]
+
+}
+
+]
+
+}
+
+丶丶丶响应示例
+
+```json
+
+{
+
+"optResult": 0,
+
+"msg": "",
+
+}
+
+```
+
+51
+
+（3）获取 harbor 授权的 imagePullSecret
+
+接口说明资源管理员获取 harbor 授权的 imagePullSecret接口方法GET接口地址https://test.srdcoud.cn/api/dcbackend/srdres/v1/ext/cluster/{clusterId}/names pace/{namespaceId}/harbor/{harborId}/imagePullSecret消息头域auth-token：****** //通过 oauth 获得的用户鉴权 token消息体返回响应
+
+请求示例
+
+**路径参数**52
+
+"harborId": "1"
+
+"clusterId": "1"
+
+"namespaceId": "1"
+
+**请求头 header**
+
+auth-token：********
+
+响应示例```json
+
+{
+
+"optResult": 0,
+
+"msg": "",
+
+"imagePullSecret": "*************" }
+
+```
+
+### 3.20 消息中心
+
+#### 3.20.1 接口清单
+
+53
+
+#### 3.20.2 消息格式
+
+研发云消息格式规范遵循 CloudEvents 标准，并在此基础上，对特定字段进行了约束。以下为 CloudEvent 的 JSON 数据格式说明：
+
+data 字段包含业务数据，具有以下规定的子字段：
+
+54
+
+#### 3.20.3 接口文档
+
+#### 3.20.4 对接流程
+
+1. 接入方：确认是否有研发云“外部账号 ”，若无，请申请。外部账号需绑定“外部通用数据接入 ” 角色 。2. 接入方：由单位接口人在研发云“问需管理 ”提交数据接入需求。申请说明需提供：“组织名 ”（如 xx 组织简称）、“接入中心 ”（如部署中心），“类型 ”（如 event）以及外部账号{account}信息。3. 研发云“消息中心 ”分配消息类型(eventType)：格式为：external_ {类型}. {组织}. {应用}。其中，类型有 2 种：event 为事件同步，db 为数据库同步。
+
+55

.agents/skills/telecom-rd-standards/references/source-documents/24-rd-cloud-scaffold-service.md

@@ -0,0 +1,507 @@
+# 研发云互联互通规范服务接入技术规范（脚手架服务）（试行稿）
+
+> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
+
+研发云互联互通规范
+
+服务接入技术规范（脚手架服务）
+
+中国电信股份有限公司研究院研发云平台运营中心
+
+## 2025 年 5 月
+
+1
+
+> 编制人员信息已移除。
+
+版本变更历史
+
+3
+
+## 1 文档说明
+
+### 1.1 编制说明
+
+本规范服务对象为中国电信集团及下属各级单位
+
+### 1.2 适用范围
+
+中国电信集团范围内
+
+### 1.3 起草单位
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.4 解释权
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.5 版权
+
+中国电信股份有限公司研究院-研发云平台运营中心
+
+### 1.6 名词解释
+
+1
+
+## 2 概述
+
+合作单位通过标准化方式将自己单位开发的服务快速接入研发云平台，拓展研发云平台功能，以满足更多业务场景。目前支持的主要内容是脚手架服务接入。研发云代码中心支持从模板创建代码仓库，即调用脚手架服务快速灵活的生成各类搭配的项目初始化代码库。
+
+## 3 脚手架接入
+
+### 3.1 集成开发规范
+
+脚手架工具开发需符合研发云数据结构规范、签名认证规范，如有不满足，双方协商修改。
+
+#### 3.1.1 数据结构规范
+
+● 数据流向：脚手架服务-->研发云● 数据结构说明：由脚手架服务向研发云平台提供脚手架服务可对接使用的模板信息、组件信息等。
+
+Scaffold 数据结构定义：
+
+2
+
+3
+
+Component 数据结构定义：
+
+● 示例：4
+
+{
+
+"scaffolds": [
+
+{
+
+"templateId": "9340db83-5186-4d5b-aa98-bb0d8f99274b", "templateName": "基础 Web 应用",
+
+"version": "1.0.0",
+
+"description": "这是一个基础的 Web 应用脚手架",
+
+"language": "Java",
+
+"buildType": "Maven",
+
+"components": [
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "MySQL 数据库连接",
+
+"description": "用于连接 MySQL 数据库的组件",
+
+"type": "database",
+
+"version": "1.0"
+
+},
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "JWT 认证",
+
+"description": "基于 JWT 的认证安全组件",
+
+"type": "security",
+
+5
+
+"version": "1.0"
+
+}
+
+]
+
+},
+
+{
+
+"templateId": "9340db83-5186-4d5b-aa98-bb0d8f99274b", "templateName": "Vue 单页应用",
+
+"version": "2.0.0",
+
+"description": "一个基于 Vue 的单页应用模板", "language": "JavaScript",
+
+"buildType": "Vite",
+
+"components": [
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "Vue Router",
+
+"description": "Vue 路由管理组件",
+
+"type": "web",
+
+"version": "2.0"
+
+},
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "日志处理",
+
+6
+
+"description": "用于处理前端日志的组件",
+
+"type": "log",
+
+"version": "1.0"
+
+}
+
+]
+
+}
+
+],
+
+"organization": "中国电信"
+
+}
+
+● 数据流向：研发云-->脚手架服务● 数据结构说明：由研发云调用脚手架服务生成模板代码，请求参数包含模板信息、组件信息等。● 数据结构定义：
+
+7
+
+8
+
+Component 数据结构定义：
+
+● 示例：
+
+{
+
+"templateId": "9340db83-5186-4d5b-aa98-bb0d8f99274b", "templateName": "微服务基础模板",
+
+"version": "1.0.0", "language": "Java",
+
+"buildType": "Maven",
+
+"architecture": "DDD",
+
+"projectName": "my-service",
+
+9
+
+"groupId": "com.example", "artifactId": "my-service",
+
+"components": [
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "数据库访问组件",
+
+"version": "1.0.0"
+
+},
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "身份验证组件",
+
+"version": "1.0.0"
+
+}
+
+]
+
+}
+
+#### 3.1.2 接口定义
+
+POST 类型接口 header 信息
+
+10
+
+##### 3.1.2.1 模板分页查询
+
+POST api/v1/template/page请求参数
+
+{
+
+"pageSize":0,
+
+"pageIndex":0,
+
+"templateName":"统一技术底座", "language":"Java",
+
+11
+
+"buildType":"Maven",
+
+"organization":"中国电信" }
+
+响应
+
+{
+
+"success": true,
+
+"errCode": "",
+
+12
+
+"errMessage": "", "totalCount": 0,
+
+"pageSize": 0,
+
+"pageIndex": 0,
+
+"data": [{
+
+"templateId": "9340db83-5186-4d5b-aa98-bb0d8f99274b", "templateName": "基础 Web 应用",
+
+"version": "1.0.0",
+
+"description": "这是一个基础的 Web 应用脚手架", "language": "Java",
+
+"buildType": "Maven",
+
+"organizaion": "",
+
+"orgDisplayName": ""
+
+},
+
+{
+
+"templateId": "8a889814-b727-4c62-bdea-c40b4cbe611a", "templateName": "Vue 单页应用",
+
+"version": "2.0.0",
+
+"description": "一个基于 Vue 的单页应用模板", "language": "JavaScript",
+
+"buildType": "Vite",
+
+13
+
+"organizaion": "",
+
+"orgDisplayName": ""
+
+}],
+
+"totalPages": 0 }
+
+##### 3.1.2.2 组件分页查询
+
+POST api/v1/component/page请求参数
+
+{
+
+"pageSize":0,
+
+14
+
+"pageIndex":0,
+
+"templateId":"34242343",
+
+"componentName":"数据库连接", "type":"database"
+
+}
+
+响应
+
+{
+
+"success": true,
+
+15
+
+"errCode": "",
+
+"errMessage": "",
+
+"totalCount": 0,
+
+"pageSize": 0,
+
+"pageIndex": 0,
+
+"data": [{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "MySQL 数据库连接",
+
+"description": "用于连接 MySQL 数据库的组件",
+
+"type": "database",
+
+"version": "1.0"
+
+},
+
+{
+
+"componentId": "e543562b-b59c-4d32-b86c-183113c56159", "componentName": "JWT 认证",
+
+"description": "基于 JWT 的认证安全组件",
+
+"type": "security",
+
+"version": "1.0"
+
+}],
+
+"totalPages": 0
+
+}
+
+16
+
+##### 3.1.2.3 代码生成
+
+POST api/v1/code/generate请求参数示例
+
+{
+
+"bizId": "dsdsd"
+
+17
+
+"templateId": "12354",
+
+"projectName": "demo-project", "groupId": "com.demo",
+
+"artifactId": "demo", "components": [
+
+"db-01",
+
+"sec-01"
+
+]
+
+}响应
+
+{
+
+"success": true,
+
+"errCode": null,
+
+"errMessage": null,
+
+18
+
+"data": {
+
+"taskId": "3sdeeqw3" }
+
+}
+
+##### 3.1.2.4 代码包生成状态查询
+
+GET api/v1/code/generate/{taskId}/states请求参数响应
+
+19
+
+{
+
+"success": true,
+
+"errCode": null,
+
+"errMessage": null, "data": {
+
+"taskStates":"pending" }
+
+}
+
+##### 3.1.2.5 代码下载
+
+GET api/v1/code/download/{taskId}请求参数响应文件流
+
+20
+
+##### 3.1.2.6 代码包生成状态回调
+
+POST api/codebackend/codeoutward/code-gen/v1/status/callback鉴权：使用统一的签名认证规范请求参数
+
+响应
+
+21
+
+22
+
+#### 3.1.3 签名认证规范
+
+##### 3.1.3.1 签名验证流程
+
+使用 API 参数签名算法，在跨系统接口调用时防参数篡改、防重放攻击。
+
+a) 由脚手架服务中间层提供 secretkey；
+
+b) 以 md5( nonce={随机字符串}&timestamp={13 位时间
+
+戳}&key={secretkey 秘钥,由脚手架服务颁发} ) 生成签名 sign。
+
+c) 将 sign 作为参数，拼接到请求地址后面，如： http://ip:port?nonce={随机字符串}&timestamp={系统当前时间戳}&sign={根据加密规则加密后的签名信 息}
+
+23
+
+d) 服务端接收到请求后，以同样的算法生成一次 sign。
+
+e) 后端接收到请求后，先对比 timestamp 是否超期，再判断 nonce 是否已经使用过，然后再将参数中的 sign 跟接收到的参数重新生成的 sign 对比是否一致，如果一致则签名认证则通过，否则拒绝。
+
+##### 3.1.3.2 签名工具类
+
+SignUtil.java
+
+##### 3.1.3.3 签名认证 key
+
+由脚手架服务提供
+
+3.1.4.脚手架服务发布地址
+
+研发云对接脚手架生成服务 API 均发布在 zion-initializer-manage 服务中，对接地址如下：#集群内部地址
+
+http://zion-initializer-manage:80/api/v1/*
+
+#外部地址
+
+http://10.200.1.168:31902/api/v1/*
+
+### 3.2 服务部署规范
+
+● 脚手架工具需基于研发云提供的基础设施&环境进行部署
+
+24
+
+■ 脚手架工具应支持 K8S 部署方式，研发云将为每个脚手架服务分配一个独立命名空间■ 脚手架工具应且仅应使用规定范围内的基础组件，包括 postgres、 redis、minio、kafka，《Redis 客户端接入手册（ACL)》■ 脚手架工具服务通过 K8S NodePort 方式暴露服务给研发云平台代码中心调用，NodePort 端口由研发云平台指定● 脚手架服务提供方需提供部署/升级所需数据库脚本■ 由脚手架服务方提供测试/生产环境数据库表初始化 ddl/迭代升级脚本■ 由研发云运维人员配合进行数据库初始化、数据订阅仓库初始化、产品升级等操作。● 服务部署应满足平台监控、日志接入管理要求● 服务部署应支持 ARM 硬件（后续信创要求）● 部署基本架构如下图所示：
+
+25
+
+### 3.3 订阅使用数据
+
+研发云通过能力开放专区-数据能力，提供数据订阅明细表，接入方可订阅获取自己单位脚手架的使用数据。数据订阅参考《3 研发云互联互通规范-数据开放和接入技术规范》
+
+## 4 脚手架维护
+
+26
+
+服务接入研发云后，需遵守研发云的管理规范要求，并在指定项目中协作并维护该服务。
+
+### 4.1 申请协作项目
+
+接入方提供项目标识、开发人员研发云账号、邮箱、SDP 账号，由研发云创建协作项目。
+
+### 4.2 申请测试账号
+
+接入方提供开发、测试人员姓名、手机号、邮箱，由研发云开通研发云测试环境和 SDP 账号。
+
+### 4.3 申请生产发版
+
+● 由接入方创建版本，并关联工作项，发版前需确认版本关联信息完整（工作项、代码、制品、安全）● 由接入方提交给研发云领导申请发版研发云生产环境，发版评审示例：
+
+27
+
+> 评审与传阅人员信息已移除。
+
+> 评审与传阅人员信息已移除。
+
+28

.agents/skills/telecom-rd-standards/references/standards-map.md

@@ -0,0 +1,35 @@
+# 规范原文索引
+
+在 `references/source-documents/` 中读取对应文件。该目录是对原始 DOCX 的脱敏 Markdown 整理版：文件名稳定、正文保留技术条款和章节，但已删除编制人员、联系人及联系方式。条款争议、版式、表格或模板以工作区 `规范文档/` 中对应的原始 DOCX 为准。
+
+## 适用范围与基线
+
+- `00-issue-notice.md`：关于印发中国电信软件研发规范（修订版）的通知；用于理解修订范围和实施背景，不单独作为控制结论依据。
+- `01-capability-classification.md`：分级分类实施指导意见；用于项目分类及 C0-C4 适用性。C4 适用于研发链/战略/核心重大项目，C3 适用于国家/核心重点研究，C2 适用于专业能力/省级重点，C1 适用于创新探索和未分级项目。
+- `02-rd-standards-revision-overview.md`：修订介绍；仅用于理解规范演进，不能替代现行分册。
+- `03-overall-rd-standard.md`：总体规范；涵盖原则、角色、交付物、生命周期、评审和模板。
+- `04-requirements-management.md`：需求管理分册；涵盖调研、文档、评审、验收、变更和追踪。编号格式为 `[系统标识]_（模块标识）_[编号](_二级编号)`。
+
+## 工程与交付
+
+- `05-database-design.md`：数据库设计分册；涵盖命名、SQL、数据模型及 PostgreSQL、MySQL、HTAP、UDAL 规范。
+- `06-python-coding.md`：Python 编码规范；涵盖命名、注释、格式、导入、字符串、空值比较和空白。
+- `07-frontend-coding.md`：前端编码规范；涵盖 HTML/CSS/JavaScript/前端实践。
+- `08-code-management.md`：代码管理分册；涵盖 Git、仓库命名、README、`.gitignore`、权限、分支、评审、提交和版本。
+- `09-artifact-management.md`：制品管理分册；涵盖构建元数据、扫描、制品库、访问/审计、版本、晋级、清理及 SBOM/追溯。
+- `10-pipeline-management.md`：流水线管理分册；涵盖命名、运行环境、触发、CI/CD、VerifyCI/MergeCI/ReleaseCI 和分级门禁。
+- `11-test-management.md`：测试管理分册；涵盖计划、用例、环境、执行、报告、验收、缺陷和测试分级。
+- `12-security.md`：安全分册；涵盖安全设计、开发、部署和语言专项控制，优先检查 `【强制】` 条款。
+- `13-deployment.md`：部署管理分册；涵盖准备、文档、审批、任务、执行、验证和环境要求。
+
+## 研发云互联互通试行规范
+
+- `20-rd-cloud-overview.md`：总册；适用范围和术语。
+- `21-rd-cloud-system-access-auth.md`：系统接入；SSO、OAuth 2.0 和资产授权。
+- `22-rd-cloud-data-open-access.md`：数据开放与接入；订阅/查询/接入、DCOOS、HTTP(S)、Kafka、网络和数据格式。
+- `23-rd-cloud-openapi.md`：能力开放 OpenAPI；账号/应用授权和研发云开放接口。
+- `24-rd-cloud-scaffold-service.md`：脚手架服务接入；签名、部署、服务管理、版本关联和回调。
+
+## 使用规则
+
+按标题和关键字检索相应原文；报告结论时保留原文的 C 级别和 `【强制】` 标签。本索引只负责导航，不能替代原文。

.gitignore

@@ -0,0 +1,17 @@
+# 操作系统文件
+.DS_Store
+Thumbs.db
+desktop.ini
+
+# IDE 本地配置
+.vscode/
+.idea/
+
+# 本地敏感配置
+.env
+.env.*
+!.env.example
+
+# 临时与日志文件
+*.log
+*.tmp

AGENTS.md

@@ -0,0 +1,28 @@
+# 中国电信研发项目指令
+
+本文件适用于本项目中的所有新建、修改、审查和交付工作。以 `.agents/skills/telecom-rd-standards/` 中的技能、脱敏 Markdown 整理版和工作区 `规范文档/` 中的原始 DOCX 为依据；条款争议、表格、模板和版式以原始 DOCX 为准。
+
+## 分层加载策略
+
+1. 每个新 Agent 或新任务先阅读本文件；它只提供不可绕过的红线和加载规则。
+2. 首次处理新项目、设计、审查、交付或涉及规范的任务时，阅读 `.agents/INDEX.md`，按任务—规范选择矩阵加载对应功能规范；支持技能机制的 Agent 应显式加载 `telecom-rd-standards`。
+3. 普通、小范围实现或自查，读取对应的速查指南即可；安全、密钥、鉴权、数据库权限、外部接口、CI/CD、制品和部署变更，即使范围很小也必须加载对应功能规范。
+4. 仅在下列情形核验脱敏 Markdown 原文整理版，并按需回查原始 DOCX：输出“规范要求”、C 级别结论、阻断/整改项；处理高风险变更；出现条款争议；或功能规范明确要求核验。不得以摘要或文件名替代上述结论的原文条款。
+5. 同一任务内可复用已读取且未变更的规范，不重复全量阅读；任务范围、目标 C 级别、技术栈、数据敏感性、外部接口或部署方式变化时，重新选择并补充加载。
+6. 项目未分级时，以 C1 作为临时基线，并标记为“待项目负责人确认”。
+
+## 新项目与新增模块
+
+在创建目录、脚手架或业务代码前，先读取 `01-project-init-and-architecture.md`，形成简要方案：目标、非目标、约束、数据分类、风险、可选方案、推荐方案和首批验收条件。将每项控制标记为 `规范要求`、`工程建议` 或 `待确认`；只有原文明确支持的控制才能标记为规范要求，并保留来源章节和 C 级别。
+
+实现时至少落实与范围匹配的需求追踪、设计、Git 仓库/分支/评审、测试、安全扫描、制品追溯、流水线和部署准备。优先审查密钥/敏感数据、鉴权、输入校验、错误信息、日志、第三方依赖和最小权限。
+
+## 审查与交付
+
+审查实际证据：差异、配置、流水线、测试结果、制品和部署方案。按 `【阻断】`、`【需整改】`、`【建议】`、`通过/不适用` 输出，并附证据、来源和整改动作。
+
+完成时说明目标 C 级别、适用范围、已验证证据、阻断/整改项、证据缺口和下一步。不得将中国电信内部代码、文档、密钥、令牌或签名信息放入互联网暴露的存储、处理或传输工具。
+
+## 适用边界
+
+本包直接提供 Python、前端和通用研发流程的指南。其他语言只应用已核实的通用/安全/过程要求；在没有对应原文时，明确标记语言专项要求为证据缺口，不得臆造合规结论。

README.md

@@ -1,3 +1,3 @@
-# telecom-rd-project-template
+# 中国电信研发项目模板
 
 中国电信研发项目模板