66 lines
1.8 KiB
Markdown
66 lines
1.8 KiB
Markdown
# 跨项目迭代边界与协作方式
|
||
|
||
**版本：** 2026-08-07
|
||
**适用范围：** 从 `04A.agent_tool_route` 开始的跨项目迭代
|
||
|
||
## 1. 当前现实
|
||
|
||
从 `04A` 开始，一次迭代已经不再只作用于 `lineup-app/`。
|
||
|
||
一个完整闭环可能同时涉及：
|
||
|
||
- `lineup-app/`：Runtime、Host、UI、SDK
|
||
- `lineup-adapter/hermes/`：协议转换、Agent 兼容层
|
||
- `lineup-app-server/`：必要时的传输边界
|
||
- `agent_ops/`：规划、设计、协议与验收文档
|
||
|
||
因此，迭代必须以“能力闭环”为单位，而不是以“某个仓库”命名。
|
||
|
||
## 2. 规划时必须写清的三件事
|
||
|
||
### 2.1 涉及哪些项目
|
||
|
||
每份 `01.迭代规划.md` 都必须列清：
|
||
|
||
- 主要改动项目；
|
||
- 次要联动项目；
|
||
- 只需验证、不需修改的项目。
|
||
|
||
### 2.2 哪个项目负责什么
|
||
|
||
规划和技术规范都要写清：
|
||
|
||
- Runtime 责任；
|
||
- Adapter 责任；
|
||
- 服务端责任；
|
||
- Host / 验收责任；
|
||
- 文档与协议责任。
|
||
|
||
### 2.3 哪些层不应被修改
|
||
|
||
跨项目迭代最常见的问题，不是“漏改一个文件”，而是“把不该动的边界动了”。
|
||
|
||
所以规划里必须明确：
|
||
|
||
- 哪一层是执行权威；
|
||
- 哪一层只做兼容；
|
||
- 哪一层视为透明传输；
|
||
- 哪些旧语义在本轮保持不变。
|
||
|
||
## 3. 评审时的检查顺序
|
||
|
||
跨项目迭代建议按以下顺序评审：
|
||
|
||
1. 先看产品与架构边界是否清楚；
|
||
2. 再看跨仓责任是否分清；
|
||
3. 再看协议与状态机是否闭环；
|
||
4. 最后看实施和验收能否真正跨端跑通。
|
||
|
||
## 4. 当前统一入口
|
||
|
||
从现在开始：
|
||
|
||
- 迭代规划、设计评审、技术规范、技术评审都在 `agent_ops/03.迭代规划/` 下组织；
|
||
- 具体实现仍分布在各代码仓；
|
||
- 但“本次迭代到底在做什么”只在这里定义和冻结。
|