# 当前状态与阶段判断

**版本：** 2026-08-07 整合版  
**主要来源：** 根 `项目状态记录.md`  
**说明：** 本文不原样复制运行细节，而是提炼当前阶段结论，并明确哪些判断带有时间边界。

## 1. 当前阶段结论

根据 `项目状态记录.md` 中截至 2026-08-03 的核验内容，以及根目录其他文档的交叉表述，当前更稳妥的阶段判断是：

**LineUp 已经完成了以 `lineup-app`、`lineup-app-server`、`lineup-adapter/hermes` 为核心的一条主线闭环，重点已经从“是否能跑通”转向“如何收敛 Runtime、MiniApp、工作区、设计和文档体系”。**

这比“某个服务此刻是否在线”更适合作为当前文档主结论。

## 2. 当前仍有效的高层事实

以下结论在多份文档中相互支持，仍适合作为当前状态摘要：

- 项目主线已从早期探索阶段进入结构收敛阶段；
- `lineup-app` 已经成为客户端主仓与当前唯一有效客户端基线；
- `Hermes Adapter` 是当前正式保留的 Agent 适配主线；
- `lineup-app-server` 承担登录、消息收发、同步与 Web Reference Host 服务边界；
- 文档、设计、程序清单和迭代资料已经足够多，继续分散维护的成本开始高于整合成本；
- 下一阶段重点不只是继续写功能，也包括整理信息架构与文档治理。

## 3. 需要保留日期边界的事实

原 `项目状态记录.md` 中有很多高价值事实，但它们都是“截至某次核验”的事实，不能直接提升为无日期的长期结论。例如：

- 某个端口正在监听；
- 某个服务“运行中”；
- 某个提交号是当前基线；
- 某个验证在某天通过；
- 某个 APK 体积是多少；
- 某个密钥尚未配置。

这些内容建议后续拆到 `05.运行运维/`，并保留：

- 核验日期；
- 核验方式；
- 适用范围；
- 是否仍需复核。

其中，2026-08-03 的首轮运行基线和验证事实，现已迁入：

- [2026-08-03运行基线与验证记录](../05.运行运维/01.2026-08-03运行基线与验证记录.md)

## 4. 以今天视角看，哪些内容已经偏“运行记录”

以下内容不适合继续放在项目总览层，而更适合作为运行/联调记录保存：

- 在线架构图中的实时地址和端口；
- “当前在线”组件状态表；
- 某次端到端验证通过时间点；
- 某次已知问题与部署待办。

它们不是不重要，而是时效性太强。把这些内容长期放在总览文档中，会导致读者混淆“结构性结论”和“当日运行事实”。

## 5. 当前阶段的文档判断

从文档治理角度看，当前项目已经到了必须做三件事的阶段：

1. 把项目总览、状态、职责和程序清单从根目录散点文档收拢成统一入口；
2. 维护已经迁入 `agent_ops/02.架构设计/` 的当前有效设计文档，作为新的架构主入口；
3. 把 `lineup-app/迭代/` 中的计划、设计评审和验收评审建立清晰索引。

## 6. 对原文档时效性的判断

### 6.1 仍可直接沿用的部分

- 总体阶段判断；
- 项目组件分层认识；
- 运行主线已经跑通这一结论；
- 已知限制需要继续收敛的方向。

### 6.2 需要带日期沿用的部分

- 服务在线状态；
- 具体端口、地址、版本、提交号；
- 某次真机、浏览器、Adapter 验收记录。

### 6.3 本轮不直接沿用为主入口的部分

- 细粒度部署说明；
- 历史兼容性论证全文；
- 逐文件组件明细。

这些内容后续分别下沉到 `05.运行运维/`、`02.架构设计/`、`04.程序清单/` 更合适。