Skip to content

[PR] fix(dsh): make unresolvable client-build detection explicit instead of silent - #5309

Open
ranxianglei wants to merge 1 commit into
masterfrom
2026-11-01_dsh-asar-build-note-explicit-unknown
Open

[PR] fix(dsh): make unresolvable client-build detection explicit instead of silent#5309
ranxianglei wants to merge 1 commit into
masterfrom
2026-11-01_dsh-asar-build-note-explicit-unknown

Conversation

@ranxianglei

@ranxianglei ranxianglei commented Oct 31, 2026

Copy link
Copy Markdown
Owner

Closes #5302

What

The newer-than-tested client-build soft warning (#4545) structurally NEVER fires on DSH desktop (app.asar layout): walkUpNodeModuleVersion cannot see the host package bundled inside app.asar, so found === undefined returned null by design ("absence of evidence ≠ broken build"). The safety net was silently dead exactly where it matters most.

This implements option C from the issue (minimal, zero layout assumptions): an UNRESOLVED version with the check enabled now emits ONE explicit bilingual boot note — "Could not detect the running @deepseek-ai/dsh version in this install layout … the newer-than-tested build check is INACTIVE here … set BILI_DSH_MAX_TESTED_VERSION="" to silence" — instead of staying silent. UNPARSEABLE versions keep failing open to silence; the two failure modes are now distinguished and documented everywhere. The knob silences everything, including the new note.

Behavior change (disclosed old → new)

  • OLD: undetectable host build (desktop asar; any >8-hop nesting) → total silence, no log line at all.
  • NEW: undetectable + check enabled → ONE warn-level boot note per process (bili.log [native-client] record + console banner). Web/profile layouts unaffected (the version resolves there); knob-off users stay fully silent; still soft by design — never gates or blocks traffic.

Config surface

NONE. No new key/env var/flag — the existing BILI_DSH_MAX_TESTED_VERSION is merely referenced inside the note text as the escape hatch.

Tests

tests/client-build-note.test.ts: the two pins encoding the old contract updated; bidirectional gates added (#3617): unresolvable + check-on → explicit note (lane label, npm id, EN/CN content, escape-hatch knob named, NOT the strictly-newer string); knob off (empty / whitespace) → null; explicitly raised cap → same unknown outcome; emit-channel test asserts both firing directions plus knob-off suppression in BOTH directions. Local: targeted suite 10/10 green, full typecheck clean. Docs: seed (website/config-reference/env-only.yaml) updated and artifacts regenerated with tools/gen-config-docs.mjs generate (no drift); LIFECYCLE.md ledger row updated.

Checklist items awaiting owner input (managed inside #5302, non-blocking)

  • A. host self-reported version first — if the desktop host exposes a version read-out (env / registration surface / webserver endpoint), probe order becomes "host self-report > node_modules walk-up". Needs confirmation of what the host actually exposes.
  • B. asar path candidates — add asar-layout candidate paths to the resolver; depends on asar layout details, brittle.

@ranxianglei ranxianglei changed the title fix(dsh): make unresolvable client-build detection explicit instead of silent [PR] fix(dsh): make unresolvable client-build detection explicit instead of silent Oct 31, 2026
@ranxianglei ranxianglei mentioned this pull request Oct 31, 2026
Open
This was referenced Oct 31, 2026
Closed
Closed
Open
@ranxianglei

ranxianglei commented Oct 31, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重:不重复。 这是 #4545(「高于已测版本」软提示,已合入 master)的后续修复——修的是该特性在 DSH 桌面版(asar 布局)结构性哑火的缺口;无并列 PR/issue 实现同样的「显式 unknown」提示。

标签(拟): bug / dsh / scope/wiring / p3 —— 缺陷类;dsh native lane 启动诊断可见性;边缘可观测性瑕疵(不影响压缩功能本身)。

结构化八问

  1. 是什么问题:[PR] dsh lane: note in-session when running an unverified @deepseek-ai/dsh client build (soft, exact-match) #4545 的「高于已测版本」软提示在 DSH 桌面版(app.asar)上结构性永不触发——walkUpNodeModuleVersion 看不到打进 app.asar 的宿主包,found === undefined 按旧契约返回 null(静默)。安全网在最需要处悄悄失效。本 PR 让「读不到 + 检查开着」发一条显式「未能检测到」的双语启动提示。
  2. 什么原因导致的:旧代码把「读不到(unresolved)」与「解析不了(unparseable)」都归入「证据缺失 ≠ 坏构建」统一静默;但 asar 布局下「读不到」是常态,检查遂永久哑火。修法区分两态:unparseable 仍 fail-open 静默,unresolved 显式声明「检查本机不生效」。
  3. 影响范围与严重程度:仅 dsh native lane 启动诊断面。触发条件 = dsh 桌面版(asar)或 >8 跳嵌套导致读不到宿主包、且未关检查(默认开)。p3 体验/可观测性瑕疵:压缩不受影响(本就软提示、从不拦流量),只是静默→一条 warn;web/profile 布局能解析到版本、行为不变;knob-off 用户仍完全静默。
  4. 怎么修复的:newerClientBuildMessage 判定顺序改为 knob-off(cap === undefined → null,最高优先,连新提示一并闭嘴)→ found === undefined(检查仍开 → 显式 unknown 提示)→ semver 比较。调用点 src/agent/dsh-native.ts 仅改 catch 注释(throwing 才静默,unresolvable 已在 composer 出提示)。纯 composer 层、零布局假设(选项 C)。
  5. 是否有回归问题:审过既有四态——knob-off→null、at/below-cap→null、unparseable→null、strictly-newer→告警,全部不变;唯一增量即披露那条(unresolved + check-on:静默→warn)。无高危模式:不动 wire/消息形状、不动阈值(cap 仍 0.2.0-rc.2)、不动时序(boot 一次性,dshNewerBuildNoted latch 保证每进程一次);fail-open 保留(catch 仍吞 throwing)。CI e2e dsh-native 宿主为 npm 安装、resolver 能读到版本,走原 strictly-newer / at-cap 路径,e2e 行为不变。
  6. 是否破坏缓存:不涉及(纯启动日志/横幅,不碰 prefix cache / 重试 / 增量游标 / 去重键)。
  7. 是否改了设计方向:不涉及架构转向;仍在 [PR] dsh lane: note in-session when running an unverified @deepseek-ai/dsh client build (soft, exact-match) #4545 既定「lane-generic 软提示」框架内。根治方向(选项 A 宿主自报版本 / B asar 候选路径)已列为待 owner 拍板、非阻塞,留 dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302 管理。
  8. 是否引入了新的配置:不涉及。复用现有 BILI_DSH_MAX_TESTED_VERSION,仅在提示文案中作逃生口引用;CONFIGURATION.md(en/zh)+ LIFECYCLE.md + website/config-reference/env-only.yaml seed 均以同一措辞同步更新该既有键的子行为(CI 的 docs-sync / lifecycle-ledger-guard / config-surface-guard 兜底 drift)。

证据

合并前需处理的非代码项

  1. “Closes dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302” 指向存疑:dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302 是「代理半死不活」大簇跟踪单(watchdog / 静默直连 / wedge / 端口),与本 PR 修的 client-build 提示可见性(源自 [PR] dsh lane: note in-session when running an unverified @deepseek-ai/dsh client build (soft, exact-match) #4545)不是同一机制域;且正文又称 A/B「managed inside dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302」,与「Closes dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302」自相矛盾。建议改为正确的源 issue,或至少降为 Related: #5302,避免误关整个大簇(需作者确认当初列 A/B/C 的具体是哪个 issue)。
  2. behind master(mergeable_state=behind):合并前需 sync/rebase 到当前 master。改动面(client-build-note.ts + dsh-native.ts 注释 + docs/tests)均非近期热点文件,冲突风险低,但按评审规范应先对齐再宣称可合。
  3. CI 全 queued(22 项 pending、无一完成):最终绿以 CI 为准;本地仅定向跑了上述文件作证据,未代跑全量(那是 CI 职责)。

判定:代码 merits 上可合——逻辑正确、改动最小、双向测试与文档到位、无披露外回归;待上面三项(尤其第 1 项的 issue 关联纠偏)清理后由 owner 合并。

@github-actions

github-actions Bot commented Oct 31, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

📦 Built Package Artifact

Branch: 2026-11-01_dsh-asar-build-note-explicit-unknown (e61c54f)

Latest build — install this exact version

npm install -g billion-context@0.0.9076-pr.5309.4da48d0

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Recent builds (commit → version)

commit version build
e61c54f billion-context@0.0.9076-pr.5309.4da48d0 build
6566c7c billion-context@0.0.7434-pr.5309.708dc60 build

Download artifact

  1. Download the artifact from the Actions run
  2. Extract the tarball and install:
tar xzf billion-context-pr5309.tgz
npm install -g package

Install instructions are refreshed on each push.

@ranxianglei
ranxianglei force-pushed the 2026-11-01_dsh-asar-build-note-explicit-unknown branch from 6566c7c to e61c54f Compare November 11, 2026 05:36
@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

Conflict resolved — PR rebased onto current master.

查重: 不适用（本次为既有 PR 的冲突修复运行，未新立项）。

What happened:

Verification (targeted, local — full-suite verdict belongs to remote CI on the pushed head):

  • tests/client-build-note.test.ts: 10/10 pass
  • npm run typecheck: clean
  • scripts/config-surface-guard.mjs: OK · tools/gen-config-docs.mjs check-coverage: OK (regeneration idempotent — zero residual diff)
  • scripts/lifecycle-ledger-guard.mjs: OK locally (this job was red in the stale cached run against the old head; expected to pass on the new one)

Behavior-change flag (the rebase adds nothing beyond landing the PR's own intent): unresolvable dsh client builds now emit ONE explicit "could not detect" boot note instead of staying silent (old: silent → new: explicit note; BILI_DSH_MAX_TESTED_VERSION="" silences it). The doc relocation (root stubs vs docs/) is structural only — no user-facing change.

— 八问 —

  1. 是什么问题：PR 分支落后 master 约 1190 个提交，GitHub 报 dirty 合并冲突；冲突根因是文档重组（[PR] docs: batch-migrate 14 root-level documents into docs/ (consolidation + master index + redirect placeholders) | docs: 14 个根级文档一次性迁入 docs/（集中 + 总目录 + 重定向占位） #5920）后 PR 修改的三个根目录文件变成了重定向桩，且 env-only.yaml 在 PR 改动行旁边插入了新条目。
  2. 什么原因导致的：分支与 master 的时间漂移（分支自 2026-11-01 停放至今），非代码缺陷；冲突面纯文本/位置性。
  3. 影响范围与严重程度：仅影响本 PR 的可合并性（PR 本就 open 未合），无用户面影响。
  4. 怎么修复的：单提交 rebase 到最新 master；PR 的文档改动按重组后的惯例迁到 docs/ 对应位置，生成式表格由 yaml 种子重新生成，yaml 冲突取并集保留双方内容。
  5. 是否有回归问题：rebase 本身零行为变更。逐项核对：三个源文件的自动合并区域在 master 侧无语义改动；定向测试 10/10、typecheck、config-surface-guard、gen-config-docs coverage、lifecycle-ledger-guard 本地全绿。PR 自身的有意行为变更（静默→显式提示）按设计保留并已在上文标记旧值→新值。
  6. 是否破坏缓存：不涉及（未触碰任何缓存/重试/游标/去重键逻辑）。
  7. 是否改了设计方向：不涉及（纯落地操作，让分支跟上 master 现行结构）。
  8. 是否引入了新的配置：不涉及（无新增 env/config 键；BILI_DSH_MAX_TESTED_VERSION 语义不变）。

判定：冲突已清除，PR 现为 mergeable（blocked = 等新 head 的 CI 与评审）；若新 head CI 再红，由本 lane 下一轮跟进。

@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

Conflict-fix run COMPLETE (auto-fix lane attempt 1/3) — confirming outcome; full detail in my previous comment above.

— 八问（简版）—

  1. 是什么问题：PR 分支落后 master ~1190 提交导致 dirty 合并冲突（文档重组后根目录文件变桩 + yaml 相邻插入）。
  2. 什么原因导致的：分支自 2026-11-01 停放至今的时间漂移，非代码缺陷。
  3. 影响范围与严重程度：仅本 PR 可合并性，无用户面影响。
  4. 怎么修复的：单提交 rebase 到最新 master；文档改动迁移到 docs/ 新址并重新生成；yaml 取并集。
  5. 是否有回归问题：rebase 零行为变更；定向测试/typecheck/守卫脚本本地全绿；PR 自身有意变更（静默→显式提示）按设计保留并已标记。
  6. 是否破坏缓存：不涉及。
  7. 是否改了设计方向：不涉及。
  8. 是否引入了新的配置：不涉及。

判定：冲突已清除、已推送、已验证（定向级）；剩余风险仅为新 head 的全量 CI 结果——若红，由本 lane 下一轮跟进。

@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

No action needed this run — the blocker is already resolved; verified against LIVE sources just now.

This forward appears to have been generated from the pre-rebase dirty state. Everything checked live in this run:

  • Merge state (live GitHub API): head e61c54f9, mergeable=true, mergeable_state=blocked — NOT dirty. The conflict from my earlier run is gone.
  • Branch position: merge-base of the PR branch and master IS the current master tip (e3220adc0f) — the PR is 0 commits behind, 1 ahead (its own fix commit). Structurally un-conflict-able at this moment; origin/ci-fixes also equals master tip (nothing to sentinel-merge).
  • CI (mirror cache, fetched 2026-11-11 06:40 UTC, sha e61c54f9): 30 checks — 17 success, 13 skipped (gated e2e lanes), 0 failed, 0 pending. Full suite green on the rebased head.
  • No push made this run (nothing to integrate; remote head still equals what I pushed last run, no concurrent agent activity observed).

So: conflicts resolved (previous run), CI green (verified now), PR waiting only on review/merge. If a future run sees a NEW dirty state or red check on a newer head, that will be fresh work — this one is clean.

— 八问（简版）—

  1. 是什么问题：本次收到的「冲突」告警为陈旧触发——基于 rebase 前的 dirty 状态生成。
  2. 什么原因导致的：告警生成时点早于上一轮 rebase+push 生效，非新的分支漂移。
  3. 影响范围与严重程度：无实际影响；PR 当前可合并（blocked = 等评审，非冲突）。
  4. 怎么修复的：本轮无需修复——只做了活体核验（GitHub API mergeable 状态、merge-base 位置、镜像缓存 CI 结论）。
  5. 是否有回归问题：不涉及（零改动、零推送）。
  6. 是否破坏缓存：不涉及。
  7. 是否改了设计方向：不涉及。
  8. 是否引入了新的配置：不涉及。

判定：本轮空转收工；PR #5309 现状 = 无冲突 + CI 全绿，仅待人工评审/合并。

@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

(ai: vllm-qwen/qwen3.8-27b)

Review verdict: APPROVE (posted as a comment — GitHub rejects a formal APPROVE on the author's own PR) — independent end-to-end review of the rebased head e61c54f9 (single commit, 7 files).

Correctness. The fix does what it claims: newerClientBuildMessage now checks knob-off first (cap === undefined → null, so BILI_DSH_MAX_TESTED_VERSION="" silences everything including the new note — precedence correct), then emits an explicit bilingual "could not detect" boot note when the version walk-up cannot resolve the host package (desktop app.asar / >8-hop nesting), and only then runs the unchanged strictly-newer comparison. Verified the tri-state knob semantics (src/agent/client-build-note.ts:45-50) and the once-per-process latch (src/agent/dsh-native.ts:2801). The catch-comment update (src/agent/dsh-native.ts:2806) correctly distinguishes a THROWING layout (degrades to silence) from an unresolvable one (already gets the explicit note).

Regression walk (existing behaviors, read pre-change code):

  • knob-off → null: unchanged ✓
  • resolved version at/below cap → null: unchanged ✓ (pinned by decision-table test)
  • resolved version strictly newer → warning note: unchanged ✓
  • unparseable found/cap → fail-open null: unchanged ✓ (pinned)
  • throwing resolver → catch-silent: unchanged ✓
  • ONLY delta = unresolved + check-on: total silence → ONE warn-level boot note per process — disclosed old→new in the PR body ✓

No wire/message-shape, threshold, timing, or cache/retry/cursor impact; boot diagnostic only, both compression modes N/A. Sole consumer in src/ is dsh-native.ts; nothing outside the module parses the note lines.

Tests. Real teeth, bidirectional gates per #3617: the new test pins msg≠null + content substrings ([dsh], package name, "Could not detect", the knob env, CN half) plus a negative assert against the other note's string; knob-off ""/whitespace → null; raised cap leaves the message invariant; the emit-channel test asserts firing AND suppression in BOTH directions with persistent bili.log records. Re-ran locally at head: node --import tsx --test tests/client-build-note.test.ts → 10/10 pass. Full CI suite green at this exact head (30 checks, 0 failed, via mirror cache).

Docs / config surface. tools/gen-config-docs.mjs generate at head → clean tree (regeneration idempotent, zero drift as claimed); check-coverage OK; config-surface-guard + lifecycle-ledger-guard pass; en/zh parity in docs/configuration(.zh-CN).md and the website yaml seed. No config surface changed — the existing BILI_DSH_MAX_TESTED_VERSION is merely referenced in the note text.

Closes reference (resolves the earlier thread concern). GitHub issue #5302 IS the dsh-asar detection issue ("dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar") — Closes #5302 is correct. The earlier doubt came from reading the INTERNAL e-work mirror #5302 (a different thread: the proxy-half-dead cluster tracker) — an identity-pinning mixup, not a PR defect. One owner note: merging auto-closes #5302 while its A/B options are still awaiting input — non-blocking, your call at merge time.

House conventions. Single commit, fix: convention, no version bump off a release branch, no kernel/ or pi-subagents/ touch, no kernel-change declaration (so no human-tier gate applies). Branch sits a few commits behind the current master tip (live API: mergeable=true, no conflicts) — BEHIND is not a blocker per house rules; CI is already green at this exact head.

八问（中文结构化结论）

  1. 是什么问题：dsh 桌面版（app.asar 打包布局）里 bili 找不到宿主 @deepseek-ai/dsh 的版本号，「比已测版本新」的警告永远静默——用户以为检查在跑，实际完全没跑。
  2. 什么原因导致的：版本探测只做 node_modules 向上查找（≤8 跳），asar 内的包不在该路径上；旧代码把「查不到」（found===undefined）与「没有更新」混为一谈，一律返回 null 静默。
  3. 影响范围与严重程度：仅 dsh 桌面打包布局（及 >8 跳深嵌套）且开着检查的用户；web/profile 布局不受影响（版本可正常解析）。纯可观测性缺陷——检查在这些布局本就不生效，现在只是把「不生效」说出来了；不 gate 流量、不进任何请求路径。p3。
  4. 怎么修复的：composer 内先判 knob 关（全静默优先），再对 found===undefined 发一条一次性 warn 级双语启动说明（检测不到 → 检查在此布局不生效 → 置空 knob 可静默），严格更新的比较逻辑原样不动；调用点 catch 注释同步区分「抛错=静默降级」与「查不到=已有显式说明」两条路径。
  5. 是否有回归问题：逐条清点既有行为——knob 关→null、版本≤上限→null、>上限→提示、found/cap 不可解析→fail-open null、resolver 抛错→catch 静默，全部保持不变且有测试钉住；唯一增量即 PR 正文已披露的「查不到+开检查：静默→一条 warn 启动说明」。无 wire/消息形状、阈值、时序、缓存/重试/游标影响；两种压缩模式均不涉及（纯启动诊断）。
  6. 是否破坏缓存：不涉及（未触碰任何缓存/重试/去重键逻辑）。
  7. 是否改了设计方向：不涉及——仍是软性启动诊断，模块保持 lane-generic，未改架构/边界/数据流。
  8. 是否引入了新的配置：无新增配置面——仅引用既有 BILI_DSH_MAX_TESTED_VERSION，其「置空=全部静默」语义不变（现同样覆盖新说明）。

判定：可合并。 代码正确、最小、测试有牙（本地 10/10 + CI 全绿）、文档再生成幂等零漂移、行为变更已按规范披露旧值→新值。本轮未发现需顺手修的小问题。A/B 方案跟踪在 #5302，合并将自动关闭该 issue——由 owner 定夺。

@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

Review lane done (review-worker-r1). PR #5309 head e61c54f: verdict APPROVE — posted on GitHub as a comment (formal APPROVE blocked: PAT == PR author, GitHub rejects self-approval) → #5309 (comment). Independent end-to-end pass: correctness verified at src/agent/client-build-note.ts:45-50 + dsh-native.ts:2801; full regression walk (knob-off/at-cap/newer/unparseable/throwing paths all unchanged, only delta = disclosed silent→warn for unresolvable+on); tests have teeth, re-run locally 10/10 + CI green at this head (30 checks); docs regeneration idempotent zero-drift + both guards green; Closes #5302 verified CORRECT (GitHub #5302 = the dsh-asar issue; earlier doubt was an internal-mirror #5302 identity mixup). No small findings to fix. Branch behind-master only (mergeable=true, no conflicts) — ready for owner merge. Note for owner: merge auto-closes #5302 whose A/B options still await input.

@ranxianglei

ranxianglei commented Nov 11, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

CI-engineer hand-off: all mechanical blockers cleared — PR is merge-ready, only the human merge step remains.

Status of every gate, verified live this run:

  • Conflict: resolved — head e61c54f9 sits directly on master tip e3220adc0f (merge-base = master tip, 0 behind); mergeable=true.
  • CI: fully green on exactly this head — mirror cache (fetched 2026-11-11 06:40 UTC): 30 checks, 17 success / 13 skipped (gated e2e lanes) / 0 failed.
  • Review: APPROVE (verdict above) on the same head e61c54f9 — regression walk, test teeth, docs/config-surface idempotency all confirmed independently.
  • No residual work for this lane — nothing to rebase, nothing red to fix, no decision pending on the CI side.

One merge-time note carried over from the review (owner's call, non-blocking): merging will auto-close #5302 (Closes #5302 in the PR body) while its A/B root-cause options are still awaiting input. The reviewer verified the reference is correct — the earlier doubt was an internal-mirror number mixup, not a PR defect. If you'd rather keep #5302 open until A/B lands, that's a one-line PR-body edit before merge; otherwise the auto-close stands.

Merge when ready: #5309 (human-only step — I can't merge PRs).

— 八问（简版）—

  1. 是什么问题：本轮无新问题——收到评审 APPROVE，做合并前状态清点与交接。
  2. 什么原因导致的：不涉及（非缺陷轮次）。
  3. 影响范围与严重程度：PR 已具备全部合并条件；唯一遗留是合并将自动关闭 dsh desktop: newer-than-tested build warning never fires because version lookup cannot see packages inside app.asar | DSH 桌面版：「高于已测版本」告警永不触发（版本探测看不到 app.asar 内的宿主包） #5302（A/B 方案未决），属 owner 合并时点决策。
  4. 怎么修复的：无修复动作；冲突（上轮 rebase）与红项（无）均已了结。
  5. 是否有回归问题：不涉及——本轮零改动、零推送；回归审查已由独立评审完成并逐条通过。
  6. 是否破坏缓存：不涉及。
  7. 是否改了设计方向：不涉及。
  8. 是否引入了新的配置：不涉及。

判定：CI 侧收工；球在 owner 脚下——合并即闭环（或先决定 #5302 去留）。

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

1 participant

@ranxianglei