# Gitea Codex 工作流实现发现

- `server.js` 的 `codexAppThreadConfig(session, options)` 最终将每项配置写为 `mcp_servers.<server>`，所以独立适配器应返回与 app-server config 兼容的 `{type:'stdio', command, args, env}`。
- `startCodexAppTurn()` 在 `thread/start`/`thread/resume` 后记录 `entry.threadId`，在 `turn/start` 返回后记录 `entry.turnId`；`handleCodexAppTurnComplete()` 是完成监听点。
- 运行时事件可能从 `params.turnId`、`params.turn.id`、`params.item.turnId` 取 turnId；关联标记必须同时支持明文状态字段和 HTML 注释隐藏标识。
- 官方 gitea-mcp 采用 stdio，启动参数为 `-t stdio -H <host>`，token 通过线程级 env 注入；不应放到长驻 app-server 全局环境。
- gitea-mcp 最终评论需要查询确认；查询需匹配资源、Bot 作者和 taskId/turnId/resourceKey 隐藏标识，未知状态不能直接重复执行。
- waiting_user 新评论应复用原 `sessionKey/threadId`，但每条评论创建新 task/turn；补触发必须是同一 thread 的隐藏轮次，且最多一次。

## 实现接口

- `buildGiteaThreadConfig({cwd, host, accessToken})` 返回 `config['mcp_servers.gitea']`，内部为 `type=stdio`、`gitea-mcp -t stdio -H host` 和线程级 `GITEA_HOST/GITEA_ACCESS_TOKEN`。
- `buildWorkflowMarker`/`parseWorkflowMarker` 使用 `<!-- ccweb-gitea v="1" ... -->`，缺少 taskId、turnId 或 resourceKey 时返回 null。
- `createGiteaWorkflowCodex` 通过 `verifyReply/listComments/startTurn/sendRestReply` 依赖注入实现外部副作用；`unknown` 查询直接进入保守 `failed_reply`，不会自动补触发。
- `server.js` 的 `codexAppThreadConfig` 同时兼容 `{host, accessToken}` 和已构建的 stdio config；`startCodexAppTurn`、`handleCodexAppTurnComplete` 提供 turn 生命周期薄挂接，既有 waiter 在完成时执行回执确认/补偿。