chenchenandClaude Opus 4.7
4c263040c9
docs/Heicode-对接进度与待办.md §7.5 point 7 named the Manager team as
responsible for wiring P1 resource UI to mcp-server (§2 ResourceBinding,
§3 ResourceGrant) — without this, the deeplink that the desktop client
puts on the task card (`/manager/resources?from=task`) ends in a 404.
Changes:
1. lib/heicode-mcp.ts: typed wrappers for the 9 P1 endpoints
- §2 ResourceBinding: list / get / create / update / revoke
- §3 ResourceGrant: list / get / create / revoke
- Field shape verified against live mcp-server with test account
55@55.com — 7 smoke cases pass including the 422 sensitive-keyword
enforcement and the §3 subset rule.
2. features/agnet-console/pages.tsx AgnetSKSourcesPage rewritten to
read /api/resources (filtered to status=active) instead of the
legacy Heicode-local git_sources controller:
- Card 1 代码 = resources filter type='git'
- Card 2 文档SK = resources filter type∈{sk,project_doc}
- Card 3 云账号 = resources filter type∈{cloud_account,
cloud_resource}, "auto-discovery coming soon"
hint shown when empty (current state)
- Card 4 推荐摘要 = unchanged
3. Advanced sheet form rewritten for mcp-server ResourceBinding shape:
{type, name, external_ref, metadata, permission_scope, constraints,
secret_ref, status}. Old (provider, repo_url, ref, paths, usage,
tenant_id) maps in:
name → name
repo_url → external_ref
provider → metadata.provider
ref → metadata.default_branch + constraints.ref
paths → constraints.allowed_paths (comma-joined)
usage → type ('git'/'sk'/'project_doc')
tenant_id → dropped (server uses auth.user_id)
— → permission_scope ['repo:read'] minimal default
— → secret_ref blank for now (server fills once
OpenBao Secret Broker lands per §2.1 TODO)
Form also surfaces the §2.1 422 RESOURCE_GRANT_SECRET_REJECTED
server-side error to the user.
4. Removed unused imports (GitSource{,Payload,Usage}, createGitSource,
deleteGitSource, listGitSources) — legacy git_sources controller is
still in the Go backend for now but the Manager no longer consumes it.
5. RecommendationSummaryDialog now takes ResourceBinding[] for project /
sk source counters instead of GitSource[].
Smoke verified end-to-end against live mcp-server:
list / create (incl. metadata+constraints+permission_scope) / get /
delete-binding all 200 with expected shapes; 422 secret rejection
fires on metadata.{name containing 'token'}; §3 subset rule on
allowed_actions outside binding.permission_scope returns
RESOURCE_GRANT_INVALID.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Heicode
Heicode 面向多人协作、可追溯交付的软件团队：把需求对齐、实现、验证、发布和持续运营连成一条少断层的链路，并用可编排的智能体角色承接其中可标准化的环节——强调「能复盘、能审计、能按团队规模裁剪」，而不是罗列某一家的工具栈。
下面的目录表仅供工程查阅；不代表对外产品承诺、路线图或你必须采用的集成方式。
这个仓库里有什么（工程布局）
| 目录 | 大致含义 |
|---|---|
cc-haha/ |
Heicode（终端与桌面客户端及本地服务；此为源码目录名）。 |
heicode/ |
Heicode Manager（网关与管理控制台服务端；此为源码目录名）。 |
website/ |
产品介绍站点（Next.js；可 pnpm dev 或 Docker 预览）。 |
docs/ |
愿景与范式；docs/milestones/ 交付里程碑；docs/integration/ Agnet 等平台接口设计。 |
产品在解决什么问题
- 协作范式：把瀑布 / 敏捷下的角色分工落到可复述的闸门与智能体承接边界（方向与原则见
docs/vision-heicode-full-stack-agentic-dev.md；编队明细在文档附录）。 - 交付可追溯：文档、沟通与变更尽量与版本、发布对齐，便于复盘与合规。
- 工程上：同一仓库便于客户端与服务端同步发版、统一回归，减少「谁和谁版本对不上」的摩擦。
详细愿景与范式
docs/vision-heicode-full-stack-agentic-dev.md
快速启动（开发联调）
# 根依赖（Bun monorepo 根目录）
bun install
# Heicode 客户端本地服务（目录 cc-haha）
cd cc-haha
bun run src/server/index.ts
# 另开终端：桌面端
cd cc-haha/desktop
bun run tauri dev
联调网关时示例：
HEICODE_TAIJIAICLOUD_BASE_URL=http://localhost:3000 bun run src/server/index.ts
Heicode Manager（heicode/）中与 Heicode 登录相关的路由（最小集，以实际代码为准）：
GET /heicode/oauth/authorizeGET /heicode/oauth/session
平台侧能力还包括模型发现（如 GET /v1/models）与 Anthropic Messages 兼容入口等，详见 Heicode Manager（heicode/）与 Heicode 客户端（cc-haha/）各自 README。
官网（Next.js）
cd website && pnpm install && pnpm dev
若根目录提供 docker compose，可按 compose 说明构建预览镜像（以仓库内 docker-compose.yml 为准）。
发版与回归建议
- 同一版本标签发布客户端与网关镜像。
- 每次发版至少回归：登录、模型拉取、对话请求。
- 先在本地 Docker / 本地联调通过，再做外网域名与证书。
相关外部参考（概念）
- oh-my-claudecode — Claude Code 类工具的高效实践参考。
- Agnet 平台以实际部署环境与文档为准。
许可证
各子项目许可证见各子目录内 LICENSE（例如 Heicode Manager / heicode/ 侧常见为 AGPLv3）。