[Vanarasiteja]

Why

Establish the first usable Kronos-Macro application layer without modifying the upstream Kronos model. The change adds validated market-data contracts, point-in-time filtering, a safe Kronos adapter, and transparent risk/decision primitives so later macro and pipeline work can build on stable interfaces.

What changed

• Added normalized observation schemas with UTC availability timestamps, revision metadata, validation, and as-of filtering.
• Added configurable Yahoo market-data collection, persistence paths, provider status reporting, and an optional credential-gated FRED adapter.
• Added risk sizing and trade assessment with instrument/account constraints, execution costs, R multiple, and portfolio limits.
• Added expected-value validation and explainable LONG/SHORT/NO_TRADE decision logic.
• Added a lazy Kronos adapter around the repository's actual model API with CPU as the default device, OHLCV validation, configurable context/timeframe, and explicit unavailable confidence/range fields.
• Added KRONOS-MACRO-SPEC.md documenting point-in-time semantics, scoring, regime precedence, risk, EV, and integration boundaries.

Validation

• python3 -m pytest -q tests/test_data_foundation.py tests/test_risk_decision.py tests/test_kronos_adapter.py
• Result: 21 passed
• git diff --check passed

Limitations

• Direct push to the upstream repository is unavailable from this account; the PR flow must use the authenticated fork path.
• Live Yahoo collection requires the optional provider dependency and network access.
• FRED collection requires FRED_API_KEY and an approved FRED client configuration.
• Real Kronos inference requires the model dependencies and pretrained artifacts; offline adapter tests use mocks.
• Macro factor and end-to-end orchestration layers remain follow-up work and are not fabricated by this change.