refactor(frontend): 消融 4 处自证死表面——composerApprovalMode 里同一个 3 元素枚举的 5 份手抄收成 1 张表（死常量变唯一来源），另删 shared 两个 0 消费者 key helper、workbench 一个死别名（连同其唯一 import）、web 一个值写错且 0 消费者的 threads 键（它指向 projects 根键，失效永远碰不到它声称寻址的 threads） (#2274) - #2277
Merged
Conversation
…举的 5 份手抄（车道报的是 4 份，实数 5：一个 0 消费者的 COMPOSER_APPROVAL_MODES 数组 + 4 条各自重列同一组 mode→pickerValue→labelKey 的 if/else 链）收成 1 张表 + 4 个查表函数，死常量因此变成唯一来源而不是被删掉；删 shared 的 leftLineKey/rightLineKey（全仓各只出现 1 次=自己的定义）、workbench mockData 的 WORKBENCH_MOCK_AGENT_MCP_OPTIONS 死别名连同它唯一使用的那个 import 别名、web projectQueries 里值写错且 0 消费者的 threads 键别名（它指向 projects 根键，任何对它的失效都只会重拉项目列表而永远碰不到它声称寻址的 threads） (#2274) 判据与自证（不采信车道结论，逐条自己 grep）： - 4 个死符号在 app/ 全树的命中数各为 1，即只有自己的定义，0 消费者 0 测试。 - workspaceProjectThreadsQueryKey 与紧邻上一行的 workspaceProjectsQueryKey **值完全相同**（都是 hubQueryKeys.projects.root），这是 #2274 A-15 说的 「死导出且值是错的」，就地留注释说明为什么刻意不再有本地 threads 键别名。 - composerApprovalMode 的收敛是行为保持的：三个 mode 的 pickerValue 与 labelKey 逐值照搬，未知 mode 仍回落 suggest、未知 pickerValue 仍返回 null、 选项顺序仍是 suggest/acceptEdits/plan。该文件有专属测试 composerApprovalMode.test.ts，改后全绿。 刻意不做（证据不支持「死」这个定性）： - WorkbenchProjectsPort 家族（#2274 C-3/S2）：车道定性为「两个 shell 里都结构 性不可达」，但自己 grep 出 **41 处引用**，含 desktop/App.tsx:237 的真实实例 化与专属测试。「结构性不可达」是比「0 引用」强得多的断言，需要沿渲染路径追， 删它属架构裁决（接通还是删）而非清死码 ⇒ 留给 #2274 的 S2，不在本批。 - resolveHubProjectsDefault / useWorkbenchProjectsRoute：同上，各自都有专属测试。 - rootPrefix()（C-5，0 消费者）：它是 A-12 那 4 处 no-op 失效的现成解法，应当 被接线而不是被删；接线要改键形状，等 #2261 的 S1 裁决。 - 34 个死 export 修饰符（C-4）：跨 24 文件的纯机械改动，混进本批会让 review 无法进行，且需要单独的编译验证轮次。 验证：pnpm -r typecheck 5 个包全绿；pnpm --filter {workbench,shared,web} test 共 **4,726 个测试全绿**（shared 150 文件/2,734、workbench 169/1,724、 web 33/268，0 failed）；workbench lint（tsc --noEmit）绿。 web lint（eslint src）仍报 6 个 no-explicit-any，但经 git stash 对照证明 **在干净 master 上同样红**，且全部落在我没碰的 4 个文件（agentQueries.ts ×3、 webPlatformMapping.ts、webWorkbenchProjects.ts、webWorkbenchProjectsPort.ts）， 根因是 CI 的 Lint Web step 挂着 continue-on-error ⇒ 结构上不可能让 CI 变红； 该假门禁另批处理，不在本 PR 范围内。 Co-authored-by: Cursor <cursor@vectorcontrol.tech>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
一句话
消融 4 处自证的死表面；核心不是删，是把
composerApprovalMode.ts里同一个 3 元素枚举的 5 份手抄收成 1 张表——那个"死常量"因此变成唯一来源，而不是被删掉。关联 #2274（C-2 / A-15）。
改了什么
1.
app/workbench/src/composerApprovalMode.ts：5 份 → 1 张表同一个
mode → pickerValue → labelKey三元组在这个 54 行文件里被写了 5 遍（lane 报告说 4 遍，实数 5）：COMPOSER_APPROVAL_MODES数组（0 消费者）approvalModeToPickerValueif/else 链pickerValueToApprovalMode反向 if/else 链buildComposerApprovalModeOptions手写三项.map()activeComposerApprovalModeLabelif/else 链行为逐值保持：三个 mode 的 pickerValue/labelKey 照搬，未知 mode 仍回落
suggest，未知 pickerValue 仍返回null，选项顺序仍是suggest / acceptEdits / plan。收益是结构性的：加一个 mode 从"改 5 处"变成"加 1 行"，且一个 mode 不可能再出现在某个映射里却缺席于另一个。2. 三处 0 消费者死表面（判据：全仓命中数 = 1，即只有自己的定义）
app/shared/src/ui/DiffReviewPanelHelpers.tsleftLineKey/rightLineKey（8 行）——同族的hunkStateKey有消费者，保留app/workbench/src/mockData.tsWORKBENCH_MOCK_AGENT_MCP_OPTIONS死别名，连同它唯一使用的那个 import 别名一起删（否则留下未使用 import）app/web/src/api/projectQueries.tsworkspaceProjectThreadsQueryKey：0 消费者且值是错的——与紧邻上一行的workspaceProjectsQueryKey完全相同（都是hubQueryKeys.projects.root），任何对它的失效都只会重拉项目列表、永远碰不到它声称寻址的 threads。就地留注释说明为什么刻意不再有本地 threads 键别名刻意不做（证据不支持"死"这个定性）
WorkbenchProjectsPort家族（前端探索批收口：原始 37 条已处置，现役代码与回归已复核 #2274 C-3/S2）不删：lane 定性为"两个 shell 里都结构性不可达"，但我自己 grep 出 41 处引用，含desktop/src/App.tsx:237的真实实例化与专属测试。"结构性不可达"是比"0 引用"强得多的断言，得沿渲染路径追；删它是架构裁决（接通还是删，代价分别是 2 文件 ~10 行 vs 14 文件 ~350 行）而不是清死码 ⇒ 留在 前端探索批收口：原始 37 条已处置，现役代码与回归已复核 #2274 的 S2。resolveHubProjectsDefault/useWorkbenchProjectsRoute：同上，各有专属测试。rootPrefix()（C-5，0 消费者）不删：它是 A-12 那 4 处 no-op 失效的现成解法，应该被接线而不是被删；接线要改键形状，等 react-query 键家族卫生 · 残项：desktop 的 contacts 家族（useHubContacts 把 root 当 live key，违反 ADR-029；hubEventBridge 4 条 realtime 联系人失效全部打空）——web 的 web-v4 残项已 landed #2317/ADR-035 #2261 的 S1 裁决。export修饰符（C-4）：跨 24 文件的纯机械改动，混进本批会让 review 无法进行。证据
pnpm -r typecheckpnpm --filter {workbench,shared,web} testpnpm --filter @agenthub/workbench lint（tsc --noEmit）未验证 / 可能错
pnpm --filter agenthub-web lint（eslint src --max-warnings 0）仍报 6 个no-explicit-any。已用git stash对照证明干净 master 上同样红，且 6 处全在我没碰的 4 个文件（agentQueries.ts×3、webPlatformMapping.ts、webWorkbenchProjects.ts、webWorkbenchProjectsPort.ts），全是同一个模式(key: string, options?: any) => string。根因是 CI 的Lint Webstep 挂着continue-on-error: true⇒ 结构上不可能让 CI 变红（desktop / mobile 的 lint step 同样如此）。这属另一批（把假门禁变真门禁），不在本 PR 范围内，本 PR 也没让它变好或变坏。desktop/mobile-rn的测试与 lint：本 PR 未改这两个包的任何文件。