mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: 将阶段入口迁入过程控制

Browse Source
This commit is contained in:
Codex
2026-06-15 01:04:22 +00:00
parent 77016a75a9
commit 977dd50646
3 changed files with 24 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/unidesk-oa/SKILL.md
+2 -2
View File
@@ -18,7 +18,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
- 将 `project-management/PJ2026-01` 下的 Markdown 视为长期规格真相源。 - 将 `project-management/PJ2026-01` 下的 Markdown 视为长期规格真相源。
- 将 GitHub issue 视为执行控制面、历史讨论入口和长证据承载处：状态、讨论、跨仓引用、PR 链接和收口证据可以在 issue 中流转，但规格正文不得只写在 issue 中。 - 将 GitHub issue 视为执行控制面、历史讨论入口和长证据承载处：状态、讨论、跨仓引用、PR 链接和收口证据可以在 issue 中流转，但规格正文不得只写在 issue 中。
- 长证据、trace、CaseRun registry、运行日志、历史 issue 摘要和证据索引保留在 GitHub issue 或具体执行 issue 中，禁止以 `evidence/` 目录或长证据文件形式污染 `project-management/PJ2026-01`。 - 长证据、trace、CaseRun registry、运行日志、历史 issue 摘要和证据索引保留在 GitHub issue 或具体执行 issue 中，禁止以 `evidence/` 目录或长证据文件形式污染 `project-management/PJ2026-01`。
- `project-management/PJ2026-01/specs/*.md` 规格文件不保留单独的迁移来源块；历史来源只写在修改历史 `v0.1` 的变更说明中，格式为 `迁移来源 <owner>/<repo>#<number>`。规格文件引用其他规格必须使用同目录相对路径 Markdown 链接，禁止引用其他规格的 GitHub issue、证据 issue、PR 或裸 `#<number>`；唯一例外是 L0 总规格第 5 章可保留跨 L1 阶段验证 issue 索引，用于内测、灰度和用户反馈分流，不承载问卷正文、参与者资料或执行流水。 - `project-management/PJ2026-01/specs/*.md` 规格文件不保留单独的迁移来源块；历史来源只写在修改历史 `v0.1` 的变更说明中，格式为 `迁移来源 <owner>/<repo>#<number>`。规格文件引用其他规格必须使用同目录相对路径 Markdown 链接，禁止引用其他规格的 GitHub issue、证据 issue、PR 或裸 `#<number>`；唯一例外是第 7 章过程控制可保留跨 L1 阶段验证 issue 索引，用于内测、灰度和用户反馈分流，不承载问卷正文、参与者资料、原始反馈、长证据或执行流水。
- AgentRun 仓库内 `docs/reference/spec-v01-*.md` 不再承载规格正文；迁移后只保留指向 UniDesk OA 规格的交叉引用 stub，避免 AgentRun repo 与 `project-management/PJ2026-01` 双份规格漂移。AgentRun 专项内容按职责落到 `project-management/PJ2026-01/specs/PJ2026-0102-agent-orchestration.md`、`project-management/PJ2026-01/specs/PJ2026-010601-controlled-release.md` 或 `project-management/PJ2026-01/specs/PJ2026-010602-source-sync.md` 及其 L3，不创建 `PJ2026-02`。 - AgentRun 仓库内 `docs/reference/spec-v01-*.md` 不再承载规格正文；迁移后只保留指向 UniDesk OA 规格的交叉引用 stub，避免 AgentRun repo 与 `project-management/PJ2026-01` 双份规格漂移。AgentRun 专项内容按职责落到 `project-management/PJ2026-01/specs/PJ2026-0102-agent-orchestration.md`、`project-management/PJ2026-01/specs/PJ2026-010601-controlled-release.md` 或 `project-management/PJ2026-01/specs/PJ2026-010602-source-sync.md` 及其 L3，不创建 `PJ2026-02`。
- 写入 GitHub issue/PR 正文或评论时，issue/PR 引用必须写成 `[#<number>](https://github.com/<owner>/<repo>/issues/<number>)` 或 `[#<number>](https://github.com/<owner>/<repo>/pull/<number>)`，显示短号、链接目标保留完整 URL；不要显示裸长链接、裸井号编号或 `owner/repo` 加井号编号。CLI 参数中的 `owner/repo#number` shorthand 只作为命令输入例外。 - 写入 GitHub issue/PR 正文或评论时，issue/PR 引用必须写成 `[#<number>](https://github.com/<owner>/<repo>/issues/<number>)` 或 `[#<number>](https://github.com/<owner>/<repo>/pull/<number>)`，显示短号、链接目标保留完整 URL；不要显示裸长链接、裸井号编号或 `owner/repo` 加井号编号。CLI 参数中的 `owner/repo#number` shorthand 只作为命令输入例外。
- 不要让日报或阶段报告成为总规划。阶段报告只总结相对总规格的移动，不能替代中心规划。 - 不要让日报或阶段报告成为总规划。阶段报告只总结相对总规格的移动，不能替代中心规划。
@@ -31,7 +31,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
- 需求规格是对外系统能力、边界和职责说明，不写内部治理、issue 关闭规则、长期面板、阶段报告、执行控制面、单次验证流水、PR 过程或证据堆叠。 - 需求规格是对外系统能力、边界和职责说明，不写内部治理、issue 关闭规则、长期面板、阶段报告、执行控制面、单次验证流水、PR 过程或证据堆叠。
- 文档控制表只保留规格自身必要字段；状态只能写 `已生效`、`已废弃` 或 `未生效`。不要在文档控制表里写长期面板、阶段规格、L1 划分、规格来源或迁移来源。 - 文档控制表只保留规格自身必要字段；状态只能写 `已生效`、`已废弃` 或 `未生效`。不要在文档控制表里写长期面板、阶段规格、L1 划分、规格来源或迁移来源。
- 修改历史只记录已经定稿的版本。用户未明确说“可以定稿”前，不新增 `待提交` 版本号，也不把每次小编辑拆成一个版本。 - 修改历史只记录已经定稿的版本。用户未明确说“可以定稿”前，不新增 `待提交` 版本号，也不把每次小编辑拆成一个版本。
- L0、L1、L2 需求规格正文固定使用裁剪后的 1-6 章结构：文档控制、目的和范围、术语表、系统边界和接口、内部分工与规格索引、原子需求。不要在 SPEC 正文追加假设和风险、变更控制、回写规则、开放缺口、验收标准或执行过程章节。 - L0、L1、L2 需求规格正文固定使用裁剪后的 1-7 章结构：文档控制、目的和范围、术语表、系统边界和接口、内部分工与规格索引、原子需求、过程控制。第 7 章只索引阶段验证、内测、灰度或用户反馈分流 issue；不要在 SPEC 正文追加假设和风险、变更控制、开放缺口、验收标准或执行过程流水。
- L0 系统边界必须把 HWLAB 作为完整系统看待，描述外部使用者、外部输入、受控资源、外部输出、用户接口和系统责任边界，不写内部治理材料。 - L0 系统边界必须把 HWLAB 作为完整系统看待，描述外部使用者、外部输入、受控资源、外部输出、用户接口和系统责任边界，不写内部治理材料。
- 稳定概念用术语表表达；不要写没有判定价值的“运行概念”流水。 - 稳定概念用术语表表达；不要写没有判定价值的“运行概念”流水。
- L0 的 L1 方向树和项目规格索引合并为内部模块分工与规格索引，用相对路径索引到每个内部模块规格文档。 - L0 的 L1 方向树和项目规格索引合并为内部模块分工与规格索引，用相对路径索引到每个内部模块规格文档。
project-management/PJ2026-01/specs/PJ2026-01-HWLAB.md
+11 -9
View File
@@ -26,7 +26,7 @@
| 需求规格模板 | [ISO/IEC/IEEE 29148 需求规格模板](../../templates/iso-iec-ieee-29148-requirements-spec-template.md) | | 需求规格模板 | [ISO/IEC/IEEE 29148 需求规格模板](../../templates/iso-iec-ieee-29148-requirements-spec-template.md) |
| 规格治理索引 | [规格治理](spec-governance.md) | | 规格治理索引 | [规格治理](spec-governance.md) |
本文采用 [ISO/IEC/IEEE 29148 需求规格模板](../../templates/iso-iec-ieee-29148-requirements-spec-template.md) 的 HWLAB 裁剪版：正文只保留稳定使命、范围、术语、系统边界、内部模块分工和全局原子需求。 本文采用 [ISO/IEC/IEEE 29148 需求规格模板](../../templates/iso-iec-ieee-29148-requirements-spec-template.md) 的 HWLAB 裁剪版：正文只保留稳定使命、范围、术语、系统边界、内部模块分工、全局原子需求和必要过程控制。
## 2. 目的和范围 ## 2. 目的和范围
@@ -94,14 +94,6 @@ L1 划分保持现有六个内部能力模块；本章同时作为内部模块
| PJ2026-0105 | 用户管理 | [PJ2026-0105 用户管理](PJ2026-0105-user-management.md) | 用户、组织、组织项目、组织工作台、权限、API key、credit、usage、billing、admin、租户隔离 | [客户端](PJ2026-0104-client.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[HarnessRL](PJ2026-0103-harness-rl.md)、[平台运维](PJ2026-0106-platform-ops.md) | [客户端](PJ2026-0104-client.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[硬件池](PJ2026-0101-hardware-pool.md)、[HarnessRL](PJ2026-0103-harness-rl.md) | | PJ2026-0105 | 用户管理 | [PJ2026-0105 用户管理](PJ2026-0105-user-management.md) | 用户、组织、组织项目、组织工作台、权限、API key、credit、usage、billing、admin、租户隔离 | [客户端](PJ2026-0104-client.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[HarnessRL](PJ2026-0103-harness-rl.md)、[平台运维](PJ2026-0106-platform-ops.md) | [客户端](PJ2026-0104-client.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[硬件池](PJ2026-0101-hardware-pool.md)、[HarnessRL](PJ2026-0103-harness-rl.md) |
| PJ2026-0106 | 平台运维 | [PJ2026-0106 平台运维](PJ2026-0106-platform-ops.md) | CI/CD、git mirror、YAML-first 自动化分布式运维、rollout、Prometheus 运维监控、平台发布 | 全部 L1 的发布、配置和监控需求 | [硬件池](PJ2026-0101-hardware-pool.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[HarnessRL](PJ2026-0103-harness-rl.md)、[客户端](PJ2026-0104-client.md)、[用户管理](PJ2026-0105-user-management.md) | | PJ2026-0106 | 平台运维 | [PJ2026-0106 平台运维](PJ2026-0106-platform-ops.md) | CI/CD、git mirror、YAML-first 自动化分布式运维、rollout、Prometheus 运维监控、平台发布 | 全部 L1 的发布、配置和监控需求 | [硬件池](PJ2026-0101-hardware-pool.md)、[Agent编排](PJ2026-0102-agent-orchestration.md)、[HarnessRL](PJ2026-0103-harness-rl.md)、[客户端](PJ2026-0104-client.md)、[用户管理](PJ2026-0105-user-management.md) |
### 5.2 阶段验证与反馈入口
本表只索引跨 L1 的阶段验证 issue，便于将内测、灰度和用户反馈分流回现有能力模块；不新增 L1，不替代阶段计划，也不把问卷、参与者资料或执行流水写入 L0 规格正文。
| 阶段 issue | 定位 | 关联 L1 | 回写口径 |
| --- | --- | --- | --- |
| [#1230](https://github.com/pikasTech/HWLAB/issues/1230) 内测一期招募与运行 | HWPOD 云嵌入式开发平台第一期内测；承载招募、运行、反馈分流和阶段结论 | 硬件池、Agent编排、HarnessRL、客户端、用户管理、平台运维 | 反馈先脱敏，再按主责 L1/L2 新建或关联具体 issue；阶段结束只回写稳定需求变化和重大边界移动 |
## 6. 全局原子需求 ## 6. 全局原子需求
### 6.1 HWLAB-L0-REQ-001 硬件资源池 ### 6.1 HWLAB-L0-REQ-001 硬件资源池
@@ -175,3 +167,13 @@ HWLAB 应作为云端服务保持可访问、可恢复、资源使用可控，
系统可用性与服务保障不是 HWLAB 对外出售的功能模块，而是用户能够持续使用 HWLAB 的基础条件。用户感知到的是入口可访问、任务不中途丢失、故障后有恢复路径、资源不会被失控占用；平台运维只作为后勤职责支撑这些对外结果。 系统可用性与服务保障不是 HWLAB 对外出售的功能模块，而是用户能够持续使用 HWLAB 的基础条件。用户感知到的是入口可访问、任务不中途丢失、故障后有恢复路径、资源不会被失控占用；平台运维只作为后勤职责支撑这些对外结果。
平台运维负责发布、YAML-first 自动化分布式运维、Prometheus 运维监控和故障恢复支撑。客户端、Agent编排、硬件池、HarnessRL 和用户管理提供各自服务健康指标和运行需求，并通过平台运维获得后勤支撑。 平台运维负责发布、YAML-first 自动化分布式运维、Prometheus 运维监控和故障恢复支撑。客户端、Agent编排、硬件池、HarnessRL 和用户管理提供各自服务健康指标和运行需求，并通过平台运维获得后勤支撑。
## 7. 过程控制
本章只索引跨 L1 的阶段验证、灰度、内测和用户反馈分流 issue，便于将阶段运行过程回写到现有能力模块；不新增 L1，不替代阶段计划，也不把问卷、参与者资料、原始反馈、长证据或执行流水写入 L0 规格正文。
### 7.1 阶段验证与反馈入口
| 阶段 issue | 定位 | 关联 L1 | 回写口径 |
| --- | --- | --- | --- |
| [#1230](https://github.com/pikasTech/HWLAB/issues/1230) 内测一期招募与运行 | HWPOD 云嵌入式开发平台第一期内测；承载招募、运行、反馈分流和阶段结论 | 硬件池、Agent编排、HarnessRL、客户端、用户管理、平台运维 | 反馈先脱敏，再按主责 L1/L2 新建或关联具体 issue；阶段结束只回写稳定需求变化和重大边界移动 |
project-management/templates/iso-iec-ieee-29148-requirements-spec-template.md
+11 -3
View File
@@ -13,9 +13,9 @@
使用原则： 使用原则：
- 业务需求规格用于使命和商业目标，利益相关方需求规格用于用户和运营方诉求，系统需求规格用于跨硬件、软件、人员和流程的系统级要求，软件需求规格用于软件能力要求。运行流程和一次性执行过程不进入需求规格正文，稳定概念优先沉淀为术语表。 - 业务需求规格用于使命和商业目标，利益相关方需求规格用于用户和运营方诉求，系统需求规格用于跨硬件、软件、人员和流程的系统级要求，软件需求规格用于软件能力要求。运行流程和一次性执行过程不进入 1-6 章需求正文；需要挂阶段 issue、内测、灰度或反馈分流时，放入第 7 章过程控制，稳定概念优先沉淀为术语表。
- HWLAB 的 L0、L1、L2 规格共用同一骨架，但粒度不同：L0 写使命、边界和全局需求；L1 写内部模块职责和验收边界；L2 写具体课题的交付物、阻塞项和验证计划。 - HWLAB 的 L0、L1、L2 规格共用同一骨架，但粒度不同：L0 写使命、边界和全局需求；L1 写内部模块职责和验收边界；L2 写具体课题的交付物、阻塞项和验证计划。
- 规格正文只写稳定需求、系统边界、外部输入输出和职责；内部治理、阶段报告、执行流水、长日志、拉取请求过程和一次性运行材料不进入需求规格正文。 - 规格正文的 1-6 章只写稳定需求、系统边界、外部输入输出和职责；内部治理、阶段报告、执行流水、长日志、拉取请求过程和一次性运行材料不进入需求章节。第 7 章过程控制只做阶段 issue、反馈分流和敏感信息边界的索引，不承载问卷正文、参与者资料、原始反馈或长证据。
- 每条原子需求使用独立小节。信息表使用横向表格且只放短元数据，推荐包含编号、短名、主责模块和关联模块；主责模块填写下一层主责单元，L0 写 L1，L1 写 L2，L2 写 L3，不重复当前规格本级；需求定义、职责划分、意图、范围和边界写在正文中，避免表格厚而正文薄。 - 每条原子需求使用独立小节。信息表使用横向表格且只放短元数据，推荐包含编号、短名、主责模块和关联模块；主责模块填写下一层主责单元，L0 写 L1，L1 写 L2，L2 写 L3，不重复当前规格本级；需求定义、职责划分、意图、范围和边界写在正文中，避免表格厚而正文薄。
- 不要为了凑全局需求条目自动添加证据收集、硬编码诊断、硬编码建议、任务状态收集、结果包或结果收集类次要需求；除非用户明确授意，这些内容不进入 OA 规格。 - 不要为了凑全局需求条目自动添加证据收集、硬编码诊断、硬编码建议、任务状态收集、结果包或结果收集类次要需求；除非用户明确授意，这些内容不进入 OA 规格。
@@ -48,7 +48,7 @@
| 上级规格 | <相对路径链接；L0 可留空> | | 上级规格 | <相对路径链接；L0 可留空> |
| 规格治理索引 | <相对路径链接> | | 规格治理索引 | <相对路径链接> |
本文采用 ISO/IEC/IEEE 29148 需求规格模板的项目裁剪版：正文只保留稳定使命、范围、术语、系统边界、内部模块或课题分工和原子需求。编号、层级职责、回写、偏离判定和交叉引用治理由规格治理文档承载。 本文采用 ISO/IEC/IEEE 29148 需求规格模板的项目裁剪版：正文只保留稳定使命、范围、术语、系统边界、内部模块或课题分工、原子需求和必要过程控制。编号、层级职责、回写、偏离判定和交叉引用治理由规格治理文档承载。
## 2. 目的和范围 ## 2. 目的和范围
@@ -98,4 +98,12 @@
| <需求编号> | <需求短名> | <下一层项目编号 短名，必要时使用相对路径链接> | <关联模块，使用相对路径链接> | | <需求编号> | <需求短名> | <下一层项目编号 短名，必要时使用相对路径链接> | <关联模块，使用相对路径链接> |
<正文第一段写完整需求定义。正文后续段落写主责职责、关联模块职责、意图、范围和边界。正文不放执行流水和长证据。> <正文第一段写完整需求定义。正文后续段落写主责职责、关联模块职责、意图、范围和边界。正文不放执行流水和长证据。>
## 7. 过程控制
本章只索引跨模块阶段验证、内测、灰度或用户反馈分流 issue；不新增 L1，不替代阶段计划，不把问卷、参与者资料、原始反馈、长证据或执行流水写入规格正文。
| 阶段 issue | 定位 | 关联模块 | 回写口径 |
| --- | --- | --- | --- |
| [#<编号>](https://github.com/<组织>/<仓库>/issues/<编号>) <短名> | <阶段验证或反馈分流定位> | <关联 L1/L2> | <脱敏、分流和回写规则> |
``` ```