docs: add HWLAB workbench performance SPEC

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

@@ -26,6 +26,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 - 当任务缺少上级方向、验收标准或原始验证入口时，先归类为规划/调查，不要直接变成实现任务。
 - L1 方向必须是直接服务 L0 使命的能力域。文档整理、阶段报告、项目管理机制、看板维护、技能维护、仓库名、工具名和临时执行路径都不能作为 L1 方向。
 - L1 是验收主责，不是宽泛标签。跨方向 issue 可以列关联 L1，但必须且只能有一个主责 L1，选择依据是哪个方向定义完成标准。
+- 重大规划型 issue 必须 P0 SPEC-first：P0 阶段先在 `project-management/PJ2026-01/specs/` 维护对应 SPEC，明确 SPEC 编号、上级/关联规格、架构图、数据流图、关键时序图和代码引用规则，再进入后续实现。issue 正文只能承载执行计划和证据，不能替代 SPEC 正文。
 
 ## 需求规格写作规则
 
@@ -33,6 +34,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 - 文档控制表只保留规格自身必要字段；状态只能写 `已生效`、`已废弃` 或 `未生效`。不要在文档控制表里写长期面板、阶段规格、L1 划分、规格来源或迁移来源。
 - 修改历史只记录已经定稿的版本。用户未明确说“可以定稿”前，不新增 `待提交` 版本号，也不把每次小编辑拆成一个版本。
 - L0、L1、L2 需求规格正文固定使用裁剪后的 1-7 章结构：文档控制、目的和范围、术语表、系统边界和接口、内部分工与规格索引、原子需求、过程控制。第 7 章只索引阶段验证、内测、灰度或用户反馈分流 issue；不要在 SPEC 正文追加假设和风险、变更控制、开放缺口、验收标准或执行过程流水。
+- 涉及新能力、跨模块架构、用户可见工作流、长期 API/数据模型、平台运维能力或多阶段实施的 SPEC，必须在正文中包含目标架构图、数据流图和关键时序图；图形优先使用 Markdown 内嵌 `mermaid`，并和原子需求编号互相对应。
 - L0 系统边界必须把 HWLAB 作为完整系统看待，描述外部使用者、外部输入、受控资源、外部输出、用户接口和系统责任边界，不写内部治理材料。
 - 稳定概念用术语表表达；不要写没有判定价值的“运行概念”流水。
 - L0 的 L1 方向树和项目规格索引合并为内部模块分工与规格索引，用相对路径索引到每个内部模块规格文档。
@@ -42,6 +44,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 - 单一主责、关闭验收、规格沉淀、回写和偏离判定是治理规则，不得伪装成 L0 原子需求。
 - L2 是稳定能力域，不是仓库文件名或原始 spec 文档一比一搬运目录。单个 L1 下的 L2 通常不超过 6 个；从仓库参考文档迁移过来的大量细项应合并到少量 L2，并把更细的服务、lane、source truth、验证切片放到 L3 或正文分工中。
 - 运维交付内容必须按职责归位：通用 CI/CD、发布判定、镜像 promotion 放到平台运维的发布流水；通用 Git mirror、source truth、GitOps branch、artifact catalog 放到源码同步；Secret/YAML/sourceRef/targetKey/fingerprint 放到 YAML运维。只有能抽象到多服务共用的规则才放通用 L2；AgentRun 固定 branch、namespace、Pipeline、GitOps path、真实 provider turn 等专项细节放到这些通用规格下的 AgentRun 专项 L3，`PJ2026-0102 Agent编排` 只引用这些支撑规格，不把运维后勤 L2 塞进 Agent编排。
+- 大规划型 issue 范围内新增或修改的源码文件，文件头部必须标注遵循的 SPEC 编号、短名和实现引用版本，例如 `SPEC: PJ2026-01060505 Workbench性能 draft-2026-06-17-p0`；不得只写 issue 编号、`latest` 或 `current`。自动生成文件、第三方 vendored 文件、纯配置、锁文件和无法承载注释头的二进制产物可例外，但对应生成器、渲染器或配置入口必须可追溯到 SPEC。
 
 ## HWLAB 标准 issue 锚点
 
@@ -59,6 +62,7 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 3. 写入 GitHub issue/PR 评论时，同时使用 `unidesk-gh`；所有写入必须从 `/root/unidesk` 通过 `bun scripts/cli.ts gh ...` 完成。
 4. 修改长期项目管理文档时，把稳定规划内容放到 `project-management/PJ2026-01` 的总规格/规格文件，阶段报告只保留带日期的总结。
 5. 修订 L1/L2 层级时，先按完成标准判断主责，再看实现表面。工具、CLI、Web、API 形态可以形成关联 L1，但主责 L1 必须是定义完成标准的能力域。
+6. 更新重大规划型 issue 时，先把 P0 SPEC 文件和图维护到位，再用 `unidesk-gh` 回写 issue；后续代码任务必须在 issue 中引用 SPEC 编号和实现引用版本。
 
 ## 必需层级和职责
 
@@ -71,3 +75,4 @@ description: UniDesk 项目管理运行技能。用户提到 UniDesk 项目管
 - L4：执行任务 / PR / CaseRun / smoke / 文档收口。负责具体执行和证据收集，不能重新定义父级范围。
 
 每个非平凡 issue 都应写明上级链接、目标分支/lane、验收标准、验证入口和收口回写目标。
+重大规划型 issue 还必须把“更新并确认 SPEC”列为 P0，且 P0 未完成前不得推进代码实现。

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

@@ -38,6 +38,19 @@ HWLAB Cloud M1 需要一个项目控制结构，避免局部 issue/PR 工作偏
 - 规格文件引用其他规格时，使用同目录相对路径 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。
 
+## 重大规划型 issue 的 P0 SPEC-first 规则
+
+涉及新能力、跨模块架构、用户可见工作流、长期 API/数据模型、平台运维能力或多阶段实施的大规划型 issue，P0 必须先维护对应 SPEC，再继续实现。issue 只能记录执行状态、讨论和证据，不能成为稳定需求、架构、数据流、时序或验收口径的唯一正文。
+
+P0 SPEC 必须完成：
+
+- 分配或确认 SPEC 编号、短名、层级、主责 L1/L2、上级规格和关联规格。
+- 按模板写清文档控制、目的和范围、术语表、系统边界、内部分工、原子需求和过程控制。
+- 为涉及实现架构的数据面补齐目标架构图、数据流图和关键时序图；图形优先使用 Markdown 内嵌 `mermaid`。
+- 在 SPEC 中写明后续代码文件头部应标注的 SPEC 编号、短名和实现引用版本。
+
+后续代码阶段只能在 P0 SPEC 明确后开始。后续讨论改变稳定需求、数据流、接口或验收口径时，先更新 SPEC，再更新 issue 计划。该规划型 issue 范围内新增或修改的源码文件，文件头部必须标注遵循的 SPEC 编号、短名和实现引用版本；自动生成文件、第三方 vendored 文件、纯配置、锁文件和不能承载注释头的二进制产物可例外，但对应生成器、渲染器或配置入口必须能追溯到 SPEC。
+
 ## 当前 HWLAB issue 锚点
 
 - L0 总规格：`project-management/PJ2026-01/specs/PJ2026-01-HWLAB.md`。该规格文档本身承担索引职责；历史 issue 为 `[#1194](https://github.com/pikasTech/HWLAB/issues/1194)`。

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

@@ -219,6 +219,70 @@
 - [ ] 如稳定规则变化，更新 `project-management/PJ2026-01` 中的对应规格文件
 ```
 
+## 重大规划型 issue P0 SPEC 先行块
+
+```markdown
+## P0 SPEC 先行
+
+- SPEC 编号: PJ2026-010N0M
+- SPEC 文档: project-management/PJ2026-01/specs/<对应规格文件>.md
+- 上级规格: project-management/PJ2026-01/specs/<父级规格>.md
+- 关联规格: <Web/API/AgentRun/平台运维等相关 SPEC>
+- 实现引用版本: draft-YYYY-MM-DD-p0
+- 目标图:
+  - [ ] 架构图已写入 SPEC
+  - [ ] 数据流图已写入 SPEC
+  - [ ] 关键时序图已写入 SPEC
+- 代码引用规则:
+  - [ ] 本 issue 范围内新增或修改源码文件头部必须标注 `SPEC: <编号> <短名> <实现引用版本>`
+  - [ ] 自动生成、vendored、纯配置、锁文件或二进制产物如不能加头部，必须能从生成器/渲染器/配置入口追溯到 SPEC
+
+后续实现只能在 P0 SPEC 编号、目标图和代码引用规则确认后开始。若后续讨论改变稳定需求、数据流、接口或验收口径，先更新 SPEC，再更新本 issue 计划。
+```
+
+## SPEC 图与代码引用章节片段
+
+````markdown
+### 5.1 目标架构图
+
+```mermaid
+flowchart LR
+  A[入口] --> B[服务边界]
+  B --> C[持久化或运行事实]
+  C --> D[用户/运维可见输出]
+```
+
+### 5.2 目标数据流图
+
+```mermaid
+flowchart TD
+  A[外部输入] --> B[校验/归一化]
+  B --> C[权威状态]
+  C --> D[投影/查询]
+  D --> E[外部输出]
+```
+
+### 5.3 关键时序图
+
+```mermaid
+sequenceDiagram
+  participant U as 用户或调用方
+  participant C as 客户端
+  participant S as 服务端
+  participant R as 运行事实
+  U->>C: 发起动作
+  C->>S: 受控请求
+  S->>R: 读取或写入事实
+  R-->>S: 事实结果
+  S-->>C: 稳定响应
+  C-->>U: 用户可见结果
+```
+
+### 6.N <REQ> SPEC-first 与代码引用
+
+本能力的实现必须先引用本规格，再进入代码变更。该规划型 issue 范围内新增或修改的源码文件头部必须标注遵循的 SPEC 编号、短名和实现引用版本，例如 `SPEC: PJ2026-010N0M <短名> draft-YYYY-MM-DD-p0`，并用一句话说明文件职责。实现文件不得只写 issue 编号、`latest` 或 `current` 作为规格引用。
+````
+
 ## 阶段报告章节
 
 ```markdown