chore: migrate all YAML-only config paths to DB-backed settings #453
Description
Summary
Systematic audit and migration of every place in the codebase that reads configuration directly from YAML/Pydantic config models. All config reads must go through the SettingsService so that DB overrides take precedence over YAML defaults.
Why
After #450 (settings persistence layer) is implemented, the old direct-YAML paths become a bypass — changes made via UI/API would be ignored by code that still reads from the original config objects. Every config consumer must be migrated.
Audit Targets
Files that currently read from YAML-loaded config (non-exhaustive — full audit needed at implementation time):
| File | What it reads | Migration |
|---|---|---|
| `config/loader.py` | Loads YAML, builds RootConfig | Becomes "defaults provider" — SettingsService reads from it as fallback |
| `config/schema.py` | ProviderConfig, CompanyConfig, etc. | Models stay, but consumers read via SettingsService |
| `providers/registry.py` | Provider configs from RootConfig | Read from SettingsService, subscribe to change events |
| `providers/routing/resolver.py` | Routing config | Read via SettingsService |
| `memory/config.py`, `memory/factory.py` | Memory backend config | Read via SettingsService |
| `memory/backends/mem0/config.py` | Mem0-specific config | Read via SettingsService |
| `engine/coordination/section_config.py` | Coordination config from YAML | Read via SettingsService |
| `api/state.py` | App state built from config | Wire SettingsService into state |
| `api/controllers/company.py` | Company config | Read via SettingsService |
| `templates/loader.py` | Template YAML files | Templates are read-only content, NOT user settings — leave as YAML. But template selection config goes to DB. |
What Stays as YAML
- Template definitions (`templates/`) — these are content/blueprints, not user settings
- Default values — YAML files become the "factory defaults" layer in the resolution chain
- Schema definitions — Pydantic models remain, they just get populated from SettingsService instead of directly from YAML
What Moves to DB
- All provider configuration (keys, URLs, models, retry config)
- Company configuration (name, agents, hierarchy, budgets)
- Memory backend configuration
- Coordination configuration
- Observability settings (log level, sinks)
- Security settings (trust strategies, autonomy levels)
- Any per-agent overrides
Dependencies
- feat: implement settings persistence layer (DB-backed config) #450 — Settings persistence layer (must be implemented first)
Acceptance Criteria
- Full audit of every YAML config read path
- Every config consumer reads through SettingsService
- DB overrides take precedence over YAML defaults
- No config change requires a YAML edit + restart
- Templates (content) remain as YAML files — only template settings move to DB
- Existing YAML configs still work as defaults (backward compatibility)