deploy目录是运行配方不是另一套应用
一、判断某个文件该放哪
| 内容 | 归属 |
|---|---|
| 某个可独立启动的服务/命令 | apps/ |
| 被多个 app 复用的适配器、schema、类型 | packages/ |
Dockerfile、compose、.env.*.example、部署 README | deploy/ |
推论：通用 provider adapter 放 packages/，workflow 编排放 apps/ —— 前者被复用，后者是可执行逻辑。
二、一个易混点：配置放在 deploy，但读取方是 app
deploy/<service>/.env.* 只是把配置注入容器/进程；运行时实际读取配置的仍然是 apps/ 里的代码。调用链是：
deploy/<svc>/compose.yml
→ 启动 apps/<svc> 的命令
→ apps/<svc> 执行
→ packages/* 调外部服务 / 读写数据库
所以「环境变量该放哪」要问两个问题：谁读取它（决定文件属于哪个服务的配置契约），谁部署它（决定文件放在哪个 deploy 目录）。
三、配置按边界分，不按习惯分
沿用 web 的根目录 .env.local 习惯到独立的 worker 服务上是错的：worker 属于后台进程，不是 web。每个可独立部署的单元应有自己的配置契约（并配 .example + gitignore），既避免把某类专用 key 暴露给 web 进程，也让预览/生产沿用同一份契约。
相关
- Schema是声明Migration是历史
- 两个执行入口共用一套业务规则
- Agent Harness 不只是 Tool Loop