# 跨项目迭代边界与协作方式

**版本：** 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.迭代规划/` 下组织；
- 具体实现仍分布在各代码仓；
- 但“本次迭代到底在做什么”只在这里定义和冻结。