Merge remote-tracking branch 'origin/master'

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

@@ -71,6 +71,11 @@ bun scripts/cli.ts hwlab nodes control-plane legacy-cicd --help
   - 当前 GitOps catalog 落后 source 时，plan 必须把累计发布欠账与本次 base 到 source 的请求范围分开显示；
   - 有效范围大于请求范围时标记 `expanded`，`release trigger` 必须在发送 webhook 前拒绝；
   - 计划范围扩大时先修复 source range、源码、YAML 或项目 planner，再重新 plan；
+  - renderer rollout 范围必须对应实际 GitOps Pod template diff：
+    - renderer 重建完整 runtime tree 并改写未选 workload 的 source identity 时，plan 必须把全部实际受影响 workload 计入 rollout；
+    - renderer-only 变化不得误计为镜像构建；
+    - 只有未选 workload 的 manifest 和 source identity 均保持不变时才允许显示局部 rollout；
+    - renderer 拆分后的全部 materialization 源码路径必须纳入 planner 输入集合；
   - artifact catalog 必须从 owning YAML 声明、且与 Argo/promotion 相同的 GitOps read URL 与 branch 恢复；禁止用 source mirror 中的同名 branch 代替 GitOps authority；
   - 审阅通过后运行 `release trigger --confirm`；该命令只向 PaC 发送 webhook，由 PaC 创建 PipelineRun；
   - 禁止裸创建 PipelineRun、由 CLI 直建 PipelineRun，或恢复 Gitea 自动 hook；

project-management/PJ2026-01/specs/PJ2026-010404-project-management.md

@@ -116,6 +116,7 @@
 | PJ2026-01040407 | 观测与验收 | 本规格 6.7 | web-probe observe/analyze、DOM 脱敏、YAML-first 阈值和 issue-ready evidence | 平台运维、公开入口、Cloud Web | D601/v03 原入口验收 |
 | PJ2026-01040408 | YAML-first 运行配置 | 本规格 6.8 | 独立服务部署、Secret sourceRef、DB/OTel/health/public route 配置 | YAML运维、平台发布 | D601/v03 rollout |
 | PJ2026-01040409 | MDTODO前端重写 | [PJ2026-01040409 MDTODO前端重写](PJ2026-01040409-mdtodo-web-rewrite.md) | 清除旧 MDTODO Web 前端并按有界三栏、Rxx 树、报告预览和主动编辑重新实现 | Project Management API、Web工作台、web-probe | D601/v03 MDTODO 原入口可用性 |
+| PJ2026-01040410 | TaskTree PostgreSQL持久化 | 本规格 6.9 | TaskTree 在线事务、schema migration、CLI/API repository 一致性和灾备边界 | PostgreSQL、Temporal、API契约 | TaskTree CLI、API、worker 和 Web |
 
 ### 5.1 目标架构图
 
@@ -440,6 +441,33 @@ D601/v03 的 HWPOD-bound MDTODO 验收应允许把 Source 配置到 `hwpodId=d60
 
 Secret、DB DSN、provider token、session token、API key、host path 和 raw Markdown 内容不得出现在默认 CLI 输出、probe 报告、日志或错误 envelope 中。输出只披露对象名、key 名、sourceRef、presence、fingerprint、hash、字节数和 `valuesRedacted=true` 摘要。
 
+### 6.9 CLIENT-PM-REQ-009 TaskTree PostgreSQL持久化与schema migration
+
+| 编号 | 短名 | 主责模块 | 关联模块 |
+| --- | --- | --- | --- |
+| CLIENT-PM-REQ-009 | TaskTree持久化 | PJ2026-01040410 TaskTree PostgreSQL持久化 | [API契约](PJ2026-010403-api-contract.md)、[平台运维](PJ2026-0106-platform-ops.md) |
+
+- TaskTree 的在线事务权威固定为 PostgreSQL：
+  - 本地 dispatcher、API 和 Temporal worker 必须共享同一 repository 合同；
+  - GitHub 快照只承担版本化灾备，不成为在线读写 authority；
+  - CLI transport 切换不得改变命令、DTO、状态流转和错误语义。
+- Schema migration 必须采用版本化单写语义：
+  - 每个 migration 使用稳定且单调的版本标识，并在数据库 ledger 中记录完成状态；
+  - 多进程同时初始化时，使用 PostgreSQL transaction advisory lock 或等价数据库级事务锁串行化 migration 临界区；
+  - 等待者取得锁后必须重新读取 ledger，只执行尚未完成的版本；
+  - 已完成全部 migration 的普通读命令不得再次执行 `ALTER TABLE`、constraint 重建或其他 DDL；
+  - constraint 调整必须属于一次性版本 migration，禁止在每次 store 初始化时重复 drop/add。
+- Migration 失败必须保持可恢复和可观察：
+  - migration DDL 与 ledger 更新必须在同一事务内提交或回滚；
+  - 失败时保留 PostgreSQL SQLSTATE、migration 版本和稳定错误上下文；
+  - 禁止用静默重试、忽略 DDL 错误或返回空数据掩盖 migration 缺陷；
+  - CLI 成功或失败都必须返回一次完整 JSON envelope，不能以数据库已写入替代调用端输出。
+- 验收必须覆盖可变化的并发场景：
+  - fresh database 中多个 store 并发初始化后，只完成一次 schema migration，所有调用返回正常 envelope；
+  - existing database 中并发执行 group、task 和 report 只读命令时，不出现 `40P01` 或重复 DDL；
+  - migration 中途失败后事务完整回滚，后续初始化可从 ledger 状态继续；
+  - 并发客户端数量和重复轮次由测试参数控制，不写入生产配置或规格固定值。
+
 ## 7. 过程控制
 
 本规格的阶段活动由架构治理 issue [#2123](https://github.com/pikasTech/HWLAB/issues/2123) 拆分跟踪：

project-management/PJ2026-01/specs/PJ2026-010601-controlled-release.md

@@ -155,6 +155,11 @@ L2 与 L3 发布必须使用 `plan -> 人工审阅 -> trigger` 的受控手动
 
 范围相对 owning YAML 声明的发布意图扩大时，`plan` 必须明确列出新增项。操作者应先修正源码、配置或 planner，使范围回到预期后重新生成计划；不得通过确认参数、白名单、忽略 warning 或扩大资源预算继续触发。
 
+- Renderer rollout 范围必须对应实际 GitOps Pod template diff：
+  - renderer 重建完整 runtime tree 并改写未选 workload 的 source identity 时，`plan` 必须把全部实际受影响 workload 计入 rollout；
+  - 只有未选 workload 的 manifest 和 source identity 均保持不变时，才允许显示局部 rollout；
+  - renderer 入口拆分到子模块后，全部参与 runtime materialization 的源码路径仍必须属于 planner 的 renderer 输入集合。
+
 唯一 mutation 是受控手动 `trigger`。它必须显式选择 target、lane、精确 source commit 和 pipeline intent，并向 PaC 发送 webhook；PaC 从同一 source authority 创建 commit-pinned PipelineRun。触发前必须先审阅当前输入的 plan；计划输入或范围已变化时必须重新 plan。禁止 CLI 直建或裸创建 PipelineRun、由 PR 合并回调 trigger，或为兼容旧自动链保留第二入口。
 
 `trigger` 被 PaC 接收后，动态 `next` 必须指向同一 source commit 的只读 `delivery-observe`。不得引导旧 `closeout`、自动同步、人工 PipelineRun 或 Argo mutation；触发失败或输入变化时只能回到重新 plan。

project-management/PJ2026-01/specs/PJ2026-01060107-nc01-ci-resource-governance.md

@@ -86,6 +86,12 @@ CoreDNS 和 k3s 控制面使用 Kubernetes 系统关键优先级。Sub2API 和
 
 `plan` 必须针对精确 source commit 在一次只读输出中披露：YAML configRef、env identity、env reuse/build 判定、待构建镜像数量与服务列表、待 rollout 服务、全部受影响服务、范围基线、新增范围、触发层 concurrency、构建层 max parallel、批次数、step/sidecar 资源合同、priority class 和核心保护摘要。`status` 和 `diagnosis` 必须披露运行/排队 TaskRun 数与稳定意图键状态。共享读取超时只能投影为 warning 或 unavailable，不得把全部 consumer 伪装为真实失败。
 
+- Renderer 范围判定必须符合以下规则：
+  - renderer 输入或配置变化会重建完整 runtime tree，并改写未选 workload 的 source identity 时，`plan` 必须显示全部实际 rollout 服务；
+  - 镜像构建范围继续由 env、组件输入和 artifact provenance 独立决定；
+  - 禁止用局部源码影响范围替代实际 GitOps Pod template diff；
+  - 只有未选 workload 的 manifest 和 source identity 均保持不变时，才允许报告局部 rollout。
+
 ### 5.6 CI-RESOURCE-REQ-006 中心自动触发禁用
 
 中心 PaC owning YAML 必须声明 `deliveryTrigger.mode=manual-plan-confirm` 和 `deliveryTrigger.mechanism=pac-webhook`。PaC webhook 接收端继续作为唯一 PipelineRun 创建入口，但 Gitea push hook、PR merge callback、branch follower、poller 和其他自动发送方不得调用它；PR merge 后只允许 source mirror 或 authority 更新。受控 apply 必须删除或禁用 Gitea 自动 hook，并在 status 中把自动发送方启用视为配置漂移。