up：让它跑起来，并等到真的就绪
up 按依赖顺序启动清单声明的东西。--wait 只在选中的服务真的开始监听并通过健康检查后才返回。
按依赖顺序启动
服务按 depends_on 的顺序启动。带 prepare: 的服务先在同一工作目录跑前置命令，成功后才启动长时间运行的 cmd:。已经在跑的服务会被跳过；每个服务保留自己的日志文件和运行记录。
api started :21730 ready
worker started no port--wait 证明了什么
不带 --wait，up 只证明进程起来了，没有证明服务可用。带 --wait，有端口的服务必须开始监听；声明了 health: 的服务还必须通过检查；无端口 worker 的运行记录变为活跃才算就绪。已经在跑的服务也在等待范围内。
- 每个服务按自己的
ready_timeout:等待（默认 30s）。--wait-timeout是整体上限，只会收紧、不会放宽每个服务的预算。 prepare:不计入就绪预算；慢安装要靠prepare_inputs:缓存，或调用方自己的脚本超时。- 不等待时，已启动服务带
ready: false，表格写“就绪未确认”。这不是失败。 - 超时的服务是
failed，原因ready_timeout；消息会说是服务自己的预算先到，还是调用方的上限先到。
失败的时候
services[] 的每一项是 started、skipped 或 failed；失败带可分支的 reason，以及只指向真实存在证据的 hint。部分成功仍然恰好是一个 JSON 值，退出码 1。
| 原因 | 发生了什么 | 先读什么 |
|---|---|---|
start_failed | 命令根本没起来。 | hint：拒绝它的可执行文件、工作目录或环境。 |
port_occupied | 固定端口已经被占用。 | port_holder：占用者的端口、pid、命令和类型。 |
dependency_not_ready | 依赖在等待期间退出了。 | 依赖的日志；消息带它的退出码和原因。 |
dependency_timeout | 依赖活着，但一直没就绪。 | 依赖自己的 ready_timeout: 和日志。 |
ready_timeout | 服务自己没在预算内就绪。 | 服务的日志和它的就绪声明。 |
重启但不换地址
restart 先停项目再启动。带 --only 时只重启点名的服务，其余继续运行，并保留 worktree 的 port: auto 预留，所以服务拿回原来的地址。restart 不等就绪；调用方需要证据时用 up --wait。
oberth restart --only api