feat: migrate existing config paths to read through SettingsService #497
Description
Summary
Migrate all existing config consumers (budget, security, providers, etc.) to read through SettingsService instead of directly from RootConfig. This is acceptance criterion 8 from issue #450, deferred from PR #495 due to scope.
Context
PR #495 implemented the settings persistence layer with:
SettingsServicewith 4-layer resolution (DB > env > YAML > code defaults)SettingsRegistrywith 8 namespace definition modulesconfig_bridge.pywith YAML path resolution- REST API endpoints
The infrastructure is in place — this issue covers the actual migration of call sites.
Acceptance Criteria
- All config consumers use
SettingsService.get()instead of directRootConfigattribute access -
RootConfigbecomes a "defaults provider" only — not the sole config source - Existing behavior is preserved (tests pass with same config values)
- Migration is incremental — can be done module by module
Related
- Closes criterion 8 of feat: implement settings persistence layer (DB-backed config) #450 (deferred from PR feat: implement settings persistence layer (DB-backed config) #495)
Audit Targets (from #453)
Files that currently read from YAML-loaded config (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/) — content/blueprints, not user settings - Default values — YAML files become "factory defaults" in the resolution chain
- Schema definitions — Pydantic models remain, 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
Additional Acceptance Criteria (from #453)
- Full audit of every YAML config read path
- 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)