[Withdrawn / Closed] Slash-menu pending candidate timing — E2E sampling race, no confirmed DSH 0.2 bug

[ysr666]

RETRACTED / 已撤回（2026-10-10） — This discussion was opened prematurely. DSH intentionally hides suggestion rows while an async candidate source is pending; our previous test made two separate observations across a refresh and incorrectly treated the transient state as a current DSH defect. The corrected keyboard-only real-browser E2E passed 12/12 independent DSH 0.2.0-rc.2 profiles and 12/12 independent DSH 0.2.1-alpha.2 profiles. We have not established a reproducible current DSH product bug. The earlier raw failures remain in this discussion for transparency but should not trigger maintainer work. Closing this report as withdrawn; any future failure must be refiled only with a ready/highlighted pre-Enter state and a proven failed command claim. We apologize for the premature report.

---

Verified current-release correction — October 10, 2026

DSH 0.2.1-alpha.2 (npm alpha) DOES reproduce the keyboard failure. Tested on the officially installed alpha with five independent freshly installed disposable Web DSH_HOME profiles and real Chrome: 3/5 complete keyboard-only /union Composer→Host→sidebar E2Es PASSED; 2/5 FAILED before any Host command RPC. Both alpha failures had the same bounded redacted state:

{"preEnterKeyboardState":{"phase":"plain","focused":true,"menuMounted":true,"optionCount":0,"highlightedCount":0,"rootInert":false},"afterEnter":{"phase":"plain","editable":"true","composing":false,"focused":false,"menuOptions":0,"menus":0,"rootInert":false}}

DSH 0.2.0-rc.2 (npm latest): 5/5 independent fresh-profile keyboard-only full E2Es PASSED; the failure was NOT reproduced in this sample. This is evidence of a version difference, not proof that the stable candidate can never exhibit the race. Each test used actual per-character /union typing, ArrowDown and keyboard Enter to select the real suggestion, verified the official Lexical claimed state, and submitted commands using keyboard Enter; no pointer selection, direct Host RPC, automatic retries, model credentials or real task blocking. Tests execute the full suite of native union commands when a menu selection succeeds.

The original detailed report below describes historical 0.1.7-rc.2 reproductions. Please prioritize the confirmed 0.2.1-alpha.2 failure; the discussion was originally submitted before we completed current-version testing, and its version scope has now been corrected. The pending Enter-consumption behavior is deliberate and already unit-tested upstream to keep the menu open; a separate menu-close-before-stale-span-CAS failure is plausible but still unconfirmed. See the source-level follow-up in this discussion.

---

Summary / 问题概述

In @deepseek-ai/dsh 0.1.7-rc.2, the Web Composer's native / command menu sometimes consumes a keyboard Enter while a previously highlighted suggestion is refreshing. The menu disappears, but Lexical does not enter data-phase="claimed". The next Enter therefore cannot submit that command. This is reproducible before any command Host RPC; please do not classify it as an Agent/Host refusal.

在 DSH 0.1.7-rc.2 的 Web Composer 中，斜杠建议菜单刷新期间，键盘 Enter 偶尔被消费但未成功认领命令；菜单消失、输入框仍为 phase=plain，因而不会发出后续预期的命令 RPC。这不等于 Host 拒绝执行。

Environment

• Official @deepseek-ai/dsh@0.1.7-rc.2, macOS ARM64, Node 24.5, headless Google Chrome.
• Real official Composer, fresh disposable DSH_HOME profiles; a third-party /union DSH command was installed from a local plugin tarball with the official dsh plugin --profile web add workflow.
• Blank model credentials; off-loopback browser network requests blocked; no real model task or real task blocking.
• Reproduced via genuine keyboard ArrowDown + Enter and separately by real per-character typing; using mouse selection of the same official suggestion is more stable. This is a shared DSH menu/keyboard state issue, not a report that /union production command handler rejected any request.

Reproduction and actual measurements

1. In a new real DSH conversation Composer, type /union.
2. Wait for the exact official suggestion and a visible [data-trigger-menu] [role=option] candidate; use ArrowDown to highlight the correct option (aria-selected=true).
3. Press Enter to select the command; verify that the real Composer [data-composer-input] transitions to data-phase="claimed" before typing arguments. Sometimes this never happens, although the slash menu disappears.
4. In some cases, a previously visible command description is followed by a native menu shell with Chinese section headings “指令” / “技能” but zero role=option rows: candidate readiness is asynchronous.

Redacted state captured after one unsuccessful Enter selection:

{"phase":"plain","editable":"true","composing":false,"focused":true,"menuOptions":0,"menus":0,"rootInert":false}

Independent disposable-profile samples (small samples, all failures retained):

Test path	Passed	Failed
Original keyboard Enter selection, no explicit claim check	2	1 (missing first command RPC response)
Enter selection + assert Lexical claimed	1	1 (pre-RPC phase=plain)
Wait for real option, ArrowDown to selected /union, Enter	2	1 (pre-RPC phase=plain)
Real per-character keyboard typing, same menu selection	0	1 (candidate rows disappeared before selection)
Official suggestion selected by pointer, then single Enter submission	4	0 (full 24-command flows)

One additional opt-in keyboard-only run passed. The intermittent keyboard-specific problem is NOT fixed; pointer runs do not qualify accessibility.

Source-level lead (hypothesis, not asserted unique root cause)

In the installed @deepseek-ai/dsh-client-ui-input-trigger implementation, InputTriggerController.arbitrate("enter", composing) handles the highlighted candidate's group as follows:

• highlight === null: "pass".
• Highlight exists, but its group status !== "ready": "consumed" with no pick.
• Ready group: this.pick(...), then "pick-highlighted".

menuReduce may transition ready groups back to pending during a refresh while retaining the highlight; the DSH conversation Lexical key handler prevents default Enter for consumed arbitration. This is consistent with the observed silent loss, but a stale-span guard or another race may also contribute. Please instrument both state transitions and the result of slash/input-begin-command before declaring a unique root cause.

Acceptance criteria

• Repeated keyboard-only slash menu tests covering candidate ready → pending → ready, session initialization, Enter and Tab, and real IME composition.
• Never silently lose an Enter. If the candidate is pending/stale, preserve focus and visibly indicate that it was not selected, with a clear way for the user to explicitly select it again. Never auto-replay an uncertain command.
• Preserve no-double-submit, attachment refusal and session identity boundaries, and verify actual Host command admission separately.
• Repeat with manual VoiceOver / NVDA; pointer-driven Playwright tests are not screen-reader certification.

Full reproducible harness and evidence

• Agent Picket local tracking: Investigation: DSH slash-menu pending readiness vs keyboard command claim (0.2 corrected E2E 12/12 each) ysr666/agent-picket#62
• Standalone investigation report: https://github.com/ysr666/agent-picket/blob/test/65-dsh-keyboard-enter-upstream-gate-20261010/docs/DSH_017_KEYBOARD_ENTER_UPSTREAM_REPRO.md
• Opt-in keyboard-only real browser regression: https://github.com/ysr666/agent-picket/blob/test/65-dsh-keyboard-enter-upstream-gate-20261010/tests/dsh-union-composer-sidebar.real.test.ts — run with PICKET_RUN_DSH_KEYBOARD_E2E=1 and isolated DSH/Chrome installation env vars documented in the report. This test never injects a command RPC or retries a potentially submitted user command.
• Normal pointer-picked Composer→Host→sidebar integration is a separate test, not a workaround claimed to fix keyboard selection.

Please let us know if you would prefer a smaller DSH-only regression fixture or have a newer nightly version in which keyboard arbitration has changed. No upstream source or existing user profile was modified while reproducing.

[ysr666]

Follow-up: checked current master, two distinct failure branches (2026-10-10)

I additionally checked the upstream master at d743267388641bc76f17c45ce8b4c231aed1d32c, where packages/client/ui-input-trigger/package.json reports 0.2.1-alpha.2. This is source review only, not a tested runtime reproduction on 0.2.x.

There is an important distinction that narrows the original hypothesis:

1. Pending candidate: src/client/controller.ts lines 287–295 intentionally return consumed when a highlighted group is pending. In tests/service.client.spec.ts around line 1080, upstream already has a regression asserting no pick, no submit fallthrough, and the menu stays open. In other words, pending consumption alone does not explain our observed case in which the menu closes while Lexical stays plain.
2. Potential refused claim after menu close: src/client/controller.ts around settle (lines 562–593) calls reduce({type:'close'}) before execute(outcome, hit.span). It explicitly notes that a refused edit (stale draft revision/unmappable span) mutates nothing; execute returns false. In the installed 0.1.7 conversation input, beginCommand requires span.draftRev === this.rev, leading position, successful text replacement, then transitions to claimed. This second path is strongly consistent with “menu closed, phase=plain”, but it remains a hypothesis until we capture whether slash/input-begin-command actually returned false for that run.

Suggested decisive upstream test: seed a ready highlighted slash candidate; advance the editor draft revision after its span is captured but before Enter/pick; invoke real keyboard arbitration and assert whether the menu is dismissed without any claim or visible failure notice. In parallel, test pending-group Enter to confirm that that branch keeps the menu open, as existing unit tests already require. Please preserve stale-span CAS and never auto-execute a pending command as a workaround.

The existing opt-in real-browser keyboard repro, source report and per-profile pass/fail data remain linked in the opening post. This follow-up corrects the overly broad inference that the pending-group branch by itself explains all failures.

[ysr666]

Updated current-version matrix — 2026-10-10

A second independently installed four-profile-per-version real keyboard Chrome matrix, with the unrelated official Preview Notice startup blocker resolved, has now reproduced a pre-Enter candidate-list failure on BOTH current npm tags:

• DSH 0.2.0-rc.2 (npm latest): 3/4 PASS; 1/4 FAIL. The /union suggestion was visible, but the option list returned 0 real role=option entries when keyboard navigation proceeded, failing the bounded native candidate assertion before any Host command RPC.
• DSH 0.2.1-alpha.2 (npm alpha): 3/4 PASS; 1/4 FAIL on the same pre-Enter candidate disappearance. This is in addition to the earlier alpha set 3/5 PASS; 2/5 FAIL after Enter with the command still phase=plain.

Important correction: the earlier 0.2.0-rc.2 5/5 PASS sample was factual, but it no longer supports a claim that the issue has not been reproduced on npm latest. Both current tags show an intermittent UI state issue in the expanded matrix. The two failure modes (candidate disappears before Enter vs command not claimed after Enter) may share a source but must not be asserted identical without evidence.

Each test used a newly created isolated DSH_HOME, the official DSH tarball install, actual typed Composer /union, native keyboard-only ArrowDown/Enter selection, and real Host RPC only if command was successfully claimed. No mouse fallback, no command replay, no external browser network or real Agent task. Failures occurred before command submission. The default CI does not run these real-host tests.

A reproducible experimental matrix runner is being integrated into Agent Picket, with nonzero exit on any failing profile. The underlying DSH input-trigger candidate-refresh and menu-close-before-stale-claim-CAS paths require upstream investigation. Existing pending-Enter unit coverage alone cannot explain every observed case.

[ysr666]

Correction after checking DSH MenuView and fixing the keyboard E2E (2026-10-10)

Please do not interpret our earlier pre-Enter zero-option assertion as a confirmed DSH bug on either current release. After inspecting the actual DSH packages/client/ui-input-trigger/src/client/MenuView.tsx, we found that the menu deliberately renders a loading indicator and no role=option rows while a group is pending. The prior E2E first waited for the visible suggestion and then separately called options.count(). A normal asynchronous refresh in between those reads could yield zero options before Enter, causing an overly strict test assertion. That failure did not prove a user-visible keyboard defect or Host RPC failure.

We corrected the test to wait for the actual ready-rendered /union option row (finite timeout) immediately before real ArrowDown/Enter selection. It continues to type character-by-character, verify native aria-selected, submit one real Enter and require data-phase=claimed, then run the actual authenticated Host commands and union sidebar synchronization. It has no pointer fallback, direct Host RPC injection, silent skip or automatic command replay.

Corrected test, separate disposable DSH Home installations on macOS + real Chrome:

• @deepseek-ai/dsh@0.2.0-rc.2 (npm latest): 4/4 PASS + 8/8 PASS = 12/12 complete runs, 0 observed failures.
• @deepseek-ai/dsh@0.2.1-alpha.2 (npm alpha): 4/4 PASS + 8/8 PASS = 12/12 complete runs, 0 observed failures.
• Legacy DSH 0.1.2-rc.1 native/Web/Composer: 5/5 PASS (keyboard-specific test intentionally separate/opt-in).

The earlier 0.2.x 3/4 pre-Enter failures are still true test execution results, but must be classified as unreliable pending-state sampling rather than proven current DSH defects. The historical after-Enter phase=plain observations remain unresolved. At least one earlier captured snapshot already showed zero ready options immediately BEFORE Enter, so those failures may also have involved pending refinement; we have not proved an actually ready, highlighted option failed to claim or that a stale-span CAS is the unique cause.

I apologize for the earlier overclaim based on insufficient current-version/UI-state validation. Please treat this report as a keyboard-menu timing investigation, not a confirmed regression in DSH 0.2 latest or alpha. The replacement test and evidence are being published in an experimental stacked Draft branch. Manual screen reader certification and release reviews remain separate; finite successful runs do not establish a universal guarantee.