161 lines
7.3 KiB
Markdown
161 lines
7.3 KiB
Markdown
<!-- TRELLIS:START -->
|
||
# Trellis Instructions
|
||
|
||
These instructions are for AI assistants working in this project.
|
||
|
||
Use the `/trellis:start` command when starting a new session to:
|
||
- Initialize your developer identity
|
||
- Understand current project context
|
||
- Read relevant guidelines
|
||
|
||
Use `@/.trellis/` to learn:
|
||
- Development workflow (`workflow.md`)
|
||
- Project structure guidelines (`spec/`)
|
||
- Developer workspace (`workspace/`)
|
||
|
||
If you're using Codex, project-scoped helpers may also live in:
|
||
- `.agents/skills/` for reusable Trellis skills
|
||
- `.codex/agents/` for optional custom subagents
|
||
|
||
Keep this managed block so 'trellis update' can refresh the instructions.
|
||
|
||
<!-- TRELLIS:END -->
|
||
|
||
## 常用运维命令
|
||
|
||
重启 cc-web 服务：
|
||
|
||
修改 ccweb 项目后如果需要重启服务，必须先查看当前会话列表中的运行状态。
|
||
只有在除当前对话外没有其他 `running` 对话时，才能执行重启；如果仍有其他
|
||
运行中的对话，应暂缓重启并告知用户原因。
|
||
|
||
```bash
|
||
pm2 restart ccweb --update-env
|
||
```
|
||
|
||
## Codebase Memory 代码检索约定
|
||
|
||
本项目内 **graphify 已全面弃用**。后续涉及代码定位、调用链、架构理解、影响面分析、跨模块关系梳理时，默认优先使用 `codebase-memory-mcp`，不要再启用 graphify 技能、graphify CLI 或 `graphify-out` 产物作为主路径。
|
||
|
||
当前项目的 codebase-memory 项目名：
|
||
|
||
```text
|
||
home-cc-web
|
||
```
|
||
|
||
### 默认检索流程
|
||
|
||
1. 先确认索引状态：
|
||
- `list_projects`
|
||
- `index_status(project="home-cc-web")`
|
||
2. 如果索引缺失或明显过期，先执行：
|
||
- `index_repository(repo_path="/home/cc-web", mode="full", persistence=false)`
|
||
3. 需要理解整体结构时，先用：
|
||
- `get_architecture(project="home-cc-web", aspects=["all"])`
|
||
4. 需要找功能入口、类、函数、路由时，优先用：
|
||
- `search_graph`
|
||
- `search_code`
|
||
5. 需要确认调用关系时，使用：
|
||
- `trace_path(mode="calls", direction="inbound" | "outbound" | "both")`
|
||
6. 需要读取具体实现时，先通过 `search_graph` 找到精确 `qualified_name`，再用：
|
||
- `get_code_snippet`
|
||
7. `rg` / `sed` 只作为补充校验：
|
||
- 校验最终行号
|
||
- 查未被索引的配置或纯文本
|
||
- 对 MCP 命中结果做交叉验证
|
||
|
||
### 子代理引导词模板
|
||
|
||
派发需要理解代码的子代理时，默认加入以下引导：
|
||
|
||
```text
|
||
请优先使用 codebase-memory-mcp 做代码理解：
|
||
先 list_projects / index_status 确认项目索引；
|
||
再用 search_graph 或 search_code 定位候选函数；
|
||
需要调用链时用 trace_path；
|
||
需要源码时先拿 qualified_name，再调用 get_code_snippet；
|
||
最后只用 rg/sed 校验行号或补查未索引文本。
|
||
不要使用 graphify。
|
||
```
|
||
|
||
### 本项目已验证的使用经验
|
||
|
||
- 无明确引导时，子代理不一定会主动使用 `codebase-memory-mcp`，可能退回 `rg` 或旧的 graphify 路径。
|
||
- 明确要求优先使用 `codebase-memory-mcp` 后，能稳定命中函数级入口、调用链和源码片段。
|
||
- 对 `codexapp` / `ccweb` 这类跨模块链路，`search_code` + `trace_path` + `get_code_snippet` 的组合比单纯全文检索更快建立上下文。
|
||
- 自然语言检索遇到 `developer`、`config`、`message` 等通用词会有噪声；这时应收敛到明确标识符，如 `collaborationMode`、`mcp_servers.ccweb`、`CC_WEB_SOURCE_SESSION_ID`。
|
||
- 最终答复中的文件行号仍建议用 `rg -n` 或 `nl -ba` 做一次轻量核验。
|
||
|
||
### 索引更新与忽略规则
|
||
|
||
- `auto_index` 是 `codebase-memory-mcp` 的本地配置，按当前 `CBM_CACHE_DIR` 生效；它不是 `.codex/config.toml` 里的项目级开关。
|
||
- 当前项目的项目级忽略规则写在 `.cbmignore`。普通源码级 `*.js` / `*.css` 不应一刀切排除；只排除 `*.min.js`、`*.map`、压缩包、构建目录、日志、临时文件、运行态状态文件等。
|
||
- watcher 是 Git-based polling：非 Git 项目跳过轮询；Git 项目的轮询间隔为基础 5 秒，每 500 个文件加 1 秒，最长 60 秒。
|
||
- 修改 `.cbmignore` 或大范围调整文件后，建议手动执行一次 `index_repository(repo_path="/home/cc-web", mode="full", persistence=false)`，让当前索引立即收敛到最新规则。
|
||
|
||
## Codex App / hapi 对齐经验
|
||
|
||
以下约定来自本项目对 `/home/hdzx/2026/hapi` 中 Codex app-server 接入方式的对比结果。后续如果继续维护 `codexapp`，默认按这些约定实现，避免再走偏到“看起来能跑、但拿不到原生协作能力”的分叉路径。
|
||
|
||
### 1. 初始化链路优先对齐上游协议
|
||
|
||
- `initialize` 成功后，先发送 `initialized` notification。
|
||
- 然后再做 best-effort 的能力探测：
|
||
- `experimentalFeature/enablement/set`，当前至少尝试 `{ enablement: { goals: true } }`
|
||
- `collaborationMode/list`
|
||
- 上述探测失败时：
|
||
- 只记录日志
|
||
- 不直接中断 `codexapp` 启动
|
||
|
||
### 2. collaborationMode 的参数形状必须贴近 hapi
|
||
|
||
- 一旦本轮使用 `collaborationMode`，`turn/start` 顶层参数应保持精简。
|
||
- `model`、`reasoning_effort`、`developer_instructions` 应放入：
|
||
- `collaborationMode.settings.model`
|
||
- `collaborationMode.settings.reasoning_effort`
|
||
- `collaborationMode.settings.developer_instructions`
|
||
- 使用 `collaborationMode` 时，不要再重复传顶层 `model` / `effort`，否则容易让 app-server 落到非原生协作路径。
|
||
|
||
### 3. 自定义跨会话能力走 MCP，不优先走 dynamicTools
|
||
|
||
- `ccweb_list_conversations`、`ccweb_send_message` 这类自定义能力，优先通过 `thread/start.config.mcp_servers.*` 挂载。
|
||
- 不要把它们当成 `dynamicTools` 主路径注入给 `codexapp`。
|
||
- 原因：
|
||
- `dynamicTools` 容易污染 app-server 原生工具集
|
||
- 会增加拿不到 `spawn_agent` / `wait_agent` / 原生协作工具的风险
|
||
|
||
### 4. MCP 配置要做成“线程级”而不是“进程级”
|
||
|
||
- `codexapp` 是长驻 app-server，不是一次一进程的 CLI 调用。
|
||
- 因此 `CC_WEB_SOURCE_SESSION_ID`、`CC_WEB_CROSS_HOP_COUNT` 这类来源上下文，不应只放在 app-server 进程全局环境里。
|
||
- 正确做法是随 `thread/start.config.mcp_servers.ccweb.env` 一起下发，让每个线程拿到自己的来源会话上下文。
|
||
|
||
### 5. guided input 依赖 plan 协作模式
|
||
|
||
- `request_user_input` 类能力默认按“协作 / plan 模式可用”来设计。
|
||
- Default / YOLO 模式下，不要假设引导输入一定可用。
|
||
- 如果要做降级：
|
||
- 优先退回普通文本交互
|
||
- 不要让整轮对话因为 guided input 不可用而直接失效
|
||
|
||
### 6. 能力降级要明确而保守
|
||
|
||
- 如果运行时拒绝 `collaborationMode`（例如 `unknown field collaborationMode` 或 `unsupported collaboration mode`）：
|
||
- 应记录一次能力降级
|
||
- 后续本轮可退回普通 turn 发送
|
||
- 但如果只是 `goals` 或 `collaborationMode/list` 探测失败：
|
||
- 不应直接判定整个 app-server 不可用
|
||
|
||
### 7. 回归检查要覆盖协议形状，不只看 UI
|
||
|
||
后续涉及 `codexapp` 的改动，至少要检查这些点：
|
||
|
||
- `initialize` 后是否真的调用了：
|
||
- `experimentalFeature/enablement/set`
|
||
- `collaborationMode/list`
|
||
- `collaborationMode` 存在时：
|
||
- 顶层是否没有重复 `model`
|
||
- 顶层是否没有重复 `effort`
|
||
- `ccweb` 能力是否走 `mcpToolCall`，而不是再次退回 `dynamicToolCall`
|
||
- mock / regression 中是否覆盖了上述断言
|