mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 13:51:36 +00:00
shankar0123
c95685f8ab
Sprint 4 unified-master-audit closure. Every table that joins on a
tenant identifier (managed_certificates, agents, users, roles, audit
log, etc.) has a tenant_id column. The auth middleware at
internal/auth/middleware.go:97 stamps every authenticated request
with auth.DefaultTenantID. Repository queries don't filter on
tenant. A repo skimmer sees the columns and reasonably assumes
multi-tenancy is wired end-to-end. It isn't.
This was a diligence trap: a buyer planning multi-tenant SaaS
post-acquisition would inspect the schema, conclude the
foundation is in place, and discover at integration time that the
constant-tenant invariant is hard-coded across the request layer.
Fix: docs/reference/architecture.md grows a 'Single-tenant
deployment model' subsection in Design Principles that states
plainly:
- every authenticated request carries DefaultTenantID
- tenant_id columns are forward-compatible scaffolding for the
multi-tenancy roadmap item in WORKSPACE-ROADMAP.md
- lifting to multi-tenant requires three pieces in sequence:
(1) request-derived tenant resolution
(2) per-query tenant scoping
(3) the multi-tenant-query-coverage CI guard becoming
a hard gate
- until that work lands, the multi-tenant columns are decorative
The doc points at scripts/ci-guards/multi-tenant-query-coverage.sh
(which tracks tenant_id-less query drift as an informational
warning today) and explains the inflection point for flipping it
to hard-gate. '> Last reviewed:' bumped to today.
This is a docs-only commit. No runtime behavior change.
Closes ARCH-002-MT.