refactor(frontend): 消融 #1546 projects port 死面（净 −880 行/31 文件）——portProjectsEnabled = Boolean(port) && !projects 在两个 shell 的所有可达状态恒为 false（shell 只在 hubReady 注入 port，而此时 projects 必为数组），故端口取数/游标分页/load-more 重试/端口建改与 ProjectNav sentinel UI 全部结构性不可达；按 S2 要求另开 #2290 登记 live 路径分页缺口

[DeliciousBuding]

做了什么

端到端删掉 #1546 的 WorkbenchProjectsPort 死面：31 files changed, 58 insertions(+), 938 deletions(-)（净 −880 行）。这是 #2274 里 C-3 / S2 记的「本 issue 行数最大的一块死结构」，删前已在真实树上重做可达性核实（issue 是索引不是事实源）。

删除清单：

层	删掉的东西
契约	app/workbench/src/workbenchProjectsPort.ts（整文件）、index.ts 的 WorkbenchProjectsPage/WorkbenchProjectsPort 导出
平台适配器	app/web/src/platform/webWorkbenchProjectsPort.ts + 其测试、app/desktop/src/platform/desktopWorkbenchProjectsPort.ts + 其测试、两个 App.tsx 的 import/useMemo/prop（含 web 侧因此变成未使用的 tCommon）
hook	useWorkbenchProjectsRoute.ts 298 → 154 行：端口内部取数状态、游标/hasMore/loadingMore/loadMoreError 及其 refs、loadProjects、loadMore、端口版 create/update、unmount 守卫
prop 管道	AgentHubWorkbenchTypes、workbenchFrameTypes、WorkbenchFrame、workbenchFramePartsHelpers、AgentHubWorkbenchHelpers、workbenchRoutesTypes、WorkbenchRoutes（8 处）
UI	ProjectNav 的 IntersectionObserver sentinel + loadingMore 通知 + loadMoreError/重试按钮、ProjectsPage 与 pages/projects/types.ts 的 4 个分页 props、workbenchRoutesHelpers 的分页映射、ProjectsPage.module.css 的 .sentinel 规则
i18n	projects.loadMoreError、projects.retryLoadMore（zh + en，只被上面那块死 UI 用；projects.loading 保留，live 的加载态在用）
死导出	hubDataMapping.ts 的 resolveHubProjectsDefault（0 个真实消费者，只有它自己的测试）+ 该测试块

可达性证明（为什么这是死面而不是「还没接上的功能」）

关键一行在 useWorkbenchProjectsRoute.ts：

const portProjectsEnabled = Boolean(projectsPort) && !projects;

两个 shell 的注入方式（改前原文）：

app/web/src/App.tsx:302       projectsPort={hubReady ? webProjectsPort : undefined}
app/web/src/App.tsx:291       projects={workbench.projects}          // = resolveWebWorkbenchProjects(...)
app/desktop/src/App.tsx:749   projectsPort={hubReady ? desktopProjectsPort : undefined}
app/desktop/src/App.tsx:772   projects={workbench.projects}          // = resolveHubProjects(...)

而 resolveWebWorkbenchProjects / resolveHubProjects 的返回值：hubReady=true 时恒为数组（(projects ?? []).map(...)，空数组也是 truthy）；hubReady=false 时是 undefined（mock/fixture 模式）或 []。同时两个 model 都是 projectsActions = hubReady ? {create, update} : undefined。

hubReady	projectsPort	projects	portProjectsEnabled	port.listProjects	port.createProject/updateProject
true	port	数组（truthy）	false	永不（effect 以 portProjectsEnabled 为门）	永不（if (onProjectCreate) return onProjectCreate(draft)，hubReady 时回调必存在）
false	undefined	undefined / []	false	永不（无 port）	永不（if (!projectsPort) return）

⇒ 端口分支在两个 shell 的所有可达状态下都不执行。下游同理：loadMore 恒 undefined、hasMore 恒 false、loadingMore 恒 false、loadMoreError 恒 undefined，所以 ProjectNav 的 sentinel（if (!sentinel || !hasMore) return）与重试按钮也永不渲染。

两个 shell 的注释自己就承认了这件事（改前原文）："Injected only in real mode — parent-managed projects keep the port dormant while demo mode falls back to mock fixtures."

逐条行为等价审计（删掉的每个分支在可达状态下的常量值）

删除项	改前在所有可达状态下的值	改后
sourceProjects	projects ?? (false ? portProjects : (realDataMode ? [] : MOCK))	projects ?? (realDataMode ? [] : MOCK) — 同值
effectiveProjectsStatus	projectsStatus ?? (false ? portProjectsStatus : undefined)	projectsStatus — 同值
canMutateProject	Boolean(onProjectCreate ?? onProjectUpdate ?? projectsPort)；hubReady 时前两者必有、demo 时三者皆无	Boolean(onProjectCreate ?? onProjectUpdate) — 同值
handleProjectCreate/Update	有回调走回调；无回调时 port 也必为 undefined ⇒ no-op	无回调 ⇒ no-op — 同值
loadMore / hasMore / loadingMore / loadMoreError	undefined / false / false / undefined	字段删除，消费方（分页 UI）一并删除 — 无可观察差异

证据（主机实跑）

$ pnpm -r typecheck                                       rc=0（5 包全绿）
$ pnpm exec vitest run                      # workbench   rc=0  Test Files 169 passed / Tests 1714 passed（473.31s）
$ pnpm exec vitest run                      # shared      rc=0  150 / 2746（与 master 相同：删的 2 个 i18n 键没有测试断言）
$ vitest run --config vitest.desktop-ci.config.ts         rc=0  48 / 430
$ pnpm exec vitest run                      # web         rc=0  32 / 265
$ pnpm exec eslint src --max-warnings 0     # web         rc=0（删 port 后 `tCommon` 变未使用，已一并删；这是 web 的真门禁）
$ pnpm exec eslint src                      # desktop     10 problems(6 err) → 9 problems(5 err)：改好没改坏（该 job 在 CI 里是 advisory，理由写在 YAML）
$ python3 scripts/verify/verify-i18n-deadkeys.py          rc=0（bundles 2 / dynamic prefixes 6）
$ python3 scripts/verify/verify-i18n-callsites.py         rc=0（74 files / 610 CJK lines ≤ baseline）
$ python3 scripts/verify/verify-i18n-terminology.py       rc=0
$ bash /tmp/run-validate.sh <worktree>                    PASS=61 FAIL=0 SKIP(merge-ref)=1
$ git diff --check origin/master...HEAD                   rc=0

用例数账（诚实记）：净 −19 例，全部只断言被删代码——workbench 1722→1714（端口驱动 describe 的 11 例：8 例随代码删除，3 例改写成父级驱动版本保留，另新增 1 例「mutation affordance 只来自父级回调」）；desktop 435→430（适配器测试整文件 5 例）；web 271→265（适配器测试整文件 6 例）。workbenchRoutesHelpers.test.ts 里 2 处 props.hasMore/onLoadMore 断言随字段删除而去掉（用例本身保留）。contacts/tasks 的分页测试未触碰（那是活面）。

关联

• Refs 前端探索批收口：原始 37 条已处置，现役代码与回归已复核 #2274（C-3 / S2 切片：裁决 ① 已按消融原则选「删除」而不是「接通」——接通等于给一个没人要求的功能补第二条取数路径，而 shell 侧已有 react-query 的 projects 查询；裁决 ② ProjectInfo.status 语义未触碰，本轮只删死面）
• 按 S2 的要求另开了 projects 列表在 live 路径无分页：web 固定 pageSize=50 且不读 nextCursor、desktop 连 pageSize 都不传（服务端支持游标 + 上限 200）⇒ 第 51 个项目起静默不显示；唯一实现过游标分页的 #1546 port 链路是结构性不可达死面已删 #2290：projects 列表在 live 路径无分页（web 固定 pageSize: 50 且不读 nextCursor、desktop 连 pageSize 都不传，服务端支持游标 + 上限 200）⇒ 第 51 个项目起静默不显示。删除前后用户可见行为一致（以前也不显示），但现在缺口是显式的而不是藏在一条永不执行的代码里。

Negative constraints（刻意没做）

• 没动 projects 的活面：pages/projects/** 的 UI、状态过滤（[整理] 静态审计 backlog 跟踪（探索 lane 剩余项） #2154 P2-3）、编辑器、以及两个 shell 自己的 projects 查询与 mutations。
• 没收敛 web 侧的 workspaceProjectToProjectInfo 副本（app/web/src/platform/webWorkbenchProjects.ts 与 workbench/src/hubDataMapping.ts 各有一份、签名不同：web 版多 projectGroups 投影）——那是另一条手抄分岔，需要自己的一批与实测，已在 hubDataMapping.test.ts 的头注里点名登记。
• 没实现分页（projects 列表在 live 路径无分页：web 固定 pageSize=50 且不读 nextCursor、desktop 连 pageSize 都不传（服务端支持游标 + 上限 200）⇒ 第 51 个项目起静默不显示；唯一实现过游标分页的 #1546 port 链路是结构性不可达死面已删 #2290），没改任何 src 行为。

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 7961da5a-f80c-4d4d-a638-4d2c7389a70f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}