Spensara Spensara Knowledge Base & Documentation Repository

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/BackendDatabaseConsolidation/TASK2.1.md 1,743 bytes · Updated Oct 23, 2026 10:44 AM EDT
Raw File

TASK 2.1: Add backend customer and tenant membership persistence

Summary

Add the backend persistence model that replaces Laravel-owned Customer storage and supports identity-backed tenant authorization.

Dependencies

  • TASK 1.2 complete

Files to Modify

1. Backend entities and EF mapping

Likely files:

  • backend/Kds.Ai.Data/KdsAiDbContext.cs
  • new entity files under backend/Kds.Ai.Data/Entities
  • new EF configuration files if this project uses them
  • new EF migrations under backend/Kds.Ai.Data/Migrations

2. Backend data access and DI

Likely files:

  • backend/Kds.Ai.Data/DependencyInjectionExtensions.cs
  • new repositories or services for customer and membership access

Required Behavior

The backend must persist:

  • customers/tenants formerly owned by Laravel,
  • stable tenant identifier used by application data,
  • any membership or linkage needed to map an authenticated Keycloak subject to the correct customer/tenant,
  • enough customer metadata to satisfy existing admin and portal use cases.

The model should support:

  • listing customers,
  • creating and updating customers,
  • resolving caller tenant membership,
  • enforcing tenant scoping for non-admin users.

Acceptance Criteria

  • [ ] Backend has a customer/tenant entity model
  • [ ] Backend has a membership or equivalent identity-link model if required by chosen auth design
  • [ ] EF migration exists for the new persistence model
  • [ ] DI wiring exists for customer and membership access
  • [ ] The design does not depend on Laravel database records

Notes

  • Keep ownership boundaries clear: customer data belongs here, not in Keycloak.
  • Avoid recreating a full local identity store unless there is a concrete app-only need.