Configuration and Branding

Current Shape

This repository does not implement a runtime tenant-configuration studio or an operator-editable branding platform; the current architecture explicitly treats per-tenant code, services, and deployment composition as the customization mechanism (docs/architecture/anti-goals.md:5-31).

The repo-local architecture notes describe the platform as headless, Cloudflare-native, multi-D1, and domain-worker based, with UI applications living in peer forks rather than in this repository (CLAUDE.md:14-23).

Anti-Goals That Govern Configuration

Generic tenant feature flags are explicitly out of scope because tenant differences should be represented through generated code, schemas, and deployed surfaces rather than broad runtime switches (docs/architecture/anti-goals.md:5-8).

A broad key-value behavior store is explicitly out of scope because operational behavior should not be hidden behind arbitrary runtime settings (docs/architecture/anti-goals.md:9-12).

Runtime JavaScript injection for tenant-specific behavior is explicitly out of scope because tenant differences should compile into tenant-specific surfaces, not injected snippets (docs/architecture/anti-goals.md:13-15).

Broad company-tree behavior inheritance is explicitly out of scope except for strict operational data such as hours and closures (docs/architecture/anti-goals.md:17-19).

Config-freeze and audit user interfaces are explicitly out of scope because Git history and deployment history are the audit mechanism for tenant behavior changes (docs/architecture/anti-goals.md:21-23).

A shared SaaS codebase with feature switches is explicitly out of scope; the intended shape is per-customer code surfaces deployed from the shared platform primitives (docs/architecture/anti-goals.md:25-27).

Operator-editable app builders and configuration consoles are explicitly out of scope because customization should happen in code and services (docs/architecture/anti-goals.md:29-31).

What Configuration Exists

The control plane still records tenant identity, tenant status, plan, root company, and region hint when a tenant is created or updated (workers/control-plane/src/routes/tenants.ts:12-28, workers/control-plane/src/routes/tenants.ts:47-84).

The control plane records feature-catalog entries with feature key, deployed version, integration provider, customization JSON, and migration timestamp metadata (workers/control-plane/src/routes/catalog.ts:7-24).

Feature-catalog registration inserts or updates catalog rows for a tenant and returns the registered feature list (workers/control-plane/src/routes/catalog.ts:51-114).

Feature-catalog update allows deployed version, customization JSON, last migration timestamp, and integration provider metadata to be changed for an existing feature row (workers/control-plane/src/routes/catalog.ts:116-186).

Those catalog records are inventory and deployment metadata, not a license to implement arbitrary runtime feature switches, because the anti-goals reject generic feature flags and broad runtime behavior stores (docs/architecture/anti-goals.md:5-12, workers/control-plane/src/routes/catalog.ts:7-24).

Gateway Reality

The edge gateway routes admin config paths to the catalog worker and admin brand paths to BRAND_STUDIO_WORKER when that binding exists in the runtime environment (workers/edge-gateway/src/router.ts:15-34).

The checked-in gateway wrangler.toml binds catalog, booking, availability, events, queue, integrations, Google sync, reporting, staff feed, auth, and control-plane services, but it does not declare a BRAND_STUDIO_WORKER service binding in the displayed service-binding table (workers/edge-gateway/wrangler.toml:17-59).

The safe current documentation is therefore that brand/admin routes exist in router code, while this repo does not currently provide a runtime brand-studio implementation as part of the documented Worker binding set (workers/edge-gateway/src/router.ts:15-34, workers/edge-gateway/wrangler.toml:17-59).

Tenant-Specific Surfaces

The repo guide identifies peer forks such as voyage-bank as the reference location for tenant-specific product surfaces and Meridian UI proof points (CLAUDE.md:14-23).

Current technical documentation should point customization work to per-tenant code, tenant topology, generated schemas, and deployment automation rather than to a runtime admin studio (docs/architecture/anti-goals.md:5-31, CLAUDE.md:14-23).

Corrections From Frozen HTML

The frozen page's deployment composition and tenant provisioning themes remain relevant, but claims about runtime feature configuration, runtime branding controls, operator app builders, or brand-studio customization are not supported by current architecture anti-goals (docs/architecture/anti-goals.md:5-31).

The frozen page's operational-settings framing should be narrowed to strict operational data such as hours and closures, because broad inherited behavior configuration is explicitly excluded (docs/architecture/anti-goals.md:17-19).

last verified: 2026-04-24, commit 14f3b190db8817399dcd30e1dc4e1ae7674bbf8a