epic: ClawMetry OSS → Cloud refactor — pluggable DataProvider + extension system

[vivekchand]

Epic: ClawMetry Architecture Refactor

Goal: Decouple OSS and Cloud so they can evolve independently without breaking each other. Currently if CLOUD_MODE: conditionals are scattered through a 20k-line single file — every OSS change risks Cloud, every Cloud feature pollutes OSS.

The Plan

Core insight: Extract data retrieval into a ClawMetryDataProvider ABC. OSS implements it with local file reads. Cloud implements it with Turso/Firestore. Routes never touch files or DBs directly.

Flask Routes
    ↓
ClawMetryDataProvider (ABC)
    ↓                    ↓
LocalDataProvider    TursoDataProvider
(reads ~/.openclaw)  (reads Turso/Firestore)

Phases

• Phase 1 — Package scaffold feat: Phase 1 — Package scaffold (create clawmetry/ package, legacy dashboard.py shim) #44 (1-2 days)
• Phase 2 — Config class + extensions.py plugin system feat: Phase 2 — Config class + extensions.py plugin system #45 (1-2 days)
• Phase 3 — DataProvider ABC feat: Phase 3 — DataProvider ABC (pluggable data retrieval layer) #46 (3-5 days)
• Phase 4 — Flask Blueprint split feat: Phase 4 — Flask Blueprint split (one module per API group) #47 (1 week)
• Phase 5 — Cloud integration (TursoDataProvider + clawmetry-cloud) feat: Phase 5 — Cloud sync via clawmetry connect (no separate package) #48 (1-2 weeks)

Golden Rule

Every PR in every phase must leave clawmetry --host 0.0.0.0 --port 8900 working.

After completion

• OSS changes: open PRs to this repo, merged, released to PyPI
• Cloud changes: open PRs to private clawmetry-cloud repo, deployed to Cloud Run
• Zero cross-contamination between the two