Files

T

chenchenandClaude Opus 4.7 4827682de5 refactor(client): retire client-side resources UI per new product spec

The 2026-05-08 product package (docs/product-package/) redraws the
client / Manager boundary. Per 08-client-guide.md §1-7, the client
explicitly does NOT carry resource binding, permission grants, or
any account / security surface — those move entirely to Manager.

This commit removes the client-side resources surface that landed in
slices 2-4 (commits d1db2c1, c0363be, a28c900):

Deleted:
  - cc-haha/desktop/src/api/heicodeResources.ts          (API client)
  - cc-haha/desktop/src/stores/resourceStore.ts          (zustand)
  - cc-haha/desktop/src/pages/ResourceBindings.tsx       (page)
  - cc-haha/desktop/src/components/resources/Modals.tsx  (3 modals)
  - cc-haha/src/server/api/heicode-resources.ts          (proxy)

Reverted:
  - Sidebar.tsx: drop the Resources nav item + RESOURCES_TAB_ID import
  - ContentRouter.tsx: drop the 'resources' branch + import
  - tabStore.ts: drop RESOURCES_TAB_ID + 'resources' from TabType
  - router.ts: drop 'heicode-resources' case + handler import
  - i18n zh.ts + en.ts: strip ~63 keys (sidebar.resources +
    resources.* + grants.*)

Kept (still useful for the new spec's Manager-side data needs):
  - mcpAuth schema in types/provider.ts
  - mcpAuth wired through CreateProviderInput / UpdateProviderInput
  - providerService persistence of mcpAuth on add/update
  - Path A login flow that decodes JWT exp claims and stores the
    pair on the saved provider

Why keep token persistence even though the client doesn't expose
binding/grant UI any more? Per product spec the Manager will surface
余额 / 模型 / 用量 / 调用日志 (§2.3.1 in mcp-server's 待办 doc), and
the client will surface high-risk approvals (08-client-guide.md
§5). Both flows need a JWT pair we can refresh without re-prompting
for password — that machinery is already in place.

Next slice candidates per product spec (08 + 10 + 11):
  - High-risk approval dialog (新增 Tier 1, mock-wired UI first)
  - Task card + intent input as main client surface
  - Execution feedback panel (Agnet sub-stage status)
  - Delivery result panel
None of those are in this commit; this commit is purely cleanup.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-08 11:19:21 +08:00

3.3 KiB

Raw Blame History

08. Heicode 客户端说明

客户端定位

Heicode 客户端是用户主体验，承担本地对话、想法输入、任务推进、执行反馈、交付接收和高危审批。它不是独立模型配置工具，也不是 CodeGW 后台客户端。

Heicode Manager 不是主体验，但它仍然负责账号与安全、客户端下载、Git/云资源绑定、Agnet 部署、任务状态、余额与审计等辅助操作。用户不在网页上编码，主要在客户端里推进开发任务。

客户端必须保持：

只登录 Heicode。
只使用 Heicode 提供的模型。
不出现模型提供方选择。
不出现旧服务入口。
视觉风格与 Heicode 保持一致。

模型

客户端模型来源：

Heicode
-> CodeGW 用户侧模型能力
-> 客户端展示可用模型

客户端不内置默认 Claude 模型，也不让用户选择模型提供方。用户看到什么模型，由 Heicode 和 CodeGW 映射决定。

主要功能

功能	说明
对话输入	用户描述产品想法、开发任务或维护需求
任务推进	继续要求、查看 Agnet 执行反馈、接收交付结果
任务状态	查看 Heicode 返回的任务和子 Agnet 进度
模型选择	从 Heicode 提供的模型中选择
高危审批	对生产部署、密钥访问、云操作做确认
日志反馈	展示关键执行反馈和失败原因
安装更新	从 Heicode 下载页获取安装包

客户端里的 Agnet 闭环

客户端里发生的不是单次对话，而是持续推进的任务闭环：

用户输入想法或补充要求
-> Heicode 判断当前子任务
-> 调用 Agnet 执行需求/开发/测试/修复/部署中的某一环
-> Agnet 按权限调用需要的 SK 工具
-> 中间结果、失败原因和下一步建议回到客户端
-> 用户继续补充、修正或审批
-> Agnet 继续推进
-> 最终返回交付物和部署结果

所以客户端应该更像“任务驾驶舱”，而不是一次性聊天窗口。

高危审批体验

审批弹窗应清楚展示：

操作类型。
目标资源。
请求角色。
风险等级。
有效期。
预计影响。
是否会派生短期凭证。

用户操作：

批准。
拒绝。
查看详情。

安装包分发

安装包由 Heicode 下载页提供。

平台：

macOS arm64。
Windows。
后续可扩展 Linux。

macOS 注意：

如果未完成 Developer ID 签名和 notarization，系统可能弹出安全提示。
产品文案应说明当前安装方式和后续签名计划。

客户端不应该出现的内容

模型提供方配置。
旧登录入口。
第三方路由登录入口。
CodeGW 后台入口。
OpenBao 地址或 token。
长期云密钥输入框。
无法解释的个人 API key 自动复制。

验收标准

打开客户端只看到 Heicode 登录入口。
登录地址是 https://code.xinghanlab.com。
模型列表来自 Heicode。
没有模型提供方菜单。
没有旧品牌和旧模型默认文案。
高危审批能明确展示风险和资源范围。

3.3 KiB Raw Blame History