config.yaml — replace direct Python file editing for watchlists, weights, and output preferences

[DogInfantry]

Summary

Introduce a config.yaml as the single configuration entry point. Users should never need to edit pipeline_v2.py or screening.py directly for standard customisation like watchlists, screener weights, peer sets, or output format preferences.

Motivation

Editing pipeline_v2.py is a developer behaviour. Config files are a user behaviour. This is the single lowest-effort change with the highest adoption impact. It also makes the repo look production-designed rather than demo-grade, which matters for portfolio credibility.

Proposed config.yaml Structure

# config.yaml
watchlist:
  - AAPL
  - MSFT
  - NVDA

as_of: "2026-04-15"  # or "latest"

screener:
  weights:
    valuation: 0.30
    quality: 0.25
    growth: 0.25
    momentum: 0.20
  min_score: 0.60

output:
  format: [html, pdf, markdown]
  interactive_charts: true
  include_audit_trail: true

peers:
  AAPL: [MSFT, GOOGL, META, AMZN]
  MSFT: [AAPL, GOOGL, ORCL, SAP]

data_sources:
  fred_api_key_env: FRED_API_KEY
  sec_user_agent_env: SEC_USER_AGENT

Implementation Notes

• Use pydantic-settings or PyYAML + dataclass for typed config loading
• Environment variable overrides for all API keys (never in config.yaml)
• config.yaml validated at startup with clear error messages for missing/invalid fields
• CLI flag --config path/to/config.yaml to specify non-default location
• Provide config.example.yaml with all fields documented

Acceptance Criteria

• config.yaml loaded at pipeline start and validated
• Watchlist, screener weights, peer sets, and output format all driven by config
• config.example.yaml committed with inline documentation comments
• pipeline_v2.py and screening.py no longer require direct editing for standard use
• CLI --config flag supported
• Unit tests for config validation (missing fields, invalid types, env var resolution)
• README Quick Start updated to show config.yaml setup as primary workflow