docs: refine HWLAB spec governance

.agents/skills/unidesk-oa/SKILL.md

@@ -18,12 +18,25 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 - 将 `project-management/PJ2026-01` 下的 Markdown 视为长期规格真相源。
 - 将 GitHub issue 视为执行控制面、历史讨论入口和长证据承载处：状态、讨论、跨仓引用、PR 链接和收口证据可以在 issue 中流转，但规格正文不得只写在 issue 中。
 - 长证据、trace、CaseRun registry、运行日志、历史 issue 摘要和证据索引保留在 GitHub issue 或具体执行 issue 中，禁止以 `evidence/` 目录或长证据文件形式污染 `project-management/PJ2026-01`。
-- 所有写入 Markdown 正文、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 只作为命令输入例外。
+- `project-management/PJ2026-01/specs/*.md` 规格文件不保留单独的迁移来源块；历史来源只写在修改历史 `v0.1` 的变更说明中，格式为 `迁移来源 <owner>/<repo>#<number>`。规格文件引用其他规格必须使用同目录相对路径 Markdown 链接，禁止引用其他规格的 GitHub issue、证据 issue、PR 或裸 `#<number>`。
+- 写入 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 只作为命令输入例外。
 - 不要让日报或阶段报告成为总规划。阶段报告只总结相对总规格的移动，不能替代中心规划。
 - 当任务缺少上级方向、验收标准或原始验证入口时，先归类为规划/调查，不要直接变成实现任务。
 - L1 方向必须是直接服务 L0 使命的能力域。文档整理、阶段报告、项目管理机制、看板维护、技能维护、仓库名、工具名和临时执行路径都不能作为 L1 方向。
 - L1 是验收主责，不是宽泛标签。跨方向 issue 可以列关联 L1，但必须且只能有一个主责 L1，选择依据是哪个方向定义完成标准。
 
+## 需求规格写作规则
+
+- 需求规格是对外系统能力、边界和职责说明，不写内部治理、issue 关闭规则、长期面板、阶段报告、执行控制面、单次验证流水、PR 过程或证据堆叠。
+- 文档控制表只保留规格自身必要字段；状态只能写 `已生效`、`已废弃` 或 `未生效`。不要在文档控制表里写长期面板、阶段规格、L1 划分、规格来源或迁移来源。
+- 修改历史只记录已经定稿的版本。用户未明确说“可以定稿”前，不新增 `待提交` 版本号，也不把每次小编辑拆成一个版本。
+- L0 系统边界必须把 HWLAB 作为完整系统看待，描述外部使用者、外部输入、受控资源、外部输出、用户接口和系统责任边界，不写内部治理材料。
+- 稳定概念用术语表表达；不要写没有判定价值的“运行概念”流水。
+- L0 的 L1 方向树和项目规格索引合并为内部模块分工与规格索引，用相对路径索引到每个内部模块规格文档。
+- 原子需求每条独立成节，信息表使用横向表格 `编号 | 需求 | 主责模块 | 职责划分`。主责模块必须带项目编号和相对路径链接；不写 `类型`、`验证方法`、`验证入口`、`必需证据`、`接受标准`，正文只说明意图和边界，不重复需求句。
+- 平台运维在 L0 中只能作为支撑后勤职责出现；对外需求应写成系统可用性、可恢复、资源可控等用户可感知能力，不写成“HWLAB 对外提供平台运维能力”。
+- 单一主责、关闭验收、规格沉淀、回写和偏离判定是治理规则，不得伪装成 L0 原子需求。
+
 ## HWLAB 标准 issue 锚点
 
 - L0 总规格：`project-management/PJ2026-01/specs/PJ2026-01-HWLAB.md`，历史 issue `[#1194](https://github.com/pikasTech/HWLAB/issues/1194)`。
@@ -44,7 +57,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 
 除非用户给出更严格的层级，否则使用以下任务树：
 
-- L0：重大项目 / 总规格。负责使命、非目标、当前中心、L1 方向树、全局验收和偏离规则。
+- L0：重大项目 / 总规格。负责使命、范围、系统边界、内部模块分工与规格索引、全局原子需求。
 - L1：方向。负责一个稳定能力域、范围边界、成功标准、L2 课题清单和子工作验收定义权。
 - L2：课题。负责某个 L1 内的具体工作计划，包括交付物、阻塞项和验证计划。
 - L3：子课题 / 验收切片。负责一个有界验收路径，例如一条 CaseRun 线、Web 检查、CLI smoke 或部署/控制面验证。

.agents/skills/unidesk-oa/references/project-planning.md

@@ -34,7 +34,7 @@ HWLAB Cloud M1 需要一个项目控制结构，避免局部 issue/PR 工作偏
 不要把长证据正文放进项目管理目录。项目管理目录只承载规格、治理和阶段中心；长证据保留在 GitHub issue。
 规格文件和 GitHub issue 的引用规则分开处理：
 
-- `project-management/PJ2026-01/specs/*.md` 中，每个规格文件最多保留一个 GitHub issue 链接，即迁移来源表里的自身原 issue。
+- `project-management/PJ2026-01/specs/*.md` 不保留单独的迁移来源块；历史来源只写在修改历史 `v0.1` 变更说明中，格式为 `迁移来源 <owner>/<repo>#<number>`。
 - 规格文件引用其他规格时，使用同目录相对路径 Markdown 链接，例如 `[PJ2026-0101 硬件池](PJ2026-0101-hardware-pool.md)`；不要引用其他规格的 GitHub issue、证据 issue、PR 或裸 `#<number>`。
 - GitHub issue/PR 正文和评论中的 issue/PR 引用必须写成 `[#<number>](https://github.com/<owner>/<repo>/issues/<number>)` 或 `[#<number>](https://github.com/<owner>/<repo>/pull/<number>)`，显示短号、链接目标保留完整 URL；不要显示裸长链接、裸井号编号或 `owner/repo` 加井号编号。`owner/repo#number` 只允许作为 CLI 命令参数 shorthand。
 

.agents/skills/unidesk-oa/references/templates.md

@@ -3,71 +3,79 @@
 ## L0 总规格骨架
 
 ```markdown
-# HWLAB 总规格
+# PJ2026-01 HWLAB 总规格
 
 ## 修改历史
 
 | 版本 | 对应 commit id | 更新日期 | 变更说明 |
 | --- | --- | --- | --- |
-| v0.1 | <commit> | <YYYY-MM-DD> | <一句话变更说明> |
+| v0.1 | <commit> | <YYYY-MM-DD> | 创建需求规格；如来自历史 issue，只在这里写迁移来源 <owner>/<repo>#<number>。 |
 
-编号: PJ2026-01
-短名: HWLAB
+当前正文仍在规格治理草稿中；未定稿前不新增版本号，不为单次编辑追加 `待提交` 版本。
 
-## 1. 项目使命
+## 正文
 
-用一段话描述产品目标和科研目标。
+## PJ2026-01 HWLAB 总项目需求规格
 
-## 2. 非目标
+## 1. 文档控制
 
-- ...
+| 字段 | 内容 |
+| --- | --- |
+| 编号 | PJ2026-01 |
+| 短名 | HWLAB |
+| 层级 | L0 总项目 |
+| 状态 | 已生效、已废弃或未生效 |
+| 需求规格模板 | [ISO/IEC/IEEE 29148 需求规格模板](../../templates/iso-iec-ieee-29148-requirements-spec-template.md) |
+| 规格治理索引 | [规格治理](spec-governance.md) |
 
-## 3. 当前中心
+## 2. 目的和范围
 
-- 当前主验证线:
-- 次级验证线:
-- 明确暂停/后置的线:
+### 2.1 项目使命
 
-## 4. 方向树
+<用一段话描述对外系统目标和用户价值。>
 
-| 层级 | 标题 | GitHub issue | 规格章节 | 当前状态 |
-| --- | --- | --- | --- | --- |
-| L1 | PJ2026-0101 硬件池 | TBD | ... | ... |
-| L1 | PJ2026-0102 Agent编排 | TBD | ... | ... |
-| L1 | PJ2026-0103 HarnessRL | TBD | ... | ... |
-| L1 | PJ2026-0104 客户端 | TBD | ... | ... |
-| L1 | PJ2026-0105 用户管理 | TBD | ... | ... |
-| L1 | PJ2026-0106 平台运维 | TBD | ... | ... |
+### 2.2 范围内
 
-## 5. 全局验收标准
+- <系统能力范围>
 
-- ...
+### 2.3 范围外
 
-## 6. 方向详情
+- <不属于本规格的对象>
 
-### L1: <方向短名>
+## 3. 术语表
 
-- 目标:
-- 非目标:
-- 当前课题:
-- 验收标准:
-- 验证入口:
-- 开放阻塞:
+| 术语 | 定义 |
+| --- | --- |
+| <术语> | <稳定定义> |
 
-## 7. issue 层级索引
+## 4. 系统边界和接口
 
-- L0:
-- L1:
-- L2:
-- L3/L4:
+本规格把 HWLAB 作为一个完整系统看待；本章只描述外部输入、外部输出和系统边界，不描述内部治理流程。
 
-## 8. 偏离规则
+| 边界项 | 内容 |
+| --- | --- |
+| 外部使用者 | <用户、外部系统、管理员或自动化任务> |
+| 外部输入 | <用户请求、业务对象、资源约束、身份凭据、文件或硬件选择> |
+| 受控资源 | <系统管理的设备、数据、运行环境或外部资源> |
+| 外部输出 | <用户可获得的状态、结果、产物、通知、报告或记录> |
+| 用户接口 | <Web、CLI、API、SDK、Webhook 等> |
+| 系统边界 | <系统负责什么；明确不替代用户或外部系统负责什么> |
 
-- ...
+## 5. 内部模块分工与规格索引
 
-## 9. 阶段报告链接
+| 编号 | 内部模块 | 规格文档 | 主责边界 | 上游依赖 | 下游支撑 |
+| --- | --- | --- | --- | --- | --- |
+| PJ2026-0101 | 硬件池 | [PJ2026-0101 硬件池](PJ2026-0101-hardware-pool.md) | <主责> | <依赖> | <支撑对象> |
 
-- ...
+## 6. 全局原子需求
+
+### 6.1 HWLAB-L0-REQ-001 <需求短名>
+
+| 编号 | 需求 | 主责模块 | 职责划分 |
+| --- | --- | --- | --- |
+| HWLAB-L0-REQ-001 | <HWLAB 应提供的对外系统能力> | [PJ2026-0101 <主责模块>](<相对路径>) | <主责负责什么；关联模块负责什么；哪些内容不属于本需求> |
+
+<正文说明该原子需求的意图、范围和边界。正文不重复需求句，不写类型、验证方法、验证入口、必需证据或接受标准。>
 ```
 
 ## L0 issue 正文
@@ -105,7 +113,7 @@
 
 | 层级 | 负责定义 | 不负责 | 回写对象 |
 | --- | --- | --- | --- |
-| L0 | 项目使命、当前中心、L1 方向树、全局验收、偏离规则 | PR 细节、CaseRun 日志、日报流水 | L0 规格文件、L1 issue |
+| L0 | 项目使命、范围、系统边界、内部模块分工、全局原子需求 | PR 细节、CaseRun 日志、日报流水、内部治理规则 | L0 规格文件、L1 issue |
 | L1 | 能力域范围、成功标准、L2 课题清单、原入口验收类型 | 单个 PR、一次 smoke、仓库/工具/运行面名称、项目管理动作 | L0 规格文件、对应 L1 规格文件 |
 | L2 | 单个方向内的具体课题、交付物、阻塞、验收计划 | 总方向定义、实现细节流水 | L1 issue，重大移动再回写 L0 |
 | L3 | 一个有界验收切片和单一验收路径 | 路线图、跨课题计划、父级范围变化 | L2/L1 issue |