docs: specify v02 cloud web validation checks
This commit is contained in:
Codex
@@ -100,7 +100,7 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
|
||||
|
||||
1. UniDesk CLI `hwlab g14 control-plane trigger-current --lane v02 --confirm` 解析当前 `origin/v0.2` 完整 source commit SHA，先复核 `devops-infra` mirror 的 `localV02` ref，必要时自动执行一次 bounded manual `git-mirror sync` Job，再创建 commit-pinned `hwlab-v02-ci-poll-<short12>` PipelineRun；默认 `--dry-run` 只返回将要创建的 manifest 和 mirror pre-sync 计划。
|
||||
2. `prepare-source` 通过 `devops-infra` mirror checkout `v0.2` source，并从 mirror 中的 `v0.2-gitops` 读取上一版 `deploy/artifact-catalog.v02.json`。
|
||||
3. CI/CD 校验只保留最小构建、语法、打包和冒烟检查；旧 DEV/D601/main gate、运行时内部证明型校验、健康诊断重断言和历史预检不进入 lane。
|
||||
3. CI/CD 校验只保留最小构建、TypeScript 语义检查、自动单元测试、打包和必要冒烟检查；旧 DEV/D601/main gate、运行时内部证明型校验、健康诊断重断言和历史预检不进入 lane。
|
||||
4. planner 根据 component input 判断 affected/reused services。
|
||||
5. affected service 通过 BuildKit 发布到 G14 本地 registry；reused service 复用 catalog digest。
|
||||
所有 selected service 的 build TaskRun 都只依赖 `plan-artifacts`，不按 service 串行排队，也不设置 8 并发或其他 Pipeline 级限流。
|
||||
@@ -120,6 +120,16 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
|
||||
|
||||
`rpt004:mvp:e2e`、`runner:issue-visibility:preflight` 和 `dev-base-image:preflight` 不属于 v0.2 最小 CI/CD 校验入口；它们代表旧验收、旧 runner 可见性预检或旧镜像基础预检口径。v0.2 `check/validate` 不再引用这些任务，若它们重新进入默认 check plan、package script 或 PipelineRun，应直接删除该入口，而不是为其补兼容逻辑。
|
||||
|
||||
### 最小测试/校验机制
|
||||
|
||||
v0.2 最小校验的目标是拦截高确定性低级错误，不恢复旧重型门禁。`hwlab-cloud-web` 源码、模板或浏览器 bundle 输入发生变化时，CI 必须在镜像发布和 GitOps promotion 前执行 Cloud Web source check。该 check 至少包含实际 bundle 输入集合的 TypeScript 语义检查、自动发现的单元测试、bundle build 和 dist freshness 校验。
|
||||
|
||||
语法检查和 Bun build 不能证明浏览器运行路径安全。`node --check` 只解析语法，`Bun.build()` 只转译和打包，二者都可能放过 `isRequestTraceEvent is not defined` 这类未绑定标识符；因此 Cloud Web check 必须用实际参与 bundle 的 `app.ts`、`app-device-pod.ts`、`app-conversation.ts`、`app-trace.ts` 和 `app-helpers.ts` 生成同一入口并运行 TypeScript semantic check，例如 `tsc --noEmit` 或等价 Bun/TS checker。该检查失败时不得继续发布 `hwlab-cloud-web` 镜像。
|
||||
|
||||
Cloud Web 单元测试必须自动发现并执行 repo-owned `web/hwlab-cloud-web/**/*.test.ts`，不能只依赖手写文件清单。新增 `app-trace`、markdown、auth、status 或 device-pod 前端纯逻辑测试后，应天然进入 `bun run --cwd web/hwlab-cloud-web check`。trace 渲染核心路径必须有不依赖浏览器、Playwright、公网或真实 provider 的轻量单测，直接构造 `runnerTrace.events` 并调用 trace row/render helper，确保请求事件、setup 事件、tool command summary、assistant markdown 和 completion row 不会因未定义 helper 或数据形态漂移在浏览器运行时崩溃。
|
||||
|
||||
默认 v0.2 CI 不启动 Playwright、布局 smoke、移动端截图、旧 quick prompt 检查、旧 M3 evidence 检查或历史 DEV/D601 browser gate。这些检查只能作为显式人工诊断或专项验收命令存在，不能重新进入最小 CI/CD 关键路径。新增测试也必须只表达当前 v0.2 目标行为；发现旧 UI/旧路由/旧门禁断言阻碍当前目标时，删除旧断言而不是维护兼容分支。
|
||||
|
||||
写 mirror 的一致性模型是 local-first、manual-flush。promotion task 只能持有 mirror/relay 写凭证，不持有 GitHub deploy key；GitHub deploy key 只存在于 `devops-infra` mirror/relay sync/flush 边界。mirror/relay 必须在本地 receive 期间完成 object closure、目标 branch allowlist、non-fast-forward 拒绝和 changed-path 最小校验；receive 成功后本地 ref 即为 Argo 可消费事实。flush 失败不得回滚已经 rollout 的本地 GitOps revision，但必须保留 pending/outbox 状态，下一次手动 flush 可重试并输出 last error，不得静默丢弃。
|
||||
|
||||
## 性能预算与回归判定
|
||||
@@ -466,6 +476,14 @@ GitOps branch 已更新、source branch render 通过、PipelineRun 名称存在
|
||||
|
||||
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：触发一次 `v0.2` code-only promotion，确认 `gitops-promote` 只 push 到 `devops-infra` 本地 mirror/relay，Argo 从本地 mirror/relay rollout；再执行 `git-mirror flush --confirm`，确认 GitHub `origin/v0.2-gitops` 快进到同一 revision，status 中 pending 清空。
|
||||
|
||||
## T8
|
||||
|
||||
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：在 v0.2 source checkout 或对应 PipelineRun primitive validation 日志中确认 `bun run --cwd web/hwlab-cloud-web check` 会在 `hwlab-cloud-web` 镜像发布前执行，并且该 check 包含实际 bundle 输入集合的 TypeScript 语义检查、自动发现的 `*.test.ts` 单元测试、bundle build 和 dist freshness 校验。
|
||||
|
||||
## T9
|
||||
|
||||
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：确认默认 v0.2 CI 没有重新加入 Playwright、旧 layout smoke、旧 quick prompt、旧 M3 evidence 或 DEV/D601 browser gate；若这些旧门禁重新进入最小 check plan 或 PipelineRun，应直接删除入口并保留 Cloud Web semantic check 与单元测试。
|
||||
|
||||
## 规格的实现情况
|
||||
|
||||
| 规格项 | 状态 | 说明 |
|
||||
|
||||
@@ -10,10 +10,10 @@
|
||||
|
||||
## 内部架构
|
||||
|
||||
- `web/hwlab-cloud-web/app.mjs` 是浏览器端主应用，组织 Workbench 状态、Code Agent 会话缓存、trace 轮询和 device-pod 面板。
|
||||
- `web/hwlab-cloud-web/app.ts` 是浏览器端主入口，和 `app-device-pod.ts`、`app-conversation.ts`、`app-trace.ts`、`app-helpers.ts` 共同组成实际 bundle 输入集合，组织 Workbench 状态、Code Agent 会话缓存、trace 轮询和 device-pod 面板。
|
||||
- `internal/dev-entrypoint/http.mjs` 提供静态服务、health 和 HTTP proxy 基础能力。
|
||||
- `internal/dev-entrypoint/cloud-web-routes.mjs` 定义可代理到 cloud-api 的同源 API route 和认证边界。
|
||||
- `web/hwlab-cloud-web/auth.mjs` 管理工作台登录态；真正的用户权限 authority 仍应收敛到 cloud-api。
|
||||
- `web/hwlab-cloud-web/auth.ts` 管理工作台登录态；真正的用户权限 authority 仍应收敛到 cloud-api。
|
||||
|
||||
## API 接口说明
|
||||
|
||||
@@ -28,6 +28,14 @@
|
||||
|
||||
## 测试规格
|
||||
|
||||
Cloud Web 的默认校验入口是 `bun run --cwd web/hwlab-cloud-web check`。该入口必须在 v0.2 CI 的 `hwlab-cloud-web` 镜像发布前执行，且保持秒级或低十秒级，不引入浏览器、Playwright、公网或真实 provider 依赖。
|
||||
|
||||
Cloud Web check 必须先对实际 bundle 输入集合运行 TypeScript 语义检查。语法检查和 Bun build 只能证明源码可解析或可打包，不能稳定发现未绑定标识符；`isRequestTraceEvent is not defined` 这类错误必须由 semantic check 在发布前拦截。实现上可以生成与 dist build 相同顺序的临时 app entry，再执行 `tsc --noEmit` 或等价 TS checker；只跑 `node --check`、`bun build` 或源码字符串断言不满足本规格。
|
||||
|
||||
Cloud Web 单元测试必须自动发现并执行 repo-owned `web/hwlab-cloud-web/**/*.test.ts`，不允许只维护硬编码文件清单。`app-trace` 的 trace row/render helper 必须有纯逻辑单测，直接构造 request、setup、commandExecution、assistant markdown 和 completion events，证明 trace 展示路径不会因为漏定义 helper、事件分类漂移或 markdown body 渲染变更而在浏览器运行期崩溃。
|
||||
|
||||
Cloud Web check 通过后仍需执行 bundle build 和 dist freshness 校验，确保实际发布的 `dist/app.js` 来自同一组 TypeScript 输入。默认 check 不恢复旧 quick prompt、旧 layout smoke、旧 M3 evidence、旧 DEV/D601 browser gate 或 Playwright；这些只能作为显式专项诊断，不得进入默认 CI/CD 关键路径。
|
||||
|
||||
## T1
|
||||
|
||||
阅读 docs/reference/spec-v02-hwlab-cloud-web.md，然后用 cli 手动测试以下内容：访问 `http://74.48.78.17:19666/` 和 `/health/live`，确认页面和 health 均来自 v02 cloud-web，而不是 DEV/PROD 端口。
|
||||
@@ -40,6 +48,14 @@
|
||||
|
||||
阅读 docs/reference/spec-v02-hwlab-cloud-web.md，然后用 cli 手动测试以下内容：打开 Workbench device-pod 面板，确认 status/freshness/blocker 显示来自 `/v1/device-pods`，未登录或未授权时必须显示认证/授权 blocker，不得把 fixture 或 blocked fallback 写成真实硬件 DEV-LIVE。
|
||||
|
||||
## T4
|
||||
|
||||
阅读 docs/reference/spec-v02-hwlab-cloud-web.md，然后用 cli 手动测试以下内容：运行 `bun run --cwd web/hwlab-cloud-web check`，确认输出或日志显示已执行 Cloud Web TypeScript 语义检查、自动发现的单元测试、bundle build 和 dist freshness 校验；不得用只跑 `bun build` 或浏览器手工刷新替代该检查。
|
||||
|
||||
## T5
|
||||
|
||||
阅读 docs/reference/spec-v02-hwlab-cloud-web.md，然后用 cli 手动测试以下内容：确认 trace 渲染相关单测覆盖 request、setup、commandExecution、assistant markdown 和 completion row；该测试必须能在无浏览器、无 Playwright、无公网、无真实 provider 的环境中执行。
|
||||
|
||||
## 规格的实现情况
|
||||
|
||||
| 规格项 | 状态 | 说明 |
|
||||
|
||||
Reference in New Issue
Block a user