application-tenant

Forge tenant module — multi-tenancy + per-tenant DB isolation. Wraps identity-tenant + infrastructure-tenant-pool. Unlocks SaaS-shape consumer apps with isolated tenant orgs.

What it is for

application-tenant — multi-tenancy for the Forge framework.

Wraps identity-tenant (tenant identity, status, isolation strategy) and infrastructure-tenant-pool (per-tenant DB pool management). Foundation for the saas profile.

B-009: before this, migrations() returned Vec::new() and migrate_pending returned Ok(0) while ignoring the pool, so tenants and tenant_members (plus the invite workflow / single-owner constraints) were never created by anything that actually called this module's own migration path. infrastructure-tenant-pool (crates/infrastructure/tenant-pool) ships no migrations/ directory of its own — it manages per-tenant PgPool instances at runtime, no schema — so only identity-tenant's two files are vendored here.

Real gap found at Gate 0.5, not solved here: the central application-engine platform set independently mirrors this exact schema (crates/application/engine/migrations/093_tenant_tables.sql, whose own header says it copies identity-tenant/migrations/{001,002} verbatim) but wraps every CREATE TABLE in IF NOT EXISTS and every CREATE TRIGGER in a DO $$ ... EXCEPTION WHEN duplicate_object guard. The library crate's own vendored files, unlike that mirror, use plain CREATE TABLE tenants / CREATE TABLE tenant_members with no IF NOT EXISTS. So on a DB where the central set has already run, calling this module's own migrate_pending() errors with "relation already exists" instead of the no-op the central mirror was written to guarantee — the inverse of application-taxonomy's silent-shadowing gap (same root cause: two independent copies of one library crate's schema, one idempotent and one not). Matches B-009's own Risk Assessment ("double-applying migrations... must be idempotent and must not assume a virgin schema"); flagged rather than guessed around, per application-catalog's precedent.

Second dependency gap, same Gate-0.5 pass, not a bug — solvable by the caller: both migration files attach an update_updated_at_column() trigger without defining that function themselves. It is foundation-basemodels' own prerequisite (crates/foundation/basemodels/migrations/001_base_model_infrastructure.sql, same shape as application-taxonomy's identical gap). A host mounting application-tenant standalone must apply that one migration first (or application-engine's central platform set, which also defines the function) or migrate_pending() fails with "function ... does not exist". The live-pg test applies foundation-basemodels' migration directly.

Capabilities

TenantModule

application-tenant — multi-tenancy for the Forge framework.

How to use it

No examples/ target and no doctest in this crate's rustdoc. The tests listed under Verification are the closest executable usage.

Module structure

No public modules: the crate root is its whole surface.

Public surface

`crate root`

Re-exports. Exported here, defined elsewhere.

Boundary

Reaches into identity, infrastructure.

Shares tier application with 120 other crates: application-agreements, application-ai, application-analytics, application-approvals, application-assessments, application-audit-log, application-auth, application-billing, … (120 total).

_What this crate deliberately does NOT own is a judgment. No committed registry records one for it, so none is stated here._

Where it sits

Tier flow. Which tiers this crate's own edges cross.

flowchart LR
  n_application["application"] --> n_identity["identity"]
  n_application["application"] --> n_infrastructure["infrastructure"]

Dependencies

Runtime, in this workspace.

Runtime, from outside the workspace.

Development, from outside the workspace.

Build. None.

Depended on by. Nothing in this workspace.

Signal flow — what reaches this crate, and what it reaches.

flowchart LR
  SELF["application-tenant"]
  SELF -->|runtime| n_application_core["application-core"]
  SELF -->|runtime| n_identity_tenant["identity-tenant"]
  SELF -->|runtime| n_infrastructure_tenant_pool["infrastructure-tenant-pool"]
  classDef self fill:#1f883d,stroke:#1f883d,color:#fff;
  class SELF self;

Feature flags

No Cargo features are defined: every capability is unconditional, so no consumer can receive a half-wired crate.

Targets

Error model

No public error type was detected: no public item declares a type named *Error, and no public signature returns one.

Operational characteristics

No unsafe block, unsafe fn, unsafe impl or unsafe trait was found by the parser anywhere in this crate's source.

Configuration

Related capabilities

No workspace crate depends on this one.

Verification

Evidence by module. How often each public module is named by something executable.

What the tests establish, by name:

• migrate_pending_creates_tenant_members_table — tests/pg_forge_tenant.rs
• test_module_migrations_non_empty — src/lib.rs

Documentation coverage

pie showData
    title Public items with rustdoc
    "Documented" : 0
    "No rustdoc detected" : 7

Metrics

pie showData
    title Public API by kind
    "method" : 6
    "struct" : 1

pie showData
    title Rust source composition
    "Code" : 66
    "Blank or comment" : 56

Generation

Rendered by tools-corpus corpus readme from repository evidence alone, renderer schema 2, lexicon current. No model, network service or database was consulted. Regenerate with tools-corpus corpus readme --write; verify with --check.