# TASK 1.4: Add Backend Tenant Warehouse Smoke Path

## Summary

Create the minimal backend smoke path that proves application code can resolve a tenant warehouse and connect to the correct Redshift tenant database.

This task implements the backend integration seam required by `../../docs/features/ETL/slices/01-redshift-foundation/foundation-spec.md`.

It does not migrate simulator writes, anomaly detector queries, monitor definitions, or ETL runtime behavior.

Status: deferred in the current branch shape.

The original dedicated validator abstraction and CLI command were removed when the branch stopped enforcing a hardcoded canonical curated contract.

## Dependencies

- TASK 1.1 (tenant routing metadata)
- TASK 1.2 (tenant warehouse foundation abstractions)
- TASK 1.3 (Redshift connectivity and configuration)

## Files to Create

### 1. Tenant warehouse smoke path in `backend/Kds.Ai.Warehouse`

Create a small smoke-testable operation that exercises the real foundation path:

1. resolve `tenant_id -> tenant_database` from `kdsaidb`,
2. reject missing tenant warehouse mappings,
3. reject inactive tenant warehouse mappings,
4. open a Redshift connection to the resolved tenant database,
5. confirm the tenant Redshift database can be opened against the bootstrapped phase-1 schema template.

### 2. Validation result model

Create a result model that can report:

- resolved `tenant_id`,
- resolved `tenant_database`,
- active/inactive mapping state,
- connection success or failure,
- validation errors.

The exact model shape may differ, but failures must be explicit enough for CLI/admin callers to diagnose bootstrap problems.

## Files to Modify

### 3. `backend/Kds.Ai.Cli` or other smoke entrypoint

If a smoke command is added, it should accept `tenant_id` and should not accept a direct tenant database override. Database selection must come from `kdsaidb`.

### 4. DI modules as needed

Register the smoke-path service in the same foundation DI path as the resolver, connection factory, and bootstrapper.

## Required Behavior

- Resolve tenant database through the platform metadata path, not through user-provided SQL or command-line database overrides.
- Fail clearly for missing tenant mapping.
- Fail clearly for inactive tenant mapping.
- Open the resolved Redshift tenant database through the foundation connection factory.
- Keep existing PostgreSQL-based simulator/runtime paths intact.
- Do not integrate this validation path into the anomaly detector runtime.

## Acceptance Criteria

- [ ] A backend validation service exists in `Kds.Ai.Warehouse`
- [ ] The validation service resolves `tenant_id -> tenant_database` from `kdsaidb`
- [ ] Missing tenant mappings are rejected clearly
- [ ] Inactive tenant mappings are rejected clearly
- [ ] The validation service opens the resolved Redshift tenant database through the foundation connection factory
- [ ] A CLI smoke command exists to invoke the validation service by `tenant_id`
- [ ] The CLI smoke command does not accept direct tenant database routing overrides
- [x] Existing PostgreSQL-based runtime paths are not changed by this task
- [x] Solution builds without errors

## Notes

- This task proves the backend integration seam, not business runtime behavior.
- The branch currently relies on bootstrap plus later runtime consumers rather than a dedicated validator command.
- Do not make the anomaly detector, simulator, or monitors depend on this path in phase 1.