diff --git a/.agents/skills/unidesk-webdev/SKILL.md b/.agents/skills/unidesk-webdev/SKILL.md index 0b5cb992..9e6bff8f 100644 --- a/.agents/skills/unidesk-webdev/SKILL.md +++ b/.agents/skills/unidesk-webdev/SKILL.md @@ -32,6 +32,7 @@ description: UniDesk Web 开发与浏览器验证技能。用户处理 UniDesk/H ## web-probe 证据规则 - 用户要求“用 web-probe 做 smoke”时，`web-probe` 是取证工具，smoke 目标以用户/issue 指定的业务入口为准；例如目标是 Workbench 时，必须用 `web-probe run` 或 `web-probe observe start` + `observe command --type sendPrompt` 验证 Workbench 页面、会话、消息终态和 `observe analyze` 结果，不能改成只验证 web-probe 工具自身。只有用户明确说“验证 web-probe 自身/基础设施”时，才把 screenshot/script/observe 作为工具自检 smoke。 +- web-probe 发现 Workbench 请求风暴、浏览器卡死、内存上涨、submit/command 失败或投影缺失时，修复目标默认是 Workbench runtime/projection/read model 或业务代码；不得为了通过 smoke 去降低 Playwright/Chromium 能力、减少采样、自动刷新页面、关闭 freeze/memory 检测或把 blocker 降级。探针侧只能补证据、root cause 可见性和 YAML policy 接入。 - 交互式线上验收优先使用 `web-probe observe start`、`observe command`、`observe collect` 和 `observe analyze`；`web-probe script` 只作为一次性探测逃生口。重复出现的高频动作（折叠侧栏、关闭报告、切换全屏、导出低码率截图、采集布局指标）必须沉淀为 observe command 或 analyzer 能力。 - 截图取证必须优先配合页面的 RESTful 深链：截图命令应直接打开能恢复目标 source/file/task/report/session/run 和聚焦区域的 URL，再等待稳定 DOM 合约后截图。若目标页面缺少必要深链能力，不要先用脆弱点击/滚动流程硬截；应先增强前端深链与刷新恢复能力，再把截图能力接回 web-probe/observe/sentinel 命令。 - Issue closeout 引用 observer id、command id、stateDir/report SHA、screenshot SHA 和关键字段摘要；不要粘贴截图二进制、完整 JSON、Secret、cookie 或无界日志。 diff --git a/docs/reference/frontend.md b/docs/reference/frontend.md index 8b433d93..486de0b1 100644 --- a/docs/reference/frontend.md +++ b/docs/reference/frontend.md @@ -59,6 +59,14 @@ frontend shell 必须把左侧主模块与顶部子标签编译为统一的 URL - 浏览器直开、刷新、`history.back()` / `history.forward()`、点击总览 drilldown 卡片、点击左侧边栏、点击顶部标签都必须走同一个路由状态机；不得出现“页面内容切换了，但 URL 没变”或“URL 变了，但 shell 仍停在旧 tab”的分裂状态。 - frontend Bun server 必须把这些模块前缀下的深链接路由作为 SPA 入口返回同一个 `index.html` 和同一个 UniDesk shell；实现上允许统一把非静态资源路径都回到同一个 shell，但判定标准是公网直开 `/ops/status/`、`/nodes/docker/`、`/app/pipeline/`、`/app/code-queue/` 等深链接时都不得 404，且必须和从主页导航进入时一样显示左侧主模块边栏、顶部状态栏、顶部子标签和完整业务页面。禁止为某个用户服务 deep link 返回缺少 UniDesk shell 的独立/standalone bundle；新增应用服务、普通页面和性能优化入口也必须满足“直开 URL 与站内导航同壳同页”的一致性要求。 +## Workbench Runtime Guard + +Workbench 卡死、浏览器内存上涨、SSE 断线后 REST 请求风暴、刷新后消息堆叠、跨 session/trace 串线和 final response 投影缺失都属于 Workbench 运行面或唯一投影问题，权威规格是 [Workbench实时运行面](../../project-management/PJ2026-01/specs/PJ2026-0106050514-workbench-realtime-runtime.md) 与 [Workbench唯一投影](../../project-management/PJ2026-01/specs/PJ2026-0104010803-workbench-unique-projection.md)。修复方向必须优先回到 Workbench runtime、projection writer/finalizer、read model、SSE/REST contract、Vue store/reducer 和共享 runtime 模块；不得通过降低 Playwright/Chromium 能力、减少 web-probe 采样、自动刷新页面、切换 session repair、吞掉 submit 失败或把错误降级为提示文案来让 smoke 变绿。 + +Workbench 前端的 SSE、REST gap-fill、health probe、session refresh、trace refresh、storage、scroll 和 timeline row 更新必须经过统一 runtime 模块：typed error、scoped key、refresh queue/single-flight、SSE transport、timeline row model、safe storage、scroll runtime 和 health runtime。新增 `watch`、`setInterval`、visibility handler、EventSource error handler 或组件级 `fetch` 时，必须先确认是否能接入这些模块；不能在组件、store 或 analyzer 中再散写一套 retry、防抖、补洞、缓存、排序或 root-cause 逻辑。 + +当线上 web-probe 或哨兵发现请求风暴或浏览器无响应时，web-probe 是证据来源，不是业务修复目标。浏览器内存预算和 kill policy 的数值由 YAML/source-of-truth 控制，判定应按每个 page/page epoch 的 baseline 后有效内存和响应性证据；多页面启动的基础 RSS 不得被当成应用请求风暴的根因，也不得以压低 web-probe baseline 作为 Workbench 修复。 + ## Overview Task Drilldown `态势总览` 中的 `待处理任务` 指标必须可点击进入任务调度的 `待处理任务` 子标签，展示具体 queued、dispatched、running 任务的状态、Provider、已等待时间、payload 摘要和显式 `查看原始JSON` 操作。总览不得只给出无法追溯的数字；当后台把超时未终态任务转为 failed 后，待处理指标应回落，历史记录仍可在任务历史和执行结果中查看。核心指标还必须展示 `PGDATA`，显示 PostgreSQL 当前数据库用量、命名卷 `unidesk_pgdata_10gb` 和配置容量，便于从总览判断数据库状态。 diff --git a/docs/reference/observability.md b/docs/reference/observability.md index 06b7fed5..954c118e 100644 --- a/docs/reference/observability.md +++ b/docs/reference/observability.md @@ -25,6 +25,16 @@ Web/Workbench trace、Web 哨兵和 `web-probe observe` 的人工判定入口以 Web 哨兵 dashboard/API 展示问题的第一事实源是 sentinel runner 的 `/api/overview`、`/api/runs`、`/api/runs/{id}`、`/api/findings` 和 `web-probe sentinel dashboard verify|screenshot` 远程浏览器证据。OTel/Tempo 查询不到 `hwlab-web-probe-sentinel` service span 或具体 `sentinel-run-*` id 时，只能说明当前 instrumentation 或保留窗口没有覆盖这条 dashboard/API 路径；不得因此把 UI/API 口径问题判为已追穿，也不得阻塞已由 API/DOM 证据定位的修复。需要继续追 runner 内部链路时，应把缺少 Web 哨兵 span 作为 instrumentation 问题登记到对应治理 issue。 +## Workbench Request Storm And Freeze + +Workbench 请求风暴和浏览器无响应的根因调查必须同时使用 OTel、web-probe artifact 和前端 runtime 诊断，不能只看 provider 是否成功或单个 REST route 是否返回 200。最小证据应包含同一用户动作的 `traceId/sessionId/turnId` 或脱敏 scoped key、request family 计数、SSE transport state、recovery action、refresh queue/single-flight 状态、browser memory/freeze sample、observer/run/report SHA，以及用户页面是否仍可操作。缺少其中某个观测面时，先补观测或记录 instrumentation gap，再给出根因结论。 + +OTel 结论必须区分执行完成与可见投影完成。若 AgentRun/provider span、`turn_status_read` 或 projection write 显示 completed，但 Workbench UI 的 trace rows、final response 或 timeline 为空，这不是 provider 失败的充分证据；应继续检查 Workbench read model、projection revision、SSE cursor replay、trace event page、runtime reducer 和 request fan-out。相反，若 OTel 显示 submit/admission/dispatch/provider 已失败，则 web-probe 的空 UI 只是用户可见症状，不能把根因改写成前端布局或 dashboard 问题。 + +请求风暴的判定重点是同一 scoped key 或同一 transport error 是否重复触发多个请求族，尤其是 session/message/turn/trace/health 互相拉起、并发重复或 error handler 递归。修复必须让所有恢复动作通过 Workbench realtime SPEC 定义的 keyed queue、single-flight、bounded recovery action 和 typed error 诊断；不得通过增加轮询间隔、隐藏错误、自动刷新页面、减少采样、关闭 web-probe 检测或把红灯降级为 warning 来消除现象。 + +浏览器 freeze/blocker 的监控阈值、采样间隔和 kill policy 只从 YAML/source-of-truth 读取。调查报告只写字段族、采样来源、baseline 计算方式和可复测入口，不在文档或源码中复制具体数值。页面级有效内存应按 page/page epoch baseline 后增长量解释；多页面或 Chromium 启动基础成本是观测 baseline，不是 Workbench 应用内存泄漏的替代根因。 + ## CLI Logs 异步 job 的 stdout 和 stderr 位于 `.state/jobs/`。`job|jobs list` 默认只返回最新 50 条摘要，并为已知异步工作流返回轻量 `progress.summary`；`job status ` 与兼容别名 `jobs get/read ` 会返回结构化 `progress` 与有限尾部，避免输出爆炸，同时保留完整日志文件路径便于继续排查。实现必须只读取日志尾部字节，不得先把完整 job 日志读入 CLI 内存；长时命令的阶段、关键对象名和下一步查询命令应优先沉淀到 `progress`，不能要求调用者先阅读完整日志才能知道是否卡在提交、构建、发布或观测阶段。 diff --git a/project-management/PJ2026-01/specs/PJ2026-010401-web-workbench.md b/project-management/PJ2026-01/specs/PJ2026-010401-web-workbench.md index d5ab336e..933e4c3f 100644 --- a/project-management/PJ2026-01/specs/PJ2026-010401-web-workbench.md +++ b/project-management/PJ2026-01/specs/PJ2026-010401-web-workbench.md @@ -271,6 +271,8 @@ flowchart LR Web工作台在本规格中只保留前端消费边界：Cloud Web reducer、selectors、session rail、timeline、composer 和 Trace detail 只能消费该专项定义的 durable projection；SSE 只是 projection commit 后的通知和加速；fake-server fixture 只重放同一 REST/SSE 合同。Web reducer/selectors、Trace renderer、CLI renderer、fake-server 和测试断言不得从 trace tail、message text、tool event、result cache、session summary、list row、workspace snapshot、localStorage 或 elapsed timeout 推断 lifecycle、terminal、running 或 final response。运行中相对时间展示是唯一允许的显示层本地 now 使用场景：`startedAt`、`lastEventAt`、`finishedAt` 和 sealed `durationMs` 仍来自 durable projection，浏览器只用本地 now 对这些权威字段做直接格式化，不产生新事实。前端严禁为了掩盖跳变、归零、非单调、投影滞后或后台 tab 抖动而加入平滑、滤波、单调 floor、跳变 cap、二次缓存、最近更新时间重算或“看起来连续”的时间造假；发现此类异常必须暴露 diagnostic 并修 durable projection、read model、SSE/outbox 或上游时间源。详细架构图、数据流图、关键时序图、0repair 和严禁读侧推理约束以专项规格为准，本文不再维护第二份投影架构正文。 +[PJ2026-0106050514 Workbench实时运行面](PJ2026-0106050514-workbench-realtime-runtime.md) 是 Workbench 浏览器实时链路、防请求风暴和 freeze/blocker 的专项规格。Web 工作台新增或修改 SSE/EventSource、REST gap-fill、health probe、session/message/turn/trace refresh、timeline row、storage、scroll 或 runtime diagnostic 逻辑时，必须遵守该专项的 typed error、scoped key、refresh queue/single-flight、SSE transport、browser memory policy 和 no-probe-masking 要求。卡死、内存上涨和请求风暴的修复不得落在 web-probe/Playwright 资源削减、自动刷新或 analyzer 降级上；这些探针只能提供证据和红灯。 + 长程可靠 Workbench 的用户可见验收矩阵如下，后续实现和回归验证必须直接引用这些稳定场景，而不是用单次 canary 或局部截图替代。 长程可靠 Workbench 还必须覆盖 AgentRun terminal outbox 恢复场景：同一 session 连续两轮提交后，即使 cloud-api 在中途重启、events page 没有 terminal event 或第 2 轮后 `lastTraceId` 已变化，用户仍应在第 1/第 2 轮 message card 看到 sealed terminal final response，并能打开每个历史 trace 的 events page。用户在上游 command 已 terminal 后点击 cancel，不得把 completed final response 改写为 canceled；Web 只能展示 already-terminal/no-op 或真实 terminal projection 的状态。 diff --git a/project-management/PJ2026-01/specs/PJ2026-0106050514-workbench-realtime-runtime.md b/project-management/PJ2026-01/specs/PJ2026-0106050514-workbench-realtime-runtime.md index 9820a466..6f0f47e5 100644 --- a/project-management/PJ2026-01/specs/PJ2026-0106050514-workbench-realtime-runtime.md +++ b/project-management/PJ2026-01/specs/PJ2026-0106050514-workbench-realtime-runtime.md @@ -48,6 +48,7 @@ Workbench实时运行面负责把浏览器侧多轮 Workbench 的实时输入、 - server health/availability 探测、诊断投影和避免健康探测放大请求风暴。 - OTel/RUM/web-probe 对同一 Workbench 运行链路的 trace id、span、browser memory、request family 和 freeze/blocker 观测。 - Web 哨兵在浏览器无响应或浏览器内存超过受控 YAML 参数时直接杀死浏览器并报阻塞红错误；不得 fallback、自动刷新或把阻塞降为普通警告。 +- Workbench 请求风暴和浏览器 freeze 的防回归 closeout，要求修复点落在 Workbench runtime/projection/read model 或共享 runtime 模块，不得落在 web-probe/Playwright 资源削减、自动刷新或 analyzer 降级。 - 多阶段执行 issue、PR、rollout 和 web-probe smoke 的收口要求。 ### 2.3 范围外 @@ -71,6 +72,7 @@ Workbench实时运行面负责把浏览器侧多轮 Workbench 的实时输入、 | freeze blocker | web-probe 或浏览器运行面证明页面无响应、浏览器无法操作或浏览器内存超过受控 policy 后产生的阻塞红错误。 | | browser memory policy | YAML/source-of-truth 下发给 web-probe 或 runtime 的浏览器内存观测与 kill 策略；本文只定义字段语义，不定义数值。 | | REST 风暴 | 同一用户动作或 transport 错误导致 `/sessions`、`/messages`、`/turns`、`/traceEvents`、`/health` 等请求族无界重复或互相触发的状态。 | +| 架构退化修复 | 为了让 smoke、dashboard 或哨兵变绿而改变探针、刷新策略、fallback、采样强度或错误等级，却没有修复 Workbench runtime/projection/read model 根因的行为；本专项禁止该模式。 | ## 4. 系统边界和接口 @@ -217,6 +219,10 @@ sequenceDiagram | OPS-WBRT-REQ-010 | StageTracking | 本专项每个执行阶段必须有独立 GitHub 子 issue 跟踪，父 issue 只保存总 SPEC、阶段索引、PR/rollout/web-probe evidence 和剩余风险。 | | OPS-WBRT-REQ-011 | MechanicalCopy | 可迁移的 OpenCode 通用模块必须先机械拷贝再适配；closeout 必须记录 OpenCode 来源行号、HWLAB 拷贝后行号、适配 diff 范围、被保留/删除/改名的能力清单，以及不存在“参考后重写”的复查结论。 | | OPS-WBRT-REQ-012 | ShrinkageReview | 缩水是独立 P0 缺口；如果迁移后模块缺少 OpenCode 原有状态机、错误处理、限流/防抖、SSE/reducer、scroll persistence、timeline row parity 或 root cause 输出，即使生产路径已经 import，也不得判定完成。 | +| OPS-WBRT-REQ-013 | AppFixBoundary | 请求风暴、浏览器卡死、内存上涨、final response 投影缺失和刷新堆叠的修复必须落在 Workbench runtime、projection writer/finalizer、read model、SSE/REST contract、Vue store/reducer 或本专项迁移的共享模块；web-probe/Playwright 只能增强证据、baseline、blocker red 和 report 可见性，不能作为业务修复点。 | +| OPS-WBRT-REQ-014 | RequestStormRegression | 所有 SSE error、visibility change、health probe、session refresh、message refresh、turn status read、trace page read 和 gap-fill 都必须携带 scoped key、原因、in-flight/dedup 诊断和 recovery action；同一 scoped key 的重复恢复必须被 queue/single-flight 合并或阻塞，不能跨请求族递归触发。 | +| OPS-WBRT-REQ-015 | EvidenceSplit | closeout 必须区分 provider/AgentRun 执行完成、Workbench projection 完成和浏览器可见完成。OTel 显示 completed 但 UI trace rows/final response 为空时，应归入 read model/projection/runtime 可见性问题继续调查；不得把 completed trace 的空 UI 重新归因成 provider 失败，也不得用 analyzer fallback 生成假的 final response。 | +| OPS-WBRT-REQ-016 | NoProbeMasking | web-probe smoke 的目标是用户指定业务入口。为通过 smoke 而减少轮次、禁用内存/freeze 检测、自动 reload、重建页面、关闭 network 采样、吞掉 submit/command 失败或把 blocker red 降级为 warning，都属于架构退化。 | ## 7. 过程控制和源码引用 @@ -240,7 +246,19 @@ SPEC: PJ2026-0106050514 Workbench实时运行面 draft-2026-06-30-p0-1297-spec-f P0 未完成前，不得把 P1-P4 标记为可执行完成；P1-P4 中任何稳定语义、字段族、状态机或验收口径变化，必须先更新本 SPEC，再更新对应子 issue 和代码。 -### 7.1 #1315 纠偏完成定义 +### 7.1 防请求风暴与防架构退化 closeout + +Workbench 请求风暴或浏览器 freeze 类 issue 的关闭证据必须同时覆盖： + +- 原入口用户动作：至少证明目标 Workbench 页面、provider/profile、session、prompt/command、traceId 或等价 turn id 与用户实际路径一致。 +- 执行链路事实：OTel 或等价诊断能区分 admission、dispatch/provider、projection write/read、turn status read 和 browser visible ack；执行完成不自动等于 UI 完成。 +- 请求族事实：report 或 runtime diagnostic 能展示 session/message/turn/trace/health 请求族的 fan-out、dedup、single-flight、recovery action 和 root cause，不只写“没有卡死”。 +- 浏览器事实：web-probe 保存页面响应性、memory/freeze sample、requestfailed/pageerror/console 摘要和 analyzer finding；如果未触发 blocker，应说明没有达到 YAML policy，而不是删掉检测。 +- 架构事实：修复 PR 应指向 Workbench runtime/projection/read model 或本专项迁移模块的接入点，并说明旧散写 retry/fallback/repair 是否删除或变薄；只改 web-probe/Playwright/analyzer/dashboard 不足以关闭业务修复 issue。 + +若当前 issue 明确只验收“没有请求风暴或浏览器卡死”，允许把 final response 投影为空、trace rows 为空等问题记录为非阻塞剩余风险；但必须说明该裁剪口径，不得把这类投影缺口写成已修复。 + +### 7.2 #1315 纠偏完成定义 #1315 不再以“降低 web-probe/Playwright 启动内存占用”作为修复方向；web-probe 的浏览器资源占用只作为观测 baseline。真正完成标准是：OpenCode 可整模块迁移的能力在 HWLAB Vue Workbench 中 100% 完成机械拷贝、适配和生产接入，且所有新增策略参数都由 YAML 或 runtime projection 控制。 diff --git a/project-management/PJ2026-01/specs/PJ2026-01060508-web-probe-sentinel.md b/project-management/PJ2026-01/specs/PJ2026-01060508-web-probe-sentinel.md index 6da678bc..b2b26c8a 100644 --- a/project-management/PJ2026-01/specs/PJ2026-01060508-web-probe-sentinel.md +++ b/project-management/PJ2026-01/specs/PJ2026-01060508-web-probe-sentinel.md @@ -459,6 +459,8 @@ Web哨兵必须只编排现有顶层 `web-probe observe start/status/command/col 人工 CLI 是排障和原入口验收的一等入口；哨兵是调度入口。两者对同一 stateDir、同一 report 和同一 trace-frame 的解释必须一致。 +当 `web-probe` 被用于 Workbench smoke 或巡检时，smoke 目标是 Workbench 用户入口，不是 web-probe 自身。若观察到请求风暴、浏览器 freeze、内存上涨、submit/command 失败、trace rows 缺失或 final response 缺失，哨兵只能记录 blocker、root cause、artifact 和 drill-down；修复责任必须回到 [Workbench实时运行面](PJ2026-0106050514-workbench-realtime-runtime.md)、[Workbench唯一投影](PJ2026-0104010803-workbench-unique-projection.md) 或对应业务规格。不得为了让哨兵变绿而减少采样、自动刷新页面、重建 page、关闭 freeze/memory 检测、降低 finding 等级、修改 Playwright 启动参数或把业务 smoke 改成 web-probe 工具自检。 + ### 6.2 OPS-SENTINEL-REQ-002 YAML-first 配置引用 | 编号 | 短名 | 主责模块 | 关联模块 | @@ -503,6 +505,8 @@ P8 起，quick verify 如果没有产生 sendPrompt 业务 turn、有效 session P8 恢复判定必须把 Workbench 业务失败继续 drill-down 到运行面依赖。当 trace-frame 或 Final Response 暴露 `hwlab-cloud-api request handling failed`、PostgreSQL `53300`、`too many clients already` 或等价 DB 连接槽耗尽证据时，quick verify 不能收口为前端展示缺陷；必须检查 PK01/PostgreSQL `max_connections`、各服务连接池、CrashLoop 探针风暴和当前 `pg_stat_activity`，并通过 YAML source of truth 收敛容量或池化参数。 +请求风暴和 freeze 判定必须保留请求族、page/page epoch、页面内存 baseline 后有效内存、CDP/Playwright 响应性、control command 结果和 OTel trace/span 关联摘要。具体 policy 数值来自 YAML/source-of-truth；报告只展示字段、状态、来源和是否命中 policy，不在 dashboard、report 文案或源码中复制硬编码阈值。若当前 closeout 明确裁剪为“未复现请求风暴或浏览器卡死”，可以把 trace rows/final response 投影为空列为非阻塞剩余风险，但不得写成 Workbench 投影问题已修复。 + ### 6.5 OPS-SENTINEL-REQ-005 CI/CD、GitOps 和 maintenance | 编号 | 短名 | 主责模块 | 关联模块 | @@ -519,7 +523,7 @@ HWLAB runtime 发布 Pipeline 应在 Argo sync 前调用当前哨兵 `maintenanc 哨兵服务不可用、首次安装未完成或配置未就绪时，CI/CD 必须结构化失败并输出缺失项、恢复建议和可重试命令；不得自动回退到原纯客户端 CLI、裸 Playwright、私有 API、read-side repair、reload 循环或 session repair 形成第二执行路径。人工排障可以显式运行原 `web-probe observe start/status/command/collect/analyze`，但不能被 targetValidation 当作自动通过证据。 -`web-probe sentinel control-plane trigger-current --confirm --wait` 只等待 source mirror、publish、flush、publicExposure、Argo 和 runtime observed 收敛；CI/CD confirm-wait 超过 YAML `confirmWait.maxSeconds`（当前 120s）时必须输出 warning，并先优化等待阶段耗时，不得继续把长业务验证塞在部署同步路径里死等。`sentinel validate --quick-verify --confirm --wait` 和 maintenance stop quick verify 才执行 targetValidation 业务验证；业务 quick verify 可通过 YAML `targetValidation.maxSeconds` 放宽到 300s。计时超限本身只作为非阻塞告警；只有真正影响 Code Agent 多轮业务链路、submit/command 执行、trace/final 可见性或 session 连续性的失败才构成 targetValidation blocker。不得通过减少业务轮次、吞掉 submit 失败、fallback 到第二执行路径或读侧 repair 来消除红灯。 +`web-probe sentinel control-plane trigger-current --confirm --wait` 只等待 source mirror、publish、flush、publicExposure、Argo 和 runtime observed 收敛；CI/CD confirm-wait 超过 YAML `confirmWait.maxSeconds` 时必须输出 warning，并先优化等待阶段耗时，不得继续把长业务验证塞在部署同步路径里死等。`sentinel validate --quick-verify --confirm --wait` 和 maintenance stop quick verify 才执行 targetValidation 业务验证；业务 quick verify 的等待预算由 YAML `targetValidation.maxSeconds` 控制。计时超限本身只作为非阻塞告警；只有真正影响 Code Agent 多轮业务链路、submit/command 执行、trace/final 可见性或 session 连续性的失败才构成 targetValidation blocker。不得通过减少业务轮次、吞掉 submit 失败、fallback 到第二执行路径或读侧 repair 来消除红灯。 ### 6.6 OPS-SENTINEL-REQ-006 dsflash-go 十轮 canary @@ -581,7 +585,7 @@ P15 cadence/OTel 范围内新增或修改的 CronJob renderer/status probe、run | --- | --- | --- | --- | | OPS-SENTINEL-REQ-009 | Dashboard工作台 | PJ2026-0106050809 Dashboard工作台 | [Workbench性能](PJ2026-01060505-workbench-performance.md)、[Web工作台](PJ2026-010401-web-workbench.md) | -Dashboard 必须是值守和分析工作台，而不是 raw JSON 或单列表格。首屏至少呈现 overall status、node/lane/public origin、config readiness、scheduler heartbeat age、maintenance 状态、latest run、120s targetValidation budget、severity counts 和最新 report SHA。超过 120s 的 quick verify 或 canary 仍应保持 warning/red，不得通过调大预算、减少轮数或 fallback 视图变绿。 +Dashboard 必须是值守和分析工作台，而不是 raw JSON 或单列表格。首屏至少呈现 overall status、node/lane/public origin、config readiness、scheduler heartbeat age、maintenance 状态、latest run、YAML targetValidation budget、severity counts 和最新 report SHA。超过 YAML targetValidation budget 的 quick verify 或 canary 仍应保持 warning/red，不得通过调大预算、减少轮数或 fallback 视图变绿。 Runs history 必须支持 scenario、status、severity、时间窗口、maintenance、observer id、run id 和文本搜索；排序至少覆盖 updated time、created time、finding count 和 severity。Run timeline 应稳定展示最近窗口状态，帮助用户判断 blocked 是否连续、同一 finding 是否反复出现。 @@ -691,7 +695,7 @@ publish Job 未在等待预算内结束时，CLI 必须输出 job 名称、pod 当 publish 已产出镜像 digest，但 GitOps、git mirror、Argo 或 runtime observed 未收敛时，CLI 必须直接给出下一步：先查看 `web-probe sentinel control-plane status` 和 `hwlab nodes git-mirror status`，若 GitOps pending flush 则走 `hwlab nodes git-mirror flush --confirm --wait`，若 Argo/runtime stale 则走 `web-probe sentinel control-plane apply --confirm --wait`。操作员不得靠猜测在裸 `kubectl/argo` 和多条旧路径之间切换。 -JD01/v03 `jd01-web-probe-sentinel` 的小改动滚动上线是本阶段验收入口。closeout 必须记录 SPEC P14 引用、source commit、publish job、digest、GitOps revision、git mirror pending/inSync、Argo/runtime alignment、`validate`、远程 dashboard screenshot 和 latest report 证据。若总等待仍超过 120s，closeout 必须记录阶段归因、env reuse/cache 摘要和下一步优化方向；不得通过单纯放宽 120s 预算收口。 +JD01/v03 `jd01-web-probe-sentinel` 的小改动滚动上线是本阶段验收入口。closeout 必须记录 SPEC P14 引用、source commit、publish job、digest、GitOps revision、git mirror pending/inSync、Argo/runtime alignment、`validate`、远程 dashboard screenshot 和 latest report 证据。若总等待仍超过 YAML confirmWait 或 targetValidation 预算，closeout 必须记录阶段归因、env reuse/cache 摘要和下一步优化方向；不得通过单纯放宽 YAML 预算收口。 ### 6.15 OPS-SENTINEL-REQ-015 Cadence 调度稳定性与 OTel 覆盖 @@ -721,7 +725,7 @@ Dashboard 增强执行 issue 为 [#935](https://github.com/pikasTech/unidesk/iss P7 P6 收口必须区分 public dashboard validation 与 targetValidation quick verify：`monitor.pikapython.com` root/CSS/JS 200 只证明公开入口和静态 dashboard 资源可用；quick verify 的 `observe command`、采样样本、analyze report 和 red finding 仍是业务恢复判定的一部分。若 quick verify 因 `observe-command-newSession-failed`、`no-samples` 或等价采样器控制失败而 blocked，P6 issue 必须保持未关闭或显式拆出后续 blocker，不得只凭 public dashboard 200 关闭。 -P8 哨兵恢复执行 issue 为 [#971](https://github.com/pikasTech/unidesk/issues/971)。P8 closeout 必须回写：SPEC P8 引用、120s warning 证据、`quick-verify-no-business-turn` 或等价业务触达证据、`browser-timeout` 分类修正、中文运维页面验证、`monitor.pikapython.com` 公网入口验证、k3s 内部 Service DNS quick verify 路径、D601/v03 用户入口 smoke 结果，以及仍未解除的真实业务 blocker 是否已单独拆出。 +P8 哨兵恢复执行 issue 为 [#971](https://github.com/pikasTech/unidesk/issues/971)。P8 closeout 必须回写：SPEC P8 引用、YAML wait-budget warning 证据、`quick-verify-no-business-turn` 或等价业务触达证据、`browser-timeout` 分类修正、中文运维页面验证、`monitor.pikapython.com` 公网入口验证、k3s 内部 Service DNS quick verify 路径、D601/v03 用户入口 smoke 结果，以及仍未解除的真实业务 blocker 是否已单独拆出。 P8-P8 起，targetValidation 的 availability blocker 与 Workbench timing 架构治理必须分层。若同一 trace 在 terminal 前最后一帧仍为 running，随后 terminal commit 的 sealed `durationMs` 把可见 `totalElapsed` 小幅校正到更短值，且 drop 不超过 YAML `turnTimingSampleSlackSeconds`、final response 与完成行均已可见，则该现象作为 terminal-boundary timing correction 证据保留，不生成 `turn-timing-total-elapsed-decrease` red blocker。归零、running/running 下降、terminal 后增长、完成耗时与卡片耗时超出 slack、trace 乱序和完成行非最后仍保持 red；根因治理继续归 [HWLAB #2055](https://github.com/pikasTech/HWLAB/issues/2055) 和 [HWLAB #2125](https://github.com/pikasTech/HWLAB/issues/2125)，不得在 UI、CLI renderer 或 analyzer 中做读侧 repair。 @@ -735,6 +739,6 @@ P12 cadence 调度和 monitor-web 交互修复执行 issue 为 [#1123](https://g P13 D518 多 runner 强边界与 OTel 根因收敛执行 issue 为 [#1206](https://github.com/pikasTech/unidesk/issues/1206)。P13 closeout 必须回写：SPEC P13 引用、[#1208](https://github.com/pikasTech/unidesk/issues/1208)-[#1216](https://github.com/pikasTech/unidesk/issues/1216) 阶段状态、D518 双 sentinel 独立 Deployment/Service/PVC/CronJob/GitOps/Argo/public route 证据、route/API sentinelId 强断言、report/index 不串线证据、dashboard verify/screenshot localPath/SHA、k3s CronJob 调度证据、latest selected run 与 historical trend 状态分层证据、以及 OTel AgentRun namespace/trace gap 是否已解除或拆入后续 issue。 -P14 Web 哨兵 CI/CD 可见性执行 issue 为 [#1285](https://github.com/pikasTech/unidesk/issues/1285)。P14 closeout 必须回写：SPEC P14 引用、source commit、PR/merge commit、JD01/v03 `jd01-web-probe-sentinel` publish job、digest、GitOps revision、git mirror flush 状态、Argo/runtime observed alignment、`validate`、dashboard screenshot、latest report，以及超过 120s 时的结构化阶段归因和可续跑命令。 +P14 Web 哨兵 CI/CD 可见性执行 issue 为 [#1285](https://github.com/pikasTech/unidesk/issues/1285)。P14 closeout 必须回写：SPEC P14 引用、source commit、PR/merge commit、JD01/v03 `jd01-web-probe-sentinel` publish job、digest、GitOps revision、git mirror flush 状态、Argo/runtime observed alignment、`validate`、dashboard screenshot、latest report，以及超过 YAML 等待预算时的结构化阶段归因和可续跑命令。 P15 Cadence 调度稳定性与 OTel 覆盖执行 issue 为 [#1372](https://github.com/pikasTech/unidesk/issues/1372)。P15 closeout 必须回写：SPEC P15 引用、[#1374](https://github.com/pikasTech/unidesk/issues/1374)-[#1378](https://github.com/pikasTech/unidesk/issues/1378) 阶段状态、JD01/v03 `jd01-web-probe-sentinel` CronJob manifest/GitOps/Argo/runtime observed 证据、`sentinel-cadence-cronjob-missing` 防回归状态、monitor-web cadence/OTel coverage 显示、OTel trace search 或 instrumentation-gap 证据、受控 rollout/publish job、GitOps revision、source commit、dashboard/health 验收，以及 CI/CD 门禁仍只验证 `/health` 的证据。