Documentation Index
Fetch the complete documentation index at: https://mintlify.com/kishnahai0806/SteelWorks/llms.txt
Use this file to discover all available pages before exploring further.
OperationsDataSource is a typing.Protocol defined inline in app.service (app/service.py) that defines the contract between OperationsMetricsService and its data source. Any object that implements these four methods with compatible signatures can be passed as the repository argument to the service — no inheritance or explicit registration is required.
Protocol definition
Method signatures
get_available_weeks
OperationsMetricsService: calendar_week_id (int) and week_label (str).
get_available_lines
production_line_id (int), line_name (str), and is_active (bool). The service expects the repository to handle any active/inactive filtering itself.
get_issue_summary
The
calendar_week_id of the selected production week.Deduplicated, sorted list of selected
production_line_id values. The service normalizes line IDs via normalize_line_ids() before this method is called.When
True, the returned dicts must include a line_name key in addition to week_label, issue_type_name, and issue_count. When False, line_name is omitted.get_affected_lots
The
calendar_week_id of the selected production week.Deduplicated, sorted list of selected
production_line_id values.week_label (str), line_name (str), lot_code (str), issue_count (int), and issue_types (str, comma-separated).
Implementing a custom data source
Any class that satisfies the four method signatures above works as a repository. The example below shows a minimal test double suitable for unit testing:Python uses structural subtyping —
FakeDataSource does not need to explicitly inherit from or register with OperationsDataSource. It just needs to implement the four methods with compatible signatures.