refactor: unify storage repo abstraction layer (panel/service repos bypass StorageContainer)

[nmhjklnm]

问题描述

当前 storage 层存在两套并行模式：

模式 A — 已有抽象层（核心 repos）

contracts.py（Protocol 定义）
    ↓
StorageContainer（统一工厂，strategy='sqlite'|'supabase'）
    ↓
lifespan.py 注入 → app.state.member_repo / thread_repo / ...
    ↓
Router 通过 request.app.state 取用

已覆盖：LeaseRepo, TerminalRepo, MemberRepo, ThreadRepo, ChatRepo, ContactRepo 等核心 repos。

模式 B — 直接实例化（panel/service repos）

# task_service.py
def _repo():
    return SQLitePanelTaskRepo(db_path=DB_PATH)  # 直接 new，绕过抽象

涉及文件：

• backend/web/services/task_service.py → SQLitePanelTaskRepo
• backend/web/services/cron_job_service.py → SQLiteCronJobRepo
• backend/web/services/monitor_service.py → SQLiteSandboxMonitorRepo（×8 处）
• backend/web/services/resource_service.py → SQLiteSandboxMonitorRepo + upsert_lease_resource_snapshot
• core/agents/registry.py → SQLiteAgentRegistryRepo
• core/tools/task/service.py → SQLiteToolTaskRepo
• sandbox/sync/state.py → SQLiteSyncFileRepo

临时解决方案（当前已合并）

新增 backend/web/core/storage_factory.py，提供按 LEON_STORAGE_STRATEGY 选择 provider 的工厂函数。各 service 改为调用工厂函数，Supabase 实现已对应补全。

这是有意为之的技术债，功能可用，但架构不一致。

正确解法（Approach A）

1. storage/contracts.py 补全 Protocol：PanelTaskRepo, CronJobRepo, AgentRegistryRepo, ToolTaskRepo, SyncFileRepo, SandboxMonitorRepo, ResourceSnapshotRepo
2. storage/container.py 扩展 StorageContainer 加入上述 repos 的 strategy wiring
3. backend/web/core/lifespan.py 注入到 app.state
4. 服务层 改为接受 repo 参数，由 router 从 request.app.state 传入
5. 删除 backend/web/core/storage_factory.py

验收标准

• 所有 service 不再直接 import storage.providers.sqlite.*
• LEON_STORAGE_STRATEGY=supabase 时所有 repo 均走 Supabase
• storage_factory.py 已删除
• contracts.py 覆盖全量 repo Protocol

参考

现有模式 A：storage/container.py, storage/contracts.py
临时补丁：backend/web/core/storage_factory.py
Supabase 实现：storage/providers/supabase/

[shuxueshuxue]

@f-2j 再详细说一下当前的实现和期望的实现有何不同

[f-2j]

@shuxueshuxue 我把“当前实现”和“期望实现”拆开讲清楚：

先澄清一个语义：

• main 分支当前真实代码：panel/service 相关 repo 仍然是直接 new SQLite*Repo。
• 我在 issue 里提到的“临时方案”：是指先加一层 storage_factory 做 strategy 分发（不进 StorageContainer）。

所以这里有两层“当前”，下面我按架构层面对比：

1) 入口层（repo 获取方式）

• 当前(main)：service 内直接 import storage.providers.sqlite.* 并实例化。
  • 例子：backend/web/services/task_service.py、cron_job_service.py、monitor_service.py
  • core/agents/registry.py、core/tools/task/service.py、sandbox/sync/state.py 也是同样模式。
• 期望：service 不再知道 sqlite/supabase 实现类，只依赖协议（Protocol）和注入进来的 repo 实例。

2) 抽象层（contracts/container 覆盖范围）

• 当前(main)：storage/contracts.py + storage/container.py 只覆盖核心一批 repo（checkpoint/run_event/lease/terminal/chat_session 等）。
  • PanelTask/CronJob/SandboxMonitor/AgentRegistry/ToolTask/SyncFile/ResourceSnapshot 还不在这套统一抽象里。
• 期望：把上述 repo 全部补进 contracts.py + StorageContainer，统一 strategy wiring。

3) 生命周期注入（lifespan/app.state）

• 当前(main)：backend/web/core/lifespan.py 只注入了 entity/chat/thread/member 这一组 sqlite repo。
• 期望：把 panel/service 那组 repo 也在 lifespan 注入到 app.state，路由/服务从这里拿。

4) 服务层签名与依赖方向

• 当前(main)：router -> service 函数（service 自己创建 repo）。
• 期望：router/lifespan 负责拿 repo，service 接收 repo 参数（或构造注入），依赖方向改成“上层注入、下层纯业务”。

5) strategy 一致性（sqlite/supabase）

• 当前(main)：这批 panel/service repo 只有 sqlite 实现，LEON_STORAGE_STRATEGY 对这部分不生效。
• 期望：所有 repo 都由同一 strategy 入口决定，LEON_STORAGE_STRATEGY=supabase 时不会再有“局部仍走 sqlite”的绕行。

6) 关于 storage_factory 的定位

• 临时方案（如果采用）本质上是“把直接 new sqlite”升级成“通过工厂做分发”，但仍是旁路，不是最终统一抽象。
• 期望最终态：分发逻辑只在 StorageContainer，storage_factory.py 不再需要。

一句话总结：

• 当前(main)问题是“实现层直连 + 抽象层缺口 + 生命周期未统一注入”；
• 期望实现是“协议统一 + 容器统一分发 + 生命周期统一注入 + 服务层只做业务，不感知 provider”。

[shuxueshuxue]

Related follow-up PR #209 is handling the resource/monitor Supabase migration and contract split in a bounded slice, while preserving the existing repo/protocol abstraction shape. Not claiming full closure of #191, but it touches one of the concrete seams called out there. #209

[shuxueshuxue]

@f-2j why is the linked #209 closed? check the status and current related prs

[f-2j]

@shuxueshuxue 已核查，结论如下（按当前 GitHub 状态）：

1. 为什么 Design resource observability split #209 关闭

• Design resource observability split #209 是 Draft PR，状态是 CLOSED，merged_at = null，说明不是合并关闭。
• 关闭时间：2026-04-06 13:16:03 UTC。
• 关闭前作者在 Design resource observability split #209 明确写了两条：
  • “Superseded by Integrate compat monitor into resource observability split #210”
  • “Closing this in favor of Integrate compat monitor into resource observability split #210 ... Integrate compat monitor into resource observability split #210 continues as the single review surface.”
• 对应评论：
  • Design resource observability split #209 (comment)
  • Design resource observability split #209 (comment)

2. 当前 related PR 状态

• 直接引用 refactor: unify storage repo abstraction layer (panel/service repos bypass StorageContainer) #191 的 PR（文本检索 #191）：目前只看到 #209（已关闭）。
• Design resource observability split #209 的后续承接 PR：#210（OPEN, Draft）
  • Integrate compat monitor into resource observability split #210
  • Integrate compat monitor into resource observability split #210 的描述里写了 Supersedes #209，所以现在实际审阅面是 Integrate compat monitor into resource observability split #210。
• 另外，Integrate compat monitor into resource observability split #210 同时标注 Follow-up to #182，而 feat(monitor): transplant compat monitor and swebench runner #182 当前是已关闭（未合并）。

如果你希望，我下一条可以把“#191 的验收项”逐条映射到 #210 当前覆盖到哪一步（已覆盖/未覆盖/需后续 PR）。