Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)

Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Implementation Specs (157)

Detailed engineering and feature implementation specifications.

implementation-specs/specs/RedshiftFoundation/TASK1.4.md 3,465 bytes · Updated Oct 23, 2026 10:44 AM EDT

Raw File

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:

resolve tenant_id -> tenant_database from kdsaidb,
reject missing tenant warehouse mappings,
reject inactive tenant warehouse mappings,
open a Redshift connection to the resolved tenant database,
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

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.