# TASK 1.1: Add Synthetic Feed Configuration and Service Contract

## Summary

Create the configuration, request/result models, and service contract for the temporary synthetic KDS feed.

This task establishes the implementation seam for:

- selecting the target `tenant_id`,
- selecting the source simulator `store_guid`,
- choosing incremental or full-refresh behavior,
- invoking the reusable synthetic feed service from CLI or future dev/admin adapters.

This task does not read source data or write Redshift rows yet.

## Dependencies

- Redshift Foundation slice complete

## Files to Create

### 1. Synthetic feed options/models

Create options and models in the appropriate backend module. Prefer placing the reusable feed contract near the warehouse foundation or an integration-oriented module rather than inside CLI command code.

Recommended logical models:

- `SyntheticKdsFeedOptions`
- `SyntheticKdsFeedRequest`
- `SyntheticKdsFeedResult`
- `WarehouseFeedMode` or equivalent mode flag

Exact names may differ, but these concepts must be represented.

### 2. Synthetic feed service abstraction

Create a reusable service contract equivalent to:

- `IWarehouseFeed<SyntheticKdsFeedRequest, SyntheticKdsFeedResult>`

The contract should expose one async operation that accepts a request and returns a result.

## Files to Modify

### 3. Dependency injection registration

Register the synthetic feed service contract and options shape where the implementation will be consumed.

Do not wire it into anomaly detector runtime behavior.

## Required Behavior

The request/options model must support:

- `tenant_id`
- source `store_guid`
- full-refresh mode
- optional incremental mode
- cancellation token support through the async service method

The result model should support:

- target `tenant_id`
- target `tenant_database`
- source `store_guid`
- batch id when available
- orders read/written count
- order items read/written count
- skipped/deleted count when available
- validation summary when available
- success/failure status or exception propagation strategy

## Acceptance Criteria

- [x] A synthetic feed options/configuration shape exists
- [x] Feed request model includes `tenant_id` and source `store_guid`
- [x] Feed request supports full refresh and/or incremental mode
- [x] Feed result model exposes row counts and target tenant/database context
- [x] A reusable synthetic feed service abstraction exists
- [x] Feed contracts are not implemented only inside CLI code
- [x] DI registration path exists for the feed service
- [ ] No source reads are implemented in this task
- [ ] No Redshift writes are implemented in this task
- [x] Solution builds without errors

## Notes

- Keep names clearly marked as synthetic/bootstrap infrastructure.
- The contract should be easy to remove or replace when the real ETL runtime exists.
- Do not add S3, `COPY`, `UNLOAD`, Athena, or production adapter concepts here.