[loopx-agent]

Lark settings must distinguish an unread catalog from a confirmed empty directory. Both the tab and toolbar now share an unknown count while loading or after a failed read; a successful empty response still shows zero, and the existing error and retry remain visible. This adds no navigation or confirmation step.

The old source-contract assertion matched the local loading variable after #6879 split catalog and connection reads. It failed before the packaged browser checks started. Its invariant now runs against the rendered page in the existing progressive-loading scenario: held response, populated/empty/failed catalogs, retry, stale-generation rejection and no duplicate health probes. It also found the toolbar's false-zero cases, which fail before the corresponding fixes.

Validation hold: standard premerge still fails the existing maintained Python/TypeScript twin budget: 44 versus 43. The unmodified check gives the same failure for immutable base 88df41c2261708ec587a50723e4b1ee5aad587de and this head, with all guard/source inputs verified identical. The new Inbox pair is inherited from #6860; this PR does not change the budget or its owner. Resolve that gate before merge. The proposal is complete and ready for review.

Validation

• npm run build: types, dashboard and verified Chat bundle passed.
• npm run smoke:personal-workspace-packaged:catalog: all CI preflights and all 70 packaged scenarios passed. The final focused scenario separately passed loading, true zero, failure, retry, stale results and 390px layout.
• Before-fix checks reproduce both false-zero failures; the old source contract also reproduces its variable-name failure.
• Diff hygiene, bilingual RFC check, public-boundary scan and the other selected premerge checks passed. The budget failure above remains recorded.
• Source/build 6826f90b738a6ee470006cd8db7c783477fa6728; final head ba295ddb5f691402230a9a0de26da76a8cbb687e differs only by the failure-state screenshot. All application and scenario source hashes match.

The change stays within the existing Lark settings read owner. The bounded refactor shares one count between two consumers and replaces one implementation-shaped assertion with behavior. Existing provider, configuration and operation authorization remain with their current owners. Live accounts, installed App adoption and sustained latency/cost are outside this validation.

First-screen evidence

Actual compiled UI served by the packaged HTTP handler, with synthetic API responses. Desktop 1512px and narrow 390px; images contain no live accounts or messages.

Before: unread catalog incorrectly shows zero in the toolbar.

After: unread counts remain unknown.

Read failure keeps the error and retry visible, with no invented zero.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

精确 head ba295ddb5f691402230a9a0de26da76a8cbb687e：APPROVE，未发现阻塞本次显示修复的问题。标准预合并仍因既有语义双实现预算 44/43 失败，保留独立的合并阻塞。

动机

打开 Lark 设置、查看可复用 App 的用户。目录尚未返回时工具栏显示零个 App；目录读取失败后，标签页和工具栏也把未知数量显示成零，容易让用户误以为配置丢失。本次让两个数量显示共用已有读取状态：加载和读取失败时显示省略号，成功读到空目录才显示零，失败提示与原地重试继续可用。真实账户、安装态 App 采用以及持续时延和成本仍未验证；本次只交付现有设置页数量的真实性修复。不改变账户、配置、健康核验和执行权限，也不把合成目录当作真实飞书连通性证明。

改动思路

目录表示“有哪些配置”，健康核验表示“当前能否使用”。前者成功读到三个 App 时，即使其中一个核验失败、另一个仍在核验，数量也应为三。相反，目录请求还未完成或失败时，不能把初始空数组解释为确认没有配置。

目录与健康核验的职责保持分离，数量只是已有状态的派生；无需新增配置、持久状态或第二个读取 owner。当前 PR 修复现有 Lark 设置页两处数量，沿用错误、重试和核验；真实账户与安装态采用仍留在原交付边界。不改代码会保留误导，只修标签页则漏掉工具栏，共用一个派生值已经是完整而小的修复。

实际状态	基线	本次 head
目录等待返回	标签未知，工具栏零	两处未知
目录读取失败	两处零	两处未知，错误和重试保留
成功空目录	两处零	两处零
三个配置、部分健康核验失败	两处三	两处三

这是实际重新构建页面的对照结果，目录与健康读取经过原 HTTP 和 reducer，仅命令传输使用合成数据。

具体改动

关键代码讲解

1. LarkSettingsPage.appCount 从已有 appsLoading、appsError 和 apps.length 派生一个值，再供标签页及工具栏共同使用。错误判定明确为非 null，没有把核验失败或空目录混成目录失败。
2. useLarkApps.refresh 保持原职责：目录成功后结束数量加载，各 App 独立核验；刷新中止上一代请求。独立验证中，三个配置里一快、一慢、一失败仍显示三，切换代次后迟到的旧结果未覆盖新卡片。
3. verifyLarkLoading 在现有浏览器场景加入等待目录、成功空目录、失败与重试，保留代次和去重断言。删除的正则只认旧局部变量名，基线确实因此失败；本次没有保留一个空壳检查来代替真实页面验证。

规范依据是 docs/architecture/rfcs/goal-workspace-surface-v0.md，读取的不可变版本为 88df41c2261708ec587a50723e4b1ee5aad587de。其中 Progressive loading stays per region. 已实现：加载或失败不显示空成功；No new authority. 已实现：操作仍由原 owner 执行，本次未增加授权、接口或账户能力。另按已有设计规范核对未知不等于零与失败可见。

全量检查了 7 文件、+47/-6，包含四张首屏图。四张图已直接置于 PR 描述，并准确注明构建版本与合成响应；桌面和 390px 页面都保持可读，未添加导航或确认步骤。

对主干的风险

最强反例是“目录成功但健康核验失败”：如果错误归类错误，页面仍可能隐藏真实配置数量。独立运行通过：基线和 head 均显示三；成功空目录显示零、不发健康请求；目录失败时 head 显示未知及目录错误，原地重试恢复三。五代读取均为 5 次目录加 9 次健康请求，没有重复。旧代慢结果、重试和 390px 无横向溢出也已核实。

本次重新执行构建、类型检查、现有源合同、场景语法检查及 19 项真实 HTTP 测试，均通过；Ego 使用当前重新构建的页面，分别验证不可变基线和精确 head。未把作者报告的全部 70 场景当成本次重跑记录。第一次私有验证误把独立连接错误当成目录错误，修正观察对象后完整路径通过；这些原始失败保留在私有证据中，不归因给 PR。

语义与 CI 对齐

未查询或等待远端 CI。标准本地预合并的直接检查、另外三项 catalog 检查与公开边界检查通过，semantic-vocabulary-drift-smoke.py 仍失败。相同命令在不可变基线 88df41c2261708ec587a50723e4b1ee5aad587de 与本 head 均得到 44 independently maintained py/ts twins; budget is 43。逐项验证了控制面、语义注册及检查器等 836 个跟踪路径的对象一致，本 diff 未改变其因果输入；数量显示不变量有独立通过证据。因此该失败归为既有且无关，允许本次审阅 APPROVE，但预算失败仍阻止合并，未调预算、缩窄扫描或宣称通过。

我的整体评价

交付判断为 justified_increment：用户体验 improved，长程执行影响 preserved。本次去掉误导性的零，不增加账户操作或必填步骤；没有证据可据此宣称持续工作效率改善。已有 owner 与一处派生值足够，范围和维护成本相称，共用数量及替换变量名断言是已经应用的有界简化。语义保持 local_only，没有新共享词汇或兼容分支。

未发现阻塞 finding，给予精确 head APPROVE。真实账户、安装态 App 采用以及持续时延和成本仍未验证；本次只交付现有设置页数量的真实性修复。另保留预合并预算失败的合并阻塞；本评审不授予合并、安装或忽略检查的权限。

English verdict: APPROVE at ba295ddb5f691402230a9a0de26da76a8cbb687e. Independent rebuilt base/head HTTP and UI checks confirm unknown counts for pending/failed catalogs, real zero for confirmed empty, and unchanged health, retry and generation behavior. The unchanged 44/43 semantic ratchet remains a separate merge hold; no live-account or installed-adoption qualification is claimed.