docs: 补充 WebProbe 阻断后的验证降级流程
Pipelines as Code CI / hwlab-web-probe-sentinel-nc01- Success
Pipelines as Code CI / platform-infra-gitea-nc01- Success
Pipelines as Code CI / unidesk-host- Success

This commit is contained in:
Codex
2026-07-16 08:23:31 +02:00
parent f94366a0a5
commit 6655384306
+9
View File
@@ -17,6 +17,15 @@ description: UniDesk Web 开发与受控浏览器验证技能。用户提到 Web
- Web-probe 正式 CLI 入口是 `bun scripts/cli.ts web-probe ...`;旧 `hwlab nodes web-probe` 已移除,只能按 CLI 提示迁移,不要在 issue 或长期文档中继续记录旧入口。
- 涉及 Web 哨兵、`web-probe sentinel``monitor.pikapython.com`、定期/周期巡检或新建巡检时,必须同时加载 `$unidesk-monitor`
- 真实用户入口验证优先;源码检查、构建通过或截图局部正常不能替代原入口验收。
- WebProbe 因内存、浏览器资源或受控启动策略阻断时:
- 只把浏览器证据标记为 blocked,不得把整个开发、诊断或验收任务一并停止;
- 先记录策略引用、实际指标、阈值、blocker code 和允许的恢复入口;
- 需要止压时加载 `$unidesk-gc`,只执行其 scoped plan/run/status/memory 流程;
- scoped 恢复后仍不满足启动条件时停止重复 GC 和浏览器重试,继续执行不需要浏览器的验证;
- 优先使用仓库正式 CLI 访问同一已部署 Web/Cloud API dispatcher,完成 CLI E2E 或真实运行面短查询;
- 随后执行与改动直接相关的 CLI 合同测试、单元测试和轻量语法检查;
- 每层证据必须标明 `browser=blocked`、实际覆盖范围和未覆盖的视觉/DOM/交互边界;
- 用户目标只要求 CLI/API/CaseRun 终态时,同 dispatcher 的 CLI E2E 可以完成该目标,但不得冒充浏览器或视觉验收。
- 调试 HWLAB Cloud Web/Workbench 业务或功能 bug 时,使用 YAML 声明的 `--origin internal`;验收 public exposure、DNS、FRP、Caddy 或公网用户入口时,显式使用 `--origin public`
- `--url` 只是 custom/local 一次性逃生口,与 `--origin` 互斥;禁止通过手写 URL 或 IP 选择内网/公网运行面。本地 fake-server、localhost、dist 静态服务和 custom URL 只能作为开发 preflight 证据。
- 禁止在本地或 master server 直接跑 `vue-tsc` / 前端全量 typecheck 作为默认验证;本地只做语法级检查和真实入口复测,完整类型检查交给 CI、PipelineRun 或明确指定的受控构建运行面。